很多项目和产品在开始之前已经注定了失败，并不是这个项目经理不努力，而是这个项目本身就是一个错误的开始，一个成功的项目需要满足受众的需求，而了解这些需求离不开需求管理这一必要环节。

如果一个项目经理和PMO从来没有关注过，只盯着项目执行，那一定不是一个好的项目管理者。

今天分享给大家有关需求开发和管理的规范，希望对大家有所帮助。

第一章 目的

本需求开发及管理规范的主要目的是为指导项目组进行需求分析和管理，从而达到以下几个方面的目标：

1. 确保需求的准确性和完整性

通过对产品需求进行约束和规范化，结合市场和用户的反馈，项目组可以更好地进行需求分析并将产品需求转化成开发需求，从而确保需求的准确性和完整性。

2. 提高开发效率和产品质量

规范化的需求开发和管理可以为开发人员提供更清晰的开发方向，并通过需求优化和补充提升开发效率和产品质量。

3. 确保需求的一致性和可追溯性

通过规范化的需求变更管理、需求跟踪，以及可监控的需求开发过程，可以确保工作产品与需求的一致性，并且使得需求可追溯。

4. 提高项目透明度和可信度

通过需求的规范化管理，项目组成员能够更清晰地了解项目进展并更好地识别潜在的问题和风险，因此，规范化的需求开发和管理可以提高项目的透明度和可信度。

5. 促进需求与开发之间的协作和沟通

通过规范化的需求开发和变更管理，可以促进需求与开发之间的协作和沟通，确保需求与开发之间的高效沟通和合作。

本需求开发及管理规范旨在将需求变成为一切的前导，促进计划、设计、开发和测试等过程中需求的准确性、完整性、一致性和可追溯性，从而确保项目的成功完成，并以高质量的产品满足客户的期望。

第二章 范围

适用于公司立项开发的所有类型的业务类、运营类、研发类项目，包括软件开发、硬件开发、系统集成、项目实施等。

第三章 角色与职责

第四章 入口准则

lMRD、PRD评审通过，立项申请审批通过；

MRD和PRD的评审通过，代表产品需求已经得到公司和团队的认可，同时立项申请审批也通过了，产品已经开始正式开发了。

l需求变更时，技术分析及商务分析完成，产品经理更新了PRD。

需求变更时，需要进行技术分析和商务分析，确保变更需求的合理性和可行性，同时需要产品经理及时更新PRD，以便开发团队能够及时获得最新的需求文档，进行二次开发。

另外还需要有：

1. 需求分析报告：需求分析报告是产品需求分析的重要输出，也是需要在产品开发过程中反复使用的重要材料。因此，在开始产品开发之前，需要对需求分析报告进行评审，确保需求文档的准确性和完整性。

2. 市场调研资料：市场调研能够为产品需求分析提供重要支持，产品经理需要收集和分析市场调研资料，包括用户需求、竞争对手、行业趋势等信息，进一步完善产品的定位和需求文档。

3. 用户反馈：在产品实际使用过程中，用户的反馈和建议是产品改进的重要来源，需要对用户反馈进行定期收集和分析，及时更新PRD，进一步优化产品需求。

第五章 输入

1. MRD和PRD是产品需求分析的重要输入，包括产品定位、功能需求、业务需求、用户需求等。

2. 研发需求库包括全部已经收集和分析的需求，为产品开发提供重要支持。

3. 企业标准和认证标准、规范是为规范和保证产品开发质量的重要基础材料。

4. 竞争对手产品资料提供对市场环境的分析，帮助产品不断优化和改进。

5. 国家政策、法律法规的遵守是产品开发必须的基本法律和道德要求。

6. 任何与用户需求相关的材料均可以成为产品需求分析的重要输入。

第六章 流程图

第七章 主要活动

需求开发的目的是通过调查与分析，将产品需求转化为产品开发需求。需求开发的主要活动包括：需求获取、需求分析和需求定义。

需求管理的目的是在客户与项目组之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。 需求管理的主要活动包括：需求确认，需求跟踪控制和需求变更。

1.1 策划需求开发及管理活动

MRD、PRD评审通过，立项申请审批通过后，项目经理负责向研发中心总经理申请并协调系统工程师资源，对需求开发及管理的活动进行策划，并体现至项目计划中。

系统工程师可由一个人组成，也可由多人组成，当系统工程师有多人时，成立系统组，项目经理需要明确系统组负责人，该负责人负责组织开展需求开发工作，对系统工程师负责的需求范围进行分工。

