《软件工程》教学课件05软件需求分析.ppt

上传人:牧羊曲112 文档编号:6529316 上传时间:2023-11-09 格式:PPT 页数:82 大小:273.16KB
返回 下载 相关 举报
《软件工程》教学课件05软件需求分析.ppt_第1页
第1页 / 共82页
《软件工程》教学课件05软件需求分析.ppt_第2页
第2页 / 共82页
《软件工程》教学课件05软件需求分析.ppt_第3页
第3页 / 共82页
《软件工程》教学课件05软件需求分析.ppt_第4页
第4页 / 共82页
《软件工程》教学课件05软件需求分析.ppt_第5页
第5页 / 共82页
点击查看更多>>
资源描述

《《软件工程》教学课件05软件需求分析.ppt》由会员分享,可在线阅读,更多相关《《软件工程》教学课件05软件需求分析.ppt(82页珍藏版)》请在三一办公上搜索。

1、,SOFTWARE ENGINEERING,The Definition Phase,System Engineering,Software project planning,Software requirements analysis,Software scope,Refined,确定做什么?,SOFTWARE ENGINEERING,软件需求分析,众所周知,在解决问题之前必须首先理解所要解决的问题。对问题理解得越透彻,就越容易解决它。当我们完全、彻底地理解了一个问题的时候,通常就已经解决了这个问题。,SOFTWARE ENGINEERING,软件需求分析,为了更好地理解问题,人们常常采用建

2、立问题模型的方法。所谓模型,就是为了理解事物而对事物作出的一种抽象,是对事物的一种无歧义的书面描述。通常,模型由一组图示符号和组织这些符号的规则组成,利用它们来定义和描述问题域中的术语和概念。更进一步讲,模型是一种思考工具,利用这种工具可以把知识规范地表示出来。,SOFTWARE ENGINEERING,软件需求分析,模型可以帮助我们思考问题、定义术语、在选择术语时作出适当的假设,并且可以帮助我们保持定义和假设的一致性。在对目标系统进行分析的初始阶段,面对大量模糊的、涉及众多专业领域的、错综复杂的信息,系统分析员往往感到无从下手。模型提供了组织大量信息的一种有效机制。,SOFTWARE ENG

3、INEERING,软件需求分析,为了开发复杂的软件系统,系统分析员应该从不同角度抽象出目标系统的特性,使用精确的表示方法构造系统的模型,验证模型是否满足用户对目标系统的需求,并在设计过程中逐渐把和实现有关的细节加进模型中,直至最终用程序实现模型。,SOFTWARE ENGINEERING,软件需求分析,对于那些因过分复杂而不能直接理解的系统,特别需要建立模型,建模的目的主要是为了减少复杂性。人的头脑每次只能处理一定数量的信息,模型通过把系统的重要部分分解成人的头脑一次能处理的若干个子部分,从而减少系统的复杂程度。,SOFTWARE ENGINEERING,软件需求分析,一旦建立起模型之后,这个

4、模型就要经受用户和各个领域专家的严格审查。由于模型的规范化和系统化,因此比较容易暴露出系统分析员对目标系统认识的片面性和不一致性。通过审查,往往会发现许多错误,发现错误是正常现象,这些错误可以在成为目标系统中的错误之前,就被预先清除掉。,SOFTWARE ENGINEERING,软件需求分析,通常,通过快速建立原型,让用户和领域专家经过亲身体验,对系统模型进行更有效的审查。模型常常会经过多次必要的修改,通过不断改正错误的或不全面的认识,最终,软件开发人员对问题有了透彻的理解,从而为后续的开发工作奠定了坚实基础。,SOFTWARE ENGINEERING,软件需求分析的任务,为了开发出真正满足用

