另一个造成多份不同格式的分立的需求存在的原因可能与僵化地执行CMMI有关，CMMI在三级的需求开发(Requirements Developement)这个过程域(Process Area)中将开发客户需求(Customer Requirements)和开发产品需求(Product Requirements)明确地分成了两个不同的特定目标(Specific Goals)，这导致有些企业让业务人员负责客户需求，而让开发团队负责产品(软件)需求，表面上各司其职，但实际上带来的是大家在邮件里将文档发来发去，工作效率很低而沟通的效果也不好。

　　我们推荐的需求体系是基于用例的, 它是一种可以被各方真正理解和沟通、并可以被逐步精化的需求体系。用例是这一需求文档体系的主体，但其实这一体系是由如下文档来构成的：

　　前景文档：对目标系统的商业前景进行分析;

　　涉众分析：对目标系统的涉众以及他们对目标系统的主要要求(Needs)进行分析;

　　特性列表：概述目标系统的主要特性

　　词汇表：对领域内的名词、术语和商业规则进行解释;

　　领域模型：用模型的方式对领域内的实体关系进行描述;

　　用例模型：对整个用例模型进行概述;

　　用例规约：对每个用例的基本流和备选流进行详细的描述;

　　补充规约: 对目标系统级的非功能性需求进行描述;

　　我们推荐的工作方式是：

　　不同的角色(业务，开发，测试等)组成一个虚拟团队，基于同一个基于用例的需求体系进行协同的需求开发;　　在需求开发的前期，以业务人员为主导，通过对业务的分析来丰富需求的内容; 而在需求开发的中后期，以开发人员为主导，通过对需求的分析来细化需求;如果组织需要通过CMMI评估，那么可以将前期的一个需求基线作为客户需求，而将后期的一个需求基线作为产品需求;

　　需求是在开发过程中不断演进的，虚拟需求团队定期对需求的变更进行复审，因此对需求的确认是不断以增量方式进行的;

　　开发人员将需求分析的结果以需求分析规约或分析模型的方式记录下来，但如果认为需求有问题，就应该以协作的方式对需求进行改进而不是另写一份文档;

　　测试人员同样也是对需求进行分析准备测试方案和测试用例，并同时对需求提出改进建议;

　　可能需要考虑引入一些工具来支持这样的协同需求开发过程;

　　总之，我们推荐的需求开发方法是以一个紧密协同的虚拟团队在一个需求体系之上来进行的