2022年需求管理体系建设[产品研发型企业适用] .pdf

《2022年需求管理体系建设[产品研发型企业适用] .pdf》由会员分享，可在线阅读，更多相关《2022年需求管理体系建设[产品研发型企业适用] .pdf（8页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、产品研发型企业需求管理体系目录一需求管理体系概述. 2二需求管理体系的活动. 31、需求提出、编写需求单. 32、需求评估 . 33、需求登记 . 34、需求分析设计. 35、填写开发计划. 36、用户测试案例编写. 37、开发测试 . 38、提交用户测试. 39、提交运维测试. 310、需求上线 . 3三需求管理体系的流程. 4四需求管理体系的问题分析及规范建立. 41、需求管理过程中的问题. 42、问题的解决方案（结合7 命题） . 5(1) 建立需求管理制度. 5(3) 需求接收 . 5(4) 需求评估 . 5(5) 开发计划定制及跟踪. 5(6) 需求开发及发布过程. 6(7) 过程持

2、续改进及团队培训. 63、需求管理规范. 6名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 8 页 - - - - - - - - - 第 2 页 共 8 页一 需求管理体系概述从实践意义上讲，需求是针对客户各类需求经双方（或多方） 沟通确认后形成的一种协议，协议的范围是明确的、可控的。在协议签订后，需求的计划有定制、进度有跟踪、结果有度量。 针对需求的变化，需要明确需求变化的原因及变更内容。需求的紧急程度及严重程度可评估，以确定需求及其变更的优先级，从而排定切实可行的需

3、求计划。项目需求管理的目的，在于管理项目产品及产品组件的需求，并界定这些需求与项目计划及工作产品间的差异。项目实行适当的步骤，确保议定的需求是受管理的，以支持项目策划和执行的需要。需求管理也须记录需求变更及其理由，并维护原始需求与所有产品和产品组件需求的间的双向追溯性。用户对于系统、 需求的理解是渐进的过程，因此某种意义上说需求变更存在必然性。如何有效率和有效果地管理这些新增需求或变更需求是很重要的。如果需求变更控制不当，不但造成新的需求变更得不到满足，而且对于需求进度的管理、对于系统稳定性的影响都将是负面的。 变更控制， 需要追溯变更的缘由，记录变更的原因、内容， 并做好变更比例的度量。保证

4、需求的可追溯性，对于需求变更管理至关重要；在进行需求变更对项目计划、活动及工作产品的影响评估时尤其需要需求追溯表这些管理工具。需求管理体系规范建立及其优化。在需求管理过程中的各个环节，存在较多的争执点，这就需要制度进行明确。形成一个系统的、规范的制度，使需求管理过程可细化度量；制度的形成需要配备对应的资源，比如需求跟踪工具、需求干系人的培训管理。通过制度保证需求过程可监控、上层管理者可以跟踪需求的进展情况等。需求管理成本控制。需求开发面临成本投入的现实，需求开发本身、需求管理本身，因需求开发、管理造成的物力、人力消耗都是现实的成本。在日常系统运作中，对于需求必要性的评审，对于系统变更的控制，对

5、于人员的培训都是提高效率降低总成本的方式。实际项目管理工作中，需求管理工作占据着重要的内容，下面我们结合需求管理的主要活动及流程进行分析、研究，以期建立一套规范的需求管理规范。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 8 页 - - - - - - - - - 第 3 页 共 8 页二 需求管理体系的活动1、需求提出、编写需求单系统用户在项目进行过程中会不断的有新的或者变更的需求提出。需求采用访谈、 文档、多方会议等形式采集基础信息，但最终必须由需求提出岗人员整理后

6、编写补丁需求单。2、需求评估对与需求进行可行性分析，首先应该判断的是需求的内容表达是否清晰，需求是否全面、是否包含关联性需求；其次分析需求带来的收益及成本；另外还需要判定需求优先等级，给出处理意见和建议， 不通过评估的可以直接回复给需求提出者，沟通解决需求中提出的问题。3、需求登记统一编号并纳入到需求管理库中，同时触发用户编写测试案例工作和需求分析设计工作。4、需求分析设计对需求进行详细的系统分析和设计，产出设计文档。5、填写开发计划需求计划的定制以用户、开发团队、计划跟踪者协商一致的结果为依据。其过程实质是取得用户对于进度的认可、取得团队对于进度的承诺。其成果物需求跟踪表，对于后续的需求跟踪

7、起到警示标的作用。6、用户测试案例编写通知用户系统开发计划及提交时间，同时督促用户编写并提交用户测试案例及计划。7、开发测试开发完成后，编写开发测试案例，提交开发测试环境，进行开发集成测试。8、提交用户测试开发测试完成后，提交用户测试环境通知用户测试。9、提交运维测试进行上线前的版本验证。10、需求上线需求上线运行，进入运维期间。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 8 页 - - - - - - - - - 第 4 页 共 8 页三 需求管理体系的流程版本管理

