CMM关键过程域剖析：需求管理

－－－－－－－－－－－－－－－－－－－－－－

本文欢迎转载，欢迎大家与我交流讨论。
联系方式：高巍（网名DrCMM）， w-gao@263.net

转载请保留本声明，谢谢！

－－－－－－－－－－－－－－－－－－－－－－－

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

    什么需求？谁的需求？

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

    “软件工程组在分配需求合并入软件项目中之前对其进行复审。
　　
    一般的混乱点存在于没有高一级的系统或者正被开发的软件就是整个产品的情况下。尽管这种情况下没有分配给软件的需求，但为了保持CMM的一致性，仍然使用“分配需求”的概念。毫无疑问，这个概念在这里是不能直接应用的，但是可以通过所有的产品需求都是分配需求来解释。
　　
    区分开需求管理（CMM中的概念）和软件需求分析（软件工程文献中的概念）是很重要的。一旦分配需求被文档化，并且被所有受影响部门（客户，系统工程，软件工程）通过，需求管理的基本工作就完成了，所剩下的就是管理变更而已。没有证据证明分配需求本身就可以十分清楚完整的作为软件开发的全部基础。事实上，通常它们不是。优化和精确描述需求，填补漏洞，将含义表达得更清楚是软件需求分析要做的，分析的结果在CMM中被称为“软件需求“。这样，作为需求管理的输出的分配需求实际上就成了软件需求分析的输入。需求管理远远先于软件开发的技术行动，而软件需求分析则是关键开发技术行为的第一步。
　　
    客户的主张也必须阐明。CMM词汇表中对“客户”的定义是：
　　
    “负责接收产品并且付给开发组织报酬的个人或组织。”
　　
    当一个组织为外部客户在合同约定下做软件开发时，这个概念很清楚并且可以直接的应用。甚至当一个大公司的软件开发部门为公司的其他部门开发系统的时候，也即当存在一个“内部用户”的时候，这个词的使用也是可以凭直觉的。但是在商业产品开发的情况下可能会有混乱产生，在这种情况下，软件开发的努力作为开发组织的一种投资，真正的用户是决定买不买最终的产品。这种客户在软件开发中不扮演任何角色，当然也不会与软件组织“关于需求达成协议”。但是，即便是在这种商业产品的情况下，在公司的内部也存在着这样的组织负责决定那些特征为预期的用户所需要，这些用户愿意为什么掏钱。这个组可能在客户群中做市场调查，也可能与一些典型用户展开讨论会，还有可能他们使用企业现有的客户库中的反馈信息。无论他们怎样收集信息，CMM都把这个组看作是客户的代理，并且期望在开发启动之前，代理客户与软开发组之间在需求方面达成协议。

    需求变更

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

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

    “分配需求的变更被复审，并加入到软件项目中来。”

原文转自：http://www.ltesting.net