Planning and Requirements Analysis
What this domain tests
This domain asks how you turn a vague need into a testable, prioritised, agreed set of requirements, and how you plan the work to deliver them. Questions probe elicitation technique choice, requirement quality, scope control, estimation, and stakeholder management.
Concepts to master
Know the characteristics of a good requirement: unambiguous, complete, consistent, verifiable, feasible, and traceable. Understand elicitation methods - interviews, workshops, observation, prototyping, document analysis, surveys - and when each fits: observation for tacit work, workshops for resolving conflict, prototyping for unclear interfaces. Understand MoSCoW and other prioritisation schemes, scope creep vs gold plating, assumptions and constraints, and acceptance criteria. Know the difference between a stakeholder and a sponsor, and why a requirements traceability matrix exists.
Traps in questions
Questions love to present a technique that is efficient but wrong for the situation - a survey when you need to discover unknown unknowns, or a prototype when the requirement is already fixed by regulation. Another trap is treating a stated solution ("we need a dashboard") as a requirement; the underlying need must be elicited. Watch for options that add scope under the label of quality.
Worked rule of thumb
For any elicitation question, ask: does the analyst know what to ask? If yes, structured techniques (interviews, surveys) work. If no, use discovery techniques (observation, prototyping, workshops). This single test resolves most technique-selection items.
Planning discipline
Estimates should state their basis and uncertainty; a single-point estimate with no assumptions is a red flag. Plan for review cycles and requirement sign-off, because unapproved requirements are the leading cause of rework.