8、岗测试岗运维岗开发岗需求设计岗需求管理岗需求提出岗编写补丁需求变更单需求评估需求登记N需求是否通过Y需求分析设计填写开发计划程序设计、开发开发测试运维STA 测试用户 UAT 验收测试编写测试案例提交测试报告测试环境上线测试通过？通过发布版本测试是否需求提出四 需求管理体系的问题分析及规范建立1、需求管理过程中的问题(1) 需求管理流程越快越好，需求直接提交给开发部门。(2) 需求提交方式多样，有很多口头或邮件交流内容，存在需求过于简单描述不清等问题，后续需求管理代价较大。(3) 需求提出时，不够细化或后不够完全，没有考虑整体性和关联性需求；有些需求只适用于个别分支机构；需求上存在理解差异，待

9、功能交付后，用户提出所见非所求， 造成需求、 bug 争论不休， 需求变更及bug 修复频繁， 影响系统稳定并造成成本消耗。(4) 没有划定需求的优先级，需求进度难以控制，过多的争论造成了临时事务增多，对于需求开发的支持滞后，项目整体进展缓慢，客户满意度较低。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 8 页 - - - - - - - - - 第 5 页 共 8 页(5) 需求提出后，经过一段时间的开发，后续无人跟踪。(6) 需求提出者坚持一项对系统并不合理的需求。

10、(7) 需求反馈速度慢，用户希望及时了解需求开发进度。2、问题的解决方案（结合7 命题）(1) 建立需求管理制度IT 部门、 业务部门、 以及上级管理部门制定出一套可以严格执行的需求管理体系规范。涉及到领导命题（需要高层领导的支持和参与）、投资命题（需要计划，配备专职人员以及管理时间和资金投入）、 团队命题（需要全体人员的协作和努力）、文档命题、过程命题及效果命题。向领导层阐述需求管理体系规范的目的：确保业务系统转换及生产环境稳定、最大限度的满足公司正常业务的开展；稳定满足业务流程、规则的变更。 按新流程推进后，可以提高需求质量、系统开发质量，达到保证系统稳定的目的。因为需求本身质量和开发质量

11、都得以提升，日常争论降低，分析、开发效率都得到提高。需求管理体系的形成需要配备相应的工具，对于需求的计划跟踪、需求评审、需求质量控制进行有效监控。需要加强人员培训，熟悉相应的工具；需要增加若干审批环节，增加管理资金投入。需求管理体系的形成会造成各环节流程变动，对于过往习惯造成影响，这就需要整个团队的适应。需要各部门群策群力，才能将制度落到实处。(3) 需求接收需求文档提供及分析文档形成也涉及到了文档命题（需求变更文档）支持过程活动可视化，使得复杂的智力密集的支持过程活动得到有效地控制）。在开发前期形成双方认可的文档是减少功能交付后争议的有效办法。(4) 需求评估在需求文档提交到需求管理岗后，需

12、求管理岗会同专家小组，对于需求进行可行性分析，在评审过程中就可能出现理解的差异需求进行检查，最终形成是否通过该项需求的决定，并对后续需求提交、分析的质量提出指导意见。评估后，形成评故文档记录评估意见入库。该部分一般要求有上级领导参与决策。涉及领导命题、 投资命题、文档命题。(5) 开发计划定制及跟踪在需求经过多方确认后，可根据现有开发团队的人力结合需求的优先级确定需求开名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 8 页 - - - - - - - - - 第 6 页

13、共 8 页发计划， 并将计划登记入需求跟踪表，需求过程进行统一跟踪，各部门均可获取当前需求的进展状态。如果对于计划有调整需求的，需要有明确的审批机制，评估调整计划对于项目整体进度的影响，经过相关干系人协调一致后，予以调整。 涉及团队命题、效果命题、成熟度命题。(6) 需求开发及发布过程需求开发阶段， 需要在设计文档、测试文档提供方面进行加强，提高需求开发的整体质量。 需求提交纳入配置管理库，由专人进行版本的更新，在更新时检查对应文档的提供情况。涉及团队命题、效果命题、成熟度命题。(7) 过程持续改进及团队培训过程命题：需要仔细地进行过程设计来减轻甚至消除软件支持过程认知障碍并提高群体认知活动的

