IPD体系进阶｜需求管理篇之需求实现过程

作者：卫朋

公众号：产品人卫朋

继续 IPD 体系中的需求管理相关的专题。

先来看看整个需求管理涉及的过程内容：

需求管理流程主要包含五个阶段： 需求收集； 需求分析； 需求分发/分配； 需求实现； 需求验证与确认。

其中，需求实现阶段强调的是要将客户需求转变为产品。

从而最终能够满足所确定的客户需求。

在需求实现阶段，首先任务是要对需求打上标签进行分类。

需求实现是一个复杂的过程，必须对所有的需求进行识别分析。

对优先级高、重要性高的需求优先实现。

需求实现流程主要会涉及以下几个方面：

第一个是需要立即开发的需求。

这个时候，一般是要提交 PCR 变更申请，将需求加入到当前的开发项目；

第二个是需要在下一个版本开发的需求。

需要将需求纳入到 CDT 团队进行分析；

第三个是需要纳入路标的需求。

将需求发送给路标管理团队，进行路标的排期。

其实，如果从整个需求的生命周期来看，需求会有多种状态之间的转换。

如下图所示：

最初从客户的要求，一步步转化为设计上的内部需求，在开发端实现落地。

也就是说从客户需求到最终的研发完成，需求会不断转化和分解。

比如从特性需求到功能需求的转化，从对问题的描述转化为对解决方案的描述，然后逐层展开分解。

这个时候就会涉及到对需求的跟踪和变更控制，以及管理。

需求的整体流转过程如下图所示：

主要涉及原始需求、初始需求、特性需求、系统需求几个维度，下面分别介绍一下：

1、原始需求

简称是 OR，具体是指客户对问题或产品功能、性能等要求的具体描述。

2、初始需求

简称是 HR，也就是经需求解释后，用企业内部使用的规范语言描述的原始需求。

3、接下来时系统特性

简称是 SF，具体描述的是产品为解决客户问题所具备的重要能力。

同时特性也是产品包的主要卖点，每条特性都是满足客户特定商业价值诉求的端到端解决方案。

4、最后是系统需求

简称 SR，是指支撑系统特性所需的具体需求，是系统对外呈现的、可测试的全部功能需求和非功能需求。

系统需求也需要进一步分解到子系统/模块的功能或非功能性需求。

它们实际上也是系统需求的一种表现形式，可以按领域进行，也可以按子系统进行。

完成需求分解分配后，然后由各开发组设计开发实现。

并由测试部进行测试，确认需求实现即完成验证。

需求验证的方法一般会包括内部验证和外部验证两种方式：

内部验证是指通过产品开发流程的各个评审点来操作控制，包括需求评审、跟踪等活动。

而外部验证的目的是保证对于客户需求理解的准确性。

今天的内容分享到此结束，更多干货内容，敬请期待！