对大多数国内软件企业来说，CMM的实施还处于起步阶段，准备实施CMM2级的企业占绝大多数，因此， 分析CMM2级实施过程中的问题，将有助于这些企业尽快找到适合本企业的实施方式。
一些正在实施CMM2级的企业发现有大量的重复性工作要做，原因何在？没有做好需求开发是产生这一 问题的主要原因！
1 需求管理与需求工程
需求开发和需求管理是需求工程的两部分，如果没有做好需求开发，那么从需求管理的角度看就会出 现重复性的工作。导致需求开发欠佳的主要原因有以下几点：
◆ 缺乏良好的需求规格说明编写模板
分析一些企业的CMM实施过程，从表面上看，它们的确遵循了先推荐方案再进行评审的基本选择原则， 但由于缺乏经验，实际选定的方案常常缺乏客观性，同时在企业的工程和管理机制里又缺乏实践反馈的方 法和过程来不断地改进原有的方案。一般来说，大家在一起工作的时间长了，就会形成一种“默契”，而 这很可能给以后的工程和管理工作埋下很多隐患，一旦出现意见分歧时，这种默契就不复存在。如果按 CMM的要求去做，大量类似的重复工作就会因此出现。改进的方法之一是在整个工程和管理过程中，既保 持文档和产品的一致性，又反向追踪需求规格说明更改的程度，并持续改进需求规格说明编写模板。
◆ 较严重地忽略了非功能性需求
目前，国内的软件客户很少主动提出非功能性需求，但随着客户的逐渐成熟，软件客户对软件的非功 能性需求也会越来越高，这就对软件开发商提出了更高的要求。不做好非功能性需求的规格说明编写工作 ，同样会陷入大量重复工作的包围之中。
如果缺乏非功能性需求的规格说明，将会使一些基础问题直到软件生命的中期才被发现，这将导致大 量的文档和产品需要更改，由此带来严重的工程和管理难题。改进的方法之一是调用有相当软件调试和维 护背景的资深人员参与需求规格说明的编写，他们的丰富经验往往可以较好地弥补设计开发人员在这方面 存在的不足。
◆ 缺乏对需求文档的配置管理
采用两个需求规格说明编写模板是一种不错的做法：一份给软件客户看，一份留给软件开发小组内部 使用，前者的目标是让客户较容易理解，后者则更加专业化。在这种情况下，两个需求规格说明都应纳入 配置管理的范畴以便从管理的角度保持其一致性。这还不够，从工程角度考虑，企业还应该形成一套从前 者到后者的转化规则。尽管这两个模板的表现形式可能是自然语言，但一个尽可能严谨的规则将大大缩小 转化过程中人为自由发挥的空间。需要注意的是，这套规则的建立应从一个项目开始，从基础做起，逐渐 完善。例如，首先确定项目的基本名词和动词集合，并规定语句书写规则。
◆ 需求规格说明缺乏可测性
在需求说明应具备的几个特性里，为什么单单挑出可测性呢？在需求说明编写阶段，主观性对其他特 性的影响较大，而一个独立且有经验的测试组对可测性的掌握是从独立于需求规格说明的测试文档出发的 。从测试的角度看，很多需求说明是不可测的，这就要求重写这些需求说明，直到可测性得到保证。测试 组要求的往往是简洁且准确的说明，而这恰恰是开发人员做得不够好的几个方面之一；另一方面，目前无 论是国内的市场还是企业，对测试人员都不够重视，软件企业很少招聘测试人员。实际上，优秀的软件测 试人员对保证软件质量非常重要，一般来说，测试部门的经理应该由具有软件开发经验、做过软件开发管 理且有相当测试经验的资深人员担任。处理好设计和测试人员的关系是众多国内软件企业应该进一步重视 的问题。
◆ 缺乏较好的需求规格说明转化规范
需求规格说明转化的目的是把用自然语言书写的需求说明转化为更准确的中间形式，这一转化过程也 被称为“软件建模”。一般来说，建模可以使需求说明的某些方面更形式化一些，并使设计更加清晰地保 持需求继承。通常，不做需求规格说明转化或缺乏较好的需求规格说明转化规范，将造成不同程度的需求 说明丢失，从而增加后续管理工作的难度。
需求管理的根本目的是为其后的工程和管理建立基线并保持相关及衍生文档和产品与需求的一致性， 因此需求工程完成得好坏对需求管理实施的工作量有很大影响。