Configuration identification is the activity which determines, defines, and documents the functional and physical characteristics and requirements of a system, including interoperability and interface requirements. The configuration identification function includes such tasks as:
- The selection of the Configuration Item(s)
that will comprise the overall system.
- The determination of the types of configuration
documentation required for each CI.
- The issuance of numbers and other
identifiers affixed to the CIs and to the technical documentation that
defines the CI's configuration, including internal and external interfaces.
- The contractual establishment of configuration baselines.
- The approval of the final product documentation and its subsequent release to the factory production line.
Configuration Identification: Important Definitions
Configuration Item Identification: Those specifications, drawings,
diagrams, flow charts, etc., which, when authenticated and placed on
contract, comprise the functional, allocated, and product baselines
for a system.
Baseline: A document (usually a specification) which, when added to
section C of a contract, constitutes the binding configuration
identification of a system. For Configuration Management, there are three baselines:
- System, for the product's overall functional, interface, & interoperability requirements;
- Allocated, for the general design description of the Configuration Items which comprise the system ("Allocated" is an appropriate term as the entire product's requirements are allocated or apportioned to individual subsystems;)
- Product, for the detailed design description of the Configuration
Items which comprise the weapon system.
Configuration Identification: The Key Activity Product
The key product of the configuration identification activity is a specification, requirements document, blueprint, or software source code which can be used in a Request for Quote (RFQ) or Request for Proposal (RFP). This document is used to convey the product requirements to potential contractors, whether they are vendors or manufacturing outfits. It is critical that the desired product's requirements be completely and accurately described to potential bidders and/or contractors.
Because of acquisition reform efforts, there are many questions about how a product team can put together its own specification or requirements package for a solicitation effort. Please visit this frame for more information Building Configuration Baselines.
Configuration Identification: An Example
Here is an example of configuration identification. Let's say the Air Force requires an improved cargo aircraft for landing in austere conditions (i.e., not landing in an airport, but in the Australian outback, the Canadian tundra, a field in Bosnia, you get the idea.)
To acquire this type of aircraft, the Air Force would need to prepare a requirements document to communicate to the private industry what capabilities the aircraft would require. These requirements would typically be documented in a "System Specification" . The aircraft's payload capability, required speed and handling characteristics, communications requirements, etc. would be included in the specification. This would be considered the "Functional or System Baseline."
Typically, Industrial bidders would respond with a proposed aircraft design to meet the Air Force's requirements. The proposed design would be documented by a series of specifications, each of which would describe critical parts or subsystems of the aircraft. Upon a contract award to the winning bidder, these documents would be considered the "Allocated or Design Baseline" of the aircraft. It should be possible to trace each functional requirement in the Air Force's system baseline document to one or more of the contractor's design documents. For example, UHF communications requirements could be traced to a proposed hardened, militarized radio system, which would be a critical part of the aircraft.
The finished aircraft's design would be documented by set of blueprints or engineering drawings. These documents are sometimes referred to as a "Technical Data Package" (TDP) Besides blueprints, the aircraft's finished design could be documented by a series of product test procedures, manufacturing instruction documents, software source code, and proprietary source documents. Together, all of these documents would comprise the "Product Baseline" of the aircraft. These documents would be critical for the lifetime operation of the aircraft as it is almost certain that, over time, the fleet of aircraft would require modifications to meet new military requirements. The product baseline documents are critical in designing, testing, and installing the aircraft's modifications.
Back to Homepage