Topic: Specifications

Generally, a collection of requirements for a CI or standard design. Certain types of specifications can, however, contain requirements for processes that are specific to some given project (or class of CI), which sometimes causes confusion with the concept of a Standard.   See the thing I think I know about that.

Authentication

A contractual process used to formalize concurrence at PDR by the Acquisition Customer with development requirements allocated to a CI. In effect, it forced the Developer to admit to intended capability for each CI and also (importantly) forced the Acquisition Customer to commit to paying for development if compliance were shown at FCA. More recently,... read more  

Configuration Item Classification

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... read more  

Critical Item

A type of CI that is less significant (in some senses, from some perspectives) than a Prime Item, but more important than a Non-complex Item. In the MIL-STD-490 framework, this class of CI had its own Specification (Spec) format (the “B2” specification) along with explicit rules for when it should be used. The specification was... read more  

May (usage of)

Information given to the developer with regard to a characteristic which, if not met by the proffered design, need not be explained away by the developer.  In other words…not a requirement at all, just a good idea. This form is now generally deprecated. Contrast with shall, shall-where-practicable, should, and will.  

MIL-STD-490

A now-canceled standard for specification practices. The immediate predecessor to MIL-STD-961 (at revision D).  

MIL-STD-961

The standard that succeeded MIL-STD-490 at Revision D. It was upgraded to attempt addressing development specifications after MIL-STD-490 was canceled. It never really did the job. Standards for specification practices headed downhill fast with (and following)MIL-STD-961. To be honest, they got so bad that I quit paying attention around the turn of the century. Maybe... read more  

Non-complex Item

In the MIL-STD-490 context, a CI that is not complicated enough or important enough to be considered “critical” (as in “Critical Item”).  

Shall, where practicable (usage of)

When used in a requirement, indicative of a characteristic, feature, or (occasionally) task that is considered mandatory iff it can be implemented within the existing standard design and/or manufacturing practices of the developer.  The design documentation must otherwise explain what the standard practices are with respect to the stated issue. This requirement form is now typically deprecated.... read more  

Should (usage of)

Advice to the developer with regard to a characteristic which, if not met by the proffered design, must be explained away by the developer. Contrast with shall, shall, where practicable, may, and will.  

Specification (Spec)

Generally, a collection of requirements for a CI or standard design. Certain types of specifications can, however, contain requirements for processes that are specific to some given project (or class of CI), which sometimes causes confusion with the concept of a Standard.   read more.

Specification Tailoring

The practice of identifying individual requirements within a General Specification for applicability to a specific project.  

Specification Tree

A dendrogram of the parent-child relationships between specifications on a project. The graphical paradigm can make it very difficult to show how General Specifications and re-used CI’s relate, so must be interpreted with caution.  

States and Modes

The argument over the specifics of this definition is the single biggest time-waster in System Engineering. If only the current specification practices did not require us to define states and modes in the specification… See also state, mode, and busywork.  

Verification Cross-Reference Matrix/Index (VCRM, VCRI)

Legacy development specifications typically organized their verification sections according to activity. In that case, it was necessary to indicate which verification requirements were relevant to each of the design-to requirements, each of which was considered to have been fully verified when all verification requirements indicated in the VCRI were successfully completed. This specification practice resulted... read more