软件需求工程

软件需求工程是软件开发生命周期的起始阶段，核心任务是理解并定义用户对新软件系统的期望和约束。

一、需求工程概述

1.1 定义与重要性

软件需求：从用户角度（系统外部行为）和开发者角度（内部特性）阐述系统必须具备的功能、特性、属性以及约束条件。

重要性：

用户与开发者之间沟通的桥梁
后续设计、编码、测试和验收的根本依据
需求分析质量直接关系到项目成败

1.2 需求工程的三个维度（Phol）

维度	关注点
内容维度	对系统需求的理解程度
共识维度	涉众对已知需求理解的一致性
文档化维度	将需求信息有效记录的程度

二、需求分类

2.1 按层次分类

类型	定义	关注点
业务需求	组织开发软件的根本原因和预期商业价值	战略目标
用户需求	用户使用系统能完成的具体任务和目标	用户视角
系统需求	对用户需求的细化，详细描述软件服务和约束	技术实现
技术需求	实现系统所需的技术规范、标准、平台	技术约束

2.2 功能需求 vs 非功能需求

类型	定义	示例
功能需求	系统应该做什么	"系统应允许用户注册账户"
非功能需求	系统应该如何工作	性能、可靠性、安全性、易用性

常见非功能需求

类型	描述	示例
性能	响应时间、吞吐量	页面加载时间<3秒
可靠性	平均无故障时间	MTBF > 1000小时
安全性	数据加密、访问控制	密码必须加密存储
易用性	界面友好、操作便捷	新用户10分钟内上手

三、需求过程

3.1 需求获取 (Elicitation)

目标：识别需求来源，抽取现有需求，开发创新性需求

常见困难：

用户不清楚自己真正需要什么
用户难以准确表达需求
需求随时间变化
用户和开发者使用不同术语
开发者倾向于修改需求以适应现有系统

关键信息持有者（Stakeholders）：

直接客户和最终用户
组织管理层
与系统有交互的其他部门或系统
维护人员

3.2 需求分析 (Analysis)

目标：确保需求的合理性、一致性、完整性和可行性

主要任务：

识别并解决需求之间的冲突和矛盾
确定需求的优先级
分析需求的可行性

3.3 需求规格说明 (Specification)

目标：将需求清晰、准确、无歧义地记录下来

产出物：软件需求规格说明书（SRS）

SRS的重要性：

开发团队进行设计、编码和测试的主要依据
用户确认系统功能的重要凭证

3.4 需求验证 (Validation)

目标：确保SRS准确反映用户真实意图和期望

常用方法：

评审
原型演示
模拟

3.5 需求管理 (Management)

目标：跟踪和控制需求变更

主要活动：

建立变更控制机制
评估变更影响
确保相关方对变更达成一致

四、需求分析方法

4.1 原型法 (Prototyping)

定义：通过快速构建可工作的系统模型，帮助理解和澄清需求

优点：

促进用户与开发者沟通
用户早期看到系统雏形
尽早发现问题

缺点：

用户可能对原型产生不切实际期望
临时技术方案可能影响最终质量
可能忽略非功能需求

4.2 用例技术 (Use Case)

定义：从用户角度描述系统功能的方法

核心元素

元素	说明	图示
参与者 (Actor)	与系统交互的外部实体	小人图标
用例 (Use Case)	系统提供的功能	椭圆
关系	元素之间的联系	线条

用例之间的关系

关系	含义	符号
关联	参与者与用例的联系	实线
包含 (include)	基用例必须执行的子用例	虚线箭头 + `<<include>>`
扩展 (extend)	可选执行的扩展用例	虚线箭头 + `<<extend>>`
泛化	继承关系	空心三角箭头

考试要点：include是必须执行的，extend是可选执行的

五、数据流图 (DFD)

5.1 基本概念

数据流图是结构化分析方法的核心工具，用于对信息系统的数据流和处理过程进行建模。

特点：

描述数据从外部输入，经处理转换，输出或存储的过程
关注数据的逻辑流动，而非程序控制流程

5.2 DFD基本符号

