Use Case Realisation
Home Business Change Analysis & Design Agile Testing Templates About us

Problem Statement
What are they

Approaching Use Case Realisation 

White paper prepared by Codel Services Ltd ©

Problem Statement

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:

bulletEmbedding the specification of static elements in the use case themselves, which makes them unwieldy as they are not really structured for this.
bulletIgnoring the problem and not describing these static elements
bulletOver-specifying the static elements with complex design artefacts

Uncorrected this will result in:

bulletUnwieldy, and hard to review use cases that try to convey too much information
bulletUse cases that are irrelevant to future design activities
bulletDisconnect between static and dynamic sides of the problem domain
bulletInappropriate levels of early design, often performed analyst without the necessary experience
bulletLate, unfocussed delivery and “Analysis paralysis”
bulletBespoke non-standard solutions

The solution would be:

bulletAn agile approach to use case realisation
bulletUses appropriate amounts of detail to describe static elements
bulletFully integrates with use case
bulletIs of use in later design activity
bulletAn 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


Ó 2002-2005 Codel Services Ltd