本章属于教材第二篇「关键技术」，是系统分析师考试的核心分值章节，对应 2024 版考试大纲中「系统分析」的核心能力要求，年均考查分值 15~22 分，覆盖上午选择题、下午案例分析题、论文写作三大题型。
一、章节主要内容框架
全章共分为 8 个小节，完整覆盖需求开发全流程与需求管理体系：
11.1 软件需求概述
本小节是全章的基础概念部分，核心内容包括：
需求的三层分类：业务需求（组织高层目标）、用户需求（角色任务期望）、系统需求（功能 + 非功能 + 设计约束），是需求分析的层级框架51CTO...。
质量功能部署（QFD）：将用户需求分为常规需求、期望需求、意外需求（兴奋需求）三类，用于需求优先级排序。
非功能需求模型：FURPS + 模型（功能性、可用性、可靠性、性能、可支持性 + 实现 / 接口 / 操作等约束）、PIECES 框架（性能、信息、经济、控制、效率、服务）。
需求工程的两大过程：需求开发（获取→分析→定义→验证，集中在系统分析阶段）、需求管理（全生命周期跟踪与变更控制）。
11.2 需求获取
本小节讲解需求收集的 6 类核心方法与工具，是选择题高频考点：
用户访谈：1 对 1 或小组形式，分结构化 / 半结构化 / 非结构化，适合深度挖掘动机类需求，灵活性强但样本量有限。
问卷调查：标准化问卷面向大规模用户，适合定量统计共性需求，信效度高但缺乏灵活性。
采样：基于数理统计从总体中选取代表性样本，核心公式为
样本数=0.25×(可信度因子/错误率)²，常用于大规模文档 / 行为分析51CTO...。情节串联板：通过图片、原型演示系统交互流程，分被动式、主动式、交互式三类，直观性强但耗时较长。
联合需求计划（JRP）：高度组织的跨方专题会议，6~18 人参与，1~5 小时集中讨论，快速达成需求共识，对主持人控场能力要求高。
需求记录技术：任务卡片、场景说明、用户故事（敏捷场景常用，格式为「作为 <角色>，我想 < 动作 >，以便 < 价值 >」）、Volere 白卡。
11.3 需求分析
本小节是需求工程的核心环节，讲解分析的任务与三大方法论：
需求分析的核心任务：将零散用户需求转化为完整、清晰、无歧义的规范描述，输出可指导设计的需求模型。
三大分析方法：
结构化分析（SA）：自顶向下、逐层功能分解，适合流程清晰的传统项目；
面向对象分析（OOA）：以对象为核心封装属性与行为，适合复杂迭代项目；
面向问题域分析（PDOA）：第 2 版新增考点，重描述、轻建模，先清晰定义问题域与需求列表，再推导解系统行为，适合需求模糊的复杂场景。
11.4 结构化分析方法（SA）
结构化分析的核心工具与建模方法，是案例题高频出题点：
数据流图（DFD）：
四大核心元素：外部实体、加工（处理过程）、数据存储、数据流；
分层结构：顶层图→0 层图→底层子图，遵循「父图子图平衡」原则；
常见错误：黑洞（有输入无输出）、奇迹（有输出无输入）、灰洞（输入不足以产生输出）。
状态转换图（STD）：描述系统 / 对象的状态与触发迁移的事件，用于行为建模。
数据字典（DD）：DFD 的配套说明工具，包含 6 类条目：数据元素、数据结构、数据流、数据存储、加工逻辑、外部实体，定义所有数据项的属性与规则。
11.5 面向对象分析方法（OOA）
本章的核心重难点，UML 建模是案例题必考点：
用例模型：
构建步骤：识别参与者→合并需求获得用例→细化用例描述→调整用例模型；
用例三大关系：包含（include，必执行的公共行为）、扩展（extend，条件触发的分支场景）、泛化（generalization，父子用例继承）。
分析模型：
构建步骤：定义概念类→确定类间关系→为类添加职责→建立交互图；
类间关系：依赖、关联、聚合、组合、泛化、实现，需区分关系强弱与语义差异；
核心 UML 图：类图（静态结构）、序列图 / 通信图（动态交互）、状态图、活动图。
11.6 需求定义
讲解需求规格说明书（SRS）的编写与两种需求定义方法：
需求定义的两类方法：
严格定义法（预先定义）：假设需求可提前完整明确，适合需求稳定的瀑布型项目；
原型法：迭代构建可运行原型，通过用户反馈逐步完善需求，适合需求模糊的项目。
软件需求规格说明书（SRS）：需求开发的最终交付物，遵循 IEEE 830 标准结构，包含引言、总体描述、系统特性、外部接口需求、非功能需求等核心部分，是开发、测试、验收的核心依据。
11.7 需求验证
确保需求质量的核心环节，包含评审与测试两类手段：
需求评审：
三类评审形式：正式评审（会议式多方审批）、检查（专人专项查错）、走查（开发者自查 + 团队辅助）；
评审优化策略：分层次评审、分阶段评审、正式与非正式结合、使用检查单、评审后跟踪闭环。
需求测试：通过概念测试用例模拟需求执行，提前发现遗漏、冲突、不合理的需求，在设计前修正需求缺陷。
11.8 需求管理
全生命周期的需求管控，是案例与论文的高频主题：
需求变更管理：
变更控制流程：问题分析与变更描述→变更分析与成本评估→CCB 决策→变更实现与验证；
变更控制委员会（CCB）：决策机构，负责评估变更影响、审批变更申请，不承担具体开发工作。
需求跟踪：
正向跟踪：从业务需求→用户需求→系统需求→设计→编码→测试，确保每个需求都被实现；
逆向跟踪：从测试用例→代码→设计→需求，确保每个实现都有需求依据；
核心工具：需求跟踪矩阵，记录需求与各阶段工件的映射关系。
二、主要考点与考情分析
1. 上午选择题（5~8 分）
高频考点按考频排序：
需求分层（业务 / 用户 / 系统需求的区分）、QFD 三类需求辨析；
需求获取 6 种方法的适用场景与优缺点对比；
DFD 的元素识别、常见错误判断、父图子图平衡原则；
用例三大关系（包含 / 扩展 / 泛化）的区分；
类间关系（聚合 / 组合 / 依赖 / 关联）的语义辨析；
需求评审的三类形式差异；
第 2 版新增：PDOA 方法的核心思想与特点。
2. 下午案例分析题（10~14 分）
核心出题方向：
需求缺陷分析题：给出一段 SRS 片段，指出其中的需求质量问题（如模糊表述、无验收标准、冲突需求），并给出改进建议；
DFD 改错题：给出不完整或错误的分层 DFD，补充缺失的数据流、指出常见错误（黑洞 / 奇迹 / 灰洞、父图子图不平衡）；
UML 建模题：根据业务场景补充用例图（参与者、用例、关系）、序列图（消息顺序）或类图（类与关系）；
需求管理题：给出项目中需求变更混乱的场景，指出变更流程缺陷，补充完整的变更管控方案，或说明双向跟踪的作用。
3. 论文写作（高频主题）
历年高频论文题目：
《论软件需求规格说明书的质量控制》
《论软件需求变更管理的实践》
《论需求双向跟踪在项目中的应用》
《论面向对象需求分析方法的实践》
三、重难点深度解析
（一）核心重点内容
需求分层与非功能需求识别
这是所有题型的基础考点，核心区分逻辑：业务需求讲「为什么做」，用户需求讲「谁要做什么」，系统需求讲「系统要实现什么」。案例题中需能从业务描述中准确拆分功能需求与非功能需求，并将非功能需求量化（如将「系统要快」改为「95% 的查询响应时间≤1 秒」）。
三大需求分析方法的对比与适用场景
DFD 的绘制规则与错误识别
这是案例题的必拿分点，核心规则：
数据流必须与加工相连，不能直接在外部实体之间、数据存储之间流动；
每个加工必须至少有一个输入和一个输出；
父图与子图的输入输出数据流必须完全一致（平衡原则）。
需求变更与双向跟踪
需求变更流程是案例题的标准考点，需牢记完整步骤；双向跟踪是论文的核心论据，正向跟踪解决「需求有没有都做」，逆向跟踪解决「做的有没有需求依据」，二者共同保障需求的一致性与可追溯性。
（二）高频难点与易混点
用例包含、扩展、泛化的区分
包含（include）：基础用例必须执行被包含用例，箭头指向被包含用例，如「下单」包含「验证用户登录」；
扩展（extend）：扩展用例在特定条件下触发，箭头指向基础用例，如「优惠券抵扣」扩展「订单支付」；
泛化（generalization）：子用例继承父用例的所有特性，箭头指向父用例，如「微信支付」泛化「第三方支付」。
聚合与组合的语义差异
二者都是「整体 - 部分」的关联关系，核心区别在于生命周期是否绑定：
聚合：部分可独立于整体存在，如「班级」与「学生」，班级解散学生依然存在；
组合：部分与整体生命周期完全绑定，如「订单」与「订单项」，订单删除订单项也随之消失。
PDOA 方法的理解（第 2 版新增难点）
PDOA 的核心是「先把问题说清楚，再谈系统怎么做」，它不做系统建模，只输出问题域的完整描述和需求清单，是需求分析的前置环节，通常后续再衔接 SA 或 OOA 进行建模。区别于传统方法直接建模的思路，PDOA 更强调对业务问题本身的深度理解。
SRS 的编写规范与质量判断
好的 SRS 必须满足「正确、无歧义、完整、一致、可验证、可跟踪」，案例题中常见的 SRS 缺陷包括：使用「快速」「友好」等模糊形容词、无量化验收标准、遗漏异常场景、需求之间存在冲突、未区分优先级。
本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。
欢迎访问 小易撩挨踢