A list of proposed documents are provided in Proposed documents
The documents can be categorized into the following
data items:
NOTE: Only documents relevant to the work allocation defined in
the SOW need be prepared.
Project documentation (sometimes referred to as project
"standards" or "quality plan") are regarded
as management data items and shall be used to manage the acquisition,
development and production of projected systems, and its comprising
hardware and software during the system life cycle as defined
by the contractual requirements
The following documents are in this category:
The 'Project plan' (PP) identifies and describes
the overall policies, principles, and objectives for executive
management during the total system life cycle, of the system.
The PP shall be prepared in accordance with the example model
text.
The 'System Engineering management plan' (SEMP) identifies
and describes the overall tasks, principles, and objectives for
systems engineering management during the total system life cycle,
of the system, and its comprising subsystems, HWCIs, CSCIs and
applicable equipment for the project.
The SEMP shall be prepared in accordance with the example model
text and task statements in the SOW, RFP and/or any contractually
identified conditions.
The 'Configuration Management Plan' (CMP) shall identify
and define the overall polices and methods for configuration management
to be used during the total life cycle of the systems, subsystems,
HWCIs and CSCIs to be used by the final system and supporting
equipment.
The CMP shall be prepared in accordance with the instructions
provided by (if applicable) MIL-STD-973 and DEF STAN 05-57 together
with any supporting documentation.
The 'Technical documentation standard' establishes
and defines the required standard for the preparation of specifications,
standards, and their associated documents. This shall include
plans, manuals, files, reports, etc., to be prepared and utilized
during the development of systems, subsystems and the supporting
equipment. Work instructions, code of practice, and documentation
layout shall be defined. Example "model texts" for the
identified documentation will provided as appendixes to the document.
Where applicable the applicable the model texts will be prepared
to the eclectic requirements defined in Data item Descriptions
(DID) identified by MIL-STD-498, MIL-STD-490A, MIL-STD-499A, MIL-STD-491D,
with the additional considerations added from RTCA/DO-178B, JSP
188, ISO 9000-3.
This document identifies and defines the overall
standards, organizations, processes, and procedures to be adopted
by all participating companies and suppliers who specify, design,
develop, integrate, certify, or test software being developed
for use by the project.
However, each CSCI and other software shall be developed using
their specific Software development plan as detailed in the 'Engineering
documents' paragraph.
Engineering documents are defined as documents prepared
by the engineering groups or teams. These documents specify and
describe the technical system which is being conceived, designed,
developed or produced.
The following documents are in this category:
The 'Statement of Work' shall identify the technical
effort required to be performed by a contractor.
A SOW should specify in clear, understandable terms the work to
be done in developing or producing the goods to be delivered or
services to be performed by a contractor.
A SOW defines (either directly or by reference to other documents)
all non-specification requirements for contractor effort.
Qualitative and quantitative design and performance requirements
shall be contained in specifications or standards. Such specifications
are typically referenced in the SOW but the specific qualitative
or quantitative technical requirements shall not be spelled out
in the SOW.
For example; a SOW will task a contractor to establish, implement,
and control specific speciality programs (via a SEMP), i.e., Maintainability,
Reliability, Configuration Management, Software Development, etc.
Management requirements in terms of results needed rather than
"how to manage" procedures for achieving those results.
For an Example Statement of Work model text .
When approved and authorized, a 'System/subsystem specification' (SSS) shall establish a "Functional Baseline" for the specific system, subsystem, or equipment. The SSS shall state all necessary requirements in terms of performance, including test provisions to assure that all requirements are achieved.
For an Example System/subsystem specification model text .
The 'System/subsystem design description' (SSDD)
describes the design of a system or subsystem and its operational
and support environments as specified by a 'System/subsystem specification'.
It describes the organization of s system or subsystem as composed
of CSCIs, HWCIs and manual operations. The SSDD contains the highest
level of design information for the system or subsystem. The SSDD
describes the allocation of system requirements to HWCIs, CSCIs,
and manual operations.
The main purpose of the SSDD shall be:
For an Example System/subsystem design description model text .
Development specifications for HWCIs shall establish the performance, design, development, and test requirements for both critical and prime items of the system and subsystems.
For an Example HWCI development specification model text .
A 'Software Requirements Specification' (SRS) shall specify in detail the complete requirements (functional, capability, performance, qualification, etc.,) of a particular CSCI. The document will contain the necessary requirements for programming, design, training, adaptation, quality factors, and traceability of a CSCI.
For an Example Software requirements specification model text .
The 'Interface Requirements Specification' shall detail the specific requirements for each interface to the CSCI. They shall define the requirements of one or more external interface(s) between the specific CSCI and other CSCIs, HWCIs or critical Items.
For an Example Interface requirements specification model text .
Drawing practices and identification of parts will conform to the Design Standards stated in the contractual documents. Examples are MIL-STD-100, DEF STAN 05-10, and BS 508.
The 'Software Development Plan' shall establish the individual plan for the site or area specific development of a CSCI, or an aggregate of a CSCI. The activities, personnel, facilities, organizations, schedules, code of practice and standards to be used for the development of software and its certification for each CSCI shall be identified.
For an Example Software development plan model text .
The 'Software Design Description' document describes
the complete design of a CSCI. It presents the allocation of the
CSCI requirements to software units showing the complete structure
of a CSCI. This document also describes in detail the structure
and organization of a particular CSCI. It describes the decomposition
of the CSCI into software units and may also contain the detail
interface and database requirements.
The purpose of the SDD is:
For an Example Software design description model text .
When necessary a 'Database Design Description' may be prepared as part of the 'Software Design Description' document.
For an Example Database design description model text .
The IDD(s) shall define the requirements of one or more external interface(s) between the specific CSCI and other CSCIs, HWCIs or critical Items.
For an Example Interface design description model text .
The SPS(s) shall establish the requirements o.
For an Example Software Product Specification model text .
Documents in this category identify the testing information
required for system, subsystem, CSCI, and HWCIs. They shall provide
visibility into the testing process to be employed for the project.
Operational or user documentation are available in
many forms depending on the application and its traditional publication
standard.
Rest under construction.
Back to Home page MANAGING STANDARDS Home page
Please send any beneficial comments or identification of errors using the following form to: kenr@wysywig.airtime.co.uk