Requirements: What You Actually Want

A requirement is a sentence that describes something the software must do, something it must be, or a constraint it must respect. Requirements are written in the user's language, not the engineer's language.

Three kinds of requirements:

FUNCTIONAL REQUIREMENTS. What the software does. "When a customer submits the contact form, send an email to the owner within five minutes." "Allow the manager to view this week's inventory report." "Block access to the admin page for users without the admin role."

NON-FUNCTIONAL REQUIREMENTS. How well the software does it. "Page loads in under 2 seconds on a 4G connection." "Survives 100 concurrent users without slowdown." "Available 99% of the time during business hours."

CONSTRAINTS. What the software has to live with. "Must work in Safari and Chrome." "Must run on a Mac mini with 16GB of RAM." "Must not require an internet connection for core features." "Must not store customer data on servers outside the United States."

A bad requirement: "The website should be fast." A good requirement: "Pages should load in under 2 seconds on a typical home internet connection."

A bad requirement: "Users should be able to log in." A good requirement: "Customers can log in with their email address and a password they set during signup. After 5 failed attempts in 10 minutes, their account is locked for 15 minutes."

The test: can someone build this without asking you a follow-up question? If yes, the requirement is good. If no, keep writing.

A useful exercise: write 10-20 one-sentence requirements for what you're building. Don't worry about format. Just get them out of your head and into a list. The list is your raw material for the spec in section 2.2.