（案例）（第十一章）软考系统分析师「软件需求工程」核心知识梳理

软考系统分析师·软件需求工程核心梳理

软件需求工程是系统分析师考试的核心重点 ，年均分值15-22分，覆盖上午选择题（5-8分）、下午案例分析（10-14分）及论文写作，论文高频主题为"论需求规格说明的质量控制"。以下按考试大纲框架 梳理核心考点、易混点与应试技巧，帮你搭建结构化知识体系。
需求获取、分析、定义、验证（需求评审包含在需求验证中） = 都在 系统分析阶段
需求管理 = 全生命周期都有

一、核心概念与需求分层（必考）

1. 需求工程定义

软件需求工程 是应用工程化方法，将零散用户需求转化为清晰、可验证、可管理的需求，连接用户与开发团队的"契约"，直接决定项目成败。

2. 需求分层（必背，选择题高频）

层级	核心定义	典型示例	考点提示
业务需求	组织/业务的高层次目标，"为什么做"	提升订单处理效率30%	与项目目标对齐，案例题常考"业务需求与系统需求的区别"
用户需求	具体用户/角色的任务期望，"用户要做什么"	管理员可查询订单明细	需转化为系统功能，易与功能需求混淆
系统需求	系统必须实现的功能/约束，"系统要做什么"	支持按时间范围检索订单	分功能需求 （做什么）与非功能需求（约束）
设计约束	限制系统实现的规则，"必须遵守的条件"	必须采用Oracle数据库、符合等保2.0	非功能需求的特殊类型，案例题常考识别

用户需求（用户说）：

"我想查我的订单"

"我要能登录"

"系统别太卡"
功能需求（系统要实现）：

用户登录验证功能

订单查询功能

订单列表分页显示

密码加密存储
用户需求 → 经过需求分析 → 转化为 → 功能需求

用户需求是原材料

功能需求是成品

3. 非功能需求分类（案例题核心）

• 性能需求：响应时间、吞吐量、并发数（如"1秒内响应90%查询"）；
• 可靠性需求：可用性、MTBF（平均无故障时间）、容错能力（如"可用性≥99.99%"）；
• 安全性需求：权限控制、数据加密、合规要求（如"密码含大小写+特殊字符"）；
• 可维护性/可扩展性需求：模块化、接口规范、配置化能力；
• 兼容性需求：跨浏览器、跨操作系统、数据兼容。

4. 好需求的特性（案例题缺陷识别）

无二义、完整、一致、可测试、可验证、优先级明确。

• 常见缺陷：模糊表述（"系统应高效"）、无验收标准、冲突需求、遗漏边界条件。

二、需求开发全流程（核心模块）

1. 需求获取（选择题高频，案例题考方法选择）

6种核心方法，需精准匹配场景，避免混淆：

方法	核心特点	适用场景	考点/易错点
用户访谈	1对1/小组，结构化/非结构化，深度挖掘	关键干系人、战略需求、敏感问题	灵活性强，适合"为什么"的动机挖掘；注意记录与验证
问卷调查	大范围、定量统计，标准化问卷	大量用户共性偏好、使用频率	适合"是什么"的事实统计；信效度高于访谈，量化需求首选
联合需求计划（JRP）	高度组织的群体会议（1-3天封闭式），多方联合决策	跨部门项目、快速定范围/流程	效率高、共识强；对主持人控场能力要求高，案例题常考特征
情节串联板	图片/原型展示交互流程，直观易懂	界面交互、用户操作路径复杂	适合模糊需求澄清；耗时长，需平衡成本
采样	基于数理统计的样本选择（公式：样本数=0.25×(可信度因子/错误率)²）	大规模用户行为分析、偏差控制	本质是数据选择技术，非独立获取方式，易与问卷调查混淆
需求记录技术	任务卡片、用户故事、Volere白卡	敏捷项目、需求文档化	用户故事格式："作为<角色>，我想<动作>，以便<价值>"

2. 需求分析（重点，案例题+论文核心）

3大分析方法，考试常考对比与应用场景：

