需求收集是理解你想要构建什么以及为什么要构建它的过程。需求收集通常被视为开发软件应用，或开发如飞机、宇宙飞船、汽车这样的网络物理系统（其规格包含硬件和软件）的一部分。然而，它可以应用于任何产品或项目。
一、需求收集的三个主要子流程
需求收集过程中的关键部分可以分为三个交叠的子过程：需求获取、需求文档编写和需求确认。
需求获取：这是需求收集过程的首要步骤，通过与利益相关者进行沟通，了解他们对于产品或服务的需求和预期，形式包括：会议、访谈、问卷调查等。你应尽力考虑客户、他们的用户、你自己公司内部的利益相关者以及你的关键供应商的需求。
需求文档编写：将需求收集过程的输入内容组织成适合你的组织的任何格式。这种格式可能包括：
- 用户故事
- 功能分解
- 功能说明
这些将被收集在一个需求规范中，比如产品需求文档（PRD）或系统规范。这个规范的目的是让项目团队的所有成员都能查阅到这些故事和描述。
需求确认：是确认所记录的需求如实反映了利益相关者的需求和预期的过程。通常要从利益相关者那里得到反馈，以确保团队正确理解了他们的需求。
二、需求收集的重要性?
完善的需求收集流程除了可以明确我们的开发目标，其重要性还包括：
- 大大提高了客户和用户能得到他们想要的东西的可能性。利益相关者通常很难用言辞准确地描述他们需要的东西。通过需求收集过程，我们可以帮助他们更深入地挖掘和理解自身的需求。
- 减小了项目失败的风险。在许多项目失败的案例中，一个常见的问题就是”需求定义模糊”。
- 在开发前期发现并解决需求问题，可以降低整个项目的成本。需求表述模糊或者定义错误往往会导致返工问题。许多研究都表明，随着开发过程的推进，修正需求错误的成本会呈指数式增长。
三、需求收集中的挑战
需求收集不善也会导致项目失败，以下是收集需求时经常遇到的问题：
1.确定正确的利益相关者
在项目中，常常存在一些“隐藏”的利益相关者。除了明显的决策人员，也应包括那些与客户直接交互的角色，例如客户服务代表和维护工程师，他们实际上也是产品的使用者。
国外某公司的总监Jordan Hirsch指出：“每天使用一个系统，但从未参与系统的设计项目失败的关键因素之一”
2.理解利益相关者的真实需求
利益相关者可能并不了解自己的需求。他们可能无法将自己的需求完全表述出来，还有一些需求有待我们发掘。我们要尽可能提出更多试探性的问题，并对不同的回答进行对比。往往需要通过多轮“迭代”，才能最终达成共识。
3.管理变更
在需求收集过程中，我们可能会遗漏掉需要提问的问题，或者有些信息利益相关者忘记告诉我们。所以需求的优先级可能会发生变化，在开发过程中也会不断有问题需要解决。我们要制定出一个应对变更的计划，需要预留一些时间来解决新出现的问题，记录新需求以及预留时间进行额外的审查。
四、需求收集的六个步骤
需求收集包括六个步骤，其中三个已经在上文“子流程”里提及。这些步骤通常按顺序进行，但在实际操作中，可能需要重复或者反复“迭代”。因此，最好将其视为子流程而非严格的线性步骤。
完整需求收集六个步骤包括：
- 确定相关利益相关者
- 确立项目目标和目的
- 从利益相关者中提取需求
- 记录需求
- 确认需求
- 优先处理需求
1.确定相关利益相关者
根据项目的不同，我们需要在每个利益相关者群体中寻找合适的代表，可能包括如下群体：
- 客户利益相关者
- 决策者
- 用户
- 系统管理员
- 其他相关的客户部门
- 内部利益相关者
- 行政人员
- 工程团队
- 营销团队
- 销售团队
- 客户支持团队（可包括现场维护团队）
- 主要供应商
- 分销商和其他合作伙伴
也要寻找那些“隐形”的利益相关者。在正式开始需求收集之前，团队也可在早期会议中提出探索性问题。确保所有利益相关者群体都参与其中。理想情况下，要给每一个参与方提出自己观点、表达自己需求的机会。
2.明确项目目标
你希望通过这个新产品或项目达到什么目标？你的客户希望从产品中获得什么总体结果？你公司的业务目标是什么？为了实现这些目标和结果，你需要实现哪些可行的、可衡量的目标？
把它们写下来。清楚地陈述它们，并让你所有的利益相关者对它们签字。你的目标和目的将作为你决策的框架。
你写的每个需求都应该帮助满足项目目标并达成目标。如果没有，你应该放弃它，或者将它作为未来发布的候选者。
3.从利益相关者那里获取需求
需求获取是需求收集子流程的第一个，在实际操作中会有重叠且需要不断迭代。即使在敏捷开发中，在项目开发之前可能也需要经历几轮的需求收集、文档记录以及审查和确认。
需求收集的方式有很多种，可行的方法包括调查、问卷调查以及访谈。在后续的迭代中需要经常组织访谈和跟进会议。
在访谈中要积极倾听受访者。提出探索性问题，并做好笔记。访谈结束后，要整理笔记，并在需要时进一步跟进。
4.记录需求
我们需要将收集到的需求记录下来。可采用任何已经协商达成一致的格式，它们可以是产品需求文档（PRD），政府要求的系统需求规范说明，需求管理工具（如PingCode），电子表格、数据库或其他方便团队成员查看的数据存储形式。
重点是需求文档，它需要以下要求：
- 易于理解和浏览
- 所有的利益相关者都可以随时访问和查看
- 提供了对其他文档的可追溯性
- 使用标准化的格式和模版
5.确认需求
与所有利益相关者一起审查需求，确保需求准确地反映了预期的目标，并确保所有利益相关者对每一个需求都理解一致。如果发现表述模糊的地方，应及时调整。
如果条件允许，可以利用原型设计和测试来验证需求。使用原型制作工具，能够简单快速地制作出原型，我们利用这个模型来进行可行性、可用性和产品概念的测试。
让利益相关者对需求进行签字确认。在最后的审查阶段，整个规范说明也要签字确认。
6.需求优先级排序
大多数开发项目在途中都会遇到意想不到的挑战，会遇到意想不到的障碍。时间表可能会变化，优先级可能会改变。每个需求将影响你的版本的目标，所以进行优先处理非常关键。
许多产品经理通过给功能打上“必须有”、“迫切想要”和“有也很好”等标签来确定其优先级。这样做主要基于以下两个原因：
首先，项目时间有限。如果团队优先实现相对简单的需求，最后发现没有足够的时间来完成关键需求，就会影响产品的发布时间。
其次，需求在变化。随着项目开展，可能会出现新需求。这些新需求可能非常关键，需要优先处理。我们要权衡新需求在优先级顺序中的位置。否则，我们可能会优先处理相对不太重要的需求。
五、需求收集过程中常见的问题
1.想当然的去理解我们听到的内容
有时候，有些需求简单且宽泛，面对这些需求你需要警惕，不要想当然的以为自己已经完全理解利益相关者所要表达的意思，也不要以为所有利益相关者的表述方式都一样。
例如，像”网站应有博客”这样的需求陈述可能隐藏了很多潜在的假设。应仔细思考这样的需求陈述，并提出相应问题，例如：帖子将以何种方式展示？谁管理这些帖子？是否需要评论功能？是否需要对帖子进行分类或打上标签？等等。
通过提出这些问题并对收到的答案进行交叉核查，我们就可以得出一组更具体，并且可被验证的需求。
2.关注 HOW 而不是WHAT
需求可以分为两大类：一类是产品需要实现的功能需求，即产品需要做什么；另一类是对产品实现功能的方式和形式的约束，即非功能性需求。
在需求管理阶段，我们的重点应该更多地放在产品需要做什么，而不是如何去实现。换句话说，需求描述尽可能不要涉及其实现方式，例如应该使用哪一项新技术，偏好哪种工具，以及对产品的一些个人预设期待。总之，我们需要专注于利益相关者需要什么这个问题。
首先，我们要认真听取利益相关者的意见，然后收集、审查这些意见并提炼出需求。在完成这些步骤之后，再去分析使用哪些技术手段可以满足客户和利益相关者的真正需求。
3.未能充分与利益相关者沟通
在需求收集过程中，充分与利益相关者沟通至关重要。
首先，对每个利益相关者群体的需求都要深入了解。忽视这一点是需求管理失败的主要原因之一。
其次，保持项目透明度。每次访谈、开会或调查后，都要整理并共享笔记。现代需求管理工具，如PingCode，可将注释附加到需求上，保证需求的可追溯性。可帮助我们大幅提高工作效率，同时减轻审核工作量。
第三，给利益相关者充足的时间去审查需求。给他们提供反馈、表达异议，甚至捍卫自己的观点的空间。讨论越深入就越能帮助我们发现并修正需求中存在的问题，同时也有助于所有利益相关者就需求达成一致意见。
最后，确保所有利益相关者确认并签署需求。也要让利益相关者清楚签字确认意味着什么。
六、敏捷开发中的需求收集
敏捷开发的需求收集有什么不同？
首先，敏捷团队强调快速迭代。因此，敏捷的需求收集过程需满足开发人员对开发速度和迭代的要求。
透明度在敏捷开发中也十分关键。敏捷团队需要持续更新需求文档，要方便标注，且具有可追溯性。
所以传统的文档和电子表格对敏捷团队来说，并非理想的需求管理工具。静态的需求管理工具不方便更新和分享，无法保证每个团队成员都能够快速访问到最新的需求信息并保证对同样的内容有一致理解，这些工具也通常不具备内置的功能以方便添加注释或跟踪需求的变化。
在敏捷开发环境中，如PingCode这样的需求管理工具能够简化需求收集过程，在整个ALM中对需求进行实时管理，如需求的版本管理、需求的变更管理等。
