需求分析与用例

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

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

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

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

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

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

3、用例编写的格式：

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

4、如何发现用例：

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

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

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

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

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