In the MIL-STD-490 context, CI’s could be differentiated within a single specification (see section 4.1.2) as follows:
- Types: differences as to design, model, shape, etc. Designated with capital Roman numerals. These were typically used to distinguish differences in performance (function) or other really important features that were critical to different intended end uses.
- Class: subdivisions within Type (as defined above) not constituting a difference in quality or grade (as defined below). Designated with Arabic numerals.
- Grade: differentiation on the basis of quality (e.g., TSE vs. flight hardware) including (but not limited to) reliability or robustness. Designated by capital letters.
- Composition: differentiation on the basis of chemical composition alone. Designated in accordance with industry practice. This could, for example, be used to cost-effectively procure items without full material certification for development or training purposes or for use in different environments.
- Style: differentiation in relatively unimportant minutiae of design or appearance.
Individual technical requirements were phrased within the specification to make the allocation target unambiguous, e.g., “The Type I Widget shall…” allocated to the Type I only, while “the Widget shall…” allocated to all classifications. This worked well until “The Type VII, Class 13, Grade C, Variegated Rubber, knurl-handled widget shall…” came along, at which point most people just quit trying.
Differentiation within a single specification was used in order to minimize the number of individual requirements that had to be tracked through the development process. It was an early (and very effective) approach that later became known in Object Oriented software development as “inheritance”. It fell into disuse because the early requirements database engineers forced a standardized, highly abstracted (and wrong) normalization (2) onto the requirements management process.
See also General Specification.