Planning and Requirements Analysis
This domain tests elicitation, analysis, specification, prioritization, and traceability. Questions often present a vague stakeholder statement and ask what to do next, or ask which requirement attribute is missing.
Core rules
- Elicitation techniques include interviews, workshops, observation, document analysis, prototyping, and surveys. Choose based on stakeholder availability, domain complexity, and risk.
- Analysis decomposes needs, resolves conflicts, models context and use cases, and checks requirements for ambiguity, completeness, feasibility, and testability.
- Write requirements with a single clear obligation, measurable acceptance criteria, and a traceable source. Use “shall” for mandatory requirements and avoid vague adverbs such as “fast” or “user-friendly.”
- Prioritize with a defined scheme such as MoSCoW (Must, Should, Could, Won't) or risk-based ranking, and record the rationale.
- Maintain bidirectional traceability: need to requirement, design, test, and acceptance evidence.
Worked example
A stakeholder says, “The portal must be fast.” That statement is not testable. Elicit the context: peak concurrent users, transaction types, and acceptable delay. Rewrite it as: “Under a load of 500 concurrent users, 95% of search requests shall return within 2 seconds on a production-like environment.” The new statement has a measurable threshold, a condition, and a verification method. If a security review adds latency, document the trade-off and adjust the requirement through change control rather than silently relaxing it.
Traps
- Solutionizing too early: capturing a design choice as a requirement without the underlying need.
- Omitting non-functional requirements such as availability, security, maintainability, and capacity.
- Accepting “user-friendly” or “high performance” without acceptance criteria.
- Treating a constraint as a requirement without tracing it to a source.