requirements-analysis

## Overview Requirements analysis converts stakeholder requests into verified, unambiguous, testable requirements. It identifies conflicts, gaps, and hidden constraints before they become expensive bugs. ## When to Use - After gathering stakeholder input but before writing specs - When requirements come from multiple sources that may conflict - Before estimating effort on a project - When the system must integrate with external systems or regulations ## Process ### Step 1: Collect all sources Gather: tickets, meeting notes, existing docs, similar systems, regulatory requirements, user research. Document each source. ### Step 2: Extract and categorize requirements Sort into: - **Functional** — What the system does - **Non-functional** — How well it does it (performance, security, availability) - **Constraints** — What the system cannot do or cannot use - **Assumptions** — Things believed true but not verified ### Step 3: Check for ambiguity Flag any requirement that uses: "fast," "easy," "simple," "scalable," "secure," or any other unmeasured adjective. Replace with measurable criteria. ### Step 4: Check for conflicts List pairs of requirements that could contradict each other. Example: "must respond in under 100ms" vs "must encrypt all data at rest and in transit." Resolve or prioritize explicitly. ### Step 5: Check for completeness Ask: What happens when X fails? What are the edge cases for Y? What permissions are required? What should happen with invalid input? ### Step 6: Validate with stakeholders Walk through the requirements list with at least one stakeholder. Every ambiguity you resolve costs nothing here; every ambiguity you miss costs exponentially more later. ### Step 7: Prioritize Label each requirement: **Must Have** / **Should Have** / **Nice to Have** (MoSCoW). Scope the first version to Must Haves only. ### Step 8: Create a traceability matrix Link each requirement to its source. This allows you to answer "why does this requirement exist?" at any point. ## Anti-Rationalizations **"We can figure out edge cases as we go"** Edge cases figured out during implementation become design debt. Edge cases figured out during requirements analysis become requirements. **"The stakeholder said it clearly"** Verbal clarity is not written clarity. What they said and what they meant often diverge when you write it down and ask them to confirm. ## Verification Requirements - [ ] All requirements are measurable (no unmeasured adjectives) - [ ] No unresolved conflicts between requirements - [ ] Edge cases documented for all critical flows - [ ] Requirements prioritized with MoSCoW - [ ] Traceability matrix exists (requirement → source) - [ ] Stakeholder sign-off obtained