1. 背景
软件需求是一个沟通的过程
一个项目的成功，依赖于很多不同的信息，这些信息来自各自不同的人员：
- 一方是客户和用户，有时还有分析人员、领域专家和其他从业务或组织视角来审视软件的人
- 另一方是技术团队
一旦任何一方在沟通中把持绝对地位，项目就会遭受损失。
- 如果业务方把持绝对地位，他们就会关注软件功能和交付日期，却很少关注开发人员是否能够同时满足这两个目标，或者开发人员是否确切了解需求。
- 如果是开发人员把持绝对地位，技术术语就会代替业务语言，从而导致开发人员无法倾听业务方的实际需求。
需求的协同工作方法
我们需要一种需求协同工作的方法，让双方都不占绝对主导地位，共同面对感情用事和办公室政治化的资源分配问题。
如果资源分配问题完全落在一方，项目必定会失败。
- 如果只让开发人员来承担这些问题（他们通常被告知“我不关心你们怎么做，但请你们在6月份之前完成”），他们可能会牺牲质量来换取额外的特性，也可能只部分实现一个特性，或者自行做出一些该在有客户和用户参与的情况下才能做出的决定。
- 如果只是客户和用户承担资源分配的责任，那么我们会通常在项目开始阶段看到一系列漫长的讨论，项目中的特性逐渐减少。之后，在最终发布版本的时候，只剩下很少的功能，甚至少于被减少的功能。
如何规避风险
软件开发类项目本身是很难预先评估的，中间有很多因素能决定最终项目的结果和质量，这是软件开发本身的特点。那么我们应该如何来做？如何来更好的规避风险？
基本原则：
- 不要在项目开始阶段就做一套完善的、包罗万象的决策
- 把各个决策分散项目过程中
因此，我们需要有一个获取信息的过程，越早越好，越频繁越好。