Conclusions
Before addressing the recommended option for
use case realisations, the following are to be borne to mind as the focus
of this consideration:
 |
When is the analysis team required to do
it? |
|
Is it appropriate activity to do this now
? |
o
Are we in inception phase where we want to avoid early
design
o
Are we in the construction phase where we want greater
emphasis on design
|
Does the problem require or preclude a
design focus? |
o
Is the problem domain user led (e.g. lots of interaction)
o
Is the problem technology led (e.g. STP)
|
Is this going to lead to “analysis
paralysis”? |
|
How flexible are the standards going to
be, bearing in mind that freedom of choice will increase policing cost
(and also approach D will not work if done piecemeal) |
Finally consider: is there
a simpler way of describing those extra things inferred by the use case
flow – i.e. what is “just enough”
Example
Lets assume we are in the elaboration phase of a user
led project……
It can be assumed that the sole reason for this
analysis activity is to give the designers all the information they need
to do design. To reiterate: analysis shouldn’t do design themselves, the
should let the designers do it!
However the analyst should give the designers as much
information as possible, appropriate to the current stage in the project
lifecycle. Therefore the choice of use case realisation is driven by the
maturity of the project.
The system analyst should therefore start off with
RULES, then move on to initial ACMs, through to formal ACMs. That way any
misconceptions and analysis issues can be identified and resolved early in
the lifecycle, before moving onto the more formal deliverables.
Some Do's and Don'ts
| Do ensure that all structural, rule or static terms are
elaborated in a use case realisation |
| Do not refer to design domain artefacts in the RULES, but
either relate to business logic or the characteristics of the
information being captured |
| Do use Analysis Class models (ACM) to show the interaction of
such items using robustness modelling. Entities should map to terms used
in BROM but described in logical terms. |
| Do not use contrived classes such as “XYZ Manager” – try and
use terms explicitly mentioned in the flow or if this is not possible,
ensure that the controller reflects what it is actually doing. |
| Do ensure that all structural terms either exist in the
business domain, or can be directly inferred from it. |
©
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
