定义项目范围：确认这是一个有价值的过程+同时能产生有价值的产品
1. Process 定义过程：先做什么，后做什么
考虑潜在的冲突和粗略的问题点
确定现在能解决哪些事儿，哪些必须要迟一些才能解决
Schedule 得有一个时间表
Working Flow 有一个工作流程、各部分的合作
Milestones 得有阶段性目标和阶段性成果
2. Product 定义产品 ：要做什么，不做什么
明确了项目要完成整个的全部工作
提供了一门用于讨论这件事的共同语言
“当我们所有的人都在一个办公室里工作时，几下每一件事都是很麻烦的—>没有人去定义需求”
于是：
你团队中的每一个人都有各自关于产品的想法，然后通过口口相传的方式传递出去，每个人的描述都略有不同。每个人都认为别人肩负着设计和开发产品关键环节的责任，但实际上这个人并不存在。
Scope Creep 一个雪球向前每滚一英寸，都会沾上更多的雪，直至冲到山下。
每一个额外的要求看上去并没有增加太多的工作量，但是当它们汇集到一起的时候，你的整个项目就会失去控制地膨胀，结束时间遥遥无期。
3. Functional Specifications
Feature 可以同时指功能/内容
文档不能解决问题，但定义可以。
程序员们不喜欢阅读长篇的功能说明，应该让撰写功能说明的过程变得快速简便，不要让它变成产品开发过程中的一个独立项目。
不需要包含产品的每个细节—>只需要包含在设计开发过程中可能混淆的功能定义。
不需要展望产品未来的理想化状态—>只需要记录在创建这个产品时已确定的决议。
4. Content Requirements
Content Management System, CMS
不要混淆内容的格式和它的目的。
内容元素的大小（图片像素、文本字数、音频大小）对UX决策影响很大。
尽早确定负责生成/更新内容的人（"如果不是我来维护的话，它就应该有XXX"）。
有效的内容需要日常维护，如果你没有考虑这个，那么随着时间的推移，它就无法满足用户需求。
所以，你应该指定内容负责人，并定义内容更新频率。
Content Inventory
需求大致划分3类：
A 人们讲述的、他们想要的东西
B 人们在某个过程/产品中遭遇的困难以及衍生出的建议
C 人们不知道他们是否需要的特性（突然想起的伟大构思）
Personas 人物角色
Scenarios 需求场景
需求的详略程度常常取决于该项目的具体范围。
一些需求适用于整个产品（品牌需求、技术需求），另一些只适用于特殊的特性。
当你把所有的时间都投入到维持现有产品时，你经常会忘掉哪些是真正的限制条件，而哪些是为了简化产品而曾经做过的选择。
需求优先级
最难的不是收集潜在需求或想法。难的是，你应该选择哪些是保留到你的产品中的，以及留下来这些哪些是重点去关注的。
实现的可能性：有些特性可能会因为技术上的局限无法实现，有时候仅仅是因为时间不够或是资源不足。
很少有功能是独立存在的，这不可避免地导致了特性之间的冲突，有些特性要和其他的一起权衡，才能得到一个连贯的、统一的产品。
任何不符合当前项目的战略目标的特性建议，都要通过范围定义将其排除出去。如果需求开起来很正确就反思一下你的战略，然后确定。
需求表述：
Be Positive 用积极、引导的语言去陈述
Be Specific 用操作性强的概念去定义功能特性
Avoid Subjective Language 有些概念和形容词是很主观的
