Use Cases - the use case narrative

This article describes the structure of a use case in some depth and introduces other important use case concepts.

Use case narrative

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 narrative 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 (see Requirement Engineering - an Introduction for a brief discussion of this). 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. 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.

 

Other elements

There are many other possible elements that can be used within a use case. It is crucial that whenever a IT project decides to start using use cases that the template to be used is agreed and the value of each element is understood and recognised before modelling is started. There is no value in blindly following an approach hoping that it is ‘right’ as time can be wasted on populating attributes of the template that are not fully understood. There is also some degree of personal preference for which items should be included.

Two items that have not been discussed but may be required in a use case are business rules and non-functional requirements that are specific to the use case under consideration. Additional detail regarding a complex business rule can be in a separate section. Non-functional requirements such as response time can be included in the use case. Separate sections may improve readability.

These are some of the elements that I dislike and the reasons why (I would be interested in hearing other views):

Additional Notes or Notes or Special Requirements

This is very dangerous as it can conceal requirements. Firstly, the basic and alternative flows are the right places for any requirements relating to functionality. Secondly, if there are any requirements in this section, they may be ignored by the designers of the system.

Actors Primary, secondary or others

The right place for actors is on one or more use case diagrams. If they are also in the use case narrative, they will appear in two distinct places which must be kept synchronised. If the use case diagram gets out of sync with the use case narrative, it is necessary to determine whether the use case narrative or the use case diagram accurately reflects which actors invoke this use case.

There are other elements which can be useful during certain phases but become irrelevant. This would include, for example, To Do and Issues which would be relevant before the use case has been agreed by the stakeholders.

 

Basic flow and alternative flows

An example of a basic and alternate flow are shown below:

 

The basic flow describes one particular scenario or sequence of events. There will be a number of variations on this which make up the alternate flows. The basic flow is often the most common path or the typical case and the stakeholders should agree this. Agreeing the basic flow allows the stakeholders to focus on the most obvious and then move to the variations or alternate flows after the basic flow has been established.

It is quite normal for an early draft of a use case model to consist entirely of basic flows with no alternate flows detailed or described. This is helpful when trying to map out the overall scope of the system without getting distracted by the details. It allows the stakeholders to see the overall system functionality before prioritising and planning the areas to be the subject of more detailed work.

More on requirements gathering techniques that can be used alongside use case modelling can be found in - Requirements gathering alongside use cases.

Useful Links

Here are some use case templates on the web:

Template provided by TechnoSolutions (tool vendor)

Template provided by AgileModelling site

I’m not a fan of the templates that I located on the web (above) as they seem overcomplex so here’s one I created earlier - my use case template

 

Thank you for reading this article, please make comments if you have questions, disagree or wish to discuss further.