5、户需求的软件产品,首先必须确切地知道用户的需求。对软件需求的深入理解,是软件开发工作获得成功的前提和关键,不论我们把设计和编码工作做得多么出色,不能真正满足用户需求的软件只会给用户带来失望,给开发者带来烦恼。需求分析是软件定义时期的最后一个阶段,它的基本任务是准确地回答“系统必须做什么?”这个问题。,SOFTWARE ENGINEERING,软件需求分析的任务,需求分析是定义软件的最后一个阶段,也是最重要的一个阶段,其基本任务是对目标系统提出完整、准确、清晰、具体的要求。需求分析的结果是系统开发的基础,关系到工程的成败和软件产品的质量。因此,必须采取行之有效的办法对需求分析进行严格的审查和验证

6、。Boehm对软件需求的定义:研究一种无二义性的表达工具,它能为用户和软件人员双方都接受并能够把“需求”严格地、形式地表达出来。,SOFTWARE ENGINEERING,软件需求分析,在编程过程中,事情总是会变得清晰;只有在检验了软件的早期版本后项目共利益者才能够更好地理解需求;事情变化太快,需求工程是浪费时间;底线是开发一个可运行的程序,其他都是次要的。构成这些论点的原因在于其中也包含了部分的真实情况(尤其是不超过一个月的小项目)。,SOFTWARE ENGINEERING,信息技术项目成功的3要素,用户参与程度高级管理层的支持明确的需求说明,SOFTWARE ENGINEERING,软件

7、需求分析的困难,懂得应用领域专业知识的人很可能不是实际编写软件的人。这些应用领域的专家因而必须将他们的需求告诉软件开发的技术人员。口头、书面语言中所固有的模糊性给领域专家与开发软件的技术人员之间的交流增添了一层复杂性。我们都拥有自己不同的背景知识,它导致基于以往的经验对相同的现象做出不同的解释。,SOFTWARE ENGINEERING,软件需求分析的困难,在系统开发的每个阶段应该让未来用户参与,不论这些未来用户是否是领域专家。在软件开发过程中,软件开发的计划有必要允许最终用户来评价该系统。不幸的是,许多软件企业的人相信只需要在系统开发早期阶段和开发完成时,向用户了解专业知识。这种态度很可能会

8、导致许多软件开发项目的失败。,SOFTWARE ENGINEERING,软件需求分析的任务,1、确定系统的综合要求系统功能要求系统性能要求:如响应时间、存储容量、安全性能等。系统运行要求:主要是对系统运行时的环境要求,如系统软件、外存和数据通信接口等。将来可能提出的要求:为扩充及修改作准备。2、分析系统的数据要求3、导出系统的逻辑模型:用DFD、DD等描述4、修正系统的开发计划:通过需求对系统的成本及进度有了更精确的估算,可进一步修改开发计划。,SOFTWARE ENGINEERING,软件需求分析的任务-分析系统的数据要求,任何一个软件系统本质上都是信息处理系统,系统必须处理的信息和系统应该

9、产生的信息在很大程度上决定了系统的面貌,对软件设计有深远影响,因此,必须分析系统的数据要求,这是软件需求分析的一个重要任务。,SOFTWARE ENGINEERING,Software Requirements Analysis软件需求分析,有几种原因使需求分析变得困难:(1)客户说不清楚需求或无需求,用户意见不统一,错误的需求等;(2)需求自身经常变动;(3)分析人员或客户理解有误,缺乏共同语言,交流障碍。让我们先接受“需求会变动”这个事实吧,免得在需求变动时惊慌失措。错误观点:反正“需求会变动”,软件也很灵活,所以只做简单的需求分析就开始编程更有效。,SOFTWARE ENGINEERIN

10、G,Software Requirements Analysis软件需求分析,如果客户本身就懂软件开发,能把需求说得清清楚楚,这样的需求分析将会非常轻松、愉快。如果客户全不懂软件,但信任软件开发方,这事也好办。分析人员可以引导客户,先阐述常规的需求,再由客户否定不需要的,最终确定客户真正的需求。最怕的就是“不懂装懂”或者“半懂充内行”的客户,他们会提出不切实际的需求。如果这些客户甚至觉得自己是上帝的父母,那么沟通和协商都会很困难。,SOFTWARE ENGINEERING,Software Requirements Analysis软件需求分析,在进行需求分析时必须注意:(1)尽可能地分析清楚

11、哪些是稳定的需求,哪些是易变的需求。以便在进行系统设计时,将软件的核心建筑在稳定的需求上。(2)在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊,日后扯皮的事情就多。,SOFTWARE ENGINEERING,Software Requirements Analysis软件需求分析,系统分析人员不可能都是全才。客户表达的需求,不同的分析人员可能有不同的理解。如果分析人员理解错了,可能会导致开发人员白干活。所以分析人员写好需求说明书后,要请客户方的各个代表验证。如果问题很复杂,双方都不太明白,就有必要请开发人员快速构造软件的原型,双方再次论证需求说明书是否正确。由于客户大多不懂软件

12、,他们可能觉得软件是万能的,会提出一些无法实现的需求。有时客户还会把软件系统分析人员的建议或答复给想歪了。,SOFTWARE ENGINEERING,Software Requirements Analysis软件需求分析,应该先了解宏观的问题,再了解细节的问题。了解需求的方式有好几种:(1)直接与客户交谈。(2)有些需求客户讲不清楚,分析人员又猜不透,这时就要请教专家。(3)有很多需求可能客户与分析人员想都没有想过。要经常分析优秀的和蹩脚的同类软件,看到了优点就尽量吸取,看到了缺点就引以为戒。,SOFTWARE ENGINEERING,Analysis Concept and Princip

13、les,A complete understanding of software require-ments is essential to the success of a software development effort.The requirements analysis task is a process of discover,refinement,modeling,and specification.Both the developer and customer take an active role in requirements analysis and specifica

14、tion.Requirements analysis is a software engineering task that bridges the gap between system-level software allocation and software design.,SOFTWARE ENGINEERING,Software Requirements Analysis,Requirements analysis enables the system engineer to specify software function and performance,indicate sof

15、twares interface with other system elements,and establish constraints that software must meet.Requirements analysis allows the software engineer(often called analyst in this role)to refine the software allocation and build models of the data,functional,and behavioral domains that will be treated by

16、software.,SOFTWARE ENGINEERING,Software Requirements Analysis,Requirements analysis provides the software designer with models that can be translated in to data,architectural,interface,and procedural design.Finally,the requirements specification provides the developer and the customer with the means

17、 to access quality once software is build.,SOFTWARE ENGINEERING,系统分析员应有的能力,分析、综合、抽象能力;较好的口头和书面表达能力;很强的专业基础和软件过程经验;所开发的项目的专业背景,等。分析员通常负责开发软件需求规格说明书,并参加所有的复审制定软件需求规格说明书,不仅仅是软件开发人员的事,用户也起着至关重要的作用。,SOFTWARE ENGINEERING,Software Requirements Analysis,Software requirements analysis may be divided into fiv

18、e areas of effort:Problem recognition(问题识别);Evaluation(评价)and synthesis(综合);Modeling(建模);Specification(软件需求规格说明);andReview(评审或复审).,SOFTWARE ENGINEERING,Problem recognition,Initially,the analyst studies the system speci-fication(if one exists)and the software project plan.It is important to understan

19、d software in a system context and to review the software scope that was used to generate planning estimates.Next,communication for analysis must be established so that problem recogn-ition is ensured.The goal of analyst is recogn-ition of the basic problem elements as perceived by the user/customer

20、.,SOFTWARE ENGINEERING,Evaluation and synthesis,Throughout evaluation and solution synthesis,the analysts primary focus is on“what,”not“how.”what data does the system produce and consume,what functions must the system perform,what interface are defined,and what constraints apply?During evaluation an

