需求工程基础

发表于 2025-12-11 Waline：阅读次数：本文字数： 4.7k 阅读时长 ≈ 17 分钟

在软件开发中，需求（Requirement）不仅仅是一份文档，它是现实世界的问题与计算机世界的解决方案之间的契约。需求工程的核心任务，就是在一个充满模糊性的现实世界中，准确地定义出计算机系统应该「做什么」。

核心视点：两个世界的交汇

理解需求工程，首先要建立「两个世界」的观念。

问题域与解系统

软件开发的本质，是构建一个计算机系统（解系统）来解决现实生活中存在的问题（问题域）。

问题域：这是现实世界的一部分。当现实状况与人们的期望产生差距时，问题就产生了。问题域是自治的，它有自己的运行规律（如物理定律、商业规则），这些规律不会因为引入了软件系统而改变。
解系统：这是计算机世界的产物。软件通过模拟和计算，影响问题域中的实体状态，从而帮助人们解决问题。

共享现象与模拟

计算机系统之所以能解决现实问题，是因为它在内部建立了一个关于现实世界的模型。

模拟：软件系统必须包含问题域中某些部分的模型（如数据模型模拟库存、对象模型模拟员工）。
共享现象：这是问题域与解系统的交集。
- 例子：条形码扫描。现实中的商品移动（问题域行为）与系统内的库存扣减（系统行为）通过扫描这一动作建立了映射。
- 数字孪生：现代 App 中，像素模拟了图形，流数据模拟了音视频，AI 模型甚至试图模拟人类智力。

需求的 IEEE 定义

用户为了解决问题或达到某些目标所需要的条件或能力。
系统为了满足合同、标准、规范所必须具备的条件或能力。
上述条件或能力的文档化表述。

需求工程的过程：从模糊到精确

需求工程不是一个线性的「流水线」，而是一个包含并发和迭代的复杂过程。其核心目标是处理需求开发中的不确定性和变更。

主要活动

需求工程（RE）通常包含以下五个核心活动，它们在实际项目中往往是交织进行的：

需求获取：「挖掘原始需要」。
- 研究应用环境，分析涉众，了解已有问题。
- 产出：模糊的、原始的用户需求。
需求分析：「保证完整与一致」。
- 这是最核心的建模过程。将用户目标映射为系统行为，识别冲突，发现遗漏。
- 关键点：这是从「用户任务」转化为「系统交互」的关键步骤。
需求规约：「文档化」。
- 使用自然语言或模型语言（如 UML）编写《需求规格说明书》（SRS）。
需求验证：「确保正确」。
- 确保写出来的需求是用户真正想要的，且是正确的、完整的。
需求管理：「控制变更」。
- 在整个生命周期中管理需求基线，跟踪变更，确保可追溯性。

敏捷环境下的需求工程（Agile RE）

在敏捷开发（如 XP, Scrum）中，需求工程的形式发生了变化：

面对面交流胜过厚重的文档。
用户故事替代了传统的规格说明。
待办事项列表的持续梳理替代了阶段性的需求冻结。
需求被拆解得极细（Epic $\to$ Feature $\to$ Story），以便在短迭代中快速交付。

需求的层次性：金字塔模型

一个优秀的软件系统，其需求应当在三个层面上保持一致。这构成了需求的「金字塔」结构。

业务需求（Business Requirements, BR）
- 定义：组织为什么要开发这个系统？这是战略出发点。
- 关注点：高层次的商业目标（Objective）。通常涉及收入增加、成本降低、效率提升等。
- 来源：商业模式画布（BMC）。BR 往往对应画布中的核心资源优化、关键业务改进或收入来源拓展。
- 例子（连锁商店）：「系统上线 6 个月后，商品积压率减少 50%」（对应成本结构优化）。
用户需求（User Requirements, UR）
- 定义：用户使用系统能做什么？
- 关注点：任务（Task）。描述用户为了完成业务目标，需要执行的具体工作流程。
- 表达方式：通常使用用例（Use Case）或用户故事（User Story）来描述。它侧重于「人」的视角，而非技术的视角。
- 例子：「收银员可以扫描商品，处理顾客的付款。」
系统级需求（System Requirements, SR）
- 定义：开发人员需要实现什么？
- 关注点：系统行为（System Behavior）和交互。这是最底层的详细需求，直接指导编码。
- 转化难点：从 UR 到 SR 的转化需要创造性的分析与建模。用户只知道「我要结账」（UR），系统分析师需要将其拆解为「系统校验 ID」、「系统查询价格」、「系统计算总额」、「系统更新库存」等一系列微小的系统行为（SR）。

