Home Business Change Analysis & Design Agile Testing Templates About us

Problem Statement
What are they


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”


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

bulletDo ensure that all structural, rule or static terms are elaborated in  a use case realisation
bulletDo not refer to design domain artefacts in the RULES, but either relate to business logic or the characteristics of the information being captured
bulletDo 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.
bulletDo 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.
bulletDo 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: