软件工程4.ppt
- 文档编号:2683043
- 上传时间:2022-11-07
- 格式:PPT
- 页数:107
- 大小:3.91MB
软件工程4.ppt
《软件工程4.ppt》由会员分享,可在线阅读,更多相关《软件工程4.ppt(107页珍藏版)》请在冰豆网上搜索。
第四章第四章需求工程需求工程成功来之不易成功来之不易软件项目失败的原因软件项目失败的原因一些常见的情景需求错误的成本软件需求的重要性l软件需求是决定软件开发是否成功的一个关键因素需求分析可以帮助开发人员真正理解业务问题需求分析是估算成本和进度的基础需求分析可以避免建造错误的系统,从而减少不必要的浪费软件规格说明有助于开发人员与客户在“系统应该做什么”问题上达成正式契约需求分析形成了软件开发的基线,有助于管理软件的演化和变更软件需求是软件质量的基础,为系统验收测试提供了标准软件需求的重要性案例:
小型图书资料管理系统l问题描述某学院打算开发一个小型图书资料管理系统MiniLibraryMiniLibrary,该系统基于InternetInternet实现教师和学生对各种图书资料的借阅、查询和管理。
图书管理员负责管理各种图书资料,查询图书资料信息,并进行图书的借阅管理。
注册用户可以通过InternetInternet随时查询图书资料信息和个人借阅情况,预订目前借不到的图书资料,并可以快捷地查找和浏览所需要的电子资料。
系统可以提供适当的浏览器供用户阅读电子文献资料。
要求用户界面友好,响应速度快,具有良好的可扩展性。
内容提纲软件需求l软件需求用户解决问题或达到目标所需的条件或能力。
系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
一种反映上面或所描述的条件或能力的文档说明。
l对定义的理解软件需求的概念涵盖了用户角度(系统的外部行为)和开发人员角度(系统的内部特性)两个方面,其中的关键在于需求一定要文档化。
软件需求的不同层次业务需求l业务需求是组织或客户对于系统的高层次目标要求,定义了项目的远景和范围,即确定软件产品的发展方向、功能范围、目标客户和价值来源。
l业务需求的内容业务:
产品属于哪类业务范畴?
应该完成什么功能?
需要为什么服务?
客户:
产品为谁服务?
目标客户是谁?
特性:
产品区别于其他竞争产品的特性是什么?
价值:
产品的价值体现在什么方面?
优先级:
产品功能特性的优先级次序是什么?
业务需求:
MiniLibraryl业务要求各种图书资料的借阅、查询和管理;使用计算机实现图书资料的日常管理,提高工作效率和服务质量;用户通过网络查询和浏览电子资料,改变原有的借阅模式;由于版权的限制,某些电子资料只能让用户浏览和打印而不能下载。
l客户与用户学院的高层管理者图书管理员借阅者:
教师、学生用户需求l用户需求是从用户角度描述的系统功能需求和非功能需求,通常只涉及系统的外部行为,而不涉及系统的内部特性。
l用户需求的描述原则:
应该易于用户的理解。
一般不采用技术性很强的语言,而是采用自然语言和直观图形相结合的方式进行描述。
问题:
自然语言表达容易含糊和不准确。
用户需求:
MiniLibraryl举例:
用户可以通过InternetInternet随时查询图书信息和个人借阅情况,并可以快捷地查找和浏览所需要的电子资料。
l分析:
上述需求描述包含了三个不同的需求用户可以通过InternetInternet随时查询图书信息。
用户可以通过InternetInternet随时查询个人借阅情况。
用户可以通过InternetInternet快捷地查找和浏览所需要的电子资料。
l问题:
“随时”和“快捷”是对系统功能的约束,十分模糊。
系统需求l系统需求是更加详细地描述系统应该做什么,通常包括许多不同的分析模型,诸如对象模型、数据模型、状态模型等。
l系统需求模型的描述结构化英语(PDLPDL)可视化模型形式化方法l系统需求主要是面向开发人员进行描述,是开发人员进行软件设计的基础。
功能需求l功能需求描述系统应该提供的功能或服务,通常涉及用户或外部系统与该系统之间的交互,一般不考虑系统的实现细节。
l举例:
MiniLibraryMiniLibrary用户可以从图书资料库中查询或者选择其中的一个子集。
系统可以提供适当的浏览器供用户阅读电子文献。
用户每次借阅图书应该对应一个唯一的标识号,它被记录到用户的帐户上。
非功能需求l非功能需求从各个角度对系统的约束和限制,反映了应用对软件系统质量和特性的额外要求,例如响应时间、数据精度、可靠性、开发过程的标准等。
l举例:
MiniLibraryMiniLibrary系统应在2020秒之内响应所有的请求。
系统每周77天、每天2424小时都可以使用。
对于一个没有经验的用户而言,经过两个小时的培训就可以使用系统的所有功能。
非功能需求非功能需求思考问题l分析以下描述,它们是否属于需求?
普通读者必须注册成合法用户才可以使用该系统。
用户可以预订目前借不到的图书资料。
用户不希望自己的借阅记录被他人查阅。
系统通过ADOADO与图书资料数据库连接,并从图书资料数据表中获得图书资料的基本信息。
系统应该具有良好的可扩展性。
l思考:
如果所开发的软件系统只是简单地替代现行的手工操作方式,是否可行?
为什么?
软件需求的错误需求工程l需求工程是应用已证实有效的原理和方法,并通过合适的工具和符号,系统地描述出待开发系统及其行为特征和相关约束。
需求获取:
开发人员聆听客户的需求,观察用户的行为;需求分析:
分析和整理所收集的用户需求;需求规格说明:
以文档形式,精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件;需求验证:
使用评审和商议等有效手段对其进行验证,最终形成一个需求基线;需求管理:
在软件开发过程中有效地管理和控制需求变更。
需求工程过程内容提纲需求的来源l客户或用户学院的高层管理者、项目投资人系统管理员教师、学生、图书管理员l标准图书资料的标准l政策或法律图书资料管理规程、知识产权和版权保护等l系统或过程文档当前手工管理的文件、表格、记录等l相关领域的专家需求获取l需求获取应该识别项目相关人员的要求,解决不同项目相关人员之间的需求冲突。
l需求获取的困难用户通常并不真正知道自己希望计算机系统做什么用户通常使用业务语言表达需求,开发人员缺乏相关的领域知识和经验,难以准确理解这些需求不同的用户提出不同的需求,可能存在矛盾和冲突管理者可能出于增加影响力的原因而提出特别的需求由于经济和业务环境的动态性,需求经常发生变更需求获取需求获取技术l需求获取的关键在于通过与用户的沟通和交流,收集和理解用户的各项要求。
l需求获取技术用户面谈需求专题讨论会问卷调查现场考察原型化方法基于用例的方法用户面谈l用户面谈一种理解商业功能和商业规则的最有效方法l面谈过程需要认真的计划和准备面谈之前确立面谈目的确定要包括的相关用户确定参加会议的项目小组成员建立要讨论的问题和要点列表复查有关文档和资料确立时间和地点通知所有参加者有关会议的目的、时间和地点用户面谈l面谈过程需要认真的计划和准备(续)进行面谈衣着得体,准时到达寻找异常和错误情况深入调查细节详细记录指出和记录下未回答条目和未解决问题面谈之后复查笔记的准确性、完整性和可理解性把所收集的信息转化为适当的模型和文档确定需要进一步澄清的问题域适当的时候向参加会议的每一个人发一封感谢信需求专题讨论会l需求专题讨论会项目主要风险承担人在短暂而紧凑的时间段内集中在一起,一般为11至22天,与会者可以在应用需求上达成共识、对操作过程尽快取得统一意见。
l优点协助建立一支高效的团队,围绕项目成功的目标;所有的风险承担人都畅所欲言;促进风险承担人和开发团队之间达成共识;揭露和解决那些妨碍项目成功的行政问题;能够很快地产生初步的系统定义。
需求专题讨论会l专题讨论会准备参加会议人员:
主持人、用户、技术人员、项目组人员安排日程:
通常在具有相应支持设备的专用房间进行l举行会议可能出现行政间的责备或冲突,主持人应掌握讨论气氛并控制会场。
会议最重要的部分是自由讨论阶段,这种技术非常符合专题讨论会的气氛,并且营造一种创造性的和积极的氛围,同时可以获得所有相关者的意见。
注意分配会议时间,记录所有言论。
需求专题讨论会问卷调查l问卷调查可用于确认假设和收集统计倾向数据问卷需要快速回答,允许匿名方式l存在问题相关的问题不能事先决定问题背后的假设对答案造成偏颇,如这符合你的期望吗?
难以探索一些新领域难以继续用户的模糊响应l在完成最初的面谈和分析后,可作为一项协作技术可以收到良好的效果。
现场考察现场考察l现场观察商业过程和工作流程掌握用户如何实际使用一个系统以及到底用户需要哪些信息,最好的办法是亲自观察用户是如何完成实际工作的。
l一般方法对办公室进行快速浏览,了解布局、设备要求和使用、工作流总体情况。
安排几个小时观察用户是如何实际完成他们的工作,理解用户实际使用计算机系统和处理事务的细节。
像用户一样接受训练和做实际工作,发现关键问题和瓶颈。
l注意:
观察可能使用户紧张。
原型化方法l原型化方法一个软件原型是所提出的新产品的部分实现,帮助开发人员、用户以及客户更好地理解系统的需求,它比开发人员常用的技术术语更易于理解。
l建立原型的原因解决在产品开发的早期阶段需求不确定的问题,用户、经理和其他非技术项目风险承担者发现在确定和开发产品时,原型可以使他们的想象更具体化。
l基于WEBWEB的应用系统原型使用HTMLHTML进行界面设计需求获取的文档确定产品前景与项目范围识别和描述项目相关者问题描述理解项目相关者的要求理解项目相关者的要求建立用例模型l用例建模是以任务和用户为中心的,开发和描述用户需要系统做什么。
l用例建模的步骤确定系统的参与者确定场景确定系统用例确定用例之间的关系编写用例描述文档确定参与者l参与者是与系统交互的外部实体,它既可以是人员也可以是外部系统或硬件设备。
l确定参与者谁使用系统的主要功能?
谁需要系统的支持以完成日常工作任务?
谁从系统获取信息?
谁负责维护和管理系统以保证其正常运行?
系统需要应付(处理)哪些外部硬件设备?
系统需要和哪些外部系统交互?
MiniLibrary:
参与者确定场景l确定参与者和场景的关键在于理解业务领域,这需要理解用户的工作过程和系统的范围。
l确定场景的问题参与者希望系统执行的任务是什么?
参与者访问什么信息?
谁生成数据?
参与者需要通知系统的哪些外部变化?
(时间和频率)系统需要通知参与者什么事件?
(时间)MiniLibrary:
借书场景名称:
借书参与者实例:
BobBob,图书管理员;JohnJohn,普通读者事件流程:
1.John1.John向BobBob提供个人的注册号、所借图书的编号和书名等;2.Bob2.Bob在系统中查询该图书是否在图书馆;3.Bob3.Bob登记JohnJohn的借书记录,并将图书借给JohnJohn。
其他流程:
1.1.图书已被借出或者不存在:
BobBob告诉JohnJohn无法借出。
2.John2.John不是合法注册用户:
BobBob请求JohnJohn注册后在借书。
确定用例l用例描述了一个完整的系统事件流程,其重点在于参与者与系统之间的交互而不是内在的系统活动,并对参与者产生有价值的可观测结果。
l确定用例参与者需要从系统中获得什么功能?
参与者需要做什么?
参与者读取、产生、删除、修改或存储系统的某些信息吗?
系统中发生事件需要通知参与者吗?
参与者需要通知系统某件事情吗?
系统的输入/输出信息是什么?
这些信息从哪儿来到哪儿去?
采用什么实现方法满足某些特殊要求?
确定用例l可观测用例止于系统边界,描述交互而不是内在系统活动。
l结果值用例是目标导向的,参与者有一些需要使用它来满足的目标。
l系统执行结果值由系统生成l由角色观测业务语言(图书),而非技术语言(数据库表)用户观点(预订图书),而非系统观点(处理预订图书)l用例粒度粒度过细,陷入功能分解。
过细的粒度,一般都会导致技术语言的描述,而不再是业务语言。
确定用例的常见问题确定用例的常见问题l用户观点还是系统观点?
MiniLibrary:
用例l与“图书管理员”有关的用例管理读者:
在系统中维护普通读者的注册
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件工程
![提示](https://static.bdocx.com/images/bang_tan.gif)