需求工程
为什么做需求、需求分类、需求工程五大活动、需求获取方法、需求规格说明书（SRS）的结构与编写。
🎯学习目标
- 理解需求工程的目标与重要性
- 掌握需求的分类（用户/系统需求、功能/非功能需求）
- 掌握需求工程过程（获取/分析/规格说明/验证/管理）
- 掌握需求规格说明书（SRS）的结构与编写
1为什么要进行需求工程
美国 Standish Group 的 CHAOS Report 对大量 IT 项目统计发现：失败/超支项目中，与"需求"相关的原因（需求不完整、用户参与不足、需求频繁变更等）占很大比例。
⚠️ 结论需求问题是项目失败的首要根源。做好需求工程，是项目成功的前提。
💡 通俗理解：什么是需求工程？
需求就是"用户到底想要什么"。听起来简单，实际上最容易出错。
想象你去餐厅点菜：你说"来份红烧肉"，厨师做了甜的，你想要咸的——这就是需求不明确。你说"随便"，结果端上来你不爱吃——这就是需求没获取。你吃了一半说"再加个汤"——这就是需求变更。
需求工程就是系统地收集、分析、记录、验证、管理这些需求的过程。它包含5个活动：获取（问用户想要什么）→ 分析（整理归类）→ 规格说明（写成文档）→ 验证（确认没理解错）→ 管理（需求变了怎么办）。
2需求工程的目标与重要性
需求工程（Requirements Engineering）：对需求进行获取、分析、规格说明、验证和管理的系统化过程（1997 年定义）。最终产物是需求规格说明书（SRS）。
需求错误的代价随阶段增长（重要）
图1 · 需求错误发现得越晚，修复代价越高（呈指数增长）
3需求分类 ⭐（重点）
1. 用户需求 vs 系统需求（需求层次）
概貌需求最高层，业务目标/愿景
用户需求用自然语言+图表描述系统提供的服务与约束（面向用户）
系统需求详细描述系统功能、服务、约束（面向开发者）
2. 功能需求 vs 非功能需求 ⭐
⚙️
功能需求
Functional系统应当提供的功能、服务、行为——回答"系统能做什么"。如：登录、查询、下单
🛡️
非功能需求
Non-functional对系统的约束和质量属性——性能、可靠性、可用性、安全性、可维护性、可移植性等。"做得多好"
⭐ 非功能需求三大类产品需求（性能/可靠性/可用性等对产品的要求）、组织需求（来自客户或开发组织的政策/规程/标准）、外部需求（法律法规/道德/与外部系统互操作等）。
非功能需求度量举例：性能（每秒处理事务数/响应时间）、空间（内存/存储占用）、可靠性（MTTF 平均无故障时间）、健壮性、可移植性。
4需求工程过程 ⭐（五大活动）
图2 · 需求工程五大活动（迭代/螺旋进行，需求管理贯穿全程）
| 活动 | 主要任务 |
|---|---|
| 需求获取 | 从涉众、已有系统、文档中收集需求 |
| 需求分析与协商 | 分类、抽象、建模，解决需求冲突 |
| 需求规格说明 | 形成需求规格说明书 SRS |
| 需求验证 | 检查需求的有效性、一致性、完整性等 |
| 需求管理 | 管理需求变更、追踪需求（贯穿全程） |
5需求获取（需求捕获）
需求来源
涉众（stakeholders，与系统利益相关者）、已有系统、相关文档、领域知识。
需求获取的方法与技术
🗣️
访谈/面谈
与涉众直接交流（结构化/非结构化）
📋
问卷调查
面向大量用户收集
👀
现场观察
观察用户实际工作
🧩
原型法
用原型澄清需求
🎬
场景/用例
用使用场景描述
案例心理健康助人者系统：通过访谈助人者与来访者、观察咨询流程、问卷收集，获取功能与非功能需求。
6需求规格说明与验证
需求规格说明
- 重要性：作为开发、测试、验收的共同依据。
- 编写方法：自然语言描述、结构化语言描述、可视化（图形/模型）描述。
- 常用模板：IEEE 830 软件需求规格说明书模板。
需求有效性验证（V&V）
验证技术：需求评审、原型、测试用例。
⭐ 需求验证检查 5 点有效性（满足用户真实需要）、一致性（需求间不矛盾）、完整性（无遗漏）、现实性（技术/成本可行）、可验证性（可被测试检验）。
7需求规格说明书 SRS 文档结构 ⭐
一份典型的 SRS 文档结构（含封面：系统名、版本号、作者、日期）：
| 章节 | 内容 |
|---|---|
| 1. 概述 | 编写目的、范围、定义、参考资料 |
| 2. 总体描述 | 系统范围、系统上下文模型（Context Model）：系统与外部实体的交互 |
| 3. 功能需求 | 3.1 业务需求 / 用例图；3.2 功能需求分析（用例描述表）；3.3 数据需求分析（数据流图、数据字典、ER 图） |
| 4. 非功能需求 | 4.1 性能需求、4.2 资源需求、4.3 安全需求等 |
| 5. 接口需求 | 系统的界面/接口上下文环境 |
| 参考资料 | 引用的标准、文档 |
💡 上下文模型Context Model（系统上下文模型）画出系统作为一个整体，与外部实体（用户、外部系统）之间的数据交互，界定系统边界。
⭐重点例题
例1：区分功能需求与非功能需求"用户能在线下单"=功能需求（做什么）；"系统响应时间<2秒""支持10万并发""数据加密传输"=非功能需求（性能/安全等质量约束）。
例2：需求工程包含哪些活动？需求获取→分析与协商→规格说明→验证→管理（管理贯穿全程，过程是迭代的）。
例3：常用的需求获取方法有哪些？访谈/面谈、问卷调查、现场观察、原型法、场景/用例、头脑风暴。来源：涉众、已有系统、文档、领域知识。
例4：一份 SRS 应包含哪些主要内容？概述、总体描述（含系统上下文模型）、功能需求（用例图+用例描述+数据需求）、非功能需求（性能/资源/安全）、接口需求、参考资料。
例5：需求验证要检查哪些方面？有效性、一致性、完整性、现实性（可行性）、可验证性——可用评审、原型、测试用例来验证。
🎯自测（点击展开）
需求工程包含哪五个活动？
需求获取、需求分析与协商、需求规格说明、需求验证、需求管理。
功能需求与非功能需求的区别？
功能需求=系统做什么（功能/服务）；非功能需求=对系统的约束和质量属性（性能/可靠性/安全性等）。
非功能需求分为哪三大类？
产品需求、组织需求、外部需求。
常用需求获取方法有哪些？
访谈/面谈、问卷调查、现场观察、原型法、场景/用例。
需求验证要检查哪几个方面？
有效性、一致性、完整性、现实性、可验证性。
SRS 中"系统上下文模型"的作用？
描述系统与外部实体的交互，界定系统边界。
📝强化题库
选择题点选即时判分；填空题输入后"检查"或"显示答案"。
已答 0/0答对 0正确率 —
已答 0/0答对 0