在范围层，我们从讨论战略层面的抽象问题——“我们为什么要开发这个产品？”——转而面对一个新的问题 ：“我们要开发的是什么？”（why——what）
建立功能规格说明书来描述文档本身，而用“需求”来描述文档的内容。

最用之不竭的需求源泉总是来自用户本身。但更多的时候，你的需求将来自与项目利益相关的同事——那些在企业中总想影响你的产品的人。
不管是哪种情况，去了解“人们在想什么”的最佳途径就是直接去询问他们。

记下来
无论这个项目有多么庞大或多么复杂，有几条膏泽适用于撰写任何类型的功能规格说明。

乐观(be positive)。描述这个系统将要做什么事情去防止不好的事情发生，而不是描述这个系统不应该做什么不好的事情。比如：
这个系统不允许用户购买没有风筝线的风筝。
替换成以下会更好：
如果用户想买一个没有线的风筝的话，这个系统应该引导用户用户到风筝线页面。

具体(be specific)。尽可能详细地解释清楚状况，这是我们能决定一个功能是否被实现的途径。
比如：
1.最受欢迎的视频要重点标注。
2.上一周被播放最多的视频要显示在列表的最前端。
第二句用具体的细节定义清楚了我们的目标

避免主观的语气（avoid subjective language）。这是另外一种使需求“保持明确”和“避免歧义”的途径——因而避免了误解的可能性。
比如：
这个网站的风格是时尚、闪耀的。
形容都过于主观，需要找到某种方式来明确说出应该达到的标准。
这个网站应该符合邮递员小张所期望的时尚。

带着“我们想要什么”、“我们的用户想要什么”的明确认识,我们才能弄清楚如何去满足这些战略目标。当你把用户需求和产品目标转变成产品应该提供给用户什么样的内容和功能时,战略就变成了范围。

用文档来定义产品需求，这件事很麻烦，但是你必须要做。这是由于以下两个原因：
1.这样你才知道你正在建设什么
2.这样你才知道你不需要建设什么