第三章需求分析

第三章需求分析第3章需求分析

意义软件需求的深入理解是软件开发工作获得成功的前提条件，不论我们把设计和编码做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发带来烦恼。

需求分析是软件定义时期的最后一个阶段，它的基本任务不是确定系统怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。并在在需求分析阶段结束之前，由系统分析员写出软件需求规格说明书，以书面形式准确地描述软件需求。即：

----准确地回答“系统必须做什么?”。

在分析软件需求和书写软件需求规格说明书的过程中，分析员和用户都起着关键的、必不可少的作用。

3.1需求分析的任务

需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。其中：

•

业务需求：反映组织机构和客户对系统、产品高层次的目标要求。

•用户需求：从用户使用的角度给出需求的描述。

如一个小型超市需要一个商品的查询系统。业务需求：进货人员需要查询商品库存以便保证及时进货；收款员需要查询商品的销售价格以便结账；经理需要查询商品的销售及盈利情况。用户需求:这三类用户怎样去查询系统，查询哪些信息，还需要哪些操作。•系统需求：从系统的角度描述要提供的服务以及所受到的约束。•

功能性需求：描述系统应该做什么，即为用户和其它系统完成的功能、提供的服务。•

非功能性需求：产品必须具备的属性或品质。•设计约束：设计与实现必须遵循的标准、约束条件。如运行平台、协议、选择的技术、编程语言和工具等。软件需求的描述

•结构化语言、PDL

•图形化表示

•数学描述（形式化语言描述）1确定对系统的综合要求

---功能需求、性能需求、可靠性和可用性需求、出错处理需求、接口需求、约束、

逆向需求、将来可能提出的要求。需求分析的具体任务分析系统的数据要求3导出系统的逻辑模型4修正系统开发计划3.2软件需求获取需求分析是一个包括创建和维持系统需求文档所必需的一切活动的过程。它包含了如下活动：系统可行性研究、需求获取和分析、需求描述和文档编写、需求有效性验证、需求管理（管理需求工程的变更）。可行性研究需求获取和分析需求描述需求有效性验证可行性研究报告系统模型用户需求和系统需求需求规约软件需求过程需求管理需求获取是开发人员与客户或用户一起对应用领域进行调查研究，收集系统需求的过程。需求分析是将获取到的需求准确的理解、求精，并将其转化为完整的需求定义（包括建模），进而生成需求规约的过程。需求获取和分析有一定的难度，因为：1）项目相关人员通常并不真正知道希望计算机做什么，让他们清晰的表达出需要系统做什么是件困难的事，他们或许提出不切实际的要求。2）项目相关人员用自己的语言表达需求，这些语言包含很多工作中的专业术语和专业知识。系统分析员没有这些知识和经验，而他们又必须了解这些需求。3）不同的项目相关人员有不同的需求，可能以不同的方式表达，分析人员必须发现所有潜在的需求资源，而且能发现这些需求的相容或冲突之处。4）经济和业务环境决定了分析是动态的，需求在分析过程中会发生变更。个别需求的重要程度会改变，新的需求会从新的项目相关人员那里得到。

软件工程思想(林锐P38—P48)需求分析为什么困难？如何进行需求分析？

需求获取技术

•

建立由客户（用户）、系统分析员、领域专家参加的联合小组。

•

需求获取的方法：个别访谈、召集会议、文档研究、问卷调查、观察用户工作流程、建立原型。

•

获取的需求的表达方式：（1）需求列表需求与系统的特殊视角或环境的关系

（2）业务流程图（状态/活动图）

（3）用例（Use-Case）/场景（Scenario）

（4）数据流图

（5）实体关系图

（6）类图、活动图、时序图等。

用例把系统分成一组逻辑的、互相联系较少的部分，每一部分都描述了系统与外部角色交互所提供的服务，即用例的集合代表了所有将会在系统需求中出现的交互。因此容易从使用的角度理解系统应达到的功能。例：列出图书馆系统中以下参与者的最小用例集：借阅者、借书员、图书管理员、会计系统。

借阅者：

•按题目查询书籍

•按作者查询书籍

•按主题查询书籍•预定已被其他人借出的书籍•查询借阅者的个人信息并列出借阅的书籍

借书员：所有借阅者的用例，再加上

•

为借阅者查找某一书籍

•

登记已归还的书籍

•

续借一本书

•

登记缴纳的罚款

•

添加新的借阅者

•

更新借阅者的个人信息（地址、电话号码等）

图书管理员：

所有借阅者和借书员的用例，再加上

•

添加藏书

•

删除藏书

•

改变系统中对已有书籍的记录信息

会计系统（独立运行）

•

获得借阅者支付的超期罚款3.3需求分析方法

常见的需求分析方法有：

功能分析方法

将系统看作若干功能模块的集合，每个功能又可以分解为若干子功能,子功能还可继续分解,分解的结果已经是系统的雏形。结构化分析方法是一种以数据、数据的封闭性为基础，从问题空间到某种表示的映射方法，由数据流图（DFD图）表示。信息建模法是从数据的角度对现实世界建立模型的,基本工具是ER图。面向对象的分析方法

