[ad_1]
Use Case Description
In use cases – an introduction, it was explained how the use case, in essence, describes the interaction between an actor (or category of users) to achieve a goal of observable value.
The use case description must provide more elements than a simple sequence of user to system interactions.
The following elements constitute the bare essentials for a use case:
Name and Unique Number
The name is what appears on the accompanying use case diagram. The number or other unique reference is useful when it is being discussed. It is essential when considering requirement traceability. It can be used when cross referencing more technical design artefacts but will definitely be required when tracing through to test conditions and scripts to verify the delivery of the requirements.
Brief Description
This provides an informal, natural language description of the use case and the goal that is being satisfied. There should be no requirements or functionality in this section, all functionality should be in the main body. It can also be used in a use case catalogue which is simply a list of all the use cases and their attributes.
Preconditions
This describes what must be true at the outset of the use case. It can relate to conditions within the system or also conditions outside of the system under study. For example, when withdrawing money from an ATM from a specific bank, the customer must be an existing customer of the bank.
Basic Flow Of Events (aka Happy Path or Basic path)
This is the ‘guts’ of the use case and describes the sequence of user to system interactions and related system behaviour or rules. It is commonly referred to the primary scenario or happy path which indicates what happens where everything is straightforward with no complications. This is discussed later in this article along with alternate flows.
Alternative Flows
These describe variations when things don’t follow the ‘happy path’. This may be because it is a valid variation or it may be an exception where an error occurs which prevents the actor from achieving their goal.
Postconditions
These are things that are true at the conclusion of a use case. Traditionally, these identify things that are always true regardless of what path is taken through the use case description. If the use case has many alternate flows, there may be a whole series of possible outcomes with different post conditions that have little cross over. In some cases, it is useful to identify post conditions for the basic flow and each of the alternate flows.
[ad_2]
