Chapter 4: Requirements Gathering and Analysis

Why this matters

More production software fails to meet its actual need because of a requirements misunderstanding than because of a coding bug — and this failure mode is uniquely expensive because it's often invisible until late: the code works exactly as specified and still fails to solve the actual problem, because the specification itself was wrong. Requirements gathering is the stage most responsible for preventing this specific, costly failure mode.

Functional vs. non-functional requirements

[BEGINNER] Functional requirements describe what the system should do (specific behaviors, features, business rules). Non-functional requirements describe qualities the system must have regardless of specific features — performance, security, availability, scalability, usability. Both matter, and non-functional requirements are the more commonly neglected of the two, since they're less visible in a feature list and easier to postpone thinking about until late:

Functional: "Users can filter their order history by date range."

Non-functional: "The order history page must load within 2 seconds for
a user with up to 10,000 orders" — this requirement, if omitted, doesn't
prevent the functional feature from technically working; it just means
nobody designed for it, and the feature might work fine in testing (with
a handful of test orders) and fail badly in production for a real,
high-volume user.

The five whys: getting past a stated request to the actual underlying need

[SENIOR INSIGHT] A stakeholder's initial request is frequently a proposed solution, not the actual underlying need — and building exactly what was literally requested can miss the real need entirely if the requested solution turns out to be a poor fit. The five whys technique (repeatedly asking "why" to a stated request) surfaces the actual underlying need:

Stakeholder request: "We need an 'export to CSV' button on the reports page."

Why? "So users can look at report data in Excel."
Why? "Because our reports page doesn't let users sort or filter by
      multiple columns at once."
Why? "Because we never built multi-column filtering into the reports UI."

Actual underlying need surfaced: users need better ways to slice and
analyze report data — CSV export was ONE possible solution the
stakeholder proposed, but multi-column filtering directly in the UI
might serve the actual need better, without requiring users to leave
the application and use a separate tool at all.

This doesn't mean the stakeholder's originally requested solution is always wrong — sometimes CSV export genuinely is the best answer — but understanding the underlying need means the team can evaluate multiple possible solutions against the actual problem, rather than building exactly what was asked for without ever confirming it's the best way to solve the real issue.

User stories and acceptance criteria

[BEGINNER] A common, effective format for capturing a functional requirement at a working level of detail, widely used in Jira and similar tools:

User story: "As a returning customer, I want to see my past order history,
so that I can reorder items I've purchased before without re-searching."

Acceptance criteria (specific, testable conditions that define "done"):
- Order history is accessible from the account menu.
- Orders are displayed in reverse chronological order by default.
- Each order shows date, items, and total.
- A "reorder" button on each past order adds all its items to the current cart.
- If an item is no longer available, it's excluded from the reorder with
  a visible note, rather than silently failing or blocking the whole reorder.

[IN PRACTICE] The acceptance criteria are doing real work beyond the user story itself — the user story captures why (motivation, per the "why" discipline above), while the acceptance criteria capture exactly what counts as complete, removing ambiguity about edge cases (like the unavailable-item case above) before implementation starts, rather than discovering that ambiguity during testing or, worse, after release.

Requirements change — plan for it, don't fight it

[SENIOR INSIGHT] Chapter 2 covered how different SDLC models handle changing requirements differently — but regardless of model, requirements will change to some degree on nearly every real project, because genuinely complete upfront understanding is rare, especially for anything genuinely new. The practical discipline isn't "prevent requirements from changing" (usually unrealistic) but "make the cost of a requirements change visible and proportionate to the stage it's discovered at" — a change identified during requirements gathering is nearly free; the same change discovered after implementation is complete is expensive, and a change discovered after release (requiring a redesign of already-shipped, in-use functionality) is the most expensive of all. This is the direct, practical argument for iterative approaches (Chapter 2): they surface requirements misunderstandings at the cheapest possible point, by getting working software (and real feedback) in front of stakeholders early and often, rather than waiting for one large, late reveal.

Common mistakes

1. Building exactly what was literally requested without probing for the actual underlying need, potentially missing a better solution to the real problem, or building something technically correct but practically unhelpful.
2. Neglecting non-functional requirements because they're less visible than a feature list, only discovering a performance, security, or scalability gap once it causes a real production problem.
3. Writing user stories without concrete, testable acceptance criteria, leaving ambiguity about edge cases to be discovered during testing or after release, rather than resolved during requirements analysis.
4. Treating every requirements change as a failure of the original gathering process, rather than recognizing that some degree of change is normal and planning a process (iterative development, Chapter 2) that makes the cost of discovering it proportionate to how early it's caught.

Checklist: gathering and analyzing requirements well

1. Ask "why" repeatedly on a stated request to distinguish a proposed solution from the actual underlying need, before committing to build exactly what was literally asked for.
2. Explicitly elicit non-functional requirements (performance, security, scalability, availability) alongside functional ones — don't let them go undiscussed until a production problem surfaces the gap.
3. Write concrete, testable acceptance criteria for every requirement, resolving edge-case ambiguity during analysis rather than during testing or after release.
4. Choose (or confirm) a process that surfaces requirements misunderstandings early (iterative development, frequent stakeholder feedback) rather than assuming requirements gathered once at the start will remain fully accurate throughout the project.

Discussion / interview questions

1. "What's the difference between functional and non-functional requirements, and why are non-functional requirements often neglected?" Strong answer: Functional requirements describe specific behaviors/features; non-functional requirements describe qualities like performance, security, and scalability that apply regardless of specific features — they're often neglected because they're less visible in a feature list and easier to postpone considering until a production problem forces the issue.

2. "A stakeholder asks for a specific feature. How would you determine whether that feature is actually the best solution to their underlying need?" Strong answer: Uses a technique like the five whys — repeatedly asking why the requested feature is needed — to surface the actual underlying problem, then evaluates whether the originally requested solution (or an alternative) best addresses that underlying need, rather than building exactly what was asked without further analysis.

3. "Why do acceptance criteria matter, beyond a user story's narrative description?" Strong answer: Acceptance criteria capture exactly what counts as "done" in specific, testable terms, resolving edge-case ambiguity (like what happens with an unavailable item during a reorder) during requirements analysis — before implementation, rather than discovering the ambiguity during testing or after release.

4. "Why does the cost of a requirements change depend so heavily on when it's discovered?" Strong answer: A change identified during requirements gathering costs little to nothing (nothing has been built yet); the same change discovered after implementation requires reworking built code; discovered after release, it requires redesigning already-shipped, in-use functionality — the same underlying change gets progressively more expensive to accommodate the later it's caught, which is the core practical argument for iterative, feedback-early approaches.

Chapter summary / cheat sheet

• Functional requirements (what the system does) and non-functional requirements (qualities like performance and security) both need explicit attention — non-functional requirements are more commonly neglected since they're less visible.
• The "five whys" technique distinguishes a stakeholder's proposed solution from their actual underlying need, avoiding building exactly what was asked for without confirming it's the best answer to the real problem.
• User stories capture motivation ("why"); acceptance criteria capture exactly what counts as complete, resolving edge-case ambiguity before implementation.
• Requirements will change on nearly every real project — the practical goal is making the cost of a change proportionate to how early it's discovered, which is the core argument for iterative development.

---