第6章 软件需求分析与建模.ppt

软件需求概论,2,第6章需求分析与建模最佳实践,6.1需求分析与建模的要点与误区分析6.2周期一:理清框架与脉络6.3周期二：确定需求细节6.4其他需求分析,需求分析是需求工程中最为核心的工作，而需求建模则是需求分析的主要手段。,3,6.1需求分析与建模的要点与误区分析,6.1.1需求分析到底做什么6.1.2建模的目标与要点6.1.3选择建模工具的要点,4,6.1.1需求分析到底做什么,需求分析是业务分析，也就是选择一种业务导向的线索将零散的需求串起来，形成一个体系完整、内容清晰的框架，以指导后续的设计、开发工作。概括为：分解、提炼、消除矛盾,5,需求分析到底做什么之一：分解,分解：自顶向下的方法现代需求工程理论更建议采用业务导向的分解，而非传统的系统导向的分解。分解结构类型(1)业务流程为主线索的分解结构联机事务处理系统、管理信息系统适用。(2)程序结构为主线索的分解结构适用于问题域不复杂或者系统与问题域关联性不强的情况。,6,6.1.1需求分析到底做什么,(3)基于场景的分解结构适用于决策支持系统、面向用户的嵌入式系统(4)基于数据的分解结构适用于诸如数据仓库之类的数据类项目选择了一个合适的分解结构之后，就可以把需求规格说明书的大纲确定下来，知道应该捕获什么信息；因此当信息捕获回来后，需求分析的任务就是将其填充到相应的级别上，并不断验证是否已经填充完成。,7,需求分析到底做什么之二：提炼,提炼：自底向上的方法分解是一种自顶向下的方法，当你按任何一种线索进行分解时，就会破坏其他线索的完整性。例如，如果以“事”为线索，那么会发现数据需求分解后就会出现相互交叠的情况，也就是在多个业务事件中都涉及相同的类。当出现这样的现象时就会阻碍需求分析人员建立全面理解，因此我们还需要采用自底向上的方法进行提炼。,8,需求分析到底做什么之三：消除矛盾,在分析过程中，显然会发现有些需求是相互矛盾、相互冲突的。由于你是在把收集的信息放在一个预先定义的结构中发现这些矛盾的，因此对矛盾的影响范围会有直观的了解，也知道它影响到哪些层面。这样，你就可以很快地找到相应的人员，通过进一步的捕获来消除矛盾。,9,6.1.2建模的目标与要点,建模是需求分析的主要手段，它通过简化、强调来帮助需求分析人员理清思路，达成共识1.建模的目的帮助我们按照实际情况或按我们需要的样式对系统进行可视化；提供一种详细说明系统的结构或行为的方法；给出一个指导系统构造的模板；对我们所做出的决策进行文档化。,10,6.1.2建模的目标与要点,2建模的要点与原则要点：设计要考虑到计划之外的变化；设计要文档化；用可视化的模型表达架构，有助于理解变化所代表的含义。原则：模型是用来沟通的，需要时才构建。,11,6.1.3选择建模工具的要点,1正确认识建模方法论,12,6.1.3选择建模工具的要点,2正确认识UMLUML是一种Language(语言)！UML是一种Modeling(建模)Language!UML是一种Unified(统一)ModelingLanguage！如何选择UML图？,13,第6章需求分析与建模最佳实践,6.1需求分析与建模的要点与误区分析6.2周期一:理清框架与脉络6.3周期二：确定需求细节6.4其他需求分析,14,6.2周期一:理清框架与脉络,6.2.1业务流程分析6.2.2业务实体分析6.2.3角色与使用场景分析6.2.4周期一的产物,15,6.2周期一:理清框架与脉络,16,6.2.1业务流程分析,这个阶段的任务是理清需求的结构框架(领域类图)和行为脉络(流程图和用例图)该工作的输入是需求定义阶段产生的业务事件列表和报表列表，输出的是领域模型和用例模型在整个过程中是针对每个业务事件进行业务流程分析、业务实体分析和用例分析；针对每类报表业务实体分析和用例分析。,17,6.2.1业务流程分析,业务流程分析是针对每个业务事件来进行的，业务事件是业务流程的触发，沿着对业务事件的响应序列，找到所有相关的业务活动，表述出这些业务活动之间的关系就是该任务的关键目标。在业务流程分析中，信息的主要来源是负责该业务流程的中层管理人员，因此访谈的对象就是这一类人员。具体来说，它就是针对每一个业务事件，分析并识别现有业务活动，确定业务活动之间的关系；了解这些业务活动需要接受哪些信息，将产生哪些数据(表单)，确定数据传送的路线；同时标识出业务活动是由哪些部门、岗位负责等信息。在分析过程中，要注意抓住核心业务和主要活动点、部门内以及部门之间的衔接，工作中的烦琐及反复的环节，成本高、效率低、时间长的环节以及任务转手次数较多的环节。,18,1.业务流程分析的要点与产物,关键的要点：一是理解流程的层次性；三大层次：组织级，部门级，岗位级二是了解流程的类型；生产性流程，管理性流程，支持性流程三是掌握以业务事件识别、寻找流程的技巧。流程分析产物，最常使用的模型有三种：跨职责流程图、活动图和数据流图。,19,2.跨职责流程图应用基础与要点,跨职责流程图是商业建模的标准工具，它定义了一套标准的建模元素和建模方法.(1)跨职责流程图的主要元素流程名称职责带区流程阶段流程元素并行流程引用,20,2.跨职责流程图应用基础与要点,(2)绘制要点在进行业务流程分析时，关键的入手点是部门级的业务流程，也就是从业务事件出发，分析该业务事件会触发的一系列活动。要真正保障绘制出来的跨职责流程图是真实、有效的，就必须强化用户的参与。具体来说，我们应该先找到业务事件的负责人，然后通过设问的方式，让他描述响应该业务事件所进行的活动，说明活动的执行岗位以及它们之间的关系、数据传递。,21,跨职责流程图的绘制示例,每年初将由航标站根据本年度的计划任务，并结合上一年度的情况制订新年度计划，形成向航标处业务部门提交的工作计划。航标处业务部门对其工作计划进行审核，同时上报处计划部门，计划部门对其进行反馈。航标处业务部门进行补充，形成“工作计划”上报处领导。由航标处领导对其进行审核与确认，并形成“工作任务”下发给养护中心。然后再由养护中心安排具体的采购计划。采购计划生成后报航标处领导审批后进行采购流程。,22,跨职责流程图的绘制示例,23,3.活动图应用基础与要点,(1)活动图概述活动图是一种表述过程机理、业务过程以及工作流的技术。它可以用来对业务过程、工作流建模，也可以对用例实现甚至是程序实现来建模。(2)活动图的主要元素(最主要的几种建模元素)初始节点和活动终点活动节点转换分支与监护条件分岔与汇合,24,3.活动图应用基础与要点,(3)带泳道的活动图(4)带对象流的活动图(5)复杂活动图辅助活动图汇合描述发送信号与接收信号引脚(pin)扩展区(ExpansionRegion)(6)绘制活动图之后,25,4.数据流图应用基础,数据流图(DFD)是一种历史悠久的建模方法，它对于数据流为主线索的处理过程是最合适的，例如计费系统。(1)数据流图的主要元素,26,4.数据流图应用基础,(2)分层的数据流图数据流图模型中引入了层次结构的数据流程图。它是按照系统的层次结构进行逐级分解的，以分层的数据流图来反映这种结构关系,27,以下是绘制数据流图的一些约定规则：过程通过数据存储区进行通信，而不是从一个过程直接流到另一个过程。使用数据流图时，不要试图让数据流图反映处理顺序。用简明的动词短语命名每一个过程：动词加对象。过程的编号要惟一且具有层次性。在单个图中绘制的过程不要超过810个，否则就很难绘制、更改和理解它。与圆圈相连的数据流不允许只有输入或只有输出。,28,4.数据流图应用基础,(3)数据流图的绘制过程通过标识业务事件完成从顶层图到0层图的分解；再通过将业务事件分解成业务活动实现0层图到1层图的细化；然后就是通过将业务活动分解成业务步骤实现1层图到2层图的分解。,29,4.数据流图应用基础,(3)数据流图的绘制过程构建顶层图“课程注册系统”,30,4.数据流图应用基础,(3)数据流图的绘制过程根据业务事件绘制DFD片段,31,根据业务事件绘制DFD片段,32,4.数据流图应用基础,(3)数据流图的绘制过程将DFD片片段合并成DFD,33,4.数据流图应用基础,(3)数据流图的绘制过程逐步细化，分解到底,34,622业务实体分析,在业务流程中，必须会涉及许多业务实体(或称为业务数据、业务术语)，要正确地构建出信息系统，就必须对这些业务实体建立正确的认识。具体来说，就是要了解这个问题域中有哪些业务实体，它们之间存在什么样的逻辑关系、数量关系，以及有什么相应的结构规则。实际上这样的工作就是大名鼎鼎的“领域建模”、“概念建模”。,35,1业务实体分析任务概述,在领域建模的过程中，应该更多地采用“自底向上”的方法；针对每一个业务事件、每一类报表创建局部的领域类图片段，然后当完成这些建模工作之后，再对其进行抽象、提炼，形成全局的领域模型。针对每一个业务事件、每一类报表进行领域类图片段的绘制时，其主要的步骤包括三个：识别出业务实体，确定实体之间的关系(语义关系和数量关系)，定义实体的关键属性。,36,1业务实体分析任务概述,业务实体分析的产物有两种可选的模型：类图E/R模型也叫实体关系图,37,2.类图应用基础及要点,38,（1）领域建模方法示例,领域建模时，其工作主要就是标识类明确类之间的逻辑关系和数量关系添加重要的结构规则三个方面。,39,参考案例：个人图书管理系统需求概述,小王是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版杜等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。还希望能够对书籍的购买金额、册数按特定时间周期进行统计。,40,标识类,发现类的方法有很多种：脑力风暴：所谓脑力风暴是指我们看到需求或模型后，感觉到系统中应该存在哪些分析类。词性分析法：所谓词性分析法，是指我们根据需求描述或模型中的词汇进行分析，在分析过程中，按词性进行类、属性、方法的划分。(领域模型)CRC分析法（候选类、职责、协作分析法）：CRC分析法也是一个简单易行的分析方法。通过对那些可能的类进行职责与协作的分析，进一步确认系统中的分析类及其属性、方法。CRC分析法要求我们对每一个候选类做一个卡片，在卡片上对这个类进行描述，在描述的下面写上这个类的职责，在背面写出与这个类有协作关系的其它类及协作关系。(领域模型)根据边界类、控制类、实体类帮助分析系统中的类(分析模型)其中最广泛应用的莫过于“名词动词法”，,41,标识类,问题域建模的第一步-标识类名词动词法，其主要规则是从名词与名词短语中提取对象与属性；从动词与动词短语中提取操作与关联；而所有格短语通常表明名词应该是属性而不是对象。,42,找到备选类：,小王是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版杜等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。还希望能够对书籍的购买金额、册数按特定时间周期进行统计。,43,决定候选类,类剔除原则：无关紧要的类系统外的类表述的概念相对较小，适合于某个候选类的属性非问题域本质类,44,“小王”、“人”、“家里”系统外的概念，无须对其建模；“个人图书管理系统”、“系统”指的就是将要开发的系统，即系统本身，也无须对其进行建模；“书籍”是一个很重要的类，而“书名”、“作者”、“类别”、“出版社”、“书号”则都是用末描述书籍的基本信息的，因此应该作为“书籍”类的属性处理。而“规则”是指书号的生成规则，书号则是书籍的一个属性，因此“规则”可以作为编写“书籍”类构造函数的指南；“基本信息”则是书名、作者、类别等描述书籍的基本信息统称，“关键字”则是代表其中之一，因此无须对其建模；“功能”、“新书籍”、“信息”、“记录”都是在描述需求时使用到的一些相关词语，并不是问题域的本质，因此先可以将其淘汰；“计算机类”、“非计算机类”是该系统中图书的两大分类，因此应该对其建模，并改名为“计算机类书籍”和“非计算机类书籍”，以减少歧义；,45,“外借情况”则是用来表示一次借阅行为，应该成为一个候选类，多个外借情况将组成“外借情况列表”，而外借情况中一个很重要的角色是“朋友”借阅主体。虽然本系统中并不需要建立“朋友”的资料库，但考虑到可能会需要列出某个朋友的借阅情况，因此还是将其列为候选类。为了能够更好地表述，将“外借情况”改名为“借阅记录”，而将“外借情况列表”改名为“借阅记录列表”；“购买金额”、“册数”都是统计的结果，都是一个数字，因此不用将其建模，而“特定时限”则是统计的范围，也无须将其建模。不过从这里的分析中，我们可以发现，在该需求描述中隐藏着一个名为“书籍列表”的关键类，它也就是执行统计的主体,46,通过以上的分析，我们就可以得到一个候选类列表：书籍计算机类书籍非计算机类书籍借阅记录借阅记录列表书籍列表,47,明确类间关系之确定关联关系,确定关联关系“计算机类书籍”、“非计算机类书籍”与“书籍”之间是继承关系“书籍列表”则是由多个“书籍”组成的，“借阅记录列表”是由多条“借阅记录”组成的，这种组成关系适用于组合还是聚合关系?-聚合更合适“借阅记录”与“书籍”关联关系,初始类模型,48,明确类间关系之多重性分析,加入多重性信息,49,确定类的主要职责,类的职责：类所维护的知识-类的成员变量(即属性)类能够执行的行为-成员方法（属于行为需求领域，体现在用例模型中）,加入类的属性,50,补充类之间的结构规则,类图中的诸如导航性、角色名、导出属性、限定符及约束等修饰属性导航性分析“书籍”与“借阅记录”之间存在关联关系。它们之间是一种双向关联约束“书籍”对象创建后就不能够被删除，只能被修改，因此在Book类边上加上了一条用自由文本写的约束；显然一本书要么属于计算机类，要么属于非计算机类，因此在两个“泛化”关系上增加一个“二者取之一”的约束。,51,（2）领域建模的常见误区,ICONIK方法的创始人曾经对领域建模工作总结了10大误区一些解释:立即给关联指定多重性，确保每个关联都有明确的数量关系对名词和动词做过度的分析，而背离初衷-“分析崩溃”不对用例和时序图进行研究，就将操作分配给类对象和类的通用程度越高，在其他项目中重用它们的可能性就越大。【案例：模块管理、导入；报表管理、导入】,52,（2）领域建模的常见误区,对于每个“整体部分”关系，就使用聚合还是组合表示而争论不休未对问题空间进行建模之前，就假定一种具体的实现策略将类命名为难以理解的名称，而不是直观的名称直接进入到实现结构，如友元关系和参数化类领域类和关系型数据库表之间建立一对一的映射过早地执行“模式化”,53,2.类图应用基础及要点,(3)类模型的演化类模型是从需求分析、设计阶段不断演化而成的，其过程如图656所示。,54,方法4：分析模型中有3种十分有用的构造型：实体类、控制类和边界类,实体类：实体对象的抽象，通常来自域模型也就是现实世界，用来描述具体的实体，通常映射到数据库表格与文件中。控制类：控制对象的抽象，主要用来体现应用程序的执行逻辑，将其抽象出来，可以使得变化不影响用户界面和数据库中的表。边界类：边界对象的抽象，通常是用来完成参与者(用户、外部系统)与系统之间交互的对象，例如From、对话框、菜单、接口等。分析模型通常是在用例模型和领域模型的基础上进行综合分析而得的。从领域模型中将得到实体类，而边界类主要负责处理与用户的交互，控制类则负责完成实际的程序逻辑。,55,实体类、控制类和边界类,转pdf,56,3E/R图应用基础,描述业务实体之间的关系除了可以使用类图之外，也可以使用传统的E/R模型。优势：能够更好地与后续的数据库设计结合。缺点：语义相对于类图来说更弱一些，同时对面向对象开发的指导作用相对差一些。,57,3E/R图应用基础,(1)数据建模过程,58,(1)数据建模过程,概念模型VS逻辑模型概念模型和逻辑模型有什么区别呢?它们实际上是对“需求视图”与“开发视图”的区分。换句话说，概念模型是需求人员的视图，等价于现在出镜率很高的领域模型；而逻辑模型是开发人员(包括设计人员)的视图，它约等于面向对象分析与设计方法中提到的“分析模型”。,59,概念模型VS逻辑模型具体区别：完整性：逻辑模型在完整性上要比概念模型更胜一筹，通过在需求细化、设计的阶段会对类的属性进行细化，会补充一些新的类。加工方式：概念模型的原则是忠于问题域，而逻辑模型则会从实现的便利性和需要的角度进行细化，具体来说可能会对一些类进行分拆、合并。逻辑模型VS物理模型区别实际上是对“开发视图”与“数据库视图”的区分，换句话说，物理模型就是DBA的视图。,60,6.2.3角色与使用场景分析,在传统的结构化分析与设计方法中，整个分析视角是站在解决方案域的，很容易产生对问题域分析不足的结果。以用例技术(属于面向对象分析与设计方法的范畴)为代表的现代需求分析方法则更侧重于“从用户的角度，将系统当做一个黑盒子”的视角。用例分析技术的关键是“发现使用系统的角色(参与者)，了解并梳理这些角色将如何使用系统(场景)”，从而更好地完成“人”的视角的需求梳理。,61,1.用例分析概述,用例图是用例分析的全部内容？错！用例分析包括：用例图和用例描述。用例图是目录，用例描述是封装所有需求的形式。,用例分析的组成,62,6.2.3角色与使用场景分析,2参与者与用例(1)参与者:参与者是在系统之外，透过系统边界与系统进行有意义交互的任何事物。,63,(2)用例,根据RUP的定义：用例实例(场景)是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。用例场景是有步骤的(执行了一系列动作)：也就是说，它是一个由一系列业务步骤组成的业务活动。用例场景是有目标的(可见的价值结果)：也就是说，它能够为参与者带来有意义的结果，例如“填写搜索条件”显然就是对参与者而言没有意义的，就不是一个合适的用例。例是对一组用例实例(场景)的抽象，也就是说，用例是有路径(基本事件流、扩展事件流、子事件流等)的。例如我们在从M上取款时，可能会遇到很多不同的场景：正常取到钱、卡里钱不够、密码忘了、机器里没有足够的钱、卡被吞了等；而这些都可以概括为一个名为“取款”的用例。,64,(2)用例,从某种意义上说，用例和具体场景(用例实例)之间的关系和类与对象之间的关系是类似的。一个场景是一个具体的行为，一个用例是对一类相关行为的抽象。,65,3用例图,用例图的构成，以及用例与用例之间的关系、参与者与用例之间的关系、参与者与参与者的关系,66,3用例图,(1)系统边界(2)参与者与用例的关系一个参与者表示用例的使用者在与这些用例进行交互时所扮演的角色。(3)用例之间的关系包含、扩展和泛化(4)参与者之间的关系参与者之间的关系只有一种，那就是泛化。,67,用例之间的关系,包含关系在UML中，包含关系用构造型include表示(箭头方向是从基用例到被包含用例)，它是指基用例(baseusecase)在它内部说明的某一个位置上显式地合并了另一个用例的行为。扩展关系在UML中，扩展关系用构造型extend表示(注意箭头方向是从扩展用例到基用例)，它表示基用例在由扩展用例间接说明的一个位置上，隐式地合并了另一个用例的行为。,68,泛化关系而用例之间的泛化则表示子用例继承了父用例的行为和含义；子用例还可以增加或覆盖父用例的行为；子用例可以出现在父用例出现的任何位置。,69,70,(4)参与者之间的关系,参与者之间的关系只有一种，那就是泛化。,71,小结,72,4用例的来源,自顶向下导出法自底向上合并法,73,4用例的来源-(1)自顶向下导出法,自顶向下导出法就是从流程图(流程图是通过将系统分解成主题域，再从主题域中标识出业务事件，然后为业务事件绘制出流程图)中派生出用例图。有了针对各个业务事件处理过程的流程图，我们就可以从中导出相应的用例。岗位信息-参与者的候选者业务活动-用例的候选者,74,4用例的来源-(1)自顶向下导出法,针对每张流程图进行分析之后，就可以得到一组用例图片段，然后将它们叠加在一起，就可以抽象出系统的用例模型。如图681所示的是某税务效能管理系统中针对“业务申请”流程所绘制的一张跨职责流程图，下面就以它为例，说明如何从流程图中派生出用例图。,75,76,利用流程图，“边界确定”、“角色确定”，以得出表示系统边界的用例图。边界确定(去除非EndUser的职责带区)首先要排除掉不直接使用系统的岗位，因为它们不是系统要涉及的范畴。确定角色(对剩下的职责带区进行角色化)对于职责带区“涉税窗口”。对于职责带区“局内业务科室”。确定用例用例则是从职责带区中的业务活动派生出来的。分析过程见表6-9，6-10,77,对于活动，主要是判断它是否属于系统范畴之内；对于判断，则要分析它是属于某个活动还是一个独立的活动。,78,4用例的来源-(1)自顶向下导出法,绘制用例图,79,4用例的来源-(2)自底向上的合并法,步骤收集原始需求当我们获得这样的原始需求列表之后，就可以开始通过合并的方法来导出用例。当然，我们首先需要确定有哪些参与者。确定参与者开发人员：对任务进行操作和时间记录；项目经理：对项目的任务进行分配，了解项目内产能；研发经理、管理层：确定项目及进行产能统计工作。,80,4用例的来源-(2)自底向上的合并法,合并用例将“原始需求”按参与者分组，然后再合并或分解为相应的用例。绘制用例图,81,82,83,84,5用例分析技术应用要点,(1)用例真的有粒度吗业务价值判断是关键被包含用例、扩展用例技术性用例的引入“用例粒度与系统复杂度相关”的观点是错误的影响用例大小的是业务流程，是工作任务的分工CRUD的价值被过于放大了CRUD是指在做计算处理时的增加(Create)、查询(Retrieve)（重新得到数据）、更新(Update)和删除(Delete)用例合并成“管理*”,CRUD原则对于“系统创造的东西”才适用，例如管理系统用户、管理数据字典、管理权限、管理购物车之类的东西就适用于该原则。,85,5用例分析技术应用要点,(2)用业务动词命名用例十分重要某开发团队在开发银行信用卡管理系统时，整理了一些用例，其中包括：创建客户、更新客户、删除客户。,86,5用例分析技术应用要点,(3)采用先事后人的方式分析是要点应该将人(角色、参与者)和事(场景、用例)分开考虑；在确定它们之间关联时，要先事后人地思考。在确定了参与者之后，再抽取出“事”(也就是用例)，然后完成它们之间的连接，就可以很轻松地获得更合理的结果了。,87,案例,在开发一套医院管理系统时，分析人员了解到如下所示的需求：在药房中，有3个主参与者：接待员、药房技师和药剂师。其中任何一个参与者都可能接待客户，接收处方。药房技师和药剂师都可以按照处方抓药，但只有药剂师有权审核处方并在处方中签字，而药房技师是协助药剂师的。找出参与者：接待员、药房技师和药剂师抽取出“事”（用例）：收处方、配药、审核(业务活动)找出关系：,88,89,62.4周期一的产物,体检医院管理系统“客服管理子系统”、“体检业务子系统”和“物资管理子系统”三个主题域。以“体检业务子系统”为例。1工作任务说明在需求分析的第一阶段，核心任务就是结合业务流程、报表的需求，梳理出结构框架(领域模型)和行为脉络(流程图-用例模型)，为第二阶段的需求分析工作建立基础；指出方向。而具体来说，就是从上一阶段标识出来的业务事件(业务流程的起点)和报表列表开始，展开对中层管理人员的访谈与调研，而范围就是“体检业务子系统”所对应的服务中心、体检科室和综合科三个部门。然后再根据访谈的结果完成事、物、人的分析，最后在此基础上抽象出该主题域的领域模型和用例模型。,90,2业务事件分析标识出了体检者申请体检、体检者中途改单、财务部门提交团队缴费情况、客服中心查询体检情况、维护人员管理体检项和系统通知用户取报告6个业务事件以“体检者申请体检”业务事件为例进行业务流程分析、业务实体分析、角色使用场景分析,91,体检者申请体检-业务流程,访谈过程中，用户代表描述的信息：当体检者要体检时，首先将到服务中心办理。如果已经预约，则告诉服务人员其预约号或姓名；如果没有预约则填写体检申请表，选择体检项目或体检套餐(可以自由组合体检项目和体检套餐)。服务人员将根据预约单或体检申请表的内容生成系统中的体检单，并打印出来。体检者拿着体检单到收费窗口交费，收费人员根据体检单中的体检项或体检套餐对应的费用项计算总费用，生成相应的账单，收完费用后在体检单上盖上“收费已迄”的图章；如果公司已经付过相应费用，则直接盖上“收费已迄”图章。体检者拿着体检单到各体检科室进行体检，体检医生体检完后在体检单上注明已体检，并在体检完成后将该体检项的体检结果记录在电脑中。当所有的体检项都体检完之后，综合科医生将根据体检结果填写体检报告。当体检报告生成完毕后，服务人员就可以将其返还给客户。客户可以自行领取，可由公司代表统一领取，也可以由客服中心人员代为领取。,92,(1)体检者申请体检业务流程分析,93,业务实体分析业务实体分析的关键是理清问题域中的关键术语之间的关系，找出候选类，及其关系，绘制类图,94,角色使用场景分析。最后我们还将研究项目的边界，完成流程图到用例图的转换，完成系统的角色和使用场景分析。,95,将本业务流程所涉及的所有业务活动以如图6-91所示的用例图表示出来,96,3报表分析对于报表而言，分析工作可以分成why(目标)、what(内容)与How(展现形式)三个层次以“体检业务周期统计报表”为例(1)why:对于报表而言，Why要解决的问题包括：部门职位、目的、相关场景与查询频率等方面的内容。,97,(2)what(内容):对于每一类报表，我们还需要确定与它相关的业务实体(用类图来表示)、主要的数据项、数据项的计算方法，同时还要确定有多少具体的报表。相关业务实体分析报表项分析数据项及计算方法分析,98,4抽象与整理,(1)抽象用例模型(2)抽象类模型,5填充需求规格说明,通过以上分析，就可以完成结构框架和行为脉络的填充，同时将其填充到软件需求规格说明书中。(1)Word文档组织示例(2)Rose组织示例,99,第6章需求分析与建模最佳实践,6.1需求分析与建模的要点与误区分析6.2周期一:理清框架与脉络6.3周期二：确定需求细节6.4其他需求分析,100,6.3周期二：确定需求细节,6.3.1确定行为需求的细节6.3.2确定结构需求的细节6.3.3周期二的产物,101,这个阶段的任务是对用例模型、领域模型标识出用例、领域类的细节进行填充。对于组织行为需求的用例，我们要填充用例的事件流、相关需求与功能点、界面原型，以及特定于该用例的规则与约束；对于组织数据(结构)需求的领域类，我们要填充它的字段与格式，具体包括：字段属性信息：也就是每个领域类所包含的成员属性，细化其构成；字段格式与规则：也就是每个字段详细的格式(诸如字符型、日期型等类型，以及长度可选值等内容)、组成规则(诸如由多少个字符、多少个数字组成等)；计算规则：对于一些非直接输入的派生属性，通过数据表达式的方式来描述；结构规则：对于数据的组成、格式进行描述。,102,6.3.1确定行为需求的细节,1用例的灵活应用2用例描述模板3事件流分析4相关需求整理5界面原型6规则与约束,103,6.3.1确定行为需求的细节,1用例的灵活应用根据行为需求的特点，可以将其分成“业务功能、报表功能、接口、技术支撑”4种类型。统一封装成用例，但在具体细节描述方面，可以对其进行灵活处理，具体的方法如表617所示,104,6.3.1确定行为需求的细节,2用例描述模板而针对业务功能类的用例来说，其需要整理的内容主要包括事件流、相关需求与功能点、界面原型、规则与约束4个方面，描述的方法可以采用通用的用例描述模板来组织。相关的用例描述模板有不少，最常用的包括RUP所提供的经典模型和编写有效用例作者所提供的模板。,105,106,6.3.1确定行为需求的细节,3事件流分析一个用例通常是一组事件流所构成的。整个事件流模型包括：前、后置条件、基本事件流和扩展事件流。(1)前、后置条件所谓前置条件是指在用例启动时，参与者(Actor)与系统应置于什么状态。这个状态应该是系统能够检测到的，在用例启动前能够检测到的，而且还应该是有意义的。所谓后置条件是指在用例结束时，系统应置于什么状态，这个状态应该是系统能够检测到的，在用例结束前能够检测到的，而且也应该是有意义的。,107,6.3.1确定行为需求的细节,3事件流分析(2)事件流的类型对于用例而言，最常见的事件流类型包括3种:基本事件流：是对用例中常规、预期路径的描述。扩展事件流：也称为备选事件流、可选事件流；主要包括可选分支(用户的不同选择)、异常情况等情况。子事件流：用来对事件流中多次重复的部分进行概括，以便在用例描述中复用；通常会对其进行命名。(3)业务用例与系统用例业务用例描述的是所有的业务步骤，而系统用例则只描述与系统相关的业务步骤。,108,案例-机场Checkin场景描述,我招呼队列中的下一名顾客。当他走到我的桌子前时，我要求他出示机票。如果乘客使用电子机票，我需要订票记录标识符。大多数乘客不会记住它，所以我会问他们的姓名和航班。大多数人不知道他们的航班号，所以我通常会问他们的目的地。他们肯定知道的。我确信乘客和航班都是正确的。给错座位或者将乘客送到错误的目的地都会是很尴尬的事情。无论如何，我会设法在计算机中定位乘客的航班记录。如果他没有将护照给我，我会向他要。我会查看护照的照片是否与乘客相似，并检查护照是否仍然有效。如果记票记录没有显示出常客编号，我会问乘客是否参加了我们的里程计划。要么他给我常客卡，要么我问他是否愿意加入，并给他表格。我可以为航班记录提供临时的常客编号，这样乘客就可以将这次行程计入总里程。如果计算机还没有指定座位，我会找一个。这通常意味着我会问顾客靠窗还是靠走道，或者如果座位基本满了，我会告诉他还有哪些座位。当然如果计算机分配了一个座位，我总是会问他是否满意。我们确定了座位后，会在计算机上确认。此时我可以打印登机牌，但是通常我会先处理行李。我会问乘客要托运多少件行李，同时令确认他没有超出携带行李的限制。难以相信有些人总是希望将什么东西都带进空间有限的机舱中。我会对行李提一些安全性问题，并得到乘客的回答。我舍打印出行李标签并将它们安全地贴在行李上，然后我合将行李送到传送带上，完成行李托运工作。接下来我会打印登机牌。这意味着我完成了所有与计算机相关的事情。但还有一件事要做：我要确保每什事都与乘客的理解一致。我会从登机牌上读出他的目的地、航班的时间、何时如何登机，还会说明他托运了多少件行李，并确认行李的目的地与乘客的目的一致，然后将登机牌给乘客，并祝他旅途愉快。,109,6.3.1确定行为需求的细节,4相关需求整理(1)用户原始需求将需求捕获阶段获得的用户原始需求(通常每个原始需求是以一句话)整理到相应的用例中是一种很好的实践，它可以更好地建立用户原始需求和软件需求(用例)之间的映射。(2)相关功能点在需求规格说明书中除了可以将用户原始需求归类整理进来，作为开发时的重要参考依据之外，有时可能还会涉及一些无法有效地表述在事件流中的小功能点。,110,6.3.1确定行为需求的细节,5界面原型(1)要点(2)交互不要忽略,111,5界面原型-(3)别让界面掩盖本质,112,6.3.1确定行为需求的细节,6规则与约束规则是在实现时应该考虑的东西，而约束则是对技术手段选择起到限制作用的各种条件。(1)规则的类型从需求的角度来看，涉及的规则大致可以分为：行为(或称为功能、业务)规则、结构(或称为数据)规则、界面规则三类。行为规则：或称为功能规则、业务规则，它是指和业务逻辑、业务流程相关的规则。结构规则：或称为数据规则，它是指和业务实体、属性、派生属性相关的规则。.界面规则：它是指和用户界面相关的规则。,113,6.3.1确定行为需求的细节,6规则与约束(2)用例级的约束通常来说约束都是全局需求，但也有一小部分是局部的，这类约束通常会放在具体的用例中。具体来说，它主要可以分成以下几种类型：性能指标等非功能要求软、硬件环境限制技术选择限制用户特点及环境限制,114,632确定结构需求的细节,行为需求隐藏在“主题域-业务事件-业务活动(用例)-业务步骤”的分解结构中，也就是归纳在用例模型中；结构需求应该归纳在自底向上生成的领域模型中。,115,632确定结构需求的细节,1基本内容(1)领域模型的组织从领域模型的组织角度说，通常会首先按照主题域进行第一次分解，一个主题域对应一个领域模型，然后根据需要可以将各个主题域中共性的领域类抽取出来，形成全局公共的领域类模型。而对于每个主题域内的领域模型(包括全局公共的领域模型)而言，涉及的领域类可能还是很多，那我们可以根据其逻辑关系划分成不同的部分，通常用包来表示；每个包中就是一个逻辑相关的领域类图片段。接着，我们可以对每张领域类图片段进行简要的概述，罗列针对所有领域类的共性结构规则，然后再分而治之地进行描述,116,632确定结构需求的细节,接下来，我们就可以对每个领域类做进一步描述了。通常可以从“数据窗口分析”、“数据组成与格式”、“派生数据的计算方法”三个角度进行描述。(2)数据窗口分析每个业务事件就是一个数据窗口；根据业务事件所对应的流程图中标识的文档，逐一分析，填充中相应的字段构成，然后再抽取出共性的部分。,117,632确定结构需求的细节,(3)数据组成与格式.数据类型.长度、精度信息.组成格式：也就是具体的构成规则，例如编号由2位字母、6位数字和一个可选的x组成。(4)派生数据的计算方法决策表、决策树p274,118,633周期二的产物,1工作任务说明2填充用例描述3填充领域类细节4填充需求规格说明,119,633周期二的产物,1工作任务说明在需求分析的第一阶段(周期一)，完成了结构框架(领域模型)和行为脉络(流程图十用例模型)的梳理;在第二阶段，工作任务就是填充需求的细节，具体来说就是根据前面说明的过程与内容来填充用例、填充领域类。,120,633周期二的产物,1工作任务说明2填充用例描述3填充领域类细节4填充需求规格说明,121,633周期二的产物,2填充用例描述将用例分成了业务功能类、报表类、接口类和技术类4种。一个业务功能类(Actor服务人员的“开单”用例)、一个报表类(体检业务周期统计报表)的用例来说明填充用例描述的工作有哪些，应该生成什么产物。对于接口类用例的示例请参见“641接口需求”小节，对于技术类用例的说明请参见“642非功能需求的追踪”小节。,122,633周期二的产物,(1)开单用例分析用例概述通常在用例模型创建的同时，我们会对其做概要性描述；内容主要包括用例名称、编号、参与者、用例概述、相关Stakeholder等几个部分。事件流分析对该用例的前、后置条件进行分析。接下来，我们可以对用例的事件流进行分析。相关需求相关需求包括两个方面：一个是用户的原始需求；另一个是需求人员发现难以归纳到用例事件流中的功能点。,123,633周期二的产物,(1)开单用例分析用户界面原型首先应该考虑用户界面原型中的交互过程。为每个窗口进一步创建更加细节的界