Analysis
Analysis is the largest domain. The exam tests elicitation and the conversion of raw stakeholder input into verified, validated, prioritized requirements and models that developers and testers can use.
Core rules
- Select elicitation techniques by context: interviews for depth, workshops for consensus, observation for tacit work, prototypes for unclear interfaces, surveys for reach.
- Classify requirements: business, stakeholder, solution functional, nonfunctional, and transition. Nonfunctional requirements include performance, security, usability, availability, and compliance.
- Model to expose gaps: process, data, use case, state, decision tables, and interface models.
- Write acceptance criteria that are testable and agreed before build.
- Verification asks whether the requirement is written correctly and is complete and consistent; validation asks whether it is the right requirement for the business need.
- Prioritize with an agreed method such as MoSCoW, weighted ranking, or cost of delay.
Worked example
For an online returns portal, a workshop produces a use case. A state model reveals a gap: what happens when a return is partially received. The BA adds a state for partially received and acceptance criteria for refund amount and timing. A nonfunctional requirement sets 99.5 percent availability during peak. Verification finds an ambiguous term, customer, which is replaced with account holder. Validation with the returns manager confirms the partial-receipt scenario is real. Prioritization puts partial receipt in the first release because it drives 30 percent of manual work.
Traps
Treating verification and validation as synonyms, modeling everything, omitting nonfunctional requirements, accepting vague acceptance criteria, and confusing a stakeholder want with a validated need.