1.2 需求获取

需求获取的目的是通过各种途径获取产品开发需求。需求获取的质量，对后续的需求分析和需求定义工作将会产生重大影响。

1.2.1 明确需要获取的信息（What）

系统工程师应在需求获取前明确需要获取的需求信息，以确保在实施需求获取时有的放矢。

通常需求获取需要收集的信息包括但不限于以下几点：

l与产品需求相关的背景信息（如市场信息、应用场景等）；

l与产品需求直接相关的信息；

l对产品的特别期望与施加的任何约束信息。

1.2.2 明确所需获取信息的来源与渠道（Where）

系统工程师在明确了需要获取的信息之后，应确定获取需求信息的来源与渠道，以提高需求获取阶段的工作效率，使得所收集的信息更加有价值、更加全面。

需求信息的来源包括但不限于：

• 市场需求MRD；
• 产品需求PRD；
• 研发需求库；
• 公司战略层面的商业规划需求；
• 公司技术发展的需求；
• 老用户或客户提出的旧产品缺陷，需要在新品上避免的；
• 竞争对手的产品优势与不足；
• 国家政策、法律法规、相关行业标准、企业标准；
• 实施产品设计所需满足的需求；
• 执行测试验证工作所需满足的需求；
• 实施产品生产、使用、维护所需满足的需求；
• ……；

获取需求信息的渠道包括但不限于：

• 从上游产品部提供的资料中获取；
• 与产品经理进行沟通，在产品经理无法解答的情况下，与应用开发、市场、销售、售后、生产及维修人员甚至客户交谈，提问题；
• 从研发需求库获取；
• 从网络上搜查相关资料；
• 从出版物中提取信息；
• 与同行、专家交谈，听取他们的意见；
• 分析已经存在的同类产品；
• 认证机构提供；
• ……；

1.2.3 获取需求（How）

在明确需求信息、需求的来源与获取渠道后，系统工程师应选择至少一种需求获取技术获取相关的需求，作为需求分析的依据。需求获取技术包括但不限于：

1)需求调查

调查需要精心设计，以问卷形式展开，下发到调查对象（如市场、销售、售后人员、应用开发、生产及维修人员）手中，让调查对象填写答案来获取需求。

此方法最大的缺点是缺乏灵活性，由于缺乏面对面的交流，所获取的信息量也比较有限。因此在实际工作中，我们建议可以先采用调查的方式获取一定量的信息，然后有针对性地开展访谈。

2)访谈

与产品经理、市场、销售、售后人员、应用开发、生产及维修人员进行访谈，必要时可与客户、终端用户进行访谈。

访谈的形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题，有针对性地进行问答；非结构化是指列出一个粗略的想法，根据访谈的具体情况进行发挥。有效的访谈需要灵活的结合这两种方法。

访谈具有很好的灵活性，有较广的应用范围，但实际操作时存在许多困难。需要系统工程师有很强的沟通能力，同时也要求系统工程师有足够的相关业务领域知识。

3)从行业标准、行业规范中提取需求

如果要开发的产品必须满足一定的行业标准和行业规范，系统工程师可以通过阅读国家政策、法律法规、行业标准以及企业标准等各类相关的文档，并与相关领域的同行、专家进行交流来了解需求。

这种方法要求系统工程师有一定的行业从业经验，能够了解行业的发展动向。

4)文档考古

对于一些功能模块较多，内部处理流程比较复杂的产品，有时是难以通过说或者观察来了解需求细节的。这个时候就可以通过对历史存在的一些文档进行研究。其主要的工作重心是评审通过并且已经填写完毕的，也就是从已有的研发需求库、产品文档、表单、报告，获得所需的信息。

5)需求讨论会

需求讨论会是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个客户代表（市场、销售、售后、应用开发、生产、维修等）、分析人员、开发人员，通过有组织的会议来讨论需求。

在会议之前，应该将与讨论主体相关的材料提前分发给会议相关人员。在会议开始之后，先针对材料所列举的问题进行逐项专题讨论，然后对原有产品、类似产品的不足进行开放性交流，并在此基础上对新的解决方案进行构思，在此过程中将所有的想法、问题和不足记录下来，形成一个要点清单，作为后续需求分析的依据。

6)原型法

原型（prototype）即把产品主要功能和接口通过快速开发制作为“演示样机”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。同时，原型也可用于征求内部意见，作为分析和设计的接口之一，可方便于沟通。

