软件需求分析和软件需求规格.pdf

第3章
软件需求分析和软件需求规格

IEEE把软件需求定义为：
（1）用户为了解决某一问题或者达到某一目标而需要的功能和条件；
（2）这些条件和功能要求必须要被系统所满足，同时要满足相关的合同
契约、标准、规范，或者其他一些正式强制性文件。需要指出的是，所需处
理的软件需求是动态的，也就是系统的性能是不断发展的。
正如我们所看到的，所有的开发模型都要求有明确的需求。若使用敏捷
技术就需要高层需求说明书，详细需求通过与客户反复交换意见得到，并且
直接反映在软件中。另一方面是需求描述要精准，需求活动的目的就是要得
到软件需求规格说明书SRS（softwarerequirementspecification），它描述了
软件需要做什么，而不描述怎么做。
这一章中要讨论：
SRS在工程中的作用，以及一个好的SRS会带来的价值。
在产生所需要的SRS的过程中的一些不同的活动。
SRS文档要求的特性，结构以及它的关键部分。
用例分析方法和功能需求的指定以及怎样开发用例。
其他一些需求分析的方法，如数据流图（dataflowdiagram）分析法。
怎样验证需求。
3.1好软件需求规格的意义

多数软件系统起源于某些客户的需要，软件系统本身由某些开发者生
产，最终完成的系统由用户使用。然而，在一个新的系统中有我们感兴趣的
三个主要部分，它们是：客户、开发者和用户，那些客户所要求的以及用户
·28·软件工程导论

关心的需求必须要与开发者交换意见。问题是客户往往不懂软件和软件的开发过程，同
时开发者也往往不理解客户的问题和应用领域。这就造成在项目的开发过程中，各方交
流的空隙。SRS最基本的目的就是要填补这个交流空隙，开发出一个拥有共同视图的软
件。所以一个优秀的SRS的主要优点是：
SRS使得客户与开发者之间在软件究竟要做些什么上达成一致。
客户与开发者会频繁的把这些一致做成具有法律效力的契约，所以通过SRS，客户
清楚地描述它期望从开发者那得到什么，开发者也清楚地理解构造的该软件将具备什么
功能。一个相关但重要的优点是：
SRS对最终产品的验证提供一个参考。
也就是说，SRS帮助客户确定一个软件是否满足需求，没有合适的SRS，客户就没
有办法去决定软件是否按照所要求的那样去做，同时开发者也没有办法向客户表明那些
需求已经全都满足。
就以上所言已有足够的理由使客户与开发者需严肃处理这个需求说明，但是对一个
优秀的SRS还有更加实际的原因。
研究表明需求阶段存在着许多错误，并且SRS中的错误在最后的软件实现中肯定将
是个错误。显然，若我们想要得到一个高质量的最终产品，而且几乎没有错误，那就必
须从做高质量的SRS开始。换句话说，可以归纳为：
高质量的SRS是高质量软件的前提。
高质量的SRS可以减少工程费用，我们知道SRS可能存在错误，同样也知道随着
工程的进展，弥补一个错误所需的花费是呈指数增长的。所以，通过提高SRS的质量可
以为将来节省一大笔检测开销。或者说：
高质量的SRS可以减少开发费用。
3.2需求过程

需求分析过程就是做需求分析时的一系列活动的顺序，最终以形成高质量的SRS文
档为终点。典型的需求分析过程包括三个基本任务：问题或需求分析、需求说明以及需
求验证。
问题分析通常由一个高层的“问题陈述”开始，在问题分析期，为问题域和环境建
模，这对理解系统的行为、约束、以及输入输出等是很有效的，这项活动的基本目标就
是彻底地弄懂所开发的软件究竟要提供些什么。在分析过程中，分析者往往会与客户和
终端用户召开一系列的会议。在早期的会议中，客户和终端用户会向分析者解释他们的
工作和工作环境，还有他们的一些期望。在这个过程中都会提供任何有关描述工作和组
织的文档，在这些早期会议中，分析者主要是作为听众，掌握他们所提供的信息。一旦
第3章软件需求分析和软件需求规格·29·

分析者对所要开发的系统了解到一定程度时，他会在接下来的几次会议上澄清那些他所
不懂或不清楚的部分，也可能会把这些信息文档化或建成模型，他也有可能进行头脑风
暴或者想象一下这个系统将要做什么。在最后的几次会议上，分析者会向客户解释对系
统要做什么的理解，同时也会利用这几次会核实他对系统的理解是否和客户的目标一致。
由问题分析中得来的信息会形成一个最基本的需求说明书，在这份说明书中，主要
是清楚地记载需求。在这个活动中事实的陈述，说明语言和工具等都会确定下来。同时
把烦琐的信息和知识进行合理的整理并除去冗余信息，这也是这个阶段的重要目标。
需求验证把重点放在保证那些在SRS中所说明的一定是软件所需要的，同时保证产
生高质量的SRS。需求分析过程在对SRS验证后就结束了，本章后面会有更详细的介绍。
必须指出的是，在需求分析过程中，这三个活动不
会是线性的