第四章 - 范围层：功能规格和内容需求
当你把用户需求和产品目标转变成产品应该提供给用户什么样的内容和功能时，战略就变成了范围。
【范围层的定义】
定义项目范围则同时在做两件事：一个有价值的过程，以及能产生有价值的产品；
过程的价值在于：当整个事情处在假设阶段的时候，它能迫使你去考虑潜在的冲突和产品中一些粗略的点；
产品的价值在于：被定义的这个产品给了整个团队一个参考点，明确了这个项目中要完成的全部工作，它也提供了一门用于讨论这件事情的共同的语言；
用文档来定义产品需求的两个主要原因：
1、这样你才知道你正在建设什么：拥有一系列明确的要求，能让你把责任分配得更清晰；
2、这样你才知道你不需要建设什么：许多功能听上去诱人，但它们对于项目的战略目标并不是必需的；但可以把这些杰出的想法收集起来，找到一种适宜的方式，让它们符合你的长期规划，这才是真正的价值所在；
范围蠕变：每一个额外的要求看上去没有增加太多的工作量，但是当它们汇集在一起的时候，你的整个项目就会失去控制的膨胀，结束时间遥遥无期！
【功能和内容】
范围层被分为“功能型产品”和“信息型产品”两部分。
功能型产品：考虑的是功能需求规格——哪些应该被当成软件产品的“功能”以及相应的组合；
信息型产品：考虑的是内容——属于编辑和营销推广的传统领域。
范围层确定的是全部的功能需求或功能规格。有些企业用这些术语来表示两种不同的文档。
项目初期：表示需求，描述系统应该做什么；
项目末期：表示功能规格说明，描述系统真正完成了什么；
【定义需求】
大部分时候，当人们说到某种需求的时候，他们想的是产品必须拥有的、某种特性的一句简短描述。
需求的三个主要类别：
1、人们讲述的、他们想要的东西；
2、有时候人们口中说出来的、所期望的特性其实不是他们想要的，需要通过与用户探讨，得出真正解决问题的、完全不同的需求；
3、人们不知道他们是否需要的特性；
可以通过创建虚拟人物来帮我们更好的理解用户需求，可以创建一个“场景”，想象我们的用户将会经历什么样的过程，就可以找到能帮助他顺利完成这个过程的潜在需求。一个场景就是一个简短的故事，简单的描述了一个人物角色会如何完成这些用户需求。
【功能规格说明】
文档不能解决问题，但定义可以。我们需要的不是文档有多厚或有多详细，而是要足够清楚和准确。应该让文档撰写的过程变得快速简便，不要把它变成产品开发过程中的一个独立的项目。
撰写任何类型的功能规格说明的几条规则：
1、乐观：描述这个系统将要做什么事情去“防止”不好的事情发生，而不是描述这个系统“不应该”做什么不好的事情；
2、具体：尽可能详细地解释清楚状况；
3、避免主观语气：使需求“保持明确”和“避免歧义”，避免误解；
【内容需求】
不要混淆某段内容的格式和它的目的。比如“FAQ ( Frequently Asked Questions：常见问题 )”：这个词指的是内容格式：一系列简短的问题和回答。但一个FAQ真正的目的在于：它可以随时提供用户普遍需要的信息。
内容需求应该提供每一个特性规模的大致预估：文本的字数、图片的像素大小、下载的文件字节、PDF或音频文件等相对独立元素的大小等。
定义每一个内容特性的“更新频率”：介于你的用户的期望值和有效资源之间的一个合理的中间值。
