Gathering Requirements

Different situations call for different requirements-gathering tools. A user story captures a requirement from the end user's point of view, in a short, consistent format ("As a [role], I want [goal], so that [benefit]"), and fits adaptive work well. A use case describes a more detailed, step-by-step interaction between a user and a system, including alternate paths, and tends to suit more complex or predictive work. One-on-one stakeholder interviews surface individual, nuanced input; surveys gather broad input efficiently from a large group; workshops bring multiple stakeholders together to align in real time; and reviewing lessons learned surfaces requirements insight from past, similar projects before starting fresh.

A requirements traceability matrix (RTM) links every requirement back to its source and forward to the deliverable that satisfies it, so nothing gets lost and nothing gets built that wasn't actually asked for. In adaptive work, the product backlog plays an overlapping role — it's the living record of what's wanted, ranked by priority, that the RTM's more formal, predictive-style traceability doesn't usually attempt to replicate in full.

Study focus: a scenario naming a specific situation (e.g., "the team needs quick, broad input from 200 end users before the next release") is asking you to pick the matching tool (a survey, here) — these questions reward matching method to context, not reciting a list of tool names.