requirements-specificationlisted

# Requirements Specification Write requirements precisely enough that two different people implementing from the same spec would build the same thing. A vague spec doesn't save time — it just moves the ambiguity (and the rework) later. ## When to use - The ask is underspecified: "add notifications," "make search better," "support teams" — before any architecture or code, pin down what these actually mean. - Multiple stakeholders (or a stakeholder and an implementer) could reasonably disagree about scope. - Skip when the change is small and unambiguous (a one-line bug fix, a well-scoped refactor) — writing a formal spec for those is pure overhead. ## Process ### 1. Requirements gathering Split every requirement into **functional** (what the system does) and **non-functional** (how well it does it — latency, availability, security). Each one needs an id, a priority, and criteria specific enough to fail a "is this actually done?" test: ``` FR-001: System shall authenticate users via OAuth2 priority: high acceptance: - Users can log in with Google/GitHub - Session persists for 24 hours - Refresh tokens auto-renew NFR-001 (performance): API p95 latency <200ms NFR-002 (security): All data encrypted in transit and at rest ``` "Fast" and "user-friendly" are not requirements — they're not testable. Replace them with a number and a measurement method. ### 2. Constraint analysis Separate constraints by kind, since each kind trades off differently: - *