如何编写高质量需求（一）.pdfVIP

如何编写高质量需求 Karl E Wieger Process Impact 译者说明：本文于1999 年5 月初版于软件开发，再版（有修订）得到软件开发杂志的授权 译文未得到相应授权，禁止用于商业目的。有出处，以原文为主。 你的工程应该有个好的起点。一个小组要带领客户进入需求启发阶段而且你要写软件需 求说明书。这份说明有些大，但客户会很重视，所以说明必须得到赞同。 现在你正在设计其中的一个特性，已经发现了需求的一些问题。你可以用多种不同的方 式解释需求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 to specify requirements ）。跟踪每 个需求回溯到出处，如用例，系统需求，规章，或来自其他用户的意见。如果你不能标识出 处，可能需求只是个镀金的例子，没有真正的必须。 优先权：为了表明在一个详细的产品版本中应包含哪些要点，需要为每个需求，特征， 或用例分配实现的优先权。客户或其代理都应有强烈的责任建立优先权。如果所有的需求都 被视为同等重要，那么由于在开发中，预算削减，计划超时或组员的离开导致新的需求时， 项目经理将不能