考点频率：★★★★★（选择题必考，案例分析题高频）
难度：⭐⭐
建议：重点掌握需求获取与需求分析的区别，记住“获取是‘收’，分析是‘理’”
1️⃣ 需求工程在软考中的分量
需求工程是软考软件设计师考试中软件工程模块的核心考点，历年考试题型以单项选择题、多项选择题和案例分析题为主，分值占比约8%-12%。概念辨析题（如区分需求获取与需求分析的区别）是选择题的常客。在软件设计师考试中，需求工程相关知识点占软件工程模块分值的20%-25%。
据统计，软件项目失败的主要原因之一，就是需求获取不完整、需求理解有偏差，导致后续架构设计与用户期望脱节，返工成本激增。
2️⃣ 需求工程是什么？
需求工程是指应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述待开发系统及其特征和相关约束。它不仅仅是“收集需求”，而是一个贯穿软件生命周期初始阶段的综合性工程活动。
需求工程主要分为两大块：需求开发和需求管理。需求开发包括需求获取、需求分析、需求定义（编写需求规格说明书）和需求验证四个阶段。
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。
今天这篇文章聚焦于需求工程的前两个阶段：需求获取和需求分析。
3️⃣ 需求获取：把“原材料”收上来
3.1 什么是需求获取？
需求获取的核心任务是从用户、干系人、现有系统那里“挖”出原始需求。它关注的是“用户想要什么”。
用一个比喻来说：需求获取就像你去菜市场买菜——你要把各种原材料（用户的需求、期望、约束）先搬回厨房。需求获取的核心任务是“把原材料的来源搞明白”——你要主动找客户、用户、领域专家去聊、去问、去观察。
输出物：用户需求列表、用户访谈纪要、业务流程图草图
3.2 常见需求获取方法
需求获取方法大致分为三类：直接沟通、间接观察、原型法。
直接沟通类：
- 用户访谈：适合深挖隐性需求，一对一沟通，以开放式问题为主
- 联合需求计划（JRP）：召集用户、开发、测试等多方代表，集中工作坊式获取需求，高效促成多方共识
- 问卷调查：适合用户群分散、需要统计样本分布的场景，广覆盖收集共性意见
间接观察类：
- 现场观察：到用户工作现场观察实际操作流程，发现用户自己都意识不到的隐性需求
- 用户日志分析：通过分析用户的操作记录来挖掘需求
原型法：
- 快速构建原型让用户试用和反馈，在需求不明确时最有效
- 需求获取阶段用原型探索需求，需求分析阶段用原型确认需求，作用不同
考试陷阱：研讨会和焦点小组的区别——前者是结构化讨论，后者是非结构化头脑风暴。用户访谈一定要覆盖所有干系人，不能只找领导不找一线员工。
3.3 需求获取的注意事项
- 区分用户需求和系统需求：用户需求是业务语言（“我要能快速下单”），系统需求是技术语言（“系统响应时间≤2秒”）
- 双向确认：当天获取的内容当天发给对方确认，避免“你说过”“我没说过”的扯皮
- 分类归档：每条需求打上标签——功能类、非功能类、约束类、假设类
4️⃣ 需求分析：把“原材料”加工成“产品蓝图”
4.1 什么是需求分析？
需求分析是对获取到的原始需求进行过滤、建模、排序和冲突消除，最终形成软件需求规格说明书（SRS）。它回答的是“系统应该做成什么样”。
用一个比喻来说：需求分析就像你回到厨房，把买来的菜（原始需求）洗好、切好、配好——变成可以直接下锅的食材（可指导开发的规格说明）。
输出物：数据流图、用例图、需求规格说明书（SRS）
需求分析阶段的核心是建模——把原始需求“翻译”成可验证的逻辑模型。
4.2 需求分析的主要活动
| 活动 | 说明 |
|---|---|
| 需求建模 | 用例图、数据流图（DFD）、状态图等 |
| 需求排序 | 如MoSCoW方法（Must have / Should have / Could have / Won’t have） |
| 冲突识别与消除 | 发现并解决不同干系人需求之间的矛盾 |
| 需求验证 | 检查需求的正确性、完整性、一致性 |
4.3 结构化分析方法（SA）
结构化分析方法是软考的核心考点。它的核心思想是“自顶向下，逐层分解”。把一个大系统像剥洋葱一样，分解成若干个小功能模块，重点关注数据在系统中的流动、处理和存储。
核心建模工具：
| 工具 | 作用 | 考试要点 |
|---|---|---|
| 数据流图（DFD） | 描述系统的输入、输出、存储和处理逻辑 | 四大要素：外部实体、加工、数据存储、数据流 |
| 数据字典（DD） | 精确定义DFD中的所有数据元素 | 消除二义性，是数据库设计的重要输入 |
| 加工逻辑描述 | 细化DFD中复杂加工的内部逻辑 | 结构化语言、判定表、判定树 |
DFD分层绘制：顶层图（语境图）确定系统边界 → 0层图展示核心加工 → 对复杂加工继续分解。
考试重点：补充缺失的数据流、指出错误（如黑洞、灰洞、不平衡）。数据流必须经过加工，不能直接在外部实体与存储间流动。
5️⃣ 需求获取 vs 需求分析：核心区别（重点！）
这是软考选择题中极易混淆的考点，务必分清。
| 对比维度 | 需求获取 | 需求分析 |
|---|---|---|
| 核心动作 | 收集、记录、提问 | 建模、验证、优先级排序 |
| 输出物 | 访谈纪要、问卷汇总 | 数据流图、用例图、需求规格说明书 |
| 关键方法 | 访谈、观察、原型演示 | 结构化分析、面向对象分析 |
| 参与者 | 用户、客户、领域专家 | 系统分析师、架构师 |
| 典型问题 | “用户说想加积分功能” | “积分功能与现有订单系统如何对接？” |
| 是否建模 | ❌ 不涉及建模 | ✅ 必须建模 |
一句话总结：需求获取是“收集原材料”（把话问清楚），需求分析是“把原材料加工成产品蓝图”（把理理明白）。
软考答题技巧：判断某个活动属于哪个阶段——“有建模就是分析，没建模就是获取”。
6️⃣ 经典例题
例题1：需求工程中，“通过用户访谈、研讨会等方式收集所有相关方的需要和期望”主要对应于（ ）阶段。
A. 需求分析
B. 需求获取
C. 需求规格说明
D. 需求验证
解析：题干中的关键词“收集”直接指向需求获取阶段。需求分析是对收集到的信息进行提炼、建模；规格说明是文档化；验证是确认正确性。很多考生会误选A，但题目明确说“收集”行为，属于获取阶段。
答案：B
例题2：以下关于需求获取与需求分析的叙述中，正确的是（ ）。
A. 需求获取阶段需要绘制数据流图
B. 需求分析阶段不需要与用户沟通
C. 需求获取的输出是软件需求规格说明书
D. 需求分析需要对需求进行建模和冲突消除
解析：A错误——需求获取不涉及建模；B错误——需求分析仍需与用户沟通确认；C错误——需求获取的输出是用户需求列表，SRS是需求分析的输出；D正确。
答案：D
7️⃣ 记忆口诀
需求获取是“收”，需求分析是“理”。
获取不建模，分析必建模。
获取问“要什么”，分析定“什么样”。
人多地散用问卷，痛点不清做访谈，部门扯皮开JRP。
DFD看流程，DD定细节。
8️⃣ 小测验（评论区对答案）
某软件项目团队通过观察一线操作员的日常工作流程，记录了他们使用现有系统的方式和痛点。随后，团队根据这些记录绘制了用例图和数据流图，并对不同部门的需求进行了优先级排序。请问：观察操作员工作属于（ ）阶段，绘制用例图属于（ ）阶段。
A. 需求获取；需求分析
B. 需求分析；需求获取
C. 两者都是需求获取
D. 两者都是需求分析
🔔本专栏日更，点击头像 → 专栏《软考中级高频考点》订阅，第一时间接收新内容
#软考中级 #软件设计师 #需求工程 #需求获取 #需求分析 #软件工程
