Data item descriptions

U.S. Dept. Defense. Defense System Software Development Data Item Description for the Software Design Document. DI-MCCR-80012A. Washington, DC GPO, Feb. 29, 1988. 

As this edition is published, the current MIL-STD-882 is the D version and, therefore, discussion of that approach to system safety implementation follows. The D version responds to changes in the defense acquisition procedures and is no longer the source for safety-related data item descriptions (the formal detailed requirements associated with defense procurement contracts). Therefore, for several reasons, the more detailed methods of implementation of previous versions of the military standard are retained because they are still valid. This is for two reasons. First, there are some government contracts with very long periods of performance or those that have been renewed multiple times that still refer to the earlier standard version. Secondly, and perhaps more importantly, the implementation method of the previous versions provides a guide for implementation of the newer standard practice. ... 

An important part of the government system safety effort is to assure that system safety requirements are specified clearly and correctly in contract documents. The formats for system safety products or deliverables are generally prescribed by data item descriptions (DIDs). Other specific requirements concerning the exact documents to be produced and delivered are specified in the contractor requirements data list (CRDL). 

The SSPP format outline parallels the format listed in data item description DI-SAFT-80100 and thus generally conforms to the requirements of MIL-STD-882B. 

A CDRL is a DD Form 1423 list of contract data requirements that are authorized for a specific acquisition and made a part of the contract. All data delivered under contract must be specified by CDRL. The managing authority prepares the CDRL to require that the data package will be prepared and forwarded through the procurement agency, in sufficient copies, at the appropriate date to support program milestones. Many CDRLs refer to an existing Data Item Description (DID) for data format and content. 

See Data Item Description (DID) for additional related information. 

Data Item Descriptions (DIDs) were originatly defined as part of MIL-STD-498, which consisted of two parts. Overview and Tailoring Guidebook and Application and Reference Guidebook, and aimed at software development. However, the concept has proved to be of enduring value and applicability, and current defence contracts often require compliance with a large number of DIDs... 

The flic presented contains 11 data items. The header lines arc property names as used by CACTVS [64, 65], and arc sufficiently self-descriptive. For example, E NHDONORS is the number of hydrogen bond donor.s, E SM1LES" is the SMILES string representing the structure of sulfamidc, and E LOGP is the logP value (octanol/water partition coefficient) for this substance. 

There is a special keyword - loop - which enables repetition of data. This keyword is used mainly when there are several data items with the same type of content (e.g.. description of the atoms within a molecule). 

The Input Translator is completely table driven. This means that all of the information needed to process input statements (such as names of keywords, default values of data items, etc.) is stored in tables in a file called the System Definition File. Therefore, it is easy to add keywords or change defaults by changing entries in the System Definition File. In addition to the Input Language tables, almost any "changeable" information related to Input Translation is stored in the System Definition File. This includes unit conversion tables, attribute descriptions, physical property option models, data structure, unit operation model data, and stream requirements, etc. Thus it is easy to add new system parameters without changing any code in the Input Translator. 

ORIGIN ITEM TYPE ITEM DESCRIPTION ---DESIGN DATA- PURCHASED . EQUIPMENT COST USD ... 

---