需求分析与用例

一、需求分析与用例：
需求：就是系统必须提供的能力和必须遵从的条件，包括：功能需求和非功能的需求（性能要求）。
需求分析：重要手段是确定和编写用例。

用例：是文本形式的情节描述，用于需求的发现和记录。用例会影响后续的OOA/D工作。

• 参与者（Actor）：某些具有行为的事物，可以是人（由角色标识）、计算机系统或组织，例如收银员。
• 场景（Scenario）：是参与者和系统（我们要开发的系统）之间的一系列特定的活动和交互。包括主成功场景和交替场景（主成功场景表示正常功能….；交替场景是如果….）
• 系统边界：

二、用例的目的与形式：
用例编写的形式：

• 摘要—需求分析早期使用，通常用于主成功场景（如上方描述的“管理员向系统提交用户名和密码。系统进行认证。系统向管理员显示功能登录信息”）
• 非正式—需求分析早期使用，可覆盖不同的场景
• 详述—详细编写所有步骤及各种变化（见用例文档）

　　Tip1:用命的名称应使用动词开头（动词或动词+名词）
　　Tip2:编写用命的时候应尽量使用行业的专业名称，而不是计算机专业术语。因为用例是跟用户沟通的重要文档，所以从用户的观点编写用例。

三、用例编写的格式：

• 用例编号
• 用命名
• 用命描述
• 参与者
• 前置条件 //必须满足条件
• 后置条件 //用例做完后，对系统的影响
• 基本路径 //最重要，主功能场景，只描述正常成功的场景，不要出现如果….;参与者动作，系统响应
• 扩展点 //最重要，
• 补充说明 //对基本路径和扩展点的未尽事宜进行描述

四、如何发现用例：

1. 选择系统边界
2.  确定主要参与者
3.  确定每个主要参与者的目标
4.  定义满足用户目标的用例，根据其目标对用例命名

　　Tip：在真实项目中发现用例，请遵循如下思维习惯：调研需求时最先弄清楚有多少部门，多少岗位（参与者），然后找到每一个岗位的业务代表，问他们类似的问题：你平时都做什么？（参与者目标）这件事是谁交办的 ？做完了你需要通知或传达给认证吗？做这件事情你都需要填写些什么表格吗？

五、用例关联及一些术语
用例彼此之间可能具有联系，比如：处理信用卡支付用例可倾向于为处理销售、处理租金等常见用例的一部分。

注意：别花过多时间争论在用例图中如何关联用例，而不关注更重要的工作：编写用例文本

• 包含关系：主要目的是避免用例文本的重复编写，比如：处理销售、处理租金用例可包含处理信用卡支付用命。
• 扩展关系：可以将可选路径中的场景抽象为扩展关系（但通常都是不必要的）
• 泛化关系：两个或更多用例在行为、结构、目的等方面存在共性时，可使用泛化关系。