Many development and support planning milestones are related to CIs. Activities such as performance or design verification demonstration, system integration and testing, technical reviews and audits , and budget allocations are usually accomplished for each of the CIs selected. The number of CIs selected will determine the number of separate meetings related to the overall activity. A large number of CIs may lead to delays in completing critical milestones.

Existing CIs can be modified and designated as a separate and different configuration of that CI, thus saving time and money. Factors to be traded off include complexity, the use of new materials, processes, and the insertion of new technology.

There are no rules to dictate the optimum number of CIs for a given system. In general, however, the fewer CIs, the better. Selecting too many CIs increases development and support costs.

Each CI to be developed, especially CSCIs, comes with an associated set of technical reviews, audits, performance or design verification demonstrations , formal unit and integration tests, and documentation requirements. Each of these activities adds an increment of development cost and also adds costs for storage and upkeep of information related to the activities and the documentation.

The consequences of designating too many CIs include:

  • Numerous inter-CI interfaces to be defined, and documented, which, if they are all baselined early in the EMD phase, will inhibit the freedom to evolve the design solution, solve problems expeditiously, and implement advantageous changes without contractual consequence

  • CI functionality defined at too low a level or including unnecessary design constraints requiring formal test, and technical reviews, beyond what is required to achieve reasonable assurance of system performance (this is also a concern if performance specifications for the lower-level CIs are baselined too early in the EMD phase)

  • Increased overall number of requirements in the documentation disproportionate to the unique technical content of the requirements

  • Excessive fragmentation, which may actually decrease understanding of system performance; fragmented description of functionality increases the overall volume of requirements, is more difficult to understand, and complicates the document review, approval, and control process

  • Increased cost

The consequences of having too few CIs include:

  • Increased complexity of each CI, resulting in decreasing management insight and ability to assess progress

  • Where the lowest -level designated CI is a complex item (implementing unrelated functions, containing both hardware and software components , etc.):

    • The potential for reuse of the CI, or portions of the CI, is diminished

    • Re-procurement of the CI and components is complicated

    • Potential re-procurement sources are limited

    • Formal testing of critical capabilities may be delayed or made more difficult

    • The inability to account for the deployment of a CI, whose component parts are disbursed to different locations

    • Difficulty in addressing the effectivity of changes and retrofit actions, particularly when there are different quantities or separately deliverable components

    • Increased complexity in managing and accounting for common assemblies and components


The term "configuration documentation" characterizes the information that defines the performance and functional and physical attributes of a product. As described in EIA Standard 649, all other product documentation (such as operation and maintenance manuals, illustrated parts breakdowns, test plans and procedures) are based on and relate to information in the configuration documentation. The configuration documentation associated with each CI provides the basis for configuration control, logistics support, post-deployment, and software support.

Specification Types Categorized by Object

This section describes the type of CI "objects" that a specification is intended to define. This category is part of a string of categories that comprise the specification type.


A system specification defines the overall performance and mission requirements for a system, allocates requirements to lower-level components of the system, and identifies system interface and interoperability constraints. It is the top-level functional requirements specification for the system. A system specification is used to establish a functional baseline for the system.

Large systems are usually decomposed; Level 2 system components are often complex enough to be called "systems" themselves (although, for configuration management purposes, they are designated as subsystems or CIs).


The item specification for a CI defines the performance and interface requirements and design and interoperability constraints that have been allocated to the CI from a system or higher-level CI.

Item specifications provide the contractual basis for the development and verification of CI performance. The item performance (development) specification(s) will normally be used to establish the allocated baseline for the CI.


Computer software configuration items (CSCIs) are documented with software specifications. A software detailed specification is similar to the software requirements specification plus the set of design documents describing the software, interface, and database design.


Process specifications are used where a process (or service) has been developed specifically for use with a particular system/item and is critical to its performance or design. The process specification forms part of the product baseline of the CI(s).

Specification Types Categorized by Purpose


A performance specification provides requirements for a system, item, software, process, or material in terms of the required results and the criteria for verifying compliance. It defines the functional requirements, the operational environment, and interface and interchangeability requirements, but does not state how the requirements are to be achieved, require the use of specific materials or parts, or give design or construction requirements beyond those design constraints necessary to unambiguously define interface and interchangeability requirements.

The intent of a performance specification is to allow more than one design solution for the requirements specified so that interchangeable competitive products can be evaluated, and new technology can be inserted.


A detail specification may consist of all detail requirements or a blend of performance and detail requirements. The preference is for one specification to convey all the performance and detail requirements for an item.

One intent of the detail specification, as a revision of the performance specification, is to provide sufficient detail to distinguish the features of one design solution for an item from other competing design solutions. Another intent is to specify details of the design solution, such as the use of specific parts and materials, that are essential for critical safety or economic reasons, but to state as many requirements in performance terms as possible.

