Chapter2需求分析含可行性分析3学时.ppt
- 文档编号:1386098
- 上传时间:2022-10-21
- 格式:PPT
- 页数:89
- 大小:3.53MB
Chapter2需求分析含可行性分析3学时.ppt
《Chapter2需求分析含可行性分析3学时.ppt》由会员分享,可在线阅读,更多相关《Chapter2需求分析含可行性分析3学时.ppt(89页珍藏版)》请在冰豆网上搜索。
2022/10/21,1,Chapter2可行性研究及需求分析,2.1可行性研究2.2需求分析,2022/10/21,2,2.1可行性研究,2.1.1可行性研究的目的2.1.2可行性研究的任务2.1.3可行性研究的步骤2.1.4可行性研究报告参考模板,2022/10/21,3,2.1.1可行性研究的目的,目的:
确定问题是否值得去解决。
用最小的代价,在尽可能短的时间内确定问题是否能够解决。
实质:
进行一次大大压缩简化了的系统分析和设计的过程。
在较高层次上以较抽象的方式进行的系统分析和设计的过程。
2022/10/21,4,2.1.2可行性研究的任务,进一步分析和澄清问题定义,各系统实现方案的可行性分析,技术可行性,经济可行性,操作可行性,为每个可行方案制定粗略的实现进度,对以后的行动方针提出建议,逻辑模型,2022/10/21,5,2.1.3可行性研究的步骤(1/2),1、复查系统规模和目标确保分析员正在解决的问题确实是要求他解决的问题。
2、研究目前正在使用的系统了解现有系统的基本功能及缺点。
3、导出新系统的高层逻辑模型从现有系统的物理系统出发,导出现有系统的逻辑模型,设想目标系统的逻模型,建造新的物理系统。
4、进一步定义问题复查问题定义、工程规模和目标。
2022/10/21,6,2.1.3可行性研究的步骤(2/2),5、导出和评价供选择的解法从技术角度出发考虑解决问题的不同方案。
6、推荐行动方针对于所推荐的系统进行仔细的成本/效益分析。
7、草拟开发计划制定工程进度表;估算各类开发人员和各种资源的需要情况;估算系统生命周期每个阶段的成本;给出下需求分析阶段的详细极度表和成本估计。
8、书写文档提交审查,2022/10/21,7,2.1.4可行性研究报告参考模板,可行性研究报告模板1可行性研究报告模板2可行性研究报告实例,2022/10/21,8,思考,【习题2-4】目前住院病人主要由护士护理,这样做不仅需要大量护士,而且由于不能随时观察危重病人的病情变化,还可能会延误抢救时机。
某医院打算开发一个以计算机为中心的患者监护系统,试写出问题定义,并分析开发这个系统的可行性。
【医院对患者监护系统的基本要求】随时接收每个病人的生理信号,定时记录病人情况以形成患者日志,当某个病人的生理信号超出医生规定的安全范围时向值班护士发出警告信息,此外,护士在还需要时还可以要求系统打印出某个指定病人的病情报告。
2022/10/21,9,监视病情,更新病历,例:
患者监护系统,2022/10/21,10,2.2需求分析,2022/10/21,11,什么是需求,需求:
指明必须实现什么的规格说明。
它描述了系统的行为、特性或属性好的需求具有特点:
一致性、完整性可理解、无二义性可测试需求分析的三步曲:
收集用户、市场、公司对本项目的目标经过分析建立解题模型细化模型,抽取需求,2022/10/21,12,需求分析的作用,定义软件的范围及必须满足的约束;确定软件的功能和性能及与其他系统成分的接口;建立数据模型、功能模型和行为模型;最终提供需求规格说明,并用于作为评估软件质量的依据。
2022/10/21,13,软件需求的重要性,软件需求无疑是当前软件工程中的关键问题,没有需求就没有软件。
美国于1995年开始对全国范围内的8000个软件项目进行跟踪调查。
分析失败的原因发现,与需求过程相关的原因占了45%,而其中缺乏最终用户的参与以及不完整的需求又是两大首要原因,各占13%和12%。
未完成,完成未实施,完成,2022/10/21,14,需求分析在项目中的地位,2022/10/21,15,磨刀不误砍柴功,系统分析员在项目中的地位,2022/10/21,16,每个参与软件系统开发的人员都需要有一个独特的系统视角,2022/10/21,17,软件需求的困难,软件需求是软件工程中最复杂的过程之一:
应用领域的广泛性,它的实施无疑与各个应用行业的特征密切相关。
非功能性需求建模技术的缺乏,及其与功能性需求有着错综复杂的联系,大大增加了需求工程的复杂性。
沟通上的困难,由于系统分析员、需求分析员等各方面人员有不同的着眼点和不同的知识背景,给需求工程的实施增加了人为的难度。
2022/10/21,18,需求分析的任务,2022/10/21,19,软件需求,软件需求的内容,需求分析的任务,2022/10/21,20,功能需求它是对系统应该提供的服务、功能以及系统在特定条件下的行为的描述。
它与软件系统的类型、使用系统的用户等相关,有时需要详细描述系统的功能、输入/输出、异常等,有时还需要申明系统不应该做什么。
领域需求是由软件系统的应用领域所决定的特有的功能需求,或是对功能的约束。
2022/10/21,21,2022/10/21,22,该系统应该具备以下功能:
基本数据维护功能基本业务功能数据库管理功能信息查询功能,例:
一个大学图书管理系统,该系统除了一般的图书管理功能外,还能够为学生和教工从其他图书馆借阅图书和文献资料提供服务。
2022/10/21,23,
(1)基本数据维护功能:
提供使用者录入、修改并进行维护基本数据的途径;读者、图书资料的相关信息的修改,更新。
(2)基本业务功能:
读者借、还书籍的登记管理功能;随时根据读者借、还书籍的情况更新数据库系统;如果书籍已经借出,可以进行预留操作;书籍的编目、入库、更新等操作。
1、功能需求,2022/10/21,24,(3)数据库管理功能:
对所有图书信息及读者信息进行统一管理维护的功能;对书籍的借还也要进行详细的登记,以便协调整个图书馆的运作。
(4)信息查询功能:
提供对各类信息的查询功能,如对本图书馆的用户借书信息、还书的信息查询书籍源信息查询预留信息查询,对其他图书馆的书籍、资料源信息的查询。
功能需求(续),2022/10/21,25,
(1)系统安全性需求:
为保证系统安全性,对本图书馆的各项功能进行分级、分权限操作,对各类用户进行确认。
对其它图书馆借阅图书和文献资料服务控制访问范围:
如限IP、限用户等。
(2)对系统可用性的需求:
为了方便使用者,要求对所有交互操作提供在线帮助功能。
(3)对系统查询速度的需求:
要求系统在20S之内响应查询服务请求。
(4)对系统可靠性的需求:
要求系统失败发生率小于1%。
2、非功能需求,2022/10/21,26,非功能需求(续)-Microsoft,2022/10/21,27,非功能需求(续),-高质量程序设计指南:
C+/C语言(第三版)“10大”软件质量属性,2022/10/21,28,3、领域需求例如:
对“大学图书管理系统”,提出一些与图书管理的业务相关的需求:
图书编目要求按照中国图书馆分类法进行;是对遵循我国图书管理的规定,执行对图书的分类管理的标准。
由于版权限制,某些文献资料只能在图书馆规定的阅览室阅读,并限制复制和打印。
是版权法对图书馆文献资料的保护的需要,描述了对一类文献资料有限制的使用和服务。
2022/10/21,29,Q&A,Q:
从对软件需求的相关概念及重要性等的了解,你认为需求人员应该具备怎样的能力?
A:
丰富的软件开发经验;良好的沟通能力、表达能力;行业背景。
2022/10/21,30,需求获取的方法,2022/10/21,31,1.面谈法重要而直接,简单的需求获取技术。
2.问卷调查法是对面谈法的补充。
3.情景分析技术。
面谈的对象主要有用户和领域专家:
1)面谈前的准备要充分;2)面谈后注意认真分析总结;3)注意掌握面谈的人际交流技能。
是从多个用户中收集需求信息的有效方式,一般问卷设计形式:
1)多项选择问题;2)评分问题;3)排序问题。
对用户将来使用目标系统解决某个具体问题的方法和结果进行分析:
1)能在某种程度上演示目标系统的行为;2)能保证用户在需求分析过程中始终扮演积极主动的角色。
需求获取方法
(1)访谈,2022/10/21,32,需求获取方法
(2)SA方法,用户复查,分析追踪数据流图,细化数据流图,无补充修正,有补充修正,需要分解,不需要分解,面向数据流自顶向下求精过程,2022/10/21,33,需求获取方法(3)简易的应用规格说明技术,面向团队的需求收集法。
需求专题讨论会最有力的需求获取技术。
有利于培养高效团队。
由开发方和用户方共同召开,操作步骤:
开发方根据双方制定的需求调研计划召开相关需求主题沟通会;会后开发方整理出需求调研记录提交给用户方确认;如果此主题还有未明确的问题则再次沟通,否则开始下一主题;所有需求都沟通清楚后,开发方根据历次需求调研记录整理出用户需求说明书,提交给用户方确认签字。
2022/10/21,34,需求获取方法(4)快速建立软件原型,快速建立起来的旨在演示目标系统主要功能的可运行的程序。
要点:
实现用户看得见的功能,省略目标系统的“隐含”功能。
特性:
快速、容易修改。
工具和方法:
第四代技术可重用的软件构件形式化规格说明和原型环境,2022/10/21,35,分析建模,数据模型实体-联系图(E-R图):
描述数据对象及数据对象之间的关系。
功能模型数据流图(DFD):
描绘当数据在软件系统中移动时被变换的逻辑过程,指明系统具有的变换数据的功能。
行为模型状态转换图:
描绘系统各种行为模式和在不同状态间转换的方式。
2022/10/21,36,什么是模型,模型:
是对对象系统的形式化的特征抽象,概括性或近似地表示。
模型化:
是通过抽象、概括和一般化,把研究的对象或问题转化为本质(关系或结构)相同的另一对象或问题,从而加以解决的方法。
模型化方法要求所建立的模型能真实反映所研究对象的整体结构、关系或某一过程、某一局部、某一侧面的本质特征和变化规律。
2022/10/21,37,模型的构造过程,构造模型的过程是一个抽象、分析的过程。
首先,通过对现实环境的调查,获得当前系统的物理模型。
2022/10/21,38,模型的构造过程(续1),去掉具体模型中的非本质因素:
抽取现实系统的实质,抽象出当前系统的逻辑模型,2022/10/21,39,模型的构造过程(续2),分析当前系统与目标系统的差别,建立目标系统的逻辑模型。
对目标系统的逻辑模型进行细化、改进与优化需求分析的验证,2022/10/21,40,结构化分析方法:
SA,是面向数据流进行需求分析的方法适合于数据处理类型软件的需求分析基本思想:
用抽象模型的概念,按照软件内部数据传递、变换的关系,自顶向下逐层分解,直到找到满足功能要求的所有可实现的软件为止。
遵循三条原则:
分解、抽象、映射,2022/10/21,41,SA方法的步骤,深入调查研究,分析用户需求,用DFD图描述,分析系统需求,用DFD图描述,修改完善DFD图,增添功能,2022/10/21,42,SA工具划分,功能分析工具:
数据流图DFD(DataFlowDiagram)、数据字典DD(DataDictionary)、结构化英语、判定表和判定树行为分析工具:
状态迁移图、Petri网等数据分析工具:
ER图或者EER(扩展ER)图SA主要针对数据处理领域,因此,系统分析的侧重点在于功能分析和数据分析,而行为分析使用得较少。
2022/10/21,43,数据流图:
功能建模,主要图形元素:
数据源点或终点(外部实体),数据流,数据加工(数据变换),数据存储文件,2022/10/21,44,数据流图示例:
银行取款,2022/10/21,45,DFD绘制要点,数据流图的主图必须包括前述四种基本元素,缺一不可每个加工至少有一个输入数据流和一个输出数据流可以采用层次结构的数据流图,按照系统的层次结构进行逐步分解。
初画时可以忽略琐碎的细节,以集中精力于主要数据流,2022/10/21,46,分层DFD示例:
商店业务处理系统,2022/10/21,47,分层DFD示例:
第一层数据流图,2022/10/21,48,分层DFD示例:
销售数据流图细化,2022/10/21,49,数据字典,数据词典与数据流图配合,能清楚地表达数据处理的要求。
数据字典定义(词条描述):
数据流:
名称、来源、数据结
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Chapter2 需求 分析 可行性 学时