Ask ten engineers what a requirement is and you will get ten answers, most of them describing a feature. In functional safety, a requirement is something more specific and more demanding: a verifiable statement of what the system must do, tied to a hazard it exists to control. Get this wrong at the start and every downstream artifact inherits the ambiguity.
01A requirement is verifiable, or it is a wish
The test is simple: can you write down, in advance, the evidence that would prove the requirement is met? “The system shall be safe” fails that test. “Emergency stop shall reach safe torque-off within 250 ms” passes it. A requirement you cannot verify cannot anchor a safety case.
02Every requirement carries its source and its proof
A defensible safety requirement is traceable in two directions at once: back to the hazard or analysis that motivated it, and forward to the verification activity that confirms it. Requirements written without that lineage are the ones that resurface as findings late in a program — when fixing them is most expensive.
Treat requirements as the load-bearing units of the safety argument and the rest of the lifecycle has something solid to stand on.