原型法主要价值是可视化，强化沟通，降低风险，节省后期需求变更的成本，提高项目成功率。

原型法的基本步骤：

l根据MRD、PRD或合同要求等文档，确定产品要做什么，即产品的边界、主要业务或功能、产品的接口；

l根据这些需求，形成产品原型。对于所形成的原型的基本要求包括：

ü体现主要的功能；

ü提供基本的界面风格；

ü展示比较模糊的部分，以便于确认或进一步明确，防患于未然；

ü原型最好是可运行的，至少在各主要功能模块之间能够建立相互连接。

l进行原型评价并获取需求，原型评价可以从几个方面进行：

ü在公司内部演示、评审，进一步获取内部信息，并求得共识

ü与用户进行演示与交流，挖掘用户需求，从而确定产品的目标和需求

l根据原型评价的意见来修改原型，直到取得共识

原型法的优点是：

Ø鼓励管理者的积极参与；

Ø有助于解决管理者之间的差异；

Ø能给管理者一个对最终系统的直观感受；

Ø周期短；

Ø成本低；

Ø用户较满意。

原型法的缺点是：

Ø导致人们认为最终产品将很快产生；

Ø对产品操作权限的说明较弱；

Ø不适合于开发大产品；

Ø开发过程管理困难。

7)用户试用

用户试用是指在产品开发到一定程度，具备了基本的功能及性能的情况下，提供给客户试用，收集客户的反馈，记录客户提出的问题以及不足，分析得出现有产品需要改进的部分，同时识别新的需求。

用户试用过程中可同时制作并发放客户试用调查表，要求客户在试用过程中将试用体会填写至试用调查表中。

1.2.4 需求获取资料的保管

根据所采用的需求获取技术，在需求获取过程中将产生不同的记录和原始资料，项目组应将这些

记录纳入开发库进行配置管理。需求获取的记录与资料包括但不限于：

lMRD；

lPRD；

l需求的商务及技术可行性分析报告；

l调查及访谈的记录；

l需求研讨会的会议纪要；

l相关的国家政策、法律法规文件、行业标准文件、企业标准文件；

l需求原型；

l认证规范；

l竞争对手资料；

l用户试用调查表；

l……

1.3 需求分析

需求获取完成后，系统工程师要对需求获取所得到的记录与资料进行整理，并对需求获取到的信息进行分析，进一步细化需求，主要从以下几个步骤进行分析、细化：

1.分析系统边界，识别系统需求，包括

Ø功能需求

Ø性能需求

Ø客户使用需求

Ø本系统的外部接口需求

Ø本系统的内部接口需求

2.分析每个子系统的需求，即硬件子系统、软件子系统、结构子系统的需求

3.细分每个子系统模块的需求，如MODEM/IC等

4.明确每个需求的充分必要条件，识别隐形需求、非功能性需求

5.分析产品外围需求，识别测试、生产、包装、维护、安装、文档等需求

6.分析并建立各需求元素之间的关系

1.4 需求定义

需求定义的目的是根据需求获取和需求分析的结果，进一步定义和细化产品需求，产生《产品开发需求说明书》。

1.4.1 标识需求

为了确保需求易跟踪、易修改：

l项目经理应将MRD及PRD文档提交至PLM系统，通过文档编号（PLM） 版本号的方式对每一个版本的MRD及PRD进行唯一标识，并将MRD及PRD的标识记录于《产品开发需求说明书》中。

l针对细化并写入到《产品开发需求说明书》中的开发需求，需要参照《研发需求库》中的编码规则对需求进行编码：

注：针对取自《研发需求库》的共性需求，需要与需求库编码对应，不得做修改。

l在《产品开发需求说明书》中应明确需求跟踪的力度。

1.4.2 定义需求的优先级

系统工程师应确定每个需求的优先级并写入《产品开发需求说明书》，需求的优先级的评价标准如下：

优先级的定义有利于帮助项目组在项目的范围、进度、资源、预算等相关制约因素之间产生冲突时，能够正确地对需求实现的范围或实现的优先程度做出取舍。一个实现这种权衡的方法是：当接受一个新的高优先级的需求或者其它项目环境变化时，删除低优先级的需求，或者把它们推迟到下一版本中去实现。

1.4.3 编写《产品开发需求说明书》

