需求获取概述

发表于 2025-12-25 Waline：阅读次数：本文字数： 2.4k 阅读时长 ≈ 9 分钟

需求获取是软件工程中将用户期望转化为明确需求的关键过程。这一过程的困难源于多方面因素：用户因背景和立场差异存在默认知识（tacit knowledge），难以清晰表达；用户常缺乏概括综合能力，陷入认知困境（latency）；此外还面临用户参与度问题——要么越俎代庖，要么缺乏参与、抵制甚至根本没有明确用户。

需求获取的基本流程要求首先在前景（vision）上达成一致，然后只面向范围（scope）内的内容进行获取。获取来源包括用户、用户替代源、已有系统和规章制度等。整个过程具有不稳定性，包含探索性内容，需要防止遗漏并判断何时结束。

确定项目前景与范围

为何需要前景与范围

现实世界是复杂的，不同角色从不同角度观察会看到不同内容。例如对于一张桌子，木匠关注结构、商人关注价格、考古学家关注年代。为确保项目涉众以符合项目需要的角度描述现实世界：

项目前景：所有涉众共同认同的出发点，用于理解和描述问题域及需求
项目范围：明确哪些事物和事件是描述的目标

问题分析流程

flowchart LR
    A[问题域涉众] --> B[获取问题]
    F[高层次问题背景资料] --> B
    
    B --> C{问题是否明确?}
    C -->|否| D[分析不明确问题]
    D --> E[发现深层问题]
    E --> G[明确一致的问题]
    
    C -->|是| G
    
    G --> H[发现业务需求]
    H --> I[确定高层解决方案及系统特性]
    
    style A fill:#e1f5fe,stroke:#01579b,stroke-width:2px
    style F fill:#f3e5f5,stroke:#4a148c,stroke-width:2px
    style B fill:#e8f5e8,stroke:#1b5e20,stroke-width:2px
    style C fill:#fff3e0,stroke:#e65100,stroke-width:2px
    style D fill:#ffebee,stroke:#c62828,stroke-width:2px
    style E fill:#fce4ec,stroke:#ad1457,stroke-width:2px
    style G fill:#e8f5e8,stroke:#1b5e20,stroke-width:2px
    style H fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
    style I fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    
    linkStyle default stroke:#666,stroke-width:2px

获取并明确问题

收集问题并达成共识：通过背景资料收集或涉众沟通（主要是面谈）
判断问题的明确性：问题应易于理解且指明解决方向
- 反例：「生产的废品过多」——原因不明，解决方向不清
分析不明确问题：发现问题背后的问题
- 首选直接咨询涉众
- 次选利用资料和业务数据分析
- 可借助竞品分析、数据驱动运营等方法

发现深层问题示例

当前问题「产生了太多废品」，使用鱼骨图列出可能原因：

- 不准确的销售订单
- 运输损耗
- 用户退货
- 制成品折旧
- 制造缺陷

通过数据分析发现「不准确的销售订单」贡献最大，从而将问题重新定义为更具体的形式。

发现业务需求

每个明确一致的问题都对应着涉众的期望目标，即业务需求（Business Requirement）。一般情况下，业务需求是问题的反面：

问题	业务需求
生产的废品过多（因销售订单不准确）	BR2：提高销售订单的准确性，在系统使用后 3 个月内，减少 50% 因此而产生的废品

业务需求的可验证性

业务目标必须具有可验证性，需要明确度量标准和时间范围。

系统边界与用例图

用例图描述外部角色在与解决方案交互中完成的任务与目标。边框代表系统边界，促使分析者思考系统的输入与输出。

flowchart TB
    subgraph 系统边界[连锁超市销售系统]
        direction LR
        UC1[📦 商品入库]
        UC2[🚚 商品出库]
        UC3[📊 库存分析]
        UC4[💰 销售处理]
        UC5[🔄 退货]
        UC6[🎯 促销策略制定]
    end

    %% 角色定义
    业务经理[👨‍💼 业务经理]
    总经理[👩‍💼 总经理]
    收银员[👩‍💻 收银员]

    %% 关联关系
    业务经理 --> UC1
    业务经理 --> UC2
    总经理 --> UC3
    总经理 --> UC6
    收银员 --> UC4
    收银员 --> UC5

    %% 样式定义
    classDef actor fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:#01579b
    classDef useCase fill:#f3e5f5,stroke:#4a148c,stroke-width:2px,color:#4a148c
    classDef systemBoundary fill:#f1f8e9,stroke:#33691e,stroke-width:3px,dashed
    
    class 业务经理,总经理,收银员 actor
    class UC1,UC2,UC3,UC4,UC5,UC6 useCase
    class 系统边界 systemBoundary
    
    %% 标题
    linkStyle default stroke:#7b1fa2,stroke-width:2px

