In many projects there is often a need for a
lightweight analysis approach and a widely accepted way of doing this
involve the use cases.
Specifying requirements involves describing both the
dynamics (i.e. interactions) of the problem and static things that this
dynamic will interact with.
Use cases are good at describing at describing the
dynamic interaction, but are structurally poor at describing these static
elements.
Analysts often compensate for this by:
Embedding the specification of static elements in
the use case themselves, which makes them unwieldy as they are not
really structured for this.
Ignoring the problem and not describing these
static elements
Over-specifying the static elements with complex
design artefacts
Uncorrected this will result in:
Unwieldy, and hard to review use cases that try to
convey too much information
Use cases that are irrelevant to future design
activities
Disconnect between static and dynamic sides of the
problem domain
Inappropriate levels of early design, often
performed analyst without the necessary experience
Late, unfocussed delivery and “Analysis paralysis”
Bespoke non-standard solutions
The solution would be:
An agile approach to use case realisation
Uses appropriate amounts of detail to describe
static elements
Fully integrates with use case
Is of use in later design activity
An approach based entirely on UML deliverables
This paper highlights an approach to how use case are
elaborated, and identifies how common pitfalls can be avoided.
It provides an example of a hypothetical trade
acceptance process that extends the example use case given
here
