汉捷咨询介绍通过结构化、系统地定义产品包需求来构建企业产品的竞争力。当企业基于市场/客户定义产品包需求，严格讲在产品Charter阶段/立项阶段定义的为“市场需求”，在产品开发时，我们需要将市场需求无遗漏的传递到产品设计中。本文提到的产品包需求主要指的是市场需求（即外部需求）。
当产品立项通过就进入了产品开发阶段。按照IPD产品开发要求，研发人员需要将产品包需求（OR，Offering Requirements）转化为系统需求（SR，System Requirements），并进一步将之转化为分配需求（AR，Allocated Requirements）。注意，AR需求是最小单位的开发需求，不能继续分解。
在产品设计过程中，通过三类文档承载上述三级需求，分别是：
《总体设计》（简称总设）：将产品包需求分解到产品级（SR），呈现给客户的产品整体表现；
《概要设计》（简称概设）：将系统需求（SR）分解到产品内部，如子系统或功能模块，是系统工程师分配给研发各专业领域的设计输入（AR）；
《详细设计》（简称详设）：各专业领域工程师按照本领域的概要设计要求（AR），实现本领域的产品详细设计。
在产品包需求传递到产品设计过程中，需要使用系统工程的方法，具体的分解参见汉捷咨询的系统工程课程，在这里汉捷咨询只是概述性介绍如何应用。
一、需求分解分配的前提
1.1 获得清晰的产品包需求
在IPD产品开发流程中，要求研发人员严格按照产品包需求进行开发。而产品包需求的开发，参见汉捷咨询上篇文章《需求定义》，那篇文章提供了具体方法，即企业按照$APPEALS的框架收集、分析市场需求，并将识别市场需求进行排序，汇总得到产品包需求。具体内容这里就不再赘述。在本阶段，我们应该已经获得了完整的产品包需求（OR，Offering Requirements）
1.2 已完成业务分层
另外我们还需要一个前提，就是企业已经完成了“业务分层”，即产品具有清晰的、公司内部达成一致的逻辑分层架构，通常称之为“产品树”。
将上图的“产品树”高度概括，可以得到逻辑层级如下：
系统：对应企业提供的产品，实现客户要求的功能、性能；
子系统：就是将系统进行拆分，与系统中的其他部分相互作用和协调，以实现整个系统的功能和性能；
模块：构成子系统的具备某项/些功能、性能的组合；
组件：构成模块的具备某项功能的组合；
零部件：构成组件的零部件。
上面是以硬件产品为例，对业务分层进行了简单定义。同理，可应用在软件产品上，同样逻辑对软件产品进行业务分层。另外，企业可能不仅提供单一产品，有时还会提供多产品的解决方案，那么该企业的业务分层在“系统”之上还会再增加“解决方案”层。需要补充的是，某些企业的产品只是构成其他设备的一个结构件，该企业产品的构成很简单，就不必再细分子系统、模块，而可能直接就是组件级别。总之，大家在应用过程中，不必拘泥这五个层级，须结合企业产品自身特点，定义自己的业务分层的逻辑。
1.3 清晰的产品技术路线
这里指的是待开发的产品包采用什么样的技术实现方式已经清晰明了并得到验证。技术实现方式已提前解决。这也就是IPD体系强调的“技术开发与产品开发相分离”的要求。具体如何解决技术问题，不是本文讨论重点，如有兴趣，可以后续撰文进行说明。
二、产品包需求分解到总体设计（OR—>SR）
当满足上述三点后，就可以进行产品包需求向产品设计分解。既然首先是产品包需求转化为系统需求，并用总体设计文档承载，我们就要搞清楚，总体设计是干什么的。
（1）解释产品做成什么样
也就是研发系统工程师（SE，System Engineer）根据产品包需求，结合企业自身能力，对外承诺待开发的产品做成什么样子，满足什么样的功能，达到什么样的性能。客户不关注产品是如何实现的，他们只关注企业产品的功能是什么？功能、性能是否满足客户的需求？我们就要通过总体设计来回答这一点。
（2）对内提出设计要求
当系统工程师回答了产品做成什么样之后，研发各领域工程师还是不清楚如何实现待开发产品的。他们不清楚产品实现对各领域的要求，彼此之间需要如何配合。系统工程师就要在总体设计中向研发各专业领域提出设计要求，告诉各领域工程师，实现本产品，你们需要实现什么功能，达到什么性能。具体就是将产品包需求、彼此间的接口关系进行分解分配，包括：需求的分解分配关系；接口的分解分配关系。
2.1 产品包需求分解分配关系
由上图可见：
第一层级是“系统”，也就是我们的产品——摩托车；
第二层级为“子系统”，从上图可见摩托车由三个子系统构成，分别是：动力子系统、车身框架、制动子系统；
第三、四、五层级分别对应“组件”、“部件”、“结构件”。
企业的系统工程师就要在总体设计中，将产品包需求含产品规格分别传递到三个子系统中，明确各子系统响应哪些需求，实现哪些功能，达到哪些性能。可以通过产品包需求分解表来实现。
在制定接口关系的分解分配表时，需注意：
只是子系统间的分解分配，不涉及子系统内部的接口关系；
外部接口需要识别出来（如存在外部接口），并将之与子系统进行分解分配；
接口不仅包括信号/信令协议，还包含物理信息，如大小、位置等。
三、系统需求分解到概要设计（SR—>AR）
当总体设计通过评审后，研发各专业领域工程师按照总体设计，进行本专业领域的概要设计，即将SR转化为AR。
在此过程中，同样遵循系统工程的方法，将系统工程师分解过来的需求和接口关系进行“本领域内部消化”，即将本领域（即子系统）的设计输入进一步分解到各模块、组件上。
因为概要设计与总体设计同样遵循系统工程的方法，这里就不赘述了。在进行概要设计时，注意以下几点：
分解需求时，将“子系统”看成一个产品，按照已定的业务分层逻辑（即产品树），继续深入分解；
分解接口关系时，关注本子系统与产品其他子系统的接口关系；
进一步将产品规格分解到子系统内部，形成设计规格。
在需求的转化过程时（OR—>SR—>AR），一定要做到“不遗漏，不缺失”，确保产品包需求完整无缺地传递到产品设计中。同样，接口关系的分解分配也要做到这点。
我们常说：在产品设计中实现产品竞争力。制定正确的产品包需求是产品竞争力的基础，而将正确的产品包需求完整、清晰地分解分配到产品设计中，又是实现产品竞争力非常关键的一步。所以，汉捷咨询强烈建议企业产品开发人员，真真正正、踏踏实实地将这两部分内容做扎实，你将体会到意想不到的益处。
当然产品竞争力的提升不是单一要素可以解决的，比如跨部门团队的运作、技术评审的执行、产品平台的应用、CBB的重用等等，对产品竞争力的提升都有助益。汉捷咨询后续还将撰文，将之一一道来，希望与各企业产品经理及各界朋友倾心交流，取长补短。
信息来源：汉捷咨询
【相关课程】
您的位置：
