A requirement written with regard to what the End User intends to accomplish by the use of a CI or system of CI’s (which may, or may not, have been developed under a single contract with a single developer). The parameterization of an operational requirement need not be restricted to characteristics of the CI(s) or system(s) being developed. Contrast with technical requirement.
The italicized “by the use of” in the preceding paragraph is a critical distinction between Operational Requirements and Technical Requirements. Compare it to the implication of “…by a CI or system…”. The first admits that the capability of the CI is augmented, initialized, and/or directed by some other active participant or circumstance that is NOT part of the CI. The second indicates that the capability is allocable in its entirety to the CI (that is, a “proper attribute” of the CI itself, rather than how the CI is used).
Operational requirements are not typically under control of the Acquisition Customer. They are typically under the control of some agent representing the End User (such as a tactical school), and their parameterization will often be strongly related to operational concepts in the doctrinal training material. For an extraordinarily good example of such abstract analysis and decomposition in the operational domain, see FM 7-15 “The Army Universal Task List” (AUTL)1.
In legacy DoD practices, operational requirements were published in an ORD. More recently, the documentation form has been changed to the incrementally published CRD.
Footnotes- As a System Engineer, it is difficult for me to say enough good things about the AUTL. The SE community doesn’t give it anywhere near the recognition it deserves.[↩]