UCD - Chapter 4

范围层

用文档定义产品需求的原因

一、这样你才知道你正在建设什么

• 如果详细记录下你正在建设的内容，每一个人就会知道这个项目的目标是什么，什么时候将达到这个目标。

• 拥有一系列明确的要求，能让你把责任分配得更加清晰，这可以大大提高协作的效率。

二、这样你才知道你不需要建设什么

• 了解“你不需要做什么”，也就意味着知道哪些是你“不需要马上去做”的东西；

• 当前难以满足的需求，可以成为启动下一个版本的基础，这样就能形成一个不断循环的开发过程。

• 如果你不能有意识地管理你的要求，你将陷入可怕的“范围蠕变（scope creep）”中，（即“滚雪球”）

---

功能和内容

• 功能型产品，考虑的是功能规格（functional specifications），哪些应该被当成软件产品的“功能”以及相应的组合。

• 信息型产品，考虑的是内容，这属于编辑和营销推广的传统领域。

• 大部分时候，两个术语可以互换，有些人使用“功能需求规格”来表示他们的文档覆盖了包括以上两者的内容。

---

定义需求

• 表面需求：最显而易见的是人们讲述的、他们想要的东西。

• 根本需求：通过与用户探讨这些建议，你有时候可以得出能真正解决问题的、完全不同的需求。

• 潜在需求：是人们不知道他们是否需要的特性

---

功能规格说明

• 我们需要的不是文档有多厚或有多详细，而是要足够清楚和准确。

• 功能规格说明不需要包含产品的每一个细节——只需要包含在设计和开发过程中出现有可能混淆的功能定义。

• 功能规格说明不需要展望产品未来的理想化状态——只需要记录在创建这个产品时已经确定下来的决议。

规则

• 乐观

• 具体

• 避免主观的语气

---

内容需求

• 尽可能早地确定某个人来负责每一个内容元素也是非常重要的。

---

确定需求优先级

• 在战略目标和需求之间，几乎看不到一对一的简单关联。

• 有时一个需求可以满足多个战略目标。同样，一个战略目标也常常关系到多个不同的需求。

• 留意那些看上去可能需要改变战略的特性建议，它们在制定愿望文档期间并不明显。任何不符合当前项目的战略目标的特性建议，都要通过范围定义将其排除出去。

• 但是如果有那么一个特性，尽管它不在项目范围之内，也超越了任何一个的限制条件，但听起来仍像一个不错的想法，那么此时你可能需要重点审视某些战略目标。