怎样编写高质量“软件需求说明书”

怎样编写高质量

“软件需求说明

书”

如何编写高质量”软件需求说明书”

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

现在你正在设计其中的一个特性，已经发现了需求的一些问题。你能够用多种不同的方式解释需求15;需求9的说明正好与需求21相反,你因该相信哪一个?需求24非常含糊,你根本不明白它的意思;你不得不花上一个小时与2位开发人员讨论需求30,只因为你们对其各有各的理解;而且，唯一能够澄清这些问题的客户没有给你们答复。你被迫破解众多需求的含义，而且你能预料到，如果你错了，你要做大量的重复工作。

许多软件需求说明书(SRS)写得非常糟糕。任何产品的质量需要其原始材料的质量保证，糟糕的软件需求说明书不可能产出优秀的软件。不幸的是，几乎没有开发人员受过与需求的抽象、分析、文档、质检有关的教育。而且，没有非常多的好需求能够借鉴学习,部分原因是很少有工程能够找到一个好的借鉴，其它原因是公司不愿意将其产品说明书放在公共区域。

这篇文章描述了高质量需求叙述和说明的几个特性(特点)。我们将用这些观点检查一些有缺陷的需求，带着痛楚重新编写。而且我会谈一些如何编写好的需求的提示。你可能想经过这些质量

标准评估你的工程需求。对于修订，可能迟了，但你会学到一些有用的东西，并帮助你的小组在下次编写出更好的需求。

不要期望能够编写出一份能体现需求应具备的所有特性的SRS。无论你怎么细化、分析、评论和优化需求，都不可能达到完美。可是，如果你牢记这些特性,你就会编写出更好的需求,生产出更好的产品。

高质量需求叙述的特性

我们如何从一些有问题的需求中分辨出好的软件需求?这一节将分别介绍需求叙述应体现的6个特性，下一节将从整体上介绍SRS文档应具备的特性。判断每个需求是否具备应有的特性的一种方式是由持有不同观点的工程资金管理人所作的正规检查。另一种有力的方法是在编写代码前依据需求编写测试例子。测试例子能够明确显现在需求中描述的产品行为（特性），能够显现缺陷、冗余和含糊之处。

正确:每个需求必须精确描述要交付的功能。正确性依据于需求的来源,如真实的客户或高级别的系统需求说明书。一个软件需求与其对应的系统需求说明书相抵触是不正确的（当然，系统需求说明书本身可能不正确）。

只有用户的代表能够决定用户需求的正确性，这就是为什么在检查需求时，要包括她们或她们的代理的关键所在。不包括用户的需求检查就会导致开发人员的：”这是没意义的”，”这可能是她们的意思”等众所周知的猜测。

可行性:在已知的能力、有限的系统及其环境中每个需求必须是可实现的。为了避免需求的不可行性，在需求分析阶段应该有一个开发人员参与，在抽象阶段应该有市场人员参与。这个开发人员应能检查在技术上什么能做什么不能做，哪些需要需要额外的付出或者和其它的权衡。

必要性:每个需求应载明什么是客户确实需要的，什么要顺应于外部的需求，接口或标准。每个需求源于你认可、具有权说明需求的原始资料，这是考虑必须的另外情形(译注，此句翻译不顺，请参照原文：Anotherwaytothinkof"necessary"isthateachrequirementoriginatedfromasourceyourecognizeashavingtheauthoritytospecifyrequirements)。跟踪每个需求回溯到出处,如用例，系统需求,规章,或来自其它用户的意见。如果你不能标识出处,可能需求只是个镀金的例子，没有真正的必须。

优先权:为了表明在一个详细的产品版本中应包含哪些要点，需要为每个需求，特征，或用例分配实现的优先权。客户或其代理都应有强烈的责任建立优先权。如果所有的需求都被视为同等重要，那么由于在开发中，预算削减，计划超时或组员的离开导致新的需求时，项目经理将不能起到作用。优先权的作用是提供给客户的价值，实现的相关费用，实现相关联的有关技术风险。

我是用3种级别的优先权:高优先权表明需求必须体现在下一个产品版本中，中优先权表明需求是必须的,可是如果需要能够推迟到晚一些的产品版本中，低优先权表明有它很好,但我们必须认识到如果没有充分的时间或资源，它能够被放弃掉。

明确:需求叙述的读者应只能从其得到唯一的解释说明，同样，一个需求的多个读者也应达成共识。自然语言极易导致含糊。要避免使用一些对于SRS作者很清楚但对于读者不清楚的主观词汇，如:用户友好性，容易，简单，快速，有效，几个，艺术级,改进的，最大最小等等。每写一个需要都应简洁，简单，直观的采用用户熟知的语言,不要采用计算机术语。检查需求模糊的有效方式包括需求说明书的正规检查，根据需求写测试，建立用户的假想来说明产品某个特定部分预期的特性。

可证实:看你是否能够做出测试计划或其它验证方式,如检查和实证，来决定在产品中每个需求是否正确的实现。如果需求是不可验证的，决定需求是不是正确的实现就成了判断的事。需求之间不一致，不可行，不明确也能导致不可证实。任何需求如果说产品将要支持什么也是不可证实的。

高质量需求说明的特征

一个完整的SRS不但是包括长长的功能性需求列表，还包括外部接口描述和一些诸如质量属性，期望性能的非功能性需求。下面描述了高质量的SRS的一些特性。

完整:不应该遗漏要求和必须的信息。完整性也是一个需求应具备的。发现缺少的信息很难，因为根本不存在。在SRS中将需求以分层目录方式组织，将帮助评审人员理解功能性描述的结构，使她们很容易指出遗失的东西。

在需求抽象时，相对于系统功能，你过多的注意用户的业务，将导致在需求的全局观和引进不是真正必须的需求上显得不足。在需求抽象上，应用用例方法会发挥很好的作用。能够从不同角度察看需求的图形分析模型也能够检查出不完整性。

如果你知道已缺少一些信息，使用TBD(tobedetermined)标准标志能够突出这些缺陷，当你在构建产品的相关部分时,就能够从一个给定的需求集中解决所有的缺陷。

一致性:一致性需求就是不要于其它的软件需求或高级别的系统(商业)需求发生冲突。需求中的不一致必须在开发开始前得到解决。只有经过调研才能确定哪些是正确的。修改需求时一定要谨慎，如果只审定修改的部分,没有审定于修改相关的部分，就可能导致不一致性。

可修改性:当每个需求的要求修改了或维护其历史更改时，你必须能够审定SRS。也就是说每个需求必须相对于其它需求有其单独的标示和分开的说明，便于清晰的查阅。经过良好的组织能够使需求易于修改，如:将相关的需求分组，建立目录表，索引，以及前后参考（照）。

可追踪:你应能将一个软件与其原始材料相对应，如高级系统需求,用例,用户的提议等。也能够将软件需求与设计元素，源代码,用于构造实现和验证需求的测试相对应。可追踪的需求应该具有独立标示,细密和结构化的编写，不应过大，不应是叙述性的文字和公告式的列表。

需求质量的评审

这些有关需求质量的特性的描述在理论上都是非常好的，但一个好的需求到底是个什么样子的呢?为了体现得更切合实际，我们做个小练习。下面有几个从实