软件需求工程精.ppt

软件需求工程第1页，本讲稿共56页课程提纲课程提纲1.1.软件需求基本理论和概念软件需求基本理论和概念 2.2.软件需求工程过程软件需求工程过程 3.3.软件需求获取软件需求获取 4.4.软件需求分析软件需求分析 5.5.软件需求规格说明软件需求规格说明 6.6.软件需求验证软件需求验证 7.7.软件需求管理软件需求管理 8.8.软件需求实现软件需求实现 9.9.软件需求工程新进展软件需求工程新进展 10.10.软件需求开发与需求管理工具软件需求开发与需求管理工具第2页，本讲稿共56页内容提要n需求分析面临的困难需求分析面临的困难n需求分析基本方法和工具需求分析基本方法和工具n数据需求分析数据需求分析n功能需求分析功能需求分析n非功能性需求分析非功能性需求分析n实时系统需求分析实时系统需求分析n基于基于USE CASEUSE CASE的需求分析的需求分析n基于原型方法的分析基于原型方法的分析第3页，本讲稿共56页需求分析需求分析n分析是指通过对分析是指通过对问题域问题域的研究的研究,获得对该领获得对该领域特性及存在于其中的待解决的问题特性域特性及存在于其中的待解决的问题特性的透彻理解并用文档说明。的透彻理解并用文档说明。n需求分析是前面需求获取阶段的继续，通需求分析是前面需求获取阶段的继续，通过对所获取的信息进一步加工获得对系统过对所获取的信息进一步加工获得对系统的更精确描述，成为转换成需求规格说明的更精确描述，成为转换成需求规格说明的直接信息元。的直接信息元。n但是否将需求分析作为独立的过程？但是否将需求分析作为独立的过程？第4页，本讲稿共56页需求分析的关键点需求分析的关键点n问题域的结构问题域的结构n问题域的数据问题域的数据n问题域的行为问题域的行为n问题域的事件问题域的事件n问题域的状态问题域的状态n派生需求派生需求只是只是针对问题域针对问题域吗？吗？第5页，本讲稿共56页一.需求分析面临的困难n n需求分析是一个项目的开端，也是项目建设的基石。在失败的项目中，80是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。n n由于软件项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又面临着很多困难。第6页，本讲稿共56页二.需求分析基本方法和工具图图1 软件需求工程的组成软件需求工程的组成获取需求工程需求开发需求管理分析分析 编写规约 确认n n绘制关联图绘制关联图n n创建用户界面和技术原创建用户界面和技术原型型n n分析需求的可行性分析需求的可行性n n确定需求的优先级确定需求的优先级n n为需求建模为需求建模n n创建数据字典创建数据字典n n将需求分解到子系统将需求分解到子系统n n应用质量功能调配应用质量功能调配需求分析包括：需求分析包括：需求分析包括：需求分析包括：第7页，本讲稿共56页分析方法分析方法n结构化分析结构化分析n面向对象分析面向对象分析第8页，本讲稿共56页分析模型描述工具n n结构化分析工具DFD、DD和PSPEC CFD、CSPEC和STD E-R图 n n面向对象分析工具用例图，类图，对象图对象-关系图对象-行为图第9页，本讲稿共56页需求分析建模工具需求分析建模工具n数据流图数据流图n实体关系图实体关系图n状态转换图状态转换图n对话图对话图n类图类图nPetri Net第10页，本讲稿共56页建模技术建模技术n面向处理技术面向处理技术Context diagram 上下文图上下文图Data flow diagram(DFD)数据流图数据流图流程图流程图n面向数据结构技术面向数据结构技术E-R D-Entity Relationship Diagramsn面向对象建模面向对象建模处理和数据相结合处理和数据相结合Object and Class 对象和类的技术对象和类的技术第11页，本讲稿共56页需求分析基本方法 结构化分析方法结构化分析方法(SA)(SA)n结构化分析（Structured Analysis,简称SA法）的基本思想：“分解”和“抽象”n分解：把系统的复杂性降低到可以掌握的程度，把大问题分解成若干小问题，然后分别解决。n n抽象：即先考虑问题最本质抽象：即先考虑问题最本质的属性，暂把细节略去，以的属性，暂把细节略去，以后再逐层添加细节，直至涉后再逐层添加细节，直至涉及到最详细的内容。及到最详细的内容。图4 自顶向下逐层分解第12页，本讲稿共56页数据流图数据流图DFDn n描述系统逻辑模型信息在系统中的流动和处理n n用途交流信息的工具结构化分析和设计的工具第13页，本讲稿共56页数据流图数据流图DFDn n组成符号圆框代表加工圆框代表加工箭头代表数据流向箭头代表数据流向方框代表源点和终点方框代表源点和终点双杠表示数据文件或数据库双杠表示数据文件或数据库n n分层从高层到低层从高层到低层分解前后的数据流必须一致分解前后的数据流必须一致n n命名数据流数据流处理处理第14页，本讲稿共56页数据流图 DFD练习练习售书系统售书系统领书单领书单 进书通知进书通知 购书单购书单 缺书单缺书单 学学生生教材教材购销购销系统系统书书 库库保保 管管员员图5 售书系统顶层数据流图第15页，本讲稿共56页数据流图 DFDDFD练习练习售书系统售书系统领书单领书单 进书通知进书通知 进书通知进书通知 购书单缺书单购书单缺书单 1销销售售 2采采购购书库书库保保管管员员学学生生F1教材存量表教材存量表 F2缺书登记表缺书登记表 第16页，本讲稿共56页功能需求分析 加工说明PSPECn n加工说明PSPEC说明DFD中的每个加工n n描述工具结构化语言判定表判定树第17页，本讲稿共56页处理方法：事件列表与功能列表n n事件就是要求系统执行某项功能的请求n n业务事件与产品事件n n对复杂的业务任务采用任务说明、用例说明或数据流图等方法进行解释。n n对复杂的功能采用数据流图、算法描述、活动图、数学说明等进行解释。第18页，本讲稿共56页处理方法：事件列表与功能列表n n事件及功能列表的优点主要作为核对清单，以说明应开发什么。其中对这些主要作为核对清单，以说明应开发什么。其中对这些功能的详细说明构成了功能需求的主要部分。功能的详细说明构成了功能需求的主要部分。开发人员可以方便的检查产品是否实现每一个功能。开发人员可以方便的检查产品是否实现每一个功能。用户能够在某种程度上确认业务事件和任务列表。用户能够在某种程度上确认业务事件和任务列表。n n通过一致性检查确定列表是否完备。第19页，本讲稿共56页数据需求分析 数据字典数据字典DDDDn nDFD中所有元素的定义的集合n n内容数据流数据流分量数据存储处理（一般不用DD描述）n n定义数据的方法自顶向下分解数据第20页，本讲稿共56页数据需求分析 数据字典DDDDn n数据元素的组合方式顺序：A+B选择：A|B重复：1A5可选：（A）n nDD的用途分析阶段的交流工具包含控制信息数据库设计的基础第21页，本讲稿共56页E-R图n n用于对复杂数据的数据分析和建模n n实体、属性和关系n n组成符号0：11：10：m1:m第22页，本讲稿共56页E-R图例子电话机电话机生产厂商生产厂商经销商经销商用户用户生生产产购购买买使用使用经销经销第23页，本讲稿共56页数据需求与功能需求的区别n n数据需求指定了系统的存储数据。n n功能需求则说明数据的用途，以及如何记录、计算、转换、修改及传输数据等。数据需求与功能需求的区别：第24页，本讲稿共56页状态迁移图 STDn nSTD(State Transition Diagram)n n描述软件状态变迁n n符号表示矩形-系统状态箭头-状态转变方向规则表达式-事件/触发行为状状 态态1状状 态态2事件事件/触发行为触发行为第25页，本讲稿共56页状态迁移图 STDSTD例子例子20秒到/翻屏生成最新数据/翻屏半小时到/工控处理半分钟到/传送空闲/采集物品经过/计数采集PLC计数传送工控处理实时翻屏第26页，本讲稿共56页上下文图n n作用上下文图能很好地概括产品的必要接口，初步确定产品包含了哪些内容，产品之外又包含哪些内容。即说明产品及其环境的视图。说明产品的范围。n n优点：上下文图为开发任务概括了所有的接口，在开发中或开发后，方便地验证是否已经处理了所有接口。用户容易理解，并发现遗漏的接口。第27页，本讲稿共56页对话图对话图n对话图代表了一个高层抽象的用户界面体系结构。对话图代表了一个高层抽象的用户界面体系结构。n对话图描绘了系统中的对话元素和它们之间的导航连接，但它没有对话图描绘了系统中的对话元素和它们之间的导航连接，但它没有揭示具体的屏幕设计。揭示具体的屏幕设计。n对话图可以使你在对需求的理解上探索假设的用户界面概念。对话图可以使你在对需求的理解上探索假设的用户界面概念。n用户和开发者可以通过对话图在用户如何利用系统执行任务上达成共用户和开发者可以通过对话图在用户如何利用系统执行任务上达成共同的视觉界面。同的视觉界面。n对话图与系统情节叙述相关联，这些叙述还包括对每一个屏幕意图对话图与系统情节叙述相关联，这些叙述还包括对每一个屏幕意图的简短说明。的简短说明。n对话图抓住了用户一系统交互作用和任务流的本质，而不会使你太对话图抓住了用户一系统交互作用和任务流的本质，而不会使你太快陷入到屏幕布局和数据元素的特定细节中。用户可以通过跟踪对快陷入到屏幕布局和数据元素的特定细节中。用户可以通过跟踪对话图寻找遗漏、错误或多余的转换，和因此而有遗漏、错误或多余话图寻找遗漏、错误或多余的转换，和因此而有遗漏、错误或多余的需求。的需求。n你可以把在需求分析过程中形成的对话图用作详细用户界面设计时你可以把在需求分析过程中形成的对话图用作详细用户界面设计时的指南，最终形成一个执行的对话图，该对话图记录了产品的真正的指南，最终形成一个执行的对话图，该对话图记录了产品的真正用户界面的体系结构。用户界面的体系结构。第28页，本讲稿共56页对话图示例对话图示例第29页，本讲稿共56页非功能性需求分析n n所谓非功能性需求，是指软件产品为满足用户业务需求而所谓非功能性需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。软件产品的非功能性必须具有且除功能需求以外的特性。软件产品的非功能性需求包括系统的需求包括系统的性能、可靠性、可维护性、可扩充性性能、可靠性、可维护性、可扩充性和和对技术和对业务的适应性技术和对业务的适应性等。n n非功能性需求涉及的范围很广，软件产品本身不是孤立存在的，还涉及到诸多外在环境的影响。n n非功能性需求必须考虑软件既要可用，又要易用。非功能性需求必须考虑软件既要可用，又要易用。第30页，本讲稿共56页实时系统需求分析n n实时系统广泛应用在航天、航空、通信、国防等领域。实时系统以计算机技术为基础、以应用为目的、将软件和硬件紧密结合在一起，实现特定功能的系统。n n与通用系统相比，实时系统具有一些显著的特点：实时性实时性可靠性可靠性可预测性可预测性第31页，本讲稿共56页实时系统需求分析n n基于实时系统的特点，在开发一个复杂的实时系统时，一个充分再现系统特性的建模工具至关重要，对于系统分析、设计、实现、成本控制、可重用都具有重要的意义。n n可选用UML-RT工具进行实时系统的需求分析。n nUML-RT是利用通用建模语言UML的扩展机制并借鉴实时的面向对象的方法ROOM（Real-time Object-Oriented Modeling）的优点发展而来。第32页，本讲稿共56页实时系统需求分析n nUML-RTUML-RT用协作图表示特定环境下类之间的关系。用协作图表示特定环境下类之间的关系。n nUML-RTUML-RT有两种结构元素：模型结构和模型行为。有两种结构元素：模型结构和模型行为。n n模型结构：封装体封装体端口端口连接器连接器n n模型行为：模型行为：协议协议状态机状态机定时服务定时服务第33页，本讲稿共56页Petri Net(Activity Diagram)nElementsPosition TransitionTransition arcMarking第34页，本讲稿共56页Petri Net第35页，本讲稿共56页行为行为(功能功能)建模建模FSM有限状态机有限状态机-通过输入输出之间的因果关系对系通过输入输出之间的因果关系对系通过输入输出之间的因果关系对系通过输入输出之间的因果关系对系统的行为进行建模统的行为进行建模统的行为进行建模统的行为进行建模系统可看作有若干个相互区别的稳定状态系统可看作有若干个相互区别的稳定状态 外部刺激使系统从当前某个状态改变到另一外部刺激使系统从当前某个状态改变到另一个状态个状态状态转移图状态转移图State Transition Diagram状态图状态图State Chart DiagramSpecification and description language(SDL)规规范与描述语言范与描述语言Petri Net第36页，本讲稿共56页基于USE CASE的需求分析 用例图n n用例：系统和外部角色的交互n n符号表示：系统名称系统名称系统系统用例名用例名用例用例角色角色关联关联第37页，本讲稿共56页保险商务系统保险商务系统签定保险单销售统计客户统计客户保险销售员基于USE CASE的需求分析 Use Case图例子第38页，本讲稿共56页基于USE CASE的需求分析 用例之间的关系n n扩展关系n n使用关系n n组合关系扩展签保险单签汽车购买契约使用使用签保险单签汽车保险单签房屋保险单第39页，本讲稿共56页类图类图第40页，本讲稿共56页面向对象需求分析n因为人类自然地趋向于用“对象”的观点或“方法”来认识问题，分析问题以及解决问题，用基于“对象”的概念模型来建立问题域模型自然成为系统分析员与用户交流的有效工具。n用面向对象的方法进行需求分析，其根本要点在于，利用对象的概念模型建立一个针对于问题域的模型，用户和软件工程师通过该模型进行交流。通过在这么一个基于对象的问题域模型的基础上形成需求规格说明书。第41页，本讲稿共56页面向对象需求分析-步骤1.通过查看相关资料并与用户广泛地接触，自己对问题域有一个大致的了解。在这个基础上，将问题域中与系统和问题有关的对象提取出来。这就是标识对象的工作。2.将第一步中抽象出来的对象(类)的之间的关系考虑清楚；如整体与部分、从属关系等；3.为“类”提取与系统问题域有关的属性、服务等；4.由于要完成一项任务，肯定是有不同的对象互相协作完成的。同时一个对象的属性、服务也是在与相关对象的协作中体现出来的。将问题域中所有任务的对象的协作关系搞清楚，是面向对象需求分析的关键一环。即将问题域中的“剧情”搞清楚，是需求分析的主要工作之一。第42页，本讲稿共56页面向对象需求分析1.以上四步并不是单独的而是互有联系，可以同时进以上四步并不是单独的而是互有联系，可以同时进行的。通过，对以上行的。通过，对以上4步工作的反复执行我们就可以步工作的反复执行我们就可以建立一个基于对象的问题域的模型。建立一个基于对象的问题域的模型。2.在该模型的基础上，可以比较容易地产生一个符合在该模型的基础上，可以比较容易地产生一个符合用户需求的软件需求规格说明书成为后续工作的基用户需求的软件需求规格说明书成为后续工作的基础。础。第43页，本讲稿共56页基于原型方法的分析n n软件原型是所提议的新产品的部分实现或可能的实现，使用原型有3个主要目的：明确并完善需求研究设计选择方案发展为最终产品n n原型法就是不断地运行系统“原型”来进行启发、揭示、判断、修改和完善的系统开发方法。第44页，本讲稿共56页基于原型方法的分析n n对原型的基本要求包括：体现主要的功能；提供基本的界面风格；展示比较模糊的部分以便于确认或进一步明确；原型最好是可运行的，至少在各主要功能模块之间能够建立相互连接。第45页，本讲稿共56页原型方法的一般过程第46页，本讲稿共56页基于原型方法的分析n n原型可以分为三类：淘汰(抛弃)式(disposable)：目的达到即被抛弃，原型不作为最终产品。演化式(evolutionary)：系统的形成和发展是逐步完成的，它是高度动态迭代和高度动态的循环，每次迭代都要对系统重新进行规格说明、重新设计、重新实现和重新评价，所以是对付变化最为有效的方法。增量式(incremental)：系统是一次一段地增量构造，与演化式原型的最大区别在于增量式开发是在软件总体设计基础上进行的。很显然，其应付变化的能力比演化式差。第47页，本讲稿共56页基于原型方法的分析 淘汰式原型利用废弃原型从用例到用户界面设计的活动序列：利用废弃原型从用例到用户界面设计的活动序列：用例描述用例描述对话框对话框废弃型原型废弃型原型详细用户界面设计详细用户界面设计反馈反馈反馈反馈反馈反馈第48页，本讲稿共56页Risk Reduction Through Prototyping通过原型减小风险通过原型减小风险n原型开发与需求获取原型开发与需求获取n原型开发与需求分析原型开发与需求分析n原型开发与需求规范文档原型开发与需求规范文档n原型开发与需求验证原型开发与需求验证n原型开发与需求风险管理原型开发与需求风险管理第49页，本讲稿共56页使用质量功能部署使用质量功能部署质量功能部署质量功能部署(QFD)(QFD)是一种高级系统技术，是一种高级系统技术，它将产品特性、属性与对客户的重要性联它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明系起来。该技术提供了一种分析方法以明确哪些是客户最关注的特性。确哪些是客户最关注的特性。QFDQFD将需求分将需求分为三类：为三类：期望需求期望需求，即客户或许并未提及，即客户或许并未提及，但若缺少会让他们感到不满意；但若缺少会让他们感到不满意；普通需求普通需求；兴奋需求兴奋需求，即实现了会给客户带去惊喜，即实现了会给客户带去惊喜，但若未实现也不会受到责备。但若未实现也不会受到责备。第50页，本讲稿共56页QFD示例第51页，本讲稿共56页n如果你有足如果你有足够的的资源来完成你和你的源来完成你和你的客客户所想做的全部需求，那再好不所想做的全部需求，那再好不过了。了。n但在快速但在快速变化的市化的市场环境中，境中，这是不是不现实的！的！设定需求优先级设定需求优先级第52页，本讲稿共56页多种设定需求优先级的规则多种设定需求优先级的规则命命 名名 意意 义义 参参 考考高高一个关键任务的需求；下一版本所需求的一个关键任务的需求；下一版本所需求的中中支持必要的系统操作；最终所要求的，但如果支持必要的系统操作；最终所要求的，但如果有必要的话，可以延迟到下一个版本有必要的话，可以延迟到下一个版本低低功能或质量上的增强；如果资源允许的话，实功能或质量上的增强；如果资源允许的话，实现这些需求总有一天使产品更完美现这些需求总有一天使产品更完美基本的基本的只有在这些需求上达成一致意见，软件才会被只有在这些需求上达成一致意见，软件才会被接受接受（IEEE 1998）条件的条件的实现这些需求将增强产品的性能，但如果忽略实现这些需求将增强产品的性能，但如果忽略这些需求，产品也是可以被接受的这些需求，产品也是可以被接受的可选的可选的一个功能类，实现或不实现均可一个功能类，实现或不实现均可3必须完美地实现必须完美地实现（Kovitz 1999）2需要付出努力，但不必做得太完美需要付出努力，但不必做得太完美1可以包含缺陷可以包含缺陷(但不是有意的但不是有意的但不是有意的但不是有意的)第53页，本讲稿共56页设定需求优先级设定需求优先级3GPP3GPP1.1.Mandatory(M)If a requirement or a message is marked as M,it must be implemented2.2.Conditional(C)Conditional(C)If a requirement or a message is marked as C,it will be implemented conditionally3.3.Optional(O)Optional(O)If a requirement or a message is marked as O,it can be or may not be implemented第54页，本讲稿共56页设定需求优先级设定需求优先级Covey 1989Covey 1989n nHigh priority requirements are both important(the user needs the capability)and urgent(the user needs it in the next releasen nMedium priority requirements are important(the user needs the capability)but not urgent(they can wait for a later release).n nLow priority requirements are not important and not urgentLow priority requirements are not important and not urgentn nUrgent but not important,They dont add sufficient value to the productUrgent but not important,They dont add sufficient value to the productRequirementImportantNot ImportantUrgentHigh PriorityDo not do theseNot UrgentMedium PriorityLow Priority第55页，本讲稿共56页设定需求优先级设定需求优先级Suggestionsn需求获取期间就关注需求优先级的问题需求获取期间就关注需求优先级的问题n基于基于Use case标注优先级标注优先级n基于基于Scenario标注优先级，尤其对例外的处理。有些例外会标注优先级，尤其对例外的处理。有些例外会对系统产生根本影响如对系统产生根本影响如system crash，有些只是轻微的。例，有些只是轻微的。例外很难穷举，但配以优先级就容易裁决外很难穷举，但配以优先级就容易裁决n建立模型可以建立模型可以发现哪个功能更重要，排定哪个功能更重要，排定优先先级n优先级并非在整个开发过程中一成不变的优先级并非在整个开发过程中一成不变的 需求管理方面需求管理方面的问题的问题n可以使用电子表单、表格或矩阵来估计和维护一个功能或可以使用电子表单、表格或矩阵来估计和维护一个功能或USE CASE的优先级的优先级第56页，本讲稿共56页