一.需求分析的概念和原则

一.需求分析的概念和原则

3.1 需求分析的概念和原则

需求分析是发现、求精、建模和规约的过程。这一过程包括：详细精化最初由系统分

析员建立并在软件项目计划中确定的软件范围，创建所需数据流、控制流以及操作行为的

模型，在此基础上选择的解决方案。

在可行性研究之后，我们对值得开发的软件进行需求分析。

3.1.1 需求分析

需求分析是一种软件工程活动，使得系统分析员能够刻划出软件的功能和性能、指明

软件和其他系统元素的接口、并建立软件必须满足的约束。需求分析是软件设计师进行软

件分解的基础，需求分析建造了软件处理的数据模型、功能模型和行为模型。需求分析为

软件设计师提供了可被翻译成数据、体系结构、界面和过程设计的模型，最后，需求规约

为软件设计师和客户提供了软件建造完后，进行质量评估的依据。

1.软件需求的概念和分类

在我们分析需求之前，先要了解需求的类别，在获取需求时，按类别来处理就不容易

遗漏。对需求有很多种不同的分类方法，其中的一种分类方法告诉我们需求应该包括：

第一是功能需求，这方面的需求指定系统必须提供的服务，通过需求分析应该划分出

系统必须完成的所有功能；第二是性能需求，性能需求指定系统必须满足的定时约束或

容量约束，通常包括速度（响应时间）、信息量速率、主存容量、磁盘容量、安全性等方

面的需求；第三是可靠性和可用性需求，可靠性和可用性需求即需求定量地指定系统的

可靠性与可用性；第四是出错处理需求，这类需求说明系统对环境错误应该怎样响应，

例如，如果一个系统接收到从另一个系统发来的违反协议格式的消息，该系统应该做什么？第五是接口需求，接口需求描述应用系统与其环境通信的格式，常见的接口需求有用户接

口需求、硬件接口需求、软件接口需求和通信接口需求；第六是约束，约束描述了应用

系统应遵守的限制条件，在需求分析阶段提出这类需求，并不是要取代设计（或实现）过程，这只是反映了用户或环境强加给项目的限制条件，常见的约束有：精度约束、工具和

语言约束、设计约束、应该使用的标准、应该使用的硬件平台等；第七是逆向需求，逆

向需求说明了软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄

清真实需求且可消除发生误解的那些逆向需求；第八是将来可能提出的要求，应该明确

地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求，这样

做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时

能比较容易地进行这种扩充和修改。

2.需求分析的任务

需求分析的任务是借助于当前系统的物理模型（待开发系统的系统元素）导出目标系

统的逻辑模型（只描述系统要完成的功能和要处理的数据），解决目标系统“做什么”的

问题，所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系

统元素的接口细节，定义软件的其他有效性需求，通过逐步细化对软件的要求，描述软件

要处理的数据，并给软件开发提供一种可以转化为数据设计、结构设计和过程设计的数据

与功能表示。必须全面理解用户的各项要求，但这些要求不能全盘接受，只能接受合理的

要求；对其中模糊的要求要做进一步澄清，然后决定是否采纳；对于无法实现的要求要向

用户作充分的解释。最后，将软件的需求准确地表达出来，形成软件需求说明书。其实现

步骤如图3.1所示。

图3.1 参考当前系统建立目标系统模型

（1）获得当前系统的物理模型：首先，分析、理解当前系统是如何运行的，了解当

前系统的组织机构、输入/输出、资源利用情况和日常数据处理过程，并用一个具体的模

型来反映自己对当前系统的理解。此步骤也可以称为“业务建模”，其主要任务是对用户

的组织机构或企业进行评估，理解他们的需要及未来系统要解决的问题，并用一个具体模

型来反映自己对当前系统的理解。这一模型应客观地反映现实世界的实际情况。当然，如

果系统相对简单，也没必要大动干戈地进行业务建模，只要做一些简单的业务分析即可。

（2）抽象出当前系统的逻辑模型：在理解当前系统“怎样做”的基础上，取出非本

质因素，抽取出“做什么”的本质。

（3）建立目标系统的逻辑模型：分析目标系统与当前系统逻辑上的差别，明确目标