14、效力和效率。新流程的形成必然存在一定的瑕疵，因此在流程推进过程中需要不断总结，消除新流程推进过程中的问题。使各部门消除推进新流程的顾虑，体现新流程的价值。成熟度命题 （需要不断地组织学习以持续地改进全组织的软件支持过程能力。一方面团队需要学习新流程推行中需要遵循的规范，另一方面团队也需要接触新流程配套使用的工具。同时需要不断提升自身业务、技术水平以适应新流程。效果命题：需要明确地努力和定期地强化其效果。通过不断增加团队的适应水平，使新流程的效果得以显现， 不断的效果显现本身就是对团队的激励，使得新流程的认可度不断提升。3、需求管理规范依据以上分析，我们可以定义出一套新的需求管理体系规范：第一条

15、为了确保业务系统转换及生产环境稳定、最大限度的满足公司正常业务的开展；稳定满足业务流程、规则的变更；特制定本管理规范。第二条本规定约束所有需求提出部门、开发部门和需求管理部门。第三条本规范协助提高需求质量、系统开发质量，达到保证系统稳定的目的。第四条这里的需求必须是纸质的书面需求，口头需求只能作为讨论依据，最终的需求必须是书面的，需求处理时间以接到书面需求开始。第五条正式补丁需求变更单提出之前，必须同开发部门及需求管理部门沟通过，重要需求必须召开需求讨论会议，需求涉及到的任何人都可以要求召开需求讨论会第六条经过沟通讨论后形成需求初稿交由需求管理部门需求接收岗审核，需求内容必名师资料总结 - -

16、 -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 8 页 - - - - - - - - - 第 7 页 共 8 页须清晰、完整、关联性考虑周到，符合要求后，需求提出岗填写正式补丁需求变更单 ，不符合要求的，重新打回需求提出岗。第七条需求标题必须明确，能够概括主要需求内容。需求变更单中的每一项必须实事求是的填写 （如紧急程度） ，完成时间必须是需求提出方、开发部门和需求管理部门三方达成一致的结果，以支持业务为主，兼顾业务需求、系统稳定和原工作安排。第八条补丁需求变更中必须考虑需求间的相关性，如

17、果有相关联的需求1，必须说明关联需求的关系。第九条补丁需求中必须从业务上考虑对其他小组和部门的影响和关联，如果影响到其他部门或者小组的，必须说明。第十条重大需求需要提供市场分析、投资收益分析评估报告，必要时需总经理室批准。第十一条分支机构的需求需逐级上报审批，最后汇总到总公司对应部门，由总公司对应部门综合考虑是否全国通用，是否与其他分公司有冲突，是否可以优化；综合总公司对应部门意见后由该部门向需求管理部门正式提交IT 需求。第十二条需求管理部门不直接接收分支机构的IT 需求。第十三条分支机构的临时数据抓取需求按照需求管理部门运维室的数据提取 流程。第十四条对于涉及到硬件设备增加的，需要根据硬件

18、室的要求，提交该需求对应的硬件需求，与硬件室一起提前做好硬件准备。第十五条补丁需求提出者是需求的所有者，要负责需求的完整性、关联性分析， 负责组织需求的讨论、跟踪和测试。第十六条需求必须经过部门领导审批同意，每个补丁需求必须编写对应该需求的测试案例，且测试案例必须由需求提出者的直接领导或者更高级领导审核签字。第十七条需求管理部门对补丁需求分配补丁需求号后，需求提出者要开始编写测试案例，版本提交业务测试时测试案例必须编写完整。第十八条需求处理生命周期：需求在需求接受岗初审完成并分配需求号后，正式进入处理流程，直到需求上正式生产环境。第十九条需求在 IT 部门处理过程中，需求提出岗需开始准备测试案

19、例。第二十条测试案例必须对所提需求的各个功能点及其分支全面覆盖，对有影响的部1关联的需求：指2 个或者多个需求名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 7 页，共 8 页 - - - - - - - - - 第 8 页 共 8 页分需增加回归测试2案例。第二十一条需求分配编号后，需求管理部门软件室对每一个需求必须指定专门的BA分析师，负责对该需求的BA分析及后期跟踪，每一个需求必须出具处理意见。第二十二条需求到达开发部门后，在4 个工作日内给出需求时间计划安排反馈。第二十三条开

20、发部门对每一个需求有自己的处理意见和设计思路，重要的需求需要给出需求规格说明书和系统设计说明书。第二十四条开发部门在自己的开发环境下进行补丁需求的开发，测试通过后定期提交。第二十五条版本发布岗在接收到程序和需求提出岗的测试案例后，发布版本到UAT环境。第二十六条需求提出岗根据实现的测试案例，在 UAT环境测试， 并记录测试结果，形成测试报告。第二十七条在所有需求在UAT环境下测试通过后，由版本发布岗发布到STA环境， 在STA环境下做上线前的最后测试。第二十八条全部测试通过后，由版本发布岗定期更新到生产环境上。2回归测试：指之前测试通过的功能点，但是可能被新需求上线影响，需要针对这类需求所作的测试。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 8 页，共 8 页 - - - - - - - - -