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.


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.


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:

Example of a alternative flow in a use case


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.

About Alex Papworth

6 Responses to “Use Cases – the use case narrative”

Read below or add a comment...

  1. Love It says:

    Hello to every , for the reason that I am in fact keen of reading this weblog’s post to be updated on a regular basis.

    It contains nice information.

  2. Alex P says:


    apologies for taking so long to respond to this. In terms of failed preconditions, if they fail then, by definition, they are not precondiitons, so I would agree with your point.

    Regarding the question about when you stop documenting them, it’s an important question and I don’t believe there are many ‘official’ guidelines on this. I would suggest that you need to consider the people who read the use case and their needs which will include: business stakeholders, designers, testers, business analysts.
    I think your suggestion makes a lot of sense. However, to avoid any misunderstanding, it would be ANY use case, not just the one that preceeded the use case that is now being executed.
    (I don’t think you were suggesting this but I wanted to be crystal clear for anyone reading)

    Thanks for your contribution.


  3. Leslie says:

    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.”

    Question: Are failed preconditions described in the steps of the use case? I would say no .. because then you are describing the same requirement twice. So, if the use case doesn’t find the account holder and rejects the card, we do not need to state that as a precondition.

    For any use case, I could identify a nearly infinite number of preconditions .. going all the way back to ‘The Big Bang has occurred’. How do you know when to stop? My rule of thumb is only state preconditions that describe the state of the system as the result of another use case having been executed.

    In this example it depends upon the scope of the system.
    – if the project is only describing the customer’s interaction with the system, then there probably is no precondition.
    – if the project also has requirements for an administrators interface, then the precondition might be that the admin has set up a valid account for the customer.




  1. […] from the user’s perspective, describing how they would expect to interact with the system (see Use Cases – the use case narrative for more […]

  2. […] from the user’s perspective, describing how they would expect to interact with the system (see Use Cases – the use case narrative for more […]

Leave A Comment...