【软件工程】需求工程：需求规格说明与需求验证
考点频率：★★★★☆（选择题常考SRS特征，验证与确认的辨析是高频易错点）
难度：⭐⭐
建议：重点掌握SRS的六大质量特征、需求验证的常用方法，以及“验证”与“确认”的本质区别
1️⃣ 需求规格说明：把“蓝图”写成“合同”
承接上篇文章，需求分析阶段产出了数据流图、用例图等模型，但这些模型还不能直接交给开发人员编码——因为图是分散的，需要一份完整的、结构化的、无二义性的文档来统一所有人的认知。
软件需求规格说明书（SRS，Software Requirements Specification）就是这份文档。它是需求工程的核心产出物，是开发团队和用户之间的一份“技术合同”——开发团队承诺按SRS实现功能，用户承诺验收标准以SRS为准。
SRS包含哪些内容？
一份典型的SRS通常包含以下部分：
| 章节 | 主要内容 |
|---|---|
| 引言 | 项目背景、术语定义、适用范围 |
| 总体描述 | 系统主要功能、用户角色、硬件/软件环境、设计约束（如必须使用特定数据库、遵守特定法规） |
| 外部接口需求 | 用户界面、硬件接口、软件接口、通信接口 |
| 功能需求 | 系统“必须做什么”——每个功能模块的详细描述 |
| 非功能需求 | 性能（响应时间、吞吐量）、安全性、可靠性、可维护性等质量属性 |
| 数据需求 | 数据字典、数据格式、数据库要求 |
| 附录 | 业务流程图、补充说明等 |
SRS的六大质量特征（软考高频考点）
一份合格的SRS必须满足以下特征，这也是选择题中常考的考点：
| 特征 | 含义 | 反例 |
|---|---|---|
| 正确性 | 每条需求都真实反映了用户的意图 | 用户说要“导出Excel”，你写成了“导出PDF” |
| 完整性 | 包含所有需求，没有遗漏 | 漏掉了“密码输错3次锁定账号”的规则 |
| 一致性 | 需求之间不矛盾 | 前面说“支持1000并发”，后面说“内存限制只支持100并发” |
| 明确性 | 每条需求无二义性，只有一种解释 | “系统响应要快” ❌ → “系统响应时间≤2秒” ✅ |
| 可验证性 | 每条需求都可以通过测试或评审来验证 | “用户体验好” ❌ → “用户可在3步内完成下单” ✅ |
| 可追踪性 | 每条需求都有唯一编号，可从设计追溯到测试 | 需求编号 REQ-101，对应设计文档 SD-101，对应测试用例 TC-101 |
软考常考：题目给出一句需求描述，让你判断它违反了SRS的哪个特征。比如“系统应具有良好的用户界面” → 违反明确性（什么叫“良好”？没法量化）。
2️⃣ 需求验证：怎么确认“蓝图画对了”？
需求规格说明书写完后，不能直接就扔给开发团队开干——因为里面可能有错误、遗漏、矛盾。需求验证就是检查SRS“是否正确”的过程。
需求验证的常用方法
| 方法 | 说明 | 适用场景 |
|---|---|---|
| 正式评审 | 组织各方代表（用户、需求分析师、架构师、测试代表）召开会议，逐条评审SRS | 大型项目、安全关键系统 |
| 同行评审 | 由同级别需求分析师互相检查，找出逻辑漏洞和遗漏点 | 常规项目 |
| 走查 | 需求撰写人向相关人员逐条解释需求，发现不一致和含糊之处 | 需求复杂、难理解的场景 |
| 原型验证 | 构建快速原型（低保真/高保真）让用户试用，验证需求是否符合用户真实预期 | 需求不明确、用户难以具象化的场景 |
| 测试用例预编写 | 在编码前先编写验收测试用例，如果某个需求写不出测试用例，说明该需求不可验证（违反了“可验证性”特征） | 检验SRS的可测试性 |
3️⃣ 需求验证 vs 需求确认（极容易混淆！）
在软考中，验证（Verification）和确认（Validation）是两张极易混淆的“面孔”。很多同学看到“确认”就以为是“验证”，结果丢分。
记住这个经典定义：
| 概念 | 英文 | 核心问题 | 关注点 | 检查对象 |
|---|---|---|---|---|
| 验证（Verification） | “Are we building the product right?” | 我们正确地构建了产品吗？ | 过程是否正确、文档是否规范 | 需求文档、设计文档、代码是否符合规范 |
| 确认（Validation） | “Are we building the right product?” | 我们构建了正确的产品吗？ | 最终产品是否满足用户真实需求 | 原型、可运行系统是否符合用户预期 |
打个比方：
- 验证（Verification）：检查你手里的设计图纸——每根线有没有画歪？尺寸有没有标错？这就像老师检查你的作业有没有语法错误。
- 确认（Validation）：把你盖好的房子给客户看——客户说“我要的是三室一厅，你给我整了个两室一厅？”这就像用户试用产品后反馈是否满意。
放在需求工程中：
- 需求验证：检查SRS文档本身——需求写全了吗？前后矛盾吗？有没有歧义？（检查“图纸”）
- 需求确认：把原型或最终产品拿给用户看——用户满意吗？这是你想要的吗？（检查“成品”）
考试口诀：验证看文档（过程），确认看用户（结果）。验证明“对不对”，确认问“好不好”。
4️⃣ 经典例题
例题1：在需求工程中，需求规格说明书（SRS）的“明确性”特征是指（ ）。
A. 每条需求都有唯一的编号
B. 每条需求都真实反映了用户的意图
C. 每条需求只有一种解释，不存在二义性
D. 每条需求都可以通过测试来验证
解析：A是可追踪性，B是正确性，D是可验证性，C是明确性。选C。
例题2：某项目团队在SRS中写道：“系统应具备良好的扩展性。”以下说法正确的是（ ）。
A. 该需求符合“明确性”特征
B. 该需求不符合“明确性”特征
C. 该需求符合“可验证性”特征
D. 该需求符合“一致性”特征
解析：“良好的扩展性”是一个模糊的描述——什么叫“良好”？是支持增加新模块？还是支持数据库迁移？没有量化标准，违反了“明确性”特征。选B。
例题3（判断）：需求验证和需求确认本质上是同一回事，都是检查需求是否正确。（ ）
解析：错误。需求验证检查SRS文档本身是否正确、规范（验证）；需求确认检查最终产品是否满足用户真实需求（确认）。两者对象不同、目的不同。
5️⃣ 记忆口诀
SRS六大特征：正完一明可追（正=正确，完=完整，一=一致，明=明确，可=可验证，追=可追踪）。
验证与确认：验文档、认用户；验过程、认结果。
需求验证四方法：评同走原测（正式评审、同行评审、走查、原型验证、测试用例预编写）。
6️⃣ 小测验（评论区对答案）
某项目团队在需求规格说明书（SRS）中描述需求为：“用户登录后，系统应显示最近的通知。”在需求评审时，测试工程师指出该需求无法编写明确的测试用例，因为“最近”没有定义。这违反了SRS的哪个特征？该阶段属于验证还是确认？
A. 完整性；验证
B. 明确性；验证
C. 完整性；确认
D. 明确性；确认
🔔本专栏日更，点击头像 → 专栏《软考中级高频考点》订阅，第一时间接收新内容
#软考中级 #软件设计师 #需求规格说明 #需求验证 #软件工程 #软考备考
