2.2 软件需求分析的目标和过程

在规定软件需求时，软件人员与用户同样起着至关重要的作用。用户必须对软件功能和性能提出初步要求，并澄清一些模糊概念。而软件人员则要认真了解用户的要求，细致地进行调查分析，把用户“需要”什么软件认识清楚，最终转换成一个完全、准确、清楚的软件逻辑模型，并写出软件的需求规格说明，准确地表达用户的需求。

2.2.1 软件需求

IEEE软件工程标准词汇表（1997年）中将需求定义为：①用户解决问题或达到目标所需的条件或能力；②系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力。

其中，①是从用户的角度定义的，②是从软件系统的角度定义的。虽然目前对什么是软件需求的定义有不同的看法，但我们认为软件需求是指软件系统必须满足的所有功能、性质和限制。需求分析需要实现的是将用户对软件的一系列要求、想法转变为软件开发人员所需要的有关软件的技术规格说明，它涉及面向用户的用户需求和面向开发者的系统需求两个方面的工作内容。

软件需求包括3个不同的层次：业务需求、用户需求和系统需求（包括功能需求、非功能需求和数据需求）。

1.业务需求

业务需求反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。

2.用户需求

用户需求是关于软件的一系列想法的集中体现，涉及软件的功能、操作方式、界面风格、用户机构的业务范围、工作流程、用户对软件应用的展望等。因此，用户需求也就是关于软件的外界特征的规格表述。用户需求具有以下特点：

（1）用户需求直接来源于用户。需求可以由用户主动提出，也可以通过与用户进行沟通、交流或者通过问卷调查等方式获得。由于用户对计算机系统认识上的不足，分析人员有义务帮助用户挖掘需求，如可以用启发的方式激发用户的需求想法。

（2）用户需求需要以文档的形式提供给用户审查，因此，需要使用流畅的自然语言和简洁清晰的直观图表来表述，以方便用户的理解和确认。

（3）可以把用户需求理解为用户对软件的合理请求。这意味着，必须全面理解用户的各项要求，但又不能全盘接受其要求。因为并非所有用户提出的全部要求都是合理的，对其中模糊的要求还需要澄清，然后才能决定是否可以采纳。对于那些无法实现的要求应向用户充分解释，以求得到理解。

（4）用户需求主要是为用户方管理层撰写的，但是用户方的技术代表、软件系统今后的操作者及开发方的高层技术人员，也有必要认真阅读用户需求文档。

3.系统需求

系统需求是比用户需求更具有技术特性的需求陈述，它是提供给开发方或用户方技术人员阅读的，并将作为软件开发人员设计系统的起点与基本依据。系统需求需要对系统的功能、性能、数据等方面进行规格定义。系统需求往往要求用更加严格的形式化语言进行表述，以保证系统需求表述具有一致性。系统需求是综合的、多方面的，下面重点介绍功能、非功能、数据3个方面的需求特征。

（1）功能需求。功能需求是软件系统的最基本的需求表述，包括对系统应该提供的服务，如何对输入作出反应，以及系统在特定条件下的行为描述。在某些情况下，功能需求还必须明确系统不应该做什么，这取决于开发的软件类型、软件未来的用户及开发的系统类型。所以，功能性的系统需求，需要详细地描述系统功能特征、输入和输出接口、异常处理方法等。

软件系统的功能需求可以有许多不同的描述方式。软件工程中的许多问题都源自对需求描述的不严格，自然语言对需求分析最大的弊端就是它的二义性，所以我们不得不对需求分析中采用的语言做某些限制。例如，尽量采用主语+动词的表达方式。

理论上，系统的功能需求描述应该具有全面性和一致性。全面性意味着对用户所需的所有功能都应该给出描述；一致性意味着需求描述不能前后矛盾。在实际过程中，对于大型复杂的系统而言，要完全满足这两个方面的要求几乎是不可能的，因此，需要由质量保证小组进行评审。

（2）非功能需求。非功能需求包括对系统提出的性能需求、可靠性和可用性需求、系统安全，以及系统对开发过程、时间、资源等方面的约束、标准等。性能需求指系统必须满足的定时约束或容量约束，一般包括速度（响应时间）、信息量速率（吞吐量、处理时间）、存储容量等方面的需求。例如，“汇总统计分析必须在一分钟之内生成”就是一项性能需求。可靠性需求定量地指定系统的可靠程度，如“系统应支持7×24小时提供服务的业务需要”。可用性与可靠性密切相关，它量化了用户可以使用系统的程度。例如，在任何情况下，主机或备份系统应该至少有一个可用，而且在一年内，该系统的不可用时间不能超过总时间的1%。

