Uses of methodology
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

Uses of deliverables

The benefit of this methodology is that it offers a context rich model common that provides a common vocabulary for discussion in the planning phases of a cycle. This section gives an overview of how a variety of stakeholders can utilise its deliverables either in inception or elaboration, and take them forward into later phases.

Programme Planners

As each scenario and dependency model is in the context of a clear goal suggested by the use case[1], the alignment of iterations against the delivery of these will give clear and measurable benefits to the stakeholders.

This will improve the planning since cycle and iteration are conducted in a less ad-hoc manner (driven possibly by teams with conflicting needs and agendas), to a more holistic manner focussing on a set of clear objectives (or themes) for the cycle and iteration, that is executed in a logical order of dependencies.

This is done by:

1.      Review goals from use case model

2.      Identify goals that bring benefit to phase

3.      Review dependency model for the chosen goals

4.      Plan iterations in order of dependency

5.      Plan interfaces in order of dependency

 By examining figure 10 (dependency model):


Trade Management is dependent on Risk Management, Reference Data and Market Data Management interfaces


Common Interface is dependent of Trade Management interfaces

The visualization of this dependency would suggest that the development sequence, for the realization functionality in these components. In fact a further refinement due to the dependency of Trade Management on number of other components suggest that these are developed in one iteration and the others are developed in a proceeding iteration, noting interfaces first we have: 

Iteration 1:

·          Risk interface

·          Reference data interface

·          Market data interface

Iteration 2:

·          Trade interface

·          Risk functionality (architecturally critical + stubs)

·          Reference data functionality (architecturally critical + stubs)

·          Market data functionality (architecturally critical + stubs)

Iteration 3:

·          Common interfaces(s)

·          Trade functionality

·          Reference data functionality (others)

·          Market data functionality (others)

Iteration 4-6:

·          All other functionality

By following such a regime of putting interfaces first the objective of presenting demonstrable functionality to end users that meet a tangible goal is achieved in the shortest time possible, especially if the iterations are very short.

Such an approach is often difficult to do when building an enterprise as iterations are not planned coherently, and interfaces often left to last. 

Figure 24: A structured iteration plan


 Some notes:

·        Don’t need to put unchanged responsibilities on here

·        Estimates for time can be based on standard metrics that are function of complexity of responsibility, whether it is identified as new or changed, and if extending phase – standard time for doing things. Example metrics simple 1 day, medium 3 days, complex 5 days, special (needs bespoke approach). Build teams need to review and agree these.

·        Such an approach is only a start – and must be tweaked to consider testing, NFR, migration etc. This has not been shown to keep the example simple.

Component Build/Delivery Teams

Build teams can be internal, outsourced or external. It is best that representatives from these team are present in the early reviews of the enterprise models, especially when responsibilities are mapped to component use cases or analysis class responsibilities. They will have experience, especially in extending phase type projects of judging if this mapping is correct, spotting misplaced responsibilities, and challenging the estimates. It also allows them an early view of resources they need to mobilise within their teams. Since the build teams are responsible for design of their component (within the guidelines suggested by enterprise architects), the level of design activity can be planed, however it must be stressed that inappropriate early design can be dangerous.

Throughout construction the enterprise model must be updated against Baselined deliverables.

This is done by:

1.      Review static model

1.      Confirm correct assignment of responsibility

2.      Review trace of responsibility to existing analysis and design artefacts (if applicable)

3.      Review dependency model

4.      Apply metrics to estimate cost of modifying or providing realisations of new responsibilities

5.      Plan appropriate A&D activity against impacted responsibilities as defined by overall iteration plan

6.      Plan appropriate A&D activity to define new responsibilities

7.      Update scenario model with missing or erroneous responsibilities flows

8.      Review trace of interfaces to existing interfaces

9.      Plan appropriate A&D activity against impacted interfaces as defined by overall iteration plan


The architects are to review dependency models to ensure coherence to their vision of component topography. Where external systems (from GCS’s perspective) are shown, integration issues can be discussed, and the mutual responsibility agreed.

This is done by:

2.      Review dependency models

3.      Validate assignment of responsibility is appropriate against cohesion objectives

4.      Validate assignment of dependency is appropriate against coupling objectives

5.      Identify internal interfaces impacted, and update model with the interface names, if necessary adding additional ones to model

6.      Identify responsibilities on internal interfaces to support the component responsibility, and update model accordingly.

7.      Review static model

8.      Ensure static model is consistent with architectural vision

9.      Review points of integration shown in use case realisations with all impacted parties

Figure 25: Example – dependency model used to identify coupling

In this example, the architects would then decide if the highlighted coupling suggested was appropriate

Figure 26: Example – elaboration model used to identify integration points

In this example, the architects from both enterprises would review (a completed) version of the above to ensure the major integration points are well defined. Note that even if component level use cases are not adopted, the above should not be treated as a single enterprise, therefore responsibilities shown at this level, do become use cases.


