Stakeholder Engagement and Contextual Inquiry
Domain 3 tests stakeholder engagement and contextual inquiry: identifying who matters, separating needs from wants, and understanding how the context of use shapes requirements.
Core rules and concepts
- Stakeholders include users, operators, maintainers, acquirers, regulators, and affected parties-not only the paying customer.
- A need is an outcome required in context; a want is a proposed solution. Elicitation separates them before specification.
- Contextual inquiry observes work as performed, including workarounds, environmental constraints, information flows, and tacit knowledge.
- Stakeholder analysis records interest, influence, and impact. Engagement is planned, documented, and revisited as the context changes.
Worked example
A rural clinic requests a diagnostic device with a "simple interface." Interviews produce adjectives. Observation shows intermittent power from a shared generator, dust, limited biomedical support, and operators with varied literacy. The team converts the need into requirements for ride-through, sealed enclosure, and a validated maintenance concept. Reasoning: the operational context, not the interview phrase, drives the requirement. The stakeholder's wish is evidence, not a specification.
Traps that cost marks
- Treating the sponsor or buyer as the only stakeholder.
- Recording wishes as needs without validation in context.
- Ignoring indirect stakeholders such as maintenance, sterilization, and disposal staff.
- Assuming a requirement is context-free.
- Engaging once at the start and never revisiting stakeholders as the system changes.
Key points
- Stakeholders are broader than customers.
- Needs are outcomes; wants are solutions.
- Contextual inquiry observes real work.
- Stakeholder analysis is planned and recorded.
- Context shapes verifiable requirements.