非功能需求一般关心系统的整体特性，而不是个别的系统特性。因此，对于系统来说非功能需求比功能需求更关键。一个功能需求没有满足，可能降低系统的能力；而一个非功能需求没有满足，则可能使整个系统无法使用。

非功能需求不仅与软件系统本身有关，还与系统的开发过程有关。例如，质量标准的描述、使用开发工具的描述，以及必须遵守的原则等。非功能需求还源于一些用户的限制，包括预算约束、机构政策、硬件平台、隐私权的保护等。

（3）数据需求。大多数软件系统本质上都是信息处理系统。系统处理的信息和系统产生的信息在很大程度上决定了系统的面貌，对软件设计具有深远的影响。因此，必须分析系统的数据需求，这也是软件需求分析的一个任务。数据需求包括输入数据、输出数据、加工中的数据、保存在存储设备上的数据等。在结构化方法中，可以使用数据字典对数据进行全面准确的定义，如数据的名称、组成元素、出现的位置、出现的频率、存储的周期等。当所要开发的软件系统涉及对数据库的操作时，可以使用数据关系模型图，对数据库中的数据实体、数据实体之间的关系进行描述。

2.2.2 软件需求分析的目标

软件需求分析的目标是准确理解用户的要求，进行细致的调查分析，将用户的非形式要求转化为完整的需求定义，再将需求定义转换为相应形式的规格说明。

软件需求分析工作是软件生存周期中重要的一步，也是决定性的一步。只有通过软件需求分析，才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础。软件需求分析工作也是一个不断认识和逐步细化的过程。该过程将软件计划阶段所确定的软件范围逐步细化到可详细定义的程度，并分析出各种不同的软件元素，然后为这些元素找到可行的解决方法。

正如任何一项工作在着手以前，首先必须明确目标一样，软件在进入开发阶段时，也需要弄清楚，要开发的软件应该具有哪些功能，应达到什么性能。明确了需求，就得到了软件设计的依据。软件开发的实践表明，做好需求分析工作并不是一件轻而易举的事情。软件危机发生的原因之一就是忽视了需求分析这一重要的步骤，往往是软件开发人员和用户未能全面准确地理解需求，或是未能恰当地表达这些需求，以致把需求分析阶段的问题遗留到开发工作的后续阶段，最终酿成不良后果。

需求分析阶段研究的对象是软件项目的用户要求。一方面，必须全面理解用户的各项要求，但又不能全盘接受所有的要求，因为并非所有的用户要求都是合理的，对其中模糊的要求还需要澄清，然后才能决定是否可以采纳。对于那些无法实现的要求，应向用户充分解释，以求得理解。另一方面，要准确地表达被接受的用户要求。只有经过确切描述的软件需求才能成为软件设计的基础。

制定软件的需求规格说明不只是软件开发人员的事，用户也起着至关重要的作用。用户必须对软件功能和性能提出初步要求，并澄清一些模糊概念。而软件分析人员则要认真了解用户的要求，细致地进行调查分析，把用户“做什么”的要求最终转换成一个完全、精细的软件逻辑模型，并写出软件的需求规格说明，准确地表达用户的要求。

通常软件开发项目是要实现目标系统的物理模型。作为目标系统的参考，需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统“做什么”的问题。其实现步骤如图2.1所示。

1.获得当前系统的物理模型

所谓当前系统可能是需要改进的某个已在计算机上运行的数据处理系统，也可能是一个人工的数据处理过程。在这一步首先分析现实世界，理解当前系统是如何运行的，了解当前系统的组织机构、输入输出、资源利用情况和日常数据处理过程，并用一个具体模型来反映自己对当前系统的理解。这一模型应客观地反映现实世界的实际情况。

2.抽象出当前系统的逻辑模型

在理解当前系统“怎么做”的基础上，抽取其“做什么”的本质，从当前系统的物理模型抽象出当前系统的逻辑模型。

在物理模型中有许多物理因素，随着分析工作的深入，有些非本质的物理因素就会成为不必要的负担，因而需要对物理模型进行分析，区分出本质的和非本质的因素，去掉那些非本质的因素即可获得反映系统本质的逻辑模型。

3.建立目标系统的逻辑模型

分析目标系统与当前系统逻辑上的差别，明确目标系统到底要“做什么”，从而从当前系统的逻辑模型导出目标系统的逻辑模型。

具体做法：①确定变更范围，即确定目标系统与当前系统在逻辑上的差别；②将变化的部分看成新的处理步骤，对数据流程图进行调整；③由外向里对变更部分进行分析，凭经验推断其结构，获得目标系统的逻辑模型。