21、d solution synthesis activity,the analyst creates models of the system in an effort to better understand data and control flow,functional processing and behavioral operation,and information content.,SOFTWARE ENGINEERING,Communication Techniques,Facilitated Application Specification Techniques(FAST:方

22、便的应用规范技术):This approach encourages the creation of a joint team of customers and developers who work together to identify the problem,propose elements of the solution,negotiate different approach,and specify a preliminary set of solution requirements.,SOFTWARE ENGINEERING,Communication Techniques,Qu

23、ality Function Deployment(QFD)is quality management technique that translates the needs of the customer into technical require-ments for software.QFD emphasizes understanding of what is valuable to the customer and then deploying these value throughout the engineering process.QFD identifies three ty

24、pes of requirements:1)Normal;2)Expected;3)exciting.,SOFTWARE ENGINEERING,Analysis Principles,The information domain of a problem must be represented and understood.The function must is defined.The behavior of software must be represented.The models must be partitioned in a manner that uncovers detai

25、ls in a layered fashion.The analysis process should move from essential information toward implementation detail.,SOFTWARE ENGINEERING,Essential and Implementation Views,An essential view of software requirements presents the functions to be accomplished and information to be process without regard

26、to implementation.The implementation view of software require-ments presents the real world manifestation of processing functions and information structures.In some cases,a physical representation is developed as the first step in software design.,SOFTWARE ENGINEERING,The Software Requirements Speci

27、fication,软件计划,系统定义,需求分析,商业需要,其他系统元素(硬件等)的功能,代价、资源、进度,软件功能,软件作用范围,软件需求规格说明书,SOFTWARE ENGINEERING,The Software Requirements Specification,最好全部由用户/需求者编写,但实际上都由开发者和用户/需求者共同编写。该说明书是分析和综合结果的描述,包括软件功能、性能、接口、有效性和逻辑模型的描述软件需求规格说明书的描述方法:自然语言格式化语言形式化语言,SOFTWARE ENGINEERING,The Software Requirements Specificatio

28、n(SRS outline),IntroductionInformation descriptionFunctional descriptionBehavioral descriptionValidation criteriaBibliographyAppendix,编写初步用户使用手册和确认测试计划,SOFTWARE ENGINEERING,The Software Requirements Specification,正确性无二义性完整性一致性非计算机人员可以理解可修改性可跟踪性,SOFTWARE ENGINEERING,Specification Review,复审:该阶段完成标志(由用

29、户/需求者,管理部门,开发人员共同承担)Review of a software requirements specifica-tion(and/or prototype)is conducted by both software developer and customer.Because the specification forms the foundation for design and subsequent software engineering activities,extreme care should be taken in conducting the review.,S

30、OFTWARE ENGINEERING,Specification Review,采用需求确认检查单进行需求评审正式技术评审,SOFTWARE ENGINEERING,验证软件需求的原则,作为需求分析阶段工作的复查手段,应该对功能的正确性、完整性和清晰性以及其他需求给予评价。一致性:所有的需求是一致的,没有任何矛盾。完整性:需求必须是完整的,没有任何功能和性能的遗漏。现实性:完成需求所要求的软件和硬件条件,目前是可以达到的。有效性:需求是有效的,可以解决用户的问题。,SOFTWARE ENGINEERING,Summary,Analysis must focus on the informat

31、ion,functional,and behavioral domains of a problem.To better understand what is required,models are created,the problem is partitioned,and representations that depict the essence of requirements and later,implementation detail,are developed.,SOFTWARE ENGINEERING,Summary,In many cases,it is not possi

32、ble to completely specify a problem at an early stage.Prototyping offers an alternative approach that results in an executable model of software from which requirements can be refined.开发原型系统将使系统的需求更完整、准确、合理,对提高开发成功率,对提高软件质量都有很大好处。但是要增加开发的成本。对于用户和系统分析员都不熟悉的系统,以及批量生产的软件,应开发原型系统。,SOFTWARE ENGINEERING,S

