Changing What I Think I Know
Over the years, I’ve developed some strong opinions about what requirements are, and how they should be expressed. It is (therefore) with no small amount of emotional turmoil that I have arrived at a place where I need to change that opinion. I was forced to do so in order to avoid having to explain... 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
Constraint
In the legacy System Engineering context, any technical requirement that is not a Performance Requirement. Sometimes referred to as “Design Constraint”, but this is a misnomer. In the context of optimization, a limit on what values may be obtained by some measure contributing to, or a necessary correlative design feature of, an Objective Function.
Directed Design
A condition in which the acquisition customer provides contractual direction with regard to one or more design features in addition to those written into the development specification. Sometimes this happens because the customer wants to make best use of technical thoughts they’ve had; other times it happens because the System Engineering theoreticians try to avoid... read more
Emulation
I use “emulate” to model the behavior of an item without modeling the causes and effects that produce it. This is more useful in specifying requirements than when characterizing an actual design. Sometimes, I refer to this concept as “Fun With Numbers”. Contrast with simulation.
Requirement
A statement of need or intent. In most cases, the statement has been formally designated by the originating authority as a criterion for selection or approval. read more.
Requirement Quality
The oft-ballyhooed notion that we so well understand in the abstract all the subtleties, variations, and contextual implications of technical requirements that we can quantitatively measure their suitability for use in communicating complex technological concepts, one requirement at a time, in a manner simple enough to be executed by those who understand neither the product,... read more
Shall (usage of)
When used in a requirement, indicative of a characteristic or (occasionally) task that is intended as mandatory. The design‘s failure to comply with such a requirement is treated as a contract breach. Contrast with shall, where practicable, should, may, and will.
Topic (Requirement)
Every requirement has to be about something. This is it. I used to call this the “subject”, but people interpreted everything that followed as “grammar”. I found that changing the name made them pay attention longer1. The concept generalizes to apply to any characterization of a system. Footnotes If they paid attention at all.[↩]
will (usage of)
In legacy specification practices, “will” indicated simple futurity rather than need or intent. This contradicts normal legal usage and, because specifications are contractual documents, raises the potential for multiple interpretations when things end up in court. My best guidance is “don’t ever use ‘will’ in a specification”. Indicate simple futurity by using “is”. Contrast with... read more
Working with Requirements
The top-level types of requirements are defined and differentiated. read more.