The “V” model for testing should balance the scope of UAT and integration testing against the scope of enterprise scenarios. By providing these scenarios earlier, test managers can plan this activity more effectively.

Figure 27: Unravelling the “V” model

The above figure outlines the “V” model – pairing the test activity with the related development activity. Unfortunately this pairing does not usually occur at a similar stage in the lifecycle, with integration and UAT left to the end (effectively “opening” the V). With major enterprises leaving the planning of integration testing at the end can be a major reason such projects fail.

By utilising this methodology, planning for integration and UAT testing can occur almost concurrently with the development activities. Additionally by defining requirements against a components responsibility, testers can be more proactive in ensuring each component team is fulfils their responsibility in providing test data.

 This is done by:

1.      Review enterprise scenarios described in use case realisations

2.      Produce UAT test plan based on each scenario

3.      Produce integration test plan based on each scenario

4.      Review data dependencies on responsibilities on dependency model

5.      Ensure components teams plan to procure this data as part of testing activities

6.      Ensure all exceptions paths in use case realisations have been considered

7.      Plan test data for all components aginst operation signatures in component knowledge model and use case realisations

Figure 28: Example - Use case realisation model used to show component test data

Migration Planning

Migrators have similar issues to testers in that their ability to plan for transition, is often left at the last moment – again a reason for project failure. But by utilising this methodology, migration plans and migration data can be procured much earlier.

This is done by:

1.      Produce migration plan for all date identified in component knowledge model and use case realisations

Reference Data and Screens

These supplementary activities require special attention since the planning and scope of these are often poorly executed.

Screens (or a presentation layer) are shown in the end to end scenarios where they have a core responsibility,  r is the focus of the elaboration. However to show all their incidental responsibilities on each elaboration would result in contrived scenarios and loss of focus.

The portal team, as part of the inception phase must examine all these implied responsibilities and assign them to the portal in the model. This is in a similar fashion to what the architects have done to the internal interfaces.

This is done by:

1.      Review use case realisations for any implied screens

2.      Update use case realisations to show any missing screens

3.      Produce screen mock-ups or UML screen-navigation storyboards to support all these additional responsibilities

For referenced data, core data types are to be shown against the component responsible for managing them (typically this would be a core entity). These can be then planned for delivery as part of the appropriate iteration where shown in a dependency model.

Therefore planning issues of late delivery typically associated with reference data should be avoided since in most dependency models, reference data is shown as the base of the dependency chain, and will be thus planned for first, rather then last

Figure 29: Example – core data types shown in a dependency model


There has already been some discussion as to how responsibilities can either map to component level use cases or operations on analysis classes as applicable to the philosophy of the organisation. This section discusses some other uses that can occur in inception or elaboration.

Detailed component use case description.

If the component based approach is to be used, then the component level use cases should be elaborated using a standard use case template. Such descriptions should still adopt a solution independent approach, and whilst it could be argued that this is initial design, it should certainly not be treated as detailed design.

Please refer to a separate white paper on techniques for defining component level use cases: Codel Services Component Level Use case approach

Screens and reports should not be elaborated using component level use cases. Rather should be described using UML models such as user-navigation storyboards and screen mock-ups.

Interface analysis.

Interface analysis is equally as important as functional or responsibility analysis. Typically the major problems in an end-to-end enterprise will be that whilst individual functions may be correct in themselves, they don’t join up either as a result of poorly defined responsibility, or lack of understanding of interfaces. Whilst the top-down approach suggested here will mitigate this, a comprehensive interface analysis in the elaboration phases is extremely worthwhile. Whilst interfaces have been described in the dependency model, these are implicit interfaces – which just identify the name and dependency. The activity here is to specify explicit interfaces as shown in the following example:

Figure 30: Example – explicitly defined interface

In the above example, by inspecting the responsibilities of Settlement Management, component its responsibilities can be grouped for two purposes: that around the settlement run process, and that around reporting of this information. It would seem sensible then to offer two public interfaces, and thus “protect” the internal responsibilities. This way coupling points can be considerably reduced.

As a rule of thumb, consider s different explicit interface for each component dependent of the component in question – if that dependency is for a clearly different purpose.

Also the operations signatures (including input, outputs, returns, NFRs and processing logic)on these interfaces can be described, making such a model extremely rich in content.

The business

The business’s objectives are to validate the elaborations as part of the end-to-end scenarios. By being involved in this in the inception phases, this will aid them in reviewing lower level A&D artefacts in the later phases.

This is done by:

1.      Review goals from use case model

2.      Review business narrative of goal

3.      Review end-to-end scenarios – either in raw form, or customised in a PowerPoint presentation (as shown in Present the findings)


Back Next

[1] This works best if the use cases suggest an end-to-end goal

© 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: