第3章-需求分析0909.ppt

1、第3章 软件需求分析,教学目的与要求： 深刻理解需求分析阶段的概念及任务，熟练掌握数据流图的细化及ER图，HIOP图的画法。教学重点：需求分析阶段的任务、方法、具体任务。教学难点：写出需求规格说明书,第3章 需求分析,3.1 需求分析的任务3.2 与用户沟通获取需求的方法3.3 分析建模与规格说明3.4 实体-联系图3.5 数据规范化,3.6 状态转换图3.7 其他图形工具3.8 验证软件需求3.9 小结习题,成功来之不易,31%,（取消）,16.2%,（成功地完成）,53.8%,（受到挑战）,Source: Standish Group,2,软件项目失败的原因,软件项目失败的最重要的五个原因

2、,需求不完整,缺少客户的参与 缺少资源,期望值过高,缺少高层的支持,0%,5%,10%,15%,3,需求错误的成本,4,软件需求的重要性, 软件需求是决定软件开发是否成功的一个关键因素,需求分析可以帮助开发人员真正理解业务问题- 需求分析是估算成本和进度的基础,- 需求分析可以避免建造错误的系统，从而减少不必要的浪费 - 软件规格说明有助于开发人员与客户在“系统应该做什么”问题 上达成正式契约,- 需求分析形成了软件开发的基线，有助于管理软件的演化和 变更,- 软件需求是软件质量的基础，为系统验收测试提供了标准,5,什么是软件需求分析： 将用户非形式的需求陈述转化为完整的需求定义，再由需求定义

3、转换到相应的需求规格说明的过程。软件需求分析的重要性： 软件需求分析是软件生存期决定性的一步，是软件开发的基础。分析员和用户： 在分析软件需求和书写软件需求规格说明书的过程中，分析员和用户都起着关键的、必不可少的作用。,3.1 需求分析的任务,机票预定系统一、系统简介 航空公司为给旅客乘机提供方便，需要开发一个机票预定系统。各个旅行社把预定机票的旅客信息（姓名、性别、工作单位、身份证号码（护照号码）、旅行时间、旅行始发地和目的地，航班舱位要求等）输入到系统中，系统为旅客安排航班。当旅客交付了预订金后，系统打印出取票通知和帐单给旅客，旅客在飞机起飞前一天凭取票通知和帐单交款取票，系统核对无误即打

4、印出机票给旅客。此外航空公司为随时掌握各个航班飞机的乘载情况，需要定期进行查询统计，以便适当调整。二、技术要求和限制条件1在分析系统功能时要考虑有关证件的合法性验证（如身份证、取票通知和交款发票）等。2对于本系统还应补充一下功能： - 旅客延误了取票时间的处理 - 航班取消后的处理 - 旅客临时更改航班的处理3系统的外部输入项至少包括：旅客、旅行社和航空公司。,软件需求分析的基本任务是准确地回答“系统必须做什么?”,3.1 需求分析的任务,3.1.1 确定对系统的综合要求,1. 功能需求 这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。2. 性能需求 性能需求

5、指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、等方面的需求。3. 可靠性、可用性、安全性、保密性等需求 要求定量地指定系统的可靠性、可用性、安全性、保密性等。,机票预定系统一、系统简介 航空公司为给旅客乘机提供方便，需要开发一个机票预定系统。各个旅行社把预定机票的旅客信息（姓名、性别、工作单位、身份证号码（护照号码）、旅行时间、旅行始发地和目的地，航班舱位要求等）输入到系统中，系统为旅客安排航班。当旅客交付了预订金后，系统打印出取票通知和帐单给旅客，旅客在飞机起飞前一天凭取票通知和帐单交款取票，系统核对无误即打印出机票给旅客。此外航空公司为随时

6、掌握各个航班飞机的乘载情况，需要定期进行查询统计，以便适当调整。二、技术要求和限制条件1在分析系统功能时要考虑有关证件的合法性验证（如身份证、取票通知和交款发票）等。2对于本系统还应补充一下功能： - 旅客延误了取票时间的处理 - 航班取消后的处理 - 旅客临时更改航班的处理3系统的外部输入项至少包括：旅客、旅行社和航空公司。,非功能需求, 非功能需求,- 从各个角度对系统的约束和限制，反映了应用对软件系统质 量和特性的额外要求，例如响应时间、数据精度、可靠性、 开发过程的标准等。, 举例：MiniLibrary,- 系统应在 20 秒之内响应所有的请求。 - 系统每周 7 天、每天 24 小