然而，从初始业务需求直接获取系统特性是困难的。例如面对以下业务需求：

BR1：商品积压、缺货和报废减少 50%
BR2：销售人员工作效率提高 50%
BR3：店铺运营成本降低 15%
BR4：销售额度提高 20%

如何系统性地分析并获取系统特性？这需要目标模型的支撑。

目标分析与面向目标的方法

为何需要目标

传统的问题分析（寻找问题背后的问题）缺乏方法学支撑，容易遗漏重要内容。面向目标的方法通过严格定义的「目标」来确定项目范围，提供：

方法学支持——目标模型的建立与使用
对项目涉众的深度理解
对传统实体和活动分析的重要补充

目标的定义

目标

目标（Goal）是系统被开发的目的，具有明确的定义方式，包括名称、类型、关注点、定义（正式与非正式）、优先级、主体、拥有者等属性。

目标可基于一阶谓词逻辑与时序逻辑进行形式化定义。例如：

Goal: Maintain[DoorsClosedBetweenStations]
类型：SafetyGoal
关注：Train, Station
非正式定义：当列车在两个站点间运动时，列车的门必须保持关闭
正式定义：∀tr:Train, s:Station · At(tr, s) ∧ At(tr, Next(s)) ⇒ tr.doorState = "closed"

目标规格的基本模式

模式	形式化表示	含义
实现（Achieve）	P ⇒ ◊Q	如果将来某一时刻 Q 为真，则目标实现
终止（Cease）	P ⇒ ◊¬Q	如果将来某一时刻 Q 为假，则目标实现
保持（Maintain）	P ⇒ □Q	将来任一时刻 Q 都为真，则目标实现
避免（Avoid）	P ⇒ □¬Q	将来任一时刻 Q 都为假，则目标实现
优化（Optimize）	Maximize/Minimize	最大化或最小化目标函数

常用时序逻辑操作符：

操作符	含义
○Q	下一个状态中 Q 必须为真
◊Q	Q 终将在未来某个时间点为真
□Q	在所有后续路径中 Q 必须始终为真
P U Q	P 必须一直为真直到 Q 为假

目标类型

硬目标（矩形表示）：能用技术手段确认是否满足，具体可验证
软目标（云朵表示）：难以用技术手段精确确认，较为抽象

按层次划分：

高层次目标：战略性、全局性、业务相关，如「增加 50% 的传输能力」
低层次目标：技术性、局部性、产品设计相关，如「加速器每 3 秒发出一次命令」

目标模型的关系

高层次目标 G 可精化为低层次目标 {G₁, G₂, …, Gₙ}：

AND 精化：所有子目标的完成有助于（或直接保证）目标 G 的完成，子目标之间是互补的。

发现 AND 精化的场景：

同一目标有不同场景（每个 Gᵢ 代表一个典型场景）
完成目标有连续过程（每个 Gᵢ 代表一个状态）
完成目标需要多方面紧密配合
目标有不同质量环境及表现

OR 精化：任一子目标 Gᵢ 都是 G 的替代方案，子目标之间是互相替代的。

发现 OR 精化：存在多种可以相互替代的「候选办法」。

阻碍关系（Obstruction）

如果子目标 O 的达成会使得高层目标 G 失败（O ⊨ ¬G），则 O 与 G 之间是阻碍关系。阻碍关系本质上是一种反向精化，阻碍目标也可继续精化。

阻碍目标的价值

反向的目标往往更易精化，有助于发现潜在风险和约束。

支持与冲突关系（Support/Conflict）

Support：一个目标对其他目标有促进作用（可处理为 OR 精化）
Conflict：一个目标的实现对其他目标有阻碍作用

案例分析：连锁商店销售系统

背景

某连锁商店面临三个主要问题：

顾客量增长，手工作业销售迟缓，排队严重导致客源流失
商品品种增多，无法准确掌握库存，积压、缺货和报废现象上升
竞争加大，需要降低成本、吸引顾客、保持盈利

