CMM关键过程域剖析——成熟度级别2：需求管理

CMM关键过程域剖析——成熟度级别2：需求管理

需求管理是CMM二级中列出的第一个关键域，这是因为它实际上是二级引入到开发过程中的所有管理原则的先决条件。只有在开发的目标被清楚明白地表述和理解的情况下，软件开发才能以一种有计划的有序的方式进行。实际上，没有文档化的需求，在开发工作完成前后都很有可能发生产品与要求的偏离。计划、追踪、配置管理以及软件质量保证这些在二级的其他关键过程域中涉及的原则，都是从一个稳定的基础开始的，那就是文档化的需求基线。

什么需求？谁的需求？

CMM已经说得很清楚：本关键过程与中所说的需求是指“分配给软件的系统需求“，或者更简洁地说，“分配需求”。这些需求有可能是技术方面的（比如：功能和性能需求），也有可能是非技术方面的（比如：发布日期，开支限度）。这里假设被开发的软件是更大的系统中的一部分，这个更大的系统包括了正在开发着的软件和所有其它组件。更进一步的假设是那个更大的系统就是一位客户，这个客户是所有系统需求的来源。他不需要负责区分软件所要实现的系统需求和其他的需求。确切地说，负责选择哪些系统需求必须分配给软件的人是系统工程组。但是，在执行这个角色的时候，系统工程组并不是独自行事的。这个观点在本关键过程域的行为1中有明显的证据，原文如下：

“软件工程组在分配需求合并入软件项目中之前对其进行复审。“（CMU/SEI-93-TR-25,RM.AC.1）

一般的混乱点存在于没有高一级的系统或者正被开发的软件就是整个产品的情况下。尽管这种情况下没有分配给软件的需求，但为了保持CMM的一致性，仍然使用“分配需求”的概念。毫无疑问，这个概念在这里是不能直接应用的，但是可以通过所有的产品需求都是分配需求来解释。

区分开需求管理（CMM中的概念）和软件需求分析（软件工程文献中的概念）是很重要的。一旦分配需求被文档化，并且被所有受影响部门（客户，系统工程，软件工程）通过，需求管理的基本工作就完成了，所剩下的就是管理变更而已。没有证据证明分配需求本身就可以十分清楚完整的作为软件开发的全部基础。事实上，通常它们不是。优化和精确描述需求，填补漏洞，将含义表达得更清楚是软件需求分析要做的，分析的结果在CMM中被称为“软件需求“。这样，作为需求管理的输出的分配需求实际上就成了软件需求分析的输入。需求管理远远先于软件开发的技术行动，而软件需求分析则是关键开发技术行为的第一步。

客户的主张也必须阐明。CMM词汇表中对“客户”的定义是：

“负责接收产品并且付给开发组织报酬的个人或组织。”

当一个组织为外部客户在合同约定下做软件开发时，这个概念很清楚并且可以直接的应用。甚至当一个大公司的软件开发部门为公司的其他部门开发系统的时候，也即当存在一个“内部用户”的时候，这个词的使用也是可以凭直觉的。但是在商业产品开发的情况下可能会有混乱产生，在这种情况下，软件开发的努力作为开发组织的一种投资，真正的用户是决

定买不买最终的产品。这种客户在软件开发中不扮演任何角色，当然也不会与软件组织“关于需求达成协议”。但是，即便是在这种商业产品的情况下，在公司的内部也存在着这样的组织负责决定那些特征为预期的用户所需要，这些用户愿意为什么掏钱。这个组可能在客户群中做市场调查，也可能与一些典型用户展开讨论会，还有可能他们使用企业现有的客户库中的反馈信息。无论他们怎样收集信息，CMM都把这个组看作是客户的代理，并且期望在开发启动之前，代理客户与软开发组之间在需求方面达成协议。

需求变更

因为现实世界的软件系统可能有不同的严格程度和复杂性，事先预言所有的相关需求是不可能的。系统原计划的操作环境会改变，用户的需求会改变，甚至系统的角色也有可能改变。实际上，实现和测试系统的行为可能导致对正解决的问题的新的理解和洞察，这种新的认识就有可能导致需求变更。

CMM承认这一事实。实际上，本关键过程域的行为3是如此表述这个问题的：

