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:

Use Cases

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.

Actors

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

Supplementary Specifications

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.

Analysis Model

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

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 system.

Design Model

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 them.

Design Classes

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:

• Implementers for a specification when they implement the classes.
• Designers of other parts of the system to understand how their functionality can be used, and what their relationships mean.
• Use-case designers, to instantiate them in use-case realisations.
• Those who design the next version of the system to understand the functionality in the design model.
• 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.