Enterprise Elaboration
Home Business Change Analysis & Design Agile Testing Templates About us

Enterprise Planning
Enterprise Elaboration
Refine - Analysis Classes
Refine - Combined
Which Approach
Uses of Deliverables
Other Methodologies

Approach - Enterprise elaboration

The main purpose of elaboration, is to build on the framework set up in the planning phase.

There is a decision to make as to how the model is taken forward:


How responsibilities are assigned (at the analysis class or component level) and what is done with them.


How is the enterprise to be treated – black box or system of systems

Whilst this decision should be made on project initiation, its effects are mainly felt in the following elaboration phase.

These approaches are described in turn, firstly taking a pure component view, followed by a analysis class centric view, and finally a hybrid approach that leverages benefits from both.

Regardless as to the decision the methodology can bring real benefits, but with a slight different approach for some artefacts. This is summarised, outlining the pros and cons of each method, and when each should be considered.

Refine responsibilities – Component level approach

To first understand how a component view is taken is to understand that a responsibility on a component can be described as a use case where the system boundary is set at the component level. An initial component level use case model is relatively straightforward to produce, and has the advantage of being coherent to the end-to-end scenario.

Figure 13: Prototype use case model

Compare this model with figure 8. Since this is the inception phase it is enough to treat these as initial use cases – that is a use case model (with component scope) and brief description of the goal of the use case is enough. Where it is difficult to define its goal, the chances are that the responsibility is incorrect or too detailed.

The challenge is for the “extending phase” type projects, since there may well be a use case model already defined. In such cases this will form the baseline for the following analysis activities (assuming it is accurate – not always the case). If these use cases have a reference number, it is recommended that the responsibilities are traced to these rather than reverting back to the original name since this may not be verbose enough for our purposes. The mapping should be one-to-one, if it isn’t then the original use case model may be not as goal driven as was hoped!

Note that the use case names do not have to be the same – they are often more process orientate and thus less verbose.

Figure 14: End to end scenarios with use case references

Note that even for changed use cases, adopting some of the conventions of the initial use case may still be of benefit to show the potential impact of change.

The initial responsibility specification can then easily be converted to an initial use case description, applying any use case mappings as appropriate in the inception phase. Such specifications will then be extended in this phase.

Figure 15: “Initial” component use case description

[Changed: UC244] Apply validation rules for new products

The goal of this use case is to select and apply the appropriate validation regime to apply for the new equity products


Complexity: Low

Benefit: Medium

Initiative: New product expansion

Goal: Increase number of trades that can be accepted

It is important to understand that whenever use cases are used at the component level, they individually lose some of the end-to-end nature, so it should be demonstrated that they map to an overall end-to-end scenario. If the are self contained specification then build teams have lassitude in finding the correct design and implementation for them, they should not take a lead in their definition as the likely consequence will be use cases that do not interrelate.

Detailed component level use case descriptions – some pitfalls

In the elaboration phase these initial use case descriptions can be extended to become a full use case narrative, using any use case description template (your organisation is likely to have one)

Before considering writing component level (or white box) use cases at this level a number of potential pitfalls with them should be considered before deciding if it is the right approach to elaborating the enterprise

Firstly they can be hard to write without straying into detailed design, and their narrow scope makes them difficult to review (see separate paper on this as to how to avoid some of these issues.)

However most importantly, it is hard to produce an analysis class model to support use cases at this level. In the following neither component has a full view of trade, lets say A references it and B persists it. Trade would have to appear in both analysis class models but with different responsibilities. By fragmenting the analysis class model at a component level difficulties are introduced (again this is best at enterprise level).

Figure 16: Issues with component level use cases



Component A

Component B

Agile component level use case descriptions

If the issues described in the above section are likely to be a problem, then instead of using the standard use case description template, use cases can be described in a more logical manner.

Once the responsibilities have undergone peer review, as an optional exercise these can be enriched with additional information. Whilst such activity can be time consuming it can force a level discussion on what such responsibility actually will entail, and whether it is the appropriate place to do it.

Take for example the Trade Management responsibility from our example “Accept Trade ( )”. In order to fulfil this ask what information Trade Management requires knowledge of and posses in its own right. Something along the lines of “Swap Trade Details” would suffice. This leads to the following benefits:

bulletCorrelates to business domain model.
bulletBoon for testers in preparation of test data from end to end perspective
bulletHelps component use cases elaboration since this is either a business rule or a supplementary requirement

Trade Management in our scenario does not contain the validation rules, since the architects deemed these best managed centrally. So it does not have knowledge of these – hence the subsequent collaboration with Reference Data Repository. Our specification now becomes:

Reference Data Repository::Provision of new product structures and new instrument types(Equity Trade Details) = Valid Equity

So what is being said here, is as long as reference data repository is given the trade details, it can use its knowledge of the validation structure and return equity validation structure. This process can become very powerful, and can be an alternative to component level use cases (and still avoids being design) – but on the downside it does require a degree of modelling competence.

[Changed: UC244] Apply validation rules for new products

Preconditions: Trade Details

Postconditions: Validated Trade Details

                Failed Trade Details



IF (

    Reference Data Repository::Provision of new product    structures and new instrument types(Trade Details) == Valid Equity


    RETURN Validate Trade Details


    RETURN Trade Details

Analyse component responsibility cohesion

Of course in this contrived example it is suggesting that Trade Management is not actually having the responsibility of actually doing the validation, rather reacting to the results given to it (i.e. perhaps it Reference Data Repository should return the Trade Structures and Trade Management decide whether it is valid or not). We are having a very precise definition of responsibility that cannot easily be misunderstood, something that could happen if responsibilities were just defined on the basis of name. This is highlighted in the following two figures:

Figure 17: Poor responsibility cohesion

Figure 18: Better responsibility cohesion

This is exactly the sort of discussion that should occur early in the process since errors here can have profound and costly consequences later on.

Static model (component  knowledge model)

Following the analysis described above can lead to a clear picture of what each component needs to “know”. This can be shown diagrammatically in the following figure.

Figure 19: Component knowledge model

This static view is easily created from the models we have already – in fact it can be considered a “free” by-product of them. It gives a useful in the following ways:


Gives a complete picture of scope to the component teams


Something that will be very helpful for determining test data and migration.

Back Next

© 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