The purpose of this standard is to establish uniform requirements for software development and documentation.
MIL-STD-498 is intended to be applied as follows.
This standard can be applied to contractors, subcontractors, or Government in-house agencies performing software development. For uniformity, the term "acquirer" is used for the organization requiring the technical effort, "developer" for the organization performing the technical effort, "contract" for the agreement between these parties, "Statement of Work" (SOW) for the list of tasks to be performed by the developer, "Contract Data Requirements List" (CDRL) for the list of deliverable software products, and "subcontractor" for any organization tasked by the developer to perform part of the required effort. "Software development" is used as an inclusive term encompassing new development, modification, reuse, reengineering, maintenance, and all other activities resulting in software products.
This standard is invoked by citing it on a contract. It applies to each software product and to each type of software covered by the contract, regardless of storage medium, to the extent specified in the contract. Examples of types of software include deliverable versus non-deliverable, software designed to meet user needs versus software in the engineering and test environments, and software designed to meet one user need versus software designed to meet another. The acquirer is expected to specify the types of software to which the standard applies and to tailor the standard appropriately for each type of software. If the standard is invoked without such a statement of selective application, it will be understood to apply in its entirety to all deliverable software, with requirements concerning the software development environment applicable to the software development environment for the deliverable software. While this standard is written in terms of Computer Software Configuration Items (CSCIs), it may be applied to software not designated as a CSCI, with the term "CSCI" interpreted appropriately. Software installed in firmware is subject to all of the aforementioned provisions. This standard does not apply to the hardware element of firmware.
This standard and its Data Item Descriptions (DIDs) are meant to be tailored for each type of software to which they are applied. While tailoring is the responsibility of the acquirer, suggested tailoring may be provided by prospective and selected developers. General tailoring guidance can be found in Section 6 and in DOD-HDBK-248. Tailoring guidance specific to this standard can be found in Appendixes G and H and in guidebooks and handbooks planned for this standard.
The following terms have a special interpretation as used in this standard.
The following interpretations apply:
a. The term "system," as used in this standard, may mean: (1) a hardware-software system (for example, a radar system) for which this standard covers only the software portion, or (2) a software system (for example, a payroll system) for which this standard governs overall development.
b. If a system consists of subsystems, all requirements in this standard concerning systems apply to the subsystems as well. If a contract is based on alternatives to systems and subsystems, such as complex items, the requirements in this standard concerning the system and its specification apply to these alternatives and their specifications.
The term "participate" in paragraphs regarding system-level activities is to be interpreted as follows: If the software covered by this standard is part of a hardware-software system for which this standard covers only the software portion, the term "participate" is to be interpreted as "take part in, as described in the software development plan." If the software (possibly with its computers) is considered to constitute a system, the term "participate" is to be interpreted as "be responsible for."
Throughout this standard, requirements to "develop," "define," "establish," or "identify" information are to be interpreted to include new development, modification, reuse, reengineering, maintenance, or any other activity or combination of activities resulting in software products.
Throughout this standard, requirements to "record" information are to be interpreted to mean "set down in a manner that can be retrieved and viewed." The result may take many forms, including, but not limited to, hand-written notes, hard-copy or electronic documents, and data recorded in computer-aided software engineering (CASE) and project management tools.
In the event of conflict between the requirements of this standard and other applicable standardization documents, the acquirer is responsible for resolving the conflicts.
Translator: Simon Wright simon@pogner.demon.co.uk
Last updated: 22.iii.99