Requirements Elicitation and Solution Design
Requirements Elicitation and Solution Design
This domain tests how you gather, validate, prioritize, and trace requirements, then shape a solution that meets the business outcome without over-designing.
Core rules
- Map stakeholders by influence and interest; use interviews, facilitated workshops, observation, and document review, not a single source.
- Capture current state and future state; record assumptions, constraints, dependencies, and decisions in a decision log.
- Write requirements with a unique ID, owner, rationale, acceptance criteria, and priority. Use MoSCoW for negotiation, not as a substitute for sign-off.
- Separate functional requirements from non-functional requirements such as performance, availability, security, usability, and compliance.
- Maintain a requirements traceability matrix from requirement to design, build, test, and UAT.
- Run a fit-gap analysis: standard fit, configuration, customization, or process change.
Worked example
Finance wants month-end close locked at day three; operations needs late adjustments. A workshop exposes that the real need is controlled late adjustment, not an open close. The team defines a must-have control: late entries require controller approval and are logged. The design uses a standard approval workflow, avoiding a custom close module. Reasoning: reconcile conflicting wants by finding the underlying control objective.
Traps
- Jumping to a solution before confirming the problem.
- Leading questions that manufacture agreement.
- Missing non-functional requirements until testing.
- Ambiguous terms such as fast or user-friendly.