软件需求分析

软件需求分析第一页，共五十六页，2022年，8月28日课程提纲软件需求基本理论和概念

软件需求工程过程

软件需求获取

软件需求分析

软件需求规格说明

软件需求验证

软件需求管理

软件需求实现

软件需求工程新进展

软件需求开发与需求管理工具第二页，共五十六页，2022年，8月28日内容提要需求分析面临的困难需求分析基本方法和工具数据需求分析功能需求分析非功能性需求分析实时系统需求分析基于USECASE的需求分析基于原型方法的分析第三页，共五十六页，2022年，8月28日需求分析分析是指通过对问题域的研究,获得对该领域特性及存在于其中的待解决的问题特性的透彻理解并用文档说明。需求分析是前面需求获取阶段的继续，通过对所获取的信息进一步加工获得对系统的更精确描述，成为转换成需求规格说明的直接信息元。但是否将需求分析作为独立的过程？第四页，共五十六页，2022年，8月28日需求分析的关键点问题域的结构问题域的数据问题域的行为问题域的事件问题域的状态派生需求

只是针对问题域吗？第五页，共五十六页，2022年，8月28日一.需求分析面临的困难需求分析是一个项目的开端，也是项目建设的基石。在失败的项目中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。

由于软件项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又面临着很多困难。第六页，共五十六页，2022年，8月28日二.需求分析基本方法和工具图1软件需求工程的组成获取需求工程需求开发需求管理分析编写规约确认绘制关联图创建用户界面和技术原型分析需求的可行性确定需求的优先级为需求建模创建数据字典将需求分解到子系统应用质量功能调配需求分析包括：第七页，共五十六页，2022年，8月28日分析方法结构化分析面向对象分析第八页，共五十六页，2022年，8月28日分析模型描述工具结构化分析工具DFD、DD和PSPECCFD、CSPEC和STDE-R图面向对象分析工具用例图，类图，对象图对象-关系图对象-行为图第九页，共五十六页，2022年，8月28日需求分析建模工具数据流图实体关系图状态转换图对话图类图PetriNet第十页，共五十六页，2022年，8月28日建模技术面向处理技术Contextdiagram上下文图Dataflowdiagram(DFD)数据流图流程图面向数据结构技术E-RD-EntityRelationshipDiagrams面向对象建模处理和数据相结合ObjectandClass对象和类的技术第十一页，共五十六页，2022年，8月28日需求分析基本方法

——结构化分析方法(SA)结构化分析（StructuredAnalysis,简称SA法）的基本思想：“分解”和“抽象”分解：把系统的复杂性降低到可以掌握的程度，把大问题分解成若干小问题，然后分别解决。抽象：即先考虑问题最本质的属性，暂把细节略去，以后再逐层添加细节，直至涉及到最详细的内容。

图4自顶向下逐层分解第十二页，共五十六页，2022年，8月28日数据流图数据流图DFD描述系统逻辑模型信息在系统中的流动和处理用途交流信息的工具结构化分析和设计的工具第十三页，共五十六页，2022年，8月28日数据流图数据流图DFD组成符号圆框代表加工箭头代表数据流向方框代表源点和终点双杠表示数据文件或数据库分层从高层到低层分解前后的数据流必须一致命名数据流处理第十四页，共五十六页，2022年，8月28日数据流图

DFD练习—售书系统领书单

进书通知

购书单

缺书单

学生教材购销系统书库保管员图5售书系统顶层数据流图第十五页，共五十六页，2022年，8月28日数据流图

DFD练习—售书系统领书单进书通知

进书通知

购书单缺书单

1销售

2采购书库保管员

学生F1教材存量表

F2缺书登记表

第十六页，共五十六页，2022年，8月28日功能需求分析

——加工说明PSPEC加工说明PSPEC说明DFD中的每个加工描述工具结构化语言判定表判定树第十七页，共五十六页，2022年，8月28日处理方法：事件列表与功能列表事件就是要求系统执行某项功能的请求业务事件与产品事件对复杂的业务任务采用任务说明、用例说明或数据流图等方法进行解释。对复杂的功能采用数据流图、算法描述、活动图、数学说明等进行解释。第十八页，共五十六页，2022年，8月28日处理方法：事件列表与功能列表事件及功能列表的优点主要作为核对清单，以说明应开发什么。其中对这些功能的详细说明构成了功能需求的主要部分。开发人员可以方便的检查产品是否实现每一个功能。用户能够在某种程度上确认业务事件和任务列表。通过一致性检查确定列表是否完备。第十九页，共五十六页，2022年，8月28日数据需求分析

——数据字典DDDFD中所有元素的定义的集合内容数据流数据流分量数据存储处理（一般不用DD描述）定义数据的方法自顶向下分解数据第二十页，共五十六页，2022年，8月28日数据需求分析