7、时都可以使用。,- 对于一个没有经验的用户而言，经过两个小时的培训就可以使用系统的所有功能。,16,非功能需求,非功能需求,过程需求,产品需求,外部需求,软件交付 实现方法 标准,互操作性 道德 法规 成本,可用性 软件性能,存贮空间,可靠性,可移植性 安全性,17,非功能需求,特性,度量指标, 每秒处理的事务,速度, 用户或事件的响应时间, 屏幕的刷新时间, 字节数,存贮空间, RAM 芯片数, 培训时间,可用性, 帮助页面数, 平均失败时间,可靠性, 系统无效的概率, 失败发生率, 失败后的重启次数,容错性, 事件引起失败的比例, 失败时数据崩溃的可能性,18,思考题例： A银行长年开放1

8、00台ATM机，1000台用于商场酒店的POS机，B银行没有ATM和POS机只有10个每天8点上班17点下班的储蓄所。请问：A、B银行的可靠性可用性各应如何设置？4. 出错处理需求 在某些情况下，“出错处理”指的是当应用系统发现它自己犯下一个错误时所采取的行动。但是，应该有选择地提出这类出错处理需求。对应用系统本身错误的检测应该仅限于系统的关键部分，而且应该尽可能少,5. 接口需求 接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。6. 约束 常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。7、

9、用户界面需求,系统环境-多少台机器、 机型等接口；8、系统可移植性、可维护性等方面的需求。9. 将来可能提出的要求,这是软件需求分析的一个重要任务。通常采用建立数据流图、数据字典和数据模型的方法。 常用的图形工具有层次方框图HIPO和Warnier图，在本章第3.7节中将简要地介绍这两种图形工具。 软件系统经常使用各种长期保存的信息，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化(见3.5节)。3.1.3 导出系统的逻辑模型 在分析综合中逐步细化软件功能划分各子功能，对系统数据域进行分析，建立新系统的逻辑模型(系统图.数据流图.数据字典.E-R图、UM

10、L模型图表示)。 常用方法是，面对结构化分析方法（SA）面向数据结构（JSP）方法，面向对象OOA方法。,3.1.2 分析系统的数据要求,3.1.4 修正系统开发计划,3.1.4 修正系统开发计划 根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。3.2 与用户沟通获取需求的方法需求获取的困难 用户通常并不真正知道自己希望计算机系统做什么 用户通常使用业务语言表达需求，开发人员缺乏相关的领域知识和经验，难以准确理解这些需求 不同的用户提出不同的需求，可能存在矛盾和冲突 管理者可能出于增加影响力的原因而提出特别的需求 由于经济和业务环境

11、的动态性，需求经常发生变更,补充：与用户沟通获取需求的方法,3.2 与用户沟通获取需求的方法,需求获取的关键在于通过与用户的沟通和交流，收集和理解用户的各项要求。 3.2.1 访谈3.2.2 面向数据流自顶向下求精3.2.3 简易的应用规格说明技术3.2.4 快速建立软件原型,(1)访问用户和用户领域的专家(2)需求讨论会(3) 问卷调查(4)现场考察,补充：获取需求的具体方法,3.3 分析建模与规格说明需求分析的步骤,用户面谈, 用户面谈,一种理解商业功能和商业规则的最有效方法 面谈过程需要认真的计划和准备,- 面谈之前, 确立面谈目的, 确定要包括的相关用户 确定参加会议的项目小组成员 建

12、立要讨论的问题和要点列表 复查有关文档和资料, 确立时间和地点, 通知所有参加者有关会议的目的、时间和地点,52,用户面谈, 面谈过程需要认真的计划和准备（续）,- 进行面谈, 衣着得体，准时到达 寻找异常和错误情况 深入调查细节, 详细记录, 指出和记录下未回答条目和未解决问题 - 面谈之后, 复查笔记的准确性、完整性和可理解性 把所收集的信息转化为适当的模型和文档 确定需要进一步澄清的问题域, 适当的时候向参加会议的每一个人发一封感谢信,53,需求专题讨论会, 需求专题讨论会,- 项目主要风险承担人在短暂而紧凑的时间段内集中在一起， 一般为 1 至 2 天，与会者可以在应用需求上达成共识、

13、对操作过程尽快取得统一意见。, 优点,协助建立一支高效的团队，围绕项目成功的目标； - 所有的风险承担人都畅所欲言；,促进风险承担人和开发团队之间达成共识； - 揭露和解决那些妨碍项目成功的行政问题； - 能够很快地产生初步的系统定义。,54,需求专题讨论会, 专题讨论会准备,- 参加会议人员：主持人、用户、技术人员、项目组人员 - 安排日程：通常在具有相应支持设备的专用房间进行, 举行会议,- 可能出现行政间的责备或冲突，主持人应掌握讨论气氛并控制会场。,- 会议最重要的部分是自由讨论阶段，这种技术非常符合专题 讨论会的气氛，并且营造一种创造性的和积极的氛围，同时可以获得所有相关者的意见。,

14、- 注意分配会议时间，记录所有言论。,55,需求专题讨论会,56,问卷调查, 问卷调查,- 可用于确认假设和收集统计倾向数据 - 问卷需要快速回答，允许匿名方式 存在问题,- 相关的问题不能事先决定,问题背后的假设对答案造成偏颇，如这符合你的期望吗？- 难以探索一些新领域,- 难以继续用户的模糊响应, 在完成最初的面谈和分析后，可作为一项协作技术可以收到良好的效果。,57,现场考察, 现场观察商业过程和工作流程,- 掌握用户如何实际使用一个系统以及到底用户需要哪些信 息，最好的办法是亲自观察用户是如何完成实际工作的。, 一般方法,- 对办公室进行快速浏览，了解布局、设备要求和使用、工作 流总体

15、情况。,- 安排几个小时观察用户是如何实际完成他们的工作，理解用户实际使用计算机系统和处理事务的细节。,像用户一样接受训练和做实际工作，发现关键问题和瓶颈。 注意：观察可能使用户紧张。,58,3.3.1分析建模1、问题识别 双方确定对问题的综合需求。基于项目有关的软件的功能、性能、环境、用户界面、可靠性、安全性、保密性、可移植性、可维护性、等方面的需求。,3.3 分析建模与规格说明 需求分析的步骤,2、分析和综合导出软件的逻辑模型,2、分析和综合导出软件的逻辑模型 1）分析人员对获取的需求进行一致的分析检查，逐步细化软件功能，划分各子功能； 2）对系统数据域进行分解，分配到各子功能上； 3）用

16、图文结合的形式，建立新系统的逻辑模型和物理视图。 物理视图指系统数据输入输出使用什么设备或方式，例键盘输入、数据扫描、数据传送等方式。,3.3.2 软件需求规格说明,3.3.2 软件需求规格说明 软件需求规格说明书，是需求分析阶段得出的最主要的文档。 补充：需求分析阶段要编写文档： 1）编写“需求规格说明书” 2）编写初步用户手册 3）编写“确认测试计划”(为系统完成后确认验收的依据). 4） 修改完善软件开发计划 需求规格说明书写法见实验指导书,3.4 实体-联系图（E-R图）,应该包括在SRS（需求规格说明）中的内容- 功能： 软件应该提供什么功能？外部接口：软件如何与人、系统硬件和其他系

17、统等进行相互 作用？- 性能： 软件系统在运行速度、可用性、响应时间、恢复时间 等方面有什么要求？- 特性：软件系统在可移植性、可维护性、安全性等方面有什 么考虑？设计约束：是否存在必要的标准、开发语言、数据库、资源 限制、运行环境等因素的影响和策略？不应该包括在SRS 中的内容- 项目开发计划: 如成本、人员、进度、工具、方法等 - 产品保证计划 : 如配置管理、验证与测试、 质量保证等- 软件设计细节: 需求通常用于表达“做什么”， 而不描述“如何做”。,编写需求规格说明的原则,原则 1：只描述“做什么”而无须描述“怎么做” 原则 2：必须说明运行环境 原则 3：考虑用户、分析员和实现者的

18、交流 -对形式化和自然语言之间作出恰当的选择 - 明确的理解最重要，不存在十全十美的软件规格说明书,编写需求规格说明的原则,原则 4：力求寻找到恰如其分的需求详细程度 - 一个有益的原则就是编写单个的可测试需求文档 - 建议将可测试的需求作为衡量软件产品规模大小的尺度 原则 5：文档段落不宜太长 简短 - 记住：不要在需求说明中使用“和/或”、“等等”之类的词原则 6：避免使用模糊的、主观的术语- 如用户友好、容易、简单、迅速、有效、许多、最新技术、 优越的、可接受的、最大化、最小化、提高等- 不可验证 建议：采用一种标准的SRS 模板,需求工程, 需求工程是应用已证实有效的原理和方法，并通过

19、合 适的工具和符号，系统地描述出待开发系统及其行为 特征和相关约束。,活动,持续进行的需求管理 需求,需求获取,需求分析,需求验证,规格说明,工作产品,已确认的,需求规格,会议记录等,分析模型,需求规格,说明书,说明书,22,为了把用户的数据要求清楚、准确地描述出来，系统分析员通常建立一个概念性的数据模型(也称为信息模型)。数据模型中包含3种相互关联的信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系。3.4.1 数据对象 3.4.2 属性 3.4.3 联系3.4.4 实体-联系图的符号 通常，使用实体-联系图(entity-relationship diagram)来建立数据模型。

20、可以把实体-联系图简称为ER图，相应地可把用ER图描绘的数据模型称为ER模型。,3.4 实体-联系图（E-R图）,ER信息模型的设计,ER信息模型的设计E R方法是英文 entity relationship approach 的简称，译作实体一联系方法。此法通过ER图形表示信息世界中的实体、属性、关系的模型。1）ER图约定：实体用方框表示，联系用菱形框表示。框内填入相应的实体名，联系名及属性名。下图举了三个例子，表示了二个实体间的联系，而三个例子由三种不同的联系方法。,三个例子,三个例子，表示了二个实体间的联系，而三个例子由三种不同的联系方法。,第一种情况,第一种情况：是一对一的关系，一个工

21、厂只有一个正厂长。第二种情况：是一对多的联系，一个仓库存放多种和多个产品；第三种情况：是多对多的联系，一个学生要学习多门课程，而一门课程又有多名学生学习，所以是多对多的联系。同时从图中也可看出联系也可能有属性，如存放有属性数量，学习有属性成绩等。2）如何设计ER图先画出局部ER图，再对局部ER加以综合，产生一个总体ER图,先画出局部ER图，再对局部ER加以综合，产生一个总体ER图。,软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。下面给出第一、第二和第三范式的定义：(

22、1) 第一范式在同一表中没有重复项出现，如果有则应将重复项去掉。 每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。,3.5 数据规范化,(2) 第二范式满足第一范式条件,(2) 第二范式满足第一范式条件，而且每个非关键字属性都由整个关键字决定(而不是由关键字的一部分来决定)。 每个表必须有一个（而且仅一个）数据元素为主关键字，其它元素与主关键字一一对应。(3) 第三范式符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述(即一个非关键字属性值不依赖于另一个非关键字属性值)。 表中的所有数据元素，不但要能够唯一地被主关键

23、字所标识，而且它们之间还必须相互独立，不存在其它的函数关系。,3.6 状态转换图,根据本章开头讲的结构化分析的第3条准则，在需求分析过程中应该建立起软件系统的行为模型。状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果系统将做哪些动作(例如，处理数据)。因此，状态图提供了行为建模机制，可以满足第3条分析准则的要求。 （面向对象模型中介绍）,3.6 状态转换图（略）,3.7 其他图形工具,3.7 其他图形工具3.7.1 层次方框图(H图） 层次方框图是用树形结构的一系列多层次的矩形框描绘数据的层次结构。 树形结构的顶层是

24、一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。,3.7.2 Warnier图,图3.5 层次方框图的一个例子,法国计算机科学家Warnier提出了表示信息层次结构的另外一种图形工具。和层次方框图类似，Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。,3.7.2 Warnier图,HIPO图,图3.6 Warnier图的一个例子,3.7.3 HIPO图HIPO（Hierarchy Plus InputProcessOutput）图，是IBM公司于70年代中期在

25、层次结构图的基础上，做出的一种描述系统结构和模块内部处理功能的工具。 HIPO图，有H图和IPO图两部分组成。H图描述整个系统的设计结构合格模块之间的关系，H图画n层，每层根据经验一般为310个模块，层次（n层）按具体情况定。IPO图描述某一特定模块内部的处理过程和输入输出关系。HIPO图一般有1张H图，多张 IPO图组成,层次模块结构图,H图特点,层次模块结构图（H图）,1、H图基本做法：是将系统划分为若干子系统，子系统下再划分为若干的模块，大模块内再分子模块。 2、H图特点：主要关心模块的外部属性，不关心模块的内部，即只关心它是什么能够作什么，不关心它怎么做。（怎么做IPO图解决） 3、模

26、块的定义(什么是模块)：具有输入输出、逻辑功能、运行程序和内部数据这四种属性的一个程序。IPO图 IPO图是输入、处理、输出图的简称,图3.7 IPO图的一个例子图,图3.7 IPO图的一个例子图,c.5.4.4上组模块送入出入库单据,1核对纪录2核对价格3核对用户纪录4记录合格,将合格标志送回上一级模块c.5.4.4,模块编号:c.5.5.8,图3.8 改进的IPO图的形式,图3.8 改进的IPO图的形式,本书建议使用一种改进的IPO图(也称为IPO表)，,3.8 验证软件需求,需求工程, 需求工程是应用已证实有效的原理和方法，并通过合 适的工具和符号，系统地描述出待开发系统及其行为 特征和

27、相关约束。,活动,持续进行的需求管理 需求,需求获取,需求分析,需求验证,规格说明,工作产品,已确认的,需求规格,会议记录等,分析模型,需求规格,说明书,说明书,22,(1) 一致性所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。(2) 完整性需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。(3) 现实性指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。对硬件技术的进步可以做些预测，对软件技术的进步则很难做出预测，只能从现有技术水平出发判断需求的现实性。(4) 有效性必须证明需求是正确有效的，确实能解决用户面对的问题。,3.8.2 验证软件需求的方法,3.8

28、 验证软件需求3.8.1 从哪些方面验证软件需求的正确性,1. 验证需求的一致性、正确性 当需求分析的结果是用自然语言书写的时候，除了靠人工技术审查验证软件系统规格说明书的正确性之外，目前还没有其他更好的“测试”方法。 在目标系统规模庞大、规格说明书篇幅很长的时候，人工审查的效果是没有保证的。 当软件需求规格说明书是用形式化的需求陈述语言书写的时候，可以用软件工具验证需求的一致性。2. 验证需求的现实性 分析员参照以往开发类似系统的经验，分析用现有的软、硬件技术实现目标系统的可能性。必要的时候应该采用仿真或性能模拟技术，辅助分析软件需求规格说明书的现实性。,3.8.2 验证软件需求的方法,3.

29、 验证需求的完整性和有效性,3. 验证需求的完整性和有效性 只有在用户的密切合作下才能完成。只有当用户有某种工作着的软件系统可以实际使用和评价时，才能完整确切地提出他们的需要。用户通过试用原型系统，也能获得许多宝贵的经验，从而可以提出更符合实际的要求。3.8.3 用于需求分析的软件工具这类软件工具应该满足下列要求：(1) 必须有形式化的语法(或表)，因此可以用计算机自动处理使用这种语法说明的内容；(2) 使用这个软件工具能够导出详细的文档；(3) 必须提供分析(测试)规格说明书的不一致性和冗余性的手段，并且应该能够产生一组报告指明对完整性分析的结果；(4) 使用这个软件工具之后，应该能够改进通

30、信状况。,理想的做法,下面的需求描述正确吗？ 在用户每次存钱的时候系统将进行信用检查。 下面的需求描述是无歧义的吗？如果用户试图透支，系统将采取适当的行动。下面的两个需求描述中哪一个难以验证？ 系统将在 20 秒内响应所有有效的请求。 - 如果用户试图透支，系统将采取适当的行动。下面的两个需求描述是否有矛盾？- 系统允许立即使用所存的资金。- 只有在手工验证所存资金后，系统才能允许使用。,需求描述示例, 举例 如果可能的话，应当根据图书编号的列表在线确认所输入的图书编号。 问题“如果可能的话”意味着什么？ “应当”是否精确？改正？ 系统必须根据在线的图书编号列表确认所输入的图书编号。如果在图书

31、编号列表中查不到该图书的编号，或者当进行图书编号确 认时图书编号列表不可访问，系统必须显示一个出错信息并且拒 绝预订。,需求描述示例, 举例 1,产品必须在固定的时间间隔内提供状态信息，并且每次时间间隔不得小于 60 秒。,?,?,?,?, 问题,- 上述需求描述有什么缺陷？ - 如何改正？,46,需求描述示例与改正, 改正,后台任务管理器应该在用户界面的指定区域显示状态信息。 （1）在后台任务进程启动之后，消息必须每隔 6010 秒更新一 次，并且保持连续的可见性。,（2）如果正在正常处理后台任务进程，那么后台任务管理器必须显示后台任务进程已完成的百分比。,（3）当完成后台任务时，后台任务管

32、理器必须显示一个“已完 成”的信息。,（4）如果后台任务中止执行，那么后台任务管理器必须显示一 个出错信息。,47,传统软件工程方法学使用结构化分析技术，完成分析用户需求的工作。需求分析是发现、求精、建模、规格说明和复审的过程。第一步是进一步了解用户当前所处的情况，发现用户所面临的问题和对目标系统的基本需求；接下来应该与用户深入交流，对用户的基本需求反复细化逐步求精，以得出对目标系统的完整、准确和具体的需求。 具体地说，应该确定系统必须具有的功能、性能、可靠性和可用性，必须实现的出错处理需求、接口需求和逆向需求，必须满足的约束条件，并且预测系统的发展前景。,3.9 小结,为了详细地了解并正确地

33、理解用户的需求，必须使用适当方法与用户沟通。 访谈是与用户通信的历史悠久的技术，至今仍被许多系统分析员采用。从可行性研究阶段得到的数据流图出发， 在用户的协助下面向数据流自顶向下逐步求精，也是与用户沟通获取需求的一个有效的方法。 为了促使用户与分析员齐心协力共同分析需求，人们研究出一种面向团队的需求收集法，称为简易的应用规格说明技术，现在这种技术已经成为信息系统领域使用的主流技术。 实践表明，快速建立软件原型是最准确、最有效和最强大的需求分析技术。 为了更好地理解问题，人们常常采用建立模型的方法，结构化分析实质上就是一种建模活动，在需求分析阶段通常建立数据模型、功能模型和行为模型。,在需求分析

34、阶段还应该写出软件需求规格说明书，经过严格评审并得到用户确认之后，作为这个阶段的最终成果。通常主要从一致性、完整性、现实性和有效性等4个方面复审软件需求规格说明书。 多数人习惯于使用实体-联系图建立数据模型，使用数据流图建立功能模型，使用状态图建立行为模型。读者应该掌握这些图形的基本符号，并能正确地使用这些符号建立软件系统的模型。 为了提高可理解性，还可以用层次方框图或Warnier图等图形工具辅助描绘系统中的数据结构。 概括地说，任何一个计算机系统的基本功能都是把输入数据转变成输出信息，算法定义了转变的规则。因此，没有对算法的了解就不能确切知道系统的功能。IPO图是描述算法的有效工具。,3-

35、1 为什么要进行需求分析?通常对软件系统有哪些需求?3-2 怎样与用户有效地沟通以获取用户的真实需求?3-3 银行计算机储蓄系统的工作过程大致如下：储户填写的存款单或取款单由业务员键入系统，如果是存款则系统记录存款人姓名、住址(或电话号码)、身份证号码、存款类型、存款日期、到期日期、利率及密码(可选)等信息，并印出存单给储户；如果是取款而且存款时留有密码，则系统首先核对储户密码，若密码正确或存款时未留密码，则系统计算利息并印出利息清单给储户。,习题,请用数据流图描绘本系统的功能，并用实体-联系图描绘系统中的数据对象。3-4 分析习题2第3题所述的机票预订系统。请用实体-联系图描绘本系统中的数据

36、对象并用数据流图描绘本系统的功能。3-5 分析习题2第4题所述的患者监护系统。请用实体-联系图描绘本系统中的数据对象并用数据流图描绘本系统的功能，画出本系统的顶层IPO图。,3-6 复印机的工作过程大致如下：未接到复印命令时处于闲置状态，一旦接到复印命令则进入复印状态，完成一个复印命令规定的工作后又回到闲置状态，等待下一个复印命令；如果执行复印命令时发现没纸，则进入缺纸状态，发出警告，等待装纸，装满纸后进入闲置状态，准备接收复印命令；如果复印时发生卡纸故障，则进入卡纸状态，发出警告等待维修人员来排除故障，故障排除后回到闲置状态。请用状态转换图描绘复印机的行为。,10月10日习题：,3-3 银行计算机储蓄系统的工作过程大致如下：储户填写的存款单或取款单由业务员键入系统，如果是存款则系统记录存款人姓名、住址(或电话号码)、身份证号码、存款类型、存款日期、到期日期、利率及密码(可选)等信息，并印出存单给储户；如果是取款而且存款时留有密码，则系统首先核对储户密码，若密码正确或存款时未留密码，则系统计算利息并印出利息清单给储户。 请用实体-联系图描绘本系统中的数据对象并用数据流图、数据字典描绘本系统的功能。,