The following lists proposed documents to be prepared
during the total systems life cycle. It is based on past experience
and their form and content will follow the source documents as
closely as possible.
NOTE: Instructions of "how-to" prepare documents and
an example "model-text" will be defined in the 'Technical Documentation Standard'. The
following provides a brief overview of the proposed documents
to be prepared.
The system/subsystem specification shall state all the necessary requirements in terms of performance, including test provisions to assure that the requirements are achieved. Essential physical constraints will be included. Technical and mission requirements shall be stated together with the requirements for specific functional areas, interfaces between functional areas, interfaces with other systems, and application of specific existing equipment.
For model text DID List.
For model text System/subsystem specification.
The Statement of Work (SOW) is probably the most
important management document to be prepared. Attention to detail
is an absolute necessity as it will form the foundation for performance
by the supplier and will enable effective administration by the
acquirer.
NOTE: The SOW should only task the supplier to establish, implement,
and control the speciality program plans, e.g., security, maintainability,
etc. Specification details will be stated in a System/subsystem
specification or equivalent.
For model text Statement of Work.
Describes the design of a system or subsystem and
its operational and support environments as specified by a system/subsystem
specification. The SSDD may be supplemented by IDDs and DBDDs.
The SSDD shall describe the organization of a system or subsystem
as composed of HWCIs, CSCIs and manual operations. The SSDD shall
contain the highest level design information for the specific
system or subsystem. The SSDD shall describe the allocation of
system requirements to HWCIs, CSCIs, and manual operations.
The Main purpose of the SSDD shall be:
For DID DID list.
For model text System/subsystem design description
For DID Operational concept document. For model text Operational concept document.
The 'Critical/Prime item development specification' defines the performance, design, development, and test requirements of a system or hardware configuration item or equipment.
A 'Software Development Standard'
shall be prepared to establish the software development process
(activities, procedures, plans, etc.,). The SDS will define the
software development life cycle and identify the necessary "project"
standards, plans, and procedures necessary.
A Software Development plan shall be prepared for each identified
CSCI and if the project is distributed then a Software Development Plan
(overall) may be necessary to identify all the overall organization,
resources, facilities and location of the total software development.
(Will only be applicable when the project is distributed).
For model text Software development plan.
The SRS shall specify in detail the complete requirements
(Functional, performance, qualification, etc.,) of a particular
CSCI. The documents include requirements for programming, design,
adaptation, quality factors, and traceability of the CSCI. Requirements
pertaining to the CSCI's external interface may be presented in
the SRS or in one or more IRSs
When approved and authenticated, this document shall form a part
of the 'allocated baseline' for the specific CSCI.
For model text Software requirements specification.
The IRS(s) specifies the requirements imposed on one or more systems, subsystems, HWCIs, CSCIs manual operations, or other system components to achieve one or more interfaces among these entities. An IRS can cover any number of interfaces.
For model text Interface requirements specification.
The IDD(s) describes the interface characteristics of one or more systems, subsystems, HWCIs, CSCIs, manual operations, or other system components. An IDD can describe any number of interfaces.
The SDD describes the complete design of a particular
CSCI. It presents the allocation of the CSCI requirements to the
Software units showing the complete structure of a CSCI. The document
also describes in detail the structure and organization of a particular
CSCI.
The purpose of the SDD is:
A SDD with its associated IDDs and DBDDs is used as the basis for implementing the software. It provides the acquirer visibility into the design and provides information needed for software support.
The 'Software Test Plan' shall define the total scope of qualification testing for a specific CSCI and software systems. It describes organizations and responsibilities, specifies requirements, and provides schedules for test activities.
The DBDD describes the design of a data base, that is, a collection of related data stored in one or more computerized files in a manner that can be accessed by users or computer programs via a database management system (DBMS). It can also describe the software units used to access or manipulate the data.
See DID list for more details.
The TRD shall provide information necessary to test a system, subsystem, etc., or similar item in the most efficient manner possible with the minimum of interface. Sufficient tests shall be included so that all required performance characteristics can be verified.
The 'Software Test Report' record the results of the Formal CSCI testing.
The 'Acceptance test description' document shall provide description and procedure for performing each formal test identified in the 'System Test Plan' and any applicable product specification.
The 'Acceptance Test Report' shall contain the results of the formal qualification testing procedure detailed in the 'Acceptance Test Procedure' Document.
The 'Critical/Prime item product specification' establishes the performance, design, manufacture, and acceptance required for an identified critical item
Identifies and describes a version of a CSCI or interim changes (that is, changes which occur between CSCI versions) to the previously released version. The SVD records data pertinent to the status and usage of a CSCI version or interim change. Its main use is to release CSCI versions to an acquirer (customer).
The 'Software User Manual' tells a hands-on software user how to install and use a CSCI, a group of related CSCIs, or a software system or subsystem. It may also cover a particular aspect of software operation such as instructions for a particular position or task.
The 'Firmware Support Manual' provides information necessary to program or re-program the read-only memory components of a system. It is equally applicable to ROMs, programmable ROMs, Erasable PROMs, and other firmware devices. It describes the aspects of the ROM devices, support software, and support equipment required for programming and reprogramming ROMs.
The 'Product Acceptance Test Description' defines the test procedure requirements for the Prime/Critical item or UUT item. A PAS may be written using the ATLAS test specification language.
The COM provides information needed to operate a
given computer and its peripheral equipment. This manual focuses
on the computer itself, not on the particular software that will
run on the computer.
The COM is intended for newly developed computers, special-purpose
computers, or other
Drawing practices and identification of parts shall conform to the specific 'Design Standard' stated in the contractual documents and/or DEF STAN 05-10/BS 508 Drawing Procedures.
Identifies and describes the overall tasks, principles,
and objectives for an integrated technical effort (systems engineering
management) during the system life cycle phases of the project.
The SEMP shall be produced in accordance with MIL-STD-499 (or
equivalent).
See SEMP- model text.
Identifies and describes the overall polices and
methods for configuration management to be followed during the
system and development life cycle phases of the CSCIs and HWCIs.
The Configuration Management Plan shall
be produced in accordance with MIL-STD-973 (or equivalent).
Defines the required standard for documentation to be prepared during the system life cycle phases including the development of HWCIs and CSCIs. Example model text for all the necessary documents shall be contained as appendixes to the document.
Identifies the overall standards, procedures, planning processes for the systems, subsystems, equipment, HWCIs, etc., for the project.
Identifies the software element of the project (CSCIs and supporting software) by defining the overall standards, plans, procedures, and the relevant organizations being used to develop, integrate, and test the software being prepared for the project.
Describes the organizations, activities, methods and procedures applicable for use by the developer and suppliers to evaluate the quality of the products being prepared and produced. Audit and review procedures shall be provided.
The 'Software Configuration Management Plan' shall be a functional part of the 'Software Development Plan' but separate on the grounds of maintainability, and reduction of complexity of the 'Software Development plan'.
The 'Software Engineering Manual' describes or references the user instruction for the software tools used to design, develop, or implement the CSCIs allocated to the system. Also included will be any procedures required by the Software Engineering teams for performance of formal reviews.
The 'Software Product Evaluation Plan' describes the product evaluation methods and techniques to inspect and check the software products during their development. Additionally the evaluation criteria for each document will be provided. The organization tasked with performance will be identified in the SDP.
The 'Version compatibility matrix' shall be prepared detailing the compatible combinations of software versions and hardware modification states. This matrix will form a part of the 'Master Record Index'.
The 'Master Record Index' (MRI) lists a master set
of drawings which define the design standard of both hardware
and software and records changes in design.
The purpose of the MRI is as follows:
The MRI becomes a requirement when design records are accepted by the acquirer. The MRI shall form a baseline for all subsequent design changes.
The 'Physical Configuration Audit Plan' shall establish the activities, personnel, organizations, schedule, and methods to be used for the PCA of HWCIs, CSCIs, subsystems, and system prior to establishment of a production baseline.
The 'Testability program plan'
The primary objective of the System Security Management Plan shall be to minimize or contain system vulnerabilities to known or postulated security threats.
other speciality program plans when relevant.
Under construction.
Back to Home page
MANAGING STANDARDS Home page Back
to top of this pageClick here
Please send any beneficial comments or identification of errors
using the following form to: kenr@wysywig.airtime.co.uk