带着“我们想要什么”、“我们的用户想要什么”的明确认识，我们才能弄清楚如何去满足这些战略目标。当你把产品目标和用户需求转变为产品应该提供给用户什么样的功能和内容时，战略就变成了范围。
定义项目范围就是同时在做两件事：这是一个有价值的过程，同时能产生有价值的产品。
过程的价值在于，当整个事情还在假设阶段的时候。它能迫使你去考虑潜在的冲突和产品中一些粗略的点，我们能确定现在能解决哪些问题，哪些则需要再迟一点才能解决。
产品的价值在于，被定义的这个产品给了整个团队一个参考点，明确了这个项目中要完成的全部工作，它也提供了一门用于讨论这件事情的共同语言。定义好你的需求能保证设计过程中不会出现模棱两可的情况。
需要有一个固定的项目流程，阶段性的日常安排和里程碑。要明确项目的范围和时间要求。
用文档来定义需求的原因：
这样你才知道你正在建设什么：每个人就会知道这个项目的目标是什么，什么时候将会达到这个目标。
这样你才知道你不需要建设什么：知道并记录哪些是不需要马上去做的东西。确定具体的、系统的发展要求，并将任何不符合这些要求的想法作为潜在的未来功能囤积起来。当前难以满足的需求，可以成为启动下一个版本的基础，这样就能形成一个不断循环的开发过程。
避免陷入范围蠕变（scope creep）：像滚雪球一样，每一个额外的功能并没有增加太多的工作量，但当它们汇集到一起时，整个项目就会失去控制地膨胀。
在范围层，我们从战略层所考虑的“我们为什么要开发这个产品”，转向“我们要开发的是什么”。
范围层被分为两个部分，功能需求规格——哪些应该被当成软件产品的功能及相应的组合，和内容需求——这属于编辑和营销推广的传统领域。在这里，我们使用“特性（feature）”来同时表示软件的功能和所提供的内容，内容与功能往往是同时存在于一个网站的。
需求可以分为三个主要类别：
人们讲述的、他们想要的东西。这中间有一部分是非常清晰的好想法，会通过各种途径体现在最终产品上。
有时候人们说出来的所希望的特性其实并不是他们想要的，只是他们在遇到某些困难时想到的并不可行或者治标不治本的方法。通过与用户探讨这些建议，你有时可以得出能真正解决问题的、完全不同的需求。
第三种类型是人们不知道他是否需要的特性。
让不同职位类别的人一起谈论某个产品，听取不同角度出发考虑的对于产品的观点，并给予反馈。可以鼓励人们多角度全方位地思考开发中的产品遇到的问题以及解决办法。
在决定功能需求的时候，可以使用场景（scenarios）,把虚拟人物放到一个简短的故事中，简单描述了一个人物角色会如何完成这些用户需求，通过“想象我们的用户将会经历什么样的过程”，我们就可以找到能帮助他顺利完成这个过程的潜在需求。
可以尝试从竞争对手或者非潜在的竞争对手身上得到一些启示。例如借鉴游戏平台的社交群组机制建立自己（可能是非游戏产品）需要的类似的机制。
我们需要的不是功能规格说明文档有多厚有多详细，而是要足够清楚和准确。它不需要包含产品的每一个细节，只需要包含在设计或开发过程中有可能出现混淆的功能定义。同时功能规格说明也不需要展望产品未来的理想化状态，只需要记录在创建这个产品时已经确定下来的决议。
无论这个项目有多么庞大多么复杂，有几条规则适用于撰写任何类型的功能规格说明。
乐观（be positive）：描述这个系统将要做什么事情去防止不好的情况发生，而不是描述这个系统不应该做什么。例如，用“如果用户想购买A，系统应该引导用户去购买B的页面”来替换“系统不允许用户购买A”。
具体（be specific）：尽可能详细地解释清楚状况，这是我们能决定一个功能是否被实现的最佳途径。例如，用“上一周被播放最多的视频要显示在列表的最前端”替换“最受欢迎的视频要重点标注”。
避免主观的语气（avoid subjective language）：使需求保持明确，避免歧义。例如避免使用类似语句“这个网站的风格应该是时尚的”。功能规格必须可验证，例如“网站的外观应该符合企业的品牌指南文档”。
定义出所有不同类型的内容（如文字、视频、图片、音频等），可以帮助你确定需要哪些资源来制作这些内容（或它们是否应该被提供）。
内容需求应该提供每一个特性规模的大致预估：文本的字数、图片的像素、下载的文件字节等等。事先知道这些元素的大小，有利于内容的管理。
尽可能早地确定某个人来负责建设和维护某一个内容元素；定义每一个内容特性的更新频率，它是介于你的用户期望值和有效资源之间的一个合理的中间值。
对已有大量内容的项目而言，很多关于内容的信息都记录在一个用户清单（content inventory）中，这样团队中的每个人才能确切地知道他们设计用户体验需要做哪些工作。
战略目标与需求并不总是简单的一对一关系。有时一个需求可以满足多个战略目标，同样，一个战略目标也常常关联到多个不同的需求。
因为项目范围是建立在战略层的基础上的，因此我们应该去评估这些需求能否满足我们的战略目标。任何不符合当前项目的战略目标的特性建议，都要通过范围定义将其排除。但是如果有那么一个范围之外的特性听起来不错，你可能需要重新审视某些战略目标。
很少有功能是独立存在的，审视需求的时候需要统一考虑；如果时间有限，可以把这个特性放到下一个版本里；有些特性技术上不可行。
关注战略目标，而不是各种实现这些目标的手段，以此为依据制定需求的优先级。
——著作权归原作者所有——
