As stated in the previous
section, the use case flow is by it self not sufficient to allow build
teams enough unambiguous information to provide stable designs. Use case
realisations can provide this.
The focus is on static elements described in
the flow, identifying:
 | Their informational characteristics (described in logical
terms, its type and what is mandatory or otherwise) |
| Their behaviour |
| (optionally) How they relate to one another |
| (optionally) Any standard values |
| (optionally) Any state |
The designer can use this
information to construct their design models, and in the case of component
specifications, describe inter component messages.
However, like the use case
itself these artefacts:
| Must not be design (or implementation) but an analysis
artefact. |
| Be tailored to the expectations of the build community |
| Be reviewable by non-technical stakeholders (e.g. business
users) |
It is for this reason,
careful choice is required as to how use case realisations are described,
especially for the more structured and rigorous options - since for these
the temptation to stray into design is greater.
©
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
