下载后可任意编辑如何编写一个好的需求 如何编写高质量需求 KarlEWieger ProcessImpact 许多软件需求说明书（SRS）写得非常糟糕。任何产品的质量需要其原始材料的质量保证，糟糕的软件需求说明书不可能产出优秀的软件。不幸的是，几乎没有开发人员受过与需求的抽象、分析、文档、质检有关的教育。而且，没有非常多的好需求可以借鉴学习，部分原因是很少有工程可以找到一个好的借鉴，其他原因是公司不同意将其产品说明书放在公共区域。 这篇文章描述了高质量需求叙述和说明的几个特性（特点）。我们将用这些观点检查一些有缺陷的需求，带着痛楚重新编写。而且我会谈一些如何编写好的需求的提示。你也许想通过这些质量标准评估你的工程需求。对于修订，也许迟了，但你会学到一些有用的东西，并帮助你的小组在下次编写出更好的需求。 不要期望能够编写出一份能体现需求应具备的所有特性的 SRS。无论你怎么细化、分析、评论和优化需求，都不可能达到完美。但是，假如你牢记这些特性，你就会编写出更好的需求，生产出更好的产品。 一、高质量需求说明书的特性 我们如何从一些有问题的需求中分辨出好的软件需求？推断每个需求是否具备应有的特性的一种方式是由持有不同观点的工程资金管理人所作的正规检查。另一种有力的方法是在编写代码前依据需求编写测试例子。测试例子能够明确显现在需求中描述的产品行为（特性），能够显现缺陷、冗余和模糊之处。 ?正确： 每个需求必须精确描述要交付的功能。正确性依据于需求的来源，如真实的客户或高级别的系统需求说明书。一个软件需求与其对应的系统需求说明书相抵触是不正确的（当然，系统需求说明书本身可能不正确）。 1下载后可任意编辑 只有用户的代表能够决定用户需求的正确性，这就是为什么在检查需求时，要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的：“这是没意义的”， “这可能是他们的意思”等众所周知的猜想。 ?可行性： 在已知的能力、有限的系统及其环境中每个需求必须是可实现的。为了避开需求的不可行性，在需求分析阶段应该有一个开发人员参加，在抽象阶段应该有市场人员参加。这个开发人员应能检查在技术上什么能做什么不能做，哪些需要需要额外的付出或者和其他的权衡。 ?必要性： 每个需求应载明什么是客户确实需要的，什么要顺应于外部的需求，接口或标准。每个需求源于你认可、具有权说明需求的原始资料，这是考虑必需的另 外 情 形...
