Requirements Engineering and Stakeholder Analysis
What this domain tests
This domain tests whether you can find, classify, negotiate, and verify requirements, and whether you know who genuinely holds a stake. Expect functional versus non-functional requirements, constraints and assumptions, elicitation technique selection, prioritisation methods, and traceability.
Core rules
- Classify before you specify: business requirements (why), stakeholder requirements (what users need), solution requirements (functional and non-functional), and transition requirements (needed only to move from the current to the target state).
- Elicit with the technique that fits the gap. Interviews for depth with few people; workshops for cross-stakeholder conflict; observation for workarounds people cannot articulate; prototyping for unclear interaction or feasibility; document analysis for legacy rules.
- A requirement is only useful if it is verifiable. "The system shall be user-friendly" fails; "90% of trained users complete a claim submission in under three minutes" passes.
- Prioritise explicitly (MoSCoW, Kano, weighted shortest job first); prioritisation is how conflicts get resolved rather than escalated.
- Trace every requirement to a source and to a test. Orphan requirements and orphan tests are both defects.
Worked example
Legal wants seven years of immutable audit logs; operations wants sub-200 ms p95 on claim lookup; the data protection officer wants minimisation. The naive answer keeps everything forever and caches aggressively. Better: separate the append-only, immutable audit store (seven-year retention) from the current-state operational store (indexed, cacheable). Both quality attributes are met because they attach to different artefacts, and minimisation is satisfied by limiting personal data in the audit payload to identifiers plus a reference. Look for a separation-of-concerns answer before a compromise answer.
Traps
- Treating non-functional requirements as a lower-priority class; they are usually the architecturally decisive ones.
- Confusing a constraint ("must run on the existing mainframe") with a requirement to be designed for.
- Accepting a stakeholder's proposed solution as the requirement instead of asking for the underlying need.
- Missing negative requirements ("shall not store card data") and regulatory constraints.