What makes a stated requirement a design requirement and not a performance requirement is that it prescribes design, construction, material, or quality control solutions, rather than allow for development flexibility.

Design Solution Document Concepts

The requirements of the functional and allocated baselines are basically design constraints. The design solution evolves from the design and development process during the engineering and manufacturing development (EMD) phase of the life cycle. This process essentially converts the performance requirements of the baseline specification into a specific product definition that can be manufactured to produce a hardware item or compiled to produce a software item.

It is documented in design documentation for the hardware and the software comprising each CI. For hardware, the design documentation may be in the form of engineering drawings and associated lists, as well as the material and process documents that are referenced by the drawings. In the current information environment, the primary design documentation source may be in the form of two- or three-dimensional engineering models. In that case, a drawing is simply a two-dimensional view of a model that exists in a database file. Various models and product modeling tools can be employed. Engineering drawings may or may not exist as a central part of the product manufacturing process, depending on the product and the degree of automation technology employed.

In an automated development and production environment, an item is designed on the engineer's workstation, manufacturing instructions are added at the manufacturing planner's workstation, and the results are fed directly to automated machinery that produces the item. Commonly, items are designed using computer-aided design tools (CADAM, CATIA, AUTOCAD, etc.) and engineering drawings are plotted for human checking and review. Where engineering drawings are required as a contract deliverable , they should be delivered in place, in a CALS-compliant format.

For software, the design evolves through a software engineering process, using a variety of integrated tools, often called the software engineering environment (e.g., computer-aided software engineering [CASE]). The process results in computer-based versions of documentation, source, and executable code for every CSCI. The process employed to manage the automated software documentation (e.g., software library management and archiving) is similar to the process used to manage automated hardware documentation, although different tools can be employed. Upon close examination, it is fundamentally the same process used to manage the files, which contain software code. The same business rules apply to both software and documents in terms of their identification and relationships to other entities.

The developmental configuration management process consists of a formal process to control the documentation and repositories containing the elements of the developmental configuration. The engineering release system and engineering release records are an important part of this management process.

Each and every version of all elements of the developmental configuration released, for whatever purpose, should be maintained , along with the reasons the version was released and the rationale for superseding the previous version.

Software Documentation List

Process Implementation: Planning

  • Operational Concept Document: proposed system; user needs

  • Software Development Plan: development effort; process, methods , schedules, organization, resources (includes or refers to SCM and SQA plans)

  • Software Test Plan: qualification testing; SW item; SW system; environment, tests, schedules

  • Software Installation Plan: installing SW; user sites; preparations ; training; conversion

  • Software Transition Plan: transitioning to maintenance organization; HW; SW; resources; life-cycle support

System Requirements Analysis and Architectural Design

  • System/ Sub-system Specification: specifies system or sub-system requirements; requirement verification methods (may be supplemented with system-level IRS)

  • System/Sub-system Design Description: system/sub-system-wide design; architectural design; basis for system development (may be supplemented with IDD, DBDD)

Software Requirements Analysis and Design

  • Software Requirements Specification: specifies SW requirements; verification methods (may be supplemented with IRS)

  • Interface Requirements Specification: specifies interface requirements for one or more systems, sub-systems, HW items, SW items, operations or other system components; any number of interfaces (can supplement SSS, SSDD, SRS)

Software Architectural and Detailed Design

  • Software Design Description: SW item-wide design decisions; SW item architectural design; detailed design, basis for implementing; information for maintenance (may be supplemented by IDD, DBDD)

  • Interface Design Description: interface characteristics; one or more systems, sub-systems, HW items, SW items, operations or other system components; any number of interfaces; detail companion to IRS; communicate and control interface design decisions

  • Database Design Description: database design; related data, files, SW/database management system for access, basis for implementation and maintenance

Software Integration and Qualification Testing

  • Software Test Description: test preparations; test cases; test procedures; qualification testing SW item, SW system or sub-system

  • Software Test Report: record of test performed; assess results

As-Built Software Product Definition

  • Software Product Specification: contains or references executable SW, source files; SW maintenance information; "as-built" design information, compilation, build, modification procedures; primary SW maintenance document

  • Software Version Description: identifies and describes an SW version; used to release, track, and control each version

System Operation

  • Software User Manual: hands-on software user; how to install and use SW, SW item group , SW system or sub-system

  • Software Input/Output Manual: computer center; centralized or networked installation; how to access, input, and interpret output; batch or interactive (with SCOM as alternative to SUM)

  • Software Center Operator Manual: computer center; centralized or networked installation; how to install and operate an SW system (with SIOM as alternative to SUM)

  • Computer Operator Manual: information needed to operate a given computer and its peripherals

System/Software Maintenance

  • Computer Programming Manual: information needed by programmer to program for a given computer; newly developed; special purpose; focus on computer, not on specific SW

  • Firmware Support Manual: information to program and re-program firmware devices in a system; ROMs, PROMs, EPROMs, etc.