33、ummary,A software requirements specification is developed as a consequence of analysis.Review is essential to ensure that developer and customer have the same perception of the system.Unfortunately,even with the best of methods,the problem is that problem keeps changing.,SOFTWARE ENGINEERING,需求分析方法(

34、1),功能分析方法(Function Decomposition)以系统需要提供的功能为中心来组织系统。首先定义各种功能,然后把功能分解为若干子功能,同时定义功能之间的接口。子功能还可继续分解。数据结构是根据功能/子功能的需要设计的。易开始,难深入,也难于检验分析结果的正确性,同时对需求变化的适应能力差,局部错误和局部修改很容易产生全局性的影响。,SOFTWARE ENGINEERING,需求分析方法(2),结构化分析方法(数据流法)其基本策略是跟踪数据流,从问题空间到某种表示的映射方法,由数据流图(DFD图)表示。SA法更加强调问题域的研究,有严格的原则,当系统较复杂时,很难检验分析的正确性

35、,对需求变化的适应能力较差,没有一种严格的、可操作的转换规则,所以从分析到设计的过渡比较困难。,SOFTWARE ENGINEERING,需求分析方法(3),信息建模法 是从数据的角度对现实世界建立模型的,基本工具是E-R图。面向对象的分析方法 面向对象的分析方法(OOA)的关键是识别问题域内的对象,分析它们之间的关系,并建立起系统模型。OOA采用封装、继承、消息通信等原则,使问题域的复杂性得到了控制。-UML,SOFTWARE ENGINEERING,Analysis Modeling,Structured Analysis(SA):is a classical modeling metho

36、dObject-Oriented Analysis(OOA)Other analysis method:Data Structured Systems Development(DSSD);Jackson System Development(JSD);Structured Analysis and Design Technique(SADT),SOFTWARE ENGINEERING,Analysis Modeling,The analysis model must achieve three primary objectives:(1)to describe what the custome

37、r requires,(2)establish a basis for the creation of a software design,and(3)to define a set of requirements that can be validated once the software is built.,SOFTWARE ENGINEERING,结构化分析方法(SA),结构化开发方法(Structured Develop-ing Method)是现有的软件开发方法中最成熟、应用最广泛的方法,主要特点是快速、自然和方便。结构化开发方法由结构化分析方法(SA法)、结构化设计方法(SD法)

38、及结构化程序设计方法(SP法)构成。,SOFTWARE ENGINEERING,结构化分析方法(SA),结构化分析方法是面向数据流的需求分析方法。SA法是一种建模的活动,主要是根据软件内部的数据传递、变换关系,自顶向下逐层分解,描绘出满足功能要求的软件模型。SA法的描述方法:1、分层的数据流图;2、数据词典;3、描述加工逻辑的结构化语言、判定表及判定树等,SOFTWARE ENGINEERING,The elements of the analysis model,Data Flow Diagram(DFD)/Data Dictionary(DD)/Process SpecificationE

39、ntity-Relationship Diagram(ERD)/Data Object DescriptionState-Transition Diagram(STD)/Control Specification,SOFTWARE ENGINEERING,Data Flow Diagram(DFD),Information is transformed as it flows through a computer-based system.The system accept input in a variety of forms;applies software,hardware,and hu

40、man elements to transform input into output;and produces output in a variety of forms.A data flow diagram(DFD)is a graphical technique that depicts information flow and transforms that are applied as data move from input to output.,SOFTWARE ENGINEERING,软件模型,计算机系 统,变换,输入,输入,输出,输出,信息系统模型,软件模型,通常从数据流图的

41、输出端着手分析,这是因为系统的目标是产生这些输出,输出数据确定了系统必须具有的最基本的组成元素。,SOFTWARE ENGINEERING,Data Flow Diagram(DFD),Data store,Data object,process,External entity,A data object;the arrowhead indicates the direction of data flow,A transformer of information(a function)that resides within the bounds of the system to be mode

42、led,A producer or customer of information that resides outside the bounds of the system to be modeled.,A repository of data that is to be stored for use by one or more processes;may be as simple as a buffer or a queue or as sophisticated as a relation database,SOFTWARE ENGINEERING,Data Flow Diagram(

43、DFD),The DFD enables the software engineer to develop models of the information domain and function domain at the same time.数据流图(Data Flow Diagram)描绘系统的逻辑模型,只描绘数据在系统中的流动和处理情况,可不考虑具体的处理细节。,SOFTWARE ENGINEERING,DFD:命名,数据流的命名:名字(name)应代表整个数据流的内容;不要空洞、泛指,要有具体含义;如果对某个数据流命名有困难时,应重新分解;命名不能有二义性。处理的命名:通常应先为数

44、据流命名再为与之相关的处理命名;名字应反映整个处理的功能而不是一部分;名字最好由一个具体的及物动词和一个具体的宾语组成;通常名字中只包括一个动词;如果对某个处理命名有困难时,应重新分解。,SOFTWARE ENGINEERING,Data Flow Diagram(DFD),A level 0 DFD,also called a fundamental system model or a context model,represents the entire software element as a single bubble with input and output data indic

45、ated by incoming and outgoing arrows,respectively.It is important to note that no explicit indication of the sequence of processing is supplied by diagram.Explicit procedural representation is generally delayed until software design.,SOFTWARE ENGINEERING,DFD Refinement,Each of the bubbles may be ref

46、ined or layer-ed to depict more detail.Note that informa-tion flow continuity must be maintained,that is,input and output to each refinement must remain the same.This concept,sometimes called balancing.A data flow diagram depicts information flow without explicit representation of procedure logic(e.

47、g.,conditions or loops).,SOFTWARE ENGINEERING,DFD的分层细化,DFD必须逐步分层细化(一般要经过多次反复),以达到可以找出“可实现的软件元素”的程度细化准则1)第0层均是基本软件模型2)仔细说明原始的输入/输出文件3)箭头、圆圈应加有意义的名字4)每一次只能加工一个圆圈5)保持信息的连续性(完全相同或匹配),SOFTWARE ENGINEERING,DFD的分层细化,The refinement of DFDs continues until each bubble performs a simple function,that is,until

48、 the process represented by the bubble performs a function that would be easily implemented as a program component.These is a tendency to overcomplicate the DFD.,SOFTWARE ENGINEERING,DFD实例,验证定单的正确性,汇总对各出版社的要求,顾客,出版社,顾客档案,图书目录,待处理定单,定货存根,出版社档案,顾客信用情况,定单,图书目录,正确定单,一批定单,出版社信息,对出版社的定单,定货信息,图书预定系统的DFD图,S

49、OFTWARE ENGINEERING,旅行社,预定机票,准备机票,记账,旅客,航班目录,记账文件,订票单,航班,费用,机票,DFD实例,SOFTWARE ENGINEERING,The Data Dictionary,数据字典(DD)是数据的信息的集合,即对数据流图中包含的所有元素(element)的定义的集合。数据字典最重要的用途是作为分析阶段的工具。在数据字典中建立一组严密一致的定义,有助于分析员与用户通信、交流,消除误解。数据字典(DD)包括DFD中1)数据元素(如:电话号码)2)数据结构(如:图书目录)3)数据文件(如:顾客档案)4)数据流(如:正确定单)的定义,SOFTWARE E

50、NGINEERING,The Data Dictionary,Most contain the following information:1)name2)alias3)where-used/how-used4)content description5)supplementary information:data types,preset values,restrictions or limitations,etc.,SOFTWARE ENGINEERING,The Data Dictionary,数据字典的表示:自学例如,数据项词条描述包括:数据项名,类型:数字(离散值,连续值)、文字(编码

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 生活休闲 > 在线阅读


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号