实践案例：华为云 DevCloud 的需求分层

华为云在实践中将需求管理分为四个层级，完美对应了上述理论：

Epic（史诗）：对应业务需求。粒度最大，通常是公司的战略举措，需跨越数月开发。（如：凤凰商城云化改造）
Feature（特性）：对应用户所感知的模块。通常作为发布说明的一部分。（如：会员积分体系）
Story（故事）：对应用户需求。从用户角度描述的详细功能，需在一个迭代内完成。（如：作为管理员，我可以设置积分规则）。
Task（任务）：开发者的具体工作项。

需求的类型：功能与非功能

根据 IEEE 标准，软件需求可以被精细地分类。理解这些分类有助于避免「遗漏需求」。

功能需求（Functional Requirements）：- 地位：软件产生价值的基础，占比通常超过 90%。
- 核心：它是价值主张的直接体现。
性能需求（Performance Requirements）：涉及系统的「速度」和「容量」，必须量化。
- 速度：响应时间（如：查询必须在 10 秒内完成）。
- 容量：存储量（如：至少存储 10 万条记录）。
- 吞吐量：单位时间处理事务数（如：每分钟解析 5000 条语句）。
- 负载：并发用户数（如：支持 200 人同时在线）。
质量属性（Quality Attributes, QA）：也常被称为「非功能需求」（NFR）。它决定了系统「好用」的程度。依据 ISO/IEC 9126 模型，主要包括：
- 可靠性（Reliability）：不出错、不崩溃的能力。涉及故障检测、自动重连、数据恢复等。
- 可用性（Availability）：系统随时可用的概率（如：99.9% 可用）。
- 安全性（Security）：防止未授权访问。
- 可维护性（Maintainability）：修改和扩展的难易程度。
- 易用性（Usability）：用户学习和使用的成本（如：新员工培训 1 天即能上岗）。

隐形的质量需求

用户很少直接说「我需要高可维护性」，他们通常会用形容词或副词来表达，例如「快捷地操作」、「安全地支付」。需求工程师需要捕捉这些词汇，并将其转化为技术指标。

约束（Constraints）：约束是强制性的限制条件，它们限制了开发者的选择范围。这在当今互联网环境下尤为重要。
- 技术约束：必须使用特定的语言、数据库或运行环境。
- 商业规则：业务逻辑中的硬性规定（如：折扣不能超过 50%）。
- 法规与行业规范：这是当前互联网产品面临的最大挑战之一。

现实警示：合规性约束的代价

近年来，忽视「法规与社会规范」这一约束类需求，给巨头带来了惨痛教训：

反垄断约束：美团和阿里巴巴因「二选一」垄断行为分别被罚款 34 亿和 182 亿元。这警示我们，商业模式设计必须考虑《反垄断法》这一系统约束。
数据安全约束：滴滴因违法收集个人信息（相册、人脸、位置等）严重影响国家数据安全，被罚款 80.26 亿元并下架整改。这表明《个人信息保护法》是产品设计不可逾越的红线。
金融监管约束：蚂蚁集团因在支付、信贷等领域的合规问题被罚 71.23 亿元，并被迫重组，从激进的「金融创新」回归「金融基础设施」。

对外接口（External Interfaces）：系统与外部世界（硬件、其他软件、人）的交互点。
- UI 界面：人机交互设计。
- API 接口：如支付接口（支付宝/微信）、地图接口（高德/百度）。这往往体现了商业模式中的「重要合作」。

总结：优秀需求的特征

一个高质量的需求应当具备以下特性：

完备性：没有遗漏重要场景。
正确性：真实反映用户意图。
可行性：技术上可实现。
必要性：确实产生业务价值。
无歧义：不同的开发者读到同一句话，理解是一致的。
可验证：可以通过测试用例来证明需求是否被满足。

需求工程是连接「商业模式（画布）」与「代码实现」的中间件。商业模式画布提供了业务需求的来源（如为了优化成本结构而开发库存系统），而需求工程则通过用户需求和系统级需求的层层拆解，将商业愿景落地为可运行的软件。

在理解了需求的类型与层次后，我们面临的第一个实际挑战是**：如何从模糊的现实世界中提取出清晰的需求？** 这一过程被称为需求获取（Requirements Elicitation）。