系统工程师在需求分析过程中根据分析步骤逐步细化、完善，编制形成《产品开发需求说明书》。编写过程中应遵循以下规则：

l相关的需求都得到了识别与描述，以确保需求的完整性；

l各个需求之间不冲突，以确保需求的一致性；

l正确描述系统需求，引用的资料有正规的出处，以确保需求的正确性；

l定义必要的术语，适当结合图形、结构图等方式进行描述，以确保需求无二义性；

l使用较好的文档结构与需求标识，使需求能够方便地与其它工作产品相对应，以确保需求易于追溯；

l确保所描述的需求可以通过适当的手段得到验证，即需求的可测试性；

l考虑了各个层次的需求，确定了需求的优先级，以确保需求的可行性；

l从《研发需求库》中抓取共性需求，使用研发需求库对共性需求的编码；并参照《研发需求库》的细化程度，细化需求。

1.5 需求评审

需求评审是指项目经理组织相关人员共同对《产品开发需求说明书》进行评审，对需求达成共识。

系统工程师完成《产品开发需求说明书》撰写后，提交给项目经理，由项目经理组织相关人员进行需求评审。

需求评审可采用分阶段评审以及集中评审两种方法：

l项目组根据需求定义的进展情况，采用分阶段评审的方式对需求定义的阶段成果进行评审，分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。

l也可在需求完全定义完成后，对需求文档进行整体评审。

关于评审的过程详见《技术评审规范》。

1.6 需求确认

需求确认是指在项目开发过程中，通过一系列的活动对需求进行确认，主要有以下目的：

l确保开发实现与需求的一致性；

l识别新的需求；新需求识别后，依据本规则执行需求变更。

需求确认的活动需要在项目计划中体现并进行跟踪。

需求确认的活动一般包括调试、模拟用户环境的测试、用户试用、验收测试等。项目开发过程中，除产品开发主流程定义的与需求确认活动有关的活动（如调试、模拟用户环境的测试等）外，还需要执行以下活动对需求进行确认：

1、需求分析完成并且输出《产品开发需求说明书》之后，项目经理需要组织需求提出方（如产品经理、市场、销售、售后、应用开发、生产、维修人员甚至客户等）对需求进行讲解、澄清，由需求提出方对需求进行确认，确保开发需求的正确性；可采用邀请需求提出方参与《产品开发需求说明书》评审的形式来进行；

2、项目开发到一定阶段，输出原型机、工程样机之后，项目经理应组织产品的需求方（如产品经理、市场、销售、售后、应用开发、生产、维修人员甚至客户等），召开样机演示会议，同时邀请测试人员参会，对开发的成果进行演示，由需求方对需求进行确认；

3、在项目结项前，项目经理需要协调产品的需求方（如产品经理、市场、销售、售后、应用开发、生产、维修人员甚至客户等），提供样机给需求方进行验收测试，并收集验收测试的结果，验收测试通过后才能进行结项。

1.7 建立需求基线

《产品开发需求说明书》经过评审与确认后，配置管理员应根据《配置管理规范》的要求建立需求基线。

1.8 需求跟踪控制

当需求确定下来以后，应该保证在设计过程中每个需求都被实现，且项目的其它工作产品与需求保持一致。因此，一个比较好的方法就是建立一种需求双向跟踪机制。双向跟踪即：

l正向跟踪：建立需求到工作产品的对应关系，从用户需求到产品需求，从产品需求到工作产品，从工作产品到测试用例等；目的是检查每个需求是否都能在后续的工作产品中找到对应点。

l逆向跟踪：与正向跟踪相反，建立工作产品到需求的对应关系，目的是检查设计文档、代码、测试用例等工作成果是否都能在需求中找到出处。通过从下游工作产品回溯到需求，可分析需求是否得到满足，从而达到回溯的目的。

进行需求双向跟踪的一个简单的方法是建立一个映射，从需求到设计，从设计到实现，从实现到测试用例，把每个需求都映射到对应的位置。这个映射可以用《需求跟踪表》来实现。

1.8.1 建立《需求跟踪表》

当《产品开发需求说明书》评审通过之后，项目经理应安排系统工程师编制《需求跟踪表》，由系统工程师协调项目成员完成如下工作：

l根据确定的需求跟踪力度，将需求信息填写到《需求跟踪表》中，并对《需求跟踪表》的需求进行复查，确保跟踪力度合理、跟踪项适用，

