Introduction
Home Business Change Analysis & Design Agile Testing Templates About us

Problem Statement
Introduction
What they are
Granularity
Coupling
Flow Proliferation
Description
Dos and Don'ts
Example

Context

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:

Activity

Deliverables

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

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:

bullet

Initial use case model (UCM)

bullet

Brief description for all Component Use Cases

bullet

Main flow

bullet

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:

bullet

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

bullet

Project managers enough information to estimate and scope iterations

bullet

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.

Assumptions 

This paper assumes the following:

bullet

There is a central analysis team in place

bullet

Standards on semantics can be actively enforced.

bullet

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

bullet

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.

bullet

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: info@codel-services.com