软件需求分析与建模PPT学习课件.ppt

Computer&Information软件需求概论1 Computer&Information2第6章 需求分析与建模最佳实践46.1 需求分析与建模的要点 与误区分析46.2 周期一:理清框架与脉络46.3 周期二：确定需求细节46.4 其他需求分析You are here!你在这儿！你在这儿！需求分析是需求工程中最为核心的工作，而需求建模则是需求分析的主要手段。Computer&Information36.1 需求分析与建模的要点 与误区分析46.1.1 需求分析到底做什么需求分析到底做什么46.1.2 建模的目标与要点建模的目标与要点46.1.3 选择建模工具的要点选择建模工具的要点Computer&Information46.1.1 需求分析到底做什么需求分析到底做什么4需求分析是业务分析，也就是选择一种业务导向的线索将零散的需求串起来，形成一个体系完整、内容清晰的框架，以指导后续的设计、开发工作。4概括为：分解、提炼、消除矛盾分解、提炼、消除矛盾 Computer&Information5需求分析到底做什么之一：需求分析到底做什么之一：分解4分解：自顶向下的方法现代需求工程理论更建议采用业务导向的分解，而非传统的系统导向的分解。4分解结构类型(1)业务流程为主线索的分解结构|联机事务处理系统、管理信息系统适用。联机事务处理系统、管理信息系统适用。(2)程序结构为主线索的分解结构|适用于问题域不复杂或者系统与问题域关联性不强的适用于问题域不复杂或者系统与问题域关联性不强的情况。情况。Computer&Information66.1.1 需求分析到底做什么需求分析到底做什么(3)基于场景的分解结构|适用于决策支持系统、面向用户的嵌入式系统适用于决策支持系统、面向用户的嵌入式系统(4)基于数据的分解结构|适用于诸如数据仓库之类的数据类项目适用于诸如数据仓库之类的数据类项目 4选择了一个合适的分解结构之后，就可以把需求规格说明书的大纲确定下来，知道应该捕获什么信息；因此当信息捕获回来后，需求分析的任务就是将其填充到相应的级别上，并不断验证是否已经填充完成。Computer&Information7需求分析到底做什么之二：需求分析到底做什么之二：提炼4提炼：自底向上的方法分解是一种自顶向下的方法，当你按任何一种线索进行分解时，就会破坏其他线索的完整性。例如，如果以“事”为线索，那么会发现数据需求分解后就会出现相互交叠的情况，也就是在多个业务事件中都涉及相同的类。当出现这样的现象时就会阻碍需求分析人员建立全面理解，因此我们还需要采用自底向上的方法进行提炼。Computer&Information8需求分析到底做什么之三：需求分析到底做什么之三：消除矛盾 4在分析过程中，显然会发现有些需求是相互矛盾、相互冲突的。由于你是在把收集的信息放在一个预先定义的结构中发现这些矛盾的，因此对矛盾的影响范围会有直观的了解，也知道它影响到哪些层面。这样，你就可以很快地找到相应的人员，通过进一步的捕获来消除矛盾。Computer&Information96.1.2 建模的目标与要点建模的目标与要点4 建模是需求分析的主要手段，它通过简化、强调来帮助需求分析人员理清思路，达成共识 41.建模的目的帮助我们按照实际情况或按我们需要的样式对系统进行可视化；提供一种详细说明系统的结构或行为的方法；给出一个指导系统构造的模板；对我们所做出的决策进行文档化。Computer&Information106.1.2 建模的目标与要点建模的目标与要点42建模的要点与原则 要点：|设计要考虑到计划之外的变化；设计要考虑到计划之外的变化；|设计要文档化；设计要文档化；|用可视化的模型表达架构，有助于理解变化所代表的用可视化的模型表达架构，有助于理解变化所代表的含义。含义。原则：模型是用来沟通的，需要时才构建。Computer&Information116.1.3选择建模工具的要点选择建模工具的要点41正确认识建模方法论 Computer&Information126.1.3选择建模工具的要点选择建模工具的要点42正确认识UML UML是一种Language(语言)！UML是一种Modeling(建模)Language!UML是一种Unified(统一)Modeling Language！4如何选择UML图？Computer&Information13第6章 需求分析与建模最佳实践46.1 需求分析与建模的要点与误区分析46.2 周期一:理清框架与脉络46.3 周期二：确定需求细节46.4 其他需求分析You are here!你在这儿！你在这儿！Computer&Information146.2 周期一:理清框架与脉络 46.2.1 业务流程分析业务流程分析46.2.2 业务实体分析业务实体分析46.2.3 角色与使用场景分析角色与使用场景分析46.2.4 周期一的产物周期一的产物Computer&Information156.2 周期一:理清框架与脉络Computer&Information166.2.1 业务流程分析业务流程分析4这个阶段的任务是理清需求的结构框架结构框架(领领域类图域类图)和和行为脉络行为脉络(流程图和用例图流程图和用例图)4该工作的输入输入是需求定义阶段产生的业务事件列表和报表列表，输出的是输出的是领域模型和用例模型4在整个过程中是针对每个业务事件业务事件进行业务流程分析、业务实体分析和用例分析；针对每类报表每类报表业务实体分析和用例分析。Computer&Information176.2.1 业务流程分析业务流程分析4业务流程分析是针对每个业务事件来进行的，业务事件是业务流程的触发，沿着对业务事件的响应序列，找到所有相关的业务活动，表述出这些业务活动之间的关系就是该任务的关键目标。4在业务流程分析中，信息的主要来源是负责该业务流程的中层管理人员，因此访谈的对象就是这一类人员。具体来说，它就是针对每一个业务事件，分析并识别现有业务活动，确定业务活动之间的关系；了解这些业务活动需要接受哪些信息，将产生哪些数据(表单)，确定数据传送的路线；同时标识出业务活动是由哪些部门、岗位负责等信息。4在分析过程中，要注意抓住核心业务和主要活动点、部门内以及部门之间的衔接，工作中的烦琐及反复的环节，成本高、效率低、时间长的环节以及任务转手次数较多的环节。Computer&Information181.业务流程分析的要点与产物 4关键的要点：一是理解流程的层次性；|三大层次三大层次：组织级，部门级：组织级，部门级，岗位级，岗位级二是了解流程的类型；|生产性流程，管理性流程，支持性流程生产性流程，管理性流程，支持性流程 三是掌握以业务事件识别、寻找流程的技巧。4流程分析产物，最常使用的模型有三种：跨职责流程图、活动图和数据流图。Computer&Information192.跨职责流程图应用基础与要点 4跨职责流程图是商业建模的标准工具，它定义了一套标准的建模元素和建模方法.4(1)跨职责流程图的主要元素流程名称 职责带区流程阶段流程元素 并行流程引用 Computer&Information202.跨职责流程图应用基础与要点4(2)绘制要点在进行业务流程分析时，关键的入手点是部门级的业务流程，也就是从业务事件出发，分析该业务事件会触发的一系列活动。要真正保障绘制出来的跨职责流程图是真实、有效的，就必须强化用户的参与。具体来说，我们应该先找到业务事件的负责人，然后通过设问的方式，让他描述响应该业务事件所进行的活动，说明活动的执行岗位以及它们之间的关系、数据传递。Computer&Information21跨职责流程图的绘制示例4 每年初将由航标站根据本年度的计划任务，并结合上一年度的情况制订新年度计划，形成向航标处业务部门提交的工作计划。4 航标处业务部门对其工作计划进行审核，同时上报处计划部门，计划部门对其进行反馈。航标处业务部门进行补充，形成“工作计划”上报处领导。由航标处领导对其进行审核与确认，并形成“工作任务”下发给养护中心。4 然后再由养护中心安排具体的采购计划。采购计划生成后报航标处领导审批后进行采购流程。Computer&Information22跨职责流程图的绘制示例Computer&Information233.活动图应用基础与要点 4(1)活动图概述活动图是一种表述过程机理、业务过程以及工作流的技术。它可以用来对业务过程、工作流建模，也可以对用例实现甚至是程序实现来建模。4(2)活动图的主要元素(最主要的几种建模元素)初始节点和活动终点 活动节点 转换 分支与监护条件 分岔与汇合 Computer&Information243.活动图应用基础与要点4(3)带泳道的活动图4(4)带对象流的活动图 4(5)复杂活动图辅助活动图 汇合描述 发送信号与接收信号引脚(pin)扩展区(Expansion Region)4(6)绘制活动图之后Computer&Information254.数据流图应用基础 4 数据流图(DFD)是一种历史悠久的建模方法，它对于数据流为主线索的处理过程是最合适的，例如计费系统。4(1)数据流图的主要元素数据加工数据加工(数据变换数据变换)数据源或数据潭数据源或数据潭(外部实体外部实体)数据流数据流数据存储文件数据存储文件或或或或Computer&Information264.数据流图应用基础4(2)分层的数据流图数据流图模型中引入了层次结构的数据流程图。它是按照系统的层次结构进行逐级分解的，以分层的数据流图来反映这种结构关系Computer&Information274以下是绘制数据流图的一些约定规则：过程通过数据存储区进行通信，而不是从一个过程直接流到另一个过程。使用数据流图时，不要试图让数据流图反映处理顺序。用简明的动词短语命名每一个过程：动词加对象。过程的编号要惟一且具有层次性。在单个图中绘制的过程不要超过810个，否则就很难绘制、更改和理解它。与圆圈相连的数据流不允许只有输入或只有输出。Computer&Information284.数据流图应用基础4(3)数据流图的绘制过程通过标识业务事件标识业务事件完成从顶层图到0层图的分解；再通过将业务事件分解业务事件分解成业务活动实现0层图到1层图的细化；然后就是通过将业务活动分解业务活动分解成业务步骤实现1层图到2层图的分解。Computer&Information294.数据流图应用基础4(3)数据流图的绘制过程 构建顶层图“课程注册系统”Computer&Information304.数据流图应用基础4(3)数据流图的绘制过程 根据业务事件绘制DFD片段Computer&Information31根据业务事件绘制DFD片段Computer&Information324.数据流图应用基础4(3)数据流图的绘制过程 将DFD片片段合并成DFD Computer&Information334.数据流图应用基础4(3)数据流图的绘制过程 逐步细化，分解到底Computer&Information34622 业务实体分析业务实体分析4在业务流程中，必须会涉及许多业务实体(或称为业务数据、业务术语)，要正确地构建出信息系统，就必须对这些业务实体建立正确的认识。4 具体来说，就是要了解这个问题域中有哪些业务实体，它们之间存在什么样的逻辑关系、数量关系，以及有什么相应的结构规则。实际上这样的工作就是大名鼎鼎的“领域建模”、“概念建模”。Computer&Information35 1业务实体分析任务概述 4在领域建模的过程中，应该更多地采用“自底向上”的方法；4针对每一个业务事件、每一类报表创建局部的领域类图片段，然后当完成这些建模工作之后，再对其进行抽象、提炼，形成全局的领域模型。4针对每一个业务事件、每一类报表进行领域类图片段的绘制时，其主要的步骤包括三个：识别出业务实体，确定实体之间的关系(语义关系和数量关系)，定义实体的关键属性。Computer&Information36 1业务实体分析任务概述 4业务实体分析的产物有两种可选的模型：类图 E/R模型也叫实体关系图 Computer&Information372.类图应用基础及要点Computer&Information38（1）领域建模方法示例4领域建模时，其工作主要就是标识类明确类之间的逻辑关系和数量关系添加重要的结构规则 三个方面。Computer&Information39参考案例：参考案例：个人图书管理系统需求概个人图书管理系统需求概述述4小王是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版杜等关键字的组合查询功能。4 在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。4 还希望能够对书籍的购买金额、册数按特定时间周期进行统计。Computer&Information40 标识类 4 发现类的方法有很多种：脑力风暴：所谓脑力风暴是指我们看到需求或模型后，感觉到系统中应该存在哪些分析类。词性分析法：所谓词性分析法，是指我们根据需求描述或模型中的词汇进行分析，在分析过程中，按词性进行类、属性、方法的划分。(领域模型)CRC分析法（候选类、职责、协作分析法）：CRC分析法也是一个简单易行的分析方法。通过对那些可能的类进行职责与协作的分析，进一步确认系统中的分析类及其属性、方法。CRC分析法要求我们对每一个候选类做一个卡片，在卡片上对这个类进行描述，在描述的下面写上这个类的职责，在背面写出与这个类有协作关系的其它类及协作关系。(领域模型)根据边界类、控制类、实体类帮助分析系统中的类(分析模型)4其中最广泛应用的莫过于“名词动词法”，Computer&Information41 标识类 4 问题域建模的第一步-标识类 名词动词法，其主要规则是从名词与名词短语中提取对象与属性；从动词与动词短语中提取操作与关联；而所有格短语通常表明名词应该是属性而不是对象。Computer&Information42找到备选类：4小王是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版杜等关键字的组合查询功能。4 在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。4 还希望能够对书籍的购买金额、册数按特定时间周期进行统计。Computer&Information43决定候选类 4类剔除原则：无关紧要的类系统外的类表述的概念相对较小，适合于某个候选类的属性非问题域本质类Computer&Information44“小王”、“人”、“家里”系统外的概念，无须对其建模；“个人图书管理系统”、“系统”指的就是将要开发的系统，即系统本身，也无须对其进行建模；“书籍”是一个很重要的类，而“书名”、“作者”、“类别”、“出版社”、“书号”则都是用末描述书籍的基本信息的，因此应该作为“书籍”类的属性处理。而“规则”是指书号的生成规则，书号则是书籍的一个属性，因此“规则”可以作为编写“书籍”类构造函数的指南；“基本信息”则是书名、作者、类别等描述书籍的基本信息统称，“关键字”则是代表其中 之一，因此无须对其建模；“功能”、“新书籍”、“信息”、“记录”都是在描述需求时使用到的一些相关词语，并不是问题域的本质，因此先可以将其淘汰；“计算机类”、“非计算机类”是该系统中图书的两大分类，因此应该对其建模，并改名为 “计算机类书籍”和“非计算机类书籍”，以减少歧义；Computer&Information45“外借情况”则是用来表示一次借阅行为，应该成为一个候选类，多个外借情况将组成“外 借情况列表”，而外借情况中一个很重要的角色是“朋友”借阅主体。虽然本系统中并不需要建立“朋友”的资料库，但考虑到可能会需要列出某个朋友的借阅情况，因此还是将其列为候选类。为了能够更好地表述，将“外借情况”改名为“借阅记录”，而将“外借情况列表”改名为“借阅记录列表”；“购买金额”、“册数”都是统计的结果，都是一个数字，因此不用将其建模，而“特定时 限”则是统计的范围，也无须将其建模。不过从这里的分析中，我们可以发现，在该需求 描述中隐藏着一个名为“书籍列表”的关键类，它也就是执行统计的主体 Computer&Information464 通过以上的分析，我们就可以得到一个候选类列表：4 书籍 计算机类书籍 非计算机类书籍 借阅记录 借阅记录列表 书籍列表 Computer&Information47 明确类间关系之确定关联关系4 确定关联关系“计算机类书籍”、“非计算机类书籍”与“书籍”之间是继承关系 “书籍列表”则是由多个“书籍”组成的，“借阅记录列表”是由多条“借阅记录”组成的，这种组成关系适用于组合还是聚合关系?-聚合更合适“借阅记录”与“书籍”关联关系 初始类模型Computer&Information48明确类间关系之多重性分析 加入多重性信息Computer&Information49确定类的主要职责4类的职责：类所维护的知识-类的成员变量(即属性)类能够执行的行为-成员方法（属于行为需求领域，体现在用例模型中）加入类的属性Computer&Information50 补充类之间的结构规则 类图中的诸如导航性、角色名、导出属性、限定符及约束等修饰属性4导航性分析“书籍”与“借阅记录”之间存在关联关系。它们之间是一种双向关联 4约束“书籍”对象创建后就不能够被删除，只能被修改，因此在Book类边上加上了一条用自由文本写的约束；显然一本书要么属于计算机类，要么属于非计算机类，因此在两个“泛化”关系上增 加一个“二者取之一”的约束。Computer&Information51（2）领域建模的常见误区4ICONIK方法的创始人曾经对领域建模工作总结了10大误区一些解释:立即给关联指定多重性，确保每个关联都有明确的数量关系 对名词和动词做过度的分析，而背离初衷-“分析崩溃”不对用例和时序图进行研究，就将操作分配给类对象和类的通用程度越高，在其他项目中重用它们的可能性就越大。【案例：模块管理、导入；报表管理、导入】Computer&Information52（2）领域建模的常见误区对于每个“整体部分”关系，就使用聚合还是组合表示而争论不休 未对问题空间进行建模之前，就假定一种具体的实现策略将类命名为难以理解的名称，而不是直观的名称直接进入到实现结构，如友元关系和参数化类领域类和关系型数据库表之间建立一对一的映射过早地执行“模式化”Computer&Information532.类图应用基础及要点4(3)类模型的演化类模型的演化类类模模型型是是从从需需求求分分析析、设设计计阶阶段段不不断断演演化化而而成成的的，其过程如图其过程如图656所示。所示。Computer&Information54方法4：分析模型中有3种十分有用的构造型：实体类、控制类和边界类实体类：实体对象的抽象，通常来自域模型也就是现实世界，用来描述具体的实体，通常映射到数据库表格与文件中。控制类：控制对象的抽象，主要用来体现应用程序的执行逻辑，将其抽象出来，可以使得变化不影响用户界面和数据库中的表。边界类：边界对象的抽象，通常是用来完成参与者(用户、外部系统)与系统之间交互的 对象，例如From、对话框、菜单、接口等。4分析模型通常是在用例模型和领域模型的基础上进行综合分析而得的。从领域模型中将得到实体类，而边界类主要负责处理与用户的交互，控制类则负责完成实际的程序逻辑。Computer&Information55实体类、控制类和边界类4转 pdfComputer&Information56 3E/R图应用基础图应用基础 4描述业务实体之间的关系除了可以使用类图之外，也可以使用传统的E/R模型。4优势：能够更好地与后续的数据库设计结合。4缺点：语义相对于类图来说更弱一些，同时对面向对象开发的指导作用相对差一些。Computer&Information573E/R图应用基础图应用基础4(1)数据建模过程 Computer&Information611.用例分析概述4用例图是用例分析的全部内容？错！4用例分析 包括：用例图和用例描述。用例图是目录，用例描述是封装所有需求的形式。用例分析的组成Computer&Information626.2.3 角色与使用场景分析角色与使用场景分析42参与者与用例(1)参与者:参与者是在系统之外，透过系统边界与系统进行有意义交互的任何事物。Computer&Information63(2)用例4根据RUP的定义：用例实例(场景)是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。用例场景是有步骤的(执行了一系列动作)：也就是说，它是一个由一系列业务步骤组成的业务活动。用例场景是有目标的(可见的价值结果)：也就是说，它能够为参与者带来有意义的结果，例如“填写搜索条件”显然就是对参与者而言没有意义的，就不是一个合适的用例。例是对一组用例实例(场景)的抽象，也就是说，用例是有路径(基本事件流、扩展事件流、子事件流等)的。例如我们在从M上取款时，可能会遇到很多不同的场景：正常取到钱、卡里钱不够、密码忘了、机器里没有足够的钱、卡被吞了等；而这些都可以概括为一个名为“取款”的用例。Computer&Information64(2)用例4从某种意义上说，用例和具体场景(用例实例)之间的关系和类与对象之间的关系是类似的。4一个场景是一个具体的行为，一个用例是对一类相关行为的抽象。Computer&Information653用例图 4用例图的构成，以及用例与用例之间的关系、参与者与用例之间的关系、参与者与参与者的关系 Computer&Information663用例图4(1)系统边界4(2)参与者与用例的关系 一个参与者表示用例的使用者在与这些用例进行交互时所扮演的角色。4(3)用例之间的关系 包含、扩展和泛化 4(4)参与者之间的关系 参与者之间的关系只有一种，那就是泛化。Computer&Information67用例之间的关系4 包含关系在UML中，包含关系用构造型include表示(箭头方向是从基用例到被包含用例)，它是指基用例(base use case)在它内部说明的某一个位置上显式地合并了另一个用例的行为。4 扩展关系 在UML中，扩展关系用构造型extend表示(注意箭头方向是从扩展用例到基用例)，它表示基用例在由扩展用例间接说明的一个位置上，隐式地合并了另一个用例的行为。Computer&Information684 泛化关系 而用例之间的泛化则表示子用例继承了父用例的行为和含义；子用例还可以增加或覆盖父用例的行为；子用例可以出现在父用例出现的任何位置。Computer&Information69Computer&Information70(4)参与者之间的关系 4参与者之间的关系只有一种，那就是泛化。Computer&Information71小结Computer&Information72 4用例的来源4自顶向下导出法 4自底向上合并法 Computer&Information734用例的来源-(1)自顶向下导出法 4自顶向下导出法就是从流程图流程图(流程图是通过将系统分解成主题域，再从主题域中标识出业务事件，然后为业务事件绘制出流程图)中派生出用例图。有了针对各个业务事件处理过程的流程图，我们就可以从中导出相应的用例。4岗位信息-参与者的候选者 4业务活动-用例的候选者 Computer&Information744用例的来源-(1)自顶向下导出法4针对每张流程图进行分析之后，就可以得到一组用例图片段，然后将它们叠加在一起，就可以抽象出系统的用例模型。4如图681所示的是某税务效能管理系统中针对“业务申请”流程所绘制的一张跨职责流程图，下面就以它为例，说明如何从流程图中派生出用例图。Computer&Information75Computer&Information764利用流程图，“边界确定”、“角色确定”，以得出表示系统边界的用例图。边界确定(去除非End User的职责带区)|首先要排除掉不直接使用系统的岗位，因为它们不是首先要排除掉不直接使用系统的岗位，因为它们不是系统要涉及的范畴。系统要涉及的范畴。确定角色(对剩下的职责带区进行角色化)|对于职责带区对于职责带区“涉税窗口涉税窗口”。|对于职责带区对于职责带区“局内业务科室局内业务科室”。确定用例|用例则是从职责带区中的业务活动派生出来的。分析用例则是从职责带区中的业务活动派生出来的。分析过程见表过程见表6-9，6-10Computer&Information774对于活动，主要是判断它是否属于系统范畴之内；4对于判断，则要分析它是属于某个活动还是一个独立的活动。Computer&Information784用例的来源-(1)自顶向下导出法 绘制用例图 Computer&Information794用例的来源-(2)自底向上的合并法4步骤收集原始需求|当我们获得这样的原始需求列表之后，就可以开始通当我们获得这样的原始需求列表之后，就可以开始通过合并的方法来导出用例。当然，我们首先需要确定过合并的方法来导出用例。当然，我们首先需要确定有有哪些参与者哪些参与者。确定参与者|开发人员：对任务进行操作和时间记录；开发人员：对任务进行操作和时间记录；|项目经理：对项目的任务进行分配，了解项目内产项目经理：对项目的任务进行分配，了解项目内产能；能；|研发经理、管理层：确定项目及进行产能统计工作。研发经理、管理层：确定项目及进行产能统计工作。Computer&Information804用例的来源-(2)自底向上的合并法合并用例|将将“原始需求原始需求”按参与者分组，然后再合并或分解为按参与者分组，然后再合并或分解为相应的用例相应的用例。|绘制用例图绘制用例图 4 Computer&Information81Computer&Information82Computer&Information83Computer&Information84 5用例分析技术应用要点用例分析技术应用要点4(1)用例真的有粒度吗 业务价值判断是关键|被包含用例、扩展用例被包含用例、扩展用例|技术性用例的引入技术性用例的引入 “用例粒度与系统复 杂度相关”的观点是错误的|影响用例大小的是业务流程，是工作任务的分工影响用例大小的是业务流程，是工作任务的分工 CRUD的价值被过于放大了|CRUD是指在做计算处理时的增加是指在做计算处理时的增加(Create)、查询、查询(Retrieve)（重新得到数据）、更新（重新得到数据）、更新(Update)和删除和删除(Delete)用例合并成用例合并成“管理管理*”CRUD原则原则对于“系统创造的东西”才适用，例如管理系统用户、管理数据字典、管理权限、管理购物车之类的东西就适用于该原则。Computer&Information855用例分析技术应用要点用例分析技术应用要点4(2)用业务动词命名用例十分重要 某开发团队在开发银行信用卡管理系统时，整理了一些用例，其中包括：创建客户、更新客户、删除客户。Computer&Information865用例分析技术应用要点用例分析技术应用要点4(3)采用先事后人的方式分析是要点应该将人(角色、参与者)和事(场景、用例)分开考虑；在确定它们之间关联关联时，要先事后人地思考。在确定了参与者之后，再抽取出“事”(也就是用例)，然后完成它们之间的连接，就可以很轻松地获得更合理的结果了。Computer&Information87案例4在开发一套医院管理系统时，分析人员了解到如下所示的需求：在药房中，有3个主参与者：接待员、药房技师和药剂师。其中任何一个参与者都可能接待客户，接收处方。药房技师和药剂师都可以按照处方抓药，但只有药剂师有权审核处方并在处方中签字，而药房技师是协助药剂师的。找出参与者：接待员、药房技师和药剂师抽取出“事”（用例）：收处方、配药、审核(业务活动)找出关系：Computer&Information88Computer&Information8962.4 周期一的产物周期一的产物4体检医院管理系统“客服管理子系统”、“体检业务子系统”和“物资管理子系统”三个主题域。以以“体检业务子系统体检业务子系统 ”为例为例。41工作任务说明 在需求分析的第一阶段，核心任务就是结合业务流程、报表的需求，梳理出结构框架(领域模型)和行为脉络(流程图-用例模型)，为第二阶段的需求分析工作建立基础；指出方向。而具体来说，就是从上一阶段标识出来的业务事件(业务流程的起点)和报表列表开始，展开对中层管理人员的访谈与调研，而范围就是“体检业务子系统”所对应的服务中心、体检科室和综合科三个部门。然后再根据访谈的结果完成事、物、人的分析，最后在此基础上抽象出该主题域的领域模型和用例模型。Computer&Information904 2业务事件分析标识出了体检者申请体检、体检者中途改单、财务部门提交团队缴费情况、客服中心查询体检情况、维护人员管理体检项和系统通知用户取报告6个业务事件 以“体检者申请体检体检者申请体检”业务事件为例 进行 业务业务流程分析流程分析、业务实体分析业务实体分析、角色角色使用场景分析使用场景分析 Computer&Information91体检者申请体检-业务流程访谈过程中，用户代表描述的信息：4当体检者要体检时，首先将到服务中心办理。如果已经预约，则告诉服务人员其预约号或姓名；如果没有预约则填写体检申请表，选择体检项目或体检套餐(可以自由组合体检项目和体检套餐)。服务人员将根据预约单或体检申请表的内容生成系统中的体检单，并打印出来。4体检者拿着体检单到收费窗口交费，收费人员根据体检单中的体检项或体检套餐对应的费用项计算总费用，生成相应的账单，收完费用后在体检单上盖上“收费已迄”的图章；如果公司已经付过相应费用，则直接盖上“收费已迄”图章。4体检者拿着体检单到各体检科室进行体检，体检医生体检完后在体检单上注明已体检，并在体检完成后将该体检项的体检结果记录在电脑中。4当所有的体检项都体检完之后，综合科医生将根据体检结果填写体检报告。4当体检报告生成完毕后，服务人员就可以将其返还给客户。客户可以自行领取，可由公司代表统一领取，也可以由客服中心人员代为领取。Computer&Information92(1)体检者申请体检|业务流程分析业务流程分析 Computer&Information93|业务实体分析业务实体分析 业务实体分析的关键是理清问题域中的关键术语之间业务实体分析的关键是理清问题域中的关键术语之间的关系，的关系，找出候选类，及其关系，绘制类图找出候选类，及其关系，绘制类图Computer&Information94|角色角色使用场景分析使用场景分析。最后我们还将研究项目的边界，完成流程图到用例图最后我们还将研究项目的边界，完成流程图到用例图的转换，完成系统的角色和使用场景分析。的转换，完成系统的角色和使用场景分析。Computer&Information95将本业务流程所涉及的所有业务活动以如图6-91所示的用例图表示出来 Computer&Information964 3报表分析 对于报表而言，分析工作可以分成why(目标)、what(内容)与How(展现形式)三个层次 4以“体检业务周期统计报表”为例(1)why:对于报表而言，Why要解决的问题包括：部门职位、目的、相关场景与查询频率等方面的内容。Computer&Information97(2)what(内容):|对于每一类报表，我们还需要确定与它相关的业务实对于每一类报表，我们还需要确定与它相关的业务实体体(用类图来表示用类图来表示)、主要的数据项、数据项的计算方、主要的数据项、数据项的计算方法，同时还要确定有多少具体的报表。法，同时还要确定有多少具体的报表。|相关业务实体分析相关业务实体分析|报表项分析报表项分析|数据项及计算方法分析数据项及计算方法分析Computer&Information98 4抽象与整理 4(1)抽象用例模型4(2)抽象类模型5填充需求规格说明 通过以上分析，就可以完成结构框架和行为脉络的填充，同时将其填充到软件需求规格说明书中。(1)Word文档组织示例 (2)Rose组织示例Computer&Information99第6章 需求分析与建模最佳实践46.1 需求分析与建模的要点与误区分析46.2 周期一:理清框架与脉络46.3 周期二：确定需求细节46.4 其他需求分析You are here!你在这儿！你在这儿！Computer&Information1006.3 周期二：确定需求细节46.3.1 确定行为需求的细节46.3.2 确定结构需求的细节46.3.3 周期二的产物Computer&Information1014这个阶段的任务阶段的任务是对用例模型、领域模型标识出用例、领域类的细节进行填充。4对于组织行为需求的用例需求的用例，我们要填充用例的事件流、相关需求与功能点、界面原型，以及特定于该用例的规则与约束；4对于组织数据(结构)需求的领域类领域类，我们要填充它的字段与格式，具体包括：字段属性信息：也就是每个领域类所包含的成员属性，细化其构成；字段格式与规则：也就是每个字段详细的格式(诸如字符型、日期型等类型，以及长度可选值等内容)、组成规则(诸如由多少个字符、多少个数字组成等)；计算规则：对于一些非直接输入的派生属性，通过数据表达式的方式来描述；结构规则：对于数据的组成、格式进行描述。Computer&Information1026.3.1 确定行为需求的细节41用例的灵活应用42用例描述模板43事件流分析 44相关需求整理45界面原型46规则与约束Computer&Information1036.3.1 确定行为需求的细节确定行为需求的细节41用例的灵活应用 根据行为需求的特点，可以将其分成“业务业务功能、报表功能、接口、技术支撑功能、报表功能、接口、技术支撑”4种类型。统一封装成用例，但在具体细节描述方面，可以对其进行灵活处理，具体的方法如表617所示 Computer&Information1046.3.1 确定行为需求的细节确定行为需求的细节42用例描述模板而针对业务功能类的用例来说，其需要整理的内容主要包括事件流、相关需求与功能点、界面原事件流、相关需求与功能点、界面原型、规则与约束型、规则与约束4个方面，描述的方法可以采用通用的用例描述模板来组织。相关的用例描述模板有不少，最常用的包括RUP所提供的经典模型和编写有效用例作者所提供的模板。Computer&Information105Computer&Information1066.3.1 确定行为需求的细节确定行为需求的细节4 3事件流分析 一个用例通常是一组事件流所构成的。整个事件流模型包括：前、后置条件前、后置条件、基本事件流基本事件流和扩展事件扩展事件流流。(1)前、后置条件|所谓前置条件所谓前置条件是指在用例启动时，参与者是指在用例启动时，参与者(Actor)与与系统应置于什么状态。这个状态应该是系统能够检测系统应置于什么状态。这个状态应该是系统能够检测到的，在用例启动前能够检测到的，而且还应该是有到的，在用例启动前能够检测到的，而且还应该是有意义的。意义的。|所谓后置条件所谓后置条件是指在用例结束时，系统应置于什么状是指在用例结束时，系统应置于什么状态态，这个状态应该是系统能够检测到的，在用例结束，这个状态应该是系统能够检测到的，在用例结束前能够检测到的，而且也应该是有意义的。前能够检测到的，