需求工程——你真的懂吗

        经验丰富的系统架构师、项目经理都应该明白，精准的需求定位和合理的范围控制是项目成功的关键因素。

        今天我们学习一下“需求工程”，它是一个完整的、系统化的工程过程，是软件项目中最重要且最易出错的环节。作为系统架构师，深刻理解需求工程是做出正确架构决策的绝对前提。

一、软件需求的层次

1. 业务需求：最高层的抽象。反映组织或客户的高层目标。为什么要做这个系统？

   例如：“提升客户在线下单率30%”、“实现业务流程自动化，降低人力成本”。产出物：《项目愿景与范围文档》。

2. 用户需求：用户需要利用系统做什么来完成他们的任务。它从用户视角描述，通常不使用技术语言。

   例如：“作为买家，我希望能够收藏商品，以便日后方便查找。”产出物：《用例文档》或《用户故事地图》。

3. 系统需求（功能需求）：最具体的描述。定义了系统必须实现的功能，是用户需求的具体化、技术化描述。它作为开发者和测试人员之间的契约。

   例如：“在商品详情页应显示‘加入收藏夹’按钮。用户点击后，系统需将该商品ID与用户ID关联并持久化存储，并弹出‘收藏成功’提示。”产出物：《软件需求规格说明书（SRS）》的核心内容。

4. 非功能需求（质量属性/约束）：描述系统运行的条件或需要具备的品质。它约束功能需求如何被实现。这是架构师最关心的部分！

   质量属性：性能、安全性、可用性、可维护性等。约束：技术选型（必须使用Oracle数据库）、合规性要求（必须符合GDPR）、硬件环境等。产出物：《SRS》中的“非功能需求”章节，直接影响《架构设计文档》。

核心关系：业务需求 -> (衍生出) -> 用户需求 -> (分析细化为) -> 系统需求（功能+非功能）

二、全过程视角——需求工程

        “需求工程”指的是所有与需求相关的活动的集合，而不仅仅是一个步骤。它是一个贯穿项目初期的完整流程。

        其核心过程包括以下四个主要活动（这是一个闭环）：

1. 需求获取：从用户、客户、文档、现有系统等来源“挖掘”需求。

   技术：访谈、头脑风暴、问卷调查、研讨会、原型法、观察、文档分析等。

2. 需求分析：对获取的需求进行提炼、分析和审查。

   目的：发现并解决需求之间的冲突、歧义和不一致性；将需求分类、排序；建立分析模型（如用例图、数据流图）。

3. 需求规格说明：将分析后的需求文档化，生成《软件需求规格说明书（SRS）》。目的是在客户和开发者之间建立一份清晰的、共同认可的契约。

4. 需求验证：审查SRS文档，确保需求是正确的、完整的、无二义的、可实现的、可测试的。

   技术：需求评审、原型验证、编写测试用例等。

5. 需求管理：是一个对系统需求变更、了解和控制的过程，覆盖在上述所有活动之上的保护性和控制性活动，包括变更控制、版本控制、需求跟踪等活动。

《软件需求规格说明书》

• 它是什么？ 需求开发活动的最终产物，是项目的基础性文档。

• 它包含什么？

  • 引言：目的、范围、术语。

  • 总体描述：产品视角、用户特征、假设与依赖。

  • 详细需求：

    • 功能需求：逐条描述，通常按特性或用户角色组织。

    • 非功能需求：性能、安全性、可靠性、可用性等。

三、控制变化——需求管理（变更与跟踪）

1. 需求变更

   根源：市场变化、业务调整、技术革新、初期认知不足。变更是不可避免的，必须被管理，而不是被禁止。流程：识别问题->问题分析和变更描述 -> 变更影响分析和成本计算（由项目经理、架构师等评估对范围、成本、进度、技术的影响） -> CCB评审 -> 批准/拒绝 -> 实施。

2. 变更控制委员会CCB

   是什么？ 一个由项目干系人（如客户代表、项目经理、架构师、产品经理）组成的正式小组。职责：负责评估、批准或拒绝项目中的各项变更请求。它的存在确保了变更决策的集体性和权威性，避免了随意变更。

3. 需求跟踪

   是什么？ 一种能力，用于描述和跟踪一个需求的“前世今生”，并链接到后续的设计、代码和测试用例。工具：《需求跟踪矩阵》（RTM）。目的：①影响分析：当需求变更时，能快速定位到需要修改的设计、代码和测试用例，评估变更范围。②反向跟踪：检查每一行代码、每一个测试用例是针对哪个需求而做的。③正向跟踪：检查每个需求是否都被设计和实现了。

课后思考题：

1. 一个需求描述是：“系统响应速度要快。” 这属于哪个层次的需求？它存在什么问题？如何将其转化为一个好的系统需求？

2. 在一个项目中，客户突然提出一个重大的需求变更。作为架构师，你在“变更影响分析”环节，主要会从哪些技术角度进行评估？