以客户为中心的市场需求实现，是IPD体系中的业务主线之一。为了支持该主线的落地，IPD体系中设计了专门的需求管理流程。本节中，笔者从总体要求、流程框架和交付文档等三个方面，对需求管理流程做详细介绍。
一、总体要求
1. 需求定义
根据IEEE1220-1998的定义，需求是对产品或过程的操作、功能和设计的特性或约束的表述，这些表述必须是明确的、可测试的、可度量的，而且对于产品或过程的可接受性（被顾客或质量保证措施）来说是必须的。
需求首先表现为市场需求。产品研发要从市场中来，最终再回到市场，这主要体现为市场需求对产品研发的指导和牵引。因此，需求是产品研发的根源，需求管理的质量对产品研发的质量具有决定性影响。这就像一条河流，如果源头被污染了，那整条河流就不可能干净。
需求管理贯穿产品研发的全过程。在产品规划的初期，主要体现为市场需求。在产品立项阶段，要将市场需求转化产品构想和特性需求。在产品开发阶段，产品的特性需求要分配和分解到产品架构上，转化为产品的规格要求。最后，要通过物理或虚拟验证等手段，确保需求得以实现。
图4.13 研发全过程的需求演变
1）需求分类
需求是一个笼统的说法。我们可以从需求的来源、需求的重要程度、需求与功能的关系、需求实现的时间紧迫度等角度，对需求做各种形式的分类。
从信息的来源来看，需求可分为外部需求和内部需求。来自企业外部的需求，主要有来自市场的客户需求，来自政府的监管或法规需求，来自行业的竞争需求，等等。来自企业内部的需求，主要是企业为了实现业务发展和商业目标所提出的需求，也可以是市场、销售、服务、质量、制造、采购等部门提出的产品改进需求。
另外，从重要程度的由高到低，需求可分为强制性需求、必须性需求（Must）、应该性需求（Should）和可以性需求（Could）。强制性需求主要是来自政府的监管或法规需求，是没有协商余地的需求。必须性需求是必须实现的需求，否则，产品就失去了存在的价值。应该性需求的重要程度仅次于必须性需求。可以性需求一般是“锦上添花”式需求。
从需求与功能之间的关系来看，需求可分为功能性需求和非功能性需求。功能性需求与产品的核心功能紧密相关，非功能性需求则是与产品的性能、安全等要求相关，或是与产品的外延性、形式（符号）性、情感性价值有关联关系。以DFX（面向工程的设计、面向制造的设计、面向销售的设计、面向服务的设计，等等，统称DFX）思维作指导，可以帮助我们提炼出产品的非功能性需求。
从需求实现的时间紧迫度来看，需求可分为长期需求、中期需求、短期需求和紧急需求。长期需求在实现上的时间紧迫度上往往在1年以后，可以放在产品规划中予以体现。与之作对照，紧急需求的实现时间是越早越好，要放进“在研项目”中去实现。
2）需求分层
图4.14 产品包需求的分层模型
客户问题描述了客户期望产品解决的问题。需求收集时，需要将客户的口语化、情感性描述（原始需求）转为客观、规范的需求描述（初始需求）。
特性需求描述了产品为了解决客户的问题所应具有的能力。相比较需求侧的初始需求，特性需求已经是供给侧的产品属性，是将市场机会转化为可行性产品设想。
系统需求是对特性需求进行分析和加工后形成的、对产品的交付要求。我们可以这么理解，特性需求类似于软件“类”，而系统需求类似于软件“类”的“参数”，特性需求与系统需求之间往往是一对多的关系。因此，从特性需求到系统需求，是需求（产品构思）的参数化和公式化。
从需求实现的角度，在产品开发过程中，我们还要将系统需求分配或分解到产品的架构（机械架构、电气电子架构、软件架构）中，进而形成产品的规格要求或设计目标。
3. 管控要求
为了落实需求在研发中的核心地位，企业需要对需求进行端到端的全过程管理，要从需求的明确性、完整性、一致性、可行性、可验证、可追溯等方面落实需求管理的管控要求。
需求必须明确。对需求进行明确的描述，是需求管理的基础。只有基于明确的描述，相关人员对需求的理解才不会引起歧义，才容易达成一致的共识。因此，需求描述必须是客观的、规范的，不能带有情感性、口语化的表述。尤其是系统需求，必须是参数化、定量化、公式化。
需求必须完整。需求收集时，必须充分地挖掘信号微弱的、隐形存在的需求。需求在分析、加工和传递过程中，更不能有丢失。强制性、必须性、应该性等重要程度高的需求如有遗漏，将导致后续不必要、高成本的需求变更。
需求必须一致。需求的一致性要求至少体现在两个方面：1）产品规格要与市场需求保持一致，即，通过对需求进行有效管理，要确保产品在功能、性能等方面满足市场需求；2）相关人员和团队成员要对需求内容和目标的理解保持一致，即，通过需求进行有效的计划、沟通和评审，以协调相关人员的工作，合理分配研发、生产、采购等资源，进而提高协同效率，优化资源使用。
需求必须可行。需求必须具备商业上的可行性，才有可能确保企业商业目标的达成。需求必须具备技术上的可行性，有可能确保需求的实现。
需求必须可验证。只有可验证的需求才是“真”需求，才有可能通过物理或虚拟等验证手段来判定其是否已实现。否则，不可验证的需求要么是“假”需求，要么需求的整理、分析、分配、分解等工作还没有做到位。
需求必须可追溯。只有可追溯的需求才能进行需求的澄清、确认和评估，才有可能对需求的实现进行敏捷迭代，才有可能对需求管理进行持续的改进和优化。
4. 体系建设
高效的需求管理和管控要求的落实，需要有需求管理体系作保证，需要完善需求管理流程、需求管理团队、需求管理平台等的建设。
首先，企业要制定从需求的收集、整理、分析、刷选、分发、分配、分解、实现，到验证的完成流程，以确保需求管理活动的规范化和端到端。
其次，还需要建立跨部门的需求管理团队，由市场、研发、销售、服务、制造、质量等多个部门人员组成，或是成立具备研发、市场、质量等多领域能力的专业部门，确保需求管理的职责落实。
再次，通过建立统一的需求管理平台，借助数字化手段，还可实现需求信息的实时共享和需求管理的高效协同。
关于需求管理团队和需求管理平台的建设内容和相关要求，笔者将在后续章节中做详细介绍。
二、流程框架
需求管理的流程，具体由5个运营性子阶段流程和3个管理支持流程所组成。5个运营性子阶段流程分别是：需求收集、需求分析、需求分发、需求实现和需求验证。3个管理支持流程分别是：需求确认、变更管理和质量支持。
4.15 需求管理的流程框架
需求收集阶段的主要工作，是从市场、客户、竞争对手等企业外部渠道，以及市场、销售、服务、制造、采购等企业内部渠道收集一手或二手的需求信息。需求信息的收集，需要明确信息来源、明确收集对象，以及采用合适的收集方法。
需求收集需明确信息来源。需求信息的来源主要分为外部和内部。外部来源主要有：目标客户、渠道伙伴、竞争对手、第三方情报单位、行业协会、政府机构，等等。内部来源主要有：一线销售团队、市场部门、研发部门、质量部门、制造部门、采购部门，等等。
需求收集需明确收集对象，即，向谁去收集需求信息。需求的收集对象主要是目标产品的利益干系人，主要有：目标客户、渠道伙伴、竞争对手、供应商、监管机构、企业股东、营销团队、制造团队、质量团队，等等。
需求收集需采取科学方法。需求收集的方法主要有：VOC研究（含客户访谈）和市场洞察，
VOC研究是带着问题，从客户与品牌互动的各个渠道、各个触点中去搜集客户之声，可以帮助企业获得丰富的、具体的、一手的客户需求信息。VOC研究的具体操作方法可参见“激发创新灵感”章节中的相关介绍。
市场洞察是以市场调研、竞争产品分析、行业数据分析、政府政策解读、需求趋势预测等手段，从面上去了解市场需求和竞争态势，还可以对现有数据进行二次提炼、加工和整理，进而识别相关需求信息。
图4.16 需求收集汇总模版
从工作输出上，需求分析阶段的主要成果是获得产品包需求，具体包括原始需求向初始需求、特性需求和系统需求的层层转化，工作手段和管理活动则是对所收集到的需求信息做进一步的解释、过滤、检视、分类、排序和证实。
解释是对需求信息做结构化加工，从客户想当然的解决办法等表象信息中分析客户问题的动因（3Why分析，从表象找到根因），将初始需求转化为特性需求，将特性需求转化为系统需求，并在相关人员中进行上述需求信息的交流，让大家对需求信息达成一致的理解。
过滤是对需求信息进行萃取，过滤或删除掉细枝末节的需求，提炼、新增出主干性需求。比如，企业根据自己的竞争策略，剔除掉部分需求，提高某些需求的技术标准、降低某些需求的技术标准、增加全新的系统需求，等等。
检视是组织并召开由需求分析团队或相关人员参加的内部会议，对需求信息进行内部评审。
分类是从需求与功能的关系、需求的$APPEALS类型、需求的重要程度等方面，对系统需求进行分类，分类成：
1）功能性需求与非功能性需求；
2）非功能性需求还进一步分类为价格性需求（$）、可获得性需求（A）、包装需求（P）、性能需求（P）、易用性需求（E）、质量保证需求（A）、生命周期成本需求（L）、社会接受程度需求（S）、可制造性（DFM）、可服务行（DFS）、可测试性（DFT），等等。
3）强制性需求、必须性需求、应该性需求、可以性需求；
排序是综合上述分类结果，再设置一定的权重，结合权重评级对需求实现的时间紧迫度和优先级进行排序，区分出重要&不紧急的特性需求和重要&紧急的特性需求，为后一阶段的需求分发提供决策依据。
图4.17 需求分析与层层转化的示意
需求分发，是根据需求排序的结果，做如下途径的分发：
1）将长期的，或是重要且不紧急的系统需求，纳入待规划需求池，在市场管理或业务战略的制定时予以考虑；
2）将中期的，或是重要且紧急程度一般的系统需求，纳入到产品需求池，在产品（路标）规划中实现；
3）将短期的，或是重要且紧急程度较高的系统需求，纳入到对应的产品立项（产品研发任务书）中，在将要研发的项目中实现；
4）将重要且非常紧急的系统需求，提交需求变更流程进行审核和审批，审批通过后，纳入到对应的“在研项目”中实现。
需求分发时，相关人员有可能对需求的分发路径存在不同意见，需要通过需求争议的升级机制来解决。具体来说，就是将有争议的分发路径升级到更高层的决策团队来决策。
4. 需求实现
需求实现，是在产品开发的概念或计划阶段，将系统需求分配或分解到产品架构（包括机械架构、电子电气架构、软件架构）中，将系统需求转化为产品的设规格要求或设计目标。对于客户可选配的配置化产品，还需做好系统需求与产品分类特性之间的关联。
图4.18 系统需求分配到产品架构的示意
图4.19 系统需求分解到产品架构的示意
如果某个系统需求需要产品架构的多个模块共同实现，则需要将该系统需求分解到产品架构的相应模块。如图4.19所示，汽车产品的空车重量是所有模块的重量之和，而汽车产品的空车重量要求，就要分解为各个模块的重量要求。
图4.20 系统需求与分类特性的关联
另外，为了便于需求的跟踪和追溯，企业还可以编制“需求—规格”矩阵，对系统需求与产品规格之间的对照关系进行全景化展示。“需求—规格”矩阵的格式，可参见图4.21所示。
图4.21 “需求—规格”矩阵的示意
需求验证，指的是通过产品原型、虚拟测试、物理测试等手段，验证系统需求是否得到充分的实现。需求验证的主要工作内容将在产品开发的开发和验证等阶段来完成，需求管理团队需要站在需求端到端闭环的角度，对验证的结果进行确认。
6. 需求确认
需求确认，主要是确认需求（以特性需求、系统需求、产品规格、试制样品等形式来呈现）确实是客户想要的，是保证产品满足客户需求的方法，目的是减少最终产品与客户需求之间的差距。
需求确认贯穿了从需求的整理、分析、分发、分配、分解，到验证、实现的全过程，具体工作有需求的澄清、沟通、确认、跟踪、评估，等等。
为了做好需求确认和需求跟踪，企业需要为每一个需求分配唯一的编码，做到需求在项目全生命周期的唯一识别；需要详细记录每一个需求的背景、内容、优先级等信息；需要对变更进行严格的管理，确保变更的合理性和必要性；需要建立需求跟踪矩阵，明确需求与项目计划、涉及和执行的对应关系；需要定义生成需求状态包括，向项目干系人报告需求的实现情况。
需求确认的工作开展，主要以不定期的需求信息沟通和定期召开的需求评审会议等形式来进行。
7. 需求变更
需求的变更将打乱产品开发的正常节奏，带来一定程度的返工，为产品开发的质量、成本和周期等带来极大的影响，而且变更的时间点越晚，变更的影响越大。因此，企业应该通过有效的需求管理，尽量地避免需求的变更；如果难以完全避免，就需要借助专门的变更流程，对需求的变更进行严格管理。
通常，企业会建立统一的变更管理流程，作为需求管理、产品开发、平台/技术开发等的管理支持流程，集中地管理研发过程中的各种变更，包括：项目变更、需求变更、设计变更、工程变更，等等。变更管理流程包括变更申请、变更评估、变更审批、变更实施、变更验证等活动。变更管理流程的详细内容，可参见后续章节中关于“变更管理流程”的相关介绍。
借助变更管理流程对需求变更进行严格管理，1）首先要建立需求基线，确保所有人员对需求的理解保持一致；2）其次是强化变更审核，确保所有的需求变更都必须经过相关管理部门的审核，防止随意变更；3）再次是落实版本控制，采用版本控制工具对需求文档进行管理，确保不同版本之间的差异可追溯；4）然后是做好变更记录，对所有的需求变更进行全过程记录并形成变更日志，便于跟踪和审计。
8.质量支持
根据ISO 9000体系的定义，质量是产品固有特性满足要求的程度。因此，质量问题、质量特性，等等，也可视为某种形式的需求，是内部需求信息的主要来源，而质量特性及质量问题的有效管理也将为需求管理提供数据和方法上的大力支持。
质量支持流程也是需求管理、产品开发、平台/技术开发等核心研发活动的管理支持流程，内容包括质量目标、质量策划、质量控制、问题管理、持续改进，等等。质量支持流程的详细内容，可参见后续章节中关于“质量支持流程”的相关介绍。
三、交付文档
需求管理流程的运行，将产生多种形式的交付文档，这些文档将作为产品规划和产品立项的主要输入。
需求管理流程的交付文档包括：客户访谈提纲、客户调查问卷、客户访谈记录、VOC研究报告、市场调研报告、竞品对标分析、需求变更记录、需求状态报告，等等，以及前文所说的原始需求列表、初始需求列表、特性需求列表、系统需求列表、需求—特性（规格）矩阵。
基于上述交付文档，企业可以用于编写商业需求文档（Business Requirements Document，简称BRD）、市场需求文档（Market Requirements Document，简称MRD）和产品需求文档（Product Requirements Document，简称PRD），它们也是产品立项流程的主要决策依据。
为了确保文档的质量，企业应该对需求管理流程的交付文档，尤其是特性需求列表、系统需求列表、需求—特性（规格）矩阵等进行严格的评审：
1）首先要明确评审标准，包括需求在明确性、完整性、一致性、可行性、可验证、可追溯等方面的管控要求；
2）其次要落实专家评审，由跨部门的领域专家对编写人员所提交的文档进行审核，评审时还要重点关注需求的重要性、优先级、与其他需求的协调性，等等；
3）必要时，根据评审意见，编写人员再对需求文档进行修改和完善。