4.补充目标系统的逻辑模型

补充内容包括：①说明目标系统的用户界面。根据目标系统所处的应用环境及其与外界环境的相互关系，研究所有可能与它发生联系和作用的部分，从而决定人机界面。②说明至今尚未详细考虑的细节。这些细节包括系统的启动和结束、出错处理、系统的输入输出和系统性能方面的需求。③其他。例如，系统的其他必须满足的性能和限制等。

2.2.3 需求分析的过程

需求分析阶段的工作，可以分成问题识别、分析与综合、编制需求文档、需求分析评审4个过程。

1.问题识别

首先系统分析人员要研究系统的可行性分析报告（如果有的话）和软件项目实施计划，主要从系统的角度来理解软件并评审用于产生计划估算的软件范围是否恰当；确定对目标系统的综合要求，即软件的需求；并提出这些需求的实现条件及需求应达到的标准，解决要求被开发软件做什么、做到什么程度的问题。

这些要求包括功能要求、性能要求、环境要求、可靠性要求、安全保密要求、用户界面要求、资源使用要求、软件成本消耗与开发进度要求，并预先估计以后系统可能达到的目标。此外，还需要注意其他非功能需求，如针对采用某种开发模式，确定质量控制标准、里程碑和评审、验收标准、各种质量要求的优先级等，以及可维护性方面的要求。

另外，需要建立分析所需要的通信途径，以保证能顺利地对问题进行分析。分析所需的通信途径，如图2.2所示。

2.分析与综合

分析人员对获取的有关软件的各项需求，进行如下工作：

（1）各项需求的一致性分析检查。

（2）从数据流和数据结构出发，逐步细化所有软件功能，划分出各种子功能。

（3）对数据域进行分解，并分配到子功能上，以确定系统的构成和各主要成分。

（4）找出系统各成分之间的联系、接口特性和设计上的限制。

（5）判断是否存在因片面性或短期行为而导致的不合理的用户需求，是否有用户尚未提出的真正有价值的潜在需求，剔除不合理的部分，增加其需要的部分。

（6）综合成系统的解决方案，给出目标系统的详细逻辑模型。

在这个步骤中，分析和综合工作会反复进行。在对现行问题和期望的信息（输入和输出）进行分析的基础上，分析人员开始综合出一个或几个解决方案，然后检查它的工作是否符合软件计划中规定的范围等，再进行修改。总之，对问题进行分析和综合的过程将一直持续到分析人员与用户双方都感到有把握正确地制定该软件的规格说明为止。

3.编制需求文档

已经确定下来的需求应当得到清晰准确的描述，需求文档包括以下几项内容：

（1）软件需求说明书：把分析人员和用户双方共同的理解和分析结果用规范的方式描述出来，作为今后各项工作的基础。

（2）初步的用户手册：着重反映目标软件的用户功能界面和用户使用的具体要求。用户手册能强制分析人员从用户使用的观点来思考问题。

（3）编写确认测试计划：作为今后确认测试的依据。

（4）修改和完善软件开发计划：在需求分析阶段软件开发方对目标系统有了更进一步的了解，因此能够更准确地估算开发成本、进度和资源需求，需要对软件开发计划做适当的修改。

可以把描述需求的文档称为软件需求规格说明书。软件需求规格说明书（Software Requirement Specification，SRS）是需求工程最终产生的结果，必须用一种统一的方式将它们编写成可视文档，包含软件的功能需求和非功能需求。需求规格说明书是项目相关人员对要开发的软件系统达成的共识，是进行系统设计、实现、测试和验收的基本依据，也是整个软件开发过程中最重要的文件。需求规格说明书要求满足完整性、一致性、可修改性、可跟踪性等要求。同时，为了确切表达用户对软件的输入输出要求，还需要制定数据要求说明书。

4.需求分析评审

作为需求分析阶段工作的复查手段，应该对功能的正确性、文档的一致性、完备性、准确性和清晰性及其他需求给予评价。

为保证软件需求定义的质量，评审应有指定人员负责，并按规程严格进行。评审结束应有评审负责人的结论意见及签字。除分析人员之外，用户/需求者，开发部门的管理者，软件设计、实现、测试等人员都应当参加评审工作。

2.2.4 需求获取

需求获取是需求分析的主体。对待开发的软件系统，需求获取是一个确定和理解不同用户需求和限制的过程。业务需求决定用户需求，它描述了用户需要利用系统完成的任务。

获取用户需求的主要方法是调查研究。

1.了解系统的需求

