Components of the use case description
What makes up a good use case? Use cases are very
effective at showing the dynamic nature of how the system is intended to
be used by the actor (hence the name “use case”). It can also be seen as
setting the dynamic contract between system and actor. This is done by
Use cases are not so good at describing the static
things that occur in these flows. Implicit in each flow is usually a
“thing” being acted on or referred to. This could be a business rule, some
logic, some conditionality or some information that is stored or passed
around. The challenge is to make these “things” explicit, since the
designer will need specifications around both the dynamic and static
nature of the system as part of their deliverables.
What are these “things”? These tend to be the static
element of what makes up the usage contract – typically shown as nouns in
the step of a use case (even active terms such as “validation” becomes a
noun where describe as “system applies validation rules”
They are categorised as the following:
Specification – unambiguously describing the
logical informational characteristics of the use case step – although
this should not imply a data model – it should give the designer enough
information to construct one.
Logic – describing the logic around the rules and
behaviour of the use case step
Enumeration – describing what values something can
There is of course overlap between these. A step can
have both logic and specification.
example of proliferation
Request is composed of the following information items:
Identifier of Change Request
of the temporal reference data entity.
when the change is expected to become effective.
4) Type of
Change Request which is either "Create",
example of logic
Request Command is valid if and only if the following conditions are
1) The Change Request is still in the same
state and has the same values as the command issuer refers to.
requested state change is allowed according to the Change Request
state transition model for the reference data in question.
example of enumeration
of information must be able to identify its "Approval Classification"
which indicates any requirements and restrictions concerning
methods of Approval will be classified as follows:
Entry” - No approval required
Entry + Approval” - Entry and approval must always be by different
actors in all circumstances.
There are two immediate pitfalls in their
One temptation is to elaborate what these “things”
are as part of the flow. This approach loses focus as to what the flow
is trying to show (the dynamic contract between actor and system), and
therefore makes the use case harder to read and validate.
Another pitfall is to describe minor business rules
by a proliferation of alternative flows – which is inappropriate if
actually the interaction is no different. The alternative flow should
only focus on consequences of rule, or if the rule really is a major
They are of course necessary to describe to form a
complete picture and this is the focus of the next section. The challenge
is to describe in an effective manner the static nature of the use case
flow, to complement its dynamic nature, without letting the two sides
become divorced from one another.
Although in the case of security these goals can often be the mitigation
of key, named risks.
2002-2005 Codel Services Ltd
This paper has been prepared
by Codel Services Ltd to illustrate how structured business
modelling can help your organisation. Codel Services Ltd is an IT
Consultancy specialising in business modelling. If you would like further
information, please contact us at: Deryck Brailsford, Codel Services Ltd,
Dale Hill Cottage, Kirby-Le-Soken, Essex CO13 0EN,United Kingdom.
Telephone: +44 (0)1255 862354/Mobile: + 44 (0)7710 435227/e-mail: firstname.lastname@example.org