Introduction

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:

	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.

Assumptions

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

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

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