1. Requirements: FRs, NFRs, Constraints, and Assumptions

System design starts with a clear business need and a requirement baseline. Functional requirements (FRs) define required behavior. Nonfunctional requirements (NFRs) define measurable quality targets. Constraints define boundaries the design must respect. Assumptions are things we currently believe but still need to validate. Architecture trade-offs only make sense when these are visible.

Terminology note

“NFR” is common software terminology, but standards often speak more precisely about quality requirements and constraints. In this book, NFR means a measurable quality requirement. Fixed mandates and assumptions are tracked separately so they do not disappear inside a vague “NFR” bucket.

Evidence: S1, S2, S46, S47, S53

What good requirements look like

Clear and singular: one requirement should express one understandable need.

Verifiable: define how compliance can be shown by test, analysis, inspection, demonstration, telemetry, or another explicit method.

Traceable: use an ID and link the requirement to its source, design, implementation, and verification evidence.

Feasible and bounded: define relevant load, data, geography, dependencies, limits, and operating conditions.

Owned and prioritized: know who can clarify or change it and how important it is when trade-offs appear.

Assumptions visible: do not baseline a critical assumption as if it were a confirmed fact.

Evidence: S2, S23, S31, S46, S53

Common failure

“Highly available, secure, scalable, fast” is not a usable NFR set. It gives no testable target and no basis for trade-offs.

Checklist

• Business goal and expected outcome are clear.
• Functional scope is clear, including what is out of scope.
• Critical user and business flows are named.
• Important requirements have stable IDs or another traceable identifier.
• Requirement source/owner and priority are known.
• Acceptance criteria or verification method are defined where the requirement needs proof.
• Expected traffic and peak traffic are estimated.
• Data volume, growth, retention, and geography are estimated.
• Latency target is measurable, preferably using percentiles for user-facing paths.
• Throughput/capacity target is measurable.
• Availability target is defined for critical flows.
• RPO and RTO are defined where data loss or downtime matters.
• Security/compliance requirements are explicit.
• Cost or budget constraints are explicit.
• Technology, regulatory, residency, deadline, or organizational constraints are explicit when they are truly fixed.
• Important assumptions have an owner and a plan to validate or revisit them.
• Dependencies and third-party limits are known.
• NFRs are prioritized when they conflict.
• Each important NFR has a pre-production proof method and, where ongoing compliance matters, a production signal.

Evidence: S1, S2, S23, S24, S31, S32, S46, S53