需求收集

用例：
定义部分或系统的使用方式。用例用于记录对业务运作方式的理解-业务需求建模-并指定新软件系统应能

完成什么工作-系统需求建模。
用例开始于一个参与者；之后是业务或系统，最后返回到参与者。每个用例得做用都应是参与者的价值。

当然，价值对于不同的人意味着不同的事：它可以是参与者希望获得的一些信息，参与者希望从系统上获

得的效果，金钱，购买某种商品，或者激发他们的其他事。由用例驱动，而不是按照传统路径进行，有助

于找出对象，属性和操作。
业务说明：
用例模型包含用例本身和其他一些内容。
1.参与者表（带有描述）
2.术语表
3.用例（带有描述和细节）
4.通信图（可选）
5.活动图（可选）

[1]标示业务参与者：扮演某个角色的人，部门或独立的软件系统。
例子：
助手：商店的一个员工，帮助顾客租用汽车和预约汽车型号。
顾客：为获得服务而付费的人。
会员：身份和信用已经验证的顾客。
非会员：身份和信用没有验证的顾客。
Auk:处理顾客信息预约出租的已有系统。
债务部门：处理未付费用的部门。
法律部门：处理事故的部门。
[2]编写项目术语表：
可以记录每个术语与开发阶段之间的关系。下面是可以使用的关系列表：
业务参与者：业务需求中出现的参与者
业务对象：业务需求中出现的对象
系统参与者：系统需求中出现的参与者
系统对象：系统需求中出现的对象
分析对象：分析模型中出现的对象
部署制品：在系统中部署的某个信息
设计对象：设计模型中出现的对象
设计节点：构成系统体系结构的计算机或过程
设计层：子系统的垂直部分
设计包：类的逻辑组合，用于组织开发。
[3]标示业务用例：
在尽力找出用例时，应问自己如下问题：“使这个业务运转起来的重要活动是什么？”
业务用例表：
B1:顾客租用汽车：顾客租用从可用汽车中选择出来的汽车。
B2:会员预约汽车型号：当有该型号的汽车时，会员应得到通知。
。。。
业务建模中，我们对新系统的运作方式不感兴趣。只是尽力描述业务当前运作的方式。
编号模式是任意的：UML没有指定该模式，列表也没有隐含顺序。一旦有了候选得用例列表，就可以列出

每个用例涉及的步骤。可以自由使用自然语言，一步步描述，结构化语言。
例如：
B3:非会员预约汽车型号。
1.非会员告诉助手要预约的汽车型号。
2.助手再Auk中查找该汽车型号。
3.助手请求非会员为预约交纳押金。
4.助手请求非会员提供驾照和电话号码。
5.助手检查非会员的驾照。
6.如果驾照没有问题，助手就会创建新的预约，并纪录驾照号码，电话号码，在Auk中描述驾照。
7.助手给非会员一个预约卡，其中包含唯一的预约号。
[4]在通信图中演示用例
通信图显示了参与者和对象之间的一系列交互。
[5]在活动图中演示用例

系统用例模型包括：
参与者表（带有描述）
用例列表（带有描述）
用例图
用例细节（包括所有相关的非功能需求）
用例调查
辅助需求（不符合任何用例的系统需求）
用户界面草图
改进的术语表
用例的优先级

用例的关系：
特殊化，包含，扩展

特殊化：用例也可以相互继承。
包含：如果第一个用例有一些第二个用例提供的得步骤，该用例就包含第二个用例。
扩展：第一个用例给第二个用例增加步骤。
包含关系和扩展关系有一个根本区别：在包含关系中，源用例没有目的用例就不能工作，而在扩展关系中

，原用例即使没有目的用例也能工做得很好。

系统用例的细节：
用例号和标题
用例是否为抽象的
与其他用例的关系
前提条件（在执行用例之前必须满足的条件）
步骤（假定满足了前提条件）
后置条件（在完成用例后保证满足的条件）
异常路经合在这些情况下应做什么
与这个用例相关的非功能需求

前提条件，后置条件和继承
1.当一个用例特殊化另一个用立时，会继承父用例的前提条件，作为起点。子用例添加的新前提条件只能

弱化继承的前提条件（使用or合并）
2.对于后置条件，子用例的起点是父用例的后置条件，子用例添加的信后置条件只能强化继承的后置条件

（使用and合并）
3.子用例添加的前提条件和后置条件对父用例的前提条件和后置条件没有影响。

辅助需求：
不适合任何用例的非功能需求可以记录在辅助需求文档中。