Planning, Design, and Requirements Analysis
From need to verifiable requirement
Planning converts a need into something you can build, test, and defend. Start with stakeholder analysis: identify who is affected, who approves, who operates, and who is exposed to the hazard, then capture needs separately from wants. Classify requirements as functional (what the thing must do) versus non-functional or performance (how well: throughput, tolerance, availability, environmental limits, human factors) and separate regulatory requirements, which are non-negotiable and must be traceable to a source.
Every requirement should pass the SMART-for-requirements test: specific, measurable, achievable, relevant, and testable. If you cannot write the acceptance criterion, the requirement is not finished. Maintain a traceability matrix linking source → requirement → design element → verification method → evidence; change control protects it, and any change that touches a safety function triggers re-analysis, not just a schedule update.
Design-stage risk work
Hazard analysis belongs in design, when change is cheap: preliminary hazard analysis early, HAZOP for process deviations, FMEA for failure modes and their detection. Design reviews are gates, not ceremonies - a preliminary review confirms the concept and requirements baseline; a critical review confirms the design can meet them and that hazards are controlled.
Traps
The common wrong answers are: treating an unvalidated assumption as a requirement; accepting a vague requirement because the customer used confident language; gold-plating beyond scope; and deferring safety review to commissioning. Also watch for scope creep disguised as "clarification."
Worked example
"Equipment must be safe" fails the test. Rewrite: "The guard shall prevent access to the nip point and withstand a 100 N force without permanent deformation; verified by physical test at acceptance." Now it has a criterion and a verification method.