这两个月来，主要都是在进行和需求相关的培训和咨询，我发现在行业里一个根深蒂固的认识是需要/可以存在多份不同格式的分立的需求文档：业务人员可以写一份意识流的业务（客户）需求文档，开发人员可以在再写一份充斥着分析结果及IT术语的软件（软件）需求，测试人员则可以写一份闭门造车的测试需求。好像每个人都很好的完成了任务，但是谁来保证这些需求的一致性呢？我们有很好的答案—请业务人员确认他们看不懂的软件需求，请开发人员确认他们没时间或心思看的测试需求，绝妙的主意！

目前大多数客户编写软件需求规约的思路和格式基本上都与IEEE Std 830-1998标准一脉相承，这种基于结构化分析和功能分解的文档体系（包括数据流图，数据字典等）起源于70年代，当时，软件的主要应用还是科学计算或信息处理，理解需求的人往往也受过结构化分析的相关教育，然而这些内容对今天的大多说业务人员或最终用户而言就是很难理解的了。可以说在这样的软件需求规约里分析多于需求，为了解决这个问题，有的组织开始引入了非形式化、非结构化的业务需求，然而却很难在两种需求之间建立明确的对应关系，从而造成了第一段中描述的困境。

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

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

• 前景文档：对目标系统的商业前景进行分析；
• 涉众分析：对目标系统的涉众以及他们对目标系统的主要要求（Needs）进行分析；
• 特性列表：概述目标系统的主要特性
• 词汇表：对领域内的名词、术语和商业规则进行解释；
• 领域模型：用模型的方式对领域内的实体关系进行描述；
• 用例模型：对整个用例模型进行概述；
• 用例规约：对每个用例的基本流和备选流进行详细的描述；
• 补充规约: 对目标系统级的非功能性需求进行描述；

我们推荐的工作方式是：

• 不同的角色（业务，开发，测试等）组成一个虚拟团队，基于同一个基于用例的需求体系进行协同的需求开发；
• 在需求开发的前期，以业务人员为主导，通过对业务的分析来丰富需求的内容； 而在需求开发的中后期，以开发人员为主导，通过对需求的分析来细化需求；如果组织需要通过CMMI评估，那么可以将前期的一个需求基线作为客户需求，而将后期的一个需求基线作为产品需求；
• 需求是在开发过程中不断演进的，虚拟需求团队定期对需求的变更进行复审，因此对需求的确认是不断以增量方式进行的；
• 开发人员将需求分析的结果以需求分析规约或分析模型的方式记录下来，但如果认为需求有问题，就应该以协作的方式对需求进行改进而不是另写一份文档；
• 测试人员同样也是对需求进行分析准备测试方案和测试用例，并同时对需求提出改进建议；
• 可能需要考虑引入一些工具来支持这样的协同需求开发过程；

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