1. 前言
UP开发包括四个阶段：初始阶段、细化阶段、构建阶段、移交阶段；
UP每个阶段包括 业务建模、需求、设计等科目；
其中需求科目对应的需求制品包括：设想、业务规则、用例模型、补充性规格说明、词汇表。
上章主要讨论UP初始阶段需求科目对应的制品之一---用例模型，阐述了用例模型的基本概念，使用用例的好处，用例的常用形式。
本章将用一个具体的实例进行详细分析和说明用例模型，采用用例的三种常用形式之一---详述风格来说明 处理销售 这个用例的编写。
2. 详述风格的特点
详述风格详细编写所有步骤及各种变化，同时具有补充部分。
一般在需求科目进行时用摘要形式编写了大量用例后，第一次需求讨论会上，用详述风格将编写10%的关键用例，并对这10%具有架构意义的用例或场景进行设计和编程
3. 详述风格的模板
图 Alistair Cockburn创建的详述风格的用例模型模板
上图为初始阶段为需求科目产生的用例模型制品模板，它是详述风格的，下面对这个模板的不同部分进行说明：
- 用例名称
一般用动词开始
示例：对于NextGen pos系统，用例名称为 用例UC1 处理销售
- 范围
定义了所要设计的系统，包括系统用例和业务用例
系统用例描述的对系统的使用；业务用例描述顾客和有关人员如何使用业务
示例：对于NextGen pos系统，范围为 NextGen Pos应用
- 级别
分为用户目标级别和子系统级别。
用户目标级别：是通常的级别，描述了实现主要参与者目标的场景；
子系统级别：用例描述支持用户目标所需要的子步骤，若干常规用例共享重复的子步骤，则将其分离出来，创建为子系统功能级别用例
示例：对于NextGen pos系统，级别为 用户目标
- 主要参与者
调用系统服务来完成目标的主要参与者
示例：对于NextGen pos系统，主要参与者为 收银员
- 涉众及其关注点
建议并界定了系统要完成的工作，能够让我们更加清楚的详细了解系统职责，为发现并记录所有行为需求提供彻底、系统的过程。
示例：对于NextGen pos系统， 涉众为 收银员、 售货员、顾客、公司、经理、*税收代理、支付授权服务，它们都有各自的关注点
- 前置条件
给出用例中场景开始之前必须永远为真的前提，前置条件传达的应该是能够引起读者警惕的那些值得注意的假设，而非那些不值得注意的假设
示例：对于NextGen pos系统，收银员必须经过确认和认证
- 成功保证（或后置条件）
给出用例成功结束后必须为真的事物，包括主成功场景和替代场景。该保证满足所有涉众的需求
示例：对于NextGen pos系统，成功保证为 存储销售信息，准确计算税金，更新账务和库存信息，记录提成，生成票据，记录支付授权的批准
- 主成功场景（或基本流程）
典型流程，描述了满足涉众关注点的典型成功路径，通常不包括任何条件分支。记录三种步骤：
（1）参与者之间的交互；（2）确认过程（通常由系统完成）；（3）系统完成的状态变更（例如：记录或更改某事物）
示例：对于NextGen pos系统，主成功场景为 顾客购买的整个操作流程
- 扩展（或替代流程）
是主成功场景的分支，扩展描述了其它所有场景或分支，包括成功和失败路径。通常占据了文本的大部分篇幅。
（1）扩展有两部分组成：条件和处理，尽可能使用系统或参与者能够检测到的事物作为条件；
（2）扩展处理可以针对一个步骤也可以针对多个步骤；
示例：对于NextGen pos系统，扩展为对主成功场景的特殊情况及分支的说明
- 特殊需求
与用例相关的非功能性需求、质量属性（性能、可靠性和可行性）或约束（通常对于IO设备），也有建议写入补充性规格说明书中
示例：对于NextGen pos系统，特殊需求为 使用大屏UI，90%的信用卡授权时间少于30秒等
- 技术与数据变元表
技术变元是必须如何实现系统；
数据变元，如商品编码采用哪种编码方式等。
示例：对于NextGen pos系统，技术变元表为 信用卡账户可以用读卡器或键盘输入，数据变元为 商品编码采用何种编码方式
- 发生频率
示例：对于NextGen pos系统，发生频率为 可能会不断的发生
- 未决问题
示例：对于NextGen pos系统，未决问题为 税法如何变化等