---
title: "Requirements Gathering"
type: concept
tags: [Business-Analysis, Requirements, Agile]
sources: [public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]
last_updated: 2026-05-11
---

## Definition

需求收集（Requirements Gathering）是将业务需求转化为可执行、可追踪的技术需求的过程。核心方法是将敏捷用户故事与结构化元数据相结合，为需求捕获增加严谨性。

## User Story + Metadata Approach

纯用户故事（As a... I want... So that...）虽然能捕获 what（做什么）、who（谁来做）和 why（为什么），但缺乏以下关键维度：

| 元数据维度 | 说明 |
|-----------|------|
| **版本**（Version） | 需求的历史变更记录 |
| **依赖**（Dependencies） | 与其他需求的关联关系 |
| **可追溯性**（Traceability） | 从 Epic → Feature → Story 的完整链路 |
| **时间**（Scheduling） | 计划交付时间 |
| **验收标准**（Acceptance Criteria） | 如何判断需求完成 |
| **分类**（Categorization） | 业务需求 / 技术需求 / 功能需求 |

## Excel Template Example

课程演示了车库业务（Garage Business）的需求管理 Excel 表，包含：
- User Story 描述
- 版本号
- 依赖关系
- 可追溯性链接
- 计划时间
- 验收标准
- 分类标签（业务 / 技术 / 功能）

## Relationship to SAFe

在 [[SAFe]]（Scaled Agile Framework）中，需求层次为：
- **Epic**（史诗）→ 大型业务价值单元
- **Feature**（功能）→ 可独立交付的业务功能
- **Capability**（能力）→ 跨团队的业务能力
- **User Story**（用户故事）→ 具体用户视角的需求
- **Non-Functional Requirements**（非功能需求）→ 性能、安全、可用性等

## Relationship to Other Concepts

- [[INVEST]]：INVEST 原则用于检查用户故事质量
- [[BOSCARD]]：BOSCARD 定义的范围指导需求收集的方向
- [[Business-Analysis]]：需求收集是业务分析的核心活动之一
- [[Stakeholder-Wheel]]：干系人识别是需求收集的前提

## Key Quote

用户故事本身缺少严谨性，结合元数据后才能成为可管理的需求资产。

## Aliases
- 需求收集
- 需求管理
- User Story + Metadata