系统要“做什么”，从而从当前系统的逻辑模型中，导出目标系统的逻辑模型。

（4）对目标系统逻辑模型进行补充，具体内容如用户界面、启动和结束、出错处理、系统输入输出、系统性能、其他限制等等。

3．需求分析的主要工作

软件需求分析可被划分成5个工作阶段：问题分析；问题评估和方案综合；建模；规约；复审。

例1. 汽车零件的主要供应商需要一个库存控制系统，系统分析员发现与当前的手工

系统相关的问题包括：（1）不能快速地获得部件的状况；（2）更新卡片文件需要2至或

3天的工作量；（3）由于没有办法查找相关厂商的部件信息，而使得对同一厂商同一货品多次再订货，等等。一旦问题被标识出来，系统分析员将确定新系统该产生什么信息，以

及将提供什么信息。

例 2. 客户希望得到指明什么零件从库存中取出、以及还剩余多少相似零件的日报表。客户指明一旦当该零件离开仓库时库存管理员就该记载每个零件的标号。通过对当前问题

和希望的信息（输入和输出）进行的评估，系统分析员开始综合一个或多个解决方案。为

了便于开始，必须详细地定义系统的数据、处理功能和行为。

例3. 在例1与例2的基础上，一些可以进一步思考内容是，一旦已经建立这些信息，就该考虑针对实现的基本体系结构，那么客户/服务器方法似乎是合适的，但是它确实属

于在软件计划中概括的范围吗？似乎需要一个数据库管理系统，但是，该数据库系统真的

是用户/客户需要的吗？继续评估和综合的过程，直至分析员和客户均确信针对后面的开

发步骤软件确实已被适当地刻划了。

例3. 说明了在贯穿整个评估和综合过程，分析员的主要焦点是“做什么”，而不是“怎么做”，即应该思考的是：系统会产生和使用什么数据？系统必须完成什么功能？将

定义什么界面？会应用什么约束？。在问题评估和综合解决方案的活动中，系统分析员创

建系统模型，以便可以更好地理解数据流和控制流、处理功能和操作行为以及信息内容。

4. 系统分析员的主要能力

毫无疑问，在整个系统分析活动中，系统分析员起着关键的作用，这意味着我们对系

统分析员有着较高的期望，其本人也应该具备各项突出的能力。这些能力的主要表现如下：

能掌握抽象概念，能对其进行分类，能从中综合出解的能力；能从冲突或者混淆中

吸取恰当事实的能力；能弄清用户环境的能力；能伪用户系统恰当配置软硬件的能力

能较好地用书面和口头形式进行沟通的能力；有“从树木见森林“的能力。

3.1.2 需求获取

软件需求分析中的相互沟通，总是要在两方或多方间进行。系统分析员所问的第一组

问题可以关注客户、整体目标和收益。接下来的下一组问题使得系统分析员能够对问题做

更好的理解，使得客户能够表达其关于解决方案的感觉，例如：如何刻画由某成功解决方

案所产生的“好的”输出？该解决方案强调了什么问题？能向我显示或描述解决方案所应

用的环境吗？系统分析员所问的最后一组问题关注于会议的效果。例如：你是回答这些问

题的合适人员吗？你的回答是“正式的”吗？我的提问和你想解决的问题相关吗？其他人

员可以提供附加信息吗？其他我应该问你的问题吗？

除了上述做法之外，也可以采用一种面向团队的需求收集方法，该方法被应用在分析

和规约的早期阶段，被称为便利的应用规约技术，即FAST技术，该方法鼓励建立客户和

系统分析员之间的合作，由他们共同工作来标识问题、提出解决方案的要素、商议不同的

方法以及刻画出初步的解决方案需求。

FAST方法的基本原则是：

在中立的地点举行会议，由系统分析员和客户出席。建立准备和参与会议的规则。

建议一个足够正式的议程，以便可以对所有重要点的、而又是足够非正式的问题进行自由

交流。有一个“协调者”控制会议过程。使用一种“定义机制”（它可以是工作表、图表、墙上胶黏纸或墙板）记录有关信息。会议的目标是标识问题、提出解决方案的要素、商议不同的方法以及在有利于完成目标的氛围中，刻画出初步的解决方案需求。