CMM
CMM（capability Maturity Model）过程成熟度模型，这个概念是由位于宾夕法尼亚洲匹兹堡市的卡内基梅隆大学所属的软件工程研究所提出的。CMM是在软件开发机构中被广泛地用来指导过程改进工作的模型。该方法描述了软件处理能力的五个成熟级别。处于一级的组织典型地以非正式的方式管理项目进度，要获得成功，主要依靠天才从业者和管理者的英雄史诗般的奋斗。处于更高成熟度级别的组织把具有创造性、训练有素的员工同软件工程和项目管理过程结合起来，将持续不断地获得成功。 过程能力成熟度模型对需求管理是一个有用的指导。为达到软件过程能力成熟度模型的第二级，组织必须具有在软件开发与管理的六个关键过程域（key process areas，KPA）以展示达到目标的能力。需求管理是其中之一，它的目标如下：
1) 把软件需求建立一个基线供软件工程和管理使用。
2) 软件计划，产品和活动同软件需求保持一致。
需求管理的关键过程领域不涉及收集和分析项目需求。而是假定已收集了软件需求或已由更高一级的系统给定了需求。一旦需求到手且文档化了，软件开发团队和有关的团队（例如质量保证和测试）需要评审文档。发现问题应与客户或其它需求源协商解决，软件开发计划是基于已确认的需求。 开发团队在向客户、市场部或经理们作出承诺（commitment）之前，应该确认需求和确认约束条件、风险、偶然因素、假定条件。也许不得不面对由于技术因素或进度原因而不现实的需求作出承诺。但是，决不要承诺任何无法实现的事。
关键处理领域同样建议通过版本控制和变更控制来管理需求文档。版本控制确保随时能知道在开发和计划中正在使用的需求的版本情况。变更控制提供了支配下的规范的方式来统一需求变更，并且基于业务和技术的因素来同意或反对建议的变更。当在开发中修改、增加、减少需求时，软件开发计划应该随时更新以与新的需求保持一致。不反映现实的计划于事无补。 必需要强调的一点是，CMM只是推荐方法，并没有说你一定要采用这种方法。仔细的分析自身的特点，总结适合自身的方法。但是CMM提到的两个目标却是任何需求活动都应该追寻的目标。事实上，不但各个企业采用的方法不同，即便是企业内部，对于不同的项目，也不存在一个标准的模式。每个项目都有自身的特点，不能强制性的要求他们采用同样的模板。所以在项目开始的时候，一般在项目可行性论证的时候，管理小组就会根据本个项目的特性制定项目计划和需求计划。 需求管理步骤
开发组织应该定义项目组执行管理他们需求的步骤。文档化编写这些步骤能使组织成员持续有效地进行必要的项目活动。请考虑选择以下主题：
1、用于控制各种需求文档和单个需求版本的工具、技术和习惯做法。
2、建议、处理、协商、通告新的需求和变更给有关的功能域的方法。
3、如何制定需求基线。
4、将使用的需求状态，并且是谁允许作出的变更。
5、需求状态跟踪和报告过程。
6、分析已建议变动的影响应遵循的步骤。
7、在何种情况下需求变更将会怎样影响项目计划和约定。
你可以在一个文档中包含上面所有的信息。或者，你可能喜欢专题分述，例如分成变更控制过程，影响分析过程，状态跟踪过程。这些过程可能在多个项目中都有用，因为他们反映每个项目所应遵循的公共功能。
需求控制的工具有很多，你可以使用专业的Rational公司的RequisistPro，也可以使用一些可视化的数据库管理工具，甚至你可以只是使用目录结构。用什么样的工具并不是特别重要，关键还是在于人。上面已经说过，需求的管理最重要的（关键过程域）就是版本控制和变更管理。这两个方面是密切相关的。需要版本控制的一个重要因素就是需求在不断的变化。
文档的海洋
虽然到现在还没有提到任何的具体文档，但是需求过程的产品中大都是文档。文档的产生目的是为了项目能够被控制。如果为了实现控制项目的目的，而文档却陷入了不可控制的境地，那就是一条歧途了。想象起来是很可笑，但是这个错误是确实存在的。往往有一些狂热的技术分子，为了追求完美的实施项目管理，实施了过多的文档，可是这个项目本身并没有想象的那么庞大。到了最后，是由于文档的失控导致了项目的失控。即便是以完善著称的RUP（Rational Unifined Process）也并不提倡制作过多的文档。控制好你的计划，使之适合你的项目。需求分析人员应该专注于需求的获取和分析，而不是写出漂亮的文档。当然，如果用户有这方面的要求的话，你是应当重视的。
文章来源于领测软件测试网 https://www.ltesting.net/
