Understanding Use Cases in Software Engineering
In software engineering, a use case is a technique for capturing potential requirements of a new system or a software update. Each use case provides one or more scenarios that show how the system should interact with the user or another system to achieve a specific goal.
Types of Use Cases
Brief Use Case
A few paragraphs of prose that usually only include the main stage for success.
Casual Use Case
Several paragraphs that contain several scenarios, but by no means all in detail.
- Name
- Main Stage, written in prose
- Some alternative scenarios, such as the behavior to errors or invalid data.
Fully Dressed Use Case
We describe the system with the highest level of detail, including the main stage and all possible scenarios derived. It represents a more schematic approach than the previous types.
It consists of:
Use Case
Name that describes the use case.
Primary Actor
It is the one who leads the system to achieve the objective (and usually the one who initiates the use case).
If not who initiates the use case, it adds a trigger section that specifies who does.
Stakeholders
Anyone who may be affected by the system. For each subject, showing the objective with the use case. Are written with capitalized letters. The Primary Actor is always interested.
There are offstage actors involved in activities such as validations. These actors should be documented, since the system must reflect and protect their interests.
Preconditions
Indicate situations that are always given before the commencement of the use case. They are always true and are written with affirmative sentences.
Success Guarantees
Indicate goals we are satisfied when running any scenario, besides the principal, that lead to success. Sentences are written in the affirmative.
Minimum Guarantees
These are the guarantees that the system promises to stakeholders, both on success and failure. It is optional and can be collected in the exceptions.
Main Success Scenario
Describe the sequence of successful steps that occur in the most common use case. It does not include conditions or branches. It consists of simple sentences (subject + verb + CD) and assertive (avoid if).
The steps are of three types: System and Interaction of Actors, validation or verification (performed by the system) and change of state of the system.
Extensions
These are the conditions that cause the system to behave differently.
They are usually numbered referencing the step or steps of the main stage where the change occurred in flow, followed by a letter that separates the alternatives. The first line indicates the condition which causes the flow is directed to this extension. For an extension is applied in all steps of the main stage is marked with an asterisk.
Technology Variations
They include, in simple (single line), some variations that may occur during the main event. For example, you can specify the types of input/output available
- The clerk records the producer
2a. The clerk enters the product code
2b. The clerk passes the product by the barcode reader.
Level
There are three levels of use cases:
- User goals: identify a task performed by a person in a certain place and time, in response to an event and adding business value.
- Subfunction: complete other use cases, making it easier to read and understand. Do not get to meet a real need of the user. For example, a use case to identify the system or pay by card.
- Summary: collect several user objectives. They are the highest-level cases and can run for long periods of time. Refer to more specific use cases. For example: Operation of a bank, consisting of use cases to deposit money, withdraw money, ask for loan, etc.