已剪辑自: https://zhuanlan.zhihu.com/p/81683041
一、需求分析与建模的要点与误区
需求分析的任务并不是分析系统如何实现用户的需要，这是对需求分析最常见的误解。需求分析实际上是业务分析，也就是选择一种业务导向的线索将零散的需求串起米，形成一个体系完整、内容清晰的框架，以指导后续的设计、开发工作。需求分析就是先分解，再提炼，在这个过程中消除矛盾。
①分解
分解是人类控制复杂性，认知复杂事物的最佳实践，不管是采用结构化分析方法还是面向对象分析方法，分解是必然的手段。现代需求工程理论更建议采用业务导向的分解，而非传统的系统导向的分解。
以业务流程为主线索的分解结构
就是按“事”的角度进行分解。它对于联机事务处理系统、管理信息系统而言都是非常适用的方法。目标系统->主题域的分解依据的是“目标决定范围”，从主题域->业务事件、报表类型所做的是理清脉络，从业务事件->业务活动、报表类型->报表所做的是填充细节。
程序结构为主线索的分解结构
这种分解结构在需求分析过程中最常用的，但它过早进入了程序结构，割裂了与问题域之间的联系，容易导致对问题域研究的不足，降低了需求的质量。这种方法适用于问题域不复杂，或者系统与问题域关联性不强的情况下，例如工具软件、面向设备的嵌入式系统等。
②提炼
分解会破坏其他线索的完整性。如果以“事”为线索，会发现数据需求分解后就会出现相互交叠的情况，也就是在多个业务事件中都涉及相同的类。因此，需要采用自底向上的方法进行提炼。如将每个业务事件中的类进行提炼，抽取出共性的部分，建立针对整个系统的全局领域模型。
注：领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。
③消除矛盾
在这样的分析过程中，会发现有些需求是相互矛盾、相互冲突的。由于是把收集的信息放在一个预先定义的结构中发现这些矛盾的，因此对矛盾的影响范围会有直观的了解，也知道它影响到哪些层面。这样，就可以很快地找到相应的人员，通过进一步的需求捕获来消除矛盾。
①建模的目的
模型有效地帮助人们更好地认识、应用、设计复杂事物。建模是需求分析的主要手段，它通过简化、强调来帮助需求分析人员理清思路，达成共识。因此，需求建模的过程远比建模的结果更重要。主要目的是提供一种详细说明系统结构或行为的方法。
注：原先，由于计算机应用还不普及，软件系统的规模和复杂度都相对较小，应用“数据结构+算法=程序”的模式就可以解决大部分问题。随着计算机应用的不断普及，业务模式、数据量都在迅速变化之中，软件涉及的问题也越来越广，早已经超出人们可以处理的复杂度。
②正确认识建模方法论
建模方法论的时代背景与要点
结构化分析与设计方法和结构化分解是两个概念，不过结构化分析与设计方法充分应用了结构化分解的理念。结构化分解实际上是人类认识复杂事物的最佳实践，在很多领域都有应用，如生物分类、项目管理中的工作任务分解结构、公司管理（组织结构分解）等。
③正确认识UML
UML是一种统一的、标准化的建模语言，不是方法论。它能为参与软件设计和开发的人提供一种公共“语言”，使他们能够基于共同的“模型”来理解业务、需求，理解软件和架构如何构造。
UML的各种图见下表:
在需求阶段使用的UML图：
下面正式进入需求分析与建模部分。
二、周期一：理清框架与脉络
本阶段的任务是理清需求的结构框架（领域类图）和行为脉络（流程图和用例图），该工作的输入是需求定义阶段产生的业务事件列表和报表列表，输出的是领域模型和用例模型。该阶段的结束标志是标识出了绝大部分的用例，生成了领域模型。
在整个过程中对每个业务事件做业务流程分析、业务实体分析和用例分析；针对报表进行业务实体分析和用例分析。
1、业务流程分析
针对每一个业务事件，分析并识别现有业务活动，确定业务活动之间的关系；了解这些业务活动需要接收哪些信息，将产生哪些信息，确定信息传送的路线；同时标识出业务活动的部门、岗位等信息。
业务流程分析的三个关键点：一是理解流程的层次性；二是了解流程的类型；三是掌握业务事件识别、寻找流程的技巧。
流程是有层次的：
流程有组织级、部门级、岗位级三个层次，其中部门级是需求分析的主线索，岗位级是需求细节填充时的工作内容，组织级是对部门级流程的抽象概括。
流程是有类型的：
注：拿软件开发过程来说，需求分析、软件设计、软件编码、软件测试都是生产性流程；项目管理、质量保证就属于管理性流程了；支持性流程包括配置、文档控制等。
流程分析的产物：
在软件开发过程中，最常使用的模型有三种：跨职责流程图、活动图和数据流图。
①跨职责流程图
跨职责流程图主要由流程名称、职责带区、流程阶段、业务活动、判断/审批等组成。
下面是一个示例：
跨职责流程图完成的标准：一是所有的职责带区上的命名都将细化到具体的岗位；二是每类活动之间的关系已经没有疑问。还有一点是需要特别注意的是不应该对业务活动进行细化。
②活动图
下图是一个常见的活动图：
常规活动图
带泳道的活动图：
每个活动节点、分支是必须只属于一个泳道，而转换、分岔与汇合是可以跨泳道的。通过泳道，我们不仅体现了整个活动控制流，还体现出了每个活动的实施者。
带对象流的活动图：
通过带对象流的活动图表示数据、文档的流转，可以修改对象的状态，还可以显示对象的角色、状态和属性值的变化。
复杂的活动图—辅助活动图：
如果一个活动图过于复杂，或者活动图中某一组活动与主控制流关联不大，那么就可以借助辅助活动图来描述它。
活动节点“收款”，包括了多种不同处理：网上银行、点卡、汇款等。
复杂的活动图—汇合描述：
在默认情况下，当汇合的所有入流均到汇合点时，就将执行汇合点指向的活动节点。但是有些时候，你希望对其做一些约束，这时就可以借助汇合描述来完成。
汇合描述实际上是一个约束，其格式就是“{约束条件}”。可以在汇合点加上“{Order.State=Payed}”来说明，只有当订单状态为已付款时才执行下一个活动节点“供应商送货”。这样就可以更加清晰地描述出，只有客户付了钱之后，才执行订单的送货操作。
复杂的活动图 —发送与接收信号：
如果需要表示出异步事件，这在活动中可以通过信号机制来表示。
小张去必胜客吃饭，发现要排队，他决定如果15分钟还轮不到，就到隔壁的肯德基吃饭，那么就可以通过上述的符号来表示。为了使例子保持简单，假设小张排在最前面。
复杂的活动图 —引脚（pin)：
就像类中的方法可以包含不同的参数一样，一个活动节点也可能有相应的参数。如果打算标明每个活动节点所需的数据以及它将产生的数据时，引脚是一个很好的手段。
上图表示活动“计算利息”将接受三个参数：本金（principal)、利率 (rate)和年限（year)；如果传入的参数合法，将输出利息值（accrual)；如果传入的参数错误，则产生异常。该活动节点没有与其他节点相连，需在小矩形中添加箭头符号，以区别输入参数和输出参数。除用名字表示顺序之外，还可以在引脚边上标注表示顺序的数字。如果引脚产生异常对象，则可以在符号边上标注一个空心三角形。
就是当流程图绘制完之后，应该尽可能对其进行一些分析，包括瓶颈分析和利益分析，以此减少变更的影响，看下面的案例：
赊销活动图示例1
该流程是一种典型的赊销模式，收款和送货并行进行，必然会对财务部门的收款工作产生障碍。当然，这种模式对于销售部门而言是十分有利的，因此在公司初创时期，很多公司就会釆用这样的模式，毕竟这个时期总经理最关注的就是销售额。
而当销售量上升的同时，应收账款也不断上升时，这种问题就会暴露出来。特别是公司逐渐成长起来，销售额达到一定量的时候，总经理就会更关注资金安全问题。既然问题是收款和送货两个活动并行执行导致的，那么只要将这种并行模式转成串行模式就能解决问题了，也就是先收款后送货。
赊销活动图示例2
也许执行这种流程后，销售竞争力大幅下降，总经理又会认为主要矛盾在销售了，不就又有将流程改回去的冲动了吗？因此，可采用一种更合理的折中方案，引入“信用额度”控制，对于赊销顾客，根据历史交易情况设置一个信用额度，欠款在额度之内可继续赊销，否则先付款后发货。
赊销活动图示例3
③数据流图
数据流图的元素包括过程/加工、数据存储/文件、外部实体、数据流、实时连接等。
数据流图主要元素
数据流图一般是分层绘制的：
分层的数据流图示意图
第一步：构建顶层图
数据流图顶层图示例
这个课程注册系统的流程是：教务处提供有关课程信息，学生获得课程安排后，进行申请注册，教师在注册完成后得到班级列表。
第二步：根据业务事件绘制DFD片段
业务事件列表示例
DFD片段示例
第三步：将DFD片段合并成DFD
DFD 0层图示例
第四步：逐步细化，分解到底
DFD 1层图示例
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模型。它的优势在于能够更好地与后续的数据库设计结合，缺点在于语义相对于类图来说更弱一些，同时对面向对象开发的指导作用相对差一些。
在传统的数据建模理论中，将整个建模过程总结为6大阶段，它们将分别从不同的视角、循序渐进地完成
概念模型VS逻辑模型：
概念模型和逻辑模型实际上是对“需求视图”与“开发视图”的区分。换句话说，概念模型是需求人员的视图，等价于领域模型；逻辑模型是开发人员（包括设计人员）的视图，它约等于面向对象分析与设计方法中提到的“分析模型”。
例如，在某电子商务网站系统的需求调研阶段，通过与客户的沟通完成如下图所示的领域模型片段。
用E/R模型很难表示子类、组成等关系
逻辑模型片段示例，E/R模型只能通过一对多的关联关系来表示整体/部分关系
逻辑模型VS物理模型：
是对“开发视图”与“数据库视图”的区分，换句话说，物理模型就是DBA的视图。在许多团队中逻辑模型和物理模型几乎是一致的，如果说有区别的话，那就是中英文版本而已。物理模型会考虑到性能、效率等多方面的因素。
②E**/R模型的主要元素**
E/R模型与关系型数据库关系紧密，因此在数据库设计阶段它的优势很明显，相关的工具也可以实现E/R与关系型数据库的正向、逆向工程，即基于E/R图创建数据库，以及基于数据库创建E/R图。
E/R模型的基本元素
E/R模型元素之间的关系
3、角色与使用场景分析
①用例分析技术概述
用例分析技术的关键是“发现使用系统的角色（参与者），了解并梳理这些角色将如何使用系统（场景）”，从而更好地完成“人”的视角的需求梳理。
用户包括两个有机的组织部分：用例图是目录，用例描述是封装所有需求的形式。
②参与者与用例
参与者是在系统之外，透过系统边界与系统进行有意义交互的任何事物。判断的要点在于他们是不是系统行为的触发者。
边界是一个逻辑的概念，是一种职责边界而非物理边界。简单来说，它就是指“待开发系统”；如果将整个待开发系统分成不同的部分，在对每个部分创建用例模型时，也可以将这个独立的部分视为一个系统的边界。
参与者不仅可以由人承担，还可以是其他系统、硬件设备，甚至是时钟。
注：MartinFowler认为，参与者更适合的术语是Role(角色），而Actor是源于对瑞典语（Iva是瑞典人）的误译。
一般，对于由人扮演的参与者，偏向采用下图左边的形象符号；对于系统扮演的参与者，则会倾向于右边的box符号。
③用例
用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。
•用例场景是有步骤的（执行一系列动作)：是一个由一系列业务步骤组成的业务活动。
•用例场景是有目标的（可见的价值结果)：能够为参与者带来有意义的结果，如“填写搜索条件”对参与者是没有意义的，不是一个合适的用例。
•用例是对一组用例实例（也称为场景）的抽象，也就是说，用例是有路径（基本事件流、扩展事件流、子事件流等）的。如我们在ATM上取款时，可能会遇到很多不同的场景：正常取到钱、卡里钱不够、密码忘了、机器里没有足够的钱、卡被吞了等；这些可以概括为“取款”用例。
④用例图
改系统以Internet的形式向客户提供座位预订的服务，如果暂时无法获取座位信息时，允许客户进入“等候队列”，当有人退订之后将及时通知客户。另外，还将为总台服务员提供座位的安排，以及结账的功能，支持现金和银行卡两种结账方式。
上图的用例图并不是一个很好的建模结果，其中存在着一些不足，文章最后会指出这些不足并说明如何进行改进。
参与者与用例的关系：
参与者和用例之间的关联关系表示两者之间将进行通信，任何一方都可以发送和接收消息。
通过泛化关系避免交叉线
用例之间的关系：
包括包含、扩展、泛化三种关系。
参与者之间的关系：
通过参与者泛化来简化模型表示
通过泛化关系避免交叉线
用例小结：
承接上面提出的用例图不足，因为“收款”这个子事件流只有“办理结账”一个用例用到，因此不应分解出来；只是为了讲解泛化关系才做这样的处理。改进后的用例图如下：
①自顶向下导出法
从流程图中派生出用例图。流程图中的岗位信息是参与者的候选者，他们负责的业务活动就是用例的候选者。评价的要点就在于“是否属于系统范围”。针对每张流程图进行分析之后，得到一组用例图片段，将它们叠加在一起，抽象出系统的用例模型。
某税务效能管理系统中针对“业务申请”流程图
第一步：边界确定（去除非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等建模工作对其进行抽象，创建出整个主题域的用例模型和领域模型。
①抽象用例模型
体检业务子系统用例模型（非完整版本）
②抽象类模型
体检业务子系统领域模型（非完版本)
通过以上这些分析，就可以完成结构框架和行为脉络的填充，同时将其填充到软件需求规格说明书中。
需求分析与建模周期一产物：
链接：https://pan.baidu.com/s/1gL_CyUT9ju8okM59rBcaDw
提取码：pjqa
已剪辑自: https://zhuanlan.zhihu.com/p/81742713
承接上文“软件需求最佳实践笔记 | 需求分析与建模（一）”。
三、周期二：确定需求细节
本阶段的任务是对用例模型、领域模型标识出用例、领域类的细节进行填充。对于组织行为需求的用例，要填充用例的事件流；对于组织数据（结构）需求的领域类，要填充它的字段与格式，具体包括：
字段/属性信息：也就是每个领域类所包含的成员属性，细化其构成；
字段格式与规则：也就是每个字段详细的格式（诸如字符型、日期型等类型，以及长度、可选值等内容)、组成规则（诸如由多少个字符、多少个数字组成等)；
计算规则：对于一些非直接输入的派生属性，通过数据表达式的方式来描述；
结构规则：对于数据的组成、格式进行描述。
对于组织行为需求的用例而言，要细化的东西主要包括事件流、相关需求与功能点、界面原型，以及特定于该用例的规则与约束。
①用例的灵活运用
根据行为需求的特点，可以将其分成“业务功能、报表功能、接口、技术支撑”4种类型。为了需求管理的方便，可以将其统一封装成用例，在具体细节描述方面，可以对其进行灵活处理。
②用例描述模板
针对业务功能类的用例来说，需要整理的内容主要包括事件流、相关需求与功能点、界面原型、规则与约束4个方面，描述的方法可以采用通用的用例描述模板来组织。
链接：https://pan.baidu.com/s/1mPAmN2uLyt1jMbGN6JrseQ 提取码：sqsn
用例编号：主要用于需求跟踪，不建议使用如UC101、UC102…之类的顺序编号：采用这种编号，插入一个用例时会显得十分麻烦。建议使用诸如“UC_子系统_类型_用例名称缩写”带有意义的编号规则。
用例名称：采用业务动词命名，是否合适关键在于用户代表是否能够认知，是否能够与实现的工作场景相对应。
用例概述：从用户执行该用例所能实现的目标着手，而不应简单地概括所有的动作；如无法写出目标，通常应反思用例的抽取是否合适。
主参与者与次要参与者：主参与者通常是指执行用例的用户，次要参与者则通常是用例执行过程中的协作者，大部分用例是没有次要参与者的。
项目相关人员利益说明：用例的功能设计不仅取决于执行它的最终用户，还和一些间接用户相关。
规则与约束：针对本用例的数据规则、业务规则、设计约束等信息。
前置条件、后置条件、成功保证、基本事件流、扩展事件流、子事件流则是用例描述中的核心部分。
③事件流分析
场景和用例之间的关系，与对象与类之间的关系类似；也就是说，一个用例是一组相似场景的抽象；因此，一个用例通常是一组事件流所构成的。
前、后置条件
前置条件是指在用例启动时，参与者（Actor)与系统应置于什么状态。这个状态应该是系统能够检测到的，在用例启动前能够检测到的，而且还应该是有意义的。
如上面的用例，客户已发出订单：不合适！因为这是系统无法检测到的；工作人员已登录系统：从前置条件的定义来看，它是吻合的。但它仍然是不合适的。因为这是一个意义不大的前置条件。这通常是“模板综合症”的表象，模板中列出的总感觉必须填写，这并不是一种科学、有效的态度。•库存大于订单数：不合适。这个值在用例开始之前是无法检测的。相反它恰好是一个正确的后置条件。
后置条件是指在用例结束时，系统应置于什么状态，这个状态应该是系统能够检测到的，在用例结束前能够检测到的，而且也应该是有意义的。
注：前、后置条件出现的频度并不高，不要画蛇添足。
事件流的类型与表述要点
对于用例而言，最常见的事件流类型包括3种：
在编写用例事件流的时候，为更加清晰地表达的含义，应该注意以下要点：
•使用简单语法：主语明确（尽可能采用主谓宾结构，少用修饰性语法)，语义易于理解。
•明确写出“谁控制系统”：也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制。
•显示过程向前推移：每一步都有前进的感觉（如用户按下Tab键作为一个事件是不合适的）。
•用“确认”而非“检查是否”，如“系统确认所输入的信息中书名未有重名”；因为采用“检查是否”很难判断后续的动作是基于“是”还是基于“否”。
•从俯视的角度来编写：指出参与者的动作以及系统的响应，重点在于展示参与者的意图而非动作，否则很难让读者构建清晰的视图。
业务用例与系统用例
很多用例建模者都喜欢在用例描述中添加用户界面实现细节，其中一个原因是对业务用例和系统用例的错误理解。很多人认为：业务用例描述的是业务步骤，系统用例描述的是系统操作。其实错误的，实际上业务用例描述的是所有的业务步骤，而系统用例则只描述与系统相关的业务步骤。下面通过一个例子来说明业务用例以及系统用例的抽取过程。
•得到乘客的机票或记录标识符——1.确定乘客的预订信息
•确定乘客、航班、目的地是否正确——2.确保乘客身份正确，并与正确的预订联系起来
•检查护照有效并属于这名乘客——3.检查护照有效并属于这名乘客
护照必须是本人的；在旅行结束之前不能过期；对旅行的目的地国必须是有效的；签证必须是有效的；无目的国“拒绝入境”印章
•记下常客编号——4.记录常客的编号
•5.分配一个座位
•询问安全问题——6.询问安全问题并得到正确回答
•7.行李托运
•8.打印登机牌和行李标签并递给乘客
•9.祝乘客“旅途愉快”
以上有许多步骤都是与系统无关的，是由用户手工完成的。因此，可以在此基础上筛选出与系统相关的步骤。第2、3、6、9步显然都是与计算机系统没有直接关系的；将它们从事件流中去除之后，就可以获得针对该场景的系统用例事件流。
创建业务用例描述的好处主要有两个方面：
•避免断章取义，帮助开发人员更好地理解场景。例如，根据后面抽象出来的系统用例事件流，开发人员在用户确定乘客预订信息的界面之后，就会直接跳转到常客编号页面；而如果看到了业务事件流，就会想到应该在此提供一个用户信息确认界面，帮助用户更好地完成第2、3两步工作。
•更好设置未来的扩展点。例如，第3步中的工作现在必然是人工完成的，但未来随着IC卡身份证、电子护照的普及，它就可能成为系统的一部分。
不当事件流示例分析
下面是一个综合型错误的例子：
针对上面这个事件流片段，相信没有几位读者能够从中获得清晰的脉络。导致这种结果产生的主要因素主要包括以下几个方面：
•过多实现细节：在用例事件流描述中，如果出现了诸如鼠标、键盘操作，窗口、下拉菜单等信息都是不好的表现。
•过于冗长：第3〜6步的描述给人的感觉比较拖沓，这样会导致整个描述详略不当。
•将分支结构交织在主线索中：第7、8两步中就包括了一些分支结构。
修改过的用例事件流：
下面是一个过于絮叨的例子：
建议采用如下所示的描述方法：
用户输入个人基本信息（字段内容参见业务对象BO_Customer)。
用户输入订单基本信息（字段内容参见业务对象BO_Order)。
这是因为对于某个实体（诸如个人、订单等）而言，字段内容的变化是很常见的，而且它通常会在多个用例中引用。如果直接采用Copy-Paste的策略，最终难以保证进行了正确的更新。
小结
编写用例的事件流时应该避免出现实现细节，不能过于冗长也不能过于简单（判断的要点在于是否写出了交互)，并且每个事件流都应该明确地指出主语。另外，在编写事件流时应该避免直接出现if-else之类的分支结构、for…之类的循环结构，更不应该出现switch…case…之类的多路分支结构。
④相关需求整理
用例作为行为（功能）需求的封装单元，是按业务活动的角度将需求分而治之的方法，是对需求捕获阶段获得的用户原始需求的合并。实际应用中，可能会发现有时事件流很简单，没有编写的必要；有的时候却会发现事件流无法覆盖所有的功能需求。因此，需要对用例的相关需求进行整理。
用户原始需求
将需求捕获阶段获得的用户原始需求（通常每个原始需求是以一句话）整理到相应的用例中是一种很好的实践，可以更好地建立用户原始需求和软件需求（用例）之间的映射。通常，在以下几种情况下适合采用这种方法：
•事件流很简单：可以考虑直接将用户的原始需求罗列出来，忽略传统的事件流表述部分，开发人员在实现时只要注意满足这些需求即可。
•原始需求比较零散，有些超出了事件流、规则的范畴：可以考虑既编写事件流，同时还将原始需求罗列在用例描述之后。
•需求变更时：用户在提出需求变更时，我们需要找到其影响的用例，这样就能够更好地“对号入座”地处理。
具体操作时，可以考虑通过一个电子表格（或称为矩阵）来管理。
注：采用Word组织软件需求规格说明书的团队而言，可以直接把相关的原始需求放在用例描述之后
相关功能点
有时可能还会涉及一些无法有效地表述在事件流中的小功能点。例：在“受理业务申请”用例中，可能还需要实现受理表模板管理、打印格式模板管理等功能，如果它们属于局部的功能，则可以作为“相关功能点”来描述。这样当开发人员着手实现时，就能够更好地考虑到这些要求，提供更加科学、合理的解决方案。
⑤界面原型
界面原型要点
用例描述中是不建议包括界面实现细节的，而界面细节通常又属于需求的一部分，因此在需求分析、编写需求规约时也是不可忽略的一部分。
•“用户界面”的后面经常出现的词是“设计”，而非“分析”，因此用户界面不是分析出来的，而是设计出来的；需求人员应该提供设计依据而非设计结果，需求人员肯定无法了解所有最新的UI技术，也就不可能得出用户界面的最佳设计结果。
•软件需求规格说明书里的用户界面原型不是解决方案，它应该被视为约束、建议。也就是客户对用户界面原型的要求（约束），以及需求人员根据对用户场景、需要的理解给出的实现建议。开发人员不应该以此画地为牢，从而限制了合理用户界面的出现。
•创建用户界面原型时，重点在于实现用例事件流的交互过程，在于讲述每个界面中要满足的用户意图，而不仅仅是浮于表面的元素个数、位置、大小等信息。
交互不要忽略
可以考虑在原有的静态用户界面原型的基础上，绘制出“界面流转示意图”（可以用状态图或草图），以补充交互过程的描述。也可以使用状态图表示页面流转。
别让界面掩盖本质
从以上例子可以看出，用户界面至少还应该考虑从以下3个方面进行补充：
•目的：这个或者这组用户界面元素想让用户实现什么操作，达到什么意图，该信息能够有效地帮助开发人员理解场景。
•信息要求：说明信息显示的内容、格式、排序方法等方面的信息，帮助开发人员在实现时有效地实现它。例如，对于界面中心的“楼层平面图”就指出了应该显示房型、状态、房号三个信息，并建议考虑使用颜色来标识状态信息。
•操作要点：对于用户操作该界面时一些应该考虑到的要素或约束，例如，对于“完成”按钮指出要二次确认，要显示总结信息；对于“切换楼层”下拉列表而言，指出了应该能够直接通过输入数字的方法来进行快速定位。
⑥规则与约束
规则是在实现时应该考虑的东西，而约束则是对技术手段选择起到限制作用的各种条件。
规则的分类
从需求的角度来看，规则可分为：行为（功能、业务）规则、结构（或称为数据）规则、界面规则三类。
规则的影响层次
行为规则可能影响整个主题域，可能只是影响一个业务事件，也可能只是影响一个业务事件中的某张流程图，还可能只影响某个业务活动（即用例），甚至可能只对某个用例中的具体的某个步骤产生影响。通过层次分析，决定把规则写在什么地方。
对于结构规则，它影响的层次可以分为领域类间、领域类内、字段三个等级，我们也可以将其放在不同的位置上。
其他约束
⑦基于Stakeholder利益分析的需求挖掘
虽然每个用例都是为一个参与者实现一个价值的业务活动，可是在具体实现时它的功能细节却不仅仅受到参与者的影响，甚至连参与者本人也可能无法给出完整的需求。其中一个很重要的原因就在于Stakeholder的利益会对用例的功能细节产生微妙的影响。
超市收银用例Stakeholder
通过分析，我们发现收银员的上游是买单的顾客，下游是财务人员（收银员交班时要将收到的钱交给财务人员），管理者显然现场经理，但协作者还不明显。
下表分别为每类Stakeholder列出了一些分析示例：
超市收银系统LED显示位置示例
①基本内容
软件需求规格说明书中如何对领域模型进行组织，以及如何对其进行细节描述。
领域模型的组织
通常首先按照主题域进行第一次分解，一个主题域对应一个领域模型，然后根据需要可以将各个主题域中共性的领域类抽取出来，形成全局公共领域类模型。
每个主题域内的领域模型（包括全局公共的领域模型），涉及的领域类可能还很多，可根据其逻辑关系划分成不同的部分，通常用包来表示；每个包中就是一个逻辑相关的领域类图片段。
接着，对每张领域类图片段进行简要的概述，罗列针对所有领域类的共性结构规则，然后再分而治之地进行描述。最终形成如下图所示的层次结构：
接下来，对每个领域类做进一步描述。通常可以从“数据窗口分析”、“数据组成与格式”、“派生数据的计算方法”三个角度进行描述。
数据窗口分析
数据窗口分析需求实践中一种视角，通过这一工作我们可以更客观地认识系统中的数据耦合。项目实践中经常发现公共的数据表成了大家工作交叉、冲突的温床。所有的修改都经过这张公共数据表或多或少地影响到其他人的工作。对于这种情况，建议采用如下图所示的方法，将共性的属性变成公共的，个性的属性压在各个模块中。
建立数据窗口的思想后，在对数据需求进行梳理时，针对每个类可以考虑采用如下图所示的组织方法来表示。
数据组成与格式
前面讲清楚的是该领域类是由哪些字段构成的，这些字段分别应用于什么主题域、哪个业务流程或报表，以及它们之间的共性属性有哪些。接下来，就应该对其格式、组成规则进行详细的描述。具体来说，这方面的信息包括以下几种类型：
•数据类型：诸如字符串型、整型、布尔型等；
•长度、精度信息：甚至可能涉及数据库存储的长度信息，诸如varchar(100)，最好避免出现，此类信息应该放在数据库设计文档中。
•组成格式：也就是具体的构成规则，例如编号由2位字母、6位数字和一个可选的X组成。
组成格式建议考虑使用数据字典中的词条法表示：
=(等号）：表示由…构成
+(加号)：表示顺序连接的关系
|：表示从里面的项目中选择一个
{}n(花括号，外边是一个上标)：表示n次重复
()(括号）：表示可选的数据项
*…*表示特定限制的注释，诸如0—9表示数字
对于前面提到的编号而言，要表示它是由2位字母、6位数字和一个可选的x组成，可以表示为：编号={[A…Z丨a…z]}2+{0…9}6+(X)。
派生数据的计算方法
在领域类中，还涉及一些非直接输入值的属性，值是计算得出的。如订单类中的总金额。需要对它们的生成规则、计算方法进行表述，而描述的主要方法是算术表达式；有些时候可能会涉及较复杂的计算，如根据订单总金额所在的范围确定打折的幅度，这时决策表、决策树就是比较适合的方法。
②常见盲区
与结构需求相关的常见盲区包括数据结构特点、数据使用特点以及非功能要求三方面。
数据结构特点
数据使用特点
数据使用的角度不同，也会对具体的开发实现产生影响。最显然的区别在于联机事务处理系统和管理信息系统的数据使用特点；前者重在数据的记录，后者重在数据的查询、分析与统计。
数据的不同使用角度会对开发实现产生很大的影响，为了有效地预防这种情况的影响，建议为每类报表绘制一个相关领域类图片段，这样当我们动到任何一个领域类时，都可以找到所有可能受影响的报表、流程，从而采取一些相应的手段。
非功能需求
需求捕获阶段记录规模最大的用户的具体数量、数据提交的频率、数据量等信息。
①工作任务说明
在需求分析的第一阶段（周期一)，完成了结构框架（领域模型）和行为脉络（流程图及用例模型）的梳理，因此在第二阶段，工作任务就是填充需求的细节，具体来说就是根据前面说明的过程与内容来填充用例、填充领域类。
从工作量的角度来说这个阶段比上个阶段要大得多，因此通常是无法一次性完成所有的用例、所有的领域类的细节填充的。在实际的工作中，建议根据迭代计划来分阶段细化，也就是将所有的用例划在不同的需求基线上，分配在不同的迭代中，然后使需求工作与设计、开发工作实现流水线。
②填充用例描述
开单用例分析
内容主要包括用例名称、编号、参与者、用例概述、相关Stakeholder等几个部分。
用例名称：开单就是一个比较合适的用例名称，它是一个用户熟悉的业务动词，能够很好地理解。
编号：建议不要使用顺序号，而是使用有一定意义的编号；在此我们使用UC_B_TJ_KaiDan作为编号，表示这是一个业务功能类用例（B)，属于体检主题域（TJ)，用例名称为开单（KaiDan)。
参与者：该用例的参与者是“服务人员”。
用例概述：用例概述从目标、意图的角度进行表述；对于本用例而言，可写作“服务人员根据体检者的选择或预约单开具体检单，并打印出来交给体检者”。
相关Stakeholder：其相关的Stakeholder有两个，一个是上游的体检者，另一个是下游的收费人员。
2.事件流分析
先对该用例的前、后置条件进行分析。
前置条件：前置条件应该是系统可检测、在开始前可检测、有意义的；因此对于本用例而言，并没有相应的前置条件。要注意的是“体检人申请体检”是业务前提，但由于系统无法检测，因此不是合理的前置条件。
后置条件：后置条件应该是系统可检测、在结束时可检测、有意义的；对于本例而言，根据对业务的了解，我们发现体检单是由体检套餐和体检项目组成的，而体检套餐是包括体检项目的，这样就可能出现重复的项目，因此需要在用例结束时“确保没有重复的体检项目”，这就是它的后置条件。
结下来对用例的事件流进行分析。在实践中，可以询问“开单”工作是如何进行的，用户就可能谈出如下所示的场景：
“当体检者要体检时，首先到我这里办理。如果已经预约，则告诉我他的预约号或者姓名；如果没有预约则填写体检申请表，选择体检项目或体检套餐（可以自由组合体检项目和体检套餐）。然后我将根据预约单或体检申请表的内容生成系统中的体检单，并打印出来。”
开单用例的事件流描述：
基本事件流：
1.参与者输入用户姓名或预约号，系统确认用户已经预约，并从预约单中获取体检套餐与体检项目显出在屏幕上；
2.系统确认用户选择的体检套餐与体检项目符合要求（参见规则UC_KD_01);
3.系统保存并打印体检单。
备选（扩展）事件流：
la.参与者或系统确认用户没有预约
lal.参与者输入用户基本信息，并根据用户选择输入体检套餐与体检项目信息。
lb.系统发现有多个可能重名的预约用户
lbl.系统显示出所有可能重名的预约用户，并显示区分身份的主要信息；
lb2.参与者从中选择符合的预约用户，并从相应的预约单中调出数据。
2a.用户选择的体检套餐不符合要求
2al.系统给出具体的提示信息，并且阻止参与者完成体检单。异常事件流：
3a.系统保存或打印失败
3al.系统仍然显示信息录入界面，并提示失败原因。
3b.用户发现打印失败
3bl.系统已退出信息录入界面，参与者可切换到历史体检单界面，重新打印已保存的体检单。
得到事件流的初步脉络：
1.确认用户已经预约，并从预约单中获取体检套餐与体检项目；
2.系统确认用户选择的体检套餐与体检项目符合要求；
3.系统保存并打印体检单。
备选（扩展）事件流:
la.用户没有预约
lal.参与者根据用户选择输入体检套餐与体检项目信息。
注：事件流也可以通过活动图（不带泳道，或者只包括参与者和系统两个泳道）来表示；但对于本用例而言，事件流中的内容较多，但分支、循环结构并不复杂，因此更适合采用这种结构化文本，而无须采用活动图。
3.相关需求
相关需求包括两个方面：一个是用户的原始需求；另一个是需求人员发现难以归纳到用例事件流中的功能点。前者可选，只是作为需求跟踪的方便；后者如果存在，建议一定不要省略，否则需求将是不完整的。
例如下面就是一些可能的原始需求：
•通过输入预约号或用户姓名可以查询是否预约，如果有重名则应该都显示；
•体检者选择的体检项目若属于已选择的体检套餐，则应提示并说明对应套餐;
•如果发现打印出来的体检单不清晰，系统能够支持重新打印。
而相关功能点是难以合并到用例事件流中的，它可能源于用户原始需求，也可能是需求人员通过分析添加上去的：
•体检单打印时使用Excel作为模板，模板文件可管理。
•当体检者选择出多个体检项目时，系统能够自动给出体检套餐建议。
4.用户界面原型
首先应该考虑用户界面原型中的交互过程。根据前面的事件流描述，我们决定采用5个窗口（每个窗口用一个状态来表示）来支持用户的操作。
•历史体检单页面：显示已生成的历史体检单信息，在开单工作开始之前将在该页面中（该页面同时是“返回报告”用例的基础，选中历史体检单，点击打印报告……）。
•预约判断界面：用来输入预约信息，实现预约单的选择与调取。
•体检单生成界面：用来录入与验证体检单信息。
•打印页面：提供打印预览窗口。
•失败提示页面：可能包括多个，显示错误信息，帮助用户提供操作。
可以为每个窗口进一步创建更加细节的界面说明，其内容不仅包括界面上的元素，还应该有一些相应的说明。如下图就是针对“预约判断界面”的界面原型描述。
5.规则与约束
规则与约束是仅针对该用例的行为规则、结构规则、界面规则以及设计约束。以下就是针对该用例的部分规则与约束的示例。
体检业务周期统计报表用例分析
报表类的用例不太适合采用用例规格描述模板，可采用自定义格式。应该包括以下内容：
•报表名称：说明报表作用概述性名称，也是报表型用例的名称；在此是“体检业务周期统计报表”。
•报表概述（Why)：可以从报表类型概述的基础上引用和补充，具体包括：
>用户的部门与职位：对于本用例而言，用户包括体检科室主任、分管体检业务的副院长。
>用户的业务意图：对于本用例而言，通过该报表来了解在指定时间周期内，各类体检业务的总量以 及分布情况。
>相关场景与频率：每天下班、每周末、每月结束都肯定会执行一次，在平时也可能做多次查询。
报表内容（What)：涉及的数据实体以及相关的数据字段，具体包括：
>领域类图：这些数据是根据体检单、体检项目和体检套餐来统计的，也就是其关联的数据实体。
>数据项：对于本报表而言，主要的数据项见下表。
>计算公式：报表中派生数据的计算方法，对于本用例而言派生属性有两个，其中申请次数=统计周期内体检单中出现的次数总数；实际次数=申请次数+作为套餐项目出现的次数总和。
•输入/输出格式（How)：在屏幕、打印纸上的展现形式，通常会以示意图的形式出现。
•其他：与报表实现相关的其他信息。
>排序顺序：可按体检项目、申请次数、实际次数升/降序排列。
>挑选标准：所有列入统计的都是在指定周期内完成的体检单。
>自动运行详细信息：每天晚上19:00、每周六上午8:00、每月末晚上19:00自动生成日报、周报、月报，发送到指定用户邮箱中。
>总计级别：按每个类型分类小计，全部再做总计。
>换页级别：每页不超过15条，超过部分分页显示。
>其他：另外还可能加入关于报表安全和隐私、统一的报表布局要求（包括Logo、页眉页脚、日期与时间、参数、接收者、保密程度、页码格式）等信息。
③填充领域类细节
领域类从数据窗口、组成与格式、派生数据的计算方法等方面进行描述。下面就以领域类“预约单”为例，说明领域类细节的填充过程与最终的产物。
•数据窗口分析：
类名称：预约单
别名：预约信息
涉及主题域：
>客服管理子系统：体检者预约事件
>体检业务管理子系统：体检者申请体检事件
数据窗口分析：根据前面的分析，可以确定须创建两个数据窗口，并抽取出公共的数据窗口。
•数据组成与格式分析
体检者ID：指向体检者实体，预约单中不保存其详细信息；其格式参见领域类“体检者”。
销售人员ID：指向该预约工作的销售人员，预约单中不保存其详细信息；其格式参见领域类“销售人员”。
预约时间：Data格式，记录客户可能到医院体检的时间（具体哪一天）。
预约项目：记录预约者选择的体检套餐和体检项目，以子表的形式记录体检套餐和体检项目的编号；其编号规则参见领域类“体检套餐”和“体检项目”。
④填充需求规格说明
通过以上这些分析，就可以完成需求细节的填充，同时将其填充到软件需求规格说明书中。
链接：https://pan.baidu.com/s/1Pc0v6emlO1LxC6yHib33lw
提取码：dje3
承接上文“软件需求最佳实践笔记 | 需求分析与建模（二）”
四、其他需求分析
从需求的角度来说，接口描述重点从使用者、内容与格式、设计约束与要求三个方面展开：
①使用者
使用者名称：罗列出该接口的外部使用者，通常是外部系统、其他主题域。
业务目的：说明使用者将通过该接口实现什么样的业务意图。
使用时机：说明使用者将在什么场景中调用该接口。
使用频率：描述各类使用者调用该接口的频率。
②内容与格式
交互过程说明：在调用接口时，数据的传输方向、顺序信息。
数据包说明：对前面标识出来的各次数据传输的内容与格式做进一步说明，内容包括什么属性、每个属性的格式、长度等信息。
注：在这个阶段通常是不会确定协议格式的，只是从数据构成的角度描述，除非协议格式已经是确定。
③设计约束
接口实现时须考虑约束条件或者必须满足的设计要求，内容很广泛，根据项目的不同可能包括不同的内容。例如：
协议格式要求：数据包必须采用TCP格式，数据交换必须以库交换实现，数据包协议必须符合8583规范都是相关的例子。
性能要求：如“接口调用必须在3秒内完成应答”。
环境限制：如“使用者可能通过Internet访问接口”。
④示例
以体检业务管理子系统中的“查询团队体检完成情况”接口为例，说明具体的产物。
链接：https://pan.baidu.com/s/1EK6b1NTD3HeGVXRd-0vQyA
提取码：oftz
包括性能、维护性、可移植性、安全、可靠、易用等。
对于“非技术因素决定的技术选型”建议采用表格法表示，“预期的使用环境”建议用条目化文本表示，而对于“预期的软硬件环境”则适用于部署图表示。
①部署图基础
•节点
代表一类运行时的计算资源，如一类服务器、一类工作站等设备。在UML中，节点是用一个带节点类型和名称的立方体表示的。
•连接
节点之间最常见的关系就是关联关系（用一根实线表示），在部署图中，我们称之为“连接”，表示两个节点之间的物理连接。
注：对于连接不仅要罗列出使用的协议，如果使用了特定的网络端口也应该标出，因为在实际的部署中可能会因为防火墙禁用了该端口而导致系统无法正常使用。
需求分析与建模小结
这套方法的核心就是从“事、物、人、接口”4个主线着手，沿着业务的脉络（业务主题域->业务事件/流程->业务活动->业务步骤）进行有机的分解、建模（构件->流程图/包->用例->事件流），实现定向的需求分析，提供了一种演化需求规格说明的具体方法。
一、需求描述的风格与格式
常见的描述风格与选用标准包括自然语言描述、图形化模型描述、形式化规格描述三种。
自然语言为主，辅之以图形化模型，需要的地方少量使用形式化规格描述：这是现在最常见的组合形式，对于绝大多数信息系统、软件产品而言都是十分适合的方法。
图形化模型为主，辅之以自然语言作为补充，需要的地方少量使用形式化规格描述：是RUP所推荐的方法，项目团队对模型标准有较高的认识时可以考虑这种方法，它在需求管理方面会更加方便一些，但出现交流障碍的可能性更高，特别是和最终用户代表的交流。
以形式化规格语言为主，辅之以图形化模型，以自然语言为补充：适用于质量要求很高的领域，例如航天、军工中的一些重要项目。
国标/ISO 1998版链接：https://pan.baidu.com/s/1ex19jp_yG7wP-6BQtC1icw
提取码：hxkw
国标/ISO 2006版链接：https://pan.baidu.com/s/1a74ENPJRnBwan94Unkht3A
提取码：mbl2
RUP版本链接：https://pan.baidu.com/s/1D05u3XgniDjbdhZcv1-DXQ
提取码：iwgu
咨询商版本链接：https://pan.baidu.com/s/1QpKsdEwdV1j3JnM8Ov0vsw
提取码：juxk
SERU版本链接：https://pan.baidu.com/s/1Q4Aztb6sxv8zLdlb-kJOkA
提取码：f1o9
下表为SERU需求规格说明书的演化过程：
①用户需求说明书
用户需求说明书就是用户对需求的说明与介绍，它的特点是更加面向业务，存在零散、可能相互矛盾等问题。因此通常不会称之为“用户需求规格说明书”，而是称之为“用户需求说明书”，也就是强调了达不到“契约”的等级。根据CMMI的描述，客户需求是通过采集项目相关人员的需要、期望、限制和接口，对其加以解释并转换而成的；而产品需求则是对客户需求进行提炼和细化而成的。
何时需要用户需求说明书呢？
用户方有专门的需求团队或人员：此时通常会让用户方的需求团队或人员先整理需求，提交的产物就是“用户需求说明书”。
开发方拥有自有的产品体系：此时通常会先按用户的视角整理需求，然后再根据自有产品体系分析需求，形成正式的“产品需求”。
直接与用户交流的需求团队更偏向业务能力，这时可以由直接与用户交流的需求团队整理“用户需求说明书”，然后由具有一定技术能力的需求团队进行分析、建模，形成“软件需求规格说明书。
②从用户需求到软件需求规格
引入“用户需求说明书”这一文档时，定义其内容与格式必须考虑两个方面：一是与软件需求规格说明书之间的连贯性：用户需求说明书中的内容最终将成为软件需求规格说明书的来源，因此在定义内容与格式时要考虑这个因素，通常都将是其一个子集。二是写作者的背景：通常用户需求说明书是由偏业务背景的人员负责编写的，因此写什么、写到什么程度、以什么形式，必须考虑到实际操作的可能性。
二、写作策略与技巧
①非文字信息的缺乏导致信息的丢失
如果你看到“你好啊”三个字，你会想到什么？也许绝大多数的人都会认同这是一个问候语吧！但如果你看到“你好啊！！”三个字时，又会想到什么？由于后面很不寻常地添加了两个感叹号，大家也许就会开始怀疑这可能不是问候语了。如果有人很生硬地说到“你——好啊！！”，至少没有人会认为这是一个问候语了，添加了声音之后信息必将更加完整。如果大家看到了这样的画面：“一个牧羊童，看到一只狼闯进了他的羊圈，于是举起柴刀向狼冲过去，并在嘴里喊着这句话”，我想不再会有歧义发生了吧。
②读者无心，听着有意
**我.**没说甲偷了我的钱：有人说甲偷了钱，你辩解不是自己说的。
我没说.甲偷了我的钱：强调的不是你说的，但被偷了是事实，也怀疑是甲干的。
我没说**甲.**偷了我的钱：强调你不怀疑是甲干的，但也表明你的确说过有人偷了你的钱。
我没说甲**偷.**了我的钱：强调的是甲不是偷了我的钱，而是借的、拿的。
我没说甲偷了**我.**的钱：强调偷的不是我的钱，但表明你的确说过甲偷钱了。
我没说甲偷了我的钱：强调偷的不是钱，但表明你的确说过甲偷了你的东西。
因此，在写作时尽可能采用一些强调信息的标注是很有意义的，同时注意语言环境、组织结构都是缓解这些问题的方法。
①简洁、段落文字少：不要采用长篇大论的方法，段落越长，读者压力越大，产生歧义的可能性也就越大。
②列表、图表相结合的表示法：要想避免出现长段落，最简单的方法就是通过分解成子需求列表的方法转换成一系列短句。
需求描述片段举例
假如你是一个木匠，比人我要你做一个这样的东西：“一块木板，下面钉两个木桩”，你会问我什么？
如果你想问的是：木板多宽、多厚、多长，桩是什么形状的、多大，钉在什么位置、怎么钉？那么可以断定你是技术背景出身。实际上这样发问是解决不了问题的，一方面你问不完全，另一方面被问人可能根本回答不上，即使回答上了也很难保证不改变。
那么应该怎么问呢？有经验的木匠就会问：“你想干什么？”我指着一盆花说：“用来放这盆花”，木匠就一定能够做出我满意的东西来。
“一块木板，下面钉两个木粧”是What，“用来放这盆花”是Why，“木板多宽、多厚、多长，桩是什么形状的、多大，钉在什么位置、怎么钉？”是How。不难发现，最有效的需求传达并不是讲How，而是说Why。
注：项目实践中，用户往往根据自己的经验提出解决方案，即How，这个方案不一定是最佳方案，所以一定要多问Why。
What – Why – How之间的关系
分析下面这个需求示例：
需求的What是“系统在酒店图上显示空闲的客房”，如果向开发团队传递的信息只有这些，那么开发出来的可能就是一个无法放大、缩小，没有平移功能的静态平面图，毕竟开发团队会“适度”地压缩需求。
如果平面图上的标识酒店房间号的文字看不清楚时，用户会提出什么需求？对的，需要能够放大、缩小。
当需求人员把这个变更告诉开发人员时，开发人员一定会心有怨言，心想“你为什么不早说呢？”
而当开发人员交付这个功能之后，用户马上会提出新的变更，那就需要增加平移功能，只放大、缩小是无法有效“找出相邻客房”的。而你再提出变更时，开发人员也许就会忍不住发牢骚了：“你为什么不一次说清楚呢！”可是能说清楚吗？
如果一开始就告诉开发人员，要实现“系统在酒店图上显示空闲的客房”功能的原因是“客人要求相邻的客房”（Why）时用户很麻烦，那么这些变更可能根本不会出现，因为开发人员有可能：
•预防了变更：将字体变大，使酒店每一层的图在一屏中可清楚地显示出来，用户不会产生不便，从而避免了“增加缩放、平移”功能的变更。
•预见了变更：了解了其原因之后，这些功能能够预见到，事先开发出来了。
•避免了变更：有些开发人员就会提出更合理的解决方法，“不就是要相邻的房间吗？不用搞得这么复杂，当用户选择一间房间后，提供一个下拉列表，显示出所有相邻的客房！”这显然是一个用户喜欢、开发人员高兴的解决方案。
注：需求的How没说清楚时，要反思是不是Why没说清楚，因为需求人员（包括用户代表）并不是解决方案的最佳决策者，他们在解决方案域的知识、经验缺乏也是变更的来源之一。
两类措辞是最容易产生歧义的，一类是定性的词语，另一类是描述数据的词语。
①尽可能减少使用定性词语
定性的词语也就意味着不确定，例如“系统应该对数据验证提供有效的支持”、“两个模块之间存在依赖关系”等，都有很大歧义：
•有效：什么称为有效的支持，具体表现在什么方面？
•依赖：什么样的依赖，流程依赖、数据依赖，还是其他依赖关系？
编写非功能需求时，经常会用到定性的词语，因为定量描述很难做到；建议先采用“场景化描述”，然后再过渡到“定量描述”。
场景化描述就是使用相关场景描述来替代定性的非功能需求。如，写可靠性时，不写“高可靠性”，而是写“需要提供7X24小时不间断的服务”、“需要提供5X8小时的服务”；在描述易用性时，不写“高易用性”，而是写“符合只达到计算机一级水平的用户的操作习惯”等。用户的操作习惯”等。
一些重要的非功能需求，可以从以下两个方面定量描述：
•选取指标：为关注的非功能需求选择相应的指标，易用性、可靠性都不可能用数字表示，因此要选择诸如“每窗体平均逗留时间”、“平均无故障时间”等指标来描述。
•积累经验值：为选择的指标积累经验数据，对已开发、实施的系统进行数据采样，建立相应的历史数据，这样团队才能够掌握该度量单位。
②避免使用描述数据的词语
另一类容易产生歧义的是对数据规则进行描述的词语，如：在……之间、但不包括，大于但不等于：这些都容易产生疏忽，因此我们应该改为使用数据表达式来说明。下面是两个修改过的例子。
•当前库存量包括领取人本身的实际库存和其下属的实际库存：改为“当前库存量=领取人本身的实际库存+其下属的实际库存”。
•假如话单A跟话单B的主叫跟被叫都相同：改为“话单A主叫 = 话单B主叫 And 话单A被叫 = 话单B被叫”。
一、需求验证的主要手段
需求验证是需求开发的最后一个环节，它是一个质量关。其目标是发现尽可能多的错误，减少因为需求的错误而带来的工作量浪费。而需求验证的主要手段就是Review(复查，也常译为评审）。但是许多需求团队都觉得需求验证比较容易变得“务虚”，收效很少，本文的目标就是帮助大家缓解这个问题。
在KarlE.Wiegers所著的《软件同级评审》一书中，根据评审的正式化程度将其分成了6个等级。
3种相对正式的评审特点如下：
3种相对不正式的评审的特点：
审查是企业级的评审，其过程由规划、准备、会议、返工、跟踪一系列活动组成，输入是初始工作产品，输出为完成基线的产品。
①规划
规划内容、规划人员，即谁参加？评审什么？
需求相关的评审会议，参加的人员主要包括以下几种角色：
•需求规格说明书的作者、同级伙伴
•提供规格说明信息的人：分析员、客户
•要根据规格书开展工作的人：开发人员、测试人员……
•负责相关接口工作的人
而在需求评审会议中，主要的角色有主持人、作者、读者（也就是评审者）、记录员，一般来说评审者不宜超过6个（也就是除了主持人、作者、记录员之外），否则容易使评审会过于发散，难以控制。另一方面则是需要规划内容，通常不建议一次对整个需求规格说明书进行评审，应该做适当的分解。
②总体会议
在召开正式的评审会议之前，召集参加评审会议的所有成员开一个简短的会议，讨论、明确要评审的内容、评审的要点、评审时所需的资料、缺陷检查表。
③准备
审会的效果好不好，关键在于评审者是否提前做了阅读、做了准备，要想让大家在现场提出有价值的、完整的建议是不可能的。因此，应该为每位评审者提供完整的参考资料，提供一些时间，预先阅读、查找错误。同时，要求所有的评审者将阅读时发现的文字、版面类的错误直接发给作者，不要让这些东西浪费评审会的时间。
④审查会议
准备阶段的目标是发现问题，召开审查会议的目标是暴露问题、讨论问题，大家对预先找到的问题，逐一讨论，给出结论。在审查之前，待审查的文档应该符合以下几点要求：
•文档遵循标准模板：统一的模板能够易于阅读、评审；
•文档已经进行了拼写检查：也就是尽可能减少文字错误带来的问题；
•作者已经检查了版面上的错误：这也是为了尽可能减少对评审者产生干扰；
•所有未解决的问题应该做好标记：避免大家花精力找出那些本来就没搞清楚的地方。
⑤返工
这一步骤是评审活动中经常被忽略。评审活动直接目标是找出需求规格说明书中的问题，但更有价值、更有意义的是解决问题，并且避免它。
解决问题：对提出的问题是否解决进行跟踪、督促；
避免问题出现：对所有的问题都进行分类、因果分析，找到出现这些问题的深层次原因。
二、需求验证的主要误区与解决方案
①思想
由于Review被翻译成“评审”，导致很多人将其与中国人常说的评审相混淆。中国人常说的评审是评价，而Review应该是复查，是发现问题。这一点，须成为所有组织、参加需求评审会的人员都应该建立的统一认识。
②方法
东西方文化上的差异：西方人：AllOpen,ButDeny，也就是先是全开放、都是朋友，而遇到不诚信之类的现象后，就将其Deny掉（拒绝）；东方人：AllDeny,ButOpen，也就是先是防备心很重，轻易不是朋友，真到通过一系列的事之后才会Open(开放）友谊。
中国人通常是不太愿意接受“当面指出问题”的这种沟通方式的，更不要说在“众目睽睽”之下被人指出问题。
所以，需要注重建立评审文化，采用正式化程度较低的评审手段（即时评审、同级桌查）。
③语言
东方人通常不是一个好的、积极的“被评审者”，还经常不是一个好的、有效的“评审者”。不良的语言习惯是破坏评审会气氛的一大杀手，因为你一不小心变成了高高在上的“评价者”。同样一个意思，换一种表达方式，效果会更好。
④人员
要点在于合适，而不是越多越好。包括三个方面的要点：
同级：在CMM/CMMI中提到的是PeerReview，Peer就是同级，不要一开评审会就请高阶领导。很多人连“当着别人面被指出问题”都受不了，更何况是当着领导的面。
该来的人要请：评审内容所涉及的第一责任人，一定请他们参加。
不该来的人不要请：也就是评审不是越多人参加越好，通常应该保持比较小的范围，要直接相关的人员参与；一方面可以保证参与者对评审内容熟悉，另一方面也可以保证参与者关心评审过程。
⑤内容
评审时要确保评审内容、缺陷检查表的规模适合，内容应该按每小时30〜40页的速度来准备，缺陷检查表尽量在9条之内。
①评审会上，上面开大会、下面开小会
在评审会的进程中，经常出现部分参与者交头接耳，讨论一些与评审会没有直接关系或联系不紧密的话题，对会议气氛和进程产生了很明显的影响。
出现这种现象，有一半的责任是主持人的！原因就是在评审会中安排了一些与会议主题、内容关注度不高的人。
解决建议是按照评审者关注的内容拆分分场，与其大家聚在一起讨论，还不如分主题、分场次、分人员进行周期更短的评审会。
②评审会成了审判会
在评审会中，大家对作者提出了很多的批评，做了不少负面的评价，作者的处境就像是“受审”一样，带来了很大的挫折感，从而对评审产生了抵制。
出现原因是在评审会中，所有的评审者以“评价者”的角色以较生硬的语气给出意见，并且作者的资历相对较浅，不敢直接提出反对意见。
解决建议是让参与评审会的评审者转换为“建议者”、“协作者”的角度，改进语气、语句。这既可以通过培训评审者的方式来实现，也可以通过主持人以身作则的方法示范。
③评审会成了吵架会
在评审会中，大家对作者提出了很多的批评，做了不少负面的评价；作者忍不住就开始进行不够理智的反抗，双方可能产生争执，甚至可以升级为人之间的冲突。
出现原因是在评审会中，所有的评审者以“评价者”的角色以较生硬的语气给出意见，并且作者的资历与评审者相当、甚至有可能更高，因此将会直接提出反对意见。
解决建议是，要通过让参与评审会的评审者转换为“建议者”、“协作者”的角度，改进语气、语句。
④评审会成了语法纠错会
在评审会中，听到的很多错误都是“这个字写错了”、“这个词用得不好”、“这个段落没有缩进”……之类的语法、版面错误。最终导致所暴露的问题都是琐碎、无价值的细节。
出现原因有两个方面：一是好人主义，评审者心想“如果我提出一些真的问题，他面子上会过不去”，所以就不在会议上说大问题，只谈小问题；二是准备不足，评审者之前没有阅读，当轮到他提出建议时，只好现场找，结果就只能找到这种问题。
解决建议是，要通过让参与评审会的评审者转换为“建议者”、“协作者”的角度，改进语气、语句。
⑤评审会成了翻书会
在评审会议的过程中，提出的问题根本不按页码序，一会翻到第20页，一会又翻回第10页，整场听到很多的翻书声，甚至有不少评审者跟不上评审节奏。
出现原因是主持人准备不足，临时让大家的思绪随意地展开，导致组织不利，影响评审结果。
解决建议是，可以采用的方法应该与前面的方法结合起来，当所有评审者返回了问题之后，先按页码序进行排列，然后在会议上按顺序逐一解决；每翻过一页之前，还可以停一下，让大家现场再补充一些意见和建议。