——数据字典DD数据元素的组合方式顺序：A+B选择：[A|B]重复：1{A}5可选：（A）DD的用途分析阶段的交流工具包含控制信息数据库设计的基础第二十一页，共五十六页，2022年，8月28日E-R图用于对复杂数据的数据分析和建模实体、属性和关系组成符号0：11：10：m1:m第二十二页，共五十六页，2022年，8月28日E-R图例子电话机生产厂商经销商用户生产购买使用经销第二十三页，共五十六页，2022年，8月28日数据需求与功能需求的区别数据需求指定了系统的存储数据。功能需求则说明数据的用途，以及如何记录、计算、转换、修改及传输数据等。数据需求与功能需求的区别：第二十四页，共五十六页，2022年，8月28日状态迁移图

——STDSTD(StateTransitionDiagram)描述软件状态变迁符号表示矩形---系统状态箭头---状态转变方向规则表达式---事件/触发行为状态1状态2事件/触发行为第二十五页，共五十六页，2022年，8月28日状态迁移图

——STD例子20秒到/翻屏生成最新数据/翻屏半小时到/工控处理半分钟到/传送空闲/采集物品经过/计数采集PLC计数传送工控处理实时翻屏第二十六页，共五十六页，2022年，8月28日上下文图作用上下文图能很好地概括产品的必要接口，初步确定产品包含了哪些内容，产品之外又包含哪些内容。即说明产品及其环境的视图。说明产品的范围。优点：上下文图为开发任务概括了所有的接口，在开发中或开发后，方便地验证是否已经处理了所有接口。用户容易理解，并发现遗漏的接口。第二十七页，共五十六页，2022年，8月28日对话图对话图代表了一个高层抽象的用户界面体系结构。对话图描绘了系统中的对话元素和它们之间的导航连接，但它没有揭示具体的屏幕设计。对话图可以使你在对需求的理解上探索假设的用户界面概念。用户和开发者可以通过对话图在用户如何利用系统执行任务上达成共同的视觉界面。对话图与系统情节叙述相关联，这些叙述还包括对每一个屏幕意图的简短说明。对话图抓住了用户一系统交互作用和任务流的本质，而不会使你太快陷入到屏幕布局和数据元素的特定细节中。用户可以通过跟踪对话图寻找遗漏、错误或多余的转换，和因此而有遗漏、错误或多余的需求。你可以把在需求分析过程中形成的对话图用作详细用户界面设计时的指南，最终形成一个执行的对话图，该对话图记录了产品的真正用户界面的体系结构。第二十八页，共五十六页，2022年，8月28日对话图示例第二十九页，共五十六页，2022年，8月28日非功能性需求分析所谓非功能性需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。软件产品的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。非功能性需求涉及的范围很广，软件产品本身不是孤立存在的，还涉及到诸多外在环境的影响。非功能性需求必须考虑软件既要可用，又要易用。第三十页，共五十六页，2022年，8月28日实时系统需求分析实时系统广泛应用在航天、航空、通信、国防等领域。实时系统以计算机技术为基础、以应用为目的、将软件和硬件紧密结合在一起，实现特定功能的系统。与通用系统相比，实时系统具有一些显著的特点：实时性可靠性可预测性第三十一页，共五十六页，2022年，8月28日实时系统需求分析基于实时系统的特点，在开发一个复杂的实时系统时，一个充分再现系统特性的建模工具至关重要，对于系统分析、设计、实现、成本控制、可重用都具有重要的意义。可选用UML-RT工具进行实时系统的需求分析。UML-RT是利用通用建模语言UML的扩展机制并借鉴实时的面向对象的方法ROOM（Real-timeObject-OrientedModeling）的优点发展而来。第三十二页，共五十六页，2022年，8月28日实时系统需求分析UML-RT用协作图表示特定环境下类之间的关系。UML-RT有两种结构元素：模型结构和模型行为。模型结构：封装体端口连接器模型行为：协议状态机定时服务第三十三页，共五十六页，2022年，8月28日PetriNet(ActivityDiagram)ElementsPositionTransitionTransitionarcMarking第三十四页，共五十六页，2022年，8月28日PetriNet第三十五页，共五十六页，2022年，8月28日行为(功能)建模FSM有限状态机-通过输入输出之间的因果关系对系统的行为进行建模系统可看作有若干个相互区别的稳定状态外部刺激使系统从当前某个状态改变到另一个状态状态转移图StateTransitionDiagram状态图StateChartDiagramSpecificationanddescriptionlanguage(SDL)规范与描述语言PetriNet第三十六页，共五十六页，2022年，8月28日基于USECASE的需求分析

——用例图用例：系统和外部角色的交互符号表示：

系统名称系统用例名用例角色关联第三十七页，共五十六页，2022年，8月28日保险商务系统签定保险单销售统计客户统计客户保险销售员基于USECASE的需求分析

——UseCase图例子第三十八页，共五十六页，2022年，8月28日基于USECASE的需求分析