需求获取不仅仅是「收集」，更是一个「挖掘、分析与达成共识」的过程。本章的核心在于引入目标模型（Goal Modeling），这是一种弥合「高层业务目标」与「底层系统功能」之间巨大鸿沟的关键方法论。

需求获取的非平凡性

需求获取之所以困难，是因为它发生在「人」与「人」之间，充满了认知偏差与沟通障碍。

核心困难

默认知识：
- 用户往往拥有丰富的背景知识，他们认为某些事情是「理所当然」的，因此不会显式地告诉分析师。
- 例子：会计人员不会告诉程序员「借贷必须平衡」，因为这是他们的常识，但对程序员来说却是必须编码的约束。
认知困境：
- 用户缺乏概括和综合能力，往往只能看到局部，难以描述整体需求。
- 用户往往不知道自己真正想要什么，直到他们看到做出来的产品（「我不知道我要什么，但我知道这不是我要的」）。
涉众参与问题：
- 越俎代庖：管理者代替实际操作者提需求，导致需求脱离一线实际。
- 缺乏参与：关键用户太忙、抵制新系统或根本找不到明确的用户代表。

获取的基本流程

需求获取是一个不稳定、含探索性的迭代过程：

明确范围：在达成一致的前景下，只关注范围内的内容。
多源头收集：
- 人：用户、用户替代源（如客服、销售）。
- 物：已有系统、竞品（友商）、规章制度。
从笔录到文档：将非结构化的访谈笔录转化为结构化的文档。

确定项目前景与范围：从问题出发

在深入细节之前，必须先回答「为什么要做这个项目」。这通常始于对问题的分析。

问题分析与业务需求

问题是现实世界中期望与现状的差距。业务需求（Business Requirement, BR）通常就是问题的反面。

收集并明确问题
- 通过背景资料和访谈，识别业务中的困难。
- 注意：要区分「表象」与「根因」。
发现深层问题
- 使用鱼骨图（Fishbone Diagram）等工具进行根因分析。
- 案例：
  - 表象问题：生产的废品太多。
  - 分析：是因为制造缺陷？运输损耗？还是订单本身就不准确？
  - 深层问题：销售订单信息不准确，导致生产了错误的规格。
定义业务需求（BR）
- 将明确后的问题转化为可量化的目标。
- 转化：问题「废品过多」 $\to$ BR「系统上线 3 个月内，因订单错误导致的废品率降低 50%」。

定义系统边界

确定了业务需求后，需要圈定系统边界（System Boundary）。

工具：用例图。
作用：用例图中的方框（边界）至关重要，它区分了哪些是系统要做的（框内），哪些是外部角色要做的（框外）。
来源：系统边界通常由多个具体的业务问题合并而来。

面向目标的方法

为什么要使用目标模型？

在传统的分析中，我们很容易从「业务需求」（BR1: 降低库存成本）直接跳跃到「系统功能」（Feature: 扫码入库）。这种跳跃缺乏逻辑支撑，容易导致：

功能缺失：遗漏了实现目标所需的其他支撑功能。
功能冗余：开发了对目标没有贡献的功能。

目标模型（Goal Model）提供了一种精化机制，将高层的战略目标一步步拆解为底层的系统行为。

目标的定义与类型

目标是系统被开发的目的。

硬目标：可以用技术手段明确确认是否满足的。通常用矩形表示。
- 例：ATM 机必须在 3 秒内响应。
软目标：难以精确衡量，通常涉及非功能需求。通常用云朵形状表示。
- 例：提高系统的易用性。

目标规格的基本模式（基于时序逻辑）

为了精确描述目标，我们引入时序逻辑的概念（理解含义即可，无需死记公式）：

实现： $P \Rightarrow \Diamond Q$ 。如果 P 发生，未来某一时刻 Q 必须为真。
保持： $P \Rightarrow \Box Q$ 。如果 P 发生，Q 必须始终为真。（持续状态，如安全性、库存一致性）
终止： $P \Rightarrow \Diamond \neg Q$ 。未来某一时刻 Q 必须停止。
避免： $P \Rightarrow \Box \neg Q$ 。Q 必须始终不发生。（如避免死锁）
优化：最大化或最小化某个指标。

目标模型的核心机制：精化与关系

这是目标模型最核心的部分，描述了目标是如何被拆解和关联的。

精化关系

将一个高层次目标 $G$ 拆解为一组低层次子目标 $\{G_1, G_2, ..., G_n\}$ 。