业务需求

BR1：系统使用 6 个月后，商品积压、缺货和报废减少 50%
BR2：系统使用 3 个月后，销售人员工作效率提高 50%
BR3：系统使用 6 个月后，店铺运营成本降低 15%（范围：人力成本和库存成本）
BR4：系统使用 6 个月后，销售额度提高 20%（最好 40%，最可能 20%，最坏 10%）

高层目标模型

flowchart TB
    %% 样式定义
    classDef goal fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#0d47a1
    classDef subgoal fill:#bbdefb,stroke:#1565c0,stroke-width:1.5px,color:#0d47a1
    
    %% 高层目标模型
    G1[提高销售额]:::goal
    G2[减少缺货、积压与报废]:::goal
    G3[提高销售工作效率]:::goal
    G4[降低运营成本]:::goal
    G4a[人力成本]:::subgoal
    G4b[库存成本]:::subgoal
    
    G4 --> G4a
    G4 --> G4b

目标精化示例

场景精化（AND）：收银员工作有销售和退货两个场景

flowchart TB
    %% 样式定义
    classDef main fill:#e8f5e8,stroke:#2e7d32,stroke-width:2px,color:#1b5e20
    classDef sub fill:#c8e6c9,stroke:#388e3c,stroke-width:1.5px,color:#1b5e20
    
    %% 场景精化（AND）
    G[Max 收银员工作效率]:::main
    G1[Max 销售处理效率]:::sub
    G2[Max 退货处理效率]:::sub
    
    G -->|AND| G1
    G -->|AND| G2

过程精化（AND）：减少积压缺货有多个步骤

flowchart TB
    %% 样式定义
    classDef main fill:#fff3e0,stroke:#ef6c00,stroke-width:2px,color:#e65100
    classDef sub fill:#ffe0b2,stroke:#f57c00,stroke-width:1.5px,color:#e65100
    
    %% 过程精化（AND）
    G[Achieve 减少缺货、积压与报废]:::main
    G1[Maintain 库存数据一致]:::sub
    G2[Achieve 预测缺货、积压与报废现象]:::sub
    G3[Achieve 提前处置积压与报废]:::sub
    G4[Achieve 提前处置缺货商品]:::sub
    
    G -->|AND| G1
    G -->|AND| G2
    G -->|AND| G3
    G -->|AND| G4

替代方案精化（OR）：提高销售额的不同途径

flowchart TB
    %% 样式定义
    classDef main fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#4a148c
    classDef sub fill:#e1bee7,stroke:#8e24aa,stroke-width:1.5px,color:#4a148c
    
    %% 替代方案精化（OR）
    G[Achieve 提高销售额]:::main
    G1[Achieve 吸引更多顾客]:::sub
    G2[Achieve 销售更多商品]:::sub
    
    G -->|OR| G1
    G -->|OR| G2

完整目标模型

flowchart LR
    %% 样式定义
    classDef sales fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#0d47a1
    classDef inventory fill:#e8f5e8,stroke:#2e7d32,stroke-width:2px,color:#1b5e20
    classDef cost fill:#fff3e0,stroke:#ef6c00,stroke-width:2px,color:#e65100
    classDef conflict fill:#ffebee,stroke:#c62828,stroke-width:3px,color:#b71c1c
    classDef support fill:#f3e5f5,stroke:#7b1fa2,stroke-width:3px,color:#4a148c
    
    %% 销售额模块
    subgraph SG1[销售额]
        direction LR
        A1[Achieve 提高销售额]:::sales
        A2[Achieve 吸引更多顾客]:::sales
        A3[Achieve 销售更多商品]:::sales
        A4[Achieve 吸引新顾客]:::sales
        A5[Avoid 顾客流失]:::sales
        
        A1 -->|OR| A2
        A1 -->|OR| A3
        A2 --> A4
        A2 --> A5
    end
    
    %% 库存管理模块
    subgraph SG2[库存]
        direction LR
        B1[Achieve 减少缺货、积压与报废]:::inventory
        B2[Maintain 库存数据一致]:::inventory
        B3[Achieve 预测缺货、积压与报废现象]:::inventory
        B4[Achieve 提前处置积压与报废]:::inventory
        B5[Achieve 提前处置缺货商品]:::inventory
        
        B1 -->|AND| B2
        B1 -->|AND| B3
        B1 -->|AND| B4
        B1 -->|AND| B5
    end
    
    %% 成本控制模块
    subgraph SG3[成本]
        direction LR
        C1[Achieve 降低运营成本]:::cost
        C2[Achieve 降低人力成本]:::cost
        C3[Achieve 降低库存成本]:::cost
        C4[Achieve 减少人员]:::cost
        C5[Achieve 提高人员工作效率]:::cost
        
        C1 -->|AND| C2
        C1 -->|AND| C3
        C2 --> C4
        C2 --> C5
    end
    
    %% 跨模块关系
    C4 -.->|Conflict| A5:::conflict
    C3 -.->|Support| B1:::support

