Use cases can be further
elaborated in many ways, depending on the maturity and level of
completeness required. The following section outlines these techniques, in
increasing order of complexity and maturity.
Option A. Use Action Definition
Purpose: To ensure that any information
relating to static elements is specified as part of the use case, and
elaborated in the action definition section part of the template.
: Example of flow
description
|
5.
System establishes Contextual Information associated
with the log on.
(Action
Definition: Contextual Information)
|
Example showing
the italicised terms are described, with their own section heading
|
1.1.4.
Action Definition
Contextual
Information
In authentication, the context must show:
(1)
Location of access (terminal/IP)
(2)
Time of access in GMT established from trusted time source (but
translated into local time based on that location) |
This can be seen as a
fulfilling the role of glossary and specification (which at this level is
somewhat synonymous)
Advantages
 | Simple |
| Enables use case to be self contained reviewable item |
| Plain English deters design, and promotes reviewability |
| Embedded nature reduces disjoin of static artefacts to the
dynamic flow |
Disadvantages
| Requirements can easily become obsolete and out of synch |
| Reduced visibility of requirements |
| Reuse difficult: same requirement may be described
differently in two places |
Option B. Formalised, centrally managed requirement
Purpose: To ensure that any information
relating to static elements is specified within a centrally managed
requirements database, and explicitly referenced from the appropriate
step. In addition, the requirement is traced to the use case, from this
centrally managed place.
Textual requirements are maintained in a
central, controlled place, preferably using a requirements management
tool. In presentation, a report displays all these artefacts using macros,
directly after the action definition section.
These static requirements can be managed as
uniquely identified RULES within this store. This is in conformity with
their definition in RUP. Whilst a business rule is often thought to
describe business logic, it can equally describe informational
requirements,
as well as expected values.
Extending
previous example to become
|
6.
System establishes Contextual Information associated with the
log on.
(RULE 12
Contextual Information) |
The related RULE
defined in central requirements tool
|
RULE 12
Contextual Information
In authentication, the context must show:
(1)
Location of access (terminal/IP)
(2)
Time of access in GMT established from trusted time source (but
translated into local time based on that location) |
Advantages
| Simple, yet formalised |
| Visible, can be reported on in from requirements management
tool |
| Plain English deters design, and promotes reviewability |
| Embedded reports can reduces disjoin of static artefacts to
the dynamic flow |
Disadvantages
| Difficult to analyse. |
| Wordy nature makes them difficult to keep at consistent
level, and must be therefore actively policed. |
In fact these can be rephrased as business logic. For example “a valid
order comprises of X, Y and Z”
© 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: info@codel-services.com
