A good use case

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 describing:

	Preconditions
	Flows
	Interactions
	Alternatives/Exceptions

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 take

There is of course overlap between these. A step can have both logic and specification.

example of proliferation

A Change Request is composed of the following information items:

1) Identifier of Change Request

2) Identify of the temporal reference data entity.

3) Timestamp when the change is expected to become effective.

4) Type of Change Request which is either "Create",

...

example of logic

The Change Request Command is valid if and only if the following conditions are satisfied:

1) The Change Request is still in the same state and has the same values as the command issuer refers to.

2) The requested state change is allowed according to the Change Request state transition model for the reference data in question.

example of enumeration

All sources of information must be able to identify its "Approval Classification" which indicates any requirements and restrictions concerning approval.

These methods of Approval will be classified as follows:

1) “Single Entry” - No approval required

2) “Single Entry + Approval” - Entry and approval must always be by different actors in all circumstances.

...

There are two immediate pitfalls in their description:

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

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.

[1] Although in the case of security these goals can often be the mitigation of key, named risks.

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: info@codel-services.com