Requirements management is the systematic process of eliciting, documenting, analyzing, tracking, and validating the needs and expectations of stakeholders throughout a project's lifecycle. Rooted in business analysis and systems engineering, it serves as the critical bridge between stakeholder vision and successful delivery, ensuring that what gets built aligns with what's actually needed. A well-managed requirements process prevents costly rework, scope creep, and project failure—studies consistently show that requirements defects discovered late in development cost exponentially more to fix than those caught early. The discipline balances competing concerns: capturing enough detail to be actionable while remaining flexible enough to accommodate change, all while maintaining traceability from business goals through implementation to acceptance testing.
What This Cheat Sheet Covers
This topic spans 13 focused tables and 123 indexed concepts, 122 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: Requirements Elicitation Techniques
Elicitation is how requirements are drawn out of stakeholders, and choosing the right technique for each situation—structured vs. exploratory, individual vs. collaborative—determines the quality of what you capture. No single technique covers everything; effective BAs combine several across a project.
| Technique | Example | Description | |
|---|---|---|---|
One-on-one: "Walk me through your daily workflow"Group: Round-robin discussion with 3-5 SMEs | • Structured or semi-structured conversations with individual stakeholders • best for uncovering nuanced needs and the real vs. stated requirement | ||
Full-day facilitated session with cross-functional teamCollaborative whiteboard mapping of user journey | • Joint Application Development sessions bringing stakeholders, users, and developers together to define requirements collaboratively in real-time • most efficient for reaching consensus quickly | ||
Low-fidelity paper sketches → clickable Figma mockupInteractive prototype for usability testing | • Creating tangible representations of solution concepts to elicit feedback early • effective because users who cannot articulate requirements can react to something concrete | ||
Shadow customer service rep for 2 hoursTime-motion study of warehouse picking process | Watching users perform actual tasks in their environment to discover unstated needs and workarounds invisible in interview responses. | ||
Online form with Likert scale + open-ended questionsNPS survey sent to 1,000 users | • Structured data collection from large stakeholder populations • useful for quantifying opinions and priorities at scale. | ||
Rapid ideation: 50 ideas in 15 minutes, no judgingMind map clustered by theme | • Group creativity technique to generate ideas quickly without judgment • exposes unknown unknowns that structured questioning misses | ||
8-10 users discuss feature prototypes for 90 minutesFacilitated discussion with target demographics | • Moderated group discussion exploring attitudes and preferences • useful when stakeholder feedback is sparse and you need to chart direction | ||
Sticky-note workshop: Domain Events → Commands → Aggregates → Bounded Contexts | • Workshop-based technique invented by Alberto Brandolini for rapidly exploring complex business domains • uses colored stickies on a timeline to surface Domain Events, hotspots, and system boundaries | ||
"As a [role], I want [feature] so that [benefit]"Use case: Actor → Goal → Happy/Alternate paths | • Describing system behavior from the user's perspective • captures who wants to do what and why. | ||
Review existing SOP, system logs, regulatory docsAnalyze competitor product specs and marketing materials | Examining existing documentation, systems, and artifacts to extract requirements and constraints without requiring stakeholder time. | ||
Catalog all integration points with external systemsMap data exchanged between modules | • Identifying and documenting touchpoints between systems, applications, and external entities • essential in integration-heavy projects | ||
Why is checkout failing? → Why → Why → Why → Why?Fishbone diagram with 5-Why chains per spine | • Iterative questioning technique — asking "why" up to five times — to trace surface symptoms to their root cause before specifying requirements • prevents solving the wrong problem | ||
Analyze top 3 competitors' feature setsMeasure industry-standard response times | Studying competitor products, industry standards, and best practices to establish performance targets and requirements baselines. | ||
Decompile legacy system behavior → document as-isTest existing UI flows to discover undocumented business rules | Analyzing existing systems to understand current capabilities when original documentation is missing or incomplete. |