符号	名称	含义	图形
矩形框	外部实体	系统边界外的数据源或终点	□
圆角矩形/圆形	处理/加工	对数据的转换或操作	○
两条平行线	数据存储	数据的静态存储位置	═
带箭头直线	数据流	数据流动方向	→

5.3 绘制原则

清晰易懂：使用标准符号和简洁命名
逻辑性：侧重于数据逻辑流动，非物理实现
完整性：包含所有必要元素
一致性：整个DFD体系中保持一致
逐步细化：自顶向下分层

5.4 分层DFD

层次	名称	说明
顶层图	上下文图	单一处理代表整个系统，显示与外部实体的数据交互
0层图	系统概览图	将顶层处理分解为主要子处理
n层图	子图	对上层处理进一步分解

5.5 父子图平衡原则（重要！）

核心规则：

子图输入数据流总和 = 父图对应处理的输入数据流
子图输出数据流总和 = 父图对应处理的输出数据流

父图处理P的输入：A, B
父图处理P的输出：C

对应子图：
- 输入数据流总和必须等于 A + B
- 输出数据流总和必须等于 C

5.6 逻辑DFD vs 物理DFD

比较维度	逻辑DFD	物理DFD
描述对象	业务流程（做什么）	具体实现（怎么做）
关注点	数据逻辑流动	物理实现方式
抽象级别	较高	较低
包含元素	业务活动、逻辑数据单元	程序模块、物理文件、数据库表
使用时机	需求分析早期	概要/详细设计阶段
稳定性	相对稳定	相对易变

5.7 DFD绘制示例

场景：图书馆借书系统

顶层图（上下文图）：

  借阅请求                    借阅结果
读者 ───────────→ [图书借阅系统] ───────────→ 读者
                      ↑
                  图书信息
                      |
                   图书馆

0层图：

                    借阅请求
读者 ───────────→ [1.0 验证读者] ───读者信息───→ D1读者文件
        |                   ↓
        |              有效读者信息
        |                   ↓
        └───图书信息───→ [2.0 检查图书] ←──图书状态──→ D2图书文件
                              ↓
                         可借图书信息
                              ↓
                      [3.0 办理借阅] ───借阅记录───→ D3借阅文件
                              ↓
                          借阅结果
                              ↓
                            读者

六、考试要点

下午题DFD常见考法

补全数据流：根据描述补充缺失的数据流
补全外部实体：识别系统边界外的实体
补全数据存储：识别数据存储位置
检查平衡性：验证父子图是否平衡
纠正错误：发现并修正DFD中的错误

答题技巧

仔细阅读题目描述，识别名词（可能是实体或数据存储）
识别动词（可能是处理/加工）
检查每个处理是否有输入和输出
验证父子图平衡
检查数据流命名是否合理

典型错误

❌ 数据流没有经过处理直接进入数据存储
❌ 处理只有输入没有输出
❌ 处理只有输出没有输入
❌ 数据流命名不清晰
❌ 父子图不平衡

软件需求工程 ​

一、需求工程概述 ​

1.1 定义与重要性 ​

1.2 需求工程的三个维度（Phol） ​

二、需求分类 ​

2.1 按层次分类 ​

2.2 功能需求 vs 非功能需求 ​

常见非功能需求 ​

三、需求过程 ​

3.1 需求获取 (Elicitation) ​

3.2 需求分析 (Analysis) ​

3.3 需求规格说明 (Specification) ​

3.4 需求验证 (Validation) ​

3.5 需求管理 (Management) ​

四、需求分析方法 ​

4.1 原型法 (Prototyping) ​

4.2 用例技术 (Use Case) ​

核心元素 ​

用例之间的关系 ​

五、数据流图 (DFD) ​

5.1 基本概念 ​

5.2 DFD基本符号 ​

5.3 绘制原则 ​

5.4 分层DFD ​

5.5 父子图平衡原则（重要！） ​

5.6 逻辑DFD vs 物理DFD ​

5.7 DFD绘制示例 ​

六、考试要点 ​

下午题DFD常见考法 ​

答题技巧 ​

典型错误 ​