AND 精化：
- 逻辑：只有当所有子目标 $\{G_1, ... G_n\}$ 都完成时，父目标 $G$ 才算完成。
- 发现线索：
  - 场景拆分：收银员工作 = 销售场景 + 退货场景。
  - 步骤拆分：减少积压 = 发现积压（分析） + 处置积压（行动）。
  - 方面配合：降低人力成本 = 减少人员数量 + 提高单人效率。
OR 精化：
- 逻辑：任一子目标 $G_i$ 完成，父目标 $G$ 就算完成。
- 意义：代表了替代方案。
- 例：提高销售额 = 吸引更多新客户 OR 让老客户买更多。

graph TD
    G[高层目标：降低运营成本]
    G1[库存成本]
    G2[人力成本]
    G2a[减少人员]
    G2b[提高效率]
    
    G --> G1
    G --> G2
    G2 --AND--> G2a
    G2 --AND--> G2b
    
    %% 样式定义
    classDef rootNode fill:#7B68EE,stroke:#4B0082,stroke-width:3px,color:white,font-weight:bold
    classDef andNode fill:#FFA07A,stroke:#FF4500,stroke-width:2px,color:#333
    classDef leafNode fill:#98FB98,stroke:#32CD32,stroke-width:2px,color:#333
    
    %% 应用样式
    class G rootNode
    class G1,G2 andNode
    class G2a,G2b leafNode
    
    %% 连接线样式
    linkStyle default stroke:#666,stroke-width:2px
    linkStyle 2,3 stroke:#FF4500,stroke-width:2px,stroke-dasharray:5 5

阻碍关系

某个子目标的达成会导致高层目标失败，或者阻碍其他目标的达成。

作用：识别阻碍有助于我们发现反向需求或例外处理。
例：「发送加速指令」的目标可能会被「列车门未关」的状态阻碍。这提示我们需要一个「门未关则禁止加速」的约束（Avoid 目标）。

支持与冲突

支持：一个目标的实现有助于另一个目标的实现（正相关）。
冲突：一个目标的实现会削弱另一个目标（负相关）。
- 典型冲突：安全性 vs 便利性；功能丰富 vs 性能/成本。
- 处理：需要在冲突的目标之间进行权衡。

目标实现：从目标到主体

目标精化的最终目的是为了落地。

结束条件

目标精化何时停止？

当子目标被展开到单一事务时。
该事务可以被分配给一个明确的主体。

主体分配

主体可以是人，也可以是软件系统，或者是外部硬件。

Goal-Oriented $\to$ Agent-Oriented：
- 如果目标分配给系统 $\to$ 转化为系统功能/任务。
- 如果目标分配给人 $\to$ 转化为业务流程/角色职责。

映射到用例

当一个目标被精化到底层，并分配给「系统」和「用户」共同完成时，它就变成了一个用例。

目标：收银员快速处理销售。
主体：收银员（人）、POS 系统（系统）。
操作：扫描商品、计算总额、处理支付。

案例分析

连锁商店案例

背景：小店变连锁，手工记账导致排队严重、库存不清。
高层目标（BR）：
1. 减少商品积压与缺货（BR1）。
2. 提高销售效率（BR2）。
3. 降低运营成本（BR3）。
精化过程：
-「降低运营成本」 AND精化 为「降低库存成本」 +「降低人力成本」。
-「降低人力成本」 AND精化 为「减少人员」 +「提高效率」。
-「提高效率」最终落地为系统功能：「快速扫码销售」、「自动计算找零」。
冲突识别：
-「减少库存积压」可能与「保证热销品不缺货」在资金占用上存在冲突，需要平衡。

隆中对的目标模型

诸葛亮的《隆中对》是一个经典的战略目标规划案例：

终极目标：霸业可成，汉室可兴。
高层目标：
- 不可与曹操争锋。
- 不可图孙权。
- 跨有荆、益二州。
精化：
- 内：修政理。
- 外：结好孙权。
- 军事：待天下有变，两路出兵。
资源/约束：曹操拥百万之众，孙权国险民附。

总结：目标模型的价值

目标模型不仅仅是画图，它是一种思维工具。它强迫分析师：

多问 Why：向上追溯，确保每个功能都有业务价值。
多问 How：向下拆解，确保业务目标能落地为具体操作。
多问 Who：明确责任，是系统做还是人做。
多问 What if：思考阻碍和冲突，发现潜在风险。