I define elicitation as the activity I use to discover, collect, and clarify requirements. In requirements engineering, I call this requirements elicitation. First, I set a clear elicitation objective. Then, I choose the right inputs and methods. Next, I capture results and keep traceability to the sources. Finally, I validate the results with stakeholders.
I plan elicitation activities with five elements. Specifically, I name the elicitation objective, I set the desired result quality, I identify the requirements sources, I select the elicitation technique, and I add project management information. For example, I might set the objective to determine diversity among a user group. Then, I might aim to produce valid personas. In addition, I might select service engineers from five global stations as sources. Moreover, I might use contextual inquiry as the technique.
I pay attention to the relationships among these elements. Firstly, the elicitation objective must match the desired result quality. Secondly, the objective must suit the selected requirements sources. For instance, a legacy process document may not help when I need current user behavior. Thirdly, the chosen source must be able to deliver the required quality. In particular, a single stakeholder may not clarify all ambiguous needs. Fourthly, the result quality determines whether a technique can work. Therefore, I pick techniques that can reach the required certainty and completeness. Furthermore, I check how the technique interacts with the source. Similarly, I verify that the objective fits the chosen technique. Thus, I use these relationships to validate and improve each activity.
I plan dependencies among elicitation activities. For example, I may run stakeholder interviews first. Then, I hold a workshop that depends on interview outputs. In addition, I may run multiple techniques for the same objective. Consequently, I sequence tasks to reduce rework. Moreover, I record references from each elicitation activity to the documented requirements. As a result, I maintain traceability between requirements and the activity that produced them.
I choose the elicitation technique as the last planning step. First, I clarify the objective and the needed result quality. Then, I select sources and constraints. Only afterwards do I pick a technique that can deliver the results. For example, I select contextual inquiry when I need to observe real work. Alternatively, I choose interviews when I need individual input. Furthermore, I select workshops when I need group alignment.
I integrate elicitation into the project context. I assume every project uses some plan or backlog. Therefore, I treat elicitation activities as tasks. For example, I add them to a Kanban board or a Gantt chart. In addition, I include resolution activities to handle conflicts. Thus, I connect elicitation with project milestones and resources.
I keep my language simple and my records clear. Moreover, I document objectives, sources, techniques, and quality criteria. Consequently, teams can reproduce and translate the information easily. Finally, I validate results with stakeholders. Ultimately, I refine requirements until they meet the agreed quality and the project needs.