考点清单

• [x] 软件需求分类（业务需求/用户需求/系统需求/功能需求/非功能需求/设计约束）
• [x] 需求获取方法（用户访谈/问卷调查/采样/JAD/情节串联板）
• [x] 需求分析（结构化分析/DFD/数据字典/判定表/判定树/三大模型）
• [x] 基于 UML 的需求分析（用例图/包图/类图）
• [x] 需求定义（严格定义 vs 原型方法/SRS）
• [x] 需求验证（需求评审/需求测试/需求基线）
• [x] 需求管理（CCB/需求变更控制）

笔记

一、软件需求分类 ★

软件需求是描述用户对软件系统期望的一系列条件或能力。层次：业务需求 > 用户需求 > 功能需求。

类别	说明	提出方
业务需求	企业/客户对系统高层次目标要求，确定项目视图和范围	投资人、客户、市场部门
用户需求	用户的具体目标，描述用户使用系统的场景	用户访谈、问卷调查
系统需求	从系统角度详细说明，含功能需求、非功能需求、设计约束	需求分析人员

系统需求细分：

类型	说明
功能需求（行为需求）	规定开发人员必须实现的软件功能
非功能需求	系统必须具备的属性或品质（可维护性、可靠性、效率等）
设计约束（限制条件）	对系统的约束说明（特定技术、框架、数据库、操作系统等）

---

二、需求获取 ★

需求获取是确定和理解项目干系人需求和约束的过程。

方法	特点	关键记忆点
用户访谈	1对1~3交流，结构化或非结构化	信息量大、记录困难、需要足够的领域知识，灵活性高
问卷调查	用户数量众多时使用	覆盖大量用户
采样	选取有代表性样本集	基于数理统计，减少数据收集偏差
情节串联板	图片/场景讲故事	直观表达需求
联合需求计划（JAD）	高度组织的群体会议	关键用户+分析师+开发团队一起讨论

口诀：访谈最灵活要懂行，采样统计少偏差，JAD 开会一起上。

---

三、需求分析 ★

需求分析目的是将用户需求转化为清晰、准确、无歧义的需求，作为设计和实现的基础。

需求分析任务： 绘制系统上下文范围关系图 → 创建用户界面原型 → 分析需求可行性 → 确定需求优先级 → 为需求建立模型 → 创建数据字典 → QFD（质量功能部署）

结构化分析方法

结构化特点：自顶向下、逐步分解、面向数据。

三大模型：

模型	工具	用途
功能模型	数据流图（DFD）	表示系统输入、输出和处理过程
行为模型	状态转换图（STD）	表示系统状态和引起状态转换的事件
数据模型	E-R 图（实体-关系图）	表示数据元素及其关系

DFD 基本图形元素： 数据流、加工、数据存储、外部实体。

DFD 常见错误：

• 黑洞：有输入无输出的加工
• 奇迹：有输出无输入的加工
• 灰洞：输入不足以产生输出的加工

数据字典（DD）： 为 DFD 中元素提供详细定义，含数据流、数据项、数据存储、基本加工。

需求分析方法： 结构化语言、判定表、判定树。

基于 UML 的需求分析

1. 利用用例及用例图表示需求 → 获取执行者和场景 → 形成用例 → 生成用例图
2. 利用包图和类图表示总体框架结构 → 提取"关键概念"形成领域概念模型 → 生成类图

4+1 视图模型

视图	关注点	UML 对应
逻辑视图	系统功能需求，最终用户	类图、对象图、状态图
开发视图（实现视图）	软件模块组织管理，程序员	包图、组件图
进程视图	运行特性、并发/分布/容错，系统集成人员	活动图
物理视图（部署视图）	软件→硬件映射、拓扑结构，系统工程师	部署图
场景（用例视图）	使4个视图有机联系	用例图

---

四、需求定义

产物：软件需求规格说明书（SRS），是项目干系人共识文档，设计/实现/测试的依据。

两种定义方法：

方法	假设	特点
严格定义（预先定义）	所有需求都能预先定义	图形或文字完整描述最终系统
原型方法	并非所有需求都能预先准确说明	迭代循环开发，逐步纳入需求，直到需求确定后遵循严格方法

---

五、需求验证

目的：确保需求准确无误，与用户实际期望一致。

步骤：

1. 需求评审：正式评审（会议）或非正式评审（日常交流）
2. 需求测试：设计测试用例验证需求可实现的正确性

关键概念：

• 需求验证通过 → 用户签字确认 → SRS 成为需求基线
• 需求基线是稳定参考点，之后任何更改需通过正式的需求变更流程

---

六、需求管理

CCB（变更控制委员会）：对项目中任何基线工作产品的变更都可以做出决定。

需求变更管理流程：问题分析和变更描述 → 变更分析和成本计算 → 变更实现。

需求的稳定性属于需求属性之一。CMM 可重复级有 6 个关键过程区域（非 3 个）。