只需要一份需求.doc

只需要一份需求 这两个月来，主要都是在进行和需求相关的培训和咨询，我发现在行业里一个根深蒂固的认识是需要 /可以存在多份不同格式的分立的需求文档：业务人员可以写一份意识流的业务（客户）需求文档，开发人员可以在再写一份充斥着分析结果及 IT 术语的软件（软件）需求，测试人员则可以写一份闭门造车的测试需求。好像每个人都很好的完成了任务，但是谁来保证这些需求的一致性呢？我们有很好的答案 — 请业务人员确认他们看不懂的软件需求，请开发人员确认他们没时间或心思看的测试需求，绝妙的主意！ 目前大多数客户编写软件需求规约的思路和格式基本上 都与 IEEEStd830-1998 标准一脉相承，这种基于结构化分析和功能分解的文档体系（包括数据流图，数据字典等）起源于 70 年代，当时，软件的主要应用还是科学计算或信息处理，理解需求的人往往也受过结构化分析的相关教育，然而这些内容对今天的大多说业务人员或最终用户而言就是很难理解的了。可以说在这样的软件需求规约里分析多于需求，为了解决这个问题，有的组织开始引入了非形式化、非结构化的业务需求，然而却很难在两种需求之间建立明确的对应关系，从而造成了第一段中描述的困境。 另一个造成多份不同格式的分立的需求存在的 原因可能与僵化地执行 CMMI 有关， CMMI 在三级的需求开发（ RequirementsDevelopement）这个过程域（ ProcessArea）中将开发客户需求（ CustomerRequirements）和开发产品需求（ ProductRequirements）明确地分成了两个不同的特定目标（ SpecificGoals），这导致有些企业让业务人员负责客户需求，而让开发团队负责产品（软件）需求，表面上各司其职，但实际上带来的是大家在邮件里将文档发来发去，工作效率很低而沟通的效果也不好。 我们推荐的需求体系 是基于用例的 ,它是一种可以被各方真正理解和沟通、并可以被逐步精化的需求体系。用例是这一需求文档体系的主体，但其实这一体系是由如下文档来构成的： 前景文档：对目标系统的商业前景进行分析； 涉众分析：对目标系统的涉众以及他们对目标系统的主要要求（ Needs）进行分析； 特性列表：概述目标系统的主要特性 词汇表：对领域内的名词、术语和商业规则进行解释； 领域模型：用模型的方式对领域内的实体关系进行描述； 用例模型：对整个