范围层
用文档定义产品需求的原因
一、这样你才知道你正在建设什么
如果详细记录下你正在建设的内容，每一个人就会知道这个项目的目标是什么，什么时候将达到这个目标。
拥有一系列明确的要求，能让你把责任分配得更加清晰，这可以大大提高协作的效率。
二、这样你才知道你不需要建设什么
了解“你不需要做什么”，也就意味着知道哪些是你“不需要马上去做”的东西；
当前难以满足的需求，可以成为启动下一个版本的基础，这样就能形成一个不断循环的开发过程。
如果你不能有意识地管理你的要求，你将陷入可怕的“范围蠕变（scope creep）”中，（即“滚雪球”）
功能和内容
功能型产品，考虑的是功能规格（functional specifications），哪些应该被当成软件产品的“功能”以及相应的组合。
信息型产品，考虑的是内容，这属于编辑和营销推广的传统领域。
大部分时候，两个术语可以互换，有些人使用“功能需求规格”来表示他们的文档覆盖了包括以上两者的内容。
定义需求
表面需求：最显而易见的是人们讲述的、他们想要的东西。
根本需求：通过与用户探讨这些建议，你有时候可以得出能真正解决问题的、完全不同的需求。
潜在需求：是人们不知道他们是否需要的特性
功能规格说明
我们需要的不是文档有多厚或有多详细，而是要足够清楚和准确。
功能规格说明不需要包含产品的每一个细节——只需要包含在设计和开发过程中出现有可能混淆的功能定义。
功能规格说明不需要展望产品未来的理想化状态——只需要记录在创建这个产品时已经确定下来的决议。
规则
乐观
具体
避免主观的语气
内容需求
- 尽可能早地确定某个人来负责每一个内容元素也是非常重要的。
确定需求优先级
在战略目标和需求之间，几乎看不到一对一的简单关联。
有时一个需求可以满足多个战略目标。同样，一个战略目标也常常关系到多个不同的需求。
留意那些看上去可能需要改变战略的特性建议，它们在制定愿望文档期间并不明显。任何不符合当前项目的战略目标的特性建议，都要通过范围定义将其排除出去。
但是如果有那么一个特性，尽管它不在项目范围之内，也超越了任何一个的限制条件，但听起来仍像一个不错的想法，那么此时你可能需要重点审视某些战略目标。