方法	核心思想	核心工具/产出	考点/适用场景
结构化分析（SA）	自顶向下、功能分解，聚焦"怎么做（How）"	数据流图（DFD）、数据字典（DD）、数据模型（ER图）状态转换图（STD）	传统瀑布项目，适合流程清晰、需求稳定的系统；案例题考DFD元素识别与错误修正
面向对象分析（OOA）	聚焦"谁来做（Who/What）"，对象封装交互	UML模型（用例图、类图、序列图等）、实体关系图（ERD）	复杂系统、迭代开发，考试占比最高，案例题考UML图应用
面向问题域分析（PDOA）	回归问题域，重描述少建模，适合需求模糊场景	问题域文档、解系统需求文档	新教材新增考点，需掌握"问题域→解系统"的分析逻辑

维度	SA（结构化分析）	OOA（面向对象分析）	PDOA（面向问题域）
核心	数据流、加工、分解	对象、类、封装、交互	问题域、描述、问题列表
建模	强建模（DFD、DD、ER）	强建模（UML全套）	弱建模、重文档描述
思路	自顶向下、功能分解	抽象对象、行为封装	先定义问题，再设计系统
工具	DFD、数据字典、ER图	UML（用例、类、时序...）	问题描述文档、需求列表
假设	问题可完全定义、可分解	持续观察、对象化	先承认问题复杂，先描述清楚

• 能不能一起用？

  → 可以，而且很合理：

  1. 先用 PDOA 把问题、业务、需求描述清楚
  2. 再用 SA 或 OOA 去建模、画图、设计

• PDOA 用 DFD 吗？用 UML 吗？

  → PDOA 本身不用 DFD、不用 UML。

  → 它是前期需求澄清方法 ，输出文字描述和需求清单 ，

  → 后面再交给 SA/OOA 去建模。

（1）结构化分析核心工具

• DFD数据流图：4大元素（外部实体、处理、数据流、数据存储）；3类错误（父图子图平衡、处理无输入/输出、数据流无来源/去向）；
• 数据字典（DD）：6类条目（数据流、数据项、数据存储、处理逻辑、外部实体、数据关系），是DFD的补充说明。

（2）OOA 里的用例模型 vs 分析模型：

对比维度	用例模型（Use Case Model）	分析模型（Analysis Model）
阶段位置	OOA 前期，从需求到分析的入口	OOA 核心/后期，从功能到设计的过渡
内涵	用例模型 = 用例图 + 详细的用例描述（文字描述）	分析模型 = 类图（定结构） + 顺序图 / 活动图（定流程）
步骤	识别参与者-->合并需求获得用例-->细化用例描述-->调整用例模型	定义概念类-->识别类之间的关系-->为类添加职责-->建立交互图
视角	外部视角（用户怎么看系统）	内部视角（系统由什么构成）
核心回答	系统要干什么？有哪些功能？	系统由哪些对象组成、如何交互？
主要内容	参与者、用例、用例关系、用例规约	领域类图、顺序图、活动图、状态图
描述重点	系统功能、业务价值、用户目标	对象、属性、关系、行为、流程
本质	功能模型	逻辑模型 / 结构+行为模型
依赖关系	独立于实现，只看需求	基于用例模型推导出来
作用	确定系统边界、功能范围	把功能转成对象，为 OOD 做准备

1.识别参与者

确定与系统交互的外部实体（人、外部系统、设备）。

2.合并需求获得用例

从参与者出发，梳理系统功能，合并得到用例。

3.细化用例描述

编写用例规约：用例名、前置条件、后置条件、事件流、优先级。

4.调整用例模型

优化用例关系（包含、扩展、泛化），完善用例图。
1.定义概念类

从业务需求中提取核心概念、实体，抽象出概念类。

2.识别类之间的关系

确定类的泛化、关联、聚合、组合等关系。

3.为类添加职责

为类分配属性和方法（职责）。

4.建立交互图

绘制顺序图 / 通信图，描述对象之间如何协作完成用例。

关系名称	图形符号	通俗理解（人话）	考试定义（得分点）	经典例子
泛化（继承）	空心三角	"是一个" 儿子继承爸爸的东西	一般元素与特殊元素的关系	学生 ➡️ 人 狗 ➡️ 动物
实现	空心三角+虚线	"照着做" 一个类答应完成另一个类的接口	类实现了接口的规范	登录类 ➡️ 登录接口 汽车类 ➡️ 驱动接口
依赖	虚线箭头	"用一下" 临时关系、喝水关系	一个类用到另一个类，却不长期持有	司机开车 （司机临时用了车） 查询报表（临时访问数据库）
关联	实线	"有个" 长期认识、朋友关系	类之间的结构化连接，长期关系	学生 ➡️ 课程 订单 ➡️ 商品
聚合	空心菱形	"部分属于整体" 可以分开的组合	整体与部分可分离，部分能独立存在	汽车 ➡️ 轮胎（轮胎能拆下来）
组合	实心菱形	"身体一部分" 不可分离，生死相依	整体与部分不可分割，部分随整体消亡	人 ➡️ 心脏 公司 ➡️ 部门

