一、需求分析与建模的要点与误区
需求分析到底做什么
需求分析的任务并不是分析系统如何实现用户的需要，这是对需求分析最常见的误解。需求分析实际上是业务分析，也就是选择一种业务导向的线索将零散的需求串起米，形成一个体系完整、内容清晰的框架，以指导后续的设计、开发工作。需求分析就是先分解，再提炼，在这个过程中消除矛盾。
①分解
分解是人类控制复杂性，认知复杂事物的最佳实践，不管是采用结构化分析方法还是面向对象分析方法，分解是必然的手段。现代需求工程理论更建议采用业务导向的分解，而非传统的系统导向的分解。
就是按“事”的角度进行分解。它对于联机事务处理系统、管理信息系统而言都是非常适用的方法。目标系统->主题域的分解依据的是“目标决定范围”，从主题域->业务事件、报表类型所做的是理清脉络，从业务事件->业务活动、报表类型->报表所做的是填充细节。
这种分解结构在需求分析过程中最常用的，但它过早进入了程序结构，割裂了与问题域之间的联系，容易导致对问题域研究的不足，降低了需求的质量。这种方法适用于问题域不复杂，或者系统与问题域关联性不强的情况下，例如工具软件、面向设备的嵌入式系统等。
②提炼
分解会破坏其他线索的完整性。如果以“事”为线索，会发现数据需求分解后就会出现相互交叠的情况，也就是在多个业务事件中都涉及相同的类。因此，需要采用自底向上的方法进行提炼。如将每个业务事件中的类进行提炼，抽取出共性的部分，建立针对整个系统的全局领域模型。
注：领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。
③消除矛盾
在这样的分析过程中，会发现有些需求是相互矛盾、相互冲突的。由于是把收集的信息放在一个预先定义的结构中发现这些矛盾的，因此对矛盾的影响范围会有直观的了解，也知道它影响到哪些层面。这样，就可以很快地找到相应的人员，通过进一步的需求捕获来消除矛盾。
建模的目标与要点
①建模的目的
模型有效地帮助人们更好地认识、应用、设计复杂事物。建模是需求分析的主要手段，它通过简化、强调来帮助需求分析人员理清思路，达成共识。因此，需求建模的过程远比建模的结果更重要。主要目的是提供一种详细说明系统结构或行为的方法。
注：原先，由于计算机应用还不普及，软件系统的规模和复杂度都相对较小，应用“数据结构+算法=程序”的模式就可以解决大部分问题。随着计算机应用的不断普及，业务模式、数据量都在迅速变化之中，软件涉及的问题也越来越广，早已经超出人们可以处理的复杂度。
②正确认识建模方法论
结构化分析与设计方法和结构化分解是两个概念，不过结构化分析与设计方法充分应用了结构化分解的理念。结构化分解实际上是人类认识复杂事物的最佳实践，在很多领域都有应用，如生物分类、项目管理中的工作任务分解结构、公司管理（组织结构分解）等。
③正确认识UML
UML是一种统一的、标准化的建模语言，不是方法论。它能为参与软件设计和开发的人提供一种公共“语言”，使他们能够基于共同的“模型”来理解业务、需求，理解软件和架构如何构造。
UML的各种图见下表:
在需求阶段使用的UML图：
下面正式进入需求分析与建模部分。
二、周期一：理清框架与脉络
本阶段的任务是理清需求的结构框架（领域类图）和行为脉络（流程图和用例图），该工作的输入是需求定义阶段产生的业务事件列表和报表列表，输出的是领域模型和用例模型。该阶段的结束标志是标识出了绝大部分的用例，生成了领域模型。
1、业务流程分析
针对每一个业务事件，分析并识别现有业务活动，确定业务活动之间的关系；了解这些业务活动需要接收哪些信息，将产生哪些信息，确定信息传送的路线；同时标识出业务活动的部门、岗位等信息。
业务流程分析的三个关键点：一是理解流程的层次性；二是了解流程的类型；三是掌握业务事件识别、寻找流程的技巧。
流程是有层次的：
流程有组织级、部门级、岗位级三个层次，其中部门级是需求分析的主线索，岗位级是需求细节填充时的工作内容，组织级是对部门级流程的抽象概括。
流程是有类型的：
注：拿软件开发过程来说，需求分析、软件设计、软件编码、软件测试都是生产性流程；项目管理、质量保证就属于管理性流程了；支持性流程包括配置、文档控制等。
流程分析的产物：
在软件开发过程中，最常使用的模型有三种：跨职责流程图、活动图和数据流图。
①跨职责流程图
跨职责流程图主要由流程名称、职责带区、流程阶段、业务活动、判断/审批等组成。
下面是一个示例：
跨职责流程图完成的标准：一是所有的职责带区上的命名都将细化到具体的岗位；二是每类活动之间的关系已经没有疑问。还有一点是需要特别注意的是不应该对业务活动进行细化。
②活动图
下图是一个常见的活动图：
带泳道的活动图：
每个活动节点、分支是必须只属于一个泳道，而转换、分岔与汇合是可以跨泳道的。通过泳道，我们不仅体现了整个活动控制流，还体现出了每个活动的实施者。
带对象流的活动图：
通过带对象流的活动图表示数据、文档的流转，可以修改对象的状态，还可以显示对象的角色、状态和属性值的变化。
复杂的活动图—辅助活动图：
如果一个活动图过于复杂，或者活动图中某一组活动与主控制流关联不大，那么就可以借助辅助活动图来描述它。
复杂的活动图—汇合描述：
在默认情况下，当汇合的所有入流均到汇合点时，就将执行汇合点指向的活动节点。但是有些时候，你希望对其做一些约束，这时就可以借助汇合描述来完成。
汇合描述实际上是一个约束，其格式就是“{约束条件}”。可以在汇合点加上“{Order.State=Payed}”来说明，只有当订单状态为已付款时才执行下一个活动节点“供应商送货”。这样就可以更加清晰地描述出，只有客户付了钱之后，才执行订单的送货操作。
复杂的活动图 —发送与接收信号：
如果需要表示出异步事件，这在活动中可以通过信号机制来表示。
复杂的活动图 —引脚（pin)：
就像类中的方法可以包含不同的参数一样，一个活动节点也可能有相应的参数。如果打算标明每个活动节点所需的数据以及它将产生的数据时，引脚是一个很好的手段。
上图表示活动“计算利息”将接受三个参数：本金（principal)、利率 (rate)和年限（year)；如果传入的参数合法，将输出利息值（accrual)；如果传入的参数错误，则产生异常。该活动节点没有与其他节点相连，需在小矩形中添加箭头符号，以区别输入参数和输出参数。除用名字表示顺序之外，还可以在引脚边上标注表示顺序的数字。如果引脚产生异常对象，则可以在符号边上标注一个空心三角形。
就是当流程图绘制完之后，应该尽可能对其进行一些分析，包括瓶颈分析和利益分析，以此减少变更的影响，看下面的案例：
该流程是一种典型的赊销模式，收款和送货并行进行，必然会对财务部门的收款工作产生障碍。当然，这种模式对于销售部门而言是十分有利的，因此在公司初创时期，很多公司就会釆用这样的模式，毕竟这个时期总经理最关注的就是销售额。
而当销售量上升的同时，应收账款也不断上升时，这种问题就会暴露出来。特别是公司逐渐成长起来，销售额达到一定量的时候，总经理就会更关注资金安全问题。既然问题是收款和送货两个活动并行执行导致的，那么只要将这种并行模式转成串行模式就能解决问题了，也就是先收款后送货。
也许执行这种流程后，销售竞争力大幅下降，总经理又会认为主要矛盾在销售了，不就又有将流程改回去的冲动了吗？因此，可采用一种更合理的折中方案，引入“信用额度”控制，对于赊销顾客，根据历史交易情况设置一个信用额度，欠款在额度之内可继续赊销，否则先付款后发货。
③数据流图
数据流图的元素包括过程/加工、数据存储/文件、外部实体、数据流、实时连接等。
数据流图一般是分层绘制的：
第一步：构建顶层图
这个课程注册系统的流程是：教务处提供有关课程信息，学生获得课程安排后，进行申请注册，教师在注册完成后得到班级列表。
第二步：根据业务事件绘制DFD片段
第三步：将DFD片段合并成DFD
第四步：逐步细化，分解到底
2、业务实体分析
业务实体分析就是了解问题域中有哪些业务实体，它们之间存在什么样的逻辑关系、数量关系，以及有什么相应的结构规则。这样的工作就是“领域建模”、“概念建模”。领域建模采用“自底向上”方法，针对每一个业务事件、每一类报表创建局部的领域类图片段，完成这些建模后，再对其进行抽象、提炼，形成全局的领域模型。
主要步骤是识别出业务实体-> 确定实体之间的关系->定义实体的关键属性。类图 + E/R图(实体关系图)都可用于业务实体分析。
类图应用基础与要点：
要正确地理解类，就必须对面向对象的思想建立正确的认识：
住在厦门的张三，要给住在绍兴的李四送一个生日蛋糕。张三登录到一个电子商务网站购买一个蛋糕，并通过该网站将其送给李四。电子商务网站实际上是通过绍兴的蛋糕店来完成这个任务的。在整个传递过程中，各个实体之间的关联关系如上图。
实际情况要复杂得多，电子商务网站可以接受很多人的订单，也可以与不同地方的蛋糕店建立合作，以送给更多不同地方的人，因此可以对其进行抽象。
张三就是一个对象，它可以归到“订货人”这个类中；而绍兴蛋糕店也显然是一个对象，它可以归到“商户”这个类中。
从中得出以下定义：每个对象都扮演了一个角色，并为其他成员提供特定的服务或执行特定的行为。
①类的表示法
类是对一组具有相同属性、操作、关系和语义的对象的描述。关系是类之间的、语义是蕴藏的，对于一个类而言，其关键的特性是属性（成员变量）和操作（成员方法）。类用一个矩形表示的，包含三个分栏，每个分栏分别写入类的名称、类的属性和类的操作。
注：在需求建模时，应该用中文命名类和类的属性。
②类之间关系
类之间通常有关联关系、泛化关系、聚合与组合关系，见下图：
④类图的主要元素
在阅读这种简单的类图时，重要在于把握三项内容：类、关系、多重性（这也就是类图中那个重要的20%)。其阅读的顺序应遵从以下原则：先看清有哪些类，然后看看类之间存在的关系，并结合多重性来理解类图的结构特点，以及各个属性和方法的含义。
第一步：找到类
上图中共有7个类：订单、订单项、客户、收货人、送货单、供应商、产品，并且在每一个类中都定义了若干属性。
第二步：找到类之间的关系
先从关系最复杂的类开始阅读。这个类是“订单”。然后，“订单项”和“订单”之间是组合关系，根据箭头方向可知“订单”是由“订单项”组成的；“订单”和“客户”、“收货人”、“送货单”之间是关联关系。也就是说，一个订单和客户、收货人、送货单是相关的；第二个类是“送货单”，和它相关的有4个类：“订单”、“订单项”、“收货人”、“供应商”。表示“送货单”是与“订单”相关的，同时还关联到“订单项” ；另外它和“供应商”、“收货人”之间的关联关系是很显然的。
第三步：理解数量关系
数量关系在类图中是以多重性（Multiplicity)的形式表示的，它又称重数。其表示格式为“n..m”其中整数n定义所连接的最少对象的数目，而m则为最多对象数(不知道确切的最大数时，最大数用*号表示，在Rose中则用n来表示)。
类图的辅助建模元素见下图：
⑤关联类
除了上述的建模元素之外，在类建模中还会用到一个很重要的概念，那就是关联类。具体来说，如果两个类之间具有多对多关系时，就会发现有些属性是不容易放到任何一个类中的。如果要记录每“人”在某个“协会”中所担任的职务，该存在哪呢？这种属性是属于“人”还是“协会”呢？显然都不合适。这个信息是属于关联本身的特性，因此可以通过关联类来建模。
⑥类模型的演化
对于类模型，许多需求分析人员会担心：非技术背景的用户真的能够理解“类”这种抽象的概念吗？它真的是应该在需求阶段来完成的吗？它毕竟看起来是一个源于软件开发领域的概念。
正如MVC架构模式对类的分类：除了源于问题域的模型（Model)类之外，还有许多是和设计、编码相关的计算机域的用户界面（View，视图）和控制逻辑（Control ，控制器）相关的类。因此类模型是从需求分析、设计阶段不断演化而成的。
注：其实“类”就是“类型”、“一类事物”的概念，例如一张桌子是一个对象，桌子就是一个类；一张订单是一个对象，订单就是一个类。只要从这个角度进行说明，用户往往能够马上建立正确的认识。
⑦总结
领域模型是以面向对象的视角看待现实世界的结果，通过类图来描述现实世界中各种事物之间的关系。在构建模型时，最主要的工作是找出相关类，然后命名类之间的关联关系，必要时加入一些多重性描述和业务规则约束。
分析模型和领域模型是很相近的，领域模型是一种全局的业务分析模型。在RUP中，分析模型主要是针对软件系统的分析，领域模型则更多是偏重对业务领域的分析。分析模型中有3种十分有用的构造型：实体类、控制类和边界类。
实体类：实体对象的抽象，通常来自域模型也就是现实世界，用来描述具体的实体，通常映射到数据库表格与文件中。
控制类：控制对象的抽象，主要用来体现应用程序的执行逻辑，将其抽象出来，可以使得变化不影响用户界面和数据库中的表。
边界类：边界对象的抽象，通常是用来完成参与者（用户、外部系统）与系统之间交互的对象，例如From、对话框、菜单、接口等。
边界类：CommandWindow 负责接收用户输入的命令，以及向用户显示命令结果
控制类：LightlnductorControl 负责与“航标灯器”感应器通信，获取灯器当前数据
控制类：RadarResponderInductorControl负责与“雷达应答器”感应器通信，获取雷达当前数据
控制类：GPSDeviceControl 负责与“GPS定位设备”感应器通信，获取当前位置
实体类：LightState(航标灯）负责存储航标灯器状态数据
实体类：RadarResponderState(雷达应答器）负责存储雷达应答器状态数据
实体类：GPSState(GPS设备）负责GPS定位数据
设计模型是在分析模型的基础上添加设计元素的结果。与分析模型相比，设计模型中类的属性集更趋完善；它将加入模板类、参数类、抽象类/接口等设计元素，以及框架类的使用、设计模式的使用等。设计模型是一种详细设计模型，将能够直接对编程予以指导。
可以将不同的Control抽象成一个工厂类，这样就可以根据用户输入的命令来创建相应的Control，这样也达到了良好扩展性的目的。其次，选择JDBC来实现命令执行结果的存储。设计模型与选择什么语言开发是有很大关系。
E/R图应用基础：
①数据建模过程
描述业务实体之间的关系还可以用传统的E/R模型。它的优势在于能够更好地与后续的数据库设计结合，缺点在于语义相对于类图来说更弱一些，同时对面向对象开发的指导作用相对差一些。
概念模型VS逻辑模型：
概念模型和逻辑模型实际上是对“需求视图”与“开发视图”的区分。换句话说，概念模型是需求人员的视图，等价于领域模型；逻辑模型是开发人员（包括设计人员）的视图，它约等于面向对象分析与设计方法中提到的“分析模型”。
例如，在某电子商务网站系统的需求调研阶段，通过与客户的沟通完成如下图所示的领域模型片段。
逻辑模型VS物理模型：
是对“开发视图”与“数据库视图”的区分，换句话说，物理模型就是DBA的视图。在许多团队中逻辑模型和物理模型几乎是一致的，如果说有区别的话，那就是中英文版本而已。物理模型会考虑到性能、效率等多方面的因素。
②E/R模型的主要元素
E/R模型与关系型数据库关系紧密，因此在数据库设计阶段它的优势很明显，相关的工具也可以实现E/R与关系型数据库的正向、逆向工程，即基于E/R图创建数据库，以及基于数据库创建E/R图。
3、角色与使用场景分析
①用例分析技术概述
用例分析技术的关键是“发现使用系统的角色（参与者），了解并梳理这些角色将如何使用系统（场景）”，从而更好地完成“人”的视角的需求梳理。
用户包括两个有机的组织部分：用例图是目录，用例描述是封装所有需求的形式。
②参与者与用例
参与者是在系统之外，透过系统边界与系统进行有意义交互的任何事物。判断的要点在于他们是不是系统行为的触发者。
边界是一个逻辑的概念，是一种职责边界而非物理边界。简单来说，它就是指“待开发系统”；如果将整个待开发系统分成不同的部分，在对每个部分创建用例模型时，也可以将这个独立的部分视为一个系统的边界。
参与者不仅可以由人承担，还可以是其他系统、硬件设备，甚至是时钟。
注：MartinFowler认为，参与者更适合的术语是Role(角色），而Actor是源于对瑞典语（Iva是瑞典人）的误译。
一般，对于由人扮演的参与者，偏向采用下图左边的形象符号；对于系统扮演的参与者，则会倾向于右边的box符号。
③用例
用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。
•用例场景是有步骤的（执行一系列动作)：是一个由一系列业务步骤组成的业务活动。
•用例场景是有目标的（可见的价值结果)：能够为参与者带来有意义的结果，如“填写搜索条件”对参与者是没有意义的，不是一个合适的用例。
•用例是对一组用例实例（也称为场景）的抽象，也就是说，用例是有路径（基本事件流、扩展事件流、子事件流等）的。如我们在ATM上取款时，可能会遇到很多不同的场景：正常取到钱、卡里钱不够、密码忘了、机器里没有足够的钱、卡被吞了等；这些可以概括为“取款”用例。
④用例图
上图的用例图并不是一个很好的建模结果，其中存在着一些不足，文章最后会指出这些不足并说明如何进行改进。
参与者与用例的关系：
用例之间的关系：
包括包含、扩展、泛化三种关系。
参与者之间的关系：
用例小结：
承接上面提出的用例图不足，因为“收款”这个子事件流只有“办理结账”一个用例用到，因此不应分解出来；只是为了讲解泛化关系才做这样的处理。改进后的用例图如下：
怎样归纳用例
①自顶向下导出法
从流程图中派生出用例图。流程图中的岗位信息是参与者的候选者，他们负责的业务活动就是用例的候选者。评价的要点就在于“是否属于系统范围”。针对每张流程图进行分析之后，得到一组用例图片段，将它们叠加在一起，抽象出系统的用例模型。
第一步：边界确定（去除非EndUser的职责带区）。首先排除掉不直接使用系统的岗位，因为它们不是系统要涉及的范畴。本例中，我们会问用户“纳税人直接使用系统吗？省局/局外部门使用系统吗？”，当用户告诉我们纳税人要到办税服务中心提交申请，省局、局外部门不直接使用时，我们就可以将这两个职责带区中的所有活动忽略掉。
第二步：确定角色（对剩下的职责带区进行角色化）。接下来就可以将精力放在中间两个职责带区中了，通过与用户的交流，确定出与系统相关的参与者。
对于职责带区“涉税窗口”，可以询问具体是由哪个岗位负责，将其称为什么比较合适？例如用户会说：“这是由受理人员处理的”，那么就可以确定出一个名为“受理人员”的角色；
对于职责带区“局内业务科室”，可以进一步了解每个活动是由哪个岗位负责的？结果会发现不同“申请”负责的科室是不一样的，这属于业务规则的部分，属于需求细节。但可以归纳出两种角色：核查人员和审批人员，未来再根据需求细节确定岗位与角色之间的关系。
第三步：确定用例。用例是从职责带区中的业务活动派生出来的。
对于“涉税窗口”而言，图中有3个用矩形表示的活动、2个用菱形表示的判断。对于活动，主要判断它是否属于系统范畴之内；对于判断，要分析它是属于某个活动还是一个独立活动。
对于“局内业务科室”职责带区，一共包含4个活动、3个判断。
第四步：绘制用例图。
②自底向上合并法
对于流程不泾渭分明的某些中小型项目适合采用“自底向上合并法”。从需求捕获阶段获得的需求列表着手，合并出所需的用例。与前一种方法可结合使用。下面通过一个案例介绍：
第一步：收集原始需求。某开发组织为了更好地积累自己的项目经验数据，更好地进行项目估算与计划工作，决定开发一个时间记录系统，用户原始需求列表如下。
第二步：确定参与者。从上面的描述中，我们可以确定候选参与者主要包括：管理层、研发经理、项目经理、开发人员。
然后我们再进一步分析他们所能承担的工作：
•开发人员：对任务进行操作和时间记录；
•项目经理：对项目的任务进行分配，了解项目内产能；
•研发经理、管理层：确定项目及进行产能统计工作。
另外，项目经理、研发经理也可以承担开发人员的角色，而研发经理则可以承担管理层的角色，也可以是项目经理的角色，因此它只是一个扮演了多个角色的岗位，可以将其去掉。
第三步：合并用例。参与者确定之后，将“原始需求”按参与者分组，然后再合并或分解为相应的用例。
第四步：绘制用例图。
用例分析技术应用要点
①用例真的有粒度吗？
业务价值判断是关键
上图左边的用例模型片段就是一个不合理的建模结果，右边的才是正确的。一个会员可能会跑到网站上设定一个选择条件就离开吗？显然不会，除非是意外中断了。也就是这个用例并没有真正传达出有价值的结果。
注：实际的应用中会存在两方面干扰因素：被包含用例、扩展用例：有人将其认作了用例，它们表示的是子事件流、扩展事件流，不是真正意义上的用例；技术性用例的引入：例如“登录系统”之类的东西过早被建模出来，但业务价值却并不明显。
用例粒度与系统复杂度相关的观点是错误的
真正影响用例大小的是业务流程，是工作任务的分工。同样是“将保险合同输入电脑”这样一件事，针对不同的保险公司，用例的大小就是不同的：A保险公司的规定是：保险销售人员只负责将合同扫描到电脑中，由专门的后勤人员负责录入合同中的关键信息，那么就应该整理出“扫描合同”和“录入关键信息”两个用例，因为这是由不同人员来负责的。B保险公司的规定是：扫描合同、录入关键信息都是由保险销售人员负责的，那么就应该是一个名为“录入合同”的用例。
CRUD的价值被过于放大了
在互联网、各种书籍中都曾经提到一个“CRUD原则”，也就是建立将“新增XX、查询XX、更新XX和删除XX”之类的用例合并成“管理XX”。但实际上这个原则并不是那么常用的，很多时候被误用。
如在一个图书管理系统中，新增、删除、查询、更新操作实际上都不是由一个角色完成的，它怎么能够被合并在同一个用例中呢。CRUD原则对于“系统创造的东西”才适用，例如管理系统用户、管理数据字典、管理权限、管理购物车之类的东西就适用于该原则。
②用业务动词命名用例十分重要
某开发团队在开发银行信用卡管理系统时，整理了一些用例，其中包括：创建客户、更新客户、删除客户。有问题吗？当然有问题！别忙，千万不要错上加错，按CRUD原则将其合并成管理客户就将离正确越来越远了。
下图才是正确的做法：
③采用先事后人的方式分析是要点
在用例分析过程中，应该将人（角色、参与者）和事(场景、用例）分开考虑，先事后人地思考。如在开发一套医院管理系统时，分析人员了解到如下所示的需求。
在药房中，有3个主参与者：接待员、药房技师和药剂师。其中任何一个参与者都可能接待客户，接收处方。药房技师和药剂师都可以按照处方抓药，但只有药剂师有权审核处方并在处方中签字，而药房技师是协助药剂师的。
很多分析人员会先列出有哪些角色，然后再从角色看功能，结果就得到了如下图所示的用例模型。
看到这样的结果，自己也不满意，然后就开始使用扩展、包含关系来精化它，结果就得到了一个很怪异的结果。
如何获得更加合理的用例模型呢？在确定了参与者之后，再抽取出“事”（也就是用例），然后完成它们之间的连接，可轻松地获得更合理的结果。
四、周期一的产物
工作任务说明
在需求分析的第一阶段，核心任务就是结合业务流程、报表的需求，梳理出结构框架（领域模型）和行为脉络（流程图+用例模型），为第二阶段的需求分析工作建立基础，指出方向。
具体就是从上一阶段标识出来的业务事件（业务流程的起点）和报表列表开始，展开对中层管理人员的访谈与调研，而范围就是“体检业务子系统”所对应的服务中心、体检科室和综合科三个部门。然后再根据访谈的结果完成事、物、人的分析，最后在此基础上抽象出该主题域的领域模型和用例模型。
业务事件分析
在需求定义阶段中，我们已经通过和客户交流、绘制上下文关系图的方法，标识出了体检者申请体检、体检者中途改单、财务部门提交团队缴费情况、客服中心查询体检情况、维护人员管理体检项和系统通知用户取报告6个业务事件。
①体检者申请体检
业务流程分析：
注意1：开单收费环节涉及到业务判断，图中并未体现。因为它们属于细节层次，而判断的原则是对不影响泳道间协作的判断、活动均属于细节信息。
注意2：为便于在后续填充需求细节时更好地进行数据需求分析，可以标识出相关的表单、文档、规则等。可标识出以下相关文档：体检申请单（体检者在申请体检时填写的）、体检单（开单时打印出来的)、账单(收费时打印的）、体检项收费清单（在收费时使用的）、体检结果报告（体检科室的产物）以及体检报告（综合科出具的结果）。
业务实体分析：
实体分析的关键是理清问题域中的关键术语之间的关系，标识出类，确定它们之间的关系，并用类图表示出来。当主题域中所有业务流程、报表都分析完成后，再抽象出整个主题域的领域类图。本例中，听到的主要术语（候选类）就包括：体检者预约单 体检项目 体检套餐 体检单账单 体检结果 体检报告。
角色-使用场景分析
最后研究项目的边界，完成活动图到用例图的转换，完成系统的角色和使用场景分析。
综上，得到如下用例图片段：
报表分析
报表分析工作可以分成Why(目标)、What(内容）与How(展现形式）三个层次；而Why应该在需求定义中明确（有时也会拖到本阶段来完成），在这个阶段关键在于对其数据内容进行分析。以“体检业务周期统计报表”为例进行说明。
Why
What
对于每一类报表，需确定与它相关的业务实体、主要数据项、数据项的计算方法，同时还要确定有多少具体的报表。
相关业务实体分析。根据对此类报表目的分析，我们可以知道所需的信息应该从“体检单”、“体检项”、“体检套餐”三个类中获得。另外我们还需要知道体检科室和体检项之间的关系，才可以统计出每个体检科室的任务量。因此关联的业务实体包括：体检单、体检项、体检套餐、体检科室4个，这样就可以用类图表示出来。
报表项分析。“体检业务周期统计报表”是一类报表，我们需要根据实际的需要确定出具体的报表项，每个报表项可以建模为一个用例。通过与客户的交流，加上对报表目的的分析，我们可以得到如下用例图片段。
“体检业务周期统计报表”用例图片段
数据项及计算方法分析。据各类报表明确重要的数据项，对于派生出来的数据项还应该说明其计算方法。
抽象与整理
通过前面的分析，将得到多个用例图片段（一个业务流程就有一个)、多个领域类片段（每个业务流程、每类报表都将有一个)。接下来可以通过Rose等建模工作对其进行抽象，创建出整个主题域的用例模型和领域模型。
①抽象用例模型
②抽象类模型
通过以上这些分析，就可以完成结构框架和行为脉络的填充，同时将其填充到软件需求规格说明书中。
需求分析与建模周期一产物：
链接：/s/1gL_CyUT9ju8okM59rBcaDw
提取码：pjqa
相关阅读：
wend huo：1.软件需求最佳实践笔记 | 需求框架
wend huo：2.软件需求最佳实践笔记 | 需求实践现状
wend huo：3.软件需求最佳实践笔记 | 需求视图
wend huo：4.软件需求最佳实践笔记 | 软件需求与需求工程
wend huo：5.软件需求最佳实践笔记 | 需求定义
wend huo：6.软件需求最佳实践笔记 | 需求捕获
wend huo：7.软件需求最佳实践笔记 | 需求分析与建模（一）
wend huo：8.软件需求最佳实践笔记 | 需求分析与建模（二）
wend huo：9.软件需求最佳实践笔记 | 需求分析与建模（三）
wend huo：10.软件需求最佳实践笔记 | 需求描述
wend huo：11.软件需求最佳实践笔记 | 需求验证
wend huo：12.软件需求最佳实践笔记 | 需求基线
wend huo：13.软件需求最佳实践笔记 | 需求变更
wend huo：14.软件需求最佳实践笔记 | 需求跟踪
wend huo：15.软件需求最佳实践笔记 | 总结
