作者 | 毕小烦

引言：每个测试人员都知道保障需求质量非常重要，那到底为什么这么重要？又如何来保障需求质量呢？如果要回答好这些问题，必须得了解需求是什么，从哪里来到哪里去，只有搞清楚需求的来龙去脉和常见的问题，我们才能够制定出合理的保障措施。本文从测试的视角梳理了保障需求质量需要了解的方方面面。

如何保障需求质量？

关于这个问题，用 5 个字总结就是：防、评、控、量、改。

什么意思？

光看这 5 个字当然看不懂，我们也没办法用一句话就讲清楚如何保障需求质量，但为了能讲清楚，我们得知道需求的来龙去脉，知道需求是什么，从哪来，到哪去，过程中会经历什么，哪些会出现问题，哪些会隐藏风险，我们要重点关注什么。

正式开始。

1. 为何要保障需求质量？

我们所有人都在说保障需求质量非常重要，都在说我们的测试工作要提前，要左移，要在需求阶段进行严格的质量控制。

那大家有没有想过，为何需求质量这么重要？

一句话总结就是：需求是最有价值的质量控制点。

为什么这么说呢？

可以从三个方面来回答。

1. 需求是源头：没有需求研发都不用做了

首先是因为，需求是所有研发工作的源头，如果做一件事情，从源头就错了，那后果可想而知。

质量管理专家 林雪萍 老师对质量有个观点：

质量控制是环环相扣的体系，从上游的产品设计阶段，到中游的研发阶段，再到下游的发布阶段，每个环节创造的价值是在不断下降的。

对质量管理来说，价值最高的就是上游，产品的设计决定了产品的基本质量和可靠性水平。如果产品设计本身不过硬，那么，下游生产现场的工程师和工人再怎么努力、再具有工匠精神，顶多只能在车间有一些有限的补救，无法改变产品本身的先天缺陷。

这就好像拍一部电影，用了一流的演员、最棒的摄影师和最贵的服装化妆道具，但剧本本身漏洞百出、满是槽点，那么无论演员多么卖力演出，也很难扭转局面。

这个观点放到互联网产品研发中也同样适用。

从华为的 IPD 产品研发流程中也能看得比较清楚，需求从客户中来，通过需求管理，经过产品研发流程，最后再到客户中去，如此循环。如果对客户的需求理解错了，那后续的所有工作可能都是徒劳。

虽然软件产品到了下游可以进行需求变更，但变更带来的成本浪费是巨大的。

2. 需求是核心：所有工作都围绕需求展开

在研发过程中，需求属于核心位置，所有工作都围绕需求展开。
下面这张图展示了需求与其他工作过程的关系：

由此可见，需求的质量直接影响着其他工作的结果和质量。

所以需求是源头也是核心。

3. 需求是成本：需求是控制成本的关键

除此之外，需求也意味着成本。

《软件开发的 201 个原则》中有一条原则说：要立即修复需求规格说明中的错误。

为什么呢？

《探索需求》这本书里也给出了一组数据，说明了在需求阶段引入的错误，给后续阶段发现和修复所带来的成本情况。

如下所示：

发现错误的阶段	成本倍数
需求阶段	1
设计阶段	3~6
编码阶段	10
开发自测阶段	15 ~ 40
测试阶段	30 ~ 70
运营阶段	40 ~ 1000

所以，严格控制需求质量，保障高质量的产品需求，是控制整体研发成本最有效的手段，也是产品取得成功的关键。

2. 什么是需求？它从哪来到哪去？

2.1 需求定义

「需求」这个词在我们的日常工作中出现的频率特别高，像市场需求、业务需求、用户需求、技术需求等等，到处都是需求。

那到底什么是「需求」？

「需求」这个词拆开就是「需要」和「要求」，中文的解释是：由需要而产生的要求。

所以我们可以简单理解为，市场需求就是由市场需要而产生的要求。用户需求就是由用户需要而产生的要求。依此类推。

有个叫布莱恩·劳伦斯（Brian Lawrence）的职业规划顾问，对需求做了一个定义，他说：「需求是任何能驱动设计做出选择的东西。」

换句话说，你的商业设计，产品设计，服务设计等等都是由需求来驱动的，区别在于需求方（提出需求的人）不同。

图片

《软件需求》的作者说：「需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性，可以是一种对系统开发进程的约束。」

这里所说的需求当然是指「软件需求」了，它说需求是多种不同类型的信息的统称。这些信息包括了客户视角的外部系统行为（客户需求）以及来自开发人员视角的一些内部特征（功能需求）。包括了系统在特定条件下的行为和属性，使目标用户觉得系统易于甚至乐于上手（用户体验）等等。