l系统工程师同时需将本项目共性的需求在《需求跟踪表》中标示出来，说明哪些是取自需求库的，哪些是本项目新增的可提取到《研发需求库》的共性需求。

1.8.2 《需求跟踪表》的维护

随着开发的不断推进，项目经理应安排人员在项目的各个阶段成果形成时，将相关的信息填入《需求跟踪表》，建立阶段工作产品与需求的对应关系，并对其完整、正确、一致性进行确认，具体分工如下：

l系统工程师负责将总体设计成果填入《需求跟踪表》，建立与需求的对应关系；在需求发现生变更时，更新《需求跟踪表》；

l软硬件工程师负责将概要设计及详细设计成果填入《需求跟踪表》；

l测试工程师负责将每个需求对应的测试用例编号、测试责任人及测试结果填入《需求跟踪表》；

l在项目每个里程碑时由项目经理负责对需求跟踪表的完整、正确、一致性进行确认，项目结项时输出完整的《需求跟踪表》。

1.8.3 《需求跟踪表》的使用

在项目实施过程中，项目组可以利用《需求跟踪表》实施相关的控制，如：

l利用《需求跟踪表》，审核所有定义的需求是否已经在相关产品中得到实现；

l当发生需求变更时，可以利用《需求跟踪表》来确定需求变更影响的其它工作产品，确保不忽略每个受到影响的系统元素；

l相关的工作产品产生变更时，可以向前追溯到与其相关的需求与其它工作产品，从而判断是否需要对这些关联工作产品进行变更；

l在开发过程中，可以对所有定义的需求的当前开发状态进行跟踪；

l对需求的测试用例及测试结果进行跟踪，以确保每个需求都经过测试，同时可以检查测试用例的覆盖程度。

1.8.4 《研发需求库》的维护

在项目的需求开发及管理过程中，QA负责根据项目《需求跟踪表》的建立、维护等活动的输出，对组织级《研发需求库》进行维护，为以后项目的需求开发做积累，主要做以下事项：

l项目建立了《需求跟踪表》后，QA负责将系统工程师识别出来的共性需求提取到《研发需求库》中；

l测试工程师完成测试用例的设计并且将测试用例填写至项目《需求跟踪表》后，QA负责将共性需求对应的测试用例编码提取至《研发需求库》；

l需求发生变更时，若涉及到共性需求信息（包括需求对应测试用例的调整）的更改（新增、修改、删除），项目经理需要知会QA，由QA对《研发需求库》进行维护；

l项目结项前，由QA根据项目输出的完整项目《需求跟踪表》，对已提取至《研发需求库》的共性需求进行核对，确保信息完整准确。

l研发管理部需要定期组织系统工程师（根据需要从系统工程师资源池中轮流抽选），对纳入到《研发需求库》需求的正确性进行定期检查并维护，建议每半年一次，确保给项目正确的参考。

1.9 需求变更

对一个产品开发项目来说，无论最初的需求定义有多么明确，开发过程中的需求变化也还是不可避免

的。这主要有以下几种原因：

l产品所应用的外部环境发生变化；

l用户提出新的需求；

l项目组进行需求分析时未能彻底分析用户的需求，或分析错误；

l用户在开始时不能很全面的知道所需的产品功能。

l外部大环境的变化（如：市场需求或营销策略等的变化）

l公司战略调整

l……

需求变更依据《变更控制流程》执行。

第八章 主要输出物

《产品开发需求说明书》

《产品开发需求说明书 技术评审报告》《评审会议纪要》

《需求跟踪表》

《需求变更申请单》

第九章 退出标准

1. 产品所有功能需求完成并经过质量测试，符合设计文档中的要求及标准。

2. 产品所有业务需求都已经充分实现，并经过了业务流程测试和用户使用测试，符合预期的使用效果。

3. 根据项目计划，产品开发周期已经到达或超过了预期的完成时间。

4. 产品经理和开发团队达成一致意见，认为产品已经完成并可以投放市场或使用。

5. 各项评审机构已经对产品进行了评审，审核通过。

6. 产品在进行代码审查或安全漏洞扫描前，没有任何高、中风险问题存在。

7. 内部测试已经完成并达到满足需求和可接受性标准。

8. 产品的用户文档和操作说明已经完成，并确保易于理解和使用。

9. 所有代码、文档和工程资产均已通过配置管理、版本控制和备份机制进行严格管理和存储。

10. 所有需求变更都已得到记录并处理。

附需求开发管理流程实例供参考：