Scott Scheff, Principal Human Factors Practitioner, HF Designworks
Excerpt from MIL-STD 1472H: Display mounting heights for seated personnel
A Quick Backstory
As a human factors practitioner working in the early 2000s, I was asked by a client to evaluate an aircraft where the manufacturer technically followed the requirements, yet the client felt certain systems within the aircraft were unusable. In this case the human factors requirements that were flowed down to the prime manufacturer were not violated, yet the system was not usable.
This occurred for a variety of reasons, most notably the requirements were not well written. In some cases the requirement asked for an activity instead of an outcome, described the outcome with an adjective instead of a number, left out the human it was written for, or never said how it would be verified. The designers and developers read and executed on each requirement in its literal sense, missing the usability objective in the process.
A good set of requirements could have prevented this. An enforceable human factors requirement has six properties. The requirement states a measurable outcome of human performance, not an engineering activity. The requirement defines the operator population, training state, and conditions. The requirement puts a threshold and a condition on the outcome. The requirement binds a verification method, with pass criteria. The requirement invokes standards by paragraph rather than by title. And the requirement lives in the right document, with the effort in the statement of work, the product in the specification, and the evidence in a deliverable that a milestone depends on.
How human factors requirements fail
Six rules for writing requirements
RULE 1
Specify the outcome, not the activity
A requirement that tells the program engineers to perform an analysis is satisfied when the analysis is delivered. A requirement that tells the program engineer what a trained operator must be able to do with the system is satisfied only when the system does it. Both belong in the contract, but only the second is a requirement on the product, and only the second can fail at a test event. The activity requirements belong in the statement of work, where they define effort. The outcome requirements belong in the specification, where they define acceptance.
AS WRITTEN
The contractor shall apply human factors engineering principles to the design of the operator control station.
ENFORCEABLE
The operator control station shall permit an operator trained per Section 3.9 to complete each task in Table 3-4 within the task time and error limits of Table 3-4, verified by test per Section 4.7.
The first sentence is subjective and difficult to test. The second provides clear tasks, times, and error limits, and a test.
RULE 2
Define the human
Human performance requirements are statements about a population under conditions. State in detail who the operator is in terms the program can test against. This includes the anthropometric range, usually expressed as 5th to 95th percentile of the user population, suitably clothed (could include safety gear, gloves, masks, etc.) and equipped; and the environment (i.e., night, motion, vibration, degraded visual conditions, or the fatigue state at the end of a watch). Validating requirements is easy when testing to a good day/condition, but you oftentimes learn more on a bad day, or in this case when edge case opportunities are included.
AS WRITTEN
The display shall be readable by the operator.
ENFORCEABLE
Display text and symbology shall be legible to operators in the 5th through 95th percentile visual acuity range of the user population defined in Section 3.1, wearing the protective eyewear of Section 3.1.2, at all ambient illumination levels from 0.1 lux to 100,000 lux, from the design eye position of Section 3.6, verified by test.
RULE 3
Include thresholds and conditions
Clearly define thresholds and conditions. A validated subjective scale such as the Bedford workload rating or NASA Task Load Index (TLX) is acceptable if the threshold, the rater population, and the scenario are all fixed in the requirement. Whatever the instrument, the requirement should state it and clarify any specifics for the scales.
AS WRITTEN
Operator workload shall be minimized during all phases of the mission.
ENFORCEABLE
While supervising four unmanned vehicles during the transit phase of Mission Profile 2, with the off-nominal events of Table 3-7 injected, the operator shall complete all Priority 1 tasks of Table 3-4 within their time limits, and mean operator workload shall not exceed Bedford rating 4 across a test population of no fewer than eight representative operators, verified by test.
“Minimized” is not a threshold and “all phases” is not a condition. The rewritten requirement can be failed, which is the point.
RULE 4
Include the verification criteria
For human performance requirements, the specification or its verification cross-reference matrix should state the method (test, demonstration, analysis, or inspection); the fidelity of the article and environment; the number and source of test participants, with the government supplying or approving them; the pass criterion, including how many participants must succeed; and the government’s right to witness. Explicitly state that a human-in-the-loop simulation with representative operators is required before critical design review and that analysis alone is not acceptable for the requirements that carry operator safety or the crew ratio. A requirement whose verification is stated this way survives the verification planning negotiation, because the negotiation already happened when the contract was signed.
AS WRITTEN
Priority 1 alert responses shall be verified by analysis.
ENFORCEABLE
Government-approved representative operators shall acknowledge each Priority 1 alert within the Table 3-4 time limit in a production-representative human-in-the-loop test before CDR. Verification shall be by test, with the Government permitted to witness.
"Verified by analysis" leaves the door open to interpretations in what "Verified by analysis" means or how it can be executed.
RULE 5
Invoke standards by paragraph, not by title
The example of a human engineering standard MIL-STD-1472H is often used when creating human factors requirements. Too often however, there is a blanket statement “shall comply with MIL-STD-1472” which is not nearly specific enough.
AS WRITTEN
The system shall be designed in accordance with MIL-STD-1472 as a guide.
ENFORCEABLE
The operator control station shall comply with the paragraphs of MIL-STD-1472H listed in Appendix B, Table B-1, each of which is a requirement of this specification. Where Table B-1 identifies a paragraph as tailored, the tailored text in Table B-1 governs.
“Minimized” is not a threshold and “all phases” is not a condition. The rewritten requirement can be failed, which is the point.
RULE 6
Put effort into the SOW, product in the specification, and evidence on the critical path
A human-performance requirement belongs in the specification because it defines what the product must do and how acceptance will be determined. The specification should also state the verification approach described in Rule 4. The statement of work serves a different purpose: it defines the contractor’s human engineering effort, including analyses, human-in-the-loop events, and government participation. The Contract Data Requirements (CDR) list identifies the evidence the contractor must deliver, beginning with a Human Engineering Program Plan under DI-HFAC-81742 and continuing through the design approach documents, analysis reports, and test plans and reports used to evaluate the work.
Make those deliverables consequential. When human engineering plans and reports are named as entry criteria for preliminary and critical design reviews, a missing or inadequate deliverable becomes a schedule issue rather than a deferred action item. The HSI Guidebook reinforces this approach by advising programs to be “deliberate and strategic in developing SOWs and CDRLs.”
Words and phrases matter
Years ago we were brought in to support a client who was having an aircraft manufactured for them. There were requirements which stated functions A, B, and C must be present. Unfortunately the requirement did not state where those functions had to be. As a result, they were tucked away deep in a menu structure, requiring an operator to dive several menus deep on a control station interface to find them. Reaching these functions was not intuitive and, even if it was, reaching the functions in the allotted amount of time was virtually impossible. The requirements should have clearly stated where the functions should be located, how they should be labeled, and how much time an operator would have to access them.
This aircraft manufacturing example demonstrates the importance of clear and unambiguous language when writing requirements. Below is a list of common, ambiguous phrases that may appear in human factors requirements and the potential negative outcomes they allow for. My recommendation is that each of these phrases can be revised into be a meaningful and measureable requirement.
What programs can do moving forward
Pull the human factors requirements out of the current draft specification and statement of work and read them as a contractor would. Consider the impact on the program if the least expensive, literal compliance was followed. For each requirement decide whether it is an effort requirement that belongs in the statement of work or an outcome requirement that needs a number, a population, a condition, and a verification method. Build a task table that can be used in the human-in-the-loop test plan, the training analysis, and the manpower estimate. Ensure requirements are tailored to specific paragraphs in documents such as MIL-STD-1472H, rather than using a blanket statement covering the entire document.
HF Designworks is a human factors and human systems integration firm that works with defense primes and government programs on the operator side of autonomy and complex systems: requirements development and tailoring, workload and crew-ratio assessment, control station and interface design, human-in-the-loop evaluation, and HSI planning under DoDI 5000.95.
HF Designworks maintains a small-business status within the DoW and has worked within the defense industry for over 20 years serving as both a prime and a sub on a variety of ground, sea, and aviation based programs including those for the Army, Air Force, Navy, DARPA and NASA. For more information or to schedule a consultation please contact us.
Sources
Department of Defense, MIL-STD-1472H, Department of Defense Design Criteria Standard: Human Engineering, 15 September 2020; Notice 1 (validation), April 2026.
Hooks, I. F., “Writing Good Requirements,” Proceedings of the Third International Symposium of the NCOSE (INCOSE), 1993.
INCOSE Requirements Working Group, Guide to Writing Requirements, INCOSE-TP-2010-006, current edition; and Mavin, A., et al., “Easy Approach to Requirements Syntax (EARS),” IEEE International Requirements Engineering Conference, 2009.
Office of the Under Secretary of Defense for Research and Engineering, Human Systems Integration Guidebook, May 2022, with Change 1, 2024.
Department of Defense, DoD Instruction 5000.95, Human Systems Integration in Defense Acquisition, 1 April 2022.
Department of Defense, MIL-STD-46855A, Human Engineering Requirements for Military Systems, Equipment, and Facilities, 24 May 2011.
Data Item Description DI-HFAC-81742, Human Engineering Program Plan, 2007, and related DI-HFAC data items for human engineering design approach, analysis, and test documentation.
Contact
HF Designworks, Inc.
PO Box 19911
Boulder, CO 80308
(720) 362-7066