The circumstances, objects, or conditions by which an item is surrounded.
When used in the context of a specification (or other set of requirements), the concept of an Environment causes great difficulty. Except when the environment is altered by the presence and operation of the item (“self-induced”), environments are not true properties of the item. But because they reside in the “design-to” section of the specification1, our verification practices treat them as any other type of requirement. In reality, the environments are important only insofar as the item can operate during or after exposure, and they are “verified” only when all those other features have been verified with regard to that exposure.
Certain legacy practices organized the Environments section according to the operational phase in which they were encountered (e.g., “Operating”, “Transport”). While unambiguous, this tactic often resulted in environment characteristics that superficially appeared to duplicate each other. While not “wrong” in any sense, the duplication made it possible to diverge the various instances of any given (duplicated) environmental characteristic.
Other legacy practices tried to resolve the duplication issues by creating an “environments cross-reference” matrix between all environment requirements and all non-environment requirements. Each intersection on the matrix required either an assessment of non-relevance or explicit verification data. The environment requirements were considered met when all intersections for that environment requirement were populated. Given the unfortunate definition of Environments as stand-alone “requirements”, this was actually a pretty good approach.
Footnotes- Belatedly, I have come to regard this as a short-coming in the MIL-STD-490 concept of a specification.[↩]