How to write engineering requirements

• shall — binding, testable, mandatory.
  Example: The system shall encrypt all stored passwords using bcrypt.
• should — desirable but not mandatory.
  Example: The API should respond within 200 ms under normal load.
• will — statement of fact or intent, not a requirement.
  Example: Data will be archived for seven years under company policy.

1. Hierarchy matters: start with system-level requirements, then decompose into subsystem and component requirements.
2. Unique IDs: number everything (e.g., REQ-1.2.3). Don’t delete IDs; mark obsolete instead.
3. Atomic statements: one thought per requirement. Avoid “and/or.”
4. Traceability: link each requirement to its source (stakeholder, regulation, standard). Map downward to design and test cases.
5. Verification focus: every shall must be verifiable by test, analysis, inspection, or demonstration.

• REQ-1.1: The device shall operate continuously for 8 hours on battery power. [Test]
• REQ-1.2: The user interface should support dark mode. [Inspection]
• REQ-1.3: The product will be manufactured in Austin, TX. [Context only]

• Each shall has a clear verification method.
• No requirement mixes multiple ideas.
• Numbering and trace links are consistent.
• Stakeholders can understand it without a decoder ring.

Good requirements are boring to read, but delightful to build and test against.