所以，软件需求不是某个人或某个角色的诉求，而是多方干系人的诉求，是多种信息聚合，分析、平衡的结果。

2.2 需求工程

需求是怎么从一个想法变成一个产品功能的呢？

这就要看需求工程了。

需求的开发也是一个迭代的过程，是一个逐步完善的过程，我们很难在刚开始就把所有可能的情况都想清楚，信息的准确性和全面性以及产品经理的能力、经验、视角、思维局限都会影响需求质量。

那，需求的开发过程是什么呢？

一般是：获取 → 分析 → 规范 → 确认 → 实现 → 验证

如下所示：

从商业需求、市场需求、业务需求、用户调研、竞品分析等方面获取需求 → 理解以后进行归类，并与软件需求联系起来 → 再编写产品需求文档，用一致的、可存取、可评审的方式记录不同类型的需求 → 然后召开需求评审会通过多方视角确认需求 → 之后就是视觉&交互设计，系统分析设计，测试分析设计去细化需求，再通过编码去实现需求 → 最后是验证需求的完成情况

每个阶段都是不断细化和完善的过程。

2.3 需求来源

正所谓无需求不产品，产品需求是从哪里来的呢？

基本流程如下图所示：

3. 需求是怎么写出来的？

描述需求要写文档，但说到文档，我们常听说的有三种：BRD、MRD、PRD，分别是：商业需求文档、市场需求文档和产品需求文档。

BRD -> MRD -> PRD 是一个从高到低的逐层递进的关系，BRD 从战略高度告诉我们做什么产品，MRD 从战术的角度告诉我们怎么做，PRD 非常细化的告诉我们做成什么样。

而我们测试人员最关注的则是 PRD。

PRD 涉及的信息要素主要有版本记录、需求分析、需求设计、全局说明、原型设计等，一般是用 Word + 原型图（Axure/墨刀/Figama）来写。

怎么判断 PRD 写的好还是不好呢？

其实，PRD 的好坏不在于好不好看，而是信息传递的完整性和准确性，可以让一个完全没有接触过这款产品的人看了也能了解清楚。

敏捷项目

敏捷项目中使用产品待办列表（product backlog）来组织管理需求，是由 Product Owner 负责制定的一个按照重要性的级别排序的用户故事列表。

这个产品待办列表会用一些平台来管理，比如 JIRA、禅道等，然后分配到特定的迭代中实现，在迭代得以进一步澄清。

用户故事是什么？
用户故事是敏捷方法的一部分，它是从客户的角度出发，对功能的简短描述。

用户故事描述的是：
作为某个用户类型，我想要做一些事情，以便达成一些目标。

比如，作为一位有品味的中年大叔，我想个性化设定自己的微信头像，以便能够彰显个性。

如何对故事进行分级管理呢？
按工作量从大到小排序应该是：主题 > 史诗 > 特性 > 用户故事 > 任务。

简单点讲，用户故事（Story）是故事的最小单位，用来描述用户需求。而大的故事就是史诗（Epic），比史诗更具象的或多个故事的集合就是特性（Feature），按类别区分的大故事就是主题（Theme）。

用户故事（Story）用来描述需求，而任务（Task）是从用户故事中拆出来的具体的开发任务。

不同级别的故事所需的时间如下图所示：

很多人可能搞不清楚用户故事和需求文档之间的关系，可能会有这样的疑问：用户故事可以代替需求文档吗？

虽然我们可以将产品待办列表视为传统项目需求文档的替代品，但用户故事的描述是不完整的，它就是一句话需求，你没有办法拿这一句话去设计和开发。

通常比较好的做法是将「用户故事」作为实际需求的参考，在 PRD 中去细化它，添加原型图、逻辑图和实例化等。

如下图所示：

这里有一个实例化需求的概念，实例化需求的英文是 Specification by Example，简称 SBE，直译过来就是用实例说明需求。

为避免需求沟通过程中的「知识诅咒」，“实例化需求” 方法从场景出发，以用户的操作实例来澄清需求。

相比一般的规格说明，实例更加场景化，能够激发参与和深度讨论；同时，实例是具体的，其典型形式是：「在什么情况下，做什么操作，会得到什么结果」。基于具体的实例，更加便于沟通中的双向确认，保证理解的一致和场景覆盖。

如下图所示：

4. 常见的需求问题

关于常见问题，我们从理解、表达、体验、可行、管理这 5 个方面来看，对应的问题就是：理解不对、表达不准、体验不好、可能不行、管理不好。

高质量的需求正好是常见问题的反面：