毕业设计说明书
需求分析是软件开发的基础。假定在该阶段发现一个错误，解决它需要用一个小时的时间，到设计、编程、测试和维护阶段解决，则要花费2.5、5、25甚至100倍的时间。
第三章 软件需求分析过程
3.1 什么是软件需求
从根本上讲，软件需求就是为了解决现实世界中的特定问题，软件必须展现的属性。
软件需求包括两部分：功能性需求和非功能性需求。虽然功能性需求是对软件系统的一项基本需求，但却并不是唯一的需求。除功能性需求外，软件质量属性的特性，称为系统的非功能性需求。这些特性包括：系统的易用性、执行速度、可靠性，处理异常情况的能力与方式等。在决定系统的成功或失败的因素中，满足非功能性需求往往比满足功能性需求更为重要。
软件需求的属性包括可验证性、优先级、唯一性和定量化。 （1）可验证性
可验证性是软件需求的基本属性。软件需求必须是可验证的，否则软件的评审和测试就没有相应的依据。
（2）优先性
软件需求具有优先级，应该能够在有限的资源（资金、人员、技术）情况下进行取舍。
（3）唯一性
软件需求应唯一地标识出来，以便在软件配置管理和整个软件生命周期中进行管理。
（4）定量化
软件需求应尽可能地表述清楚，没有二义性，进行适当的量化，应避免含糊、无法测试、无法验证的需求出现。软件质量的可靠性和用户界面的友好性等非功能性需求的量化尤为重要。例如，系统应支持2000个并发用户，系统回应时间应低于10秒，这就是需求的量化。
3.2 需求过程中的角色
- 6 - 6
毕业设计说明书
需求过程涉及各种角色的人员。需求人员应协调软件开发人员和各领域内的专家共同完成需求过程。软件的涉众（牵涉到的角色）随项目的不同而不同，但至少包括用户（操作人员）和客户。典型的需求过程中的角色如表3-2所示。 表3-2 需求过程中的角色 角色名称 描 述 用户 指直接操作软件的人员，他们通常具有不同的业务角色，具有不同的业务需求客户指软件开发的委托方或软件市场的目标客户 市场分析人员对于没有具体客户的通用软件，市场分析人员将提供市场需要，并对实际客户进行模拟 系统分析师 对于类似的项目，系统分析师将对以前系统进行评估，判断是否存在重用的可能 对于涉众的各种需求通常很难完全满足，系统分析师应根据预算、技术等条件进行取舍。
3.3 需求过程的迭代
软件需求分析是一个不断认识和逐步细化的过程。该过程将软件计划阶段所确定的软件范围（工作范围）逐步细化到可详细定义的程度，并分析出各种不同的软件元素，然后为这些元素找到可行的解决办法。需求过程要适应客户和项目的环境，并作为配置项纳入配置管理。关于配置管理的具体内容我们将在后面第8章中详细讲解。
当前的软件业面临着巨大竞争压力，要求软件企业有更低的构建成本和更短的开发周期。有些项目受环境的影响很大，有些项目是对原有项目的升级，有些项目客户要求在指定的架构下完成。在项目初期，客户不能完全确定需要什么，对计算机的能力和限制不甚了解，所以需求过程很难是一步到位的过程。随着项目的深入，需求将随时间变化而发生变化。
因此，需求过程是一个迭代的过程，每次迭代都提供更高质量和更详细的软件需求。这种迭代会给项目带来一定的风险，上一次迭代的设计实现可能会因为
- 7 - 7
毕业设计说明书
需求不足而被推翻。但是，系统分析师应根据项目计划，在给定的资源条件下得到尽可能高质量的需求。
在很多情况下，对需求的理解会随着设计和实现的过程而不断深入，这也会导致在软件生命周期的后期重新修订软件需求。原因可能来自于错误的分析、客户环境和业务流程的改变、市场趋势的变化等。无论什么原因，系统分析师应认识到需求变化的必然性，并采取相应的措施减少需求变更对软件系统的影响。进行变更的需求必须经过仔细的需求评审、需求跟踪和比较分析后才能实施。
3.4 需求来源
理解问题域的第一步是提取需求，即确定需求的来源，识别软件的涉众，确立开发团队与客户间的关系。提取需求时，要求用户与开发人员之间保持良好的沟通。
软件的需求来源很多，我们要尽可能多地识别显式的来源和潜在的来源，并评估这些来源对系统的影响。典型的来源包括以下5种。
（1）系统目的
系统目的是指软件的整体目的或高层的目标。这是进行软件开发的动机，但它们通常表达比较模糊。系统分析师需要仔细地评估这些目标的价值和成本，对系统的整体目标进行可行性研究。
（2）行业知识
系统分析师需要获取业务领域内的相关知识。因为涉众对于通用的行业知识会一概而过，一些行业惯例需要系统分析师根据环境进行推断。当需求发生矛盾时，系统分析师可以利用行业知识对各种需求进行权衡。
（3）软件涉众
应充分考虑不同软件涉众的需求，如果只强调某一角色的需求，忽略其他角色的需求，往往将导致软件系统的失败。系统分析师应从不同涉众的角度去识别、表述他们的需求。用户的文化差异、客户的组织结构，常常会是系统难以正常实施的原因。
（4）运行环境
软件的运行环境包括地域限制、实时性要求和网络性能等。系统的可行性和软件架构都依赖于这些环境需求。
- 8 - 8
毕业设计说明书
（5）组织环境
软件作为一个组织的业务流程支持工具，受到组织结构、企业文化和内部政策的影响。软件的需求也与组织结构、企业文化和内部政策有关。
3.5 需求获取方法
常用的需求获取方法有： （1）实地参加
通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求，但比较耗费时间。
（2）开调查会
通过与用户座谈来了解业务活动情况及用户需求。座谈时，参加者之间可以相互启发。
（3）请专人介绍 （4）面谈
对某些调查中的问题，可以找专人询问。 （5）设计调查表请用户填写
如果调查表设计得合理，这种方法是很有效的，也很易于被用户接受。 （6）查阅记录
查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。 通过调查了解获取了用户需求后，还需要进一步分析和表达用户的需求。
3.6 软件需求表达
如何有效地表达软件需求？我们这里建议使用用例建模技术。用例建模技术是十多年来最重要的需求分析技术，在保障全球各类软件的成功开发中发挥了极其重要的作用。实践证明，用例技术是迄今为止最为深刻、准确和有效的系统功能需求描述方法。功能需求是指系统输入到输出的映射，以及它们的不同组合，任何功能必然要通过外部环境与系统之间的交互才能完成，因此，我们可以在内容和形式上把用例和系统的功能需求等同起来。
用例建模技术不同于结构化功能分解的特点有：
- 9 - 9
毕业设计说明书
（1）显式地表达用户的任务目标层次，突出系统行为与用户利益间的关系。 （2）通过描述执行实例情节（交互行为序列、正常/非正常事件流），能够完整地反映软件系统用以支持特定功能的行为。
（3）以契约（前/后置条件等）的形式突出了用户和系统之间常常被忽略的背后关系。
（4）部署约束等非功能需求与系统行为直接绑定，能够更准确地表达此类需求。
3.7 需求评审
3.7.1 需求评审概述
需求评审是一项精益求精的技术，它主要由非软件开发人员来进行。通过评审发现二义性的或不确定的需求，还有那些实际上是设计规格说明的所谓的“需求”，这些“需求”是不能作为设计基础和依据的。需求评审也为风险承担者们提供了在特定问题上达成共识的方法。
需求评审可以分为非正式评审和正式评审。
— 非正式评审：可以根据个人爱好的方式进行评审，包括在任何场合的交流、征求意见。它是非系统化的、不彻底的，或者在实施过程中具有不一致性。非正式评审不需要记录备案，没有人对提出的意见负责。
— 正式评审：正式技术评审的最好类型叫做审查，它遵循预先定义好的一系列步骤、过程及规定的方法和要求进行，评审内容需要记录在案，正式评审小组的成员对评审的质量负责。
3.7.2 需求评审过程
（1）确定参与者
① 审查参与者必须代表3个方面的观点：
— 需求提出人员和产品代表者的观点； — 需求分析、开发、管理人员的观点； — 软件设计、开发、测试、管理人员的观点。
② 审查组中的审查人员应限制在7个人左右或者更少。 ③ 审查的工作基础是软件需求规格说明书。
- 10 - 10