冲突识别「减少人员」与「避免顾客流失」之间存在冲突关系——人员减少可能导致服务质量下降，进而造成顾客流失。

目标精化的结束条件

目标精化应在子目标展开到单一事务时终止：

主体与系统的一次协作活动（或一系列要求全部成功的活动）
这些单一事务能够增加业务价值
单一事务可进一步展开为场景

精化过程中需识别目标隐含的：

假设、依赖与约束：商业规则、场景限定、市场环境假设、资源依赖等
质量属性：性能、安全性、可用性等非功能需求

目标实现

目标实现包含两个关键步骤：

将底层目标分配给主体（人 + 系统）
- 越是抽象、粗粒度的目标，参与的主体越多。当目标被充分精化到只包含系统的明确功能且主体只有环境中的一个对象时，可以建立用例图联系。
设计实现底层目标的操作（任务/场景）

flowchart TB
    %% 样式定义
    classDef goal fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#1565c0
    classDef actor fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#4a148c
    classDef operation fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#1b5e20
    classDef linkDefault stroke:#666,stroke-width:1.5px,stroke-dasharray:0
    classDef linkDashed stroke:#666,stroke-width:1.5px,stroke-dasharray:5 5

    %% 节点定义
    subgraph 目标
        G1[Maintain 库存数据一致]
        G2[Achieve 预测缺货、积压与报废现象]
        G3[Achieve 提前处置积压与报废]
        G4[Achieve 提前处置缺货商品]
    end
  
    subgraph 主体
        A1[总经理]
        A2[业务经理]
        A3[收银员]
        A4[销售系统]
    end
  
    subgraph 操作
        O1[库存分析]
        O2[制定促销策略]
        O3[商品入库]
        O4[商品出库]
        O5[销售处理]
        O6[退货处理]
    end

    %% 应用样式
    class G1,G2,G3,G4 goal
    class A1,A2,A3,A4 actor
    class O1,O2,O3,O4,O5,O6 operation

    %% 连接关系
    G1 -.-> A3
    G1 -.-> A4
    G2 -.-> A1
    G2 -.-> A4
    G3 -.-> A1
    G4 -.-> A2
    G4 -.-> A4
  
    A1 ==> O1
    A1 ==> O2
    A2 ==> O3
    A2 ==> O4
    A3 ==> O5
    A3 ==> O6

    %% 样式类定义（用于连接线）
    linkStyle 0,1,2,3,4,5,6 stroke:#1976d2,stroke-dasharray:5 5
    linkStyle 7,8,9,10,11,12 stroke:#7b1fa2,stroke-width:2px

小结

面向目标的方法为需求获取提供了系统化的分析框架：

从问题到业务需求：明确问题，发现问题背后的问题，将问题转化为可验证的业务需求
建立目标模型：通过 AND/OR 精化、阻碍关系、支持/冲突关系构建层次化的目标结构
目标实现：将底层目标分配给主体，设计实现操作，最终形成用例图

这一方法确保了需求获取的完整性和系统性，避免了传统方法容易遗漏重要内容的问题。

确定项目前景与范围

为何需要前景与范围

问题分析流程

获取并明确问题

发现业务需求

系统边界与用例图

目标分析与面向目标的方法

为何需要目标

目标的定义

目标规格的基本模式

目标类型

目标模型的关系

精化关系（Refinement）

阻碍关系（Obstruction）

支持与冲突关系（Support/Conflict）

案例分析：连锁商店销售系统

背景

业务需求

高层目标模型

目标精化示例

完整目标模型

目标精化的结束条件

目标实现

小结