原始需求的来龙去脉和核心要求

在软件工程术语中，“原始需求”并不是个常见的说法。

这个“原始需求”的提法是本博主自己提出来的。它的起源与CMM有关，CMM中，有“客户需求”的说法。

当时没有直接采用“客户需求”而采用“原始需求”的主要原因是当时开发产品不直接面对客户，直接面对的是工程实施部门，需求来自于工程实施部门和公司相关领导。为了便于沟通采用了“原始需求”的说法。

现在CMM已经升级到了CMMI。我们先来看看CMMI中如何说明“客户需求”的。

在需求开发过程域中，有“SG1开发客户需求”的特定目标。

SG1 开发客户需求
收集相关干系人的需要、期望、限制条件及接口得到收集，并转换成客户需求。

关键人员(例如：客户、最终使用者、供货商、构建人员、测试人员、制造人员，与后勤支持人员)的需要，是决定客户需求的基础。进行关键人员的需要、期望、限制、接口、操作概念，以及产品观念的分析、协调、细化及详细说明，以转换成客户需求。

关键人员的需要、期望、限制及接口，经常被粗略的识别或相互矛盾。因为必须清楚识别和了解关键人员的需要、期望、限制及界限，在整个项目的生命周期里可使用反复的过程，以达到这目标。为协助此必要的循环过程，最终用户或客户的代表，通常会加入此过程，以说明其需要并协助解决矛盾。组织的客户关系或营销部门，以及来自人际工程或支持部门的开发团队成员，可视为此类的代表。在收集和解决客户需求时，也应考量客户的外在环境、法规及其他限制。

SP 1.1 导出需要
导出相关干系人提出有关产品生命周期各阶段的需要、期望、限制条件及接口.

导出不仅收集需求，且要积极识别尚未经客户明确提出的补充需求。补充需求应描述各种生命周期的活动，以及它们对产品的影响。

SP 1.2 将干系人提出的需要、期望、限制条件和接口转换为客户需求
把相关干系人的需求、期望、限制条件和接口转换成客户需求。

来自相关关键人员的各种输入，须经合并、取得遗漏的信息，以及解决冲突等过程，并记录为客户需求。客户需求可包括与验证和确认有关的需要、期望及限制。

某些情况来说，客户提供项目的一套需求，或者之前项目活动的需求产出。以这些情况来说，客户需求与相关关键人员的需要、期望、限制及接口可能有所冲突，所以在冲突适当解决之后，需要转换成被认可的客户需求。

代表产品生命周期的所有阶段的相关关键人员，应包括经营及技术功能。因此，所有与产品生命周期相关的过程概念，都应与产品的概念同步考量。客户需求来自信息充分的决策，同时考量需求在经营面与技术面的影响。

--------

虽然历经CMM到CMMI变化，所提的“原始需求”仍然对应于CMMI中的“客户需求”。

在实践中，对于原始需求，也有如下的整理总结。

定义：原始需求是由用户或者用户代表提出的功能或性能需求或其他非功能需求，需求可以未经总结或提取。

目的：原始需求调查和管理的主要任务在于收集需求素材，并保证经认可的原始需求获得了实现。

流程规定：

1. 根据产品规划，产品经理划定需求提供者的范围，这个范围一般为顾客，最终用户，开发人员，生产人员，测试人员，供货商，营销人员，维护人员，和其它相关人员，要把潜在客户划分出来，这类客户是指当前还没有采购本部门任何产品的客户。

2. 通过各种方式，产品经理收集原始需求，录入，要把需求提供者信息与其提供的原始需求一起记录。

3. 产品经理或项目组将原始需求录入，初始状态是"已建议"，原始需求编号是自动生成的流水号；

4. 要求将所有原始需求录入。如果原始需求为其他项目组定制，则须注明其他项目组名称和相关的交付包。

5. 产品经理根据项目组讨论和自身判断，针对录入的原始需求，处理是否采纳此原始需求，如果采纳，原始需求的状态是"活动的"，如果拒绝，状态是"已关闭"。如果一个原始需求是由潜在客户提出的，则一般要求是由两个或两个以上的潜在客户提出，或得到其它需求提供者的佐证，才能被采纳。如果某原始需求只由一个潜在客户提出，且得不到佐证，不建议采纳。