——用例之间的关系扩展关系使用关系组合关系《扩展》签保险单签汽车购买契约《使用》《使用》签保险单签汽车保险单签房屋保险单第三十九页，共五十六页，2022年，8月28日类图第四十页，共五十六页，2022年，8月28日面向对象需求分析因为人类自然地趋向于用“对象”的观点或“方法”来认识问题，分析问题以及解决问题，用基于“对象”的概念模型来建立问题域模型自然成为系统分析员与用户交流的有效工具。用面向对象的方法进行需求分析，其根本要点在于，利用"对象"的概念模型建立一个针对于问题域的模型，用户和软件工程师通过该模型进行交流。通过在这么一个基于"对象"的问题域模型的基础上形成需求规格说明书。第四十一页，共五十六页，2022年，8月28日面向对象需求分析-步骤通过查看相关资料并与用户广泛地接触，自己对问题域有一个大致的了解。在这个基础上，将问题域中与系统和问题有关的对象提取出来。这就是标识对象的工作。将第一步中抽象出来的对象(类)的之间的关系考虑清楚；如整体与部分、从属关系等；为“类”提取与系统问题域有关的属性、服务等；由于要完成一项任务，肯定是有不同的对象互相协作完成的。同时一个对象的属性、服务也是在与相关对象的协作中体现出来的。将问题域中所有任务的对象的协作关系搞清楚，是面向对象需求分析的关键一环。即将问题域中的“剧情”搞清楚，是需求分析的主要工作之一。第四十二页，共五十六页，2022年，8月28日面向对象需求分析以上四步并不是单独的而是互有联系，可以同时进行的。通过，对以上4步工作的反复执行我们就可以建立一个基于对象的问题域的模型。在该模型的基础上，可以比较容易地产生一个符合用户需求的软件需求规格说明书成为后续工作的基础。第四十三页，共五十六页，2022年，8月28日基于原型方法的分析软件原型是所提议的新产品的部分实现或可能的实现，使用原型有3个主要目的：明确并完善需求研究设计选择方案发展为最终产品原型法就是不断地运行系统“原型”来进行启发、揭示、判断、修改和完善的系统开发方法。第四十四页，共五十六页，2022年，8月28日基于原型方法的分析对原型的基本要求包括：体现主要的功能；提供基本的界面风格；展示比较模糊的部分以便于确认或进一步明确；原型最好是可运行的，至少在各主要功能模块之间能够建立相互连接。

第四十五页，共五十六页，2022年，8月28日原型方法的一般过程第四十六页，共五十六页，2022年，8月28日基于原型方法的分析原型可以分为三类：淘汰(抛弃)式(disposable)：目的达到即被抛弃，原型不作为最终产品。演化式(evolutionary)：系统的形成和发展是逐步完成的，它是高度动态迭代和高度动态的循环，每次迭代都要对系统重新进行规格说明、重新设计、重新实现和重新评价，所以是对付变化最为有效的方法。增量式(incremental)：系统是一次一段地增量构造，与演化式原型的最大区别在于增量式开发是在软件总体设计基础上进行的。很显然，其应付变化的能力比演化式差。第四十七页，共五十六页，2022年，8月28日基于原型方法的分析

——淘汰式原型利用废弃原型从用例到用户界面设计的活动序列：用例描述对话框废弃型原型详细用户界面设计反馈反馈反馈第四十八页，共五十六页，2022年，8月28日RiskReductionThroughPrototyping

通过原型减小风险原型开发与需求获取原型开发与需求分析原型开发与需求规范文档原型开发与需求验证原型开发与需求风险管理第四十九页，共五十六页，2022年，8月28日使用质量功能部署 质量功能部署(QFD)是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确哪些是客户最关注的特性。QFD将需求分为三类：期望需求，即客户或许并未提及，但若缺少会让他们感到不满意；普通需求；兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备。第五十页，共五十六页，2022年，8月28日QFD示例第五十一页，共五十六页，2022年，8月28日如果你有足够的资源来完成你和你的客户所想做的全部需求，那再好不过了。但在快速变化的市场环境中，这是不现实的！设定需求优先级第五十二页，共五十六页，2022年，8月28日多种设定需求优先级的规则命名意义参考高一个关键任务的需求；下一版本所需求的中支持必要的系统操作；最终所要求的，但如果有必要的话，可以延迟到下一个版本低功能或质量上的增强；如果资源允许的话，实现这些需求总有一天使产品更完美基本的只有在这些需求上达成一致意见，软件才会被接受（IEEE1998）条件的实现这些需求将增强产品的性能，但如果忽略这些需求，产品也是可以被接受的可选的一个功能类，实现或不实现均可3必须完美地实现（Kovitz1999）2需要付出努力，但不必做得太完美1可以包含缺陷(但不是有意的)第五十三页，共五十六页，2022年，8月28日设定需求优先级3GPPMandatory(M)–IfarequirementoramessageismarkedasM,itmustbeimplementedConditional(C)–IfarequirementoramessageismarkedasC,itwillbeimplementedconditionallyOptional(O)–IfarequirementoramessageismarkedasO,itcanbe