Use case

Use Case的三种格式：

 

1.       Brief

在建模的早期进行分析，快速的获得系统与用户交互的场景和视图，大约花费几分钟进行构建。

 

2.       Casual

非正式的段落格式，不同的段落涉及到不同的场景，也是早期分析阶段进行构建。

 

3.       Fully dressed

所有的场景和视图都被详细的描述，有supporting section, 前置条件等等。详细的描述用户和系统的交互步骤和可能存在的变化。

 

 

Use Case Name Definition:

 

Scope

 The system under design.

 

Level

“Summary”, "user-goal" or "sub-function"

 

Primary Actor

Calls on the system to deliver its services.

 

Stakeholders and Interests

Who cares about this use case, and what do they want?

 

Preconditions

What must be true on start, and worth telling the reader?

 

Success Guarantee

What must be true on successful completion, and worth telling the reader.

 

Main Success Scenario

A typical, unconditional happy path scenario of success.

 

Extensions

Alternate scenarios of success or failure.

 

Special Requirements

Related non-functional requirements.

 

Technology and Data Variations List

Varying I/O methods and data formats.

 

Frequency of Occurrence

Influences investigation, testing, and timing of implementation.

 

Miscellaneous

Such as open issues.

 

 这里包含了很多项目，并不是所有的项目都是必须的，去除基本项目之外，有些项目很重要，值得在Use Case中表现出来。Stakeholders and Interests实机说明的是该Use Case的优先级别，这个对项目的后期计划会产生很大的影响，尤其是迭代开发的项目。"user-goal" 说明的是该case是直接描述用户目标的，也就是描述系统与客户交互的，而"subfunction"则是为了达到"user-goal"而需要进行的子功能项。

 

 

Use Case建模的指导原则：

 

1.       早期Use Case建模避免与UI相关联：

在需求分析的早期，很多时候进行Use Case建模的时候，总是想着什么UI界面之类的，Case描述也是基于UI的，比如说log in等。这些是基于实现的描述，是达成目标的手段，而不是基于用户视角和用户目的的描述。早期的Use Case需要描述用户的目标本身，而不是实现手段。此时Use Case的描述应该强调用户最基本的动机和目的，应该避免和具体的Use Interface相关联。

 

同样，早期的Use Case建模应该避免些节，避免在早期就建立具体的Use Case模型。只关注内容，而不关注User Interface。

 

2.       建模时，使用简洁的语言：

任何时候，使用简洁的语言来描述问题都是应该被赞成的，去除那些晦涩并可能产生歧义的词语。

 

3.       基于黑盒创建Use Case

黑盒创建Use Case即不描述系统工作的中间环节，组件或者与设计相关