依赖（最弱） 关联 聚合 组合（最强） 泛化、实现是另外一类继承 / 规范关系，一般不和上面 4 个放一起比强弱，但依赖依然是全场最弱。

聚合、组合 都属于 关联关系的特殊子集

层级关系

1. 最顶层：关联 Association

• 普通关联
• 聚合 Aggregation（弱关联）
• 组合 Composition（强关联）

2. 独立三大类：

• 依赖
• 关联（含普通关联、聚合、组合）
• 泛化 / 实现

一句话区分层级

• 广义关联 = 普通关联 + 聚合 + 组合
• 聚合、组合 是整体-部分形式的关联，比普通关联语义更强

核心区别（帮你彻底分清）

1. 普通关联 ：只是两个类有关系，没有整体和部分
   例：学生 ↔ 老师
2. 聚合（弱关联） ：整体-部分，生命周期独立
   班级 ↔ 学生，班级解散，学生还在
3. 组合（强关联） ：整体-部分，生命周期绑定
   人 ↔ 心脏，人没了，心脏也失效

关系强弱链

依赖 < 普通关联 < 聚合 < 组合

用例模型：外面看，有啥功能。
分析模型：里面看，有啥对象。

（3）OOA核心------UML建模（重中之重）

UML 4+1视图（逻辑/进程/实现/部署/用例）+ 9种核心图，分类记忆：

• 静态图（结构图）：类图、对象图、组件图、部署图、包图（描述系统静态结构）；
• 动态图（行为图） ：用例图、序列图（也叫顺序图）、通信图、状态图、活动图（描述系统动态行为）。

(4) 结构化分析中的状态转化图STD和OOA中的状态图

• STD (State Transition Diagram) ：是通用概念，源于结构化分析，指任何描述状态与迁移的图。
• UML 状态图 ：是STD 在 UML 标准中的正式名称（也叫状态机图），它吸收了 STD 的思想并进行了标准化、规范化。

对比维度	STD (状态转换图)	UML 状态图	关系总结
本质	一种通用的建模思想/方法	UML 标准中的一种具体图表	思想 vs 实现
归属	结构化分析（SA）的行为模型	UML 行为图（Behavioral Diagram）	旧方法 vs 新规范
图形	方框（状态）+ 箭头（迁移）	圆角矩形（状态）+ 箭头（转换）	表现形式一致
考点	软考中级（如信息系统管理工程师）	软考高级（如系统分析师）、OO 设计	覆盖范围不同

终极结论 ：不用纠结，结构化分析中的状态转化图STD和OOA中的状态图是一体两面 。在备考中，你可以把它们完全等同看待，掌握状态、事件、迁移的画法和含义即可。

高频考点：

1. 用例图3大关系（选择题必考）：
   • 包含（include）：基础用例→被包含用例（箭头指向被包含，必执行，如"登录"包含"验证密码"）；
   • 扩展（extend）：扩展用例→基础用例（箭头指向基础，条件执行，如"退款"扩展"提交订单"）；
   • 泛化（generalization）：子用例→父用例（继承关系，如"电话注册"泛化"会员注册"）。
2. 序列图核心元素：生命线、控制焦点、消息（同步/异步/返回），案例题考场景建模；
3. 状态图：描述对象状态及转移条件（如"订单"的"待支付→已支付→已完成"）。

3. 需求定义（SRS编写，案例题核心）

**软件需求规格说明书（SRS）**是需求开发最终交付物，按IEEE 830标准结构编写：

（1）SRS核心作用（选择题）

开发基准、验收标准、沟通媒介、合同依据。

（2）IEEE 830标准结构（必背，案例题考文档评审）

1. 引言（目的、范围、术语、参考文献）；
2. 总体描述（产品前景、用户特征、运行环境、约束条件）；
3. 系统特性（功能需求，含需求ID、描述、输入/处理/输出、异常处理、验收标准）；
4. 外部接口需求（用户界面、硬件/软件/通信接口）；
5. 非功能需求（性能、可靠性、安全性等，需量化）；
6. 其他需求（合规、培训、文档标准）。

