需求工程

🎯学习目标

• 理解需求的概念与层次（业务/用户/系统）；
• 掌握功能需求与非功能需求的区分；
• 掌握需求工程过程的五个活动；
• 熟悉常用需求获取技术与 SRS 文档结构；
• 理解需求验证确认与需求变更管理。

1什么是需求

需求（Requirement）是用户解决问题或达到目标所需的条件或能力，是系统为满足合同、标准、规约或其他正式文档所规定需求而必须具备的条件或能力。简单说：需求描述系统应该做什么（What），而非怎么做（How）。

需求是后续设计、编码、测试与验收的基准。研究表明：需求阶段引入的缺陷若到后期才发现，修复成本会成倍甚至成百倍增长。

2需求的层次 ⭐（核心考点）

需求按抽象程度自顶向下可分为三个层次，常用需求金字塔表示：

3功能需求 vs 非功能需求 ⭐（核心考点）

非功能需求的常见类别

4需求工程过程

需求工程（Requirements Engineering, RE）是理解和定义系统需要提供哪些服务、找出开发和运行约束的过程，目标是生产一份达成一致的需求文档。一般包含五个活动，且常常迭代进行：

5需求获取技术

需求获取是与利益相关者（Stakeholders）交互、收集需求的过程。常用技术：

其他技术还包括：头脑风暴、工作坊（联合应用开发 JAD）、文档/现有系统分析、用例与场景分析等。

6需求规格说明书 SRS

软件需求规格说明书（SRS, Software Requirements Specification）是需求工程的核心交付物，是开发、测试、验收和合同的依据。

优秀 SRS 的质量特性

SRS 典型内容（IEEE 830 参考）

• 引言：目的、范围、定义、参考资料；
• 总体描述：产品前景、产品功能、用户特征、约束与假设；
• 具体需求：功能需求、非功能需求、外部接口需求；
• 附录：数据字典、索引等。

7需求验证与确认

需求验证（Validation）检查需求文档是否定义了客户真正想要的系统，主要检查：

常用验证技术

• 需求评审（Review）：组织专家和利益相关者系统检查需求文档；
• 原型法：用可执行原型让用户确认需求；
• 编写测试用例：为每条需求设计验收测试，无法设计测试说明需求不可验证；
• 需求追踪：建立追踪矩阵确保需求被设计和测试覆盖。

8需求变更管理

系统需求总是在变化的（外部压力、管理更替、新技术）。需求变更管理用受控流程处理变更，避免需求蔓延（Scope Creep）。

• 变更控制委员会（CCB）负责评审是否批准变更；
• 对每个变更进行影响分析（成本、进度、关联需求）；
• 采用需求基线（Baseline）+ 版本控制，所有变更可追踪；
• 增量/螺旋等过程模型本身就便于以较低成本容纳变更。

9需求建模概览

需求建模用图形化模型刻画系统，比纯自然语言更精确、易沟通。常见模型：

⭐重点例题

(1) 学生可在线提交答卷           → 功能需求（系统行为）
(2) 系统须在 3 秒内返回成绩       → 非功能需求（性能）
(3) 教师可创建试卷                → 功能需求
(4) 系统须支持 5000 人同时考试    → 非功能需求（性能/容量）
(5) 答卷数据须加密存储            → 非功能需求（安全）

① 访谈 —— 深入了解图书管理员、读者的核心业务（借还、检索）
② 观察 —— 现场观察借还书流程，发现隐性需求（如逾期处理习惯）
③ 问卷 —— 面向大量读者收集对检索、预约功能的偏好
④ 原型 —— 做出检索界面原型让用户试用，验证并修正需求
⑤ 文档分析 —— 分析现有手工/旧系统的登记表与规章制度

🎯自测（点击展开）

📝强化题库

选择题点选即时判分；填空题输入后"检查"或"显示答案"。