1 需求管理与需求工程

　　需求开发和需求管理是需求工程的两部分，如果没有做好需求开发，那么从需求管理的角度看就会出现重复性的工作。导致需求开发欠佳的主要原因有以下几点：

◆ 缺乏良好的需求规格说明编写模板

　　分析一些企业的CMM实施过程，从表面上看，它们的确遵循了先推荐方案再进行评审的基本选择原则，但由于缺乏经验，实际选定的方案常常缺乏客观性，同时在企业的工程和管理机制里又缺乏实践反馈的方法和过程来不断地改进原有的方案。一般来说，大家在一起工作的时间长了，就会形成一种“默契”，而这很可能给以后的工程和管理工作埋下很多隐患，一旦出现意见分歧时，这种默契就不复存在。如果按CMM的要求去做，大量类似的重复工作就会因此出现。改进的方法之一是在整个工程和管理过程中，既保持文档和产品的一致性，又反向追踪需求规格说明更改的程度，并持续改进需求规格说明编写模板。

◆ 较严重地忽略了非功能性需求

　　目前，国内的软件客户很少主动提出非功能性需求，但随着客户的逐渐成熟，软件客户对软件的非功能性需求也会越来越高，这就对软件开发商提出了更高的要求。不做好非功能性需求的规格说明编写工作，同样会陷入大量重复工作的包围之中。

　　如果缺乏非功能性需求的规格说明，将会使一些基础问题直到软件生命的中期才被发现，这将导致大量的文档和产品需要更改，由此带来严重的工程和管理难题。改进的方法之一是调用有相当软件调试和维护背景的资深人员参与需求规格说明的编写，他们的丰富经验往往可以较好地弥补设计开发人员在这方面存在的不足。

◆ 缺乏对需求文档的配置管理

　　采用两个需求规格说明编写模板是一种不错的做法：一份给软件客户看，一份留给软件开发小组内部使用，前者的目标是让客户较容易理解，后者则更加专业化。在这种情况下，两个需求规格说明都应纳入配置管理的范畴以便从管理的角度保持其一致性。这还不够，从工程角度考虑，企业还应该形成一套从前者到后者的转化规则。尽管这两个模板的表现形式可能是自然语言，但一个尽可能严谨的规则将大大缩小转化过程中人为自由发挥的空间。需要注意的是，这套规则的建立应从一个项目开始，从基础做起，逐渐完善。例如，首先确定项目的基本名词和动词集合，并规定语句书写规则。

◆ 需求规格说明缺乏可测性

　　在需求说明应具备的几个特性里，为什么单单挑出可测性呢？在需求说明编写阶段，主观性对其他特性的影响较大，而一个独立且有经验的测试组对可测性的掌握是从独立于需求规格说明的测试文档出发的。从测试的角度看，很多需求说明是不可测的，这就要求重写这些需求说明，直到可测性得到保证。测试组要求的往往是简洁且准确的说明，而这恰恰是开发人员做得不够好的几个方面之一；另一方面，目前无论是国内的市场还是企业，对测试人员都不够重视，软件企业很少招聘测试人员。实际上，优秀的软件测试人员对保证软件质量非常重要，一般来说，测试部门的经理应该由具有软件开发经验、做过软件开发管理且有相当测试经验的资深人员担任。处理好设计和测试人员的关系是众多国内软件企业应该进一步重视的问题。

◆ 缺乏较好的需求规格说明转化规范

　　需求规格说明转化的目的是把用自然语言书写的需求说明转化为更准确的中间形式，这一转化过程也被称为“软件建模”。一般来说，建模可以使需求说明的某些方面更形式化一些，并使设计更加清晰地保持需求继承。通常，不做需求规格说明转化或缺乏较好的需求规格说明转化规范，将造成不同程度的需求说明丢失，从而增加后续管理工作的难度。

　　需求管理的根本目的是为其后的工程和管理建立基线并保持相关及衍生文档和产品与需求的一致性，因此需求工程完成得好坏对需求管理实施的工作量有很大影响。

2 配置管理与工作产品的转化

　　软件配置管理的目的是保证项目生成的产品在软件生命周期中的完整性，它需要一个较好的工具，当找不到较好的商用软件工具覆盖该关键域的实践时，许多国外软件企业会自行开发一些工具来弥补不足，并且取得了很好的效果。国内软件企业在实施该关键域时也会使用一些工具，但存在的典型问题是：有太多的SCCB（软件配置控制委员会）活动。

　　配置管理是在软件生命周期中建立和标识软件工作产品并控制基线的更改，这将保证软件工作产品的完整性和一致性。但是，作为配置项/单元标识的软件工作产品通常为典型的软件生命周期中的工作产品，这些产品具有一个共同特点：一个产品通常是由另一个产品转化而来。从一些企业配置管理下的工作产品来看，存在的主要问题是缺乏较好的可转化性。在这里，“较好的可转化性”是指把一个产品转化为另一个产品时有较规范的转化规则可循，其目的是最大程度地保证一种工作产品能被忠实地转化为另一种工作产品形式，从而最大限度地降低最初的软件需求在转化过程中出现遗漏和被错误解释的可能性。企业在实施这个关键过程域时，应由SCCB记录工作产品的更改以及引发这些更改的原因，这些数据能很好地帮助企业找出问题的症结。一般来说，引发类似问题的原因主要有以下3点：

　　需求规格说明书编写不好或不全；

　　工作产品模板定义不好；

　　工作产品之间转化缺乏规范定义。

3 项目计划与数据收集和分析

　　项目计划是CMM实施一开始就涉及且最后才能相对完善的关键过程域，它主要包括软件规模估计、工作模块计划、人力资源计划、进度安排和其他资源计划。在其他关键过程域的实践相对稳定之前，项目计划的实践总是处于需要改动的状态。

　　一般来说，期望在CMM实施之初就有一个可靠的项目计划是不现实的，因为这需要经历若干项目的实施才能获得有效数据并据此制定未来项目的计划。我们知道，配置管理可以保证项目生成的产品在软件生命周期中的完整性，因此，为了更好地实施项目计划，我们可以把用于项目计划的大部分数据放在对应的工作产品配置管理之下，必要时，还可将工作产品进一步细化，以保证对应的项目计划数据的准确性。项目完成后，我们还应该对项目计划的数据进行收集和分析，在此基础上制定下一个项目计划时，准确性就能大大提高。通过对若干项目进行同样的实践，项目经理就有了比较可靠的数据用于制定未来的项目计划。通常，项目跟踪和监督实施不好的原因很大程度上是由于项目计划的频繁更动，同时缺乏良好的项目跟踪工具，使项目管理人员逐渐失去跟踪项目的兴趣。

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