鲁达 CMMI
CMMI全称是Capability Maturity Model Integration，即能力成熟度模型集成(也有称为:软件能力成熟度集成模型) ，是美国国防部的一个设想，1994年由美国国防部(United States Department of Defense)与卡内基-梅隆大学(Carnegie-Mellon University)下的软件工程研究中心(Software Engineering Institute，SEISM)以及美国国防工业协会(National Defense Industrial Association)共同开发和研制的，他们计划把现在所有现存实施的与即将被发展出来的各种能力成熟度模型，集成到一个框架中去，申请此认证的前提条件是该企业具有有效的软件企业认定证书。
一、概述
项目需求管理（Requirements Management, REQM） 的目的， 在于管理项目产品及产 品组件的需求， 并界定这些需求与项目计划及工作产品间的差异。
项目实行适当的步骤， 确保议定的需求是受管理的， 以支持项目策划和执行的需要。需求管理也须记录需求变更及其 理由， 并维护原始需求与所有产品和产品组件需求的间的双向追溯性。从实践意义上讲， 需求是针对客户各类需求经双方（或多方） 沟通确认后形成的一种协 议， 协议的范围是明确的、 可控的。在协议签订后， 需求的计划有定制、 进度有跟踪、 结果 有度量。针对需求的变化， 需要明确需求变化的原因及变更内容。需求的紧急程度及严重程 度可评估， 以确定需求及其变更的优先级， 从而排定切实可行的需求计划。
下面我们就如下几个方面对需求管理体系进行分析、 研究：
1， 需求的管理的基本活动
2， 结合当前项目简述需求管理实践中的问题、 解决方案 。
二、需求管理的基本活动
在需求管理过程中， 包含如下关键活动：
1、 需求提出
针对客户的需求提出， 开发方进入需求了解环节。需求了解采用访谈、 文档、 多方会 议等形式采集基础信息， 在此基础上结合系统原型进行差异化分析。
2、 需求分析及评审
需求分析中， 针对需求、 系统差异进行差异记录并制定相应的矫正方案。
3、 需求计划定制及跟踪
需求计划的定制以用户、 开发团队、 计划跟踪者协商一致的结果为依据。其过程实质 是取得用户对于进度的认可、 取得团队对于进度的承诺。其成果物—需求跟踪表， 对于 后续的需求跟踪起到警示标的作用。
4、 需求变更控制
用户对于系统、 需求的理解是渐进的过程， 因此某种意义上说需求变更存在必然性。如何有效率和有效果地管理这些新增需求或变更需求是很重要的。如果需求变更控制不 当， 不但造成新的需求变更得不到满足， 而且对于需求进度的管理、 对于系统稳定性的 影响都将是负面的。变更控制， 需要追溯变更的缘由， 记录变更的原因、 内容， 并做好 变更比例的度量。保证需求的可追溯性， 对于需求变更管理至关重要；在进行需求变更 对项目计划、 活动及工作产品的影响评估时尤其需要需求追溯表这些管理工具。
5、 需求制度建立及其优化
在需求管理过程中的各个环节， 存在较多的争执点， 这就需要制度进行明确。形成一 个系统的、 规范的制度， 使需求管理过程可细化度量；制度的形成需要配备对应的资源， 比 如需求跟踪工具、 需求干系人的培训管理。通过制度保证需求过程可监控、 上层管理者可以 跟踪需求的进展情况等。6、 需求成本控制
需求开发面临成本投入的现实， 需求开发本身、 需求管理本身， 因需求开发、 管理造成 的物力、 人力消耗都是现实的成本。在日常系统运作中， 对于需求必要性的评审， 对于系统 变更的控制， 对于人员的培训都是提高效率降低总成本的方式。
三、 项目实践过程示例
（一） 需求管理过程中的问题
1、 需求提交后， 存在需求过于简单描述不清等问题， 需求分析压力较大。2、 需求分析时， 不够细化或完全按照客户的意见进行系统分析， 没有考虑系统内 的关联性。存在双方理解差异， 待功能交付后， 用户提出所见非所求， 造成需 求、 bug 争论不休， 需求变更及 bug 修复频繁， 影响系统稳定并造成成本消耗。
3、 需求的优先级没有划定， 需求进度难以排定， 造成开发压力较大且用户不满意 的局面。
4、 过多的争论造成了 临时事务增多， 对于需求开发的支持滞后， 项目整体进展缓 慢， 客户满意度较低。
（二） 问题的解决方案
1 、 建立需求管理制度 会同业务部门、 系统建设部门及其上级管理者采用会议、 文档确认等形式就需 求的提交、 需求优先级划分、 需求规范进行。 涉及到领导命题（需要高层领导的 发起、 参与和支持）、 投资命题（需要计划， 配备专职人员以及管理时间和资金投 入） 及团队命题（需要全体人员的协作和努力）。
1） 需要向领导层阐述需求管理制度形成、 按新流程推进后， 可以在项目资金整 体投入方面得到控制， 因为需求本身质量和开发质量都得以提升， 日常争论降低， 分析、 开发效率都得到提高。
2） 该制度的形成需要配备相应的工具， 对于需求的计划跟踪、 需求评审、 需求 质量控制进行有效监控。需要加强人员培训， 熟悉相应的工具；需要增加若干审批 环节， 增加管理资金投入。
3） 新制度形成会造成各环节流程变动， 对于过往习惯造成影响， 这就需要整个 团队的适应。需要各部门群策群力， 才能将制度落到实处。
2、 需求接收及其分析 需求文档提供及分析文档形成也涉及到了文档命题（需要文档（解释和沟通） 支 持过程活动可视化， 使得复杂的智力密集的支持过程活动得到有效地控制）。在开 发前期形成双方认可的文档是减少功能交付后争议的有效办法。
3、 需求评审 在需求文档和需求分析文档形成后， 可会同专家小组， 对于需求提交、 分析的 质量进行监控， 在评审过程中就双方理解的差异进行消除， 并对后续需求提交、 分析的质量提出指导意见。评审后， 形成评审文档备案。
4、 需求计划定制及跟踪 在需求经过多方确认后， 可根据现有开发团队的人力结合需求的优先级确定需 求开发计划， 并将计划登记入需求跟踪表， 需求过程进行统一跟踪， 各部门均可 获取当前需求的进展状态。如果对于计划有调整需求的， 需要有明确的审批机制， 评估调整计划对于项目整体进度的影响， 经过相关干系人协调一致后， 予以调整。
5、 需求开发及更新过程 需求开发阶段， 需要在设计文档、 测试文档提供方面进行加强， 提高需求开发 的整体质量。需求提交纳入配置管理库， 由专人进行版本的更新， 在更新时检查 对应文档的提供情况。
6、 需求变更 变更需要在新流程中明确登记原因、 追溯变更设计的功能点， 并对变更进行审 核。变更得到严格控制， 并定期对各部门变更进行统计， 提高需求提交的计划性和 需求本身的质量。
7、 团队培训 成熟度命题（需要不断地组织学习以持续地改进全组织的软件支持过程能力。一方面团队需要学习新流程推行中需要遵循的规范， 另一方面团队也需要接触新流 程配套使用的工具。同时需要不断提升自身业务、 技术水平以适应新流程。效果命题：需要明确地努力和定期地强化其效果。通过不断增加团队的适应水 平， 使新流程的效果得以显现， 不断的效果显现本身就是对团队的激励， 使得新流 程的认可度不断提升。
8、 过程改进 过程命题：需要仔细地进行过程设计来减轻甚至消除软件支持过程认知障碍并提 高群体认知活动的效力和效率。新流程的形成必然存在一定的瑕疵， 因此在流 程推进过程中需要不断总结， 消除新流程推进过程中的问题。使各部门消除推 进新流程的顾虑， 体现新流程的价值。
（三） 形成的流程 经过多方讨论， 我们形成了需求管理理流程
（四） 改进小结
在执行新的管理制度后， 得到领导层的支持， 并有序推进。各业务部门在实践过 程中发现新的流程带来了需求开发质量的提高和团队需求进度承诺的有效， 也普遍接受 了新的管理流程。开发在推行新流程后， 减少了临时事务， 客户满意度提高， 团队士气 得以提升， 也普遍接受了新的流程。
领导层在经过数月后发现需求提交和开发质量大幅度提升、 需求进度可控， 对项目 团队和各部门的工作都给予了较高评价！