Functional requirements

Functional requirements describe what the system does: user-visible operations, APIs, workflows, and data mutations. Write them as verbs with actors — "user posts a message," "admin bans account," "system sends digest email" — not as technology choices.

Group flows by priority so the high-level design covers the critical path first. Link each flow to inputs, outputs, and consistency expectations so later API and data model steps are grounded.

On interviews: list five to seven core operations for the prompt, note sync versus async behavior, and flag which flows need strong consistency.

Common pitfalls: listing features without user journeys; mixing functional and non-functional items; designing for edge cases before the happy path works.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

• Enumerate primary user and system operations.
• Separate must-have from nice-to-have flows.
• Note sync versus async per operation.
• Tie each flow to data created or read.