What Artifacts Should Be Produced and Made Available During the First Phase?

This section identifies and discusses the artifacts that should be produced during the system spec-ification contract. These artifacts should be made available to contractors bidding on the system realization contract.

Glossary

Every project brings a plethora of terms and phrases. A project glossary defining these terms should be produced and made available to bidders for the system realization phase. This will greatly aid contractors in the frenzy of activity that occurs during the proposal generation process.

Vision Statement

The Vision Statement (sometimes called a Concept of Operations [CONOPS]) is vital. It should be written from the perspective of the project stakeholders. The reason for supplying this with the RFP for the second phase is to quickly communicate the project's motivation to prospective bidders. This helps set the context for the project. The vision statement is discussed further in Chapter 7, "Inception: Kicking Off the Project."

Software Architecture Document

The Software Architecture Document is another vital set of information. It describes the architectural decisions that were made during the Elaboration phase. It should also describe how the architecture meets the system's supplementary requirements covering response time, throughput, reliability, scalability, and so on. This helps the bidders understand the system's complexities.

Set of Business and System Use Cases

This information helps the bidders understand the complexity of interactions (as well as the number of interactions) actors can have with the system. The actors should be clearly identified, especially those who have an interface to other (external) systems. If possible, an estimation of the completeness of the use cases should be given. (Usually requirements are not 100% complete by the end of the Elaboration phase.)

UML Models

Models illustrating the system's analysis and design should be provided.

Set of Supplementary Requirements

The supplementary requirements describe the nonfunctional requirements to which the system must conform. Supplementary requirements describe areas such as scalability, reliability, response time, and the number of users the system must support. These requirements can be significant cost drivers. Usually, the supplementary requirements are 100% complete by the end of the Elaboration phase. If they aren't, an estimate of their completeness should be given.

Executables Produced by Iterations

Since the Elaboration phase produces some early releases of the system, potential bidders should be given these releases. Accompanying these releases should be the list of requirements that the releases satisfy, and a list of risks that the iteration was designed to address. The source code should be provided or be available for inspection. Build instructions to perform a build of the releases should be included.

List of Risks and Risk History

An important aspect of the Elaboration phase is to directly address project risks. A risk history, containing risks identified in the Inception and Elaboration phases, should be provided. The history should include which risks have been successfully retired and how they were retired. If risks remain, they should be identified, and a suggested course of action to address the risk provided.

Other Information

The contractor supporting the system specification phase will have other information that can assist those bidding on the second phase. For example, what software tools will be used to build the executable releases? The tools (and their version numbers) should be identified. Also, the contractor may have a sense of the size of team that will be needed to develop the system in the customer's time frame. If possible, the initial contractor should be made available for a period of time (perhaps 2 months) for questions after the second phase is awarded to the new contractor.