软件工程-②需求工程

一、需求工程概述（教材核心定义）

需求工程是应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述待开发系统及其行为特征和相关约束的工程化过程，覆盖了体系结构设计之前的所有核心开发活动，核心目标是确定客户真实需求，定义设想中系统的所有外部特征，为后续架构设计、编码实现提供明确依据。

教材明确：需求工程的核心价值的是“避免需求偏差”——据统计，软件项目失败的主要原因之一，就是需求获取不完整、需求理解有偏差，导致后续架构设计与用户期望脱节，返工成本激增。因此，需求工程是系统架构设计师必须熟练掌握的基础能力，也是软考综合知识、案例分析的高频考点。

1.1 需求的定义与三个层次（教材重点）

教材明确了需求的本质：用户解决问题或达到目标所需的条件或权能，也是系统或系统部件要满足合同、标准、规范等正式文档所需的条件或权能，最终体现为反映这些条件的文档说明。

需求分为三个核心层次，自上而下逐层细化，是软考常考的基础知识点，需重点记忆：

• 业务需求：最高层次，反映组织机构或客户对系统的高层次目标要求，是“为什么做”的问题，通常由客户高层管理人员提出，比如“银行核心系统需实现存款、取款、转账的全流程线上化，满足监管合规要求”。

• 用户需求：中间层次，描述用户使用产品必须完成的任务，是用户对软件产品的具体期望，是“用户要做什么”的问题，比如“柜员需通过系统快速查询客户账户余额、办理转账操作，操作步骤不超过3步”。

• 系统需求：最底层，是开发人员必须实现的具体需求，分为功能需求和非功能需求，是“系统要做什么、要达到什么标准”的问题，也是需求工程的核心落地内容。

1.2 系统需求的细分（教材重点，软考高频）

教材将系统需求进一步细分为功能需求和非功能需求，两者缺一不可，案例分析题中常要求考生区分并梳理这两类需求：

• 功能需求：定义系统必须实现的具体功能，确保用户能完成既定任务，从而满足业务需求。比如“系统需支持客户手机号登录、密码重置、账户挂失功能”，是需求的核心核心，也是架构设计的直接依据。

• 非功能需求：对系统设计和实现提出的约束和质量要求，不直接实现业务功能，但决定系统的可用性、可靠性、安全性等，是架构设计的关键考量因素（与后续架构质量属性直接关联），教材明确主要包括：

  • 性能需求：响应时间、吞吐量、并发量等，比如“系统并发用户数≥1000，单笔转账响应时间≤1秒”；

  • 安全性需求：数据加密、权限控制、防攻击等，比如“客户密码需加密存储，管理员权限分级管控”；

  • 可靠性需求：系统可用性、容错能力等，比如“系统年可用性≥99.9%，支持故障自动恢复”；

  • 可维护性需求：系统易修改、易扩展，比如“系统模块耦合度低，支持新增支付方式时无需大规模修改代码”；

  • 约束条件：开发语言、运行环境、合规标准等，比如“系统需兼容Windows Server 2019，符合金融行业监管规范”。

二、需求工程的完整流程（教材核心流程，必背）

《系统架构设计师教程（第2版）》明确，需求工程是一个闭环的工程化过程，分为5个核心阶段，各阶段衔接紧密、缺一不可，也是软考案例分析题中“需求管理”考点的核心依据，需准确记忆各阶段的任务和输出物：

2.1 阶段1：需求获取（需求工程的基础）

核心任务：通过多种方法，全面、准确地收集用户的原始需求，避免需求遗漏或理解偏差，是后续所有工作的基础——教材强调，需求获取的质量直接决定整个需求工程的成败。

教材明确的需求获取步骤：

1. 开发高层的业务模型：结合目标系统的应用领域（如银行、电信），描述用户的核心业务过程，确定初始需求，后续通过迭代逐步完善；

2. 定义项目范围和高层需求：明确系统的边界（哪些功能属于系统，哪些不属于），描述系统与参与者的关系，通过系统上下文图、顶层用例图等建模手段呈现高层需求概貌；

3. 识别用户角色和用户代表：明确所有涉众（用户、客户、测试人员、维护人员等），区分不同用户角色的需求，若用户为应用程序或硬件，需选取熟悉其逻辑的人员作为用户代表；

4. 获取具体需求：在明确项目范围和涉众后，收集每个涉众的具体、详细需求；

5. 确定目标系统的业务工作流：梳理用户业务的完整流程，明确流程中的关键节点和需求；

6. 需求整理与总结：将收集到的需求分类整理，包括功能需求、性能需求、安全需求、用户界面需求等，形成初步的需求清单。

教材重点强调的获取方法（软考高频考点，需区分适用场景）：

• 用户面谈：一对一或一对多沟通，适合获取详细、个性化的需求，面谈后需复查笔记的准确性，转化为规范的需求描述；

• 需求专题讨论会：由主持人、用户、技术人员、项目组共同参与，畅所欲言，快速达成需求共识，解决涉众之间的需求冲突；

• 问卷调查：适合用户数量多、需求相对统一的场景，用于确认假设、收集统计性需求数据，通常在面谈后使用，弥补面谈的局限性；

• 现场观察：通过观察用户实际执行业务的过程，直观了解业务细节，避免用户因习惯而遗漏的隐性需求；

• 原型化方法：针对需求模糊、不确定的场景（如人机界面设计），快速制作可演示原型，让用户体验后反馈修改，明确需求；

• 头脑风暴法：适用于新业务拓展类项目，组织团队发散思维，产生新的需求观点，明确具体需求方向。

2.2 阶段2：需求分析（需求的提炼与建模）

核心任务：对获取的原始需求进行分析、提炼、整理，消除歧义、冗余和冲突，建立需求的概念模型，将用户需求转化为系统可理解、可实现的需求描述，核心是“理清需求之间的关系，明确需求的优先级”。

教材强调，需求分析的关键是“去粗取精、去伪存真”，常用的分析方法和工具的（软考高频）：

• 结构化分析方法：通过数据流图（DFD）、数据字典、判定表、判定树等工具，描述系统的数据流和逻辑流程，适合结构化系统的需求分析；结构化分析方法链接

• 面向对象分析方法（OOA）：以用例为核心，通过用例图、类图、时序图等UML模型，描述系统的角色、用例和对象关系，是当前主流的需求分析方法，也是教材重点介绍的方法；面向对象链接

• 需求优先级排序：结合业务需求和项目资源，对需求进行分级（如必须实现、应该实现、可以实现、暂不实现），常用方法有MoSCoW法（Must、Should、Could、Won’t），为后续架构设计和开发计划提供依据。

2.3 阶段3：需求规格说明（需求文档化）

核心任务：将需求分析的结果整理成标准化的文档，即《软件需求规格说明书（SRS）》，这是需求工程的核心输出物，也是客户与开发团队之间的约定，后续所有开发活动（架构设计、编码、测试）都以该文档为依据。

教材明确，《软件需求规格说明书》需包含以下核心内容（软考案例分析题常考文档结构）：

• 引言：项目背景、需求范围、文档目的；

• 总体描述：系统概述、运行环境、用户特征、约束条件；

• 具体需求：功能需求、非功能需求的详细描述；

• 接口需求：系统与外部系统、用户、硬件的接口描述；

• 其他需求：数据需求、安全需求、可维护性需求等；

• 附录：术语定义、参考资料等。

教材特别强调：需求规格说明书需具备完整性、一致性、可测试性、可行性——即所有需求都需明确描述，无歧义、无冲突，每个需求都能设计测试用例验证，且在当前技术和资源条件下可实现。

2.4 阶段4：需求确认与验证（需求的审核）

核心任务：由客户、用户、开发团队、测试团队共同参与，对需求规格说明书进行审核，确认需求是否符合用户期望、是否完整、是否可实现，确保需求文档的准确性和可用性，避免后续返工。

教材明确的验证方法：

• 用户确认：让用户通读需求文档，确认需求符合其原始期望；

• 复审会议：组织各方人员召开复审会，逐一审核每个需求，提出修改意见；

• 原型验证：通过演示原型，验证需求的合理性和可操作性；

• 可测试性验证：检查每个需求是否能设计测试用例，确保后续测试工作可开展。

验证通过后，需求规格说明书将成为“需求基线”——即需求的基准版本，后续任何需求变更都需基于该基线进行控制，这是需求管理的核心基础。

2.5 阶段5：需求管理（需求的持续管控）

核心任务：在需求基线建立后，对需求的变更进行控制、跟踪和管理，确保需求变更有序进行，避免需求失控导致项目延期、成本增加，贯穿整个项目生命周期（从需求确认到系统维护）。

教材重点强调的需求管理核心内容（软考高频考点）：

• 需求基线管理：明确需求基线的版本，控制对基线的修改，任何修改都需经过审批；

• 需求变更控制：建立规范的变更控制流程，所有需求变更都需提交变更申请，经过分析、审批后才能实施（详细流程见下文）；

• 需求跟踪管理：建立需求跟踪矩阵（RTM），跟踪每个需求从“需求获取”到“设计、编码、测试、上线”的全流程，确保每个需求都被实现、被测试，避免需求遗漏；

• 需求版本管理：对需求文档的每个版本进行管理，记录版本变更记录，便于追溯和回滚；