软件开发常常是系统开发的一部分。仔细分析研究系统的需求规格说明，对软件的需求获取是很有必要的。

2.市场调查

了解市场对待开发软件有什么样的要求；了解市场上有无与待开发软件类似的系统，如果有，在功能上、性能上、价格上情况如何。

3.访问用户和用户领域的专家

把从用户那里得到的信息作为重要的原始资料进行分析；访问用户领域的专家所得到的信息将有助于对用户需求的理解。

4.考察现场

了解用户实际的操作环境、操作过程和操作要求。对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。

在做调查研究时，可以采取如下调查方式：

（1）制定调查提纲，向不同层次的用户进行问卷调查。

（2）按用户的不同层次，分别召开调查会，了解用户对开发系统的想法和建议。

（3）向用户领域专家或关键岗位上的工作人员进行个别咨询。

（4）实地考察，跟踪现场业务流程。

（5）查阅与待开发系统有关的资料。

（6）使用各种调查工具，如数据流程图、任务分解图、程序网络图等。

为了能够有效地获取和厘清用户需求，应当打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，协同工作。

需求获取技术包括以下两个方面的工作：

（1）建立用户要求获取方法的框架。

（2）支持和监控需求获取过程的机制。

2.2.5 软件需求分析的原则

近年来软件开发人员已提出了许多软件分析与说明的方法。虽然各种分析方法都有其独特的描述方法，但总的看来，所有分析方法还是有它们共同适用的基本原则。

1.需要能够表达和理解问题的信息域和功能域

所有软件定义与开发工作最终是为了解决好数据处理问题，就是将一种形式的数据转换成另一种形式的数据。其转换过程必定经历输入、加工数据和产生结果数据等步骤。

对于计算机程序处理的数据，其信息域应包括信息流、信息内容和信息结构。

信息流即数据和控制通过一个系统时的变化方式，如图2.3所示。输入对象首先转换成中间数据/控制，然后转换成输出对象。在此期间可以从已有的存储（如磁盘文件或内存缓冲区）中引入追加数据/控制。对数据进行转换是程序中应有的功能或子功能，两个功能之间中间数据/控制的传递可确定功能间的接口。

信息内容即单个数据或控制对象，它们构成了某个更大的由软件变换生成信息的集合。例如，学生名册包含班级、人数、学号、姓名、性别、各科成绩等，学生名册的内容由它所包含的项定义。为了理解对学生名册的处理，必须理解它的数据内容。类似地，控制对系统状态的内容可以由一个位串定义，每位表示一个单独的信息项，它会指明某个特殊设备是在线还是离线。

信息结构即各种数据和控制项的内部组织。在结构中数据项与其他哪些数据项相关？所有数据是在一个信息结构中，还是在几个信息结构中？一个结构中的数据与其他结构中的数据如何联系？这些问题都由信息结构的分析来解决。

2.以层次化的方式对问题进行分解和不断细化

通常将软件要处理的问题作为一个整体来看，显得太大、太复杂，很难理解，因此需要把问题以某种方式分解为几个较易理解的部分，并确定各部分间的接口，从而实现整体功能。在需求分析阶段，软件的功能域和信息域都能进行进一步分解。这种分解可以是同一层次的，称为横向分解；也可以是多层次的，称为纵向分解，如图2.4所示。

如果把一个功能分解成几个子功能，并确定这些子功能与父功能的接口，就属于横向分解。但如果继续分解，又把某些子功能分解为小的子功能，某个小的子功能又分解为更小的子功能，这就属于纵向分解了。

3.要给出系统的逻辑视图和物理视图

给出系统的逻辑视图（逻辑表示）和物理视图（物理表示），这对系统满足处理需求所提出的逻辑限制条件和系统中其他成分提出的物理限制条件来说是必不可少的。

软件需求的逻辑视图给出的是软件要达到的功能和要处理的数据之间的关系，而不是实现的细节。例如，一个商场的销售处理系统要从顾客那里获取订单，系统读取订单的功能并不关心订单数据本身的物理形式和读入设备，也就是说无须关心输入的机制，只是读取顾客的订单而已。类似地，系统中检查库存的功能只关心库存文件的信息结构，而不关心它在计算机中的具体存储方式。

软件需求的逻辑描述是软件设计的基础。软件需求的物理视图给出的是处理功能和数据结构的实际表现形式，这往往是由设备本身决定的。例如，一些软件靠终端键盘输入数据，另一些数据处理软件靠 A/D 转换设备提供数据。软件分析人员必须弄清系统对软件的限制，并考虑功能和数据结构的物理表示。分析人员在需求分析过程中，并不需要考虑“如何实现”，仅需要考虑“做什么”。

