软件需求说明书.doc

您的工程应该有个好的起点。一个小组要带领客户进入需求启发阶段而且您要写软件需求说明书。这份说明有些大,但客户会很重视,所以说明必须得到赞同。

现在您正在设计其中的一个特性,已发现了需求的一些问题。您能够用多种不同的方式解释需求15;需求9 的说明正好和需求21相反,您因该相信哪一个?需求24很含糊,您根本不明白他的意思;您不得不花上一个小时和2位研发人员讨论需求30,只因为您们对其各有各的理解;并且,唯一能够澄清这些问题的客户没有给您们答复。您被迫破解众多需求的含义,并且您能预料到,假如您错了,您要做大量的重复工作。
许多软件需求说明书(SRS)写得很糟糕。任何产品的质量需要其原始材料的质量确保,糟糕的软件需求说明书不可能产出优秀的软件。不幸的是,几乎没有研发人员受过和需求的抽象、分析、文档、质检有关的教育。而且,没有很多的好需求能够借鉴学习,部分原因是很少有工程能够找到一个好的借鉴,其他原因是公司不愿意将其产品说明书放在公共区域。
这篇文章描述了高质量需求叙述和说明的几个特性(特点)。我们将用这些观点检查一些有缺陷的需求,带着痛楚重新编写。而且我会谈一些如何编写好的需求的提示。您也许想通过这些质量标准评估您的工程需求。对于修订,也许迟了,但您会学到一些有用的东西,并帮助您的小组在下次编写出更好的需求。
不要期望能够编写出一份能体现需求应具备的任何特性的SRS。无论您怎么细化、分析、评论和优化需求,都不可能达到完美。但是,假如您牢记这些特性,您就会编写出更好的需求,生产出更好的产品。
高质量需求叙述的特性
我们如何从一些有问题的需求中分辨出好的软件需求?这一节将分别介绍需求叙述应体现的6个特性,下一节将从整体上介绍SRS文档应具备的特性。判断每个需求是否具备应有的特性的一种方式是由持有不同观点的工程资金管理人所作的正规检查。另一种有力的方法是在编写代码前依据需求编写测试例子。测试例子能够明确显现在需求中描述的产品行为(特性),能够显现缺陷、冗余和含糊之处。
正确:每个需求必须精确描述要交付的功能。正确性依据于需求的来源,如真实的客户或高级别的系统需求说明书。一个软件需求和其对应的系统需求说明书相抵触是不正确的(当然,系统需求说明书本身可能不正确)。
只有用户的代表能够决定用户需求的正确性,这就是为什么在检查需求时,要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致研发人员的:“这是没意义的”,“这可能是他们的意思”等众所周知的猜测。
可行性:在已知的能力、有限的系统及其环境中每个需求必须是可实现的。为了避免需求的不可行性,在需求分析阶段应该有一个研发人员参和,在抽象阶段应该有市场人员参和。这个研发人员应能检查在技术上什么能做什么不能做,哪些需要需要额外的付出或和其他的权衡。
必要性:每个需求应载明什么是客户确实需要的,什么要顺应于外部的需求,接口或标准。每个需求源于您认可、具备权说明需求的原始资料,这是考虑必需的另外情形(译注,此句翻译不顺,请参照原文:Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority