2.1 需求与需求分析

2.1.1 需求的定义

软件工程师所解决的问题通常很复杂，了解问题的本质是很困难的。从项目相关人员入手，能够获得较为全面的信息。项目相关人员涉及对项目有利益关系的人员，包括：

● 发现系统的潜在最终用户；

● 考虑系统打算支持的业务过程描述以及与这些过程相关的人员；

● 可能会受到系统引入的影响的人员；

● 使用系统的客户；

● 开发和维护系统的工程师和维护人员；

● 可能给系统添加需求的监管机构和认证机构等。

因此，项目相关人员可能是系统最终用户和机构管理人员、工程人员、业务专家、工会代表等。例如，Autoteller银行自动柜员机系统（ATM）的项目相关人员有：

● 当前银行客户；

● 其他银行代表；

● 硬件和软件维护工程师；

● 市场开发部；

● 银行管理者；

● 柜台职员；

● 数据库管理员；

● 信息安全管理员。

这些项目相关人员会对系统提出不同方面的要求，最终都会有可能成为系统的需求，那么到底什么是需求呢？一般来说，需求是对系统应提供的服务和所受到的约束的描述。需求来自于用户，同时也是经过了开发人员抽象之后的需求，因此，从两个方面阐述了系统所应该具备的内容，将需求分为用户需求和系统需求，用户需求表达了高层的概要需求，系统需求表达对系统应该提供哪些服务的详细描述。具体定义如下：

1．用户需求

用户根据自己的工作实际需要，采用自然语言、非形式化的图形或一些适合正在解决问题的表示法等，给出的关于系统需要提供哪些服务以及系统操作受到哪些约束的说明。用户是项目的相关人员，通常不会描述得很详细。

2．系统需求

系统需求是指详细地给出系统将要提供的服务以及系统所受到的约束的描述。这是详细的需求说明，可以表达成系统的抽象模型，在以后的章节中会给出详细的需求分析模型。如表2-1所示，某高校选课系统给出的用户需求和系统需求的描述不同。

在系统需求说明中，又包括两类需求，称为功能性需求和非功能性需求。具体定义如下：

（1）功能性需求。包括对系统提供的服务、如何对输入做出反应以及系统在特定条件下的行为描述。如文字处理软件能够提供文字编辑、保存、新建、插入其他对象、打印输出等功能，可以实现对文件的查找、浏览。功能性需求描述了系统应该做什么，系统预期提供的功能或服务，一般取决于开发的软件类型、软件未来的用户和开发的系统类型，因此，它详细地描述系统的功能、输入、输出和异常。

（2）非功能性需求。是指不直接与系统具体功能相关的一类需求，与系统的总体特性有关，如可靠性、反应时间和存储空间。对系统提供的服务或功能给出的约束，包括时间约束、开发过程的约束、标准等。许多非功能性需求关心的是系统整体特性而不是个别的系统特性，因此，非功能性需求比功能性需求对系统更为关键。如果一个功能性需求没有满足，则可能降低系统的能力；而如果一个非功能需求没有满足，则可能使整个系统无法使用。我们经常听说关于银行出错造成某个银行卡突然出现大笔金额，或存折上出现大额数目等，这些都是因为银行管理软件出现错误，结果造成银行系统某些部分无法运行。提供基本功能并不是系统能够正常运行的基本要求。然而，非功能需求来源于用户的限制，包括预算的限制、组织机构的特征、相关的管理政策、与系统其他设备、硬件的衔接，以及其他安全、隐私等方面的要求，都会造成系统非正常运行，降低系统的性能指标。一般将非功能性需求依照起源进行分类，如图2-1所示。

①产品需求。描述产品行为的需求，包括系统运行速度和内存消耗等性能需求；也包括反应系统可以接受的出错率等系统可靠性需求，以及系统可移植性和可用性方面的需求。如某信息查询软件产品需求在1s中的时间内给出相应的结果。这是效率需求的描述。很多软件产品对系统所占用的空间、运行环境都有相应的要求。

②机构需求。起源于客户所在的机构和开发者所在的机构中的政策和规定。包括机构采用的过程标准；实现系统的相应要求，如程序开发语言、系统运行环境、设计方法等；还有交付方面的要求，对产品及其文档交付的要求。一般软件产品都会有完成时间、产品所具有的标准等方面的要求。

③外部需求。指系统外部因素和开发过程。包括互操作需求，定义系统如何与其他机构中的系统实现互操作；法律需求，确保系统在法律许可的范围内工作；道德需求，保证系统能被用户和一般社会公众所接受。因此，特别是软件产品的知识产权问题，以及系统运行的安全性等问题尤为突出。

一般来说，非功能性需求需要量化，表2-2给出了用来指定非功能性系统特性的度量。基于这些度量可以检验系统是否满足了相应的需求。

功能性需求和非功能性需求理论上应该在需求文档中分开描述，但是，如果将非功能性需求与功能需求分开，它们之间的关系很难看出来，因此，通常的做法是将系统总体特性方面的需求单独列举出来，或有别于其他需求。另外，在需求方面中，目前还包含了领域需求，很多实际应用软件系统是处在某个特殊领域中，具有领域独特的需求要求，反映了领域的基本问题，可能是一个新的特有的功能需求、对已存在的功能需求的约束或者是需要实现的一个特别计算等。如很多特殊的领域，像银行、证券、电信等需要有其特殊的计算方式，数字表示的精度要求等；而石油、化工、医药等由于生产管理方式的特殊性，有自己独到的领域知识，更多地受限于政策、法规、标准等。

2.1.2 需求分析的任务

需求分析是软件工程中的一种活动，是系统设计的基础。软件需求分析阶段是把来自用户的信息加以分析提炼，抽象出功能和性能的描述。通过需求分析，使得软件工程师能够划分出软件的功能、性能，指出软件系统和其他系统之间的接口，并建立软件系统必须满足的约束。它要求分析员具有相应的业务知识，能够很好地理解用户需求和用户环境，并且有广泛的计算机知识，有一定的硬件、软件系统开发经验，有良好的沟通能力，对用户的需求具有概括和分析能力。因此，需求分析的主要任务是通过软件开发人员与用户的交流和讨论，准确地获取用户对系统的具体要求。为了满足用户的需求，回答系统必须“做什么”的问题，需求分析的任务还不是确定系统怎样完成它的工作，仅仅是确定系统要完成哪些工作，也就是对系统提出完整、准确、清晰、具体的要求。然后，在正确理解用户需求的前提下，软件开发人员还需要将这些需求准确地以文档的形式表达出来，作为设计的依据。需求分析阶段结束时，需要提交的主要文档是软件需求规格说明书。通俗地说，需求分析的任务就是准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么，用规范的形式准确地表达用户的需求。

具体而言，需求分析主要有两个任务。

第一是通过对问题及其环境的理解、分析和综合，建立分析模型。

分析人员通过对问题及其环境的理解、分析和综合，清除用户需求的模糊性、歧义性和不一致性，分析人员将自己对原始问题的理解与软件开发经验结合起来，对问题进行归纳和整理。在对问题进行需求描述时，一般包括了对目标系统的外部行为、性能、功能等方面的描述。形式化的语言用户难以理解，甚至一些计算机术语用户都难以理解，用文字表达很难清楚地展现系统的体系结构，表示系统的需求。而分析人员选定一些图形记号分别表示信息流、处理的功能和系统行为，并用这些符号构成分析模型方式，以一种简洁、准确、结构清晰的方式描述软件系统需求，用户比较容易看懂，很容易和用户交流，有利于需求分析的评审。

第二是在完全弄清用户对软件系统的确切要求的基础上，用“软件需求规格说明书”（Software Requirement Specification, SRS，以下简称需求说明书）把用户的需求表达出来。

作为设计的基础和验收的依据，需求说明书应该是精确而无二义的，这样才不致被人误解。

用户能看懂需求说明书，并能发现和指出其中的错误是保证软件系统质量的关键，所以需求说明书必须简明易懂，尽量不包含计算机技术上的概念和术语，使用户和软件人员都能接受它。总之，需求说明书应该既完整、一致、无二义，又要简明易懂并易于维护。需求说明书主要有以下三个作用。

（1）作为用户和软件人员之间的合同，为双方相互了解提供基础。用户通过需求规格说明书在分析阶段即可初步判定目标系统是否能够满足用户的期望。

（2）反映出问题的结构，可以作为软件人员进行设计和编写的基础。设计人员以需求规格说明书作为设计的基本出发点。

（3）作为验收的依据，即作为选取测试用例和进行形式验证的依据。根据需求规格说明书确立测试标准，并且各项需求都应该是可测试的。

因此，需求分析所要做的主要工作是深入描述软件的功能和性能，确定软件设计的限制和软件系统同其他系统之间的接口，定义软件的有效性需求。分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据与功能表示。在软件完成后，制定的软件需求规格说明书还要为评价软件质量提供依据。

2.1.3 需求分析的步骤

需求分析过程是对现有系统的问题分析与获取的过程，通过需求分析的步骤去获得准确的需求，并以文档方式加以描述和验证需求，如图2-2所示。

通过图2-2可以看出，需求分析阶段的工作，大致可分为如下几个步骤。

1．可行性研究

