当把用户需求和产品目标转为产品应该给用户提供什么样的内容和功能的时候，战略层就上升到了范围层。
当你的产品各个阶段不断迭代更新，我们需要用文档定义产品需求，虽然很麻烦，但是及其必要。原因有二：
一：这样你才知道你在建设什么；
当我们详细记录产品建设的内容，每一个人都知道这个项目的终极目标，什么时候达到这个目标，产品不再是一个只停留在产品经理脑中的一个思维，而是变成团队每个成员都可以接受到的东西，人人参与进来。拥有一系列明确的要求，能让你把责任分配的更清晰，可以大大提高协作的效率。当了解了一个详细策划的完整范围之后，就可以看到各个相对独立、也不显著的要求之间的内在联系。
二：这样你才知道你不需要建设什么。
在实际项目中，许多需求听起来相当诱人，但是它们对于项目的战略目标并不是必须的，或者现阶段说实现起来并不合理，当这些需求出现时，可以用文档记录下来，可以为你提供一个评估这个想法的架构，帮助了解它们当初如何满足项目的目标。如果不能有意识的管理你的需求，将陷入可怕的"范围蠕动"，即雪球越滚越大，难以阻止它。每一个额外的需求看起来并没有增加太多工作量，但是当汇集在一块时候，整个项目将会膨胀，结束时间遥遥而无期。
范围层被"功能型产品"和"信息型产品"分为两个部分，在前者中我们需要考虑功能需求规格，在后者我们需要考虑的是内容，这属于编辑和营销推广的传统领域。
在软件开发中，范围层确定的是全部的功能需求或功能规格。在项目初期，表示需求，描述系统应该做什么；在项目末期，表示规格功能说明，描述系统真正完成了什么。其中，功能规格在功能需求后面撰写，并且加入具体的实施细节。
定义需求
需求主要分为两种，一种适用于整个产品，如品牌需求；另一种只适用于特殊的场景。大部分时候人们说到某种需求的时候，想到是产品必须拥有的某种特性的一句简单描述。最用之不竭的需求源泉总是来自用户本身，但是更多时候，需求却来自于项目利益相关的同事。汇集企业的各个部门成员或不同类型的用户代表进行头脑风暴会议，是一种打开设计者思路，让他们考虑以前从未想到的可能性的、非常有效的工具。我们也可以期望从竞争对手处得到一些启示，稍加改造找寻我们自己的需求。
功能规格说明
下面几条规则适用于撰写任何类型的规格说明：
乐观
描述这个系统将要去做什么去防止不好的情况发生，而不是描述这个系统不应该做什么不好的事情。
如"这个系统不允许用户购买没有风筝线的风筝"就不如"如果用户想买一个没有线的风筝，这个系统应该引导用户到风筝线页面"描述的好。
具体
尽可能的详细解释清楚情况，这是我们能决定一个功能是否能被实现的最佳途径。
避免主观语气
功能规格必须可验证，如果采用主观的语气就无法得到验证，如"这个APP应该符合大众的审美"。那么什么才是大众的审美呢？就无法得到验证。
确定需求优先级
收集潜在的需求并不困难，几乎每个人都可以说出“这个产品应该增加哪些特性”这样的想法，然而最棘手的部分是排列出哪些功能应该包含到你现在这个项目中去。在战略目标和需求之间，几乎没有一对一的简单关联。由于项目范围是建立在战略层的基础上的，因此我们应该去评估这些需求是否能满足我们的战略目标（无论是产品需求还是用户需求），除此之外我们还要确定第三种范围：实现这些需求的可行性有多大？有些特性因为技术上的局限而无法实现，而有的特性是因为实现需要很多资源去做，这超出了团队的能力范围，而有时候仅仅 是因为时间不够，这种情况下我们就可以把特性放在下一个版本迭代实现。很少有功能是独立存在的，当不可避免的导致了特性的冲突，我们要从公司的大战略范围得到一个平衡，这样才能得到一个连贯的统一的产品。
