目录
一．需求管理体系概述 (2)
二．需求管理体系的活动 (3)
1、需求提出、编写需求单 (3)
2、需求评估 (3)
3、需求登记 (3)
4、需求分析设计 (3)
5、填写开发计划 (3)
6、用户测试案例编写 (3)
7、开发测试 (3)
8、提交用户测试 (3)
9、提交运维测试 (3)
10、需求上线 (3)
三．需求管理体系的流程 (4)
四．需求管理体系的问题分析及规范建立 (4)
1、需求管理过程中的问题 (4)
2、问题的解决方案（结合7命题） (5)
(1) 建立需求管理制度 (5)
(3) 需求接收 (5)
(4) 需求评估 (5)
(5) 开发计划定制及跟踪 (5)
(6) 需求开发及发布过程 (6)
(7) 过程持续改进及团队培训 (6)
3、需求管理规范 (6)
一．需求管理体系概述
从实践意义上讲，需求是针对客户各类需求经双方（或多方）沟通确认后形成的一种协议，协议的范围是明确的、可控的。在协议签订后，需求的计划有定制、进度有跟踪、结果有度量。针对需求的变化，需要明确需求变化的原因及变更内容。需求的紧急程度及严重程度可评估，以确定需求及其变更的优先级，从而排定切实可行的需求计划。
项目需求管理的目的，在于管理项目产品及产品组件的需求，并界定这些需求与项目计划及工作产品间的差异。项目实行适当的步骤，确保议定的需求是受管理的，以支持项目策划和执行的需要。需求管理也须记录需求变更及其理由，并维护原始需求与所有产品和产品组件需求的间的双向追溯性。
用户对于系统、需求的理解是渐进的过程，因此某种意义上说需求变更存在必然性。如何有效率和有效果地管理这些新增需求或变更需求是很重要的。如果需求变更控制不当，不但造成新的需求变更得不到满足，而且对于需求进度的管理、对于系统稳定性的影响都将是负面的。变更控制，需要追溯变更的缘由，记录变更的原因、内容，并做好变更比例的度量。保证需求的可追溯性，对于需求变更管理至关重要；在进行需求变更对项目计划、活动及工作产品的影响评估时尤其需要需求追溯表这些管理工具。
需求管理体系规范建立及其优化。在需求管理过程中的各个环节，存在较多的争执点，这就需要制度进行明确。形成一个系统的、规范的制度，使需求管理过程可细化度量；制度的形成需要配备对应的资源，比如需求跟踪工具、需求干系人的培训管理。通过制度保证需求过程可监控、上层管理者可以跟踪需求的进展情况等。
需求管理成本控制。需求开发面临成本投入的现实，需求开发本身、需求管理本身，因需求开发、管理造成的物力、人力消耗都是现实的成本。在日常系统运作中，对于需求必要性的评审，对于系统变更的控制，对于人员的培训都是提高效率降低总成本的方式。
实际项目管理工作中，需求管理工作占据着重要的内容，下面我们结合需求管理的主要活动及流程进行分析、研究，以期建立一套规范的需求管理规范。
1、需求提出、编写需求单
系统用户在项目进行过程中会不断的有新的或者变更的需求提出。需求采用访谈、文档、多方会议等形式采集基础信息，但最终必须由需求提出岗人员整理后编写《补丁需求单》。
2、需求评估
对与需求进行可行性分析，首先应该判断的是需求的内容表达是否清晰，需求是否全面、是否包含关联性需求；其次分析需求带来的收益及成本；另外还需要判定需求优先等级，给出处理意见和建议，不通过评估的可以直接回复给需求提出者，沟通解决需求中提出的问题。
3、需求登记
统一编号并纳入到需求管理库中，同时触发用户编写测试案例工作和需求分析设计工作。
4、需求分析设计
对需求进行详细的系统分析和设计，产出设计文档。
5、填写开发计划
需求计划的定制以用户、开发团队、计划跟踪者协商一致的结果为依据。其过程实质是取得用户对于进度的认可、取得团队对于进度的承诺。其成果物—需求跟踪表，对于后续的需求跟踪起到警示标的作用。
6、用户测试案例编写
通知用户系统开发计划及提交时间，同时督促用户编写并提交用户测试案例及计划。
7、开发测试
开发完成后，编写开发测试案例，提交开发测试环境，进行开发集成测试。
8、提交用户测试
开发测试完成后，提交用户测试环境通知用户测试。
9、提交运维测试
进行上线前的版本验证。
10、需求上线
需求上线运行，进入运维期间。
四．需求管理体系的问题分析及规范建立
1、需求管理过程中的问题
(1)需求管理流程越快越好，需求直接提交给开发部门。
(2)需求提交方式多样，有很多口头或邮件交流内容，存在需求过于简单描述不清
等问题，后续需求管理代价较大。
(3)需求提出时，不够细化或后不够完全，没有考虑整体性和关联性需求；有些需
求只适用于个别分支机构；需求上存在理解差异，待功能交付后，用户提出所
见非所求，造成需求、bug争论不休，需求变更及bug修复频繁，影响系统稳定
并造成成本消耗。
(4)没有划定需求的优先级，需求进度难以控制，过多的争论造成了临时事务增多，
对于需求开发的支持滞后，项目整体进展缓慢，客户满意度较低。
(5)需求提出后，经过一段时间的开发，后续无人跟踪。
(6)需求提出者坚持一项对系统并不合理的需求。
(7)需求反馈速度慢，用户希望及时了解需求开发进度。
2、问题的解决方案（结合7命题）
(1)建立需求管理制度
IT部门、业务部门、以及上级管理部门制定出一套可以严格执行的需求管理体系规范。涉及到领导命题（需要高层领导的支持和参与）、投资命题（需要计划，
配备专职人员以及管理时间和资金投入）、团队命题（需要全体人员的协作和努力）、文档命题、过程命题及效果命题。
向领导层阐述需求管理体系规范的目的：确保业务系统转换及生产环境稳定、最大限度的满足公司正常业务的开展；稳定满足业务流程、规则的变更。按新流程
推进后，可以提高需求质量、系统开发质量，达到保证系统稳定的目的。因为需求
本身质量和开发质量都得以提升，日常争论降低，分析、开发效率都得到提高。
需求管理体系的形成需要配备相应的工具，对于需求的计划跟踪、需求评审、需求质量控制进行有效监控。需要加强人员培训，熟悉相应的工具；需要增加若干
审批环节，增加管理资金投入。
需求管理体系的形成会造成各环节流程变动，对于过往习惯造成影响，这就需要整个团队的适应。需要各部门群策群力，才能将制度落到实处。
(3)需求接收
需求文档提供及分析文档形成也涉及到了文档命题（需求变更文档）支持过程活动
可视化，使得复杂的智力密集的支持过程活动得到有效地控制）。在开发前期形成
双方认可的文档是减少功能交付后争议的有效办法。
(4)需求评估
在需求文档提交到需求管理岗后，需求管理岗会同专家小组，对于需求进行可行性
分析，在评审过程中就可能出现理解的差异需求进行检查，最终形成是否通过该项
需求的决定，并对后续需求提交、分析的质量提出指导意见。评估后，形成评故文
档记录评估意见入库。该部分一般要求有上级领导参与决策。涉及领导命题、投资
命题、文档命题。
(5)开发计划定制及跟踪
在需求经过多方确认后，可根据现有开发团队的人力结合需求的优先级确定需求开
发计划，并将计划登记入需求跟踪表，需求过程进行统一跟踪，各部门均可获取当
前需求的进展状态。如果对于计划有调整需求的，需要有明确的审批机制，评估调
整计划对于项目整体进度的影响，经过相关干系人协调一致后，予以调整。涉及团
队命题、效果命题、成熟度命题。
(6)需求开发及发布过程
需求开发阶段，需要在设计文档、测试文档提供方面进行加强，提高需求开发的整
体质量。需求提交纳入配置管理库，由专人进行版本的更新，在更新时检查对应文
档的提供情况。涉及团队命题、效果命题、成熟度命题。
(7)过程持续改进及团队培训
过程命题：需要仔细地进行过程设计来减轻甚至消除软件支持过程认知障碍并提高
群体认知活动的效力和效率。新流程的形成必然存在一定的瑕疵，因此在流程推进
过程中需要不断总结，消除新流程推进过程中的问题。使各部门消除推进新流程的
顾虑，体现新流程的价值。
成熟度命题（需要不断地组织学习以持续地改进全组织的软件支持过程能力。一方
面团队需要学习新流程推行中需要遵循的规范，另一方面团队也需要接触新流程配
套使用的工具。同时需要不断提升自身业务、技术水平以适应新流程。效果命题：
需要明确地努力和定期地强化其效果。通过不断增加团队的适应水平，使新流程的
效果得以显现，不断的效果显现本身就是对团队的激励，使得新流程的认可度不断
提升。
3、需求管理规范
依据以上分析，我们可以定义出一套新的需求管理体系规范：
第一条为了确保业务系统转换及生产环境稳定、最大限度的满足公司正常业务的开展；稳定满足业务流程、规则的变更；特制定本管理规范。
第二条本规定约束所有需求提出部门、开发部门和需求管理部门。
第三条本规范协助提高需求质量、系统开发质量，达到保证系统稳定的目的。
第四条这里的需求必须是纸质的书面需求，口头需求只能作为讨论依据，最终的需求必须是书面的，需求处理时间以接到书面需求开始。
第五条正式补丁需求变更单提出之前，必须同开发部门及需求管理部门沟通过，重要需求必须召开需求讨论会议，需求涉及到的任何人都可以要求召开需求讨论会第六条经过沟通讨论后形成需求初稿交由需求管理部门需求接收岗审核，需求内容必
须清晰、完整、关联性考虑周到，符合要求后，需求提出岗填写正式《补丁需求变
更单》，不符合要求的，重新打回需求提出岗。
第七条需求标题必须明确，能够概括主要需求内容。需求变更单中的每一项必须实事求是的填写（如紧急程度），完成时间必须是需求提出方、开发部门和需求管理部门
三方达成一致的结果，以支持业务为主，兼顾业务需求、系统稳定和原工作安排。
第八条补丁需求变更中必须考虑需求间的相关性，如果有相关联的需求1，必须说明关联需求的关系。
第九条补丁需求中必须从业务上考虑对其他小组和部门的影响和关联，如果影响到其他部门或者小组的，必须说明。
第十条重大需求需要提供市场分析、投资收益分析评估报告，必要时需总经理室批准。
第十一条分支机构的需求需逐级上报审批，最后汇总到总公司对应部门，由总公司对应部门综合考虑是否全国通用，是否与其他分公司有冲突，是否可以优化；综合
总公司对应部门意见后由该部门向需求管理部门正式提交IT需求。
第十二条需求管理部门不直接接收分支机构的IT需求。
第十三条分支机构的临时数据抓取需求按照需求管理部门运维室的《数据提取》流程。
第十四条对于涉及到硬件设备增加的，需要根据硬件室的要求，提交该需求对应的硬件需求，与硬件室一起提前做好硬件准备。
第十五条补丁需求提出者是需求的所有者，要负责需求的完整性、关联性分析，负责组织需求的讨论、跟踪和测试。
第十六条需求必须经过部门领导审批同意，每个补丁需求必须编写对应该需求的测试案例，且测试案例必须由需求提出者的直接领导或者更高级领导审核签字。
第十七条需求管理部门对补丁需求分配补丁需求号后，需求提出者要开始编写测试案例，版本提交业务测试时测试案例必须编写完整。
第十八条需求处理生命周期：需求在需求接受岗初审完成并分配需求号后，正式进入处理流程，直到需求上正式生产环境。
第十九条需求在IT部门处理过程中，需求提出岗需开始准备测试案例。
第二十条测试案例必须对所提需求的各个功能点及其分支全面覆盖，对有影响的部1关联的需求：指2个或者多个需求
分需增加回归测试2案例。
第二十一条需求分配编号后，需求管理部门软件室对每一个需求必须指定专门的BA 分析师，负责对该需求的BA分析及后期跟踪，每一个需求必须出具处理意见。
第二十二条需求到达开发部门后，在4个工作日内给出需求时间计划安排反馈。
第二十三条开发部门对每一个需求有自己的处理意见和设计思路，重要的需求需要给出需求规格说明书和系统设计说明书。
第二十四条开发部门在自己的开发环境下进行补丁需求的开发，测试通过后定期提交。
第二十五条版本发布岗在接收到程序和需求提出岗的测试案例后，发布版本到UAT 环境。
第二十六条需求提出岗根据实现的测试案例，在UAT环境测试，并记录测试结果，形成测试报告。
第二十七条在所有需求在UAT环境下测试通过后，由版本发布岗发布到STA环境，在STA环境下做上线前的最后测试。
第二十八条全部测试通过后，由版本发布岗定期更新到生产环境上。
2回归测试：指之前测试通过的功能点，但是可能被新需求上线影响，需要针对这类需求所作的测试。
产品管理规范 公司内部编号：（GOOD-TMMT-MMUT-UUPTY-UUYY-DTTI-
产品管理规范 公司管理体系文件编号： 产品管理规范版号： 页码：共21页 编制：日期： 审核：日期： 批准：日期： 1 目的 实现以市场为导向的产品规划，有计划有组织地进行研究与产品开发活动。 有效地调动营销部门以及生产部门的创造性思维，把市场与消费者的认识转换在新产品中，确保产品开发和企业产品战略的一致性，快速、合理应对市场需求，规避产品投资风险，并为企业获得最大限度的利润。 2 范围 本制度适用于本公司产品开发、上线、管理全过程，对产品管理的流程做出规定，是公司管理产品规划工作的依据，各相关营销、生产部门必须遵照执行。 3 职责 产品管理是企业在产品生命周期中对产品规划、开发、生产、运营和支持等环节进行管理的业务活动，包括需求管理、市场管理以及开发管理 4 内容 具体如下： 产品战略规划
产品战略包含：1 产品路线 2 产品策略 3 产品计划 产品研发 产品研发包含：1 需求阶段 2 设计阶段 3 开发阶段 4 测试阶段 5 发布阶段（上线） 产品生命周期 产品生命周期包含：周期管理（1 导入期 2 成长期 3 成熟期 4 衰退期）组织、主要人员及职责 1组织结构 2重要角色 重要角色负责人：产品负责人、研发负责人、产品管理负责人、运营负 责人。 重要角色包括：产品经理（需求提出人）、需求管理员、技术人员、运 营人员。 3其中对重要角色职责及相关要求定义如下： 产品管理会 产品管理会由产品中心、运营中心、产品研发中心总监以及参与在产品生命周期过程中的产品规划经理、用户研究人员、产品负责人、开发负责人、运营负责人等共同组成。 主要职责： （1）制定运营计划，确定运营目标； （2）优化产品，制定运营策略； （3）监控产品质量，把控经营结果；
密级：内部公开 文档编号：SL_RD_XQGLGF 需求管理规范 ------------------------------------------------------------------- XXX科技公司对本文件资料享受着作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
目录
1.目的 为了保证需求得到有效的处理，客户的需求得到准确的理解和实现，同时也为了规范需求的管理过程，明确需求各个阶段的活动和输出，保证项目的开发前 期获得有效的输入，特制订本规范。 2．范围 本规范适用于公司所有产品研发类、产品开发类、合同开发类以及维护开发类项目。 3．术语 4.部门/角色与职责
5.内容 5.1流程图 图1需求开发与管理过程活动示意图
5.2主要活动 需求管理的目的是在客户与项目组之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求管理的主要活动包括：需求确认，需求变更和需求跟踪控制。 （需求的收集和整理） 产品经理作为需求的唯一接入口，应基于现有产品的业务发展方向，通过与用户的交流、问卷调查等方式，收集用户对于该产品业务的看法，并对这些看法进行归类整理和登记，达成口头或者是书面的需求意向协议书。 （这个过程需要对产品的业务建立起一个概念模型，以便对其进行抽象描述。用户很多时候都不懂专业术语，所以需要尽可能的使用场景化的语言描述方式去进行描述。比如想调研用户的理财方式，很多用户可能不清楚“理财”的具体意思，但你问他“平时是如何管理多余的资金，是变成银行存款还是有别的方式？”可能他会更容易明白。） 产品经理就获得的需求意向或者意向协议书，围绕产品的业务核心，进行初步的评估，预判其成本、时间、资源、技术等可行性和必要的风险评估，以确认需求是否要接受。 除了要从收集回来的需求当中找到要做的真实需求外，还要基于需求的业务价值评判出需求执行的优先级。 其评估的过程，产品经理可以召集研发负责人，组织一次需求的分析讨论会，以便对需求更全面的分析。 根据需求调研和需求分析的结果，进一步定义准确无误的产品需求。完成需求的分解工作，并输出产品功能需求文档，包括但不限于以下内容：详细的《产品需求说明书》，《功能列表》，《技术指标参加资料》等。 产品功能需求文档编写完成后，产品经理召集产品设计启动会，向UE、UI、研发人员宣讲产品功能需求，讨论实现方案，启动开发设计工作。 （需求定义的过程更多的是对需求进行准确的描述，从用户使用场景的角度、功能操作流程的角度等方面，对分析出来的真实需求做出完整、无二义性的定义，让其他相关人员能准确的理解需求。） 需求确认是指项目组和客户（或客户代表）共同对《产品需求说明书》、原型等进行评审，双方对需求达成共识后做出承诺。 UI/UE工程师在规定的时间内完成产品设计文档（效果图和原型），召集产品设计评审会（同时也是产品开发启动会），向需求部门、产品经理、研发、测试宣讲产品开发需求，各部门对产品设计文档进行评审确认，达成统一认知和共识，使需求能够推进实现落地。 在需求评审的过程中，一定要说明清楚需求的背景、价值、意义，而不是纯粹的需求讲解，这样有助于各方对需求的理解。 需求确认包含两个重要工作：“需求评审”和“需求承诺”。 需求的评审 应对所形成的需求文档进行评审，以便作为下一阶段工作的基础。需求评审
●理解产品包需求（OR，Offering Requirements）的概念、产品包需求分层、需求工 程方法论 ●如何与其他部门协作采集高价值的用户需求、掌握需求的变化 ●掌握如何用模板和工具来参与并指导相关部门识别、采集高价值的用户需求 ●如何透过需求描述的表象得到的顾客效用与价值，即掌握顾客的心声 ●基于培训和讨论、整理出需求调研访谈指南 ●掌握筛选、解释需求的工具，评审分析市场需求的价值 ●学习如何有效的激励其他部门配合，让需求管理流程形成一个快速畅通的闭环 ●分享讲师在著名企业产品开发、研发管理实践经验和十多年的咨询/培训经验，并 通过现场的互动和全方位案例资料（如：流程、模板、查检表等）的展示帮助学员“学以致用”，理清适合自己企业在产品需求管理方面的工作思路以及具体的实践方法和工具。 客户的需求不断变化，如何快速高效地推出满足客户需求、具有差异化优势和竞争优势的产品，并最终获得市场的成功，是企业的核心问题！我们发现国内许多科技型企业在产品需求管理方面存在如下问题： 1. 产品开发没有实现市场驱动，是“闭门造车”，关注技术而不关心客户；产品开发出 来后才找客户、找卖点； 2. 缺乏完备的需求收集、汇总、整理和分析机制，导致研发和市场脱节，需求无法有 效传递和落实，相关环节和部门（如：客户、市场部、开发部、测试部等）对需求 的理解也不一致，经常针对需求“吵成一锅粥”； 3. 对客户/市场需求分析不充分、不透彻、不完整，导致产品需求变化频繁，产品开发 大量返工，“计划不如变化快”，开发过程“失控”； 4. 需求管理各个阶段的职责不清晰，也缺乏组织支撑；往往了解市场的不懂技术，懂 技术的不了解市场，不知道需求应该由谁负责；
目录 2 1.前言......................................................................................................................... 3 2.需求管理背景......................................................................................................... 3 3.需求管理流程......................................................................................................... 4 4.指导规范................................................................................................................. 6 5.需求管理体系......................................................................................................... 6 5.1.制度 .............................................................................................................. 7（一）总则 .............................................................................................................. 7（二）机构职责 ...................................................................................................... （三）总体工作流程 ............................................................................................ 10 10（四）需求提出 .................................................................................................... 10（五）需求分析 .................................................................................................... 11（六）需求评审 .................................................................................................... 12（七）需求跟踪 .................................................................................................... 12（八）需求实现 .................................................................................................... 12（九）附则 ............................................................................................................ 13 5.2.细则 ............................................................................................................ 13 5.3.流程图 ........................................................................................................ 14 5.4.评审细则 .................................................................................................... 15 5.5.模板 ............................................................................................................ 5.6.编写指南 .................................................................................................... 16 16 6.合理性评价...........................................................................................................
业务需求管理制度 第一条总则 规范各部门有关业务需求的提出、变更及维护，为整体业务系统建立统一的需求管理机制和跟踪机制，从而提高沟通效率及需求反馈的响应速度和透明度，保障产品开发结果与需求的一致性，特制定本细则。 第二条适用范围 本规定适用于管理所有业务部门提交到本部的所有需求。 第三条定义 1、业务需求：对需要在整体业务系统中实现或调整的业务功能的说明或描述； 2、业务需求方：为公司整体业务系统提出所要实现或调整功能的部门，包括无线运营部、销售服务部和财务结算部等； 3、业务需求承接方：负责承接业务需求，目前由产品技术部的产品专员对接各部门的需求。 第四条需求的重要程度 需求部门所需功能对整体业务系统的影响程度，可分为非常重要、重要和一般三个级别，非常重要为最高级别。 a)非常重要：业务系统所需的该项功能对整体业务系统影响非常大，如该需求为关键流程的关键环节； b)重要：业务系统所需的该项功能对整体业务系统影响大； 页脚内容1
c)一般：业务系统所需的该项功能对整体业务系统影响一般，如页面显示文字、字体、颜色等。第五条需求的紧急程度 需求部门所需功能的急迫程度，可分为非常紧急、紧急和一般三个级别，非常紧急为最高级别。 a)非常紧急：所提业务需求非常急迫，如不尽快实现，关键业务流程不能被正确执行、且无可替代措施； b)紧急：所提业务需求比较急迫，如不尽快实现，业务流程不能被正确执行，但存在可替代措施或方法； c)一般：所提业务需求急迫性一般，不会对现有流程存在较大影响。 第六条需求提交 各部门通过JIRA填写详细需求信息，向需求承接方发起需求任务，在需求提出时需注意以下几个方面： 1、详细描述需求背景、需求内容，包含需求介绍、功能性需求详细描述及数据需求描述，明确本部门需求对接人； 2、提出需求时应说明需求的重要程度和紧急程度； 3、提出需求时应认真考虑业务需求的合理性、完整性和前瞻性，充分考虑各种流程、各个环节以及异常流程的处理； 4、为更加清楚地说明业务需求变更情况，可附带附件、附图等文档。 第七条需求分析 1、需求承接方就接受到的需求进行需求分析，需求不明确的地方与需求方及时进行沟通，并在 页脚内容2
产品需求分析管理和产品规划培训课程 课程背景 营销大师科特勒指出：“以市场为导向、以客户为中心”就是对市场需求的管理！市场需求管理是公司战略、市场计划、新产品开发的依据，决定了公司竞争力的延续，直接影响到公司效益。 但是：“有价值的客户需求在哪里，对有价值的需求如何进行汇总、分析。”目前大量的理论体系到此为止，如何在实际的操作层面上进行下去？如何执行？根据权威机构统计：项目缺陷的56％来源于需求定义错误，80％的缺陷修复成本用于修复需求导致的错误，需求的正确与否直接影响产品开发周期、产品开发成本，甚至直接决定产品最终的市场成败。 通过和众多国内科技企业接触，我们发现这些企业中普遍存在如下问题： 1.缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联系”； 2.产品开发过程需求工作持续时间短，需求分析不充分；需求没有有效地分层分级，对不同阶段需求应该详细到什么程度没有明确的定义； 3.需求的表达不够结构化，充斥着“故事会”格式的需求，直接影响了不同团队对需求理解一致性； 4.产品开发闭门造车，关注技术，不关注客户； 5.产品开发出来才找客户、找卖点； 6.不清楚业界众多需求分析工具如何在不同需求分析阶段进行恰当运用等； 本课程结合以上企业在市场需求管理中存在的问题进行深入的探讨，结合多年企业的实践和研发管理咨询的案例，就企业在市场需求的收集、整理、归类、分析、分解与分配、执行与验证等环节的问题展开深入的讲解，并分享大量企业的案例。 课程特色 课程的实践性：讲师从事过市场需求管理的工作多年，同时完成过近10个咨询项目，通过大量的案例和演练，让学员非常便于理解；具体的操作方法和工具：课程涉及的市场需求分析和市场需求管理的方法和工具十分具体，操作性非常强；讲师独特的专业背景：讲师都是从研发做起，在知名企业担任研发中高层领导，并且在成功的企业有成功的实践经验。 培训收益 1.了解研发需求工程过程与其他研发流程体系的接口关系； 2.掌握从市场角度进行有效的客户需求收集的机制和方法，筛选高质量的客户需求； 3.掌握对客户需求进行整理、分类、分析的方法，提高各个角色对需求理解的一致性，最终形成产品包需求，明确产品的竞争优势与卖点； 4.掌握外部需求和内部需求一体化管理的机制，从而降低产品的端到端生命周期成本； 5.掌握对产品包需求进行分解和分配，确保需求与设计协同一致，减少模块间耦合的方法； 6.掌握对客户需求、产品包需求、设计需求进行持续验证和跟踪的机制和方法； 7.掌握构建需求收集长效机制，提升公司整体需求管理能力的机制和方法； 8.掌握支撑研发需求工程各个阶段工作运作的工具和操作方法。 课程大纲 一、例分析：某案例公司市场之路
需求管理体系改进方法研究 需求管理过程 当软件开发完成需求开发工作之后，不可避免地会遇到软件需求的变更。有效的需求管理需要对变更带来的潜在影响及可能的成本费用进行评估。变更控制委员会与关键的项目风险承担者要进行协商，以确定哪些需求可以变更。同时，无论是在开发阶段还是在系统测试阶段，还应跟踪每项需求的状态。需求管理的主要工作如下： 1) 确定需求变更控制过程：确定一个选择、分析和决策需求变更的过程。所有的需求变更都需遵循此过程，商业化的问题跟踪工具都能支持变更控制过程。 2) 建立变更控制委员会：组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本。 3) 进行需求变更影响分析：应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于变更控制委员会作出更好的决策。 4) 跟踪所有受需求变更影响的工作产品：当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。这样能减少因疏忽而不得不变更产品的机会，这种变更在变更需求的情况下是必须进行的。 5) 建立需求基准版本和需求控制版本文档：确定一个需求基准，这是一致性需求在特定时刻的快照。之后的需求变更就遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。最好的办法是使用合适的配置管理工具在版本控制下为需求文档定位。 6) 维护需求变更的历史记录：记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。 7) 跟踪每项需求的状态：建立一个数据库，其中每一条记录保存一项功能需求。保存每项功能需求的重要属性，它包括状态（如已推荐的，已通过的，已实施的，或已验证的），这样在任何时候都能得到每个状态类的需求数量。 8) 衡量需求稳定性：记录基准需求的数量和每周或每月的变更（添加、修改、删除）
密级：内部公开 文档编号：SL _RD_XQGLGF 需求管理规范 编制：XX生效日期：2018-03-09 审核：XXX批准： ------------------------------------------------------------------- XXX科技公司对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
2017-07-21 0.1 创建XX XXX
目录 1.目的.............................................................................................................................. - 3 -2．范围........................................................................................................................................ - 3 -3．术语........................................................................................................................................ - 3 - 4. 部门/角色与职责.................................................................................................................... - 3 - 5. 内容......................................................................................................................................... - 4 -5.1 流程图................................................................................................................................. - 4 -5.2 主要活动............................................................................................................................. - 5 - 5.2.1需求获取（需求的收集和整理）..................................................................... - 5 - 5.2.2需求分析............................................................................................................. - 5 - 5.2.3需求定义............................................................................................................. - 5 - 5.2.4需求的确认......................................................................................................... - 6 - 5.2.5需求的实现......................................................................................................... - 7 - 5.2.6需求的测试......................................................................................................... - 7 - 5.2.7需求跟踪............................................................................................................. - 7 - 5.2.8 需求变更............................................................................................................ - 7 - 6.相关附件、表单....................................................................................................................... - 8 -
产品需求开发管理规范 为规范需求管理流程，特制定本规范。请相关岗位人员参考执行，以提高沟 通效率，降低项目风险。 0 流程图 需求处理流程 产品业务客户技术测试与售后阶段 沟通处理需求提出需求收集需求问题反馈整理分析需求需求设计 （原型）接收反馈客户打回/接收 需求评审需求文档编写通过不通过需求评估开发排期确认不通过 通过 功能开发单元测试 功能测试性能测试确认验收 发布使用商务沟通 收费功能 上线检测 涉及部门/岗位人员类型说明： 客户：包括已经购买或潜在客户，及终端用户。 业务：是指销售、代理商或其他一线与客户接触的工作人员。 产品：产品规划设计人员。 技术：技术经理、开发工程师、设计师（UE\UI ）等人员。 测试：测试经理、测试工程师等。 售后：售后服务人员，包括热线电话或在线客服等。
需求收集一般分为两种途径，一线业务人员（销售或代理商）与售后服务部。需求收集后需要提交至产品部进行需求分析，根据具体情况给出需求处理结果，如果需求存在异议产品人员可以与客户联系沟通确认清楚。在此过程中产品人员应该根据客户所处的商务阶段（如有合同条款）判断是否需要另行收费，技术人员需要配合产品评估大致工时，以确定收费金额。 在此过程中可能存在需求打回的情况，需要产品人员给出分析结果并与相关人员沟通确认。在确定打回后业务人员应积极配合沟通客户，以确保客户满意度。无论是打回还是受理都需要向客户反馈情况。 输入：需求收集表（根据具体情况可能包含可行性分析，或与产品一起提出）、需求检测工单 输出：需求跟踪表 参与人：业务、售后、产品 2原型设计 原型设计是产品人员根据所确定的需求进行功能设计的过程，用相应方法能完整的展示传递功能、交互、验证等信息。可以用word、Excel、PPT等方式进行描述，最好是使用Axure。 输入：需求跟踪表 输出：功能原型（rp文件） 参与人：产品
零壹移动互联 需求管理制度（版，2015年） 修改记录
目录 第一章总则................................................. 错误!未定义书签。第二章职责与分工........................................... 错误!未定义书签。第三章需求总体说明......................................... 错误!未定义书签。第四章需求提交............................................. 错误!未定义书签。第五章需求评估............................................. 错误!未定义书签。第六章需求开发............................................. 错误!未定义书签。第七章系统测试............................................. 错误!未定义书签。第八章需求上线............................................. 错误!未定义书签。第九章生产问题管理......................................... 错误!未定义书签。第十章需求变更控制与管理................................... 错误!未定义书签。第十一章需求进度监控及查询................................. 错误!未定义书签。第十二章附则............................................... 错误!未定义书签。
零壹移动互联 需求管理制度（2.0版，2015年） 拟制人肖波日期20150630 审核人日期 批准人日期 修改记录 日期版本 作者/修 改者 描述审核人 20150701 V2.0 肖波修改需求开发管理流程与相关人员 分工 -1-
目录 第一章总则 (3) 第二章职责与分工 (3) 第三章需求总体说明 (4) 第四章需求提交 (7) 第五章需求评估 (7) 第六章需求开发 (10) 第七章系统测试 (11) 第八章需求上线 (13) 第九章生产问题管理 (14) 第十章需求变更控制与管理 (14) 第十一章需求进度监控及查询 (17) 第十二章附则 (17) -2-
第一章总则 第一条为规范零壹移动互联（以下简称“零壹”）需求管理，明确各阶段的工作内容、处理流程、参与人员以及相关干系人的职责，在保证需求质量的同时，提高需求实现效率，特制订本制度。 第二条本制度适用于研发部的所有系统开发需求。 第三条本制度适用的读者包括需求开发负责人、需求提交人员、需求评估人员、开发人员、测试人员、生产运维人员、项目管理员等。 第二章职责与分工 第四条职责分工 角色职责 需求提交人员1.负责需求调研与编辑、编写业务需求申请表、提交业务需求审批。 2.根据需求评审和评估意见，及时修改业务需求，并发给需求相关干 系人。 3.配合需求开发、测试人员提供业务知识的支持。 4.协助确认需求开发结果。 5.负责需求上线后验证工作。 项目管理人员1.负责需求审批、评估、技术文档评审、测试、上线等需求管理流程 的整体协调工作。 2.组织需求评估会议。 3.处理测试申请----提交测试部门进行分配与测试。 4.维护需求信息、跟进需求变更以及需求处理进展，定期向相关领导、 部门汇报需求进展。 需求开发负责人1.参与需求评审，从技术角度对需求实现方式、风险等进行评估。 2.制定需求开发计划，分配需求开发人员。 3.负责需求所有工作的沟通、协调管理。 4.负责需求开发进度、成员、变更管理。 5.负责或参与需求所有成果的审批。 需求评估人员1.从架构、业务、技术、风险等方面对业务需求的内容和实现方式进 行全面评估，并提出评估意见。 2.审核根据评估意见修改后的业务需求。 -3-
需求管理规范说明数据产品事业部-生产部-采集部
文档履历
发布范围
目录 1.目的 (2) 2.适用范围 (2) 3.术语及定义 (2) 3.1需求管理 (2) 3.2需求获取 (2) 3.3需求列表 (2) 3.4需求状态 (2) 4.执行准则 (2) 5需求管理过程 (3) 5.1需求过程所涉及工作 (3) 5.1.1需求定义 (3) 5.1.1.1需求获取 (3) 5.1.1.2需求分析 (4) 5.1.1.3需求说明 (4) 5.1.1.4需求验证 (6) 5.1.2需求维护 (6) 5.1.2.1需求基线定制 (6) 5.1.2.2需求变更 (7) 5.1.2.3需求跟踪 (9) 5.1.2.4需求状态 (10)
1.概述 需求管理，需要明确需求管理流程，并对每个相关部门所应有的责任与权利进行界定，同时要建立有效的监管措施，使流程中的每个环节都能发挥有效作用。 需求管理不是项目前期的一个环节，而是贯穿整个项目的关键流程。在具体进行需求管理时，应该着重注意明确职责避免缺位、需求应分层沟通和确认、分步实施和先易后难的原则。 2.目的 为了阐述清楚一个项目需求各个层次中的每一个环节设计考虑。保证项目执行的质量、进度、需求的完整与可追溯性。保证业务需求提出者与需求分析人员、项目执行人员、验收人员及其也相关利益人对需求达成共识。 3.适用范围 本管理规范只适用于数据产品事业部-采集部需求管理人员。 4.术语及定义 4.1需求管理 是一种获取、组织、并记录项目所产生或接受的技术性、非技术性需求，以及组织项目的需求。 通过需求管理能够管理所有的需求变更、维护需求与项目实施过程的关系、识别需求与工作产品间的不一致，使客户、与项目团队对不断变化的需求达成并保持一致。 4.2需求获取 是业务规划部门依据需求方提交的业务需求，经过分析、整合、加工而形成的按系统、分功能抽象记录的需求概述。它是项目管理的基本单元，也是用户需求编写的依据。 4.3需求列表 是需求分析人员依据需求条目，通过分析，按照需要实现的目标点组织编写的需求清单。 4.4需求状态 指某时间点上反映出的需求问题情况。 5.执行准则 1、必须列明需求条目 2、必须列明用户需求列表 3、需求一定要进行分类 4、需求需分优先级
软件项目管理规范 一、软件项目管理的定义 软件项目管理是软件工程和项目管理的交叉学科，软件项目管理的概念涵盖了管理软件产品开发所必须的知识、技术及工具。根据美国项目管理协会PMI对项目管理的定义可以将软件项目管理定义为：在软件项目活动中运用一系列知识、技能、工具和技术，以满足软件需求方的整体要求。 软件工程的活动包括问题定义、可行性研究、需求分析、设计、实现、确认、支持等，所有这些活动都必须进行管理，软件项目管理贯穿于软件工程的演化过程之中，如图1所示。 图1 软件工程的演化过程 二、软件项目管理的过程 为保证软件项目获得成功，必须清楚其工作范围、要完成的任务、需要的资源、需要的工作量、进度的安排、可能遇到的风险等。软件项目的管理工作在技术工作开始之前就应开始，而在软件从概念到实现的过程中继续进行，且只有当软件开发工作最后结束时才终止。管理的过程分为如下几个步骤： （1）启动软件项目 启动软件项目是指必须明确项目的目标和范围、考虑可能的解决方案以及技术和管理上的要求等，这些信息是软件项目运行和管理的基础。 （2）制定项目计划 软件项目一旦启动，就必须制定项目计划。计划的制定以下面的活动为依据。 ·估算项目所需要的工作量 ·估算项目所需要的资源 ·根据工作量制定进度计划，继而进行资源分配 ·做出配置管理计划 （3）跟踪及控制项目计划 在软件项目进行过程中，严格遵守项目计划，对于一些不可避免的变更，要进行适当的控制和调整，但要确保计划的完整性和一致性。 （4）评审项目计划 对项目计划的完成程度进行评审。并对项目的执行情况进行评价。 （5）编写管理文档 项目管理人员根据软件合同确定软件项目是否完成。项目一旦完成，则检查项目完成的结果和中间记录文档，并把所有的结果记录下来形成文档而保存。 三、软件项目管理的内容
产品管理规范 1 目的 实现以市场为导向的产品规划，有计划有组织地进行研究与产品开发活动。有效地调动营销部门以及生产部门的创造性思维，把市场与消费者的认识转换在新产品中，确保产品开发和企业产品战略的一致性，快速、合理应对市场需求，规避产品投资风险，并为企业获得最大限度的利润。 2 范围 本制度适用于本公司产品开发、上线、管理全过程，对产品管理的流程做出规定，是公司管理产品规划工作的依据，各相关营销、生产部门必须遵照执行。 3 职责 产品管理是企业在产品生命周期中对产品规划、开发、生产、运营和支持等环节进行管理的业务活动，包括需求管理、市场管理以及开发管理 4 内容 具体如下：
?产品战略规划 产品战略包含：1 产品路线2 产品策略3 产品计划 ?产品研发 产品研发包含：1 需求阶段2 设计阶段3 开发阶段4 测试阶段5 发布阶段（上线） ?产品生命周期 产品生命周期包含：周期管理（1 导入期2 成长期3 成熟期4 衰退期） ?组织、主要人员及职责 ?1组织结构 ?2重要角色 重要角色负责人：产品负责人、研发负责人、产品管理负责人、运营负责人。 重要角色包括：产品经理（需求提出人）、需求管理员、技术人员、运营人员。 ?3其中对重要角色职责及相关要求定义如下： ?产品管理会 产品管理会由产品中心、运营中心、产品研发中心总监以及参与在产品生命周期过程中的产品规划经理、用户研究人员、产品负责人、开发负责人、运营负责人等共同组成。 主要职责： （1）制定运营计划，确定运营目标； （2）优化产品，制定运营策略； （3）监控产品质量，把控经营结果； （4）对产品进行全生命周期管理； （5）对产品需求的提出、终止和变更进行决策； （6）监督产品管理相关制度的执行。 ?评审委员会
需求管理规范 需求采集 采集说明 1.通过各种形式对用户的需求进行收集，通常的形式有：用户访谈，调查问卷，数据分析，领导提供需 求，产品人员需求等。 2.在这个阶段对需求的属性详细记录，并且记录可追溯的反馈人员。 采集要求 1.采集的需求必须符合运营需求。 2.需求必需符合icage产品定义。 3.需求必需具有可实现性、拓展性、可开发和合理性。 4.项目组成员确认，对人员进行限制，不能有过多相关人员加入 5.满足用户需求和业务需求一致性。 6.对开发周期进行安排，计算人力成本并分析工期合理性。 采集流程 采集阶段的文档
需求分析 分析说明 1.对需求进行一番分析，确定其基本属性，做了之后会对产品带来哪些商业价值？用户量的提高？一级 实现改项目需求最多要付出的人员、时间等系数，确认需求性价比。 2.对于一些bug或是功能的小修改，不做详细分析，直接转为需求处理。 分析要求 1.需求分析人员必须完成相关需求分析文档； 2.分析人员要使用符合大众的习惯性语言表达； 3.分析人员要了解业务及需求 4.需求文档中不能含有模棱两可的文字，如可能、一般等 5.需求分析工期不能超过预期时间 6.需求分析应具备合理性 分析流程
分析阶段的文档 需求评审 评审说明 1.结合现状对需求进行处理，主要解决做不做？什么时候做，做什么的问题； 2.需求评审以会议形式展开，邀请与项目相关人员及领导参加 3.通过评审，对多个需求进行打包，整理所需的需求点 4.对打包后的需求形成文档，提交领导复核，确认后进行开发周期 评审要求 1.符合icage产品定义 2.需求形式化语言清晰易懂 3.需求必须符合运营需求 4.标示将来产品迭代可预测的需求 5.需求必须可拓展性及可实现性或者后续产品迭代时人力成本和开发成本及技术实现的难易程度 6.满足用户需求和业务需求一致性 7.需求必须合理 8.开发周期、人力成本、工期需合理
CMMI需求管理规范
目录 一．概述 (3) 二．需求管理的基本活动 (3) 1、需求提出 (3) 2、需求分析及评审 (3) 3、需求计划定制及跟踪 (3) 4、需求变更控制 (3) 5、需求制度建立及其优化 (4) 6、需求成本控制 (4) 三．项目实践过程示例 (4) 1 、建立需求管理制度 (4) 2、需求接收及其分析 (5) 3、需求评审 (5) 4、需求计划定制及跟踪 (5) 5、需求开发及更新过程 (5) 6、需求变更 (5) 7、团队培训 (5) 8、过程改进 (6)
一．概述 项目需求管理（Requirements Management, REQM）的目的，在于管理项目产品及产品组件的需求，并界定这些需求与项目计划及工作产品间的差异。项目实行适当的步骤，确保议定的需求是受管理的，以支持项目策划和执行的需要。需求管理也须记录需求变更及其理由，并维护原始需求与所有产品和产品组件需求的间的双向追溯性。 从实践意义上讲，需求是针对客户各类需求经双方（或多方）沟通确认后形成的一种协议，协议的范围是明确的、可控的。在协议签订后，需求的计划有定制、进度有跟踪、结果有度量。针对需求的变化，需要明确需求变化的原因及变更内容。需求的紧急程度及严重程度可评估，以确定需求及其变更的优先级，从而排定切实可行的需求计划。 下面我们就如下几个方面对需求管理体系进行分析、研究： 1，需求的管理的基本活动 2，结合当前项目简述需求管理实践中的问题、解决方案（结合7命题）。 二．需求管理的基本活动 在需求管理过程中，包含如下关键活动： 1、需求提出 针对客户的需求提出，开发方进入需求了解环节。需求了解采用访谈、文档、多方会议等形式采集基础信息，在此基础上结合系统原型进行差异化分析。 2、需求分析及评审 需求分析中，针对需求、系统差异进行差异记录并制定相应的矫正方案。 3、需求计划定制及跟踪 需求计划的定制以用户、开发团队、计划跟踪者协商一致的结果为依据。其过程实质是取得用户对于进度的认可、取得团队对于进度的承诺。其成果物—需求跟踪表，对于后续的需求跟踪起到警示标的作用。 4、需求变更控制 用户对于系统、需求的理解是渐进的过程，因此某种意义上说需求变更存在必然性。 如何有效率和有效果地管理这些新增需求或变更需求是很重要的。如果需求变更控制不当，不但造成新的需求变更得不到满足，而且对于需求进度的管理、对于系统稳定性的影响都将是负面的。变更控制，需要追溯变更的缘由，记录变更的原因、内容，并做好变更比例的度量。保证需求的可追溯性，对于需求变更管理至关重要；在进行需求变更对项目计划、活动及工作产品的影响评估时尤其需要需求追溯表这些管理工具。
产品需求分析与需求管理－－如何搞定市场需求 主讲：董奎（Don）（研发管理咨询资深顾问INCOSE（国际系统工程师联合会）会员） 课程对象：企业CEO/总经理、研发总监、研发经理/项目经理/技术经理/产品经理、产品规划专家等。 【课程背景】 通过和众多国内科技企业接触，发现这些企业中普遍存在： 1.技术很牛，但最终倒闭的公司一大推；被技术人员嗤之以鼻的公司，反而活的还不错 2.研发从早忙到晚，产品开发的不少，但市场成功的产品屈指可数，开发的越多，死得越快 3.产品开发闭门造车，关注技术，不关注客户；产品开发出来才找客户、找卖点 4.了解市场的不懂技术，懂技术的不了解市场，不知道需求应该谁负责 5.需求准确把握决定产品成败，但没有人关注需求，即使偶尔想关注也不知道如何关注 6.需求的表达不够结构化，充斥着“故事会”格式的需求，直接影响了不同团队对需求理解的一致性 7.缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联系” 8.不能从自身能力提升来引导客户需求，反而天天在抱怨客户需求经常变动 9.针对需求大家“吵成一锅粥”：公司与客户吵，市场与开发吵，开发与测试吵，…… 不能满足客户需求、给客户创造价值，再牛的技术也没有价值。根据权威机构统计项目缺陷的56%来源于需求定义错误，80%的缺陷修复成本用于修复需求导致的错误，把技术变成金钱的不二选择关注、锁定、满足市场需求，创造客户价值。本课程重点讲解： 1.如何确定目标客户，如何分析需求关系人？ 2.如何从市场（客户）角度进行有效的客户需求收集？ 3.围绕产品成功2个核心因素差异化+成本优势，整理产品需求
4.如何对客户需求进行整理和分析，形成产品包需求？ 5.如何基于产品需求与竞争友商对比分析，确定我们的核心诉求，形成产品概念？ 课程贯穿案例分享，详细讲解目标客户 客户要求 客户需求 产品包需求 产品概念确定全过程，详细讲解把技术转变为金钱的方法和工具（利润区、回溯分析、决策模型分析、KJ、$APPEALS、BSA、概念定义7个核心秘诀、破坏性创新的3石蕊实验、SweetPoint模型、基于不同产品生命周期的12个创新思路等），提升产品的竞争力，确保市场成功、财务成功。 【课程价值】 1.掌握从市场角度进行有效的客户需求收集的机制和方法，筛选高质量的客户需求； 2.掌握对客户需求进行整理、分类、分析的方法，提高各个角色对需求理解的一致性，最终形成产品包需求，明确产品的竞争优势与卖点； 3.掌握外部需求和内部需求一体化管理的机制，从而降低产品的端到端生命周期成本； 4.掌握产品核心诉求的提炼方法，确定有吸引力的产品概念； 5.掌握支撑研发需求工程各个阶段工作运作的工具和操作方法； 【培训内容】 一、案例分享 二、六个基本概念 1.什么是客户？ 1)客户、用户、目标客户、潜在客户、可以送给竞争友商的毒药客户 2.什么是需求？ 1)WANTS/NEEDS/DEMANDS、真假需求、客户需求、用户需求、产品需求、设计需求、需求规格、技术需求、非技术需求 2)案例：某运营上广告折射对需求五层次的理解 3.需求工作的2个基本点： 1)差异化 2)成本优势