当你把用户需求和产品目标转变成产品应该提供给用户什么样内容和功能时，战略就变成了范围。如果你不能有意识地管理你的要求，你将陷入可怕的“范围蠕变（scope creep）”中。内容需求常常伴随着功能的需求。现在，真正的内容常常是通过一个内容管理系统来进行管理。
定义需求
需求的详略程度常常取决于该项目的具体范围。如果该项目的目标是完成一个复杂的子系统，那么就需要有一个非常详细明确的需求，即使这个项目的范围相对于整个网站来讲非常小。相反地，一个大型项目，它的内容也许只是相似或相同性质的东西，那么需求只需要一般化就可以了。
不管你是从企业内部的管理者，还是直接从用户处获得的帮助，来定义的这些需求，这个过程中得到的需求将分成三个主要类别。首先，最显而易见的是人们讲述的、他们想要的东西。有时候当人们在某个过程或某个产品中遭遇到一些困难时，想象有某种解决办法可以缓解这一困难。通过与用户探讨这些建议，你有时候可以得出真正解决问题的、完全不同的需求。第三种类型的需求，是人们不知道他们是否需要的特性。
定义需求的方式：
（1）让一个工程师、一个客服人员、一个营销人员坐到一间会议室中谈论同一个产品。通过这种方式讨论出来的功能需求通常是得到如何去除某些障碍的方法。
（2）通过创建虚拟人物角色来帮助我们更好地理解用户需求。在决定功能需求的时候，我们把这些人物角色放到一个场景中。
（3）我们也期望从竞争对手处得到一些启示。即使不是产品的直接竞争对手，也能提供丰富的潜在需求。
功能规格说明
功能规格说明不需要包含产品的每一个细节——只需要包含在设计或开发过程中出现有可能混淆的功能定义。同时功能规格说明也不需要展望产品未来的理想化状态——只需要记录在创建这个产品时已经确定下来的决议。
适用于撰写任何类型的功能规格说明的规则：
（1）乐观：描述这个系统将要做什么事情去“防止”不好的情况发生，而不是描述这个系统“不应该”做什么不好的事情。
（2）具体：尽可能详细地解释清楚状况，这是我们能决定一个功能是否被实现的最佳途径。
（3）避免主观的语气：量化定义一些功能或者界定一系列的标准或指南文档。
内容需求
（1）内容需求应该提供每一个特性规模的大致预估：文本的字数、图片的像素大小、下载的文件字节、PDF或音频文件等相对独立元素的大小等
（2）尽可能早地确定某个人来负责每一个内容元素：日常维护
（3）定义每一个内容特性的“更新频率”：“更新频率”来自于你产品的战略目标，它是介于你的用户期望和有效资源之间的一个合理的中间值
（4）如果你的网站是为各种拥有相异用户服务的，搞清楚哪些用户想要哪种内容，能帮助你决定用什么方式来呈现这些内容
（5）对于那些已有大量内容的项目而言，整理一个现有网站中所有内容的清单，可以让团队中的每个人确切地知道，他们设计用户体验需要做哪些工作
确定需求优先级
在战略目标和需求之间，几乎看不到一对一的简单关联。有时，一个需求可以满足多个战略目标，同样，一个战略目标也常常关系到多个不同的需求。
评估需求是否能满足我们的战略目标（无论是网站目标还是用户需求），除了这两种目标，我们还要额外确定第三种范围：实现这些需求的可行性有多大？
有些特性可能会因为技术上的局限而无法实现。如果是因为时间有限，那你可以把这个特性放到下一个版本或项目里程中。如果是资源有限，则技术或企业的变化有时能减少资源的负担。
很少有功能是独立存在的。留意那些看上去有可能需要改变战略的特性建议。如果有那么一个特性，尽管它不在项目范围之内，也超越了任何一个的限制条件，但听起来仍然像一个不错的想法，那么此时你可能需要重点审视某些战略目标，你有可能是太早地进入了需求定义阶段。
如果你的战略计划或愿景文档在战略目标的范围内制定了一个清晰的优先级别顺序，那么这些优先级别应该是决定是否采纳人们所建议的相关特性的首要因素。
全文摘自《用户体验要素——以用户为中心的产品设计》（机械工业出版社）Jesse James Garrett 著
