白癜风可以治疗好吗 http://pf.39.net/bdfyy/bdflx/190522/7157873.html出品
51Testing软件测试网
6.1.3 需求说明书
开发软件系统最困难的部分就是准确说明开发什么；最困难的概念性工作是编写详细技术需求，这包括所有面向用户、面向机器和其他软件系统的接口。同时，这些也是一旦做错将最终会给系统带来极大损害的部分，并且以后再对它们进行修改也极困难。
每个软件产品都是为了使其用户能以某种方式改善他们的工作和生活，于是，花在了解他们需求上的时间便是使项目成功的一种高层次的投资。这对于最终用户的业务应用程序、企业信息系统及一个大的软件系统中的部分产品都是非常重要的。然而，即便并非出于商业目的的软件，如软件库、组件和工具这些供开发小组内部使用的软件，需求也是必需的。
当然，你可能偶尔不需要文档说明就能与其他人的意见一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价。
怎样才能区分优秀的和糟糕的需求说明书？下面讨论整个需求说明书和每条需求说明的特点。让项目各方从不同角度对需求说明书进行认真评审，确定哪些需求确实是需要的。只要你在编写、评审需求时把这些特点记在心中，就会写出更好的需求文档，同时也会开发出更好的产品。
1．需求说明书的七大特征
完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有信息。
正确性：每一项需求都必须准确地陈述要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统需求说明。若软件需求与对应的系统需求相抵触，则软件需求说明书是不正确的。只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。没有用户参与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。”其实这完全是评审者的凭空猜测。
可行性：每一项需求在已知系统和环境的权能与限制范围内是可以满足的。为避免不可行的需求，最好在获取需求（收集需求）的过程中软件工程小组的一位组员始终与需求分析人员或市场分析人员一起工作，由软件工程小组的成员负责检查技术可行性。
必要性：每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。每项需求都能回溯至客户的某项输入。
划分优先级：给每项需求、特性或用例分配一个实施优先级，以指明它在特定产品中所占的分量。如果所有的需求都同样重要，那么项目管理者在开发或节省预算或调度中就会丧失控制自由度。
无二义性：对软件需求说明书的所有读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，因此尽量把每项需求用简洁明了的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查、编写测试用例、开发原型及设计特定的方案脚本。
可验证性：检查一下是否能通过设计测试用例或其他的验证方法（如用演示、检测等）来确定产品按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾、不可行或有二义性的需求是不可验证的。
2．每条需求说明的四大特点
完整性：不能遗漏任何必要的需求信息。遗漏的需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息，用TBD（ToBeDetermined，待确定）作为标准标识来标明该项缺失。在开始开发之前，必须解决需求中所有的TBD项。
一致性：与其他软件需求或高层（系统、业务）需求不相矛盾。在开发前必须解决所有需求间的不一致问题。只有进行一番调查研究，才能知道某一项需求是否确实正确。
可修改性：在必要时或维护每一个需求变更历史记录时，应该修订SRS。这就要求每项需求要独立标出，并与其他需求区别开来，从而无二义性。每项需求只应在SRS中出现一次，这样在更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求说明书更容易修改。
可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接。可跟踪性要求每项需求以一种结构化的、细粒度（fine-grained）的方式编写并单独标明，而不是以大段的文字叙述。
6.2 需求工程概要
需求工程是随着计算机的发展而发展的，在计算机发展初期，软件规模不大，软件开发所
