How to write good requirements?

Requirements are everywhere in MedTech, and knowing how to write them is a valuable skill.

In this playbook, I’ve compiled the best practices I’ve come across, along with some theory and examples.

Good requirements prevent rework, delays, and misunderstandings in projects, which is why this playbook covers the following topics:

→ Why device specifications grow large and why that’s normal when clinical, safety, service, and regulatory teams all have a seat at the table

→ How to frame any need as a user story before writing a single line

→ The four parts of a well-formed requirement: condition, subject, object, constraint of action

→ Which verb to use : shall, should, will, may and why picking the wrong one creates ambiguity during verification

→ Five characteristics that make a requirement set stand up to review: complete, consistent, feasible, comprehensible, verifiable

→ A structure checklist to organize hundreds of requirements without losing track

What you get out of it:

A repeatable method you can apply to your next project. Fewer review cycles. Fewer “that's not what we meant” conversations. A spec your whole team can read and navigate.