（3）需求定义方法

• 严格定义（预先定义）：假设需求可提前明确，适合需求稳定的瀑布项目；
• 原型方法：快速构建原型，用户参与验证，适合需求模糊的迭代项目。

4. 需求验证（选择题+案例题）

核心目的：确认需求无歧义、完整、一致、可验证 ，避免返工。
3类评审方式（案例题考改进建议）：

1. 评审：正式会议，多方参与，全面检查；
2. 检查：专人详细查错，聚焦细节缺陷；
3. 走查：开发者自查，团队辅助，快速修正。

关键动作 ：验证通过后基线化，用户签字确认，变更需走流程。

三、需求管理（高频，案例题+论文）

核心目标：控制变更、保障追溯，避免需求漂移。

1. 需求变更管理（必考）

• 变更流程：提交变更申请→CCB（变更控制委员会）评估→批准→更新需求→通知相关方→执行变更→验证；
• CCB核心职责：评估变更影响（范围、进度、成本、质量）、决策是否变更、监督执行；
• 变更原则：所有变更必须记录，无CCB批准不执行，案例题考"变更流程缺陷识别"。

2. 需求跟踪（核心考点）

双向跟踪 （正向+逆向），通过需求跟踪矩阵实现，论文高频考点：

跟踪类型	核心逻辑	作用	考点
正向跟踪	业务需求→用户需求→系统需求→设计→编码→测试	确保每个需求都有实现	案例题考"正向跟踪缺失的风险"
逆向跟踪	测试用例→缺陷→需求→设计→编码	确保每个实现都有验证	避免"需求遗漏导致测试缺失"

需求跟踪矩阵核心字段：需求ID、来源、功能描述、设计文档、测试用例、状态、优先级。

3. 需求风险管理

• 风险识别：需求模糊、干系人冲突、需求频繁变更、需求与业务目标不一致；
• 风险应对：采用原型法、建立变更流程、加强干系人沟通、需求基线化管理。

四、高频易混点对比（避坑指南）

1. 需求文档 vs SRS ：
   • 需求文档：面向业务人员，业务语言，目标级需求；
   • SRS：面向开发团队，技术语言，可实现的系统需求，需基线化。
2. 包含 vs 扩展 ：
   • 包含：必执行，箭头指向被包含用例；
   • 扩展：条件执行，箭头指向基础用例。
3. SA vs OOA ：
   • SA：功能分解+数据流，关注"How"，适合传统项目；
   • OOA：对象+交互，关注"Who/What"，适合复杂系统。
4. 用户访谈 vs 问卷调查 ：
   • 访谈：深度定性，适合"为什么"，关键干系人；
   • 问卷：广度定量，适合"是什么"，大规模用户。

五、应试技巧（得分关键）

1. 选择题技巧

• 概念题：紧扣定义关键词（如"可验证""双向跟踪"）；
• 场景题：匹配方法/模型的适用场景（如需求模糊用原型，跨部门项目用JRP）；
• 易混题：用表格对比核心差异，强化记忆（如上述易混点）。

2. 案例题技巧

• SRS评审题：按"结构完整性→内容准确性→可验证性→优先级→变更流程"5个维度检查，逐一标注缺陷并给出改进建议；
• 需求识别题：先区分业务/用户/系统需求，再区分功能/非功能需求，量化非功能需求；
• 需求跟踪题：绘制跟踪矩阵，说明正向/逆向跟踪的作用及缺失风险。

3. 论文技巧

• 主题聚焦：围绕"需求规格质量控制""需求变更管理""需求双向跟踪"展开；
• 结构清晰：背景→问题→解决方案（流程/工具）→效果→总结，结合实际项目案例；
• 突出能力：体现系统分析师的需求分析、建模、变更控制、干系人管理能力。

六、备考建议

1. 核心突破：重点掌握UML建模（用例图、序列图、类图）、需求跟踪矩阵、SRS标准结构，这是案例题得分核心；
2. 真题训练：近5年真题反复刷，重点分析案例题的缺陷类型与答题模板；
3. 实操练习：尝试编写1份完整的SRS文档，绘制需求跟踪矩阵，提升实战能力；
4. 关联记忆：结合计算机体系结构、数据库、网络等知识，理解需求与系统设计的关联，应对综合知识题。