Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
I would avoid relying on any single elicitation technique, because stakeholders may leave requirements unstated for very different reasons. Sometimes they assume something is obvious, sometimes the knowledge is tacit, and sometimes they do not recognize the need until they see a process, scenario or possible solution challenged.
I therefore combine conversation with observation, process and interface analysis, scenarios, prototypes, and questions about exceptions, constraints and failure conditions. Comparing perspectives across stakeholders is particularly valuable because important requirements often become visible at the interfaces between roles rather than within any one stakeholder’s description.
I also distinguish an inferred requirement from a validated one. If observation or analysis suggests a need that nobody explicitly stated, I treat it as a hypothesis to test with the relevant stakeholders, not as permission to define the requirement on their behalf.
For me, the deeper skill is not simply asking better questions. It is creating multiple ways for needs, assumptions and constraints to become visible, and then validating whether what we have inferred actually represents a legitimate need, constraint or obligation. Saving Changes...
A lot depends on how different the product, service or outcome is from what stakeholders have been used to before. It also depends on the value stream and processes it belongs to.
If it is a product, then the use of prototypes or virtual reality simulations by stakeholders as they try to execute their working procedures with team members closely observing what they are doing and how they are doing it can help.
Senior IS Project Manager| Baycare Health SystemsClearwater, Fl, United States
One tool that I picked up in my journey as a LSS Black Belt was the 5 Whys. Here is a link to an introduction, let me know if this is what you are looking for. Five whys - Wikipedia Saving Changes...
I use techniques like stakeholder interviews, observation asking “why” questions, reviewing existing processes and documents and validating assumptions through prototypes or scenarios. I also look for gaps, contradictions and non-functional and system requirements that stakeholders may have assumed. Bringing an expert or SME into the discussion can help uncover requirements based on their prior experience and domain expertise. Tying each requirement to a specific goal and success criteria helps identify missing requirements and ensures alignment to the bigger picture and the final outcome. Saving Changes...
Program Manager| HARPER SRLSanto Domingo / Distrito Nacional, Dominican Republic
One technique I use is to walk through the actual process with stakeholders instead of only asking what they need. When people describe what they do step by step, gaps, exceptions, and dependencies often come up that they wouldn’t think to mention as requirements.
I also ask about what happens when something goes wrong or doesn’t follow the normal process. Those scenarios usually uncover additional requirements. Saving Changes...
Community Champion