可行性研究的输入信息是系统的一个框架描述和系统将如何在机构中使用的说明信息，可行性研究的结果给出一份研究报告，主要阐述项目是否值得开发，并给出具体的意见和建议。一般来说，主要集中在几个焦点问题上，如系统是否符合机构的总体目标？系统是否可能在现有的技术条件、预算和时间限制内完成？系统能否与已存在的其他系统兼容？可行性研究包括信息评估、信息汇总和报告生成。可行性研究报告需要对系统是否要开发给出意见和建议，可能提出对系统功能范围的修正、对预算和时间安排的调整意见和建议。

2．需求获取

通过与用户、客户和其他与系统开发相关的人员交流，进行调查研究，来发现系统需求的过程。需求信息的获取可来源于阅读描述系统需求的用户文档；对相关软件、技术的市场调查；对管理部门、用户的访问咨询；对工作现场的实际考察等。

3．需求提炼：建立系统的逻辑模型

需求提炼的主要任务是建立分析模型。图形化的分析模型是说明软件需求极好的手段，常用的模型有数据流图、实体关系图等。对于获取的原始需求，软件开发人员需要根据掌握的专业知识，运用抽象的逻辑思维，找出需求间的内在联系和矛盾，去除需求中不合理和非本质的部分，确定软件系统的真正需求，通过现有的需求分析的方法及工具，对其进行清晰、准确的描述。

4．需求描述：编写需求规格说明书

需求阶段应提交的主要文档包括需求说明书、初步的用户手册和修正后的开发计划。

5．需求验证

为了保证软件开发的质量，对需求分析阶段的工作要按照严格的规范进行复审，从不同的技术角度对该阶段工作做出综合性的评价。通过评审可以发现具有二义性的或无法实现的需求，以及那些定义不够明确的需求。

因此，软件需求分析的过程就是依据软件的作用范围，进一步对目标的对象和环境做细致深入的调查，提出可能的各种解决方案，加以分析评价，配置相应的其他元素，建立一个目标系统的逻辑模型并写出软件需求说明书。

2.1.4 需求的内容与特征

1．需求的内容

在需求分析过程中通常需求描述都是关于系统如何与它所处的环境交互的过程，需求的内容一般包括以下各项。

（1）功能描述。功能需求描述主要对系统做什么、系统何时做什么、系统何时及如何修改或升级等方面的内容加以说明。

（2）性能描述。性能需求描述阐述软件开发的技术性能指标，例如：存储容量限制执行速度，相应时间吞吐量。

（3）环境需求。包括硬件和软件所需要的环境，硬件环境包括：机型、外设、接口、地点、分布、温度、湿度、磁场干扰等，软件环境包括：操作系统、网络、数据库等。

（4）界面需求。界面需求主要描述系统内部信息交换以及与外部系统之间的信息交换，如有来自其他系统的输入吗？有来自其他系统的输出吗？对数据格式有规定吗？

（5）用户或人的因素。用户类型决定了提供的系统说明和培训内容的不同，各种用户熟练程度、受何种训练能够使用户理解系统的基本操作，使用系统的难度、用户错误操作系统的可能性有多少等问题。

（6）文档需求。文档需求描述给出需要哪些文档，文档针对哪些读者等做进一步说明。

（7）数据需求。数据需求给出输入、输出数据的格式要求，以及发送数据的频率、数据的准确性和精度，还有数据流量、数据需保持的时间等信息。

（8）资源需求。资源需求描述软件运行时所需的数据、软件、内存空间等资源，以及软件开发、维护所需的人力、支撑的软件和开发设备等。

（9）安全保密。安全保密要求需对访问系统或系统信息加以控制吗？如何隔离用户之间的数据？程序如何与其他程序和操作系统隔离？以及系统备份等要求。

（10）软件成本消耗与开发进度。软件成本消耗与开发进度需求给出软件开发规定的时间表、软硬件投资有无限制等问题。

（11）质量保证。质量保证对系统的可靠性要求加以描述。系统必须监测和隔离错误吗？出错后，重启系统允许的时间？系统变化如何反映到设计中？维护是否包括对系统的改进？系统的可移植性问题等。

2．需求的特征

需求不仅描述了与系统之间的信息流向，系统对信息进行了转化的过程，而且描述了系统的约束条件。因此，通常针对需求的特征进行验证。

（1）完整性。每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能的所有必要信息。

（2）正确性。每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触，则是不正确的。只有用户代表，才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。没有用户参与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。”其实这完全是评审者凭空猜测。

（3）可行性。每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求，最好在获取（Elicitation）需求过程中始终有一位软件工程小组的组员与需求分析人员或市场人员在一起工作，由他负责检查技术可行性。

（4）必要性。每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。

（5）划分优先级。给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看做同样重要，那么项目管理者在开发或节省预算或调度中就会丧失控制自由度。

（6）无二义性。对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。

（7）可验证性。检查一下每项需求是否能通过设计测试用例或其他的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾、不可行或有二义性的需求也是不可验证的。