收集需求是什么
收集需求通过访谈、工作坊、原型、观察等方式获取业务需要，最终形成需求文件与需求跟踪矩阵。它的产出不只是清单，而是可验证的需求条目：每条需求都要有来源、优先级与验收准则，否则后续的范围定义与验收都会失去判据。
基本信息
| 所属过程组 | 规划（5.2 收集需求） |
|---|---|
| 主要输入 | 章程、干系人登记册、商业论证、假设日志 |
| 主要输出 | 需求文件、需求跟踪矩阵 |
| 需求分类 | 业务需求、干系人需求、解决方案需求、过渡需求与质量需求 |
典型使用场景
- 项目早期：与业务方澄清目标与成功判据
- 界面与流程确认：用原型把模糊描述变成可讨论的具体方案
- 跨部门共识：用工作坊暴露冲突并现场收敛
- 合规需求梳理：把监管与审计要求转成可验收条目
- 变更评估：新需求与既有需求做优先级与依赖比对
常用技术
| 技术 | 适用场景 | 注意点 |
|---|---|---|
| 访谈 | 关键干系人的深度需求 | 受访谈人视角限制，需交叉验证 |
| 工作坊 | 跨部门共识与冲突暴露 | 需要主持与议题管理 |
| 原型 | 界面与流程验证 | 避免把原型细节当成最终承诺 |
| 观察 | 挖掘未言明的实际流程 | 注意被观察者的行为偏差 |
| 问卷 | 大范围意见收集 | 问题设计直接决定结果质量 |
| 标杆对照 | 借鉴同业与外部的做法 | 需要说明可比性与适用条件 |
需求文件要素
需求文件要素
需求编号 | 需求描述 | 来源 | 优先级 | 验收准则 | 状态
分类：业务需求、干系人需求、解决方案需求（功能与非功能）
# 质量需求与过渡需求（上线迁移、培训等）同样要纳入
# 验收准则要可测试，否则需求无法在验收阶段被判定需求质量检查
| 检查项 | 要求 | 不合格的表现 |
|---|---|---|
| 是否可测试 | 能用明确判据验证 | 写成了模糊描述或口号 |
| 来源是否清楚 | 指明提出人与业务背景 | 来源不明，冲突时无法评判 |
| 优先级是否明确 | 有统一的分级标准 | 全部标为高优先级 |
| 是否可追溯 | 能对应到设计与测试用例 | 需求与实现之间断链 |
需求收集不覆盖隐性干系人（运维、安全、审计），他们的诉求会在验收与上线阶段以阻力的形式补回来。
需求跟踪矩阵是范围控制与验收的证据链：从需求到设计、开发、测试再到验收，每一环都能对上，范围蔓延就很难隐形发生。