面向对象的分析方法（OOA）的关键是识别问题域内的对象，分析它们之间的关系，并建立起三类模型。3.3.1、结构化分析方法（StructuredAnalysis简称SA）

SA的基本思想

结构化分析方法的基本思想是“分解”和“抽象”。分解：对于一个复杂的系统，为了将复杂性降低到可以掌握的程度，可以把大问题分解成若干小问题，然后分别解决。抽象：分解可以分层进行，即先考虑问题最本质的属性，暂把细节略去，以后再逐层添加细节，直至涉及到最详细的内容，这种用最本质的属性表示一个系统的方法就是“抽象”。SA法的步骤建立当前系统的“具体模型”。抽象出当前系统的逻辑模型。建立目标系统的逻辑模型。为了对目标系统做完整的描述，还需要考虑人机界面和其他一些问题。SA法的描述方法分层的数据流图数据词典描述加工逻辑的结构化语言、判定表及判定树实例：医院病房监护系统产生病情报告监视病情更新病历系统功能要求：

1、监视病员的病症（血压、体温、脉搏等）

2、定时更新病历

3、病员出现异常情况时报警。

4、随机地产生某一病员的病情报告。顶层：病员护士护士病员监护系统病员日志病症信号要求报告病症报告报警医院病房监护系统第一层：病员护士护士中央监视病员日志病症信号要求报告病症报告报警局部监视生成报告病员极限更新日志病员数据格式化病员数据生理信号极限值1324日志数据日志数据医院病房监护系统顶层DFD图第二层：加工“中央监视”分解计算超过极限值否病员数据超过极限值报警开解信号产生报警信息病员极限格式化病员数据体温血压、体温脉搏生理信号极限值时间脉搏血压日期时钟格式化病员数据3.13.23.33.4医院病房监护系统二层DFD图计算超过极限值否病员数据超过极限值报警开解信号产生报警信息病员极限格式化病员数据体温血压、体温、脉搏生理信号极限值时间脉搏血压日期时钟格式化病员数据3.13.23.33.4第二层：加工“中央监视”分解医院病房监护系统分层DFD图图2..15第一层格式化病员数据生理信号极限值病员护士护士中央监视病员日志病症信号要求报告病症报告报警局部监视生成报告病员极限更新日志病员数据1324日志数据图2..163.3.2、E-R方法（Entity-RelationshipApproach）

和实体模型E-R方法，即实体-联系方法。用于数据库逻辑设计过程，可定义实体模型。实体模型，是客观世界的纯表示，不涉及具体的数据结构、存取路径、存取效率等问题。实体模型中包含3种相互关联的信息：实体（数据对象）、实体的属性及实体彼此间相互连接的关系。举例图3.2某校教学管理ER图实体教师属性学生属性课程属性联系属性关系(1).实体-联系图的符号ER图中包含了实体、关系和属性等3种基本成分。通常用矩形框代表实体；用连接相关实体的菱形框表示关系；用椭圆形或圆角矩形表示实体(或关系)的属性；并用直线把实体(或关系)与其属性连接起来。(2).属性属性定义了实体的性质。必须把一个或多个属性定义为“标识符”，也就是说，当我们希望找到数据对象的一个实例时，用标识符属性作为“关键字”(通常简称为“键”)。应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。

如：学生具有学号、姓名、性别、年龄、专业（其它略）等属性；课程具有课程号、课程名、学分、学时数等属性；教师具有职工号、姓名、年龄、职称等属性。(3).联系数据对象彼此之间相互连接的方式称为联系，也称为关系。联系可分为以下3种类型：

a.一对一联系(1∶1)如：一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。

b.一对多联系(1∶N)如：某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教。c.多对多联系(M∶N)如：学生与课程间的联系(“学”)是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。联系也可能有属性。

如：学生“学”某门课程所取得的成绩，既不是学生的属性也不是课程的属性。由于“成绩”既依赖于某名特定的学生又依赖于某门特定的课程，所以它是学生与课程之间的联系“学”的属性。规范化的目的是：消除数据冗余，即消除表格中数据的重复；消除多义性，使关系中的属性含义清楚、单一；使关系的“概念”单一化，让每个数据项只是一个简单的数或字符串，而不是一个组项或重复组；方便操作。使数据的插入、删除与修改操作可行并方便；使关系模式更灵活，易于实现接近自然语言的查询方式。数据规范化如何规范化？规范化---将数据的逻辑结构归结为满足一定条件的二维表

（关系）。即：

1.表格中每个信息项必须是一个不可分割的数据项，不可是组项。

2.表格中每一列(列表示属性)中所有信息项必须是同一类型，各列的名字(属性名)互异，列的次序任意。

3.表格中各行(行表示元组)互不相同，行的次序任意。教工号姓名性别职称职务001张毅坤男教授院长002李林女讲师用教学管理例说明如何规范化有三个实体型，即课程、学生和教师，用三个关系保存它们的信息：

学生(学号，姓名，性别，年龄，年级，专业，籍贯)

教师(职工号，姓名，年龄，职称，职务，工资级别，工资)

课程(课程号，课程名，学分，学时，课程类型)为表示实体型之间的联系，又建立两个关系：

选课

(学号，课程号，听课出勤率，作业完成率，分数)

教课

(职工号，课程号，授课效果)这五个关系，组成了数据库的模型。在每个关系中，属性名下加（下划线）指明关键字。关键字能唯一地标识一个元组。1、范式级别越高，存储同样数据就需要分解成更多张表，因此，

“存储自身”的过程也就越复杂。2、随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差。3、范式级别提高则需要访问的表增多，因此性能(速度)将下降。从实用角度看来，选用第三范式都比较恰当。通常用“范式(NormalForms)”定义消除数据冗余的程度。第一范式(1NF)数据冗余程度最大，第五范式(5NF)数据冗余程度最小。但是：第一范式

每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。

如：学生(学号，姓名，性别，年龄，年级，专业，籍贯)教师(职工号，姓名，年龄，职称，职务，工资级别，工资)课程(课程号，课程名，学分，学时，课程类型)第二范式

满足第一范式条件，而且每个非关键字属性完全依赖于关键字。

如：选课

(学号，课程号，听课出勤率，作业完成率，分数)教课

(职工号，课程号，授课效果)第三范式

符合第二范式的条件，非主属性相互独立，即任何非主属性间不存在函数依赖。

如：教师(职工号，姓名，年龄，职称，职务，工资)-----工资依赖于职称或职务教师(职工号，姓名，年龄，职称，职务，工资级别，工资)3.4状态转换图

状态转换图(简称为状态图)

通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果系统将做哪些动作(例如，处理数据)。1).状态

状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。系统对事件的响应，既可以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。

初态(即初始状态)状态终态(即最终状态)中间状态一张状态图中只能有一个初态，而终态则可以有0至多个。2).事件事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。

例如，内部时钟表明某个规定的时间段已经过去，用户移动或点击鼠标等都是事件。简而言之，事件就是引起系统做动作或(和)转换状态的控制信息。初态用实心圆表示，终态用一对同心圆(内圆为实心圆)表示。中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下3个部分。上面部分为状态的名称，这部分是必须有的；中间部分为状态变量的名字和值，这部分是可选的；下面部分是活动表，这部分也是可选的。3).符号活动表的语法格式：事件名(参数表)/动作表达式其中，“事件名”可以是任何事件的名称。在活动表中经常使用下述3种标准事件：entry，exit和do。entry事件指定进入该状态的动作，exit事件指定退出该状态的动作，而do事件则指定在该状态下的动作。需要时可以为事件指定参数表。活动表中的动作表达式描述应做的具体动作。3).符号状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。状态变迁通常是由事件触发的，在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式；如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。事件表达式的语法：事件说明［守卫条件］／动作表达式事件说明的语法为：事件名(参数表)。守卫条件是一个布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真状态转换就发生。动作表达式是一个过程表达式，当状态转换开始时执行该表达式。3).符号4).举例电话系统的状态图3.5其他图形工具

层次方框图

Warnier图

IPO图举例3.5.1层次方框图层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。随着结构的精细化，层次方框图对数据结构也描绘得越来越详细，这种模式非常适合于需求分析阶段的需要。系统分析员从对顶层信息的分类开始，沿图中每条路径反复细化，直到确定了数据结构的全部细节时为止。领导层辅助决策系统查询辅助决策物资信息重点供料信息商情信息人员状况合同监视财务信息计划执行情况工程进展情况超储低储情况经营指标历年对比价格预测物资用量预测库存定额核定库存结构分析经济采购批量保本保利分析3.5.2Warnier图法国计算机科学家Warnier提出了表示信息层次结构的另外一种图形工具。Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。用Warnier图可以表明信息的逻辑组织。它可以指出一类信息或一个信息元素是重复出现的，也可以表示特定信息在某一类信息中是有条件地出现的。重复和条件约束是说明软件处理过程的基础，所以很容易把Warnier图转变成软件设计的工具。举例图中表示一种软件产品要么是系统软件要么是应用软件。系统软件中有P1种操作系统，P2种编译程序，此外还有软件工具。软件工具是系统软件的一种，它又可以进一步细分为编辑程序、测试驱动程序和设计辅助工具，图中标出了每种软件工具的数量。3.5.3IPO图左边的框中列出有关的输入数据。中间的框内列出主要的处理，处理框中列出处理的次序暗示了执行的顺序，但是用这些基本符号还不足以精确描述执行处理的详细情况。在右边的框内列出产生的输出数据。在IPO图中还用类似向量符号的粗大箭头清楚地指出数据通信的情况。一种改进的IPO图(也称为IPO表)在需求分析阶段可以使用IPO表简略地描述系统的主要算法(即数据流图中各个处理的基本算法)。