• 需求状态管理：跟踪每个需求的状态（如待审核、已确认、已实现、已测试），确保需求进度可管控。

三、需求变更管理（教材重点，软考案例分析高频）

教材明确：需求变更不可避免，核心原因包括需求获取不完整、对需求理解有偏差、业务流程变化、市场环境变化等。需求变更管理的核心不是“禁止变更”，而是“规范变更流程，控制变更风险”，避免变更无序导致项目混乱。

3.1 需求变更控制流程（教材原文流程，必背）

1. 识别问题：发现需求偏差或需要变更的场景，提出需求变更提议；

2. 问题分析和变更描述：分析问题的有效性，明确变更的具体内容、范围和原因，形成正式的《需求变更申请表》；

3. 变更分析和成本计算：评估变更对项目进度、成本、质量、架构设计的影响，计算变更所需的资源和时间；

4. 变更审批：由变更控制委员会（CCB）对变更申请进行审批，决定是否批准变更（审批结果分为：批准、驳回、延期）；

5. 变更实现：若变更批准，按照项目开发流程执行变更（计划驱动模型中，需回溯到需求分析阶段，重新进行分析、设计、实现；敏捷模型中，将变更纳入下一次迭代）；

6. 变更验证与归档：变更实现后，验证变更的正确性，更新需求基线、需求文档和需求跟踪矩阵，归档变更记录。

3.2 变更控制委员会（CCB）的职责（教材重点）

教材明确，变更控制委员会（CCB）是需求变更的决策机构，由客户代表、项目负责人、架构设计师、测试负责人等组成，核心职责包括：

• 审核需求变更申请的合理性和必要性；

• 评估变更对项目的影响（进度、成本、质量、架构）；

• 决策变更是否批准、驳回或延期；

• 监督变更的执行过程，确保变更按流程实施；

• 协调变更过程中的各方利益，解决变更引发的冲突。

3.3 教材强调的需求变更策略（软考必记）

• 所有需求变更必须遵循变更控制流程，无审批的变更不得实施；

• 对于未获得批准的变更，不得开展设计和实现工作；

• 变更需及时通知所有相关人员，确保各方对变更内容达成共识；

• 不得从项目配置库中删除或修改变更请求的原始文档，确保变更可追溯；

• 每一个集成的需求变更，都必须能跟踪到一个经核准的变更请求，保持需求的可追踪性。

四、需求跟踪（教材核心工具，软考高频）

教材明确，需求跟踪的核心目的是建立并维护“需求-设计-编码-测试”之间的一致性，确保所有开发工作都围绕需求展开，避免需求遗漏或偏离，核心工具是需求跟踪矩阵（RTM），也是软考案例分析题中常要求绘制的工具之一。

4.1 需求跟踪的两种方式（教材重点）

• 正向跟踪：从需求出发，跟踪到设计文档、编码模块、测试用例，确保每个需求都被实现、被测试；

• 逆向跟踪：从测试用例、编码模块、设计文档出发，回溯到对应的需求，确保所有开发成果都有需求依据，无多余功能。

4.2 需求跟踪矩阵（RTM）核心内容（教材示例）

教材给出的RTM核心字段，软考案例分析可直接套用：

五、教材高频考点总结（软考必记）

结合《系统架构设计师教程（第2版）》原文，梳理需求工程的软考高频考点，直击核心，避免无效复习：

1. 需求的三个层次：业务需求、用户需求、系统需求（功能+非功能），能区分不同层次的需求描述；

2. 需求工程的5个阶段：获取→分析→规格说明→确认与验证→管理，记住每个阶段的核心任务和输出物；

3. 需求获取的6种方法：面谈、专题讨论会、问卷调查、现场观察、原型化、头脑风暴，掌握每种方法的适用场景；

4. 需求变更控制流程：识别问题→分析描述→成本计算→审批→实现→验证归档，记住CCB的职责；

5. 需求跟踪矩阵（RTM）：掌握正向/逆向跟踪的含义，能绘制简单的RTM；

6. 需求基线的定义和作用：验证通过的需求规格说明书，是变更控制的基准；

7. 非功能需求的分类：性能、安全性、可靠性、可维护性等，能结合案例场景梳理非功能需求。

六、总结（教材核心观点）

《系统架构设计师教程（第2版）》强调：需求工程是系统架构设计的前提和基础，架构设计必须基于明确、完整、一致的需求——脱离需求的架构设计，再优秀也无法满足用户期望。对于系统架构设计师而言，掌握需求工程的流程和方法，不仅是软考通关的关键，更是实际工作中规避项目风险、提升架构合理性的核心能力。

本文严格对照教材原文梳理，无多余拓展，适合软考备考和工作备查，后续可结合教材案例，深化对需求工程的理解，真正将知识点落地到实际架构设计工作中。