6. 当项目组认为原始需求得到满足之后，将原始需求状态置为 "已解决"，此时至少要有一个功能点或者需求用例和这个原始需求对应，否则不允许改变状态。

7. 原始需求"已解决"之后，产品经理或产品经理的授权代理人参考测试报告，并通过功能展示逐条评审原始需求的完成情况，如果符合，进行"已关闭"操作，原始需求的状态变为"已关闭"，否则把状态改回"活动的"，要求项目组重新实现原始需求。



原始需求采纳标准

必须条件

1， 语法通顺，表述清楚，没有歧义；

2， 需求的范围已经明确说明或可以推断是有限的，可控的；

3， 此需求必定存在至少一种用户场合是适用的；

4， 此需求描述的是产品本身，而不是开发产品的某个过程；

5， 此需求不包含设计实现的内容；

6， 此需求不存在重复的需求，即没有冗余；

7， 此需求不是发现的缺陷；

8， 推测此需求的技术实现在项目当前限制范围之内是可行的。

推荐条件

1， 需求来自2个或2个以上来源；

2， 需求是场景化描述的；

3， 需求是付款用户提出的；

4， 需求是竞争对手产品的卖点；

5， 提出需求的用户有行业前景，比如海关，公安，税务等等；

6， 已经有明确的性能需求。

满足推荐条件越多，优先级越高。



示例

不附合标准的原始需求

原始需求表述	不符合的原因
能够提供各项操作的Web Service	范围没有限制，没有说明什么操作
XXX地方电子警察拦截	语法不完整，不知其义
设备信息查询中病毒库查询不正确，实际有四种	这是一个缺陷，不是需求
应当请客户确认原型后，再开发XXX模块	这是开发过程
客户登录时，先调用A模块，然后调用B模块，再经C检验后确认用户登录	包含设计，不是用户的语言
第3个小版本的原始需求	没有内容，只为流程

表4-2 附合标准的原始需求

原始需求表述

用户可以在子网路由器层中删除路由器（或网关）

在发生报警的时候能够发出电子邮件

点击所有显示计算机的记录都应能显示完整的终端信息

若有软件违规发生，向服务端发送软件违规信息

以上虽然全面的说明了原始需求。但可惜的是反而把原始需求最核心的要求淹没了。

所以在本文的最后，特别要来说明什么是原始需求最核心的要求。

原始需求最核心的要求不在于已经采纳的原始需求，恰恰在于被拒绝的原始需求。只有知道了哪些原始需求被拒绝了或者延迟了，才能相信所采纳的原始需求是真正要做的。

只记录经过选择采纳了的原始需求的做法只能保证这些原始需求得到实现，不能保证恰当的、合适的原始需求得到了采纳。

而原始需求最关键的地方在于如何寻找最恰当的原始需求，其次才是实现原始需求。

因此，原始需求应当全面的记录来自于各方对产品的要求，无论这个要求是否可行，是否合理，是否要做，是否优先。

在记录时，为了不影响后续人员的判断，要尽量传递用户的真实意思，采用用户的语言，保持“原始”。

以产品经理、项目经理为首的产品开发相关人员应当第1时间记录原始需求，积累好原始需求，当要选择做的时候，再来做谨慎的选择。

只有全面的收集记录的原始需求，才能有产品全面的判断和选择，进而开发出受到客户欢迎的产品。



Scrum中有product backlog，其中的条目一般是用户故事，由于用户故事颗粒度受迭代的限制，需要对用户故事进行分析。

考虑上诉提到的原始需求，存在两种做法：目前比较常见的是 直接利用 product backlog管理原始需求，将原始需求记录为用户故事，碰到过大的原始需求就分解为多个用户故事。另外一种做法就是前文所述，将原始需求与Product backlog分开管理，适合的场景是存在多处用户的软件，有许多客户和潜在客户，以及不少干系人。分开管理的好处主要在于能够更好的跟踪用户，更系统的理解用户的需要，能够选择更恰当的需求。