Use case Model

     The Unified Process (UP) defined this artifact within the requirements discipline. It is a set of all written use cases. It is a model of the system’s functionality and environment.

    The Use-Case model may optionally include a UML use case diagram to show the names of use cases, and actors, and their relationships. This gives a context diagram of a system and its environment.

Types of Actors
An actor is anything with behavior, including the system under discussion (SuD) itself when it calls upon the services of other systems. Actors are not only roles played by people, but organizations, software, and machines. There are three kinds of external actors in relation to the SuD:

• Primary actor − has user goals fulfilled through using services of the SuD which drive the use cases.. For example, the cashier.
• Supporting actor − provides a service (for example, information) to the SuD. The automated payment authorization service is an example.
• Offstage actor − has an interest in the behavior of the use case, but is not primary or supporting; for example, a government tax agency.

Use Case Formats Use cases are written in different formats, depending on need. Use Cases are written in varying degrees of formality:
brief

• Succinct one-paragraph summary
• Usually the main success scenario
• Done during early requirements analysis
• Should take only a couple of minutes.
• The prior Process Sale example was brief.

casual

• Informal paragraph format.
• Multiple paragraphs covering various scenarios.
• Done during early requirements analysis.
• Should take few minutes of time.
• The prior Handle Returns example was casual.

fully dressed

• The most elaborate.
• All steps and variations are written in detail.
• Includes supporting sections, such as preconditions and success guarantees.
• Mainly done after many use cases are identified and during early requirements workshop for high-value and high-risk requirements(e.g., core architectural)

A Template for Fully Dressed Style
Various format templates are available for fully dressed use cases. The most widely used and shared template format is shown below:

Use Case Section	Comment
Use case name	Start with a verb
Level	“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
Main success scenario	A typical, unconditional happy path scenario of success.
Extensions	Alternate scenarios of success and failure.
Special requirements	Related non-functional requirements.
Technology and data variations list	Varying I/O methods and date formats
Frequency of occurrence	Influences investigation, testing, and timing of implementation.
Miscellaneous	Such as open issues

The Two-Column Variation
It was first proposed by Rebecca Wirf and Brock in and is promoted by Constantine and Lockwood to aid usability analysis and engineering.

It is also called as conversational format, which emphasizes an interaction going on between the actors and the system. Here is the same content using the two-column format:
Use Case UC1: Process Sale

Primary actor: Cashier
Main success scenario:
Actor Action(or intention)	System Responsibility
1. Customer arrives at a POS checkout with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.	4. Records each sale line item and presents item description and running total.
Cashier repeats steps 3-4 until indicates done.	5. System presents total with taxes calculated.
6. Cashier tells Customer the total, and asks for payment.
7. Customer pays.	8. Handles payment.
	9. Logs the completed sale and sends information to the external accounting and inventory systems. System presents receipt.