第3章 需求分析
• 基本任务是准确地回答：“系统必须做什么?” 。
对目标系统提出完整、准确、清晰、具体的要求。
• 系统分析员应该写出软件需求规格说明书。
需求分析应遵守下述准则：
(1) 必须理解并描述问题的信息域，建立数据模型。
(2) 必须定义软件应完成的功能，建立功能模型。
(3) 必须描述作为外部事件结果的软件行为，建立行为模型。
(4) 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。
3.1 需求分析的任务
3.1.1 确定对系统的综合要求
1. 功能需求
指定系统必须提供的服务，划分出系统必须完成的所有功能。
2. 性能需求
指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。
3. 可靠性和可用性需求
4. 出错处理需求
当应用系统发现它自己犯下一个错误时所采取的行动。但是，仅限于对系统的关键部分有选择地提出这类出错处理需求。
5. 接口需求
描述应用系统与它的环境通信的格式。
常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。
6. 约束
描述在设计或实现应用系统时应遵守的限制条件。
常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。
7. 逆向需求
说明软件系统不应该做什么。
用于澄清真实需求，消除可能发生的误解的那些逆向需求。
8. 将来可能提出的要求
对系统将来可能的扩充和修改预做准备。
3.1.2 分析系统的数据要求
这是软件需求分析的一个重要任务。
通常采用建立数据模型的方法(ER图)。
表示方法：
数据结构（表示数据元素之间的逻辑关系）
数据字典（不够形象直观）
层次方框图和Warnier图（3.7节介绍）
存储方式：
数据库或文件。
3.1.3 导出系统的逻辑模型
• 综合上述两个步骤的结果导出系统的逻辑模型
• 用以下工具描述
数据流图
实体联系图
状态转换图
数据字典
主要的处理算法
3.1.4 修正系统开发计划
•修正可行性分析中制定的开发计划
•估计比较准确的系统成本和进度
3.2 与用户沟通获取需求的方法
3.2.1 访谈
• 正式
• 非正式
• 调查表
• 情景分析技术
3.2.2 面向数据流自顶向下求精
结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。
• 可行性研究得出的是目标系统的高层数据流图
• 需求分析的目标之一就是把数据流和数据存储定义到元素级。
• 从数据流图的输出端着手分析，输出数据决定了系统必须具有的最基本的组成元素。
输出数据组成元素通过调查访问不难搞清。
每个输出数据元素又是从哪里来的呢?
或者是从外面输入到系统中来，或者是通过计算由系统中产生出来的。
• 从输出端往输入端回溯，可确定每个数据元素的来源，及有关的算法。
但是，高层数据流图中许多细节没有包括，因此回溯时常常遇到下述问题：
某个数据元素需要用到数据流图中目前还没有的数据元素，
或者得出这个数据元素需要用的算法尚不完全清楚。
• 数据元素归入数据字典
• 算法记录在IPO图中
• 增补数据流图
• 请用户复查
复查过程验证了已知的元素，补充了未知的元素，填补了文档中的空白。
• 追踪更详细的数据流，把数据流图扩展到更低的层次。通过功能分解完成数据流图的细化。
在分析追踪时可能产生新的问题，这些问题的答案可能又在数据字典中增加一些新条目，或产生新的或精化的算法描述。
最终得到对系统数据和功能要求的满意了解。
下页图3.1粗略地概括了上述分析过程。
图3.1 面向数据流自顶向下求精过程
3.2.3 简易的应用规格说明技术
为了解决上述问题，人们研究出一种面向团队的需求收集法，称为简易的应用规格说明技术。
这种方法提倡用户与开发者密切合作，商讨不同方案并指定基本需求。
•初步访谈，确定问题和解决方案
•开发者和用户分别写“产品需求”
•开会前，将“产品需求”分发
•每个人审查“产品需求”，列出系统对象
•开会，合并对象（消去冗余），得到意见一致的列表
•分小组讨论，制定小型规格说明
•综合讨论，起草软件规格说明书
3.2.4 快速建立软件原型
•快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。其特性：
快速
容易修改
•为了快速地构建和修改原型，通常使用下述3种方法和工具：
第四代技术（使得软件工程师能够快速地生成可执行的代码，是较理想的快速原型工具）
可重用的软件构件（使用一组已有的软件构件来装配原型）
形式化规格说明和原型环境（调用自动工具把基于形式语言的规格说明翻译成可执行的程序代码）
3.3 分析建模与规格说明
3.3.1 分析建模
为了更好地理解复杂事物，人们常常采用建立事物模型的方法。
所谓模型，是为了理解事物而对事物做出的一种抽象，是一种无歧义的书面描述。
模型由一组图形符号和组织这些符号的规则组成。
根据结构化分析准则，需求分析过程应该建立3种模型，它们分别是数据模型、功能模型和行为模型。
数据模型
实体－联系图，描绘数据对象及数据对象之间的关系，用于建立数据模型。
功能模型
数据流图，描绘当数据在软件系统中移动时被变换的逻辑过程，指明系统具有变化数据的功能，是建立功能模型的基础。
行为模型
3.6节状态转换图（状态图），指明作为外部事件结果的系统行为。描绘了系统的各种行为模式(称为“状态”)和在不同状态间转换的方式。是行为建模的基础。
3.3.2 软件需求规格说明
是需求分析阶段得出的最主要的文档。
• 用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。
• 自然语言的规格说明具有容易书写、容易理解的优点，为大多数人所欢迎和采用。
3.4 实体——联系图
数据模型中包含3种相互关联的信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系。
3.4.1 数据对象
数据对象是对软件必须理解的复合信息的抽象。
数据对象可以是外部实体、事物、行为、事件、角色、单位、地点或结构等。总之，可以由一组属性来定义的实体都可以被认为是数据对象。
3.4.2 属性
属性定义了数据对象的性质。
必须把一个或多个属性定义为“标识符”，也就是说，当人们希望找到数据对象的一个实例时，用标识符属性作为“关键字”(通常简称为“键”)。
3.4.3 联系
客观世界中的事物彼此间往往是有联系的。
数据对象彼此之间相互连接的方式称为联系，也称为关系。联系可分为以下3种类型。
一对一联系(1∶1)
一对多联系(1∶N)
多对多联系(M∶N)
(1) 一对一联系(1∶1)
例如，一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。
(2) 一对多联系(1∶N)
例如，某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教(见图3.2)。
(3) 多对多联系(M∶N)
例如，图3.2表示学生与课程间的联系(“学”)是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。
3.4.4、实体联系图的符号
通常，使用实体�联系图(entity�relationship diagram)来建立数据模型。可以把实体�联系图简称为ER图，相应地可把用ER图描绘的数据模型称为ER模型。
ER图中包含了实体(即数据对象)、关系和属性3种基本成分，通常用矩形框代表实体，用连接相关实体的菱形框表示关系，用椭圆形或圆角矩形表示实体(或关系)的属性，并用直线把实体(或关系)与其属性连接起来。
ER模型可以作为用户与分析员之间有效的交流工具。
3.5 数据规范化
软件系统经常使用的各种长期保存的信息，通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，通常需要把数据结构规范化。
3.6 状态转换图
用于建立软件系统的行为模型。
通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。
此外，还指明了作为特定事件的结果系统将做哪些动作(例如，处理数据)。
因此，状态图提供了行为建模机制。
3.6.1 状态
状态：
是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。
在状态图中定义的状态主要有：
初态(即初始状态)、终态(即最终状态)和中间状态。
在一张状态图中只能有一个初态，而终态则可以有0至多个。
当描绘单程生命期时，需要标明
初始状态(系统启动时进入初始状态)和
最终状态(系统运行结束时到达最终状态)。
描绘循环运行过程时不必。
3.6.2 事件
事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。
例如，内部时钟表明某个规定的时间段已经过去，用户移动或点击鼠标等都是事件。
简而言之，事件就是引起系统做动作或(和)转换状态的控制信息。
3.6.3 符号
初态用实心圆表示，
终态用一对同心圆(内圆为实心圆)表示。
中间状态用圆角矩形表示，
可以用两条水平横线把它分成上、中、下3个部分。
上面部分为状态的名称，这部分是必须有的；
中间部分为状态变量的名字和值，这部分是可选的；
下面部分是活动表，这部分也是可选的。
活动表的语法格式：事件名(参数表)/动作表达式
• “事件名”可以是任何事件的名称。
经常使用下述3种标准事件：entry，exit和do。
entry指定进入该状态的动作，
exit指定退出该状态的动作，
do指定在该状态下的动作。
• 需要时可以为事件指定参数表。
• 动作表达式描述应做的具体动作。
• 两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。
状态变迁通常是由事件触发的，在状态转换的箭头线上标出触发转换的事件表达式；如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。
事件表达式的语法如下：
事件说明［守卫条件］／动作表达式
• 事件说明的语法为：事件名(参数表)。
• 守卫条件是一个布尔表达式。
如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。
如果只有守卫条件没有事件说明，则只要守卫条件为真状态转换就发生。
• 动作表达式是一个过程表达式，当状态转换开始时执行该表达式。
3.6.4 例子
图3.4（见书57页）
没有人打电话时电话处于闲置状态；
有人拿起听筒则进入拨号音状态，到达这个状态后，电话的行为是响起拨号音并计时；
这时如果拿起听筒的人改变主意不想打了，他把听筒放下(挂断)，电话重又回到闲置状态；
如果拿起听筒很长时间不拨号(超时)，则进入超时状态；……。
3.7 其他图形工具
3.7.1 层次方框图
用树形结构的一系列多层次的矩形框描绘数据的层次结构。
树形结构顶层的矩形框，代表完整的数据结构，
下面的各层矩形框代表这个数据的子集，
最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。
例如，描绘一家计算机公司全部产品的数据结构可以用图3.5中的层次方框图表示。
图3.5 层次方框图的一个例子
3.7.1 层次方框图
从对顶层信息的分类开始，沿图中每条路径反复细化，直到确定了数据结构的全部细节时为止。
3.7.2 Warnier图
表示信息层次结构的另外一种图形工具。
但这种图形工具比层次方框图提供了更丰富的描绘手段。
用Warnier图可以表明信息的逻辑组织，
它可以指出一类信息或一个信息元素是重复出现的，
也可以表示特定信息在某一类信息中是有条件地出现的。
图3.6中的Warnier图表示
一种软件产品要么是系统软件要么是应用软件。
系统软件中有P1种操作系统，P2种编译程序，此外还有软件工具。
软件工具是系统软件的一种，它又可以进一步细分为编辑程序、测试驱动程序和设计辅助工具，并标出了每种软件工具的数量。
图3.6 Warnier图的一个例子
3.7.3 IPO图
IPO图是输入、处理、输出图的简称，它是美国IBM公司发展完善起来的一种图形工具，能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。
IPO图使用的基本符号既少又简单，因此很容易学会使用这种图形工具。
在左边的框中列出有关的输入数据，
在中间的框内列出主要的处理，
在右边的框内列出产生的输出数据。
处理框中列出处理的次序暗示了执行的顺序。
在IPO图中还用粗大箭头指出数据通信的情况。
图3.7是一个主文件更新的例子，通过这个例子不难了解IPO图的用法。
图3.7 IPO图的一个例子图
建议使用一种改进的IPO图(也称为IPO表)，图中包含某些附加的信息，比原始的IPO图更有用。如图3.8所示。
在需求分析阶段可以使用IPO图简略地描述系统的主要算法(即数据流图中各个处理的基本算法)。
当许多附加信息暂时还不具备时，在软件设计阶段可以进一步补充修正这些图，作为设计阶段的文档。
这正是在需求分析阶段用IPO图作为描述算法的工具的重要优点。
图3.8 改进的IPO图的形式
3.8 验证软件需求
3.8.1 从哪些方面验证软件需求的正确性
软件系统中15%的错误起源于错误的需求。
一般说来，应该从下述4个方面进行验证：
(1) 一致性：所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。
(2) 完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。
(3) 现实性：指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。
(4) 有效性：必须证明需求是正确有效的，确实能解决用户面对的问题。
3.8.2 验证软件需求的方法
1. 验证需求的一致性
•人工审查（正确性不能保证）
•形式化描述软件需求的方法：当软件需求规格说明书是用形式化的需求陈述语言书写时，可以用软件工具验证需求的一致性。
2. 验证需求的现实性
• 经验
• 应该采用仿真或性能模拟技术，辅助分析软件需求规格说明书的现实性。
3. 验证需求的完整性和有效性
• 用户是需求的权威，但是不能很好表达自己的需求
• 根据需求开发一个软件系统，用户试用，成本翻倍
• 建立快速原型系统，使用户提出更符合实际的要求
3.8.3 用于需求分析的软件工具
为了有效地保证软件需求的正确性，特别是一致性，需要有适当的软件工具支持需求分析工作。
这类软件工具应该满足下列要求：
(1) 必须有形式化的语法(或表)，使可以用计算机自动处理使用这种语法说明的内容；
(2) 使用这个软件工具能够导出详细的文档；
(3) 必须提供分析(测试)规格说明书的不一致性和冗余性的手段，并且应该能够产生一组报告指明对完整性分析的结果；
(4) 使用这个软件工具之后，应该能够改进通信状况。
