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.