【系统分析师】第11章-关键技术：软件需求工程（核心总结）

软件需求工程是系统分析师考试中的核心内容，也是软件工程的重要基础。《系统分析师教程（第二版）》对软件需求工程的基本概念、需求获取、分析、建模、验证与管理等进行了系统阐述。

一、软件需求工程概述

1.1 定义与重要性

软件需求工程是连接用户需求与软件产品的核心桥梁，其本质是通过系统化的流程，将模糊、零散的用户期望转化为清晰、可验证、可管理的软件需求，最终保障软件产品的功能与用户目标高度契合，是软件项目成功的关键前提。

软件需求工程是指对软件系统需求进行系统化获取、分析、建模、验证和管理的过程。其核心目标是明确用户需求，确保软件系统能够满足用户期望和业务目标。需求工程的重要性体现在：

• 减少软件开发中的返工与修改；
• 提高软件系统的质量与用户满意度；
• 降低开发成本与风险；
• 确保软件系统与业务目标一致。

1.2 需求的分类

需求是指用户为解决特定问题或实现特定目标，对软件产品提出的功能、性能、约束等方面的期望。根据《系统分析师教程（第二版）》，需求从不同维度可分为以下类别，各类别层层递进、相互支撑，共同构成需求体系：

需求类别	核心定义	关键特征	典型示例
业务需求	组织层面的高层目标，反映业务战略方向	战略性、宏观性、目标导向	“实现线上订单转化率提升20%”“降低库存周转天数至15天”
用户需求	用户在使用软件时的具体操作期望，以用户视角描述	场景化、主观性、非技术化	“我希望3步内完成订单支付”“能快速查询近3个月的消费记录”
功能需求	软件为实现用户需求需提供的具体功能，是需求的核心	可执行性、可验证性、技术关联	“支持微信/支付宝两种支付方式”“提供按时间/金额筛选的消费查询功能”
非功能需求	对软件功能的补充约束，保障使用体验与系统质量	约束性、全局性、隐性关键	性能（“支付响应时间≤2秒”）、安全性（“用户密码加密存储”）、易用性（“新用户上手培训≤30分钟”）
设计约束	开发过程中需遵循的技术或环境限制	强制性、外部依赖性	“需兼容Windows 10及以上系统”“采用Java语言开发后端”

1.3 需求工程的核心目标与原则

需求工程的核心目标并非简单“收集需求”，而是通过规范化流程，确保需求的完整性、一致性、可行性，减少需求变更带来的项目风险，为后续设计、开发、测试提供明确依据。其需遵循三大核心原则：

1. 用户参与原则：需求采集需贯穿用户（或用户代表），避免“闭门造车”，确保需求符合实际使用场景；
2. 渐进明细原则：需求并非一次性确定，需在项目推进中逐步细化，平衡“尽早明确”与“避免过度设计”；
3. 可验证原则：每一项需求都需具备可验证的标准（如“响应时间≤2秒”可通过性能测试验证），避免模糊表述（如“界面要友好”）。

1.4 需求工程的常见问题与应对策略

在实际项目中，需求工程易出现“需求遗漏”“变更频繁”“用户不认可”等问题，《系统分析师教程（第二版）》针对这些问题提供了具体应对思路：

常见问题	核心原因	应对策略
需求遗漏或理解偏差	需求获取方法单一，未覆盖关键用户；未与用户确认需求	1. 采用“访谈+观察+原型”组合方法；2. 需求文档完成后，让用户签字确认，形成“需求基线”
需求变更频繁	需求未明确优先级；变更流程不规范；业务场景变化	1. 初期明确需求优先级，核心需求锁定基线；2. 建立严格的变更审批流程，高成本变更需高层决策
非功能需求被忽视	过度关注功能，忽略性能、安全性等隐性需求	1. 需求分析阶段单独梳理非功能需求，纳入《SRS》；2. 非功能需求需量化（如“支持1000人同时在线”）
需求文档难以理解	文档表述模糊，缺乏可视化模型	1. 结合用例图、DFD等模型辅助说明；2. 避免技术术语堆砌，确保用户能看懂核心内容

二、需求获取

2.1 定义与目标

需求获取是指从用户和业务环境中收集信息，识别并记录用户需求的过程。其目标是全面、准确地理解用户需求，为后续的需求分析奠定基础。

2.2 需求获取的方法

常见的需求获取方法包括：

1. 访谈法：通过与用户、业务专家进行一对一或小组访谈，获取需求信息；
2. 问卷调查法：通过设计问卷，收集大量用户的需求信息；
3. 观察法：通过观察用户的实际工作流程，获取隐含需求；
4. 文档分析法：通过分析现有文档（如业务流程图、用户手册），提取需求；
5. 头脑风暴法：通过集体讨论，激发创新和需求灵感。