“分配需求的变更被复审，并加入到软件项目中来。”（CMU/SEI-93-TR-25,RM.AC.1）

此处的关键是在需求发生变更时，没有必要马上把这些变更付诸软件开发工作。实际上，坚持把需求变更付诸开发努力，企业就会形成一种混乱且不稳定的氛围，浙江严重破坏项目的控制和管理。需求管理关键过程域试图通过把分配需求的变更囤积到可管理的组中，等到开发工作允许的时候在引入的方法，避免产生这种混乱的氛围。结果，需求管理创建了一个隔绝开发工作与所有的真实的、潜在无序的、来自于客户的变更。这个缓冲器允许真实的变更被注意、记录、追踪，同时开发工作又不会因此而被扰乱。开发项目应该周期性的暂停来吸收最新的需求变更积累，此时，所有的计划，设计，行为都根据刚刚吸收的需求变更的影响进行更新。

维护的需求管理

需求管理只能应用于新的开发项目中么？维护工作呢？需求管理怎样应用于维护工作?

CMM同样使软件维护工作从改进的过程成熟度中受益。在典型的维护情景中，有一系列的变更请求和/或问题报告必须满足。这些变更请求和问题报告可能单个的提出，也有可能为了分析实现之便综合成相联系的一组。无论哪种情况下，这些定义详细维护工作的目标的文档都作为“分配需求”的角色。而CMM要求的是把它们文档化，控制好，保证它们被所有的受影响组通过，保证软件维护计划和活动与它们保持一致，并且对它们来说是是可追踪的。变更请求和问题报告可以是维护组织选定的任意形式和内容，只要它们可以为软件维护人员提供充足的指导，帮助他们知道客户需要它们来做什么。与开发需求的情况相同，可能在技术工作之前可能会有技术诊断和分析，但这些诊断和分析的工作是技术维护活动的一部分，而不是需求管理的一部分。

需求管理的困难

从这里的描述看来，需求管理的活动简直太简单，太基础了，显然没有哪个软件开发组织会不有效的进行着这种活动。但是，我们看见许多处于一级水平的软件公司在为把该原则

付诸实施奋力拼搏着。

问题经常处在企业对透明度的惧怕。客户觉得保持需求含糊不清，松散或者无正式文件能够给他们更多的机会去说：“那并不是我所要的，那并不是我认为的需求的含义。”文档化清晰的需求可能迫使用户在系统满足了文档化的需求但没有满足实际需要的情况下，为开始变更负责。相似地，开发人员觉得含糊不清，松散或者无正式文件的需求能给他们更大的余地，允许他们与预算和进度尽可能地接近，然后说：“这就是我们所认为的需求的含义，如果你需要其他的什么东西，你必须另外付出代价。”文档化清晰的需求会迫使开发者承担满足这些需求的义务，并使他们暴露于开支、进度评估不准确的风险之下。

这样一来，尽管客户与开发人员的利益动机相对，但他们却走到了一起，偷偷摸摸地共谋抵抗CMM的实施。每一方都认为他们在保护自己的利益，巩固自己讨价还价的地位，但是事实上每一方都在走向将来的失望和争吵。

完美主义在这里也会成为障碍之一。人们通常承认，至少向自己承认，他们不清楚将来所有的系统需求。不幸的是，他们就这样想：因为需求不会完美，那么他们也就无法对需求文档化了。事实上，就像软件设计能在反复优化的每个阶段精确地用文档描述出来一样，软件需求也可以随着变化进行文档化，在进化的每个阶段，对系统需求的理解只在该阶段有效。对需求或者设计的连续影像的记录允许对该过程所学到的有个清楚的档案，允许所有的项目参与者对任何给定的关于正被开发的系统的问题，包括他们知道和不知道的都能够理解。有效的文档化和需求管理可以标志着一个软件企业的文化改变，通常几个主要文化改变中的第一次源自于长期的软件过程改进规划。但是，拥有清楚，写出来的需求显然是制订清晰的、写出来的、正式的承诺的必要前提。打破模糊的、暧昧的、没有文档化的需求是一种伟大的挑战。但是制订坚持遵守的承诺，并实践它，是个更加巨大的挑战。