1、目的
市场需求管理是所有其它业务活动的基础。只有通过创新不断满足市场需求的企业才能适应市场变化而获得可持续发展。
基于市场的创新集中体现为客户需求驱动产品及解决方案的开发。具体实现方式是将核心业务划分出一个个产品及解决方案包（Offering），并根据客户需求定义产品及解决方案包需求（OR，Offering Requirements），再将包需求转化为设计需求（DR，Design Requirements），然后通过产品及解决方案的开发实现和满足客户需求。
市场需求管理提供了一个可执行的流程和相关的方法，通过多渠道多手段的需求收集，建立市场需求库来管理具有高附加值的产品及解决方案包需求，并将选定的需求反馈到市场管理流程和研发流程，为市场需求分析、市场管理、产品规划、研发投资决策和业务盈利计划提供数据支撑。
2、概念定义
包需求(OR，Offering Requirements)：站在客户视角用客户化语言描述的产品及解决方案的市场需求，侧重产品及解决方案的系统外在行为，具备可验证的描述和说明。
设计需求(DR，Design Requirements)：在包需求及产品概念和可选技术方案基础上，通过系统工程方法对功能、性能、质量、成本、进度等进行权衡和分析，确定产品功能、性能及技术规格可接受的参数范围，是用技术语言描述的产品及解决方案的系统内在行为，具备可测试的参数。
中长期需求：时间跨度在6个月以上的市场需求；
短期需求：时间跨度在3到6个月内的市场需求；
紧急需求：3个月以内的市场需求；
客户定制需求：单个客户或某类客户的特殊需求；
DFx需求：指可靠性、可测试性、可制造性、可安装性、可维护性、可扩展性、环境适应性等方面的市场需求；
产品缺陷：产品在设计、实现及制造过程中产生的不符合项；
3、角色定义
产品管理团队(PMT)：由跨功能部门(市场/营销、研发、销售、供应链、财务、质量)重量级代表组成的业务管理团队，承担市场管理、产品规划、市场需求管理；
需求管理团队(RMT)：属于PMT的需求管理子团队，承担市场需求的管理和决策；
需求分析团队(RAT)：是跨功能部门的小组，由系统工程师、研发、市场营销、销售、制造、采购、技服、质量等各领域专家组成，承担市场需求的分析；
需求管理员(RMO)：负责RMT的事务性工作，包括需求管理对外接口、《市场需求收集表》的接收管理、需求管理IT系统的操作等；
销售项目需求管理接口人(CCM，需求承诺经理)：属于销售、行销或技服团队的成员，在销售项目投标团队中承担需求管理角色；
系统设计组(SDT)：承担产品及解决方案的系统设计，包括技术可选方案评估、规格定义、设计需求、总体技术方案、关键技术、测试方案等；
系统工程师(SE)：作为系统设计组的Leader，是产品和解决方案的总体技术负责人，是产品研发团队的核心成员；
质量工程师(QA)：负责对市场需求管理流程执行规范性进行审计，提出流程优化建议；
项目经理(PM)：负责产品及解决方案的项目管理，管理整个跨部门的业务团队，对产品及解决方案项目的总体盈利业务目标负责；
4、输入
各类市场需求信息、《市场需求收集表》、市场需求数据库。
5、输出
《产品及解决方案包需求》
《项目需求变更》及《项目计划变更请求》
刷新的《业务计划》
刷新的《产品及解决方案路标》
刷新的《技术规划》
6、过程描述
如下图所示，OR流程的基本阶段划分：收集、分析、分配、实现、验证。
以下按各阶段顺序展开过程描述。
6.1需求搜集
了解市场需求要从多方面收集客户原始数据。需求通常来自各种内部和外部渠道，需求收集不只是一个步骤或活动，它包括了公司所有相关组织的日常业务活动的集合。公司所有人员都应参与到市场需求收集活动中，包括公司管理层、研发、营销、销售、技服、制造、采购、物流、财务和其它功能性支撑团队。
为降低需求收集的盲目性，应首先识别客户，对客户进行类型分析。客户可以包括：购买者、最终用户、关系人、渠道、集成商、分销商、软件开发商、增值代理商、服务提供商、合作伙伴等，不同的客户关注不同的需求。其次，要对客户的决策链和关注要点进行分析。通过对最终用户的购买决定进行回溯分析，可以确定所有影响交付条件的人。
为了确保生成高价值的客户需求，收集需求应采用市场和客户驱动的方法，并参考业界最佳实践。应采用$APPEALS方法进行产品需求调研，发掘客户的潜在需求，真正理解客户意图。$APPEALS从多个维度，不同权重来收集需求，联系细分市场和竞争对手，涉及到差异化分析和蓝海的价值创新(减少，增加，剔除，创新)，通过差异化需求收集提升产品核心竞争力。差异化需求往往就是产品的重要卖点，即说服客户为什么购买产品的简单决策依据。
$APPEALS方法从8个方面对产品进行客户需求定义和产品定位。具体如下：
$-产品价格（Price）；
A-可获得性（Availability）；
P-包装（Packaging）；
P-性能（Performance）；
E-易用性（Easy to use）；
A-保证程度（Assurances）；
L-生命周期成本（Life cycle of cost）；
S-社会接受程度（Social acceptance）。
需求收集渠道分为内部渠道和外部渠道，内部渠道包括公司管理层、研发、营销、销售、技服、制造、采购、物流、财务和其它功能性支撑团队，可以通过组织专家交流、Workshop、经验交流的方式收集整理基本的需求。
以下总结了几种具有良好效果的常用外部市场需求收集方法：
| 方法 | 需求收集方法说明 | 优点 | 不足 |
| 1 | 研发高层交流 | 研发高层交流是指邀请客户高层参与交流有关产品信息，获得未来产品计划的输入信息，前提是双方有良好的客户关系。虽然关系建立及相互交流都是在高层级别进行，但是交流本身更关注于技术，而且双方会共享当前与未来的需要和行动。研发高层交流由经验丰富的高层技术人员担任公司和客户间产品开发的技术接口人；客户方派出一个高层技术人员作为客户方接口人；通过整个开发流程的紧密接触，公司和客户建立互利关系。公司获取了客户对产品计划和产品需求的反馈，以及客户如何使用产品的第一手信息。客户获取了提前获取产品计划和交付件信息，赢得为新产品做准备的时间。研发高层是了解客户需求的特殊职位，可以确保研发流程中有合适的级别代表客户需求，研发高层最直接的交流方法是代表客户直接在需求数据库中输入需求。 | 利用良好的客户关系来获得高价值的需求。所选客户可以对一个或多个产品在开发的各个阶段提供具有价值的反馈。在早期收集和验证需求可以减少漏掉重要需求或开发过程中的变更。 | 要求有良好的客户关系。更多在技术领域。公司要承诺保证有效的双向需要及计划。客户可能会低估需求的复杂程度并要求提早交付需求，需要对客户期望进行适当管理(市场需求承诺管理)。 |
| 2 | 解决方案 | 解决方案团队主要目的是与业务合作伙伴一起制定客户在某个领域内的解决方案，范围超越产品本身，更加贴近客户需要。主要内容包括：确保公司关注客户需要；确保公司对未来解决方案具有前瞻性；确保公司与所选解决方案合作方的成功；解决跨公司的深层次的跨产品集成问题。通过解决方案的共同制定，可以从中提炼客户需求，提升产品开发能力，加大产品上市的可能性。可以对跨公司需求、尤其是采用合作伙伴产品和工具对公司产品增效的需求的收集有所贡献。 | 该方法利用与其它公司的业务伙伴关系来改进客户需求收集。考虑的是完整的解决方案，该方法拓宽了对客户需求理解的视野。 | 该方法的主要目的是建立战略业务伙伴关系、提升开发能力和产品竞争力。收集客户需求并不是其主要目的。 |
| 3 | 竞争分析/标杆测试 | 用标杆来评估产品性能，并按照业界/客户认可的性能标准衡量，来与竞争对手进行对比。表明产品是否符合客户的基本需求，以及产品与竞争对手相比的优劣。产品竞争分析是一项例行的活动，通过与一到三个关键竞争对手比较来评估交付，特别是在竞争激烈的销售战或产品的验收阶段。分析业界差距，了解什么对客户是最重要的，可以采取什么行动以满足客户需求从而改善竞争地位。通过竞争分析和标杆测试可以进行有效的市场需求收集，应用范围超越单个产品，可以扩大到多个产品或产品集。 | 竞争分析和标杆测试有助于根据业界标准衡量产品，反映产品竞争地位。可以确认是否满足必须的性能要求。 | 标杆测试与需求收集的联系是松散、不系统的。 |
| 4 | 试验局/BETA测试 | 试验局、原型测试或产品试用的目的是从关系客户处获得反馈，并让他们从该活动中受益。通过试验局从所选客户那里获得对早期产品的反馈，以在产品正式发布之前发现问题。如果执行得当，它可以验证需求及需求执行情况。并据此确定补救措施（在当前版本或未来版本）。试验局重点关注于确保需求以规定的方式交付。 | 通过试验局试用可以在客户环境验证需求，并收集新的潜在需求。 | 试验局的主要目的是在客户环境下测试早期产品。通常重点是测试和找问题。 |
| 5 | 客服高层交流 | 公司应向大客户提供支持服务来避免和预防问题。提供这种服务的主要方式就是客服高层交流，目的是从客服的角度建立与客户的关系，并且通过这种关系来解决一系列问题，比如用这种方式可从客户高层获得明确的、点对点的需求。用服高层交流使正常的操作层交流得到加强，从技术支持角度建立了与客户的关系，通过这种在客户环境下的亲密接触，关注点应该超越对问题的解决，转向对代表积极解决方案的支持需求进行定义，避免后续出现此类问题。通过对这种交流的管理，可以针对性的提炼出一系列客户需求。 | 提供了从客户高层获得支持需求的一种方法。可获得对当前版本及未来版本潜在需求。可以更好地站在客户角度考虑产品的可维护性需求。 | 客服高层交流的重点是提供主动的技术支持和提高客户满意度。产品包需求的收集并不是该活动的首要目的。 |
| 6 | 技术支持 | 公司将技服工程师（有时是研发工程师）派到客户驻地，提供技术支援，其目的是提高客户满意度和忠诚度。在与客户交流中，客户通常会透露出现存在的或者未来的多种需求。在客户实际环境也可以通过观察与实测获取到有关产品的环境适应性、可用性、可服务性、可安装性、可靠性、兼容性、互操作性等方面的需求，以及在客户环境使用的竞争产品特性需求。 | 可以对跨产品特性、环境适应性、UCD、竞争产品特性等需求进行有效收集。 | 客户需求收集不是现场支持的首要目的，所收集到的需求更多是针对问题。 |
| 7 | 支持热线 | 公司提供支持热线，作为处理客户查询和问题汇报的一种支持产品包。支持热线提供了一种简便且系统的方法来管理客户的要求并跟踪直至问题最终解决。支持热线并不是产品包需求的主要来源，但是通过分析来电记录，可以获得客户需求。 | 支持热线接收来自客户的查询与问题解答要求，可以对来电反馈问题进行分析，确定客户需求。 | 客户来电通常都是客户操作层，多是技术与操作问题。 |
| 8 | 专家顾问团/经验交流 | 通过组织业务领域的公司内外部专家开展行业分析和技术交流，可以获得行业的发展趋势和技术趋势等市场需求，也可以对产品工程、系统工程、客户痛点分析方面的需求进行总结。 | 可以获得权威的价值需求信息。 | 所邀请专家要达到行业内领先水平，如果邀请不到外部专家，则容易闭门造车。 |
| 9 | 市场调研 | 针对选定的目标客户，通过问卷、电话访谈、网络访谈等方式进行主动的市场调研，收集客户需求。 | 可以主动有针对性地收集需求。 | 回收问卷可能无效，有时客户并不能深入回答相关问题。 |
| 10 | 媒体信息/网上调查 | 公司营销部门(市场管理、产品管理)应随时关注行业媒体、咨询公司及行业网站等信息。通过定期的行业信息及技术信息搜集和分析，可以提炼出有价值的市场需求。 | 可以收集到比较全面的市场需求。 | 公开媒体上的需求多数价值不高。 |
| 11 | 标准、专利分析 | 研发技术专家、营销专家通过对行业内的标准、专利进行分析，或加入行业标准联盟组织、参与行业标准会议，主动收集市场需求，规划产品路标。 | 可以收集到完整的产品基础性的需求，关注行业动向。 | 需在技术预研方面加大投入，回报周期长。 |
| 12 | 客户简报 | 利用客户简报与最大、最好的客户尽量在产品开发流程的早期分享信息，该活动属于营销活动。从需求收集的角度来看，主要目的是获得产品包需求的早期反馈与早期验证。因此，客户简报可以及时向开发团队提供输入，改进产品包需求与客户需要间的结合。向客户宣传产品路标信息是日常销售活动的一部分，也可以用来与客户验证需求，以便在开发早期获得相关输入。 | 客户简报的主要优势是能够在开发早期与主要客户验证产品包需求，验证流程也会调整或形成新的需求。 | 客户简报目的是在开发早期获得反馈。重点与正在开发的版本相关，要尽量避免增加客户工作量，以及泄露公司开发意图。 |
| 13 | 客户交流 | 公司与所选细分市场的最大、最好的客户定期会面，获得未来的需求。参加交流的客户应是能作决策的高层，这些客户一般处在行业前沿，且与公司关系好，因此可以从中得到最前沿和最真实的需求信息，通过引导、整合以及过滤来获得价值需求。采用社交软件(IM)与客户保持长期沟通，也是获得高价值需求的一种有效方法。通过仔细选择，邀请所选客户中的相应角色，可以了解到更加详细的需求。 | 可以获得最新最前沿的需求信息。 | 为了保证效果，应根据公司目标细分市场，仔细选择客户。事先确定客户中哪些人员对需求最有发言权，并说服客户选派这些人选参与。 |
| 14 | 销售/投标 | 公司销售人员随时与客户保持联系，建立沟通例会，定期拜访，通过销售项目与客户进行交流，参与市场投标，对客户提出的标书进行分析，可以获得需求收集机会，可通过销售周报的方式提交市场需求，对于重大的需求应直接提交需求管理团队。 | 可以获得大量准确的客户需求。 | 这种方法收集的都是短期或紧急需求。 |
| 15 | 展会与行业交流 | 参加行业展会或客户交流会有助于获得业界的认知，提高公司信誉，吸引新的客户。也提供了与客户交流、收集业界与竞争对手情报的机会，应安排参会人员进行主动的市场需求信息搜集。市场敏感度高的参加者在与会期间经常考虑的是能否产生新的产品包需求。如果发现了可能的产品包需求，需在出差报告中记录下来并及时呈报。所有参展参会人员的出差报告中应包含产品需求的内容。 | 展会是获得客户需求的一种间接方式，为吸引新客户、会后交往提供了机会。 | 参加展会和行业交流属于市场营销活动，重点在于提高知名度，获得行业信息和竞争情报。客户需求并非关注重点。 |
| 16 | 客户满意度调查 | 客户满意度报告属于公司级项目，通过它来获得有关客户满意度方面的输入，确定竞争中的优劣势。可指定第三方公司来收集客户对公司及竞争对手的反馈，对自身及对手的竞争表现进行分析和汇报。各业务部门利用这些调查结果来确定行动计划与未来计划。从需求收集的角度来看，客户调查从公司层面提供宏观的输入，可以从客户满意度调查反馈表中了解到有关产品层面具体需求的反馈，公司可以针对这些需求采取积极的应对措施。 | 客户满意度调查覆盖广泛客户，为公司绩效提供系统的衡量。调查结果对公司与业务部门规划都非常有用。 | 客户满意度调查从公司整体角度获得宏观的输入，对产品级的反馈较少。 |
产品及解决方案的开发需要一定的开发周期，过多的短期或紧急需求会导致频繁地需求变更，对产品质量、研发成本的控制不利。因此，市场需求搜集应重点关注中长期需求，尽量避免短期紧急需求。
除了被动收集市场需求外，应主动开展市场需求搜集活动，建立客户需求收集的例行机制。
对搜集的需求经确认是产品缺陷的，应转入缺陷管理流程进行处理。
需求搜集活动应纳入项目部门和功能部门的KPI体系及员工绩效管理系统。
6.2需求分析
市场需求分析由RAT团队负责。对于市场原始需求，通过系统整理成为可验证的OR需求，再分解转化为可实现可测试的设计需求。
需求分析的途径包括：从分析人员以及公司内部员工的视角进行分析；从客户的视角进行分析，这是分析的关键。发现客户在以下方面的感受：欲望和需求，从在评价拟购买的产品到最后的使用阶段；公司在这些方面上的表现；与竞争对手在这些方面的表现进行比较。基本的步骤包括对市场需求的解释、过滤、检视等系统整理，以及对市场需求的分类、分解、排序、确认等深入分析。
对收集到的市场需求，应首先进行系统的整理，包括解释、过滤和检视。根据对客户原始陈述和需求提交人的解释来补充和完善需求描述。解释客户原始数据能使RAT团队更好地理解客户的整体需求，提高相关环节对需求理解的一致性。
通过需求过滤，进行简单归类，剔除原始信息中的冗余部分，去掉重复需求、无效需求、错误需求及非需求项。原始的冗余信息可以由需求管理员(RMO)在需求管理IT系统中进行直接的关闭处理。
需求描述应遵循准确性、一致性、完整性、可实现、可验证的原则。通过从这些原则的角度对市场原始需求的检视，可以进一步深化对市场需求的理解，逐步将众多需求逐步筛选/归类为所需的对产品和解决方案的包需求(OR)，去除或修正错误、歧义、不一致、不完整、不可信的市场原始需求。
对OR需求应从多个维度(时间、业务分层、客户需求要素等)进行必要的分层和分类，并记录分层分类结果，以利于分析和决策。
从时间角度，可分为紧急需求、短期需求、中期需求和长期需求。这样的划分有利于确定对需求分配路径作出决策，也有利于对需求实现的时间计划进行评估。
从业务分层的角度，可分为服务与咨询需求、解决方案需求、产品需求、平台与组件需求、关键技术/基础技术需求。这样的分类有利于分析出需求如何实现，以及需求实现的途径和代价。
从客户需求要素的角度，可采用$APPLEAS方法进行需求分类，分为以下八类：
$价格：客户为一个满意的产品/交付希望支付的价格。要从实际和感觉两方面来考虑客户能接受的购买价格。包括以下的数据评估：技术、低成本制造、物料、人力成本、制造费用、经验、自动化程度、简易性、可生产性等。
A保证：在可靠性、安全和质量方面的保证。要考虑客户在可预测的环境下关于减少其关注确定的性能方面如何评价整个产品，包括保证、鉴定、冗余度和强度。
P性能：对交付物期望的功能和特性。要从实际和感觉两方面来考虑有关功能和特性的产品性能。产品工作得怎样？是否具备所有必须的和理想的特性？是否提供更高性能？从客户角度来衡量，如速度、功率、容量等。
P包装：期望的设计质量、特性和外观等视觉特征。就软件而言它描述了交付或提供的功能包。要考虑客户对外形、设计等意见，及这些属性对交付的期望的贡献程度。关于包装的考虑应包括样式、模块性、集成性、结构、颜色、图形、工艺设计等方面。
E易用：交付的易用属性。要考虑客户对产品的舒适、学习、文档、支持、人性化显示、感觉的输入/输出、接口、直观性等方面的考虑意见。
A可获得性：客户在容易和有效两方面的购买过程(例如：让客户有他自己的方式)。要考虑在整个购买过程的优秀程度，包括预售的技术支持和示范、购买渠道/供应商选择、交付时间、客户定制能力等。
L生命周期成本：所有者在使用的整个生命周期的成本。要考虑安装成本、培训、服务、供应、能源效率、价值折旧、处理成本等。
S社会接受程度：影响购买决定的其他影响。要考虑口头言论，第三方评价、顾问的报告、形象、或行业的标准、法规、社会认可、法律关系、产品义务等对购买决定起了怎样的促进作用。
需求排序可以采用$APPLEAS方法。$APPEALS方法从多个维度，不同的权重来分析需求，联系到细分市场和竞争对手，涉及到差异化分析和蓝海的价值创新(减少，增加，剔除，创新)，是理解市场和分析市场中的一个重要内容。使用客户$APPEALS框架来确定客户的欲望与需要，可以建立针对每一个细分市场的产品和解决方案包对应图。建立客户$APPEALS框架的目的主要包括：处理目标细分市场的全部客户欲望与需要；建立客户驱动的需求集，作为投资的重点；确定要想在所选细分市场获得成功必须达到的主要分界标准；确定促使客户选择公司产品的主要差异。
$APPEALS方法涉及很多内容，首先是要通过用户调查收集具体的用户最关心哪个维度的问题，根据这些调查数据来确定每个维度的权重；其次是要分析本公司和竞争对手公司的产品在现阶段$APPEALS各个维度的评分，然后是画出相应的雷达图进行差异化分析。根据公司的战略目标和市场策略，应该重点关注哪些核心功能和核心需求，如何减少自己的弱势并提升自我优势以体现差异化，如何进行价值创新等。
通过$APPEALS分析，可以设定客户需求要素每个评判维度的重要性和权重，确认客户购买标准和需求的优先次序：必备需求、更满意的、可选需求等。
为进一步确保需求的可实现性和可验证性，市场需求应根据相关标准细化到一定的颗粒度，应对复杂的需求进行分解。也可以从产品和解决方案的角度对市场需求进行进一步的阐述和细化，转化为产品及解决方案的需求规格，即设计需求(DR)。为确保需求的可实现性，需要进行需求评估，包括技术评估(是否可以获得相应的技术，代价如何，是否存在难以逾越的技术障碍，架构是否支持，平台是否可以继续重用)、工作量评估、进度估算、成本估算及确定适当的质量目标。
在需求分析完成时，还需要通过与市场需求收集人或客户进行进一步的沟通，以确认最终分析完成的需求是否符合市场实际和客户期望。最后，RAT汇总市场需求分析结论(包括OR和DR描述)，提交RMT进行需求评审决策。
6.3需求评审
对于零散的市场需求，RAT定期将需求分析的结论和建议汇总，提交RMT评审。对于产品及解决方案包需求，应系统整理形成相关文档，提交RMT评审。
RMT主任根据市场优先级、需求的重要性及紧急程度等评估是否发起及采取何种方式进行评审。
RMT例行召开市场需求评审会议，进行集中的需求决策评审，并记录评审结论。也可以采用网络评审方式，在需求管理IT系统中发起评审，由各RMT成员在需求管理IT流程中进行意见反馈和讨论，由RMT主任汇总各RMT成员意见完成最终决策。
对于重大的市场紧急需求，由RMT主任召集临时会议进行决策。
在需求评审中，应采用$APPLEALS方法进行客户购买标准分析。通过$APPLEALS方法可以分析出各细分市场客户是不是对价格都很敏感，影响客户决定购买的要素是哪些，以及对各关键要素的敏感度分析。通过这种分析和评估，可以针对目标细分市场得出对需求优先级的判断，确定评审结论。
对于一些重大的客户需求，应客户要求，可能需要在给客户的交付计划方面作出市场承诺。客户需求承诺应严格按照RMT需求决策的结论并考虑一定开发延期风险因素来答复客户，并要记录在案(需求管理IT数据库系统中记录并跟踪)，严格履行承诺。市场需求承诺应根据RMT的授权，由销售客户经理、行销经理、技服经理向客户进行正式的反馈。
应制定《市场需求评审Checklist》来指导需求评审，通过检查表的方式进行全面规范的评审。
6.4需求分配
根据RMT市场需求评审的结果，对市场需求进行分配。
市场需求分配的路径如下：
对于所有接纳的市场需求，应分发至市场管理流程(MM)，进入产品规划，形成或刷新产品及解决方案的包需求，重大需求应进入或刷新业务计划书(BP)和项目任务书(Charter)，供投资决策评审。
对于已接纳的重大中长期需求，应分发至产品及解决方案的路标规划（Roadmap），纳入未来的产品及解决方案版本。
对于涉及正在开发项目的短期和紧急需求，应分发至正在进行的产品及解决方案的开发项目，并启动产品需求变更。根据产品需求变更对开发项目的影响程度启动项目计划变更请求(PCR)，对于在研项目超过20%工作量影响的，应启动PCR，进行投资决策评审；小于20%影响的，由项目组进行项目变更控制。
对于涉及到未来关键技术的市场需求，需要进行技术开发或外部合作以获取关键技术，这类需求分发至技术规划或技术开发项目，并刷新技术规划路标及技术项目需求包。
市场需求分配由需求管理员(RMO)启动操作，下发任务书到相关责任团队。
6.5需求实现
市场需求经需求分配后，不管是进入市场管理、产品规划、业务计划、项目任务书，最终都是进入产品及解决方案的研发项目或技术研发项目，通过开发流程实现需求。
在研发项目中的需求实现是在项目经理和系统工程师主导下由研发团队负责。具体由系统组负责产品包需求(OR)的验证、分析和整理，定义设计需求(DR)，定义和评估备选概念，进行系统设计(系统架构、总体方案、设计规格、各子系统详细需求)，由开发团队负责详细设计和实现，测试组和系统组进行评估、设计验证和测试。
在需求分析过程中已完成将一些复杂需求分解成设计需求和产品规格以评估开发工作量、技术可行性、开发成本、风险等。在需求开发阶段，应通过需求工程和系统工程的有机融合方法将市场需求分解转化为更加细致的产品需求规格（即设计需求），补充完善内部需求(如：DFx等)，完善架构设计、平台重用，对开发工作量、进度、成本因素、质量因素、技术风险、知识产权等进行权衡分析，确保需求与设计的协同一致。
对于RMT决策分发到当前处于开发状态的产品研发项目的，应进行需求变更控制。具体包括由系统工程师提交需求变更申请，包括对工作量、进度、成本等影响的评估，由项目经理组织决策并实施项目需求变更控制，协调更改项目计划、成本、定价、产品资料、市场资料等一系列项目变更。小于20%影响的项目需求变更可以由项目经理决策，对于超过20%影响的项目需求变更还应通过投资决策委员会的批准。
在需求实现过程中，由系统工程师及系统组负责需求跟踪和确认。
6.6需求验证
在整个研发流程中应对客户原始需求、市场需求、产品包需求、设计需求、设计规格进行持续验证、确认和跟踪。需求的验证和确认(V&V)主要由系统组及测试组承担。
在需求分析阶段，应确认产品包需求与客户原始需求(欲望、所想所需)是否一致。
在产品上市发布前的一般可获得性评审阶段，应确认最终交付的产品包是否满足客户原始需求(欲望、所想所需)。
在产品概念、计划阶段或系统设计阶段，应分别对市场需求、产品包需求、设计需求、产品规格书等进行验证，包括需求早期确认、例行需求确认、需求常规确认。
在开发阶段，应对开发需求进行验证，并对开发交付包进行系统的测试。
具体验证和确认可以通过技术评审、检视、评估、测试的方式进行，RAT应参与产品及解决方案研发过程中的各项技术评审(TR)活动。
7、销售项目的需求管理
在销售项目中，需求承诺的接纳处理责任主体是RMT，产品及解决方案的研发团队无权接受来自行销、销售、技服直接反馈的客户需求承诺。
所有销售项目的需求承诺必须以正式和规范的方式(如：录入需求管理IT系统、提交市场需求收集表)传递给RMT，邮件、电话、传真等方式只能作为必要的沟通手段。
所有销售项目需求的对外答复必须以面向市场发布的产品功能清单、市场技术指导书(或销售指导书)为基础，对于功能清单未包括的需求，必须经过RMT给出答复口径，才能对外答复和承诺。
未经RMT批准的答复和需求承诺，发生任何客户投诉时，由擅自承诺的行销、销售或技服部门承担责任。
销售项目从投标阶段到交付和维护阶段应设立需求管理接口人角色来负责客户需求收集和需求承诺管理。
需求管理接口人负责受理投标项目组成员提交的标书不满足项和需求，负责监控、推动RMT提供对标书不满足项和需求的答复、承诺、解决方案及相关技术资料。
需求管理接口人应负责将销售项目中的需求录入需求管理数据库IT系统或填写《市场需求收集表》提交RMT，负责对销售项目中的客户需求和承诺的闭环管理。
在合同签订后的交付和维护阶段，销售项目需求管理接口人应对项目需求承诺的开发状态进行监控，存在交付风险时应组织与RMT、开发团队、产品经理沟通协商解决。
在进入新的行业细分市场、新的区域市场、新的国家或地区市场时，需求管理接口人应推动相关的行销、销售、技服团队将管制、地区标准、互操作性要求等所有需求调查、分析清楚，作为销售项目的需求录入需求管理IT系统或填写《市场需求收集表》提交RMT。
8、需求管理的IT支持系统
为提升市场需求管理的效率，应提供对市场需求管理的IT数据库支持系统。
通过IT技术可以实现全公司需求管理活动的协作共享。市场需求管理涉及公司多个业务部门、功能部门及分支机构，需求管理IT支持系统应支持跨地域的分布式接入、数据的同步更新及协作处理。
需求管理IT系统支撑在需求传递过程中起非常重要的作用。通过需求管理数据库，可以实现对需求的录入、检索、分类、整理、评审和跟踪。
需求管理流程IT支撑系统的价值：
统一的版本需求管理流程：无论是外部客户需求、市场规划需求都使用相同的流程，统一评估，统一规划，确保需求的开发与业务目标发展一致。
实现需求管理端到端状态的可视化：需求记录包含丰富的信息，包括变更的记录，使得市场部门、研发产品管理部门和研发团队能够及时了解需求所处的状态，减少多方沟通的时间，并能够及时的向客户传递相应的信息，提高客户的满意度。
需求信息的集中管理：每条需求都有相应的属性，如客户优先级别，所涉及的产品模块等，需求开发时间等。有了这些信息，市场部门和研发团队可以定制各种报表对需求进行查询、过滤和排序，多角度的了解需求的状况。
全球同步进行需求管理：市场部门及研发团队可能分布在不同地点，但是所有相关人员可以通过WEB的方式访问需求，进行需求的沟通。
9、需求管理的质量保证
市场需求管理流程是公司的核心业务流程之一，QA应定期审计需求管理流程的执行效果，提出过程优化和改进建议。
10、附件：
《市场需求采集表》
《产品包需求(OR)开发指导书》
《产品设计需求(DR)开发指导书》
《需求跟踪矩阵》《需求分配表》
《项目需求变更请求》
《需求验证表》下载本文
