6.1.3 需求说明书
开发软件系统最困难的部分就是准确说明开发什么；最困难的概念性工作是编写详细技术需求，这包括所有面向用户、面向机器和其他软件系统的接口。同时，这些也是一旦做错将最终会给系统带来极大损害的部分，并且以后再对它们进行修改也极困难。
每个软件产品都是为了使其用户能以某种方式改善他们的工作和生活，于是，花在了解他们需求上的时间便是使项目成功的一种高层次的投资。这对于最终用户的业务应用程序、企业信息系统及一个大的软件系统中的部分产品都是非常重要的。然而，即便并非出于商业目的的软件，如软件库、组件和工具这些供开发小组内部使用的软件，需求也是必需的。
当然，你可能偶尔不需要文档说明就能与其他人的意见一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价。
怎样才能区分优秀的和糟糕的需求说明书？下面讨论整个需求说明书和每条需求说明的特点。让项目各方从不同角度对需求说明书进行认真评审，确定哪些需求确实是需要的。只要你在编写、评审需求时把这些特点记在心中，就会写出更好的需求文档，同时也会开发出更好的产品。
1．需求说明书的七大特征
●完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有信息。
●正确性：每一项需求都必须准确地陈述要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统需求说明。若软件需求与对应的系统需求相抵触，则软件需求说明书是不正确的。只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。没有用户参与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。”其实这完全是评审者的凭空猜测。
●可行性：每一项需求在已知系统和环境的权能与限制范围内是可以满足的。为避免不可行的需求，最好在获取需求（收集需求）的过程中软件工程小组的一位组员始终与需求分析人员或市场分析人员一起工作，由软件工程小组的成员负责检查技术可行性。
●必要性：每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。每项需求都能回溯至客户的某项输入。
●划分优先级：给每项需求、特性或用例分配一个实施优先级，以指明它在特定产品中所占的分量。如果所有的需求都同样重要，那么项目管理者在开发或节省预算或调度中就会丧失控制自由度。
●无二义性：对软件需求说明书的所有读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，因此尽量把每项需求用简洁明了的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查、编写测试用例、开发原型及设计特定的方案脚本。
●可验证性：检查一下是否能通过设计测试用例或其他的验证方法（如用演示、检测等）来确定产品按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾、不可行或有二义性的需求是不可验证的。
2．每条需求说明的四大特点
●完整性：不能遗漏任何必要的需求信息。遗漏的需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息，用TBD（To Be Determined，待确定）作为标准标识来标明该项缺失。在开始开发之前，必须解决需求中所有的TBD项。
●一致性：与其他软件需求或高层（系统、业务）需求不相矛盾。在开发前必须解决所有需求间的不一致问题。只有进行一番调查研究，才能知道某一项需求是否确实正确。
●可修改性：在必要时或维护每一个需求变更历史记录时，应该修订SRS。这就要求每项需求要独立标出，并与其他需求区别开来，从而无二义性。每项需求只应在SRS中出现一次，这样在更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求说明书更容易修改。
●可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接。可跟踪性要求每项需求以一种结构化的、细粒度（fine-grained）的方式编写并单独标明，而不是以大段的文字叙述。
6.2 需求工程概要
需求工程是随着计算机的发展而发展的，在计算机发展初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。后来软件开发中引入了生命周期的概念，需求分析成为其第一个阶段。随着软件系统规模的扩大，需求分析与定义在整个软件开发和维护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。20世纪80年代中期，形成了软件工程的子领域—需求工程。进入20世纪90年代以来，需求工程成为研究的热点之一。从1993年起每两年举办一次需求工程国际研讨会，自1994年起每两年举办一次需求工程国际会议，在1996年Springer-Verlag发行了新的刊物— Requirements Engineering。
需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文件，并对用户不断变化的需求演进给予支持。
软件需求工程是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。
需求工程是一个不断地进行需求定义、文件记录、需求演进的过程，最终在验证的基础上冻结需求。20世纪80年代，Herb Krasner定义了需求工程的五阶段生命周期—需求定义和分析、需求决策、需求说明书形成、需求实现与验证、需求演进管理。后来，Matthias Jarke和Klaus Pohl提出了三阶段周期—获取、表示和验证的说法。
综合几种观点，可以把需求工程的活动划分为两大部分—需求开发和需求管理，如图6-2所示。
图6-2 需求工程的活动
●需求开发是从用户和市场获取需求并分析、形成需求说明书的过程，是一系列决定需求内容的活动。
●需求管理是一种获取、组织并记录系统需求的系统化方案，也是一个使客户与项目团队对不断变更的需求达成并保持一致的过程。
版权声明：51Testing软件测试网获得人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
