第3章-需求分析(4)

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,第三章 需求分析,第,3,章 需求分析,3.1,需求分析的,任务,3.2,与用户沟通,获取需求,的方法,3.3,分析建模与,规格说明,3.4,实体,-,联系图,3.5,数据规范化,3.6,状态转换图,3.7,其他图形工具,3.8,验证软件需求,3.9,小结,需求分析的,意义,软件需求的深入理解,是软件开发工作,获得成功的前提,条件，不论我们把设计和编码做得如何出色，不能真正,满足用户需求,的程序只会令用户失望，给开发带来烦恼。,需求分析是软件定义时期的最后一个阶段，它的基本任务,不是确定系统怎样完成,它的工作，,而是确定系统必须完成,哪些工作，也就是对目标系统提出,完整、准确、清晰、具体的要求。,并在需求分析阶段结束之前，由系统分析员写出,软件需求规格说明书,，以书面形式准确地描述软件需求。即：,-,准确地回答,“,系统必须做什么,?,”,。,在分析软件需求和书写软件需求规格说明书的过程中，,分析员和用户都起着关键的、必不可少的作用,。,什么是需求：,需求的概念,需求来源于用户的一些“需要”、“要求”,这些,“需要”被分析,、确认后,形成完整的文档,，该文档详细地说明了,产品“必须”或“应当”做什么,什么是需求：,需求的内容,功能：,系统必须提供的服务,性能：,系统必须满足的定时或容量约束，,e.g.,，速度（响应时间），信息量速率，磁盘容量，安全性等。,可靠性：,定量地指定系统的可靠性,比如银行、证券系统对可靠性要求极高，根本不允许有故障停机的时间；,机场雷达系统在一个月内不能出现,两次,以上故障。,技术性限制,比如用户指定平台、数据库、开发工具等,其它限制,经济、时间、法律,什么是需求：重要性,可行性分析不是已经弄清做什么了么？,可行性分析阶段已经粗略了解了用户的需求，甚至已经提出了一些可行的方案,但是，,可行性研究的基本目的,是用,较小的成本,在,较短的时间,内确定是否存在可行的方案。因此许多,细节被忽略,。,在系统开发前，还需要进一步确定,什么是需求：重要性,Brooks,在他,1987,年经典文章,“,No Silver Bullet”,中阐述了需求的重要性：,“开发软件系统最困难的部分就是,准确说明,开发什么,。最困难的,概念性工作,是编写出详细的需求,，包括所有,面向用户、面向机器和其它软件系统的接口,。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难”,什么是需求：重要性,例,1,：阿丽亚娜,5,型火箭首次发射失败,The reason: there was no discussion in the,requirements documents,of the ways in which the Ariane-5 trajectory would be different from Ariane-4.,什么是需求：了解客户,基本概念,“用户”,(,user,),是一种泛称，它可细分为,“,客户,”,(,customer,),“,最终用户,”,(,end user,),“,间接用户,”,(,或称为关系人,),掏钱买软件的用户称为客户,而真正操作软件的用户叫最终用户,客户与最终用户不一定是同一个人,什么是需求：了解客户,客户是掏钱的人，所以他是“上帝”,与客户打交道的主要目的是：,第一,获取需求,第二,签合同,什么是需求：了解客户,最终用户即使不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得,如果项目规模比较大，那么开发方与,最终用户,的来往就比较多,如从最终用户那里获取详细的需求，请最终用户试验软件，对最终用户进行培训,重视“间接用户”,例如：财务软件的销售必须得到财政部的批准，,杀毒软件必须得到公安部的认可，,医疗器械必须通过卫生部的批准,什么是需求：需求工程,需求工程,所有与需求相关的活动统称为需求工程,需求工程,需求开发,需求调查,需求分析,需求定义,需求管理,需求确认,需求跟踪,变更控制,什么是需求：需求工程,需求开发,需求调查：,通过,各种途径获取用户的需求,信息（原始材料）,需求分析：,对,各种需求信息进行分析,，,消除错误,，刻画细节,需求定义：,根据,需求调查和需求分析的结果,，进一步,定义准确无误的产品需求,，产生,需求规格说明书,。,设计人员将依据,需求规格说明书,开展系统设计工作,什么是需求：需求工程,需求管理,需求确认：,开发方和客户共同对需求,文档进行评审,，双方对需求,达成共识,后作出,书面承诺,，使需求文档具有商业,合同效果,需求跟踪：,比较需求文档与后续工作成果之间的对应关系，确保产品,依据需求文档进行开发,需求变更控制：,依据,规范处理需求变更,，防止需求变更失去控制而导致项目混乱,需求开发,需求调查,选定对象,：最终用户,补习领域知识,：,自学、请领域专家辅导、现场观察体验,根据,用户优先级确定需求的优先级,综合,考虑市场和技术的走向,需求开发,需求调查的,常用手段,用户访谈,：交谈、收集资料,用户故事,：用户描述一个使用场景,借助,图表,使用,原型,网络收集,用户需求,比如论坛,需求开发,需求记录的工具,文字说明,UML,模型,用例图,状态图,顺序图等,极限编程中的故事卡,传统方法中的,数据流图,层次方框图,IPO,图等,下订单,查询订单,取消订单,用户要求,需求开发,需求规格说明书,描述系统的,各项特性,完整、详细,对于,开发者,：,必须,很详细,，这样才好编程实现,不能有歧义,对于,用户,必须,好理解,，不能太技术化,法律,上,相当于是合同约定,应当,有验收标准,，比如通过,XXX,测试,需求管理：需求验证,验证的内容：,一致性：,各项需求之间无矛盾,完整性：,无遗漏,现实性：,可实现,有效性：,能解决用户的问题,验证的方法：,人工审查,软件工具,原型法,需求管理：需求确认,需求确认：,双方责任人对通过了正式技术评审的,需求规格说明书,作出承诺，具有商业合同的效果,需求承诺的“,八股文,”如下：,本,需求规格说明书,建立在,双方对需求的共同理解基础之上，,乙方同意后续的开发工作,根据该,需求规格说明书,开展,。如果需求发生变化，甲方将按照,“变更控制规程”执行,。乙方明白需求的变更将导致双方重新协商成本、资源和进度等,甲方签字,乙方签字,需求管理：需求跟踪,需求,跟踪,建立与维护,“,需求设计编程测试,”,之间的一致性，确保所有的工作成果符合用户需求,建立需求跟踪表格,保存了需求与,后继工作成果,的对应关系，,#,需求规格说明书,设计文档,代码,测试用例,1,标题，说明,标题，说明,代码名称，说明,用例名称，说明,2,.,.,.,.,需求管理：需求变更控制,基本流程：,变更申请评估,/,审批更改重新确认,策略：,如果需求变更带来的,好处,大于,坏处,，那么允许变更，但,必须按照已定义的变更规程执行,，以免变更失去控制,如果需求变更带来的坏处大于好处，那么拒绝变更，拒绝用户需要社交技巧,优先排序、分批实现,实践中的困难和对策,知识技能问题,“隔行如隔山”，需求分析员可能是用户所在专业的外行,对策：,补习应用域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。,如果可能的话，开发方最好请既懂软件又懂应用域知识的行家来帮忙,实践中的困难和对策,态度问题,开发人员习惯于被动地对待需求开发：,需求是用户的事情，不是我们的事情。如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，,应当由他们自己负责？,对策：,给具有错误观念的开发人员们洗脑：需求分析员的天职就是,在有限的时间内获取准确而细致的用户需求,，如果做不到就是失职，不要找借口,实践中的困难和对策,合作关系,用户经常不配合：,我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们不成？我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧,.,竞标项目尤为困难,：,用户未必会买你的产品，他不会投入很多精力来协助你搞,需求开发,对策：,出色的需求分析员不仅要有过硬的专业知识，还要,具备较强的交流、沟通能力,在开展需求开发之前，以,协议的方式确定合作关系,。“好话”和“丑话”都说在前头，这样能减少今后的摩擦。如果条件允许的话，开发方最好,为用户举办关于需求工程的培训,，这样的培训将使用户明白,需求的重要性以及忽视需求的危害性，,从而促使他们积极友善地参加需求工程中的各项活动,实践中的困难和对策,用户在需求工程中的“权利”,有权要求开发方,派遣资质合格的需求分析员,有权要求开发方,提供用户看得懂的需求文档,有权,审查需求文档,，并对有争议的需求作出决策。如果认为需求文档不能准确地反映用户真实的意愿，可以拒绝在需求文档上签字,如果用户想要变更需求，有权要求开发方对该,变更将产生的影响作出真实可信的评估，以便用户决定是否变更需求,实践中的困难和对策,用户在需求工程中的,“义务”,以积极友善的态度与,开发方交流、协作，,尽可能地为开发方人员提供工作和生活上的便利,乐意接受需求分析员的采访,，在不泄漏机密的前提下尽可能地回答需求分析员的问题,在不泄漏机密的前提下，,尽可能地向需求分析员提供与需求相关的材料,与需求分析员共同评审需求文档,，确保需求文档准确地反映用户真实的意愿,实践中的困难和对策,用户说不清楚需求,有些用户真的,不知道需求是什么,有些用户虽然心里明白，但却,说不清楚,比如买鞋子，很难用语言说清楚脚的大小和形状，必须要试穿时感觉到舒服才会买鞋,对策：,如果营销人员水平比较高，他能够在用户不清楚自己要什么的情况下,引导用户“消费”,例如,很多政府机构大搞网络建设。这些机构的领导大多数不清楚网络干什么用，就让开发人员替他们想需求吧，反正是花公家的钱,实践中的困难和对策,双方互相误解,对策：,需求确认必不可少,开发人员写不好需求文档,对策：,要想写出好的需求文档，前提条件是,把需求调查工作做好,开发人员写作能力比较差,对策：,提高开发人员写作能力的根本办法就是让他们,多练习写文档,，熟能生巧,企业应当,提供文档模板和示例文档,，尽可能地降低写作难度,业务需求,项目范围文档,用户需求,文档,功能需求,质量属性,其他非功能需求,设计约束,需求规约,(specification,),非功能需求,系统需求,需求组成的全景图,软件需求的组成,反映组织机构和客户对系统、产品,高层次的目标要求。,E.g.,一个小型超市需要一个商品的查询系统。,业务需求：,进货人员,需要查询商品库存以便保证及时进货；,收款员,需要查询商品的销售价格以便结账；,经理,需要查询商品的销售及盈利情况。,用户需求,:,这三类用户,怎样去查询,系统，,查询哪些,信息，还需要哪些操作。,业务需求,项目范围文档,用户需求,文档,功能需求,质量属性,其他非功能需求,设计约束,需求规约,(specification,),非功能需求,系统需求,需求组成的全景图,软件需求的组成,从系统的角度描述要,提供的服务以及所受到的约束,。,产品必须具备的,属性或品质。,需求获取和分析,需求描述,需求有效性验证,系统模型,用户需求和系统需求,需求规约,软件需求过程,需求管理,1,确定对系统的,综合要求,-,功能需求、性能需求、可靠性和可用性需求、出错处理需求、接口需求、约束、,逆向需求、将来可能提出的要求。,3.1,需求分析的,具体任务,分析系统的,数据要求,数据结构，利用数据字典全面准确的定义数据,导出系统的,逻辑模型,通常采用,DFD,、,E-R,图、状态转换图、数据字典以及算法来描述逻辑模型,4,修正系统开发计划,3.2,与用户沟通,获取需求的方法,访谈：广泛采用的需求分析技术,面向数据流自顶向下求精,：结构化分析方法,简易的,应用规格说明技术,：面向团队的需求收集方法,快速建立,软件原型,：,Rapid, Easy to modify,面向数据流自顶向下求精,3.3,分析建模与规格说明,1.,分析建模,模型：,就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，,由一组图形符号和组织这些符号的规则组成。,结构化分析 (,Structured Analysis,，,SA),实质上是一种创建模型的活动。,需求分析过程应该建立,3,种模型,数据模型：,E-R,图，描绘数据对象间的关系,功能模型：,DFD,，描绘数据在软件系统中移动时被变换的逻辑过程,行为模型：,状态（转换）图，描绘了系统的各种行为模式（状态）和在不同 状态间转换的方式,3.3.2,软件需求规格说明,(,SRS,),S,oftware,R,equirement,S,pecification,通常用,自然语言,，完整、准确、具体地描述系统的,数据要求、功能需求、性能需求、,可靠性和可用性要求、出错处理需求、,接口需求、约束、逆向需求以及将来可能提出的要求。,软件需求规格说明书，是需求分析阶段得出的最主要的文档。,软件需求说明书的编写,提示（,GB856T88,）,1,引言,1.1,编写目的,1.2,背景,1.3,定义,1.4,参考资料,2,任务概述,2.1,目标,2.2,用户的特点,2.3,假定和约束,软件需求说明书的编写,提示（,GB856T88,）,3,需求规定,3.1,对,功能,的规定,3.2,对,性能,的规定,3.2.1,精度,3.2.2,时间特性,要求,3.2.3,灵活性,3.3,输人输出,要求,3.4,数据管理,能力要求,3.5,故障处理,要求,3.6,其他专门要求,4,运行环境规定,4.1,设备,4.2,支持软件,4.3,接口,4.4,控制,3.4,实体,-,联系图,(,ER,),：,Entity Relationship Diagram,ER,图,：用来,建立数据模型,的工具。,概念性 数据模型（信息模型）,：是一种,面向问题,的数据模型，是按照用户的观点对数据建立的模型。它描述了从,用户角度看到的数据,，,反映了用户的现实环境,，而且与在软件系统中的实现,方法无关。,数据模型中包含,3,种相互关联的信息：,数据对象：,矩形框,，复合信息的抽象。复合信息指居于不同属性或性质的事物，注意，仅有单个值的事物不是数据对象。,属性：,椭圆形或圆角矩形,，定义了数据对象的性质,联系：,菱形框,，数据对象彼此间相互连接的,关系,43,E-R,图：实体、属性和联系,实体,客观世界中存在的且可相互区分的事务,可以是人也可以是物，可以是具体的事物也可以是抽象概念,例如：,教师,学生,课程,联系,客观世界中的事物之间往往是有联系的,例如，教师与课程之间存在“教”的联系,教,教师,课程,M,N,4 需求分析,44,E-R,图：实体、属性和联系,属性,实体,或者,联系,的性质,学,学生,课程,M,N,姓名,学号,班级,课程号,课程名,学时,成绩,举 例,图,3.2,某校教学管理,ER,图,对象,教师属性,学生属性,课程属性,联系属性,关系,3.5,数据规范化,为什么数据要规范化？,规范化的目的是：,减少数据冗余,：即减少数据库或文件中数据重复；,消除多义性,：使关系中的属性含义清楚、单一；,数据操作无异常,：使数据的插入、删除与更新操作无异常；,关系数据库的规范化理论主要包括三个方面的内容：,（,1,）数据依赖：联系,（,2,）范式（,Normal Form,）：标准,（,3,）规范化方法：分解,1NF,2NF,3NF,BCNF,4NF,5NF,第 一 范 式（,1NF,）,每个属性值都,必须是原子值,，即仅仅是一个简单值,而不含内部结构。,如：,教师,(,职工号,，姓名，年龄，职称，职务，工资级别，工资,),学生,-,课程,（,学号,，姓名，性别，年龄，籍贯，系别，,课程号,，课程名，学分，成绩）,第一范式是最低级别的范式。关系数据库中的所有关系模式都必须属于第一范式。,第 二 范 式,(2NF),满足第一范式条件，而且,每个非关键字属性,都由,整个关键字,决定,(,而不是由关键字的一部分来决定,),。,如：,学生,-,课程,（,学号,，姓名，性别，年龄，籍贯，系别，,课程号,，课程名，学分，成绩）,（1）,学生,（,学号,，姓名，性别，年龄，籍贯，系别）,（2）,课程,（,课程号,，课程名，学分，成绩）,（3）,学生-课程,（,学号,，,课程号,，成绩）,第 三 范 式,(3NF),符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性值不依赖于另一个非关键字属性值（本质：非主属性之间不存在传递函数依赖关系）。,3.6,状态转换图,状态转换图,(,简称状态图,),通过描绘系统的,状态,及,引起系统状态转换,的,事件,，来表示,系统的,行为,。,此外，状态图还指明了作为特定事件的结果系统将,做哪些动作,(,例如，处理数据,),。,1.,状 态,状态,是任何可以被观察到的,系统行为模式,，,一个状态代表系统的一种行为模式。,状态规定了系统对事件的响应方式,。,系统对事件的响应，既可以是做一个,(,或一系列,),动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。,初态,(,即初始状态,),状态 终态,(,即最终状态,),中间状态,一张状态图中,只能有一个,初态，而终态则可以有,0,至多个。,2.,事 件,事件是在某个特定时刻发生的事情，它是对引起,系统,做动作或,(,和,),从一个状态转换到另一个状态,的外界事件的抽象。,事件就是引起系统做动作或,(,和,),转换状态的控制信息。,例如，内部时钟表明某个规定的时间段已经过去,用户移动或点击鼠标等都是事件,。,初态,用实心圆,表示，,终态,用一对同心圆,(,内圆为实心圆,),表示。,中间状态,用圆角矩形表示,，可以用两条水平横线把它分成,上、中、下,3,个部分。,上面部分,为状态的名称,，这部分是必须有；,中间部分,为状态变量的名字和值,，这部分是可选的；,下面部分,是活动表,，这部分也是可选的。,3.,符 号,活动表的语法格式：,事件名,(,参数表,)/,动作表达式,其中，,“,事件名,”,可以是任何事件的名称。在活动表中经常使用下述,3,种标准事件：,entry,，,exit,和,do,。,entry,事件指定,进入,该状态的动作，,exit,事件指定,退出,该状态的动作，,do,事件则指定在该状态下的动作。,需要时可以为,事件指定参数表,。活动表中的动,作表达式描述应做的具体动作。,3.,符 号,状态图中两个状态,之间带箭头的连线称为状态转换,，箭头指明了转换方向,。,状态变迁通常是由,事件触发,的，在这种情况下应在表示状态转换的,箭头线上标出触发转换的事件表达式,；如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。,事件表达式的语法：,事件说明守卫条件动作表达式,事件说明,的语法为：,事件名,(,参数表,),。,守卫条件,是一个布尔表达式。一般守卫条件为真时，状态转换就发生。,动作表达式,是一个过程表达式，当状态转换开始时执行该表达式。,3.,符 号,4).,举 例,电话系统的状态图,3.7,其他图形工具,层次方框图,Warnier,图,IPO,图,3.7.1,层次方框图,（,Hierarchy,）,描绘数据的层次结构,(,分类、组成关系,),层次方框图用,树形结构,的,一系列多层次的矩形框,描绘数据的层次结构。,树形结构的,顶层是一个单独的矩形框,，它代表完整的数据结构，,下面的各层矩形框代表这个数据的子集,，,最底层,的各个框代表组成这个数据的,实际数据元素,(,不,能再分割的元素,),。,随着结构的精细化，层次方框图对数据结构也描绘得越来越详细，,这种模式非常适合于,需求分析阶段的需要,。系统分析员从对顶层信息的分类开始，沿图中每条路径,反复细化，,直到确定了数据结构的全部细节时为止。,举 例,领导层辅助决策系统,查询,辅助决策,物,资,信,息,重点供料信息,商情信息,人员状况,合同监视,财务信息,计划执行情况,工程进展情况,超储低储情况,经营指标,历年对比,价格预测,物资用量预测,库存定额核定,库存结构分析,经济采购批量,保本保利分析,4 需求分析,63,3.7.2,Warnier,图,法国计算机科学家,Warnier,提出了表示,信息层次结构的,另外一种图形工具。,Warnier,图也用,树形结构,描绘信息,，,但是这种图形工具比层次方框图,提供了更丰富的描绘手段。,用,Warnier,图可以,表明信息的逻辑组织,。,它可以指出,一类信息或一个信息元素是重复出现的,，也可以表示特定信息在某一类信息中是,有,条件地出现,的。,重复和条件约束是,说明软件处理过程的基础,，所以很容易把,Warnier,图转变成软件设计的工具。,4 需求分析,65,图形工具,Warnier,图,(n),：数据元素出现,n,次,(n1, n2),：,数据元素,重复,n1,到,n2,次,：两个元素只能出现一个,软件产品,系统软件,操作系统,(P1),编译程序,(P2),软件工具,(P3),编辑程序,(P3),测试驱动程序,(P4),设计辅助工具,(P5),应用软件,图中表示一种软件产品,要么,是系统软件,要么,是应用软件。系统软件中有,P1,种操作系统，,P2,种编译程序，此外还有软件工具。软件工具是系统软件的一种，它又可以进一步细分为编辑程序、测试驱动程序和设计辅助工具，,图中标出了每种软件工具的数量,。,3.7.3,IPO,图,(Input/Process/Output),左边的框中列出有关的,输入数据,。,中间的框内列出,主要的处理,，处理框中列出处理的次序暗示了执行的顺序，但是用这些基本符号还,不足以精确描述执行处理的详细情况,。,在右边的框内列出产生的,输出数据,。,在,IPO,图中还用类似向量符号的粗大箭头清楚地指出,数据通信的情况,。,一种改进的,IPO,图,(,也称为,IPO,表,),在需求分析阶段可以使用,IPO,表,简略地,描述系统的主要算法,(,即数据流图中各个处理的基本算法,),。,需求分析阶段，,IPO,表中的许多,附加信息暂时还不具备,，但在设计阶段可以进一步补充修正这些图，,作为设计阶段的文档。,这正是在需求分析阶段用,IPO,表作为描述算法的工具的重要优点。,3.8,验证软件需求,一致性：所有需求必须是一致的任何一条需求不能与其它需求矛盾；,完整性：规格说明书应该包括用户需要的每一个功能；,现实性：指定的需求应该在现有的硬件与软件技术上可以实现的；,有效性：必须证明需求是正确有效的，确实能够解决用户面对的问题。,