项目实践过程示例
（一） 需求管理过程中的问题
1、 需求提交后，存在需求过于简单描述不清等问题，需求分析压力较大。
2、 需求分析时，不够细化或完全按照客户的意见进行系统分析，没有考虑系统内的关联性。存在双方理解差异，待功能交付后，用户提出所见非所求，造成需求、bug争论不休，需求变更及bug修复频繁，影响系统稳定并造成成本消耗。
3、 需求的优先级没有划定，需求进度难以排定，造成开发压力较大且用户不满意的局面。
4、 过多的争论造成了临时事务增多，对于需求开发的支持滞后，项目整体进展缓慢，客户满意度较低。
（二） 问题的解决方案
1 、建立需求管理制度
会同业务部门、系统建设部门及其上级管理者采用会议、文档确认等形式就需求的提交、需求优先级划分、需求规范进行。 涉及到领导命题（需要高层领导的发起、参与和支持）、投资命题（需要计划，配备专职人员以及管理时间和资金投入）及团队命题（需要全体人员的协作和努力）。
1）需要向领导层阐述需求管理制度形成、按新流程推进后，可以在项目资金整体投入方面得到控制，因为需求本身质量和开发质量都得以提升，日常争论降低，分析、开发效率都得到提高。
2）该制度的形成需要配备相应的工具，对于需求的计划跟踪、需求评审、需求质量控制进行有效监控。需要加强人员培训，熟悉相应的工具；需要增加若干审批环节，增加管理资金投入。
3）新制度形成会造成各环节流程变动，对于过往习惯造成影响，这就需要整个团队的适应。需要各部门群策群力，才能将制度落到实处。
2、需求接收及其分析
需求文档提供及分析文档形成也涉及到了文档命题（需要文档（解释和沟通）支持过程活动可视化，使得复杂的智力密集的支持过程活动得到有效地控制）。在开发前期形成双方认可的文档是减少功能交付后争议的有效办法。
3、 需求评审
在需求文档和需求分析文档形成后，可会同专家小组，对于需求提交、分析的质量进行监控，在评审过程中就双方理解的差异进行消除，并对后续需求提交、分析的质量提出指导意见。评审后，形成评审文档备案。
4、 需求计划定制及跟踪
在需求经过多方确认后，可根据现有开发团队的人力结合需求的优先级确定需求开发计划，并将计划登记入需求跟踪表，需求过程进行统一跟踪，各部门均可获取当前需求的进展状态。如果对于计划有调整需求的，需要有明确的审批机制，评估调整计划对于项目整体进度的影响，经过相关干系人协调一致后，予以调整。
5、 需求开发及更新过程
需求开发阶段，需要在设计文档、测试文档提供方面进行加强，提高需求开发的整体质量。需求提交纳入配置管理库，由专人进行版本的更新，在更新时检查对应文档的提供情况。
6、 需求变更
变更需要在新流程中明确登记原因、追溯变更设计的功能点，并对变更进行审核。变更得到严格控制，并定期对各部门变更进行统计，提高需求提交的计划性和需求本身的质量。
7、 团队培训
成熟度命题（需要不断地组织学习以持续地改进全组织的软件支持过程能力。
一方面团队需要学习新流程推行中需要遵循的规范，另一方面团队也需要接触新流程配套使用的工具。同时需要不断提升自身业务、技术水平以适应新流程。
效果命题：需要明确地努力和定期地强化其效果。通过不断增加团队的适应水平，使新流程的效果得以显现，不断的效果显现本身就是对团队的激励，使得新流程的认可度不断提升。
8、过程改进
过程命题：需要仔细地进行过程设计来减轻甚至消除软件支持过程认知障碍并提高群体认知活动的效力和效率。新流程的形成必然存在一定的瑕疵，因此在流程推进过程中需要不断总结，消除新流程推进过程中的问题。使各部门消除推进新流程的顾虑，体现新流程的价值。
形成的流程
经过多方讨论，我们形成了需求管理理流程
