Home Business Change Analysis & Design Agile Testing Templates About us

Problem Statement
What they are
Flow Proliferation
Dos and Don'ts


The following figure outlines where the system analysis activity described in this paper fits into the overall software engineering process:


Referencing the above figure it can be seen that it is part of system analysis that takes “Black-box” Use Case to “White box” or Component Use Cases, and from Component Use Cases to Component Use Case realisations. The objective of each activity is to pass on a baselined set of deliverables as described below:



Stakeholder needs

Product Vision

Black box Use Cases

Use case model, Use case description, Business Rules

Black box Use Cases Realisations

Enterprise scenarios, dependence models, interface specifications

White Box/ Component Use Case

Component Use Case model, Component Use Case descriptions, Design and Implementation notes

Component Use Case Realisations

Business Rules, Analysis Class Model


Design Class Model, User Experience Model

Note that this process is not waterfall. In the system analysis domain, the baseline of each iteration will have artefacts of varying levels of maturity. For Component Use Cases the levels of maturity are as follows:


Initial use case model (UCM)


Brief description for all Component Use Cases


Main flow


Alternative flow

Analysis vs. Design

Before any consideration as to the nature of the deliverables, the role of the team setting these must be understood. RUP sets a fuzzy boundary between analysis and design, so fundamentally: is the team to be involved in analysis or design or both?

It is clear that the analysis team’s role should purely be systems analysis. This is because build teams are responsible for delivery, and design is more closely aligned to that activity. Therefore this paper suggests the existence of a centralised analysis team focussed solely on setting a consistent programme wide analysis vision, and whose key customer is the build team.

The deliverables of such a team should be such as to give the:


Development teams enough information for them to design, and subsequently build.


Project managers enough information to estimate and scope iterations


Testers enough information to identify enterprise tests

By separating analysis and design this avoids the pitfall of premature design.

The terms “analysis” and “design” are often blurred. For the purposes of this paper system analysis is technology independent, whereas design is technology dependent.


This paper assumes the following:


There is a central analysis team in place


Standards on semantics can be actively enforced.


Only the analysis team is able to define and update the Component Use Cases and associated analysis artefacts.


Maintenance, as part of an iterative approach a 30% overhead (as compared to overall analysis overhead) to keep Component Use Cases up-to date throughout the cycle is not unrealistic.


Detailed design is the responsibility of the build team

 Back Next

[1] Although in the case of security these goals can often be the mitigation of key, named risks.

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