Chapter2需求分析(含可行性分析)-3学时.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,Chapter 2,可行性研究及需求分析,2.1,可行性研究,2.2,需求分析,11/15/2026,1,2.1,可行性研究,2.1.1,可行性研究的目的,2.1.2,可行性研究的任务,2.1.3,可行性研究的步骤,2.1.4,可行性研究报告参考模板,11/15/2026,2,2.1.1,可行性研究的目的,目的：确定问题是否值得去解决。,用,最小的代价,，在,尽可能短的时间内,确定问题是否能够解决。,实质：进行一次大大压缩,简化了的系统分析和设计的过程,。,在较高层次上以较抽象的方式进行的系统分析和设计的过程。,11/15/2026,3,2.1.2,可行性研究的任务,进一步分析和澄清问题定义,各系统实现方案的可行性分析,技术可行性,经济可行性,操作可行性,为每个可行方案制定粗略的实现进度,对以后的行动方针提出建议,逻辑模型,11/15/2026,4,2.1.3,可行性研究的步骤（,1/2,）,1,、复查系统规模和目标,确保分析员正在解决的问题确实是要求他解决的问题。,2,、研究目前正在使用的系统,了解现有系统的基本功能及缺点。,3,、导出新系统的高层逻辑模型,从现有系统的物理系统出发，导出现有系统的逻辑模型，设想目标系统的逻模型，建造新的物理系统。,4,、进一步定义问题,复查问题定义、工程规模和目标。,11/15/2026,5,2.1.3,可行性研究的步骤（,2/2,）,5,、导出和评价供选择的解法,从技术角度出发考虑解决问题的不同方案。,6,、推荐行动方针,对于所推荐的系统进行仔细的成本,/,效益分析。,7,、草拟开发计划,制定工程进度表；,估算各类开发人员和各种资源的需要情况；,估算系统生命周期每个阶段的成本；,给出下需求分析阶段的详细极度表和成本估计。,8,、书写文档提交审查,11/15/2026,6,2.1.4,可行性研究报告参考模板,可行性研究报告模板,1,可行性研究报告模板,2,可行性研究报告实例,11/15/2026,7,思 考,【,习题,2-4】,目前住院病人主要由护士护理，这样做不仅需要大量护士，而且由于不能随时观察危重病人的病情变化，还可能会延误抢救时机。某医院打算开发一个以计算机为中心的患者监护系统，试写出问题定义，并分析开发这个系统的可行性。,【,医院对患者监护系统的基本要求,】,随时接收每个病人的生理信号，定时记录病人情况以形成患者日志，当某个病人的生理信号超出医生规定的安全范围时向值班护士发出警告信息，此外，护士在还需要时还可以要求系统打印出某个指定病人的病情报告。,11/15/2026,8,产生,病情报告,监视病情,更新病历,例：患者监护系统,11/15/2026,9,2.2,需求分析,11/15/2026,10,什么是需求,需求：指明必须实现什么的规格说明。它描述了系统的行为、特性或属性,好的需求具有特点：,一致性、完整性,可理解、无二义性,可测试,需求分析的三步曲：,收集用户、市场、公司对本项目的目标,经过分析建立解题模型,细化模型，抽取需求,11/15/2026,11,需求分析的作用,定义,软件的范围,及,必须满足的约束,；,确定,软件的功能,和性能及与其他系统成分的,接口,;,建立,数据模型,、,功能模型,和,行为模型,；,最终提供,需求规格说明,，并用于作为评估软件质量的依据。,11/15/2026,12,软件需求的重要性,软件需求无疑是当前软件工程中的关键问题，,没有需求就没有软件,。,美国于,1995,年开始对全国范围内的,8000,个软件项目进行跟踪调查。,分析失败的原因发现，与需求过程相关的原因占了,45%,，而其中,缺乏最终用户的参与以及不完整的需求又是两大首要原因,，各占,13%,和,12%,。,未完成,完成未实施,完成,11/15/2026,13,需求分析在项目中的地位,11/15/2026,14,磨刀不误砍柴功,系统分析员在项目中的地位,11/15/2026,15,每个参与软件系统开发的人员都需要有一个独特的系统视角,系统,构架工程师,项目经理,系统分析员,设计人员,测试人员,用户,11/15/2026,16,软件需求的困难,软件需求是软件工程中最复杂的过程之一：,应用领域的广泛性,，它的实施无疑与各个应用行业的特征密切相关。,非功能性需求建模技术的缺乏,，及其与功能性需求有着错综复杂的联系，大大增加了需求工程的复杂性。,沟通上的困难,，由于系统分析员、需求分析员等各方面人员有不同的着眼点和不同的知识背景，给需求工程的实施增加了人为的难度。,11/15/2026,17,需求分析的任务,11/15/2026,18,软 件需 求,用 户需 求,系 统需 求,功能需求,非功能需求,领域需求,由客户管理员、,用户等提出,软件需求的内容,需求分析的任务,11/15/2026,19,功能需求,它是对系统应该提供的服务、功能以及系统在特定条件下的行为的描述。它与软件系统的类型、使用系统的用户等相关，有时需要详细描述系统的功能、输入,/,输出、异常等，有时还需要申明系统不应该做什么。,领域需求,是由软件系统的,应用领域,所决定的特有的功能需求，或是对功能的约束。,11/15/2026,20,非功能需求,产品需求,机构需求,外部需求,互操作,需求,道德,需求,立法,需求,性能,需求,空间,需求,交付,需求,实现,需求,标准,需求,隐私,需求,安全,性需求,可用性,需求,效率,需求,可靠性,需求,可移植,性需求,11/15/2026,21,该系统应该具备以下功能：,基本,数据维护,功能,基本,业务,功能,数据,库管理,功能,信息,查询,功能,例：一个大学图书管理系统，该系统除了一般的图书管理功能外，还能够为学生和教工从其他图书馆借阅图书和文献资料提供服务。,11/15/2026,22,（,1,）基本数据维护功能：,提供使用者录入、修改并进行维护基本数据的途径；,读者、图书资料的相关信息的修改，更新。,（,2,）基本业务功能：,读者借、还书籍的登记管理功能；,随时根据读者借、还书籍的情况更新数据库系统；,如果书籍已经借出，可以进行预留操作；,书籍的编目、入库、更新等操作。,1,、功能需求,11/15/2026,23,（,3,）数据库管理功能：,对所有图书信息及读者信息进行统一管理维护的功能；,对书籍的借还也要进行详细的登记，以便协调整个图书馆的运作。,（,4,）,信息查询功能：,提供对各类信息的查询功能，如,对本图书馆的用户借书信息、还书的信息查询,书籍源信息查询,预留信息查询，,对其他图书馆的书籍、资料源信息的查询。,功能需求（续）,11/15/2026,24,（,1,）系统安全性需求：,为保证系统安全性，对本图书馆的各项功能进行分级、分权限操作，对各类用户进行确认。对其它图书馆借阅图书和文献资料服务控制访问范围：如限,IP,、,限用户等。,（,2,）对系统可用性的需求：,为了方便使用者，要求对所有交互操作提供在线帮助功能。,（,3,）对系统查询速度的需求：,要求系统在,20S,之内响应查询服务请求。,（,4,）对系统可靠性的需求：,要求系统失败发生率小于,1%,。,2,、非功能需求,11/15/2026,25,非功能需求（续）,-Microsoft,11/15/2026,26,非功能需求（续）,功 能 性,正确性（,Correctness,）,健壮性（,Robustness,）,可靠性（,Reliability,）,非 功 能 性,性能（,Performance,）,易用性（,Usability,）,清晰性（,Clarity,）,安全性（,Security,）,可扩展性（,Extendibility,）,兼容性（,Compatibility,）,可移植性（,Portability,）,-,高质量程序设计指南：,C+/C,语言（第三版）“,10,大”软件质量属性,11/15/2026,27,3,、领域需求,例如：对“大学图书管理系统”，提出一些与图书管理的业务相关的需求：,图书编目要求按照,中国图书馆分类法,进行；,是对遵循我国图书管理的规定，执行对图书的分类管理的标准。,由于版权限制，某些文献资料只能在图书馆规定的阅览室阅读，并限制复制和打印。,是版权法对图书馆文献资料的保护的需要，描述了对一类文献资料有限制的使用和服务。,11/15/2026,28,Q&A,Q,：,从对软件需求的相关概念及重要性等的了解，你认为需求人员应该具备怎样的能力？,A,：,丰富的软件开发经验；,良好的沟通能力、表达能力；,行业背景。,11/15/2026,29,需求获取的方法,11/15/2026,30,1.,面谈法,重要而直接，简单的需求获取技术。,2.,问卷调查法,是对面谈法的补充。,3.,情景分析技术,。,面谈的对象主要有用户和领域专家：,1,）面谈前的准备要充分；,2,）面谈后注意认真分析总结；,3,）注意掌握面谈的人际交流技能。,是从多个用户中收集需求信息的有效方式，一般问卷设计形式：,1,）多项选择问题；,2,）评分问题；,3,）排序问题。,对用户将来使用目标系统解决某个具体问题的方法和结果进行分析：,1,）能在某种程度上演示目标系统的行为；,2,）能保证用户在需求分析过程中始终扮演积极主动的角色。,需求获取方法（,1,）,访谈,11/15/2026,31,需求获取方法（,2,）,SA,方法,用户复查,分析追踪,数据流图,细化,数据流图,无补充修正,有补充修正,需要,分解,不需要分解,面向数据流自顶向下求精过程,11/15/2026,32,需求获取方法（,3,）,简易的应用规格说明技术,面向团队的需求收集法。,需求专题讨论会,最有力的需求获取技术。有利于培养高效团队。,由开发方和用户方共同召开，操作步骤：,开发方根据双方制定的,需求调研计划,召开相关需求主题沟通会；,会后开发方整理出,需求调研记录,提交给用户方确认；,如果此主题还有未明确的问题则再次沟通，否则开始下一主题；,所有需求都沟通清楚后，开发方根据历次,需求调研记录,整理出,用户需求说明书,，提交给用户方确认签字。,11/15/2026,33,需求获取方法（,4,）,快速建立软件原型,快速建立起来的旨在,演示目标系统主要功能,的可运行的程序。,要点：实现用户看得见的功能，省略目标系统的“隐含”功能。,特性：快速、容易修改。,工具和方法：,第四代技术,可重用的软件构件,形式化规格说明和原型环境,11/15/2026,34,分析建模,数据模型,实体,-,联系图（,E-R,图）：描述数据对象及数据对象之间的关系。,功能模型,数据流图（,DFD,）：,描绘当数据在软件系统中移动时被变换的逻辑过程，指明系统具有的变换数据的功能。,行为模型,状态转换图：描绘系统各种行为模式和在不同状态间转换的方式。,11/15/2026,35,什么是模型,模型,：是对对象系统的形式化的特征抽象，概括性或近似地表示。,模型化,：是通过,抽象,、,概括,和,一般化,，把研究的对象或问题转化为本质（关系或结构）相同的另一对象或问题，从而加以解决的方法。,模型化方法要求所建立的模型能真实反映所研究对象的整体结构、关系或某一过程、某一局部、某一侧面的本质特征和变化规律。,11/15/2026,36,模型的构造过程,构造模型的过程是一个抽象、分析的过程。,首先，通过对现实环境的调查，获得当前系统的物理模型。,学,生,学,生,购,书,申,请,购书,单,发,票,领,书,单,书,107,张,教务科,206,王,会计室,206,李,出纳员,507,赵,教材科,学生购买教材的实际处理流程：当前系统物理模型,11/15/2026,37,模型的构造过程（续,1,）,去掉具体模型中的非本质因素：抽取现实系统的实质，抽象出当前系统的逻辑模型,学,生,学,生,购,书,申,请,购书,单,发,票,领,书,单,书,审查,有效性,开发票,开领,书单,发书,学生购买教材的逻辑模型,11/15/2026,38,模型的构造过程（续,2,）,分析当前系统与目标系统的差别，建立目标系统的逻辑模型。,学,生,审查并,开发票,购书单,发票,领书单,开领,书单,无效书单,学,生,计算机教材管理系统的逻辑模型,对目标系统的逻辑模型进行细化、改进与优化,需求分析的验证,11/15/2026,39,结构化分析方法：,SA,是,面向数据流,进行需求分析的方法,适合于,数据处理类型软件,的需求分析,基本思想：用,抽象模型,的概念，按照软件内部数据传递、变换的关系，,自顶向下逐层分解,，直到找到满足功能要求的所有可实现的软件为止。,遵循三条原则：,分解,、,抽象,、,映射,11/15/2026,40,SA,方法的步骤,当前系统,具体模型,建立,当前系统,逻辑模型,抽象,目标系统,逻辑模型,建立,完善的系统逻辑模型,改进,深入调查,研究,分析用户需求,用,DFD,图描述,分析系统需求,用,DFD,图描述,修改完善,DFD,图,增添功能,11/15/2026,41,SA,工具划分,功能分析工具：,数据流图,DFD(,Data,Flow Diagram,),、数据字典,DD(Data,Dictionary),、结构化英语、判定表和判定树,行为分析工具：,状态迁移图、,Petri,网等,数据分析工具：,ER,图或者,EER,（,扩展,ER,）,图,SA,主要针对数据处理领域，因此，系统分析的侧重点在于,功能分析,和,数据分析,，而行为分析使用得较少。,11/15/2026,42,数据流图：功能建模,主要图形元素：,数据源点或终点,(,外部实体,),数据流,数据加工,(,数据变换,),数据存储文件,11/15/2026,43,数据流图示例：银行取款,11/15/2026,44,DFD,绘制要点,数据流图的主图必须包括前述四种基本元素，缺一不可,每个加工至少有一个输入数据流和一个输出数据流,可以采用层次结构的数据流图，按照系统的层次结构进行逐步分解。,初画时可以忽略琐碎的细节，以集中精力于主要数据流,11/15/2026,45,分层,DFD,示例,:,商店业务处理系统,11/15/2026,46,分层,DFD,示例,:,第一层数据流图,11/15/2026,47,分层,DFD,示例,:,销售数据流图细化,11/15/2026,48,数据字典,数据词典与数据流图配合，能清楚地表达数据处理的要求。,数据字典定义（词条描述）：,数据流：名称、来源、数据结构等,数据元素：名称、类型、长度、取值范围等,数据文件：名称、输入输出、存取方式,加工逻辑：名称、功能简述,源点及汇点：外部实体名,11/15/2026,49,数据字典示例：存折格式,存折户名所号帐号开户日性质,(,印密,),1,存取行,50,户名,2,字母,24,所号“,001”.“999”,帐号“,00000001”.“99999999”,开户日年月日,性质“,1”.“6”,注：“,1”,表示普通户，“,5”,表示工资户等,印密“,0”,注：印密在存折上不显示,存取行日期（摘要）支出存入余额操作复核,11/15/2026,50,数据词典卡片示例,名字：订货信息,别名：订货报表,描述：每周一次生成的需要定货的商品信息列表,定义：订货信息,=,商品编号,+,商品名称,+,订货数量,+,商品单价,+,供应商,位置：存储在文件中。,名字：商品编号,别名：,描述：标识库存清单中一个特定商品的关键字,定义：商品编号,=10,字符,10,位置：订货信息、订货报表、库存清单,名字：商品名称,别名：,描述：某种商品的名字,定义：商品名称,=1,字符,12,位置：订货信息 订货报表,名字：订货数量,别名：,描述：某种商品一次订货的数量,定义：订货数量,=1,数字,5,位置：订货信息,订货报表,11/15/2026,51,状态图,状态图中使用的主要符号,11/15/2026,52,状态图,-,电话系统的状态图,11/15/2026,53,关系实体图：数据建模,概念性数据建模方法：是实体联系方法（,Entity-Relationship Approach,）,ER,图描述现实世界中的实体，而不涉及这些实体在系统中的实现方法。,ER,图元素：,实体,联系,属性,11/15/2026,54,实体、联系和属性,实体：客观世界中存在的且可相互区分的事务。,Entities,例：,Student,Instructor,Class,联系：客观世界中的事物彼此间的联系。,Relations,例：,Enrolled in,Teach,1,1,1,N,M,N,属性：实体或联系所具有的性质。,Attributes,例：,Name,ID#,11/15/2026,55,实体的多种联系表示,11/15/2026,56,ER,图示例,-,教学实体模型,在教学管理中，一个教师可以教授零门、一门或多门课程，每位学生也需要学习几门课程。因此，教学管理中涉及的对象（实体型）有学生、教师和课程,。,学生与课程是多对多的联系，而教师与课程的联系是零、一对多,11/15/2026,57,ER,图示例,11/15/2026,58,软件需求规格说明书：,SRS,用自然语言或形式化方法描述用户对软件系统的需求。,内容应该包括：,需要能够表达和理解问题的,信息域,和,功能域,要给出系统的,逻辑视图,和,物理视图,从现实中分离功能，即描述要“,做什么,”而不是“,怎样实现,”,非功能性需求，主要包括：,可靠性、安全性,可测试性,可维护性,适应性、可移植性,11/15/2026,59,参考资料,ZD-,软件需求规格说明书,-,ProductID-Vx.x.doc,ZD-,用户需求说明书,-,ProjectID-Vx.x.doc,11/15/2026,60,课后练习,要实现,教学管理系统,中的“学生选课”子系统,试用数据流图描述本系统的功能,11/15/2026,61,案例,医院病房监护系统,（采用结构化分析方法）,需求案例分析,11/15/2026,62,一、问题的描述,在医院,ICU,病房里，将病症监视器安置在每个病床，对病人进行监护。监视器将病人的组合病症信号实时地传送到中央监护系统进行分析处理。,在中心值班室里，值班护士使用中央监护系统对病员的情况进行监控，监护系统实时地将病人的病症信号与标准的病诊信号进行比较分析，当病症出现异常时，系统会立即自动报警，并打印病情报告和更新病历。,根据医生的要求随时打印病人的病情报告，系统还定期自动更新病历。,11/15/2026,63,经过初步的需求分析，得到系统功能要求：,1,、监视病员的病症,(,血压、体温、脉搏等,),。,2,、定时更新病历。,3,、病情出现异常情况时报警。,4,、随机地产生某一病员的病情报告。,产生,病情报告,监视病情,更新病历,请分析软件,系统,需求,!,11/15/2026,64,1,、监视病员的病症,采集病症信号,(,血压、体温、脉搏等,),。,组合病症信号。,将模拟,病症信号转换为数字信号（,A-D,转换）。,2,、定时更新病历,将,病症信号进行格式化并加入更新日期、时间。,更新病历库中病人的信息。,可人工设定更新,病历的时间间隔。,3,、病情出现异常情况时报警,根据标准病症信号库中的值，判断是否报警。,将报警信号转换为各种模拟信号（,D-A,转换）。,实时打印病情报告，立即更新病历。,4,、随机地产生某一病员的病情报告,局部监视,更新日志,产生病情报告,二、系统功能需求,报警,11/15/2026,65,三、非功能需求,1,、监视器与网络的,可靠性要求,，涉及人的生命安全。,2,、,效率需求,中对时间、空间的需求，所采集的病症信号数据量大。,3,、,互操作需求,如要求监视器采样频率可人工调整等。,4,、对病人病历的,隐私的要求,。,11/15/2026,66,病员,护士,护士,病员监,护系统,病员,日志,病症信号,要求报告,病症,报告,报警,顶 层,DFD,图,四、医院病房监护系统分层,DFD,图,顶层确定了系统的范围，其外部实体为病员和护士。,护士,病员,护士,11/15/2026,67,第一层：,医院病房监护系统顶层,DFD,图,病员,护士,护士,中央监视,病员,日志,病症信号,要求报告,病症报告,报警,局部监视,生成报告,病员极限,更新日志,病员数据,格式化,病员数据,生理信号,极限值,1,3,2,4,日志数据,日志数据,紧急报告,11/15/2026,68,第二层：加工,“,中央监视,”,分解,计算超过,极限值否,病员,数据,超过,极限值,报警,开解信号,产生,报警信息,病员极限,格式化,病员数据,体温,血压、体温脉搏,生理信号,极限值,时间,脉搏,血压,日期,时钟,格式化,病员数据,3.1,3.2,3.3,3.4,紧急报告,医院病房监护系统二层,DFD,图,11/15/2026,69,计算超过,极限值否,病员,数据,超过,极限值,报警,开解信号,产生,报警信息,病员极限,格式化,病员数据,体温,血压、体温、,脉搏,生理信号,极限值,时间,脉搏,血压,日期,时钟,格式化,病员数据,3.1,3.2,3.3,3.4,第二层：加工,“,中央监视,”,分解,医院病房监护系统分层,DFD,图,第一层,格式化,病员数据,生理信号,极限值,病员,护士,护士,中央监视,病员,日志,病症信号,要求报告,病症,报告,报警,局部监视,生成报告,病员极限,更新日志,病员数据,1,3,2,4,日志数据,紧急报告,紧急报告,11/15/2026,70,加工分解的原则,自然性,：,概念上合理、清晰；,均匀性,：理想的分解是将一个问题分解成大小均匀的几个部分；,分解度：,一般每一个加工每次分解最多不要超过个子加工,分解应分解到基本加工为止。,画分层,DFD,图的基本原则,数据守恒与数据封闭原则,数据守恒是指加工的输入,/,出数据流是否匹配，,即每一个加工既有输入数据流又有输出数据流。,数据封闭是对整个系统而言。,11/15/2026,71,合理使用文件,当文件作为某些加工之间的交界面时，文件必须画出来，一旦文件作为数据流图中的一个独立成份画出来了，那么他同其他成份之间的联系也应同时表达出来。,注意,DFD,图不是流程图，不表示软件的控制流程。,画分层,DFD,图的基本原则,子图与父图的“平衡”,父图中某个加工的输入输出数据流应该同相应的子图的输入输出相同（相对应），分层数据流图的这种特点称为子图与父图,“,平衡,”,。,11/15/2026,72,分层,DFD,图的改进,DFD,图须经过,反复修改,，才能获得最终的目标系统的,DFD,图。从以下方面改进,DFD,图：,1,、检查数据流的正确性,数据守恒,子图、父图的平衡,文件使用是否合理。特别注意输入,/,出文件的数据流。,2,、改进,DFD,图的易理解性,简化加工之间的联系（联系越少，独立性越强，易理解性越好）。,改进分解的均匀性。,适当命名（各成分名称无二义性，准确、具体）,11/15/2026,73,验证软件需求,一致性,任何一条需求不能和其他需求相互矛盾。,完整性,规格说明书应包括用户需要的每一个功能或性能。,现实性,用现有的硬件和软件技术基本上可以实现。,有效性,确定能解决用户面对的问题。,11/15/2026,74,补充内容：需求管理,需求管理贯穿需求分析全过程，包括,:,需求管理,变更控制,建议变更,分析影响,交流,合并,测量需求的稳定性,版本控制,定义需求文档版本,确定单个需求文档版本,需求跟踪,定义与其他需求的链接,定义与其他系统元素的链接,需求状态跟踪,定义需求状态,跟踪所有需求状态,11/15/2026,75,需求管理（,Requirement Management,，,RM,）的所有活动中，最重要的是,“,需求变更管理”，,包括,:,问题分析和变更描述,变更分析和成本计算,变更实现,修正后的需求,识别出的问题,需求管理过程需要,CASE(Computer Aided Software Engineering),工具支持。,需求过程管理,11/15/2026,76,IBM Rational,需求过程管理,11/15/2026,77,IBM Rational,需求过程管理,11/15/2026,78,中地公司需求过程管理,11/15/2026,79,需求管理工具案例,IBM_Rational-需求管理的实践与案例分享.pdf,ZDSSP 中地标准软件过程ZD-需求变更汇总表-ProductID.xls,ZDSSP 中地标准软件过程-需求变更申请表-ProductID-nnn.doc,ZDSSP 中地标准软件过程-需求跟踪矩阵-ProductID.xls,ZDSSP 中地标准软件过程-需求确认表-Product.doc,11/15/2026,80,补充内容：基于用例（,USE CASE,）的需求分析,用例建模是一种从用户,使用系统的角度,来建立系统功能需求模型的一种方法。,用例建模既非从数据模型开始，亦非从系统数据流着手，而是从组成系统的,实际操作,入手。,用例图,，又称,用例模型,，是用例建模的主要成果，它从系统外部执行者的角度来描述系统需要提供哪些功能以及谁使用这些功能。,用例：系统和外部角色的交互,符号表示：,11/15/2026,81,用例,图符号,系统名称,系统,用例名,用例,角色,/,参与者,关联,11/15/2026,82,用例描述,用例描述有许多种方法，如简单文字、模板、表格、形式化语言和图形等，开发人员可根据项目进展及用户特点灵活选择。,用例,“,获取呼叫历史,”,使客户可以查阅账上已付费的所有呼叫的细节。呼叫历史可以以文本或声音的形式提供给客户。,简单文字,11/15/2026,83,保险商务系统,签定保险单,销售统计,客户统计,客户,保险销售员,用例图描述,11/15/2026,84,用例图描述,简单,ATM,系统,存款,验证顾客,管理支取,扩展点,透支通知：动作序列最后,通知透支,extend,（,透支通知）,顾客订购了,“,透支通知,”,服务且操作引起透支,取款,转账,维护,include,include,顾客,银行系统,管理员,系统,主要参与者,次要参与者,用例,通信关系,包含关系,泛化关系,扩展关系,11/15/2026,85,用例参与者描述,参与者描述的内容主要包括参与者的名称、是否为抽象参者与及对参与者的简要描述。,11/15/2026,86,用例模板描述,11/15/2026,87,本章小结,可行性研究的目的和任务,可行性研究的过程（了解）,系统流程图（了解）,掌握：,数据流图,的绘制,掌握：数据字典的定义,了解：需求规格说明书,了解：需求过程管理主要内容,了解：用例图,11/15/2026,88,作业,1.,应该从哪几个方面去研究解决方法的可行性？,2.,软件需求包括哪些内容？,3.,与用户沟通获取需求时，有哪些方法可以使用？,4.,结构化分析,-SA,的基本思想是什么？,5.SA,涉及哪三个方面的分析建模？各自都可采用哪些工具？,6.,需求分析的输出产品,(SRS),包括哪些部分？,7.,需求过程管理包含哪些主要内容，其中最重要的是什么？,8.,分析教材习题,2,第,4,题的患者监护系统。试完成如下分析任务：,（,1,）用实体,-,联系图描绘本系统中的数据对象；,（,2,）用数据流图描绘该系统功能；,（,3,）参考顶层,DFD,图绘出用例图。,11/15/2026,89,