第二部分软件需求分析与建模..ppt

2020/5/23,第二部分需求分析与建模,范锐广东海洋大学软件学院2014年3月,fanrui_n2020/5/23,第4讲软件需求分析过程,什么是软件需求？软件需求分析有哪些过程？如何启动分析过程？需求规格文档有哪些内容？需求分析有哪些技术？,fanrui_n2020/5/23,软件需求,功能需求：描述系统预期提供的功能或服务对系统应提供的服务如何对输入做出反应系统在特定条件下的行为非功能需求：指那些不直接与系统具体功能相关的一类需求产品需求机构需求外部需求领域需求：源于系统的应用领域需求,fanrui_n2020/5/23,需求分析过程,需求分析主要是理解客户需要什么、分析要求、评价可行性、协商合理的方案、无歧义地详细说明方案、确认规格说明、管理需求以至将这些需求转化为可行系统过程包括：初步沟通导出需求分析和精化可行性研究协商与沟通规格说明需求验证变更管理,fanrui_n2020/5/23,软件需求规格,一个规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型、一组使用场景、一个原型或以上各项的任意组合。软件需求规格（SRS，SoftwareRequirementSpecification）是需求分析任务的最终“产品”，它是客户、管理者、分析工程师、测试工程师、维护工程师交流的标准和依据。软件需求规格描述了系统的数据、功能、行为、性能需求、设计约束、验收标准、以及其他与需求相关的信息。分为：用户需求和系统需求,fanrui_n2020/5/23,需求规格文档标准,1引言1.1编写目的1.2项目背景（单位和与其他系统的关系）1.3定义（专门术语和缩写词）2任务概述2.1目标2.2运行环境2.3条件限制3数据描述3.1静态数据3.2动态数据3.3数据库描述3.4数据字典3.5数据采集4功能需求4.1功能划分4.2功能描述,5性能需求5.1数据精确度5.2时间特性5.3适应性6运行需求5.1用户界面5.2硬件接口5.3软件接口5.4故障处理7其他需求（检测或验收标准、可用性、可维护性可移植性、安全保密性）,fanrui_n2020/5/23,需求验证,需求验证对需求文档和制品进行质量评估，确保需求说明准确、完整包括以下内容：正确性一致性完整性可行性必要性可检验性需求的可跟踪性最后签字,fanrui_n2020/5/23,启动分析过程,确定共利益者：直接或间接从正在开发的系统中获益的人。例如，POS机系统中的共利益者有：收银员，售货员，顾客，公司，经理，支付授权服务，帐务系统和库存系统等识别视点：从不同的视角看待该系统。比如，收银员关心准确、快速生成一次销售，且没有支付错误；售货员关注销售提成协同工作：共利益者之间的协作首次提问：集中于客户和其他共利益、整体目标、收益等,fanrui_n2020/5/23,非形式化需求分析技术,会谈：正式会谈：提出一些可自由回答的问题非正式会谈：提出一些事先准备好的议题情景分析：需求分析从对场景的评论中得到信息，然后再将其以形式化方式表示出来。使用调查表制定调查表分析建立原型界面执行过程,fanrui_n2020/5/23,实例分析：POS机系统,收银员：能够准确、快速地输入，而且没有支付错误，因为如果少收货款，将从其薪水众扣除。售货员：自动更新销售提成。顾客：希望以最小代价完成购买活动并得到快速服务。便捷、清晰地看到所输入的商品项目和价格。得到购买凭证，以便退货。公司：希望准确地记录交易，满足顾客要求。确保记录了支付授权服务的支付票据。有一定的容错性。能够自动、快速地更新记帐和库存信息。经理：能够快速执行超控操作，并易于更正收银员的不当操作。支持授权服务：依据正确的通信格式进行授权服务。库存系统：正确的方式更新库存信息。记账系统：能够准确地记录每次销售支付信息。,fanrui_n2020/5/23,POS机系统主要功能需求,处理销售：收银员完成一次销售记录，并出具票据和更新库存系统和帐务系统。处理支付：完成一次销售对应的支付，包括现金支付，信用卡支付和支票支付。处理退货：根据顾客请求完成商品退货处理。办理会员卡：注册、注销和更新会员记录。,fanrui_n2020/5/23,实例分析：图书馆系统,图书馆系统的共利益者与视点有：图书流通管理：负责图书借还工作。用户：希望快速得到借书，还书服务，能够续借、预约图书，以及查询个人和图书信息。编目管理员：负责图书的管理、用户管理和处理罚金等。,fanrui_n2020/5/23,图书馆系统的主要功能需求,图书借出：管理员完成一次借书过程。图书归还：管理员完成一次还书过程。图书预约：用户查询要借的图书，若不能借，可预约该图书。图书续借：用户可以将图书的归还日期延长一段时间。图书管理：添加新书。更新图书馆信息，销毁图书。用户管理：注册新用户，更新用户信息，注销用户。处理罚金：用户缴纳罚金吼，系统将罚金数额清零。,fanrui_n2020/5/23,小结,需求分析也称为需求工程，是一个非常重要而有很复杂的，需要交替进行，反复迭代的过程。软件需求分为功能需求和非功能需求。功能需求描述系统所预期提供的服务，而非功能需求描述与系统不直接相关的一些需求。领域需求是一种特有的功能需求，反应应用领域的基本问题。软件需求规格说明文档描述了系统的数据、功能、行为、性能需求、设计约束、验收标准以及其他于需求相关的信息，它有可能成为客户与开发商之间的合同。需求分析过程通过执行初步沟通、需求导出、分析与精化、可行性研究、协商和沟通、规格说明、验证和变更管理八个不同的活动来完成。非形式技术主要包括会谈、调查表和场景技术，用于获取用户需求和系统需求。,fanrui_n2020/5/23,第5讲结构化分析建模,结构化需求分析面向数据的建模方法案例分析,fanrui_n2020/5/23,结构化分析建模,需求分析的任务就是准确地指出“软件目标产品必须做什么？”需求分析的一个重要过程就是需求建模的过程结构化分析方法是一种传统的系统建模技术,fanrui_n2020/5/23,结构化分析模型结构,fanrui_n2020/5/23,结构化分析模型结构,分析模型结构的核心是数据字典（DD，DataDictionary），包含了软件使用或生产的所有数据对象描述的中心库。分析模型结构的中间层有三种视图：数据流图（DFD，DataFlowDiagram）服务于两个目的：一是指明数据在系统中移动时如何被变换，二是描述对数据流进行变换的功能和子功能。实体关系图（E-RD，Entity-RelationshipDiagram）描述数据对象间的关系，用来进行数据建模活动的记号。状态转换图（STD，StateTransitionDiagram）指明作为外部事件的结果，系统将如何动作。分析模型结构的外层是规约描述：在实体关系图中每个数据对象的属性可以使用数据对象来描述。在数据流图中出现的每个加工/处理的功能描述包含在加工规约中。软件控制方面的附加信息包含在控制规约中,fanrui_n2020/5/23,面向数据的建模方法,系统建模的一个重要方面就是要定义系统处理的逻辑结构。最广泛采用的数据建模技术是实体-关系模型，它描述数据实体、关联及实体属性。实体关系模型可用ERD实体关系图）来表示：实体关联实体属性基数,fanrui_n2020/5/23,实例分析：图书馆系统,fanrui_n2020/5/23,实例分析：图书馆系统,实体：图书、借书者、管理员、借书目录、预约记录、书目属性给出如下：借书者：借书者编号、姓名、性别、借书数、最大借书数、罚金金额、有限期图书：图书号、书目号书目：书目号、书名、作者、出版社、丛书名、收藏数、在馆数、预约数借书记录：图书号、借书者编号、借出日期、应还日期、续借次数预约记录：书目号、借书者编号、预约日期,fanrui_n2020/5/23,实例分析：POS机系统,fanrui_n2020/5/23,实例分析：POS机系统,实体有销售、支付、商品、商品描述关联：销售包含一组商品；每个商品都有相应的描述信息；每个支付对应一个销售。实体的属性：销售：编号、总价、1商品*，日期支付：编号、支付客户、找零、销售编号商品：编号、数量商品描述：名称、产地、厂家、单价,fanrui_n2020/5/23,小结,分析模型帮助用户逐层深入理解问题，为软件设计提供基础。结构化分析方法是一种自顶向下，逐步分解的面向数据和数据流的建模方法。面向数据的建模以实体、关系和属性三个基本元素描述系统，涉及数据及其它们之间的关系，用ERD表示。,fanrui_n2020/5/23,第6讲结构化分析建模面向数据流的建模,面向数据流的建模是结构化需求分析方法之一采用自顶向下逐层分解，描绘满足用户要求的软件模型表示：数据流图：描述系统处理过程数据字典：模型中的数据信息集合状态转换图：描述系统对内部或外部事件响应的行为模型,fanrui_n2020/5/23,数据流图符号,fanrui_n2020/5/23,数据流图举例,设一个工厂采购部每天需要一张定货报表。定货的零件数据有：零件编号、名称、数量、价格、供应者等。零件的入库、出库事务通过计算机终端输入给定货系统。当某零件的库存数少于给定的库存量临界值时，就应该再次定货。数据流分析：数据源点：仓管员（负责入库或出库事务给定货系统）；数据终点：采购员（接收每天的定货报表）；数据流：事务，定货；数据存储：定货信息，库存清单；处理：处理事务，产生报表。,fanrui_n2020/5/23,数据流图举例,画基本系统模型,fanrui_n2020/5/23,数据流图举例,第一步求精,fanrui_n2020/5/23,数据流图举例,第二步求精,fanrui_n2020/5/23,数据字典卡片方式示例,fanrui_n2020/5/23,状态转换图,状态模型是一种描述系统对内部或者外部事件响应的行为模型。它描述系统状态和事件，以及事件引发系统在状态间的转换。这种模型适用于描述实时系统状态模型一般采用状态转换图（简称状态图）的标记方法状态图描述了系统中某些复杂对象的状态变化状态是可观察的行为模式，用圆角矩形表示；变迁表示状态的转换，用箭头表示；事件是引发变迁的消息，用箭头上的标记表示。状态图还可以用事件后的方括号表示先决条件，只有当这个条件为真时，才会发生状态变化；用状态自身的弧线箭头表示先决条件不为真时，状态不会改变。,fanrui_n2020/5/23,复印机控制软件状态图,fanrui_n2020/5/23,图书馆系统,fanrui_n2020/5/23,图书馆系统,fanrui_n2020/5/23,图书馆系统实体关系图,fanrui_n2020/5/23,图书馆系统数据字典,fanrui_n2020/5/23,小结,结构化分析方法是一种自顶向下，逐步分解的面向数据和数据流的建模方法。基于数据流的方法用于描述数据如何在系统中流动或被变换，用数据流图、数据字典、加工规程等形式表示。,fanrui_n2020/5/23,第7讲面向对象分析,面向对象建模用例模型领域模型案例分析,fanrui_n2020/5/23,面向对象建模,面向对象模型对象模型：定义了“做什么”的实体动态模型：规定在何种状态下，接受什么事件的触发而“做什么”功能模型：指明了系统应该“做什么”,fanrui_n2020/5/23,统一建模语言UML,统一建模语言（UML，UnifiedModelingLanguage）是一种基于面向对象的可视化建模语言。UML用丰富的图形符号隐含表示了模型元素的语法，而用这些图形符号组成元模型表达语义，组成模型描述系统结构（或称为静态特征）以及行为（或称为动态特征）。UML的模型元素：一类模型元素用于表示模型中的某个概念，如类、对象、用例、结点、构件、包、接口等；另一类模型元素用于表示模型元素之间相互连接的关系，主要有关联、泛化（表示一般与特殊的关系）、依赖、聚集（表示整体与部分的关系）等。,fanrui_n2020/5/23,UML模型元素,fanrui_n2020/5/23,UML模型视图,UML主要是用来描述模型的。它可以从不同视角为系统建模，形成不同的视图（View）。每个视图是系统完整描述中的一个抽象，代表该系统一个特定的方面；每个视图又由一组图（Diagram）构成，图包含了强调系统某一方面的信息。两类图：静态图：包括用例图、类图、对象图、构件图和部署图动态图：包括状态图、时序图、协作图和活动图五种视图：用例视图从用户角度表达系统功能；结构视图主要使用类图和对象图描述系统静态结构；行为视图展示系统动态行为及其并发性；实现视图展示系统实现的结构和行为特征；部署视图展示系统的实现环境和构件是如何在物理结构中部署的,fanrui_n2020/5/23,用例建模,需求捕获的目标：发现真正的需求以适用于用户、客户和开发人员的方式加以表示系统用户表示为一个参与者参与者在与用例进行交互时使用系统用例向参与者提供某些有价值结果而执行一些动作序列,fanrui_n2020/5/23,编写用例,用例着眼于为用户增加价值，提供了一种捕获功能需求的系统且直观的方法，可驱动整个开发过程。用例从某个特定参与者的角度用简单易懂的语言说明一个特定的使用场景。要开始开发用例，应列出特定参与者执行的功能或者活动。用例模型帮助客户、用户和开发人员在如何使用系统方面达成共识。用例图描述部分用例模型，显示带有联系的用例和参与者的集合,fanrui_n2020/5/23,POS机系统部分用例图,fanrui_n2020/5/23,用例图,用例图包括：参与者、用例、关联和边界四个要素。参与者：用小人形表示用例：用椭圆表示关联：用直线表示说明参与者驱动某个用例边界：用矩形框表示，说明系统关注点。,fanrui_n2020/5/23,开发用例,用例使用非正式的描述性风格编写，也可以使用某个结构化的格式编写，有些格式更强调描述的直观性。,fanrui_n2020/5/23,POS机系统中处理销售的场景,用例名称：处理销售范围：POS机应用级别：用户目标主要参与者：收银员涉众及其关注点：收银员：希望能够准确、快速地输入，而且没有支付错误，因为如果少收货款，将从其薪水众扣除。售货员：希望自动更新销售提成顾客：希望以最小代价完成购买活动并得到快速服务。希望便捷、清晰地看到所输入的商品项目和价格。希望得到购买凭证，以便退货。公司：希望准确地记录交易，满足顾客要求。希望确保记录了支付授权服务的支付票据。希望有一定的容错性，即便在某些服务器构件不可用时（如远程信用卡验证），也能够完成销售。希望能够自动、快速地更新帐户和库存信息。经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。前置条件：收银员必须经过确认和认证。成功保证（或后置条件）：存储销售信息，更新帐户和库存信息，记录提成，生成票据，记录支付授权的批准。,fanrui_n2020/5/23,主成功场景,1.顾客携带所购商品或服务到收银台通过POS机付款。2.收银员开始一次新的销售交易。3.收银员输入商品条码。4.系统逐步记录出售的商品，并显示该商品的描述、价格和累计额。价格通过一组价格规则来计算。收银员重复34步，直到输入结束。5.系统显示总额和计算折扣。6.收银员告知顾客总额，并请顾客付款。7.顾客付款，系统处理支付。8.系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理和提成）和库存系统（更新库存）。9.系统打印票据。10.顾客携带商品和票据离开。,fanrui_n2020/5/23,开发活动图,UML活动图通过提供特定的场景内交流的图形化表示来补充用例。活动图符号：两端为半圆形的矩形表示一个特定的系统功能箭头表示通过系统的流判定菱形表示判定分支水平线、分叉点和连接表示并发活动对象节点表示活动对象活动图通常能够既表示控制流又表示数据流。UML活动图代替传统的数据流图（DataFlowDiagram）表示法,fanrui_n2020/5/23,处理销售用例中的UML活动图,fanrui_n2020/5/23,泳道图,UML泳道图（swimlane）是活动图的一种有用的变形可以让建模人员表示用例所描述的活动图，同时看哪个参与者或分析类对活动矩形所描述的活动负责。泳道用纵向分割图的并列条形部分表示，就像游泳池中的泳道，也称特定分区。UML泳道图通常对于涉及众多参与者的非常复杂的业务过程建模具有价值。,fanrui_n2020/5/23,泳道图举例,fanrui_n2020/5/23,建立领域模型,领域模型能捕获语境中最重要的对象模型，领域对象代表系统工作的环境中存在的事情或发生的事件。领域有三种典型的形式：业务对象，表示业务中可操作的东西，例如订单、帐户和合同等。系统需要处理的现实世界中的对象和概念，如导弹、轮船等。将要发生或已经发生的事件，例如飞机起飞或午餐休息等。领域建模的目的是理解和描述在领域语境中最重要的类,fanrui_n2020/5/23,分析类,分析类侧重于处理功能性需求通过较高的、非形式化层次的职责类定义某行为分析类三种基本构造型：边界类：边界类用于建立系统与其参与者之间交互的模型，经常代表对窗口、窗体、窗幕、通信接口、打印机接口、传感器、终端以及API等的抽象。每个边界类至少应该与一个参与者有关，反之亦然。控制类：控制类代表协调、排序、事务处理以及其他对象的控制，经常用于封装与某个具体用例有关的控制。控制类还可以用来表示复杂的派生与演算，如业务逻辑。实体类：实体类用于对长效持久的信息建模。大多数情况下，实体类是直接从业务对象模型中相应的业务实体类得到的。,fanrui_n2020/5/23,分析类举例,fanrui_n2020/5/23,控制类,控制类类似于设计模型中的控制器类，其目的是UI层之上的第一个对象，主要负责接收和处理系统操作消息。把职务分配给能代表以下选择之一的类：代表整个“系统”、“根对象”、运行软件的设备或主要子系统，这些是外观控制器的所有变体。代表用例场景，在该场景中发生系统事件，通常命名为UsecaseName+Handler、UsecaseName+Coordinator或UsecaseName+Session。,fanrui_n2020/5/23,控制类举例,fanrui_n2020/5/23,用例实现分析,用例实现分析是分析模型内部的一种协作，主要描述了如何根据分析类及其交互的分析对象来实现和执行一个具体的用例。用例实现包括事件流的文本描述、反映参与者用例实现的分析的类图以及按照分析对象的交互作用描述特定流实现或用例脚本的交互图。用例实现侧重于功能性需求。,fanrui_n2020/5/23,处理销售类图,fanrui_n2020/5/23,交互图,当参与者向系统发送某种形式的消息而激活用例时，开始执行该用例中的动作序列。边界类对象将接收来自参与者的消息。边界对象向其他对象发送一个消息，并使有关对象与之交互从而实现该用例。在分析阶段，通常使用协作图类描述用例的实现。协作图又称为通信图，是以图或网络格式描述对象交互，其中对象可以置于图中任何位置。,fanrui_n2020/5/23,fanrui_n2020/5/23,分析包,分析包描述了对分析模型的制品进行组织的方式，它可以包括分析类、用例实现及其他分析。分析包应是有强内聚性与低耦合性，具有以下特点：分析包可以表示对分析内容的分割。在统一过程中，服务的概念是由服务包支持的。服务包在按照系统提供的服务而组织的分析包层次结构中处于较低层。服务包包含了一组活动相关的类，服务包不可分割。在实现用例时，可能会有一个或多个服务包参与其实现。服务包相对独立，可以复用。UML包图用于描述系统的逻辑架构层、子系统、包等。UML包用一大一小两个矩形组合而成。如果内部显示了其成员，则包名称标在上面的小矩形内，否则，可以标在包内。,fanrui_n2020/5/23,UML包图,fanrui_n2020/5/23,逻辑架构,逻辑架构是类的宏观组织结构，它将类组织为包、子系统和层等。层是对类、包或子系统的甚为粗粒度的分组，是有对系统主要方面加以内聚的职责。,fanrui_n2020/5/23,分层逻辑架构,fanrui_n2020/5/23,关联与依赖,两个分析类以某种方式相互联系，这些联系被称作关联。关联可进一步指出多样性，也称为基数。两个分析类之间存在客户服务器联系，客户类在某些方面依赖于服务器类并且建立了依赖关系。,fanrui_n2020/5/23,识别属性和操作,属性描述类的性质，可以通过分析该类存在的一些信息类构建。操作定义了某个对象的行为。操作可以分为四种类型：以某种方式操纵数据，例如：添加、删除、选择、更新等。执行计算的操纵，例如：销售中的计算总价。请求某个对象状态的操作。监视某个对象发生某个控制事件的操作。操作的构造需要交互图和场景描述等手段多次反复分析才能获取。在研究语法分析并分离动词作为候选的操作。推荐的一个方法是使用CRC技术。,fanrui_n2020/5/23,CRC技术,CRC(Class-Responsibility-Collaborator,类-职责-协作者)建模提供识别和组织与产品相关的类。一旦系统的基本使用场景（用例）确定后，则要标识侯选类，指明它们的责任和协作，即类-责任-协作者建模：责任是与类相关的属性和操作，即责任是类知道要做的事情。协作者是为某类提供完成责任所需要的信息的类，即协作类。CRC建模方法提供了一种简单标识和组织与系统或产品需求相关的类的手段。CRC模型是一组表示类标准的索引卡CRC卡的集合。CRC卡的内容分成三个部分：类的名字类的责任协作类,fanrui_n2020/5/23,销售类CRC卡,fanrui_n2020/5/23,第8讲面向对象分析行为建模,行为模型显示了软件如何对外部事件或激励做出响应。要生成行为模型，分析师必须按如下步骤进行：评估所有的用例，以使得完成理解系统内的交互序列。识别驱动交互序列的事件，并理解这些事件如何和具体的类相互关联。为每个用例生产序列。创建系统状态图。评估行为模型以验证准确性和一致性。,fanrui_n2020/5/23,系统顺序图,系统顺序图（SystemSequenceDiagram,SSD）是为了阐述与讨论系统相关的输入和输出事件而快速、简单地创建的制品。它们是操作契约和重要对象设计的输入。用例文本及其所示的系统事件是创建SSD的输入。SSD展示了直接与系统交互的外部参与者，系统以及由参与者发起的系统事件。SSD可以用UML顺序图的形式表示，用以阐述外部参与者到系统的事件。系统事件就是将系统看作黑盒，参与者为完成功能而向系统发出的事件。,fanrui_n2020/5/23,处理销售用例的系统SSD,fanrui_n2020/5/23,操作契约,操作契约使用前置条件和后置条件的形式，详细和精确描述领域模型中的对象的变化，并作为系统操作的结果。操作契约的主要输入是SSD中确定的系统操作、领域模型和领域专家的见解。操作契约四部分：操作是指操作的名称和参数交叉引用是指会发生此操作的用例前置条件是指执行操作之前对系统领域模型对象状态的假设后置条件是指完成操作后，领域模型对象的状态,fanrui_n2020/5/23,后置条件,后置条件（PostCondition）描述了领域模型内对象状态的变化。领域模型状态变化包括创建用例、形成或消除关联以及改变属性。后置条件不是在操作过程中执行的活动，相反，它们是对领域模型对象的观察结果。后置条件可以分为三种类型：创建或删除实例属性值的变化形成或消除关联,fanrui_n2020/5/23,操作enterItem的契约,操作名称：enterItem(id,quantity)交叉引用：处理销售用例前置条件：正在进行的销售后置条件：（1）创建了SaleLineItem的实例（创建关联）（2）SaleLineItem与当前Sale关联（形成关联）（3）SaleLineItem.quantity赋值