How do you prepare for a requirements elicitation session?

Before starting the elicitation, it is crucial to understand the purpose of elicitation. Consider the following for understanding the scope and purpose: Business domain, Overall corporate culture and environment Expected outputs the elicitation activities Strategy or solution approach Scope of future solution

Define the purpose plays an important part in requirements elicitation as its serves as a guiding principle to understand the objectives and clarify the project goals. It helps the team to understand the stakeholders needs, align with business objectives and also set scope and boundaries. I will say it is the foundation for a very successful project.

Proper identification of stakeholders (individuals or group who have interests in the outcome of the project ) helps the team understand their expectations and needs, this will help manage and in delivering a successful project. This can be done through stakeholders analysis, project charter and documentation, historical project data is an effective way in identifying of stakeholders.

Stakeholder analysis involves identifying the Stakeholders (who will be directly or indirectly impacted by the change) and their characteristics, as well as analyzing the information once collected. Consider the following techniques for identifying the stakeholders: Problem Statement RACI chart Organizational modeling Stakeholder persona

I think the first thing you need to do when looking at a specific space to build a product/solution for is start with the Users. What are the Jobs to be done? What are the pains they currently feel with their existing process and tools? What would they gain with a new product/solution? Subsequently there are stakeholders who will focus on the cost of building the product/solution and what can it be sold for, BUT you shouldn’t be building products/solutions which you then have to sell the customer on their need for them.

Logistics are important and should be planned prior to an elicitation. consider the following for confirming the logistics: The activity's goals, Participants and their roles, Scheduled resources, including people, rooms, and tools, Locations, Communication channels, Techniques

It’s been years since I gathered requirements in this way. My comment is, if you are dealing with a product that, in Cynefin terms, is Simple or Complicated, this approach can work. If the problems are known or knowable and the solutions predictable, you can do long term planning and requirements. In my software product experience, I have rarely encountered such products. If you are following an Agile approach and you are dealing with complex problems with many unknowns, an iterative, customer-focused approach will allow you to understand your customer, experiment with possible solutions and inspect and adapt as you go.