2.2.6 需求分析的方法

需求分析方法由对软件的信息域和功能域的系统分析过程及其表示方法组成。它提供了分解问题的方法，定义了表示系统逻辑视图和物理视图的方式。大多数的需求分析方法是由数据驱动的，就是说，这些方法提供了一种表示信息域的机制，分析人员根据这种表示，确定软件功能及其他特性，最终建立一个待开发软件的抽象模型，即目标系统的逻辑模型。信息域具有数据流、数据内容和数据结构3种属性。通常，一种需求分析方法总要利用其中的一种或几种属性。

目前存在许多需求分析方法，每种分析方法都引入了不同的记号和分析策略，但是它们仍具有以下共性。

1.支持信息域分析的机制

所有的方法都直接或间接地涉及数据流、数据内容或数据结构等信息域属性。

在多数情况下，数据流特征是用将输入转换成输出的变换（功能）过程来描述的，数据内容可以用数据词典机制明确表示，或者通过描述数据的层次结构隐含地表示。

2.功能表示的方法

功能一般用数据变换或加工来表示，每项功能可用规定的记号（圆圈或方框）标识。功能的说明可以用自然语言文本来表达，也可以用形式化的规格说明语言来表达，还可以用上述两种方式的混合方式——结构化语言来描述。

3.接口

接口的说明通常是数据表示和功能表示的直接产物，某个具体功能的流进和流出数据流应是其他相关功能的流出或流入数据流。因此，通过数据流分析可以确定功能间的接口。

4.问题分解的机制及对抽象的支持

问题分解和抽象主要依靠分析人员在不同抽象层次上表示数据域和功能域，以逐层细化的手段建立分层结构来实现。例如，不论使用何种分析方法，分析人员都能表示诸如“计算员工9月份工资”之类的功能，可以在这个抽象层次上操纵这个功能。另外，所有的分析方法都提供一种逐层分解的机制，把“计算员工9月份工资”功能划分成一些子功能，如计算房租、计算电费、计算水费、计算工会费、计算有线电视费、计算养老保险费，等等。其中，每项子功能还可以利用功能说明表示法在更低的一级抽象层次上表示。

5.逻辑视图和物理视图

大多数方法允许分析人员在着手问题的逻辑解决方案之前先分析物理视图。通常，同一种表示法既可用来表示逻辑视图，也可用来表示物理视图。

6.系统抽象模型

为了能够比较精确地定义软件需求，可以建立待开发软件的一个抽象模型，用基于抽象模型的术语来描述软件系统的功能和性能，形成软件需求规格说明。这种抽象的模型是从外部现实世界的问题领域抽象而来的，是在高级层次上描述和定义系统的服务。

对于比较简单的问题，不必建立抽象系统模型。或者说，系统模型已经在分析人员头脑中形成，直接由分析人员写成规格说明。但对于比较复杂的问题，问题领域中各种关系比较复杂，仅有在头脑中想象的模型是不够的，必须建立适当的比较形式化的抽象系统模型，才能准确而全面地反映问题领域中各种复杂的要求。

不同类型的问题有不同的需要解决的中心问题，因而要建立不同类型的系统模型。对于数学软件，设计的中心问题是算法，软件人员的主要力量要花在对数学模型算法的考虑上。对于数据通信软件，设计的中心问题是数据传送和过程控制，实现算法简单，采用数据流模型比较合适。对于涉及大量数据的数据处理软件，设计的中心问题是数据处理，包括数据的采集、传送、存储、变换、输出等，一旦数据结构明确，与它相关的算法就很简单了，因此可以采用实体—关系模型。如果系统要求有数据库支持（通过数据库获取和存放信息），还需要考虑数据在数据库中的组织方式和存取方法，建立数据库模型。因此，在分析过程中，数据模型是首先要集中精力考虑的问题。

系统模型的建立是对现实世界中存在的有关实体和活动的抽象和细化，其建立过程包括观察分析、模型表示和模型检查3个阶段，如图2.5所示。

首先，分析人员和用户合作，从各方面观察现实世界中的有关实体和活动，建立理解的共同基准，分清哪些概念与系统相关，必须纳入系统模型，哪些是系统模型不必关心的。分析人员和用户在共同理解的基础上，建立系统模型，包括系统提供的各种系统服务，模型表示的细节应有系统输入、系统输出、系统数据处理、系统控制等。

系统模型建立起来以后，还要进行检查。除静态检查之外，系统描述可以部分地模拟执行，将执行情况与对外部现实世界系统观察得到的系统跟踪信息进行对照，检查模型是否符合要求。