2.3 需求获取的注意事项

• 确保需求来源的多样性和代表性；
• 避免需求遗漏和误解；
• 记录需求时要清晰、准确、无歧义；
• 注意需求的可行性和优先级。

三、需求分析

3.1 定义与目标

需求分析是对获取的需求进行深入分析、整理和分类的过程。其目标是明确需求的内涵，识别需求之间的依赖关系，并解决需求中的冲突和矛盾。

3.2 需求分析的任务

1. 需求分类：将需求分为功能需求、非功能需求和约束条件；
2. 需求优先级排序：根据业务价值、实现难度等因素，对需求进行优先级排序；
3. 需求冲突解决：识别并解决需求之间的冲突；
4. 需求可行性分析：评估需求的技术可行性和经济可行性。

3.3 需求分析的方法

1. 功能分解法：将复杂需求分解为更小的、可管理的子需求；
2. 用例分析法：通过用例描述系统的功能需求；
3. 原型法：通过构建原型，帮助用户更直观地表达需求；
4. 场景分析法：通过描述用户使用系统的场景，分析需求。

---

四、需求建模

4.1 定义与目标

需求建模是将需求以图形化或形式化的方式表示出来，以便更好地理解和沟通需求。其目标是提供清晰、准确的需求描述，为系统设计提供依据。

4.2 需求建模的常用工具

1. 数据流图（DFD）：描述系统中数据的流动和处理过程；
2. 用例图：描述系统的功能需求及用户与系统的交互；
3. 状态图：描述系统的状态变化及触发条件；
4. 活动图：描述系统中的业务流程或操作流程；
5. 类图：描述系统中的类及其关系。

4.3 需求建模的步骤

1. 确定建模的范围和目标；
2. 选择合适的建模工具；
3. 绘制模型图；
4. 验证模型的准确性和完整性；
5. 与用户和开发团队沟通确认模型。

五、需求验证

5.1 定义与目标

需求验证是检查需求是否准确、完整、一致且可测试的过程。其目标是确保需求能够真正反映用户需求，并为后续的开发和测试提供依据。

5.2 需求验证的方法

1. 需求评审：通过组织评审会议，邀请专家和用户对需求进行审查；
2. 原型验证：通过构建原型，让用户实际操作并反馈需求；
3. 需求测试：设计测试用例，验证需求是否可测试；
4. 形式化验证：通过数学方法验证需求的逻辑一致性。

5.3 需求验证的注意事项

• 确保需求的可测试性；
• 避免需求的二义性和模糊性；
• 确保需求与业务目标一致；
• 记录验证结果并处理发现的问题。

六、需求管理

6.1 定义与目标

需求管理是对需求进行跟踪、控制和变更管理的过程。其目标是确保需求在整个软件生命周期中的一致性和可追溯性。

6.2 需求管理的内容

1. 需求跟踪：建立需求与设计、代码、测试用例之间的关联；
2. 需求变更控制：管理需求的变更请求，评估变更的影响；
3. 需求版本管理：记录需求的变更历史；
4. 需求状态管理：跟踪需求的状态（如“已批准”、“已实现”）。

6.3 需求管理的工具

1. 需求管理工具：如IBM DOORS、JIRA、CaliberRM等；
2. 配置管理工具：如Git、SVN等；
3. 项目管理工具：如Microsoft Project、Trello等。

七、典型应用案例

7.1 企业资源计划（ERP）系统

在ERP系统的需求工程中，通过访谈和问卷调查获取企业的业务需求，通过用例图和活动图进行需求建模，并通过需求评审和原型验证确保需求的准确性。

7.2 电子商务平台

在电子商务平台的需求工程中，通过用户访谈和观察法获取用户需求，通过类图和状态图进行需求建模，并通过需求测试验证需求的可测试性。

7.3 政府服务系统

在政府服务系统的需求工程中，通过文档分析和头脑风暴法获取需求，通过数据流图和用例图进行需求建模，并通过需求评审和形式化验证确保需求的逻辑一致性。

八、考试重点与论文方向

8.1 考试重点

系统分析师考试中，软件需求工程的重点内容包括：

• 需求工程的定义、目标与步骤；
• 需求获取、分析、建模、验证与管理的方法；
• 需求建模工具的使用。

8.2 论文写作方向

论文可结合实际案例，从以下角度展开：

1. 需求获取在ERP系统开发中的应用；
2. 需求建模工具在电子商务平台开发中的实践；
3. 需求验证在政府服务系统开发中的重要性；
4. 需求管理在大型软件项目中的应用。

总结：软件需求工程是系统分析师考试的核心内容，其实践贯穿于软件开发的整个生命周期。掌握需求工程的基本理论、工具和方法，不仅有助于考试备考，也为实际项目提供了科学指导。