The purpose of the Elaboration Phase is to analyse the problem
domain, establish a sound architectural foundation, develop the project plan,
and eliminate the highest risk elements of the project. To accomplish these
objectives requires the "mile wide and inch deep" view of the system.
Architectural decisions have to be made with an understanding of the whole
system: its scope, major functionality and non-functional requirements, such as
performance requirements. It is easy to argue that the Elaboration Phase is the
most critical of the four phases. At the end of this phase, the hard
"engineering" is considered complete and the project undergoes its most
important day of reckoning, the decision on whether or not to commit to the
production phases. While the process must always accommodate changes, the
elaboration phase activities must ensure that the architecture, requirements
and plans are stable enough, and the risks sufficiently mitigated to be able to
predictably determine the cost and schedule for the completion of the
development. Conceptually, this level of fidelity would correspond to that
necessary for an organisation to commit to a fixed price Construction Phase.
In the Elaboration Phase an executable architecture prototype is built in one or
more iterations, depending on the scope, size, risk, and novelty of the
project. This effort addresses at least the critical use cases identified in
the inception phase, which typically expose the top technical risks of the
project. While an evolutionary prototype of production-quality components is
always a goal, this does not exclude the development of one or more
exploratory, throwaway prototypes to mitigate specific risks such as
design/requirements trade-offs, component feasibility study, or demonstrations
to investors, customers, and end-users.
The primary objectives of the Elaboration Phase include:
Defining, validating and base-lining the architecture as rapidly as practical
Base-lining the vision
Base-lining a high-fidelity plan for the Construction Phase
Demonstrating that the baseline architecture will support this vision for
reasonable cost in a reasonable time.
The essential activities of the Elaboration Phase are:
Elaborating the vision establishing a solid understanding of the most critical
use cases that drive the architectural and planning decisions.
Elaborating the process and the infrastructure, the development environment.
Putting in place the process, tools and automation support.
Elaborating the architecture and selecting components. Potential components are
evaluated and the make/buy/reuse decisions sufficiently understood to determine
the Construction Phase cost and schedule with confidence. The selected
architectural components are integrated and assessed against the primary
scenarios. Lessons learned from these activities may well result in a redesign
of the architecture, taking into consideration alternative designs or
reconsideration of the requirements.
The outcome of the Elaboration Phase is theUse Case Model.
The Use Case Model is a model of the system's intended functions and its
environment, and serves as a contract between the customer and the developers.
The Use Case Model is used as an essential input to activities in analysis,
design, and test. The Use Case Model consists of a collection of:
A Use Case defines a set of use case instances, where each instance is a
sequence of actions a system performs that yields an observable result of value
to a particular actor.
An actor defines a coherent set of roles that users of the system can play when
interacting with it. A user can either be an individual or an external system
The Supplementary Specifications capture the system requirements that are not
readily captured in use cases. Such requirements include:
Legal and regulatory requirements and application standards.
Quality attributes of the system to be built, including usability, reliability,
performance and supportability requirements.
Other requirements such as operating systems and environments, compatibility
requirements, and design constraints.
An object model describing the realisation of use cases, which serves as an
abstraction of the Design Model. The Analysis Model contains the results of use
case analysis, Analysis Classes and any associated documents. The analysis
model may be a temporary model, as in the case where it evolves into a Design
Model, or it may continue to live on through some or all of the project, and
perhaps beyond, serving as a conceptual overview of the system.
Analysis classes are used to capture the major "clumps of responsibility" in the
system. They represent the prototypical classes of the system, and are a
'first-pass' at the major abstractions that the system must handle. Analysis
classes may be maintained in their own right, if a "high-level", conceptual
overview of the system is desired. Analysis classes also give rise to the major
abstractions of the system design: the design classes and subsystems of the
The Design Model is an object model describing the realisation of use cases, and
serves as an abstraction of the implementation model and its source code. The
design model is used as essential input to activities in implementation and
test. It is used to conceive as well as document the design of the software
system. It is a comprehensive, composite artifact encompassing all design
classes, subsystems, packages, collaborations, and the relationships between
A Design Class is a description of a set of objects that share the same
responsibilities, relationships, operations, attributes, and semantics. They
are derived from Analysis Classes as a result of the design process. The
following people use the Design Classes:
a specification when they implement the classes.
other parts of the system to understand how their functionality can be used,
and what their relationships mean.
to instantiate them in use-case realisations.
Those who design the next
version of the system to understand the functionality in the
Those who test the classes
to plan testing activities.
Software Architecture Document
The Software Architecture Document provides a comprehensive architectural
overview of the system, using a number of different architectural views to
depict different aspects of the system. It serves as a communication medium
between the architect and other project team members regarding architecturally
significant decisions that have been made on the project.
The representation and objectives of the software architecture are usually
defined before the very first iterations, and can then be maintained throughout
the project. These architectural representation guidelines are documented in
initial versions of the Software Architecture Document.