您好,欢迎访问三七文档
当前位置:首页 > 建筑/环境 > 工程监理 > [软件工程]CH3-需求分析
2019/8/101第三章需求分析问题定义可行性研究可行否?否是需求分析终止项目......计划时期开发时期主要内容3.1需求分析概述3.2数据流图3.3数据字典3.4加工逻辑描述工具3.5结构化分析方法3.6需求规格说明书第5章需求工程与需求分析2019/8/1023.1.1需求分析的任务【可行性研究】粗略了解用户的需求。用较少的成本,在较短的时间内确定是否存在一些可行的解法。许多细节被忽略了。【需求分析】准确地回答“系统必须做什么?”这个问题。2019/8/1033.1.1需求分析的任务【依据】《可行性研究报告》【任务】⑴建立目标系统的逻辑模型调查分析用户的确切需求,认真搞清、并细化到底“系统必须做什么”?反复与用户交流;建立原型系统;确定目标系统的功能、性能、运行⑵形成《软件需求规格说明书》SoftwareRequirementSpecification2019/8/1043.1.2需求类型1.按内容分类软件需求代表系统的综合要求,包括以下几种类型:①系统功能需求系统功能需求指根据系统所能实现的功能要求,对于每一类功能或者有时对于每一个功能,需要弄清输入、加工和输出等需求。②系统性能需求按照系统的性能要求分类。例如联机系统的响应时间、系统需要的存储容量、后援存储器、重新启动、安全性和可靠性等方面的要求。③系统运行需求这类要求集中表现为对系统运行时所处的环境、使用的资源、安全保密和用户界面的要求。如支持系统运行的硬件和软件是什么,采取哪种数据库管理系统,需要什么样的外存储器和数据通信接口。④未来可能出现的问题就是把不属于当前系统开发范围的问题都明确地列出来,因为将来很可能会提出这些问题。这些问题主要是为了系统将来的扩充和修改做准备,当以后需要时就可以很容易地进行扩展和修改了。2019/8/1053.1.2需求类型(3)2.按用户的期望分类①正常需求用户陈述的针对系统的目标。②期望需求隐式的需求,可能由于是非常基础的而用户没有显示的陈述,如人机交互的容易性、整体的操作正确性和可靠性,以及软件安装的容易性。③兴奋需求在用户的期望范围之外,如果实现将令人愉快和出乎意料。2019/8/1063.1.2需求类型(4)3.按必要性分类①强制的需求是指除非软件与这些需求一致,则该软件是不可接受的②希望的需求是指这些需求将增进软件产品功能,但是如果缺乏的话也不是不可接受③任选的需求是指这个功能可有可无2019/8/107案例分析:机票订票系统1.功能需求在计算机网络,数据库和先进的开发平台上,利用现有的软件,配置一定的硬件,开发一个易扩充的、易维护的、具有良好人机交互界面的机票预定系统,实现航空公司的机票销售的自动化,为企业的决策层提供准确、精细、迅速的机票销售信息。根据可行性研究的结果和客户的要求,分析现有情况及问题,采用Client/Server结构,将机票预定系统划分为两个子系统:客户端子系统,服务器端子系统。正常、强制的需求2019/8/108案例分析:机票订票系统1.功能需求客户端子系统[1]旅客信息的输入和统计…[2]旅客信息的存储…[3]机票信息的传递及接收…[4]取票通知及帐单的生成和打印…[5]机票销售情况的核算…正常、强制的需求2019/8/109案例分析:机票订票系统1.功能需求服务器端子系统[1]接收由旅行社客户端发回的所需机票信息…[2]生成航班信息…[3]传递航班信息到客户端(旅行社)…[4]接收旅行社的反馈信息…[5]印出机票给已经订票的旅客…[6]销售额的分析和管理…正常、强制的需求2019/8/1010案例分析:机票订票系统(2)2.为了保证系统能够长期、安全、稳定、可靠、高效的运行,机票预定系统应该满足以下的性能需求:⑴系统处理的及时性和准确性在系统设计和开发过程中,要充分考虑系统当前和将来可能承受的工作量,使系统的响应时间能够满足企业对信息处理的需求。机票预定系统的查询功能对于整个系统的功能和性能完成举足轻重,是系统重要的数据来源。机票数量和时间又影响企业的决策活动,其准确性很大程度上决定了机票预定系统的成败。在系统开发过程中,必须采用一定的方法保证系统的准确性。2019/8/1011案例分析:机票订票系统(3)⑵系统的开放性和系统的可扩充性例如订票方式的改变(网上订票),用户查询需求的不断完善和更新等。所有这些,都要求系统提供足够的手段进行功能的调整和扩充。而要实现这一点,应通过系统的开放性来完成,既系统应是一个开放系统,只要符合一定的规范,配置系统的硬件,通过软件的修补、替换完成系统的升级和更新换代。2019/8/1012案例分析:机票订票系统(4)⑶系统的易用性和易维护性机票预定系统是直接面对使用人员的,而使用人员往往对计算机并不是非常熟悉。这就要求系统能够提供良好的用户接口,易用的人机交互界面。要实现这一点,就要求系统应该尽量使用用户熟悉的术语和中文信息的界面;针对用户可能出现的使用问题,要提供足够的在线帮助,缩短用户对系统熟悉的过程。机票预定系统中涉及到的数据是航空公司的相当重要的信息,系统要提供方便的手段供系统维护人员进行数据的备份,日常的安全管理,系统意外崩溃时数据的恢复等工作。2019/8/1013案例分析:机票订票系统(5)⑷系统的标准性系统在设计开发使用过程中都要涉及到很多计算机硬件、软件。所有这些都要符合主流国际、国家和行业标准。如规范的数据库操纵界面、作为业界标准的TCP/IP网络协议及ISO9002标准所要求的质量规范等;同时,在自主开发本系统时,要进行良好的设计工作,制订行之有效的软件工程规范,保证代码的易读性、可操作性和可移植性。2019/8/1014案例分析:机票订票系统(6)⑸系统的先进性目前计算系统的技术发展相当快,做为机票预定系统工程,应该保证系统在下个10年时间里仍旧是先进的,在系统的生命周期尽量做到系统的先进,充分完成企业信息处理的要求而不至于落后。这一方面通过系统的开放性和可扩充性,不断改善系统的功能完成。另一方面,在系统设计和开发的过程中,应在考虑成本的基础上尽量采用当前主流并先进且有良好发展前途的产品。2019/8/1015案例分析:机票订票系统(7)⑹系统的响应速度机票预定系统系统在日常处理中的响应速度为秒级,达到实时要求,以及时反馈信息。在进行统计分析时,根据所需数据量的不同而从秒级到分钟级,原则是保证操作人员不会因为速度问题而影响工作效率。2019/8/1016案例分析:机票订票系统(2)3.机票预定系统的运行需求:机票预定系统中的各个子系统的硬件和软件的配置如下:1.服务器端子系统的运行要求:系统软件:数据库管理系统:SQLServer硬件要求:2.客户端子系统的运行要求:系统软件:数据库管理系统:SQLServer硬件要求:2019/8/10177.7.4测试种类对以计算机为基础的系统进行充分的测试。⑴功能测试⑼可使用性测试⑵可靠性测试⑽可支持性测试⑶强度测试⑾安装测试⑷性能测试⑿过程测试⑸启动/停止测试⒀互连测试⑹恢复测试⒁兼容性测试⑺配置测试⒂文档测试⑻安全性测试2019/8/10183.1.3需求获取技术问题域用户需求分析员交流2019/8/1019案例分析:图书馆管理系统(1/3)读者管理书库管理读者借阅管理2019/8/1020用户项目负责人需求分析人员设计员案例分析:图书馆管理系统(2/3)1.建立联合小组参与者:用户、需求分析人员、设计人员。2019/8/1021案例分析:图书馆管理系统(3/3)2.会议讨论明确问题、范围、环境等,逐步了解用户需求会议应有记录,整理形成文档3.分成三小组读者管理、图书管理和读者借阅子系统4.总结各方成果形成结论性的SRS2019/8/1022需求分析工具RequisiteProClearQuestTrac2019/8/10233.1.4需求特性(1)正确性需求规格说明书中的功能、行为、性能描述必须与用户对目标软件产品的期望相吻合。(2)完整性需求规格说明书不能遗漏任何用户需求(3)可验证性需求规格说明书中的每一个需求,均应存在技术和经济上可行的手段进行验证和确认。2019/8/10243.1.4需求特性(2)(4)无歧义性需求规格说明书中使用标准化术语,用户、分析人员、设计人员和测试人员对需求规格说明书中的任何语法单位只能有唯一的语义解释。(5)一致性需求规格说明书的各部分之间不能相互矛盾。这些矛盾可以表现为术语使用方面的冲突,功能和行为方面的冲突,以及时序方面的前后不一致。(6)可理解性不宜在说明书中使用太多的专业化词汇。2019/8/10253.1.4需求特性(2)(7)可追踪性需求规格说明书必须将分析后获得的每项需求与用户的原始需求项清晰地联系起来,并为后续开发和其他文档引用这些需求项提供便利。(8)可修改性需求规格说明书的格式和组织方式应保证能够比较容易地接纳后续的增删和修改;使修改后的说明书能够较好地保持其他各项属性。2019/8/10263.1.5需求描述和分析技术1.问题分解2.抽象3.建模4.多视点分析2019/8/1027整个问题子问题1子问题3子问题21.问题分解什么是问题分解?将大问题分解为小问题,通过小问题解决来实现大问题的解决问题分解有助于降低解决问题的复杂度;获取和分析问题本身所固有的整体-部分关系;图书馆系统读者管理图书管理借阅管理2019/8/1028外表抽象外表脸形衣着黑胡子大脸2.问题抽象(1/2)什么是抽象?抽象有助于控制问题复杂度,抓住问题的本质;获取一般和特殊关系;2019/8/10292.问题抽象(2/2)读者抽象(提取成份)名字性别单位类别照片Email电话读者抽象(抛弃成份)身高年龄……2019/8/10303.需求建模(1/2)什么是需求模型模型是对现实的简化,包含有主要影响的要素,忽略不相关的次要因素需求模型详细、准确地描述了用户对目标软件系统的功能、行为、性能、设计约束等方面的要求为什么需要建模从多个视点、多个不同的抽象层次来描述用户需求,从而更好促进软件的开发需求建模方法面向数据流的方法面向对象的方法注意需求建模不要涉及软件设计和实现细节2019/8/10314.多视点分析什么是多视点分析从多个角度、不同层面上分析和描述用户需求为什么需要多视点分析人的认识具有片面性(瞎子摸象)多视点可以帮助我们全面把握用户的需求2019/8/10323.1.6需求分析的步骤⑴分析系统的要求⑵目标系统的逻辑模型⑶修正开发计划⑷构造原型系统⑸复审、验证《软件需求规格说明书》必须处理的信息和应该产生的信息数据流图、数据字典、加工处理用户了解目标系统的功能、概况开发者快速、准确、完整把握需求2019/8/10333.2数据流图数据流图(DateFlowDiagram)描述软件系统逻辑模型的技术。【功能】描绘信息在系统中流动和加工处理的情况。【注意】只要考虑系统必须完成的基本逻辑功能;不要考虑如何具体地实现这些功能;极好的交流和沟通工具2019/8/10343.2数据流图数据流图(DateFlowDiagram)【符号】①数据的源点、终点系统以外的人、事物②加工处理不一定是一个程序③数据存储数据库、数据文件④数据流数据在系统中流动的方向数据描述2019/8/10353.2数据流图数据流图(DateFlowDiagram)【扩展符号】*(星号)表示数据流之间是“与”关系T*ABCTAC*数据A和B同时输入才能变换成数据C数据A变换成数据B和C与B2019/8/10363.2数据流图数据流图(DateFlowDiagram)【扩展符号】+(加号)表示数据流之间是“或”关系T+ABCTAC+数据A、数据B
本文标题:[软件工程]CH3-需求分析
链接地址:https://www.777doc.com/doc-165735 .html