【软考高级·系统分析师全链路通关实战】第 30 篇需求验证与确认——让需求在编码前就被检验本系列定位面向有开发经验、从零备考软考高级「系统分析师」的工程师以《系统分析师教程第 2 版》为主线按「综合知识 → 案例分析 → 论文」三科组织需求工程与 UML 建模深拆60 篇带你从考试小白到三科同过。本篇你将学到需求验证与确认的区别验证「正确地写」确认「写正确的」需求评审正式评审的流程阶段、评审检查单的编制与使用需求测试从需求导出验收测试用例的「可测试性」思想ATDD 雏形原型验证与形式化验证思想衔接第 19 篇的适用边界验证通过 → 需求基线的门槛关系云诊通实战问诊需求评审会发现的三类典型缺陷含缺陷定位与修复动作学完本篇你将在编码开始前就拥有一套检验需求质量的手段组合——这是把第 26 篇「1:10:100 规律」红利兑现的唯一途径。考点热力表|| 知识点 | 综合知识 | 案例分析 | 论文 ||--------|:—:—:—| 验证与确认的区别VV | ★★★ | ★★ | ★ || 需求评审流程与角色 | ★★ | ★★★ | ★★★ || 评审检查单 | ★ | ★★ | ★★ || 从需求导出测试用例可测试性 | ★★ | ★★★ | ★★ || 原型验证与形式化验证 | ★★ | ★ | ★ || 需求基线与验证的关系 | ★★ | ★ | ★★ |一、验证与确认VV 的分野1.1 两个易混概念验证Verification「我们是否正确地构建了产物」——检查 SRS 是否符合规范、是否忠实于获取与分析的结论文档自身质量单一化、无歧义、格式合规确认Validation「我们是否构建了正确的产物」——检查 SRS 描述的需求是否真正反映干系人的意图、是否解决业务问题内容正确性是不是用户真的要的一句话区分验证对照标准与上游产物确认对照真实世界与用户意图。案例题干若问「评审发现需求与用户描述不符」这是确认问题若问「需求条目含模糊词」这是验证问题。1.2 需求阶段 VV 的手段组合手段属于做什么成本需求评审验证 确认组织多方对 SRS 文档做系统性检查中需求测试导出用例确认为每条需求设计验收测试写不出用例即需求缺陷信号中低原型验证确认用可交互原型让用户提前「试用需求」中形式化验证验证用数学化规格与工具检查一致性与完备性高** walkthrough 走查 **验证非正式的小范围带领式阅读检查低选择原则成本从低到高叠加——走查抓低级问题、评审做系统覆盖、测试化检验可验证性、原型验证关键体验、形式化只用于安全攸关的核心逻辑云诊通仅处方状态与权限规则做过轻量形式化检查衔接第 19 篇形式化方法概念。二、需求评审正式评审的流程2.1 流程阶段正式评审以最规范的审查 Inspection 为代表分六个阶段未通过通过规划确定范围/角色/时间总体会议发放材料, 背景介绍准备评审人独立预读并记录问题评审会议逐条过文档, 记录缺陷不打断争吵返工作者按缺陷清单修改追查确认缺陷关闭, 评审结论签字进入需求基线第31篇角色分工主持人控流程、作者被评审文档的撰写者会上主要倾听、评审人技术/业务/测试视角、记录员缺陷登记位置、描述、严重级。评审会议的纪律是「评文档不评人」「记录缺陷而非当场修复」——当场改文档会让会议失控。2.2 评审检查单检查单checklist把评审经验固化为可勾选条目云诊通需求评审检查单节选#检查项依据1每条需求是否单一化无「并且」连接的两件事第 29 篇铁律2是否存在「快/友好/及时/尽量」等模糊词无歧义性3每条需求是否标注了验证方法可验证性4需求之间是否存在矛盾时限/口径/优先级一致性5与监管合规清单逐条核对合规需求是否全部在册完整性6每条需求能否追溯到来源条目可跟踪性7边界与例外情况是否都有定义24 小时未回复怎么办完整性8接口需求是否定义了超时、重试、降级路径接口规格完整性综合知识考点检查单属于静态分析手段不运行系统评审属于静态测试技术中的人工审查类。三、需求测试可测试性的极致运用3.1 从需求导出验收用例「需求测试」不是运行系统系统还不存在而是为每条需求尝试编写验收测试用例——写得出说明需求可验证写不出暴露的是需求缺陷。操作模板给定条件Given构造需求的前置场景患者 3 个月内有同院同科就诊记录当When触发需求描述的动作患者提交图文问诊申请则Then核对量化的预期结果系统创建会话并入候诊队列响应时间达标这套 Given-When-Then 三段式正是验收测试驱动开发ATDD的雏形需求条目与验收用例在基线前同步产出测试人员从需求阶段就介入不是等代码写完才拿 SRS。对 REQ-IVC-003消息延迟 ≤2 秒导出用例时还会追问「延迟从哪个时间点算起统计窗口多大」——这类追问又反哺需求文本精化形成闭环。3.2 原型验证与形式化验证原型验证对「患者完成预约不超过 5 步」这类体验型需求用低保真原型请真实用户走查任务路径记录步数与卡点——第 27 篇用于获取本篇用于确认同一原型两种用途形式化验证把关键规则处方状态转换、权限判定表达为形式化规格用模型检验工具穷举状态空间查死锁与不可达状态。成本高只投在「错了会出人命」的规则上——云诊通处方域的「开方→审方→生效→上报」状态机做了一轮检查发现一个「拒方后重开」的缺失转换四、云诊通实战评审会上的三类典型缺陷问诊域 SRS第 29 篇 REQ-IVC 系列的正式评审会评审人包括分析师同行、架构师、开发代表 2 名、测试代表 1 名、医生代表 1 名、监管联络员 1 名。会上登记缺陷 17 项归为三类类型一边界条件缺失完整性缺陷9 项。示例REQ-IVC-001 定义了资格校验通过与不通过两条路径但未定义「就诊记录跨院是否计入」联合体内 7 家医院互认吗。修复动作补充「牵头医院与成员医院就诊记录互认跨联合体记录不计入」并升格为一条新需求。这类缺陷的共性是主路径清晰、例外路径空白——评审时专问「如果…会怎样」最有效。类型二量化口径歧义无歧义性缺陷5 项。示例REQ-IVC-003 的「端到端延迟 ≤2 秒」开发与测试对「端到端」的起止点理解不同患者点击发送 vs 服务端落库医生端展示 vs 医生端接收。修复动作精确定义为「患者端点击发送至医生端界面呈现的时间差采样点取两端埋点」。类型三角色权限与合规漏洞确认类缺陷3 项。示例医生代表指出「实习生能否用带教医生账号接诊」监管联络员指出「问诊结束后的处方开具时限未定义」。这类缺陷靠纯文档走查很难发现必须让业务方与合规方坐进评审会——这正是评审角色构成的价值论证论文可用论点。评审结论17 项缺陷全部修复并追查关闭后SRS 第 2 版签字通过问诊域需求进入基线。三类缺陷的分布完整性 9 无歧义 5 确认 3也是经验规律边界缺失永远是第一大需求缺陷来源。记录员评审人(技术业务)主持人分析师(作者)记录员评审人(技术业务)主持人分析师(作者)提交问诊域 SRS v11会前3日发放材料检查单2独立预读, 记录预审问题3召开评审会议4逐条报缺陷(位置/描述/严重级)5登记17项缺陷清单6缺陷清单移交, 限期返工7修复: 补边界/精化口径/堵合规漏洞8提交 SRS v29追查缺陷关闭10确认关闭, 通过11评审结论签字, 进入需求基线12真题风格自测题1. 「检查 SRS 是否真实反映用户的业务意图」属于 。A. 验证 B. 确认 C. 静态分析 D. 配置审计2. 「检查需求条目是否符合单一化、无歧义等文档规范」属于 。A. 确认 B. 验证 C. 系统测试 D. 回归测试3. 正式评审审查流程的正确顺序是 。A. 规划→总体会议→准备→评审会议→返工→追查 B. 评审会议→准备→规划→返工 C. 准备→评审会议→规划→追查 D. 规划→评审会议→准备→返工4. 评审会议的基本纪律是 。A. 当场重写文档 B. 评文档不评人记录缺陷而非当场修复 C. 只允许管理者发言 D. 匿名投票定稿5. 「为每条需求尝试编写验收测试用例写不出用例即视为需求缺陷信号」体现的思想是 。A. 需求可测试性 B. 代码覆盖率 C. 性能基准 D. 数据规范化6. Given-When-Then 三段式用例模板主要用于 。A. 编译器设计 B. 从需求导出验收用例 C. 网络协议分析 D. 数据库索引设计7. 需求验证通过后需求集合的下一站是 。A. 直接编码 B. 建立需求基线纳入变更控制 C. 作废重写 D. 转入概要设计且不再回顾8. 评审检查单属于的手段类别是 。A. 动态测试 B. 静态分析人工审查 C. 形式化验证 D. 压力测试9. 云诊通评审缺陷中占比最高的类型是 。A. 边界条件缺失 B. 排版错误 C. 优先级标注错误 D. 图例风格不统一10. 「实习生能否使用带教医生账号接诊」这类缺陷能被发现主要因为 。A. 拼写检查工具 B. 业务方与合规方代表进入评审会 C. 自动化扫描 D. 文档对比工具11. 形式化验证在云诊通的应用范围是 。A. 全部 80 余条需求 B. 仅处方状态机等安全攸关的核心规则 C. 仅界面文案 D. 未使用也不考虑12. 需求评审中「追查」阶段的工作是 。A. 预读文档 B. 确认缺陷已修复关闭并形成评审结论 C. 召开总体会议 D. 编写测试脚本13. 简答为什么需求阶段的 VV 投入被认为是「回报最高的质量投资」参考答案1.B 2.B 3.A 4.B 5.A 6.B 7.B 8.B 9.A 10.B 11.B 12.B 13. 依据第 26 篇的 1:10:100 错误放大规律需求缺陷若流入设计、编码与运行阶段修复要走完整返工链并可能被下游多处继承放大需求阶段的评审、测试化、原型确认等手段在错误源头拦截修复成本仅为编码期的约十分之一、运行期的百分之一且需求 VV 成本本身远低于后期返工因此是回报最高的质量投资。本篇小结知识点核心内容VV 分野验证正确地写对照规范与上游确认写正确的对照用户意图评审流程规划→总体会议→准备→评审会议→返工→追查评文档不评人评审角色主持/作者/评审人/记录员业务方与合规方必须到场需求测试Given-When-Then 导出验收用例写不出用例需求缺陷信号ATDD 雏形原型/形式化原型确认体验型需求形式化只投安全攸关规则衔接第 19 篇基线门槛验证通过 → 签字 → 需求基线第 31 篇变更控制入口云诊通三类缺陷边界缺失最多 量化口径歧义 角色权限与合规漏洞下篇预告第 31 篇需求管理——基线、变更控制与双向跟踪基线建立后需求工程并未结束版本冻结的意义、变更控制五步流程与 CCB 决策、需求跟踪矩阵 RTM 的双向跟踪以及云诊通「监管新规引发处方需求变更」的全过程实录。如果本篇内容对你有帮助欢迎点赞收藏有任何疑问欢迎在评论区交流。