vignesh2027 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