• / 129
  • 下载费用:10 金币  

第四章 需求分析.ppt

关 键 词:
第四章 需求分析.ppt
资源描述:
第四章 需求分析,如何定义系统需求? 如何识别、获取需求?你能够采取何种手段与用户进行交流沟通? 何为需求建模?你如何理解模型与建模?,,,,软件需求分析:“做什么?”,需求分析的过程是开发人员与用户共同协商,准确地定义未来系统的目标,确定为了满足用户的需求系统必须做什么。并且使用软件开发人员和用户都能理解的语言准确地表达出来,即用 规范的形式准确地表达用户的需求。,软件需求重要性例子,☻“喂,是Jack吗?我是人力资源部的Tom,我们在使用你编写的职员系统时遇到一个问题,一个职员想把她的名字改成Sparkle Starlight,而系统不允许,你能帮帮忙吗?” “她嫁给了一个姓Starlight的人吗?”Jack问道。 ☻“不,她没有结婚,而仅仅是要更改她的名字,”Tom回答,“就是这问题,好象我们只能在婚姻状况改变时才能更改姓名。” “当然这样,我从没想到谁会莫名其妙地更改姓名,我也不记得你曾告诉我系统需要处理这样的事情。”Jack说。 ☻ Tom说:“我想你当然知道每个人只要愿意都可以随时合法更改其姓名。但不管怎样,你在本周五之前解决这问题,否则Sparkle不能支付她的帐单。” “这不是我的错!我现在正忙着做一个新的系统,还要做一些别的需求变更请求。很抱歉,只能下周才能修改。”……,故事带给我们的启示……,影响:作为客户,很恼火,因为软件系统不能进行一项基本的操作。哪怕开发者给其解决了,也不会感谢他。作为开发者,也很烦人,迫使你增加了当前的工作,又要你优先处理。 原因:由于收集、编写、协商、修改需求过程的手续或方法失误带来的。这里是非正式信息的收集、未确定或不明确的功能、未发现或未经交流的假设、不完善的需求文档,以及突发的需求变更过程所造成的。 解决办法:重视需求分析,派经验丰富的人员做,最大程度的减少类似情况发生。,需求分析的特点,老问题: ☻问题的复杂性 ☻交流障碍(讲究技巧和原则) ☻不完备性和不一致性 ☻需求易变性(动态性),派经验丰富的人去干!,系统分析员,软件需求的任务 ——理解、分解、表达、评审,1.问题识别:双方确定问题的综合需求。 ☻功能需求:系统必须做什么? ☻性能需求 :做得怎样? 例:response time , memory , back-up memory , …… ☻环境需求 :运行环境、软硬件配置等。 ☻用户界面需求 ☻可靠性、安全性、保密性、可移植性和可维护性等方面的需求。 ☻将来可能提出的要求,共同理解!,软件需求的任务,2.分析与综合:导出软件的逻辑模型。对获取的需求进行一致性的分析检查,在分析、综合中逐步细化软件功能,划分成各个子功能。也对数据域进行分解,分配到各个子功能上,并用图文结合的形式,建立起新系统的逻辑模型。,软件需求的任务,3.编写文档: ☻编写需求说明书 ☻编写初步用户使用手册 ☻编写确认测试计划☻修改完善项目开发计划,需求文档,软件需求的任务,验证需求的一致性 验证需求的完整性 验证需求的现实性 验证需求的有效性,方法:  人工审查  开发原型系统-探索型 使用软件工具—— 完整性、一致性,,基线,4.技术审查和管理复审,软件需求分析的原则 需要能够表达和理解问题的信息域和功能域信息流:数据和控制通过一个系统时的变化方式。两个功能之间的数据/控制传递就确定了功能间的接口。 信息内容:单个数据或控制对象,它们构成了某个更大的由软件变换生成的信息的集合。信息结构:各种数据和控制项的内部组织。 描述作为外部事件结果的软件行为,建立行为模型 对描述信息、功能和行为的模型进行分解,用层次的方式展示细节,需求分析的步骤,需求获取 需求提炼:分析建模(导出软件逻辑模型) 需求描述:编写 需求验证,需求获取的目的 清楚地理解所要解决的问题 完整地获取用户需求 学习用户的有关业务知识,在用户帮助下了解用户的软件或子系统业务流程,结合软件开发和应用的经验提出新的用户需求。,方法:进行调查研究 调查研究的目的:是了解用户的真正需要 调查研究的方法 访谈:正式访谈和非正式访谈。 分发调查表。 开会—讨论—确认的方法。,建立分析小组领域专家: 主角系统分析员:导演,某出版社系统调查表,某出版社系统调查表,需求获取的内容,1.用户需求分类 (1)功能性需求: 定义了系统做什么(描述系统必须支持的功能和过程) (2)非功能性需求(技术需求):定义了系统工作时的特性 (描述操作环境和性能目标),2. 两类需求包括的内容,(1) 功能 (2) 性能 (3) 环境 (4) 界面 (5) 用户或人的因素 (6) 文档 (7) 数据 (8) 资源 (9) 安全保密 (10)软件成本消耗与开发进度 (11)质量保证,系统做什么?系统何时做什么?系统何时及如何修改或升级?,软件开发的技术性指标。例如:存储容量限制、执行速度、相应时间、吞吐量,硬件:机型、外设、接口、地点、分布、温度、湿度、磁场干扰等。软件:操作系统、网络、数据库,有来自其它系统的输入吗?到自其它系统的输出吗?对数据格式有规定吗? 对数据存储介质有规定吗?,用户类型?各种用户熟练程度?需受何种训练?用户理解、使用系统的难度?用户错误操作系统的可能性?,需哪些文档、针对哪些读者,输入、输出数据的格式?接收、发送数据的频率?数据的准确性和精度?数据流量?数据需保持的时间?,软件运行时所需的数据、软件。内存空间等资源。软件开发、维护所需的人力、支撑软件、开发设备等,需对访问系统或系统信息加以控 制吗?如何隔离用户之间的数据?用户程序如何与其它程序和操作?系统隔离?系统备份要求?,开发有规定的时间表吗?软硬件投资有无限制?,系统的可靠性要求?系统必须监测和隔离错误吗?规定系统平均出错时间?出错后,重启系统允许的时间?系统变化如何反映到设计中?维护是否包括对系统的改进?系统的可移植性?,,分析和描述系统的逻辑模型1. 建立起目标系统的逻辑模型2. 沿数据流图回溯,【例】某高校医疗费管理系统,医疗费:校内门诊费、校外门诊费、住院费、子女医疗费。要求数据库中存放每个职工的职工号、姓名、所属部门。 报销时填写所属部门、职工号、姓名、日期、医疗费种类和数额。 该校规定,每年每个职工的医疗费报销有限额(如480元),限额在年初时确定,每个职工一年内报销的医疗费不超过限额时可全部报销;超过限额时,超出部分只可报销90%。职工子女的医疗费也有限额(如240元)。 医疗费管理系统每天记录当天报销的若干职工或职工子女的医疗费的类别、金额。让系统自动结账、统计当天报销的医疗费总额,供出纳员核对。每笔账要保存备查,每天所报销的费用要和各个职工已报销的金额累计起来,以检查哪些职工已超额。 系统要设计适当的查询功能。年终结算、下一年度开始时,要对数据库文件进行初始化,职工医疗费余额累加到下一年度的余额中。,需求分析的方法,功能分解法:系统=功能+子功能+功能接口。过程抽象观点,很难与软件设计明确分离。基点放在功能上,不稳定,难以适用需求的变化。功能框图,层次方框图: 用树形结构的一系列多层次的矩形框描绘数据的层次结构。,产 品,硬 件,软 件,服 务,,,,处理机,存储器,外部设备,,,,系统软件,应用软件,,,软件服务,硬件维修,培训,,,,操作系统,编译程序,软件工具,,,,,,注意:层次方框图即可以表示数据的层次结构,也可以表示程序的层次结构,,需求分析的方法,结构化分析方法:由数据流和数据字典构成,适于数据处理领域问题。但该方法的一个难点是确定数据流之间的变换,而且数据字典的规模也是一个问题,对数据结构的强调很少。,数据流图:描绘系统的逻辑模型,图中没有具体的物理元素,只是描绘信息在系统中流动和处理的情况。设计数据流图只需考虑系统必须完成的基本逻辑功能,完全不需要考虑如何具体的实现这些功能。,结构化分析方法中使用的工具主要包括:数据流图、数据字典、结构化英语、判定表和判定树。其中数据流图用以表达系统内数据的运动情况;数据词典用以定义系统中的数据;结构化语言、判定表和判定树都是用以描述数据流的加工的工具。,结构化分析的组成结构 数据字典(DD):模型核心(中心库) E-R图(ERD):数据建模的基础 数据流图(DFD) 指明数据在系统中移动时如何被变换; 描述对数据流进行变换的功能;DFD中每个功能的描述包含在加工规约。 状态变迁图(STD)指明作为外部事件的结果,系统将如何动作。,将分析模型转换为软件设计,,,数据 字典,,,,数据 流图,E-R图,状态变迁图,加,工,规,约,控制规约,数,据,对,描述,象,,,,,,数 据 设 计,体系结构设计,接口设计,过程设计,,,,,,,,,,,,,,分析模型,设计模型,,结构化分析方法(SA方法)--面向数据流自顶向下逐步求精进行需求分析的方法。,沿数据流图回朔,用户复查,细化数据流图,修正开发计划,书写文档,,审 查和复审,,,分析过程,自顶而下逐层分解的分析策略从系统的基本模型(把整个系统看成一个加工)开始,逐层地对系统进行分解。每分解一次,加工的数据量就多一些,每个加工的的功能也要更具体一些。继续重复这种分解,直到所有的加工都足够简单,不必再分解为止。通常把不需要再分解的加工称为“基本加工”,把这种分解方法称为“自顶而下,逐层细化”。,数据流图,1. 符号(四种基本符号),,,数据的源点或终点,,,数据处理,,,,,,数据存储,,数据流,,一些附加符号,* 表示数据流之间是“与”关系(同时存在) + 表示数据流之间是“或”关系 ⊕ 表示只能从几个数据流中选一个(互斥关系),描述银行取款过程的数据流图,3、画数据流图的步骤,画顶层数据流图 画分层数据流图 画总的数据流图,,,购书单,教材购销系统,,例:教材购销系统的数据流程图 (1)首先画出系统的输入输出,也就是画出它的顶层数据流图。,,,学生,领书单,,缺书单,,,,进书通知,书库保 管员,购书单,缺书单,销售 教材,采购 教材,,,1,2,,,(2)画出系统的内部,即画出下一层的数据流图。,,,,,,,,,,教材存量表,,学 生,F1,,,,,缺书登记表,F2,,,,书 库 保 管 员,进书通知,,教材入 库信息,,领书单,,,1.2,(3)分解上层图中的加工,画出下层数据流图。,,,,,,无效 书单,,,,,,教材存量表,F1,开发票,,,,,F2,缺书登记表,,,,学生,,,,,各班学生用书表,F3,,,,,售书登记表,F4,1.1,,,,审查 有效性,1.3,,,,登记并 开领书单,,学生,1.5,,,,补售 教材,1.4,,,,登记缺书,,购书单,,,,发票,领书单,有效 购书单,,,,,,,,,,,,,教材入库信息,按书号 汇总缺书,2.1,2.3,第三层DFD (1层) 采购子系统(2.0),,,,,,,,,,待购教材表,F5,,,,,教材一览表,F6,,,,书库 保 管 员,进书通知,,,,,,,,教材存量表,F1,2.2,,,,按出版社 统计缺书,修改教材库 存和待购量,,,,,F2,缺书登记表,,,,,,,,,,,,缺 书 单,教材入库信息,,,,招聘考试管理系统数据流图,招聘考试管理系统数据流图,,仓 库 管理员,定货 系统,采购员,,,,,,D1: 库存清单,仓 库 管理员,1 处理 事务,2 产生 报表,,,采购员,,,,,D2: 定货信息,,,顶层数据流图,分层数据流图1,事务,定货报表,事务,定货报表,定货信息,定货信息,库存清单,,仓 库 管理员,1.1 接收 事务,1.2 更新库 存清单,,,1.3 处理 定货,,2 产生 报表,采购员,,,,D1: 库存清单,,,,,D2: 定货信息,,,,事务,事务,库存信息,定货信息,定货信息,定货报表,为数据流(或数据存储)命名为处理命名,库存清单,分层数据流图2,43,画分层DFD图的基本原则,加工分解的原则自然性均匀性分解度,数据守恒与数据封闭原则,,,,子图与父图的“平衡”,合理使用文件,检查和修改数据流图的原则,数据流图上所有图形符号只限于前述四种基本图形元素 数据流图的主图必须包括前述四种基本元素,缺一不可 数据流图的主图上的数据流必须封闭在外部实体之间 每个加工至少有一个输入数据流和一个输出数据流 在数据流图中,需按层给加工框编号。编号表明该加工所处层次及上下层的亲子关系 规定任何一个数据流子图必须与它上一层的一个加工对应,两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡 可以在数据流图中加入物质流,帮助用户理解数据流图 图上每个元素都必须有名字 数据流图中不可夹带控制流 初画时可以忽略琐碎的细节,以集中精力于主要数据流,画数据流时需注意的问题,不要把控制流作为数据流如:下图中读下张卡属于控制流,不应画出。不要标出激发条件,,,合法卡片,卡片信息,读入 卡片,卡片校验,,,读下张卡,,,,工资单,工资率,计算工资,,,每月1号,,职工档案,,,,分层DFD图的改进,DFD图必须经过反复修改,才能获得最终的目标系统的逻辑模型(目标系统的DFD图)。可从以下方面考虑DFD图的改进:1、检查数据流的正确性① 数据守恒② 子图、父图的平衡③ 文件使用是否合理。特别注意输入/出文件的数据流。2、改进DFD图的易理解性① 简化加工之间的联系(加工间的数据流越少,独立性越强,易理解性越好)。② 改进分解的均匀性。③ 适当命名(各成分名称无二义性,准确、具体)。,46,,,,绘制数据流图的几个问题,47,合理地命名:数据流程图中对每一个元素都要命名,恰当地命名有助于数据流程图的理解与阅读。命名原则: 为了避免引起错觉,为每个元素所取的名字要能反映该元素的整体性内容,而不只是它的部分内容。 每个元素的名字都能有唯一地标识该元素。 避免用空洞的名字,要具体的含义。 如果发现难以为某个数据流或加工命名时,这往往是数据流图分解不当的征兆,可重新分解。,绘制数据流图的几个问题(二),48,编号的设置 子图的编号是父图相应的加工的编号。 子图中加工编号由父图号、小数点与局部号组成。,绘制数据流图的几个问题(三),父图-子图平衡:模型分解时必须保持父图的输入输出数据流和子图输入输出数据流相同。,49,父图-子图平衡,50,父图-子图平衡,51,父图-子图平衡补充说明,52,借助数据字典判断:,绘制数据流图的几个问题(三),53,局部数据存储局部数据存储不是父图中相应加工的外部接口,而只是本图中某些加工之间的数据接口。在子图中出现的数据存贮,可以不出现在父图中,画父图时只需画出处理逻辑之间的联系,不必画出各个处理逻辑内部的细节,有助于实现信息隐蔽。,,库存记录,,,,局部数据存储的使用,出现在加工之间的界面时,才画出来。,54,,绘制数据流图的几个问题(四),55,加工的分解与分细的程度 为提高数据流图的易理解性,注意合理分解。分得太细,则使得层次太多;分得太快,则达不到分层的目的。 从管理的层次结构原理来看,一个领导人管理他的下属一般不超过7人,故在分解一层时不宜超过7个加工。 一个加工分解到基本加工为止。基本加工:能表达系统所有的逻辑功能和必要的数据输入与输出,这些功能与数据的描述能使用户清楚地理解,并且还能使以后的系统设计人员看到每一个加工,有一个明确的概念,并据此能设计程序模块实现这些加工。 注意子加工的独立性和匀称性。,数据流图实例 功能描述: 对考生送来的报名单进行检查 合格的报名单编好序号后将准考证返送给考生,并将汇总后的考生名单送给阅卷站 对阅卷站送来的成绩进行检查,并根据考试中心制定的合格标准审定合格者 制定考生通知单(含成绩合格、不合格的标志)发送给考生 按地区进行成绩分类统计和试题难度分析,产生统计分析表汇报给考试中心,56,考务处理系统顶层数据流图,57,考务系统0层数据流图,58,考务系统一层数据流图 ——审核报名单子系统,59,考务系统一层数据流图 ——统计成绩子系统,60,,检查 成绩清单,,2.1,,审定 合格者,2.2,,,考生名册,,,正确 成绩清单,,制作 通知单,2.3,,分析 统计成绩,2.4,,分析 试题难度,2.5,试题得分清单,,,,,,考生 通知单,难度 分析表,合格 标准,,,分类 统计表,,,,成绩清单,,错误 成绩清单,,经审定的 成绩清单,数据流图的优缺点,61,☻总体概念强,每一层都明确强调“干什么”,“需要什么”,“给出什么”。 ☻可以反映出数据的流向和处理过程。 ☻由于自顶向下分析,容易及早发现系统各部分的逻辑错误,也容易修正。 ☻容易与计算机处理相对照。 ☻不直观,一般都要在作业流程分析的基础上加以概括、抽象、修正来得到。 ☻如果没有计算机系统帮助的话,人工绘制太麻烦,工作量较大。,与其它流程图的比较,62,与系统流程图的区别 系统流程图中不仅有数据流,还有物质流、资金流。 数据流程图仅以数据流的形态来反映一个组织中整个管理业务的过程。 与程序结构图的区别 程序结构图反映模块之间的控制关系,以及模块之间的调用关系,而数据流图则不反映控制关系、调用关系、控制流,只画数据流。,63,与程序流程图的区别 程序流程图中的处理框之间有严格的时间上的顺序,也就先执行哪个处理框,起始点以及终止点等。而数据流程图只反映数据的流向、加工和必要的数据存储,它不反映加工的先后的时间顺序。,课堂作业,64,,,假如要分析一家公司的营销系统。其采购部门每天须要按销售部门提供的定货单(须定的货物)向供应商采购货物。每种货物的数量都存放在数据存储货物库存中,销售和采购使每种货物数量发生的变化能够在此数据存储中及时被反映出来。具体功能如下: 1、销售部门根据顾客的定货单来确定订货,若可发货则产生发货单,并修改相应库存、制订报表,否则登记缺货,并报采购部门; 2、采购部门在接到消息后按照货物进行汇总,并确定订货单,进行购货,货物购进后修改库存并将到货通知发送销售部门进行发货。,数据字典,数据字典(Data Dictionary ,DD)是对实体-关系图、状态转换图和数据流图中出现的所有数据对象、属性、关系、状态、数据流、文件、处理等元素的定义的集合。数据字典的内容 1. 数据项 2. 数据流 3. 数据存储 4. 加工处理 5. 外部项,(1)数据流词条描述,数据流名: 说明:简要介绍作用即它产生的原因和结果 数据流来源:来自何方 数据流去向:去向何处 数据流组成:数据结构 数据量流通量:数据量,流通量,数据流条目说明举例,数据流名:发票 别名: 无 说明: 学生购书时填写的项目 数据流来源: 学生 数据流去向: 加工1“审查并开发票” 数据流组成: (学号)+姓名+{书号+数量} 数据流量:1000次/周 高峰值:开学期间1000次/天,(2)数据元素词条描述,数据元素名: 类型:数字(离散值,连续值),文字(编码类型) 长度: 取值范围: 相关的数据元素及数据结构:,数据元素条目说明举例,数据项名:货物编号别名:G-No,G-num简述:本公司的所有货物的编号类型:字符串长度:10取值范围及含义:第1位:[J|G] (进口/国产) 第2∼4位:LB01 LB29 (类别)第5∼7位:“A00”“A99” (规格)第8∼10位:“001”“999”(品名编号),(3)数据文件词条描述,数据文件名: 简述:存放的是什么数据 输入数据: 输出数据: 数据文件组成:数据结构 存储方式:顺序,直接,关键码 存取频率:,数据文件条目说明举例,文件名:库存记录 别名: 无 简述:存放库存所有可供货物的信息 组成:货物名称+编号+生产厂家+单价+库存量 组织方式:索引文件,以货物编号为 关键字 查询要求:要求能够立即查询,(4)加工逻辑词条描述,加工名: 加工编号:反映该加工的层次 简要描述:加工逻辑及功能简述 输入数据流: 输出数据流: 加工逻辑:简述加工程序,加工顺序,加工逻辑条目描述举例,加工逻辑名:查阅库存编号:1.2激活条件:接收到合格订单时优先级:普通输入:合格订单输出:可供货订单、缺货订单加工逻辑:P32,(5)源点及汇(终)点词条描述,名称:外部实体名 简要描述:什么外部实体 有关数据流: 数目:,数据字典使用的符号,= 表示“等价于”或“定义为” + 连接 [ ],| 表示“或”,用“|”分隔,表示可任选其中某一项 { } 表示“重复” ( ) 表示“可选”,用“,”号隔开1{A} 表示 A 的内容至少要出现 1 次。 {B} 表示 B 的内容允许重复 0 至任意次。如: 成绩单=学号+姓名+1{课程名+成绩}3 也可写为 成绩单=学号+姓名+ {课程名+成绩},数据字典与图形工具, 应遵守以下约定: 可以用图形工具描述的尽量用图形描述。 有关数据的组成在数据字典中描述。 有关数据的加工细节在数据字典中描述。 编写数据字典时不能有遗漏和重复,要避免不一致性。 数据字典中的条目的排列要有一定规律,方便查阅。如按英文字母表顺序或按汉字笔画顺序排列或按功能分类等; 数据字典的要易于更新修改。,数据字典与数据流图等图形工具应相辅相成、互相配合,既要互相补充又要避免冗余。,【例】写出招聘考试成绩统计系统的数据字典,1、数据项定义: 考生=准考证号+姓名+性别+出生年月+地址+1{课程名+成绩}3+总分+名次+专业代号+录用否+录用单位考生文件分两种:一种按准考证号码次序排列,另一种按考生成绩总分由高到低排列。专业代号=[1=法律/ 2=行政学/ 3=财经学]录用通知书=准考证号+专业+姓名+录用单位考生成绩单=准考证号+姓名+专业+1{课程名+成绩}3+总分 2、 处理算法: 排序:(1)三个专业的考生分别按总分由高到低的次序排序,输出成绩单,供录用参考。(2)按准考证号的顺序将考生成绩单打印出来,一份给招干委员会留底,另一份发给考生。录用原则:各专业按考生成绩总分从高分到低分的次序录用,总分相同时专业课成绩高的优先。,【例】写出医疗费管理系统数据字典,1、数据项 职工=部门名+职工号+姓名 当日明细账=报销日期+部门名+职工号+姓名+校外门诊费+校内门诊费+住院费+总额+余额+子女医疗费+子女总额医疗费总账=部门名+职工号+姓名+校外门诊费+校内门诊费+住院费+总额+余额+子女医疗费+子女总额 余额=限额-总额(小于 0 时,取 为0) 医疗费明细账={当日明细账} 2、操作说明 (1)输入数据时只需输入职工号,就可在职工库中查找出该职工所属部门名及姓名,显示在屏幕上供核对,并将医疗费总账中该职工今年内今日前已报销的医疗费总额和余额显示出来。 (2)输入当日报销的校外门诊费、校内门诊费、住院费、子女医疗费后,计算机自动算出该职工的医疗费总额和余额。 (3)核对:算出当日所有职工报销的各类医疗费的分类总和及所有总和,供出纳员核对。若发现错误应进入“修改”模块进行修改。核对正确后可进入“累加”模块。 (4)累加:把职工当天报销的各类医疗费与以前报销的分类累加并算出总额。,用于写加工逻辑说明的工具,• 结构化语言 • 判定表 • 判定树,(1)结构化语言,结构化英语的词汇表由英语命令动词数据词典中定义的名字有限的自定义词逻辑关系词 IF_THEN_ELSE、CASE_OF 、 WHILE_DO、REPEAT_UNTIL等组成。,分层 (1)外层:用来描述控制结构,采用简单、选择、重复三种基本结构 A、顺序结构:又叫简单结构,它尽量要采取简单语句避免复合语句。 B、选择结构:又叫判定结构,一般用if_then_else或case_of 结构 C、重复结构:一般用while_do(do_while)语句或repeat_until语句 (2)内层:一般采用祈使语句的自然语言短语,使用数据字典中的名词和有限的自定义词,其动词含义要具体,尽量不用形容词和副词来修饰,还可以使用一些简单的算术运算和逻辑运算符号。,商店业务处理系统中“检查发货单”,IF 发货单金额超过$500 THENIF 欠款超过了60天 THEN在偿还欠款前不予批准ELSE (欠款未超期)发批准书,发货单ENDIF ELSE (发货单金额未超过$500)IF 欠款超过60天 THEN发批准书,发货单及赊欠报告 ELSE (欠款未超期)发批准书,发货单ENDIF ENDIF,(2)判定表,如果数据流图的加工需要依赖于多个逻辑条件的取值,使用判定表来描述比较合适,以“检查发货单”为例,例:优惠折扣,某商业公司的销售策略规定:不同的购货量、不同的顾客可以享受不同的优惠。具体办法是: 年购货额在5万元以上且最近三个月无欠款的顾客可享受15%的折扣; 近三个月有欠款,但是本公司十年以上的老顾客,可享受10%的折扣; 若不是老顾客,只有5%的折扣; 年购货额在5万元以下无折扣。,举例:优惠折扣,1. 识别判断条件,并列出所有的条件及条件值; C1(交易额)=5000元、5000元 C2(信誉好)近三个月无欠款、有欠款 C3(老顾客)交易10年以上、10 年以下 2. 建立条件组合数 三种条件,每种各有二种情况,共有8种组合 3. 识别每个独立步骤 A1:折扣 15% A2:折扣 10% A3:折扣 5% A4:无折扣,4.设计判断表格,举例:优惠折扣,,,,5. 合并与简化,举例:优惠折扣,,5. 合并与简化,,举例:优惠折扣,(3)判定树,判定树也是用来表达加工逻辑的一种工具。有时侯它比判定表更直观。,,例:优惠折扣的判定树,三种表达工具的比较,(1)从工具的难易程度讲,判定树最容易,而判定表难度较高。 (2)对于逻辑验证,判定表最好,而判定树较差。 (3)对于直观表达逻辑结构,判定树最好,而判定表最差。 (4)作为程序设计说明,结构化语言最好,判定树最差。 (5)对于机器可读性,结构化语言最好,判定树最差。 (6)对于可修改性,结构化语言最好,而判定表的可修改性是最低。,综上所述,可以得出的结论: 对于一个不太复杂的判断逻辑,即条件只有2---3个,条件组合及行动在10---15个之间,使用决策树最好。 对于一个复杂的判断逻辑(条件多,组合多,相应的动作也多),使用决策表最好。 对于一个处理逻辑既包含了一般的顺序执行动作,又包含了判断或循环逻辑,则使用结构化语言最好。,三种表达工具的比较,练 习,交易所规定给经纪人的手续费计算方法如下: 总手续=基本手续费+交易中的每股价格和股数有关的附加手续费 如交易额少于1000元,则基本手续费为交易额的8.4%; 如交易额在1000-10000元之间,则基本手续费为交易额的5%+34; 如交易额大于10000元,则基本手续费为交易额的4%+134; 当每股售价低于14元时,附加手续费为基本手续费的5%(买入卖出数是100的倍数),否则附加手续费为基本手续费的9%(不是100的倍数);,IPO 图,输入/处理/输出(Input Process Output )图的简称。 【例】招聘考试成绩管理系统的 IPO 图。,,实体-关系图,,概念模型和规范化,用户的数据要求----需要哪些数据,数据之间有哪些联系,数据本身有哪些性质,数据的结构 等)。用户的处理要求---对数据进行哪些处理,每个处理的逻辑功能。概念性模型(信息模型)---一种面向问题的数据模型,是按照用户的观点来对数据和信息建模。表示概念性数据模型的最常用方法是实体-联系方法,采用用 ER图的方式,这种表示又称为ER模型。,E--R模型,实体: 客观世界中存在的且可区分的事物。联系: 客观事物之间的联系(三类--1:1,1:N,M:N)属性: 实体或联系所具有的性质。,验证软件需求,从哪几个方面验证软件需求的正确性(四个方面),一致性: 任何一条需求不能和其他需求互相矛盾。 完整性: 规格说明书应该包括用户需要的每一个功能和性能。 现实性: 指定的需求是用现有的硬件、软件技术可以实现的。 有效性: 需求是正确有效的,确实能解决用户面对的问题。,验证软件需求的方法,一致性:人工审查---》形式化描述软件需求,软件工具自动验证。 现实性: 参考以往的开发经验,分析,仿真或模拟 完整性和一致性:原型系统,注意事项,在需求分析阶段,系统分析员的主要焦点是 “做什么(what)” ,不是 “怎样做(how)”,注意事项,在需求分析时要注意用户对软件开发的了解程度。避免造成两种极端认识。,需求的变动或新增是一个极为普遍的问题,既然普遍,所以软件开发人员不仅应该在心理上接受这种变动,还应该在需求分析时积极的发掘需求。,需求人员与用户广泛交流,从深度和广度挖掘可能的需求,并应形成规范的需求文档,经用户确认。,如果为写文档而写文档,不进行及时更新,甚至准备在软件开发完成后再补文档,这是绝对错误的观点。,可能错误,没有足够用户参与(类型、数量) 开发方与用户沟通可能处于劣势 不要锦上添花,画蛇添足 不要写的过于简练,过于模糊; 计划需求的时间少了,导致需求不完整,另外,要注意: 需求在签约前要与决策者沟通好; 到竞争对手那儿找不足 不要被过细的不成熟的细节影响 记下不明确的需求,约定期限明确,否则易遗漏,例1.“产品应在不少于每60秒的正常周期内提供状态信息” 这个需求是不完整的:状态信息是什么,如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分?状态信息间隔真的假定为不少于60秒?甚者每10年显示一条新的状态信息也可以?也许它的意图是消息间隔不应超过60秒,那么1毫秒是不是太短?“每”这个词导致了不确定性。问题的后果,就是需求的不可证实。 弥补缺陷,重写需求的一种方法:1、后台任务管理器因该以误差上下不超过10秒-60秒间隔,在用户界面的指定位置显示状态信息 2、如果后台进程处理正常,那么应该显示任务已完成的百分数/比 3、任务完成时,应显示相关的信息 4、后台任务出错应该显示错误信息 为了分别测试和追踪,我们可以将其分成多个需求。如果将几个需求串接在一节中,在构造和测试时就很容易漏掉一个。,例2.“产品应瞬间在显示和隐藏不可打印字符间切换” 计算机在瞬间不能做任何事,所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己?或者用户为了模仿更改要做一些动作?而且,在文档中改变显示的范围是多大:选中的文本,整个的文档,或其他的?这也是个模糊的问题。不可打印字符和隐藏字符一样吗?或者是一些属性标志或一些控制字符?问题的后果,就是需求的不可证实。 象这样编写需求也许更好一些:“用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换”。现在就很清楚,不可打印字符是HTML标记。由于没有定义触发条件,需求对设计没有约束力。只有设计人员选定了触发条件后,你才能编写测试验证触发的正确操作。,例3.“HTML分析器可以产生HTML标记错误报告,帮助HTML入门者快速解决错误”。单词“快速”使其模糊,没有加进错误报告的定义也使其不完整。我不知道,你怎么验证这个需求。找一个自称为HTML的入门者,看看能不能根据错误报告快速解决错误?试试这个:“HTML分析器可以产生一个错误报告,错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误,就不会产生错误报告”。现在我们知道了,什么会被加到出错报告中,但是出错报告是个什么样子,则留由设计人员决定。我们还指定了一个例外:如果没有发现错误,不产生错误报告。,例4.“如果可能,主管号码应通过联机校验,而不是通过主全体主管号码列表校验”。真感到绝望,什么是“如果可能”:如果技术上可行?如果主全体主管号码列表可以联机获得?要避免象“应该”的这类不确切的词。客户是需要这个功能性还是不需要。在一些需求说明书中,采用诸如:应,将,应该/将要等一些词描述优先级的细微差别。但我更喜欢用“应”清楚的说明需求的意图,指明优先级。这是修改后的:系统应校验输入的主管号码而不通过联机的主全体主管号码列表。如果在列表中没有发现主管号码,将会显示一条错误信息,也不接受指令。,在理解各个已完成的糟糕需求上,开发人员将会遇到的难题是:开发人员与客户将会在审核需求,未达成共识前发生激烈的争论。详细检查大的需求文档不是一件轻松的事情。有人做过,而且他们花在检查上的每一分钟都是值得的。相对于开发阶段和用户的抱怨电话,在这个阶段修补缺陷是便宜的.,,需求分析示例—教材购销管理系统(1),问题描述:学校教材科根据业务的需要,建立一个学校教材购销管理系统,提高教材采购、销售和信息管理的效率。,学生,,张秘书,,购书申请,,王会计,,李出纳,,赵保管,学生,购书证明,,购书申请,,购书申请,,,书,,2)去掉具体模型的非本质因素,抽象出当前系统的逻辑模型,1)通过对现实环境的调查研究,获得当前系统的具体模型,3)分析当前系统与目标系统的差别,建立目标系统的逻辑模型。,需求分析示例—教材购销管理系统(2),4)对目标系统进行补充和完善,并写出完整的需求说明。,5)对需求说明进行复审,直到确认文档齐全,并且符合用户的全部需求为止,需求分析示例—教材购销管理系统(3),,需求分析示例—教材购销管理系统(4),,1.1 审 查有效性,,1.2 开发票,,有效 购书单,,1.3 领书并 开领书单,,发票,,1.4 登记缺书,,1.5 补售教材,,,F2: 缺书登记表,,,学生,学生,,,无效书单,领书单,,,,,领书单,,,F3: 各班学生用书表,,F4: 售书登记表,,,,,,,补售书单,暂缺书单,采购,,3. 第三层DFD图—销售子系统,F1: 教材存量表,,需求分析示例—教材购销管理系统(5),,2.3 修改教材库存和待购量,,,2.1 按 书 号 汇总缺书,,,F2: 缺书登记表,销售 子系统,书库 保管员,,,,F1: 教材存量表,进书通知,3. 第三层DFD图—采购子系统,,2.2 按出版社 统计缺书,,,F5: 待购教材表,,,F6: 教材一览表,,进书通知,,,,,,,,需求分析示例—教材购销管理系统(6),数据字典(Data Directory-DD) 领书单 = 学院+专业+班级+学号+姓名+{书号+[书名]+数量}+日期 有效购书单 = 领书单 发票= 学号+姓名+{书号+[书名]+单价+数量+总价}+书费合计 教材存量表 = {书号+单价+数量} 暂缺书单 = 学号+姓名+ {书号+数量} 补售书单 = 学号+姓名+ {书号+数量},系统任务书的基本框架如下: (1)引言 包括编写目的,背景,参考资料。 (2)系统的目标及任务 包括系统建设目标,系统的主要任务,系统性能指标,系统标准化要求。 (3)系统的结构及功能 包括系统应用组成及结构,系统主要功能。 (4)系统的规模及进度要求 包括系统规模,系统研制进度,人员计划。 但是系统任务书只是这个软件项目的一个基本要求,针对具体情况,软件开发人员和需求分析人员就要联合对软件项目的细节进行具体分析,必要时还要进行实地调研,然后共同商讨写出系统的需求分析,需求分析的编写目的在于: a. 说明系统在军事方面、技术方面、经济方面和社会条件方面实现的可行性和必要性; b. 分析原系统(工作环境)现状,描述待开发系统的详细需求,提供用户和开发人员之间沟通的基础,提供项目设计的基本信息。,需求分析报告的基本框架如下: (1) 概述 包括 编写目的,背景,参考资料,术语及缩写词。 (2) 对现有系统的分析 (3)待开发系统的详细需求 包括 功能需求,使用范围,业务流程,用户界面,输出要求,故障处理。 (4)使用环境 包括 网络环境,硬件环境,软件环境,与其他系统的关系,安全与保密。 (5) 可行性分析 包括 技术可行性分析,经济可行性分析,人员可行性分析,影响待开发系统的主要因素。 (6)结论意见,系统总体方案基本框架包括: (1)引言 包括 :编写目的,背景,参考资料,术语及定义。 (2)项目概述 包括 : --项目的主要内容 --系统需求分析:①用户需求调查分析②现行系统的现状调查分析。 --系统功能:①系统的功能要求②系统主要技术性能。 --系统的数据要求:①基础数据②业务数据③交换数据④其它数据。 --系统的设计要求:①技术结构要求②系统划分及其接口要求③系统运行环境要求④系统标准化综合要求。 (3)实施总计划 包括 :进度,预算,问题和措施。,
展开阅读全文
  微传网所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
0条评论

还可以输入200字符

暂无评论,赶快抢占沙发吧。

关于本文
本文标题:第四章 需求分析.ppt
链接地址:https://www.weizhuannet.com/p-10071214.html
微传网是一个办公文档、学习资料下载的在线文档分享平台!

网站资源均来自网络,如有侵权,请联系客服删除!

 网站客服QQ:80879498  会员QQ群:727456886

copyright@ 2018-2028 微传网络工作室版权所有

     经营许可证编号:冀ICP备18006529号-1 ,公安局备案号:13028102000124

收起
展开