> For the complete documentation index, see [llms.txt](https://docs.7ft10.com/flow-system/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.7ft10.com/flow-system/topics/ceremonies/elicitation.md). # Elicitation {% hint style="success" %} ***We use this to** .... **so that we can** ....* {% endhint %} Elicitation is the obtaining of information from the right stakeholders and other relevant sources. The main purpose is to draw out, explore and identify information relevant to the change. It is the main path to discovering: * requirements * design information ### **Preparation for planned elicitation** * Understand the scope of the elicitation activity * Select appropriate techniques * Make sure you have the right stakeholders for the activity * Plan for appropriate resources/materials * Establish logistics * Define desired /goals * Define desired outcomes * work products produced ### **Mindset to be in when facilitating Elicitation** * Genuinely wanting to learn * Curious * Ask **WHYs** to * Challenge * Understand * Make sure there is value * Teach * Make sure to cover **5 Ws and 2 Hs**
* What - is the problem? * Who - finds this a problem? * Where - is the problem occurring? * When - did the problem start? * Why - is this a problem? * How - is the problem observed? * In what mode/situation did the issue occur? * How - often does the problem occur? * frequency of problem occurring; a form to quantify the problem Essentially, by the end of a requirements elicitation session, we want to be clear of: * what the **scope** of the piece of work is * **features** that we are building is clear to all stakeholders (**EPICS**) * if it is a new project, confirm what is the Minimum Viable Product (**MVP**) for the first release * be mindful and manage scope creep * what the **assumptions** are * attempts have been made to clear out as many assumptions out as possible * **who** actually needs them and it is not assumed that they need it * there are **valid reasons** for the need * pretty much the business and technical stakeholders have been challenged to know that we **really do need** the solution * what the **solution options** could look like, platforms, application, technology constraints, knowledge constraints, etc. (very much depends on the project) * More high level at this point; solution options exploration * Where possible and it makes sense, we'd leave the solution to the delivery team * agreed **To-be process** (if applicable) is made clear to all stakeholders * highlight what aspects could potentially change, if we know ### **Benchmarking and Market Analysis/Research** Benchmarking is done by comparing a specific process, system, product, service, or structure with some external baseline, such as a similar organisation or baseline provided by an industry association. Market analysis is used to determine what customers want and what competitors provide. ### **Brainstorming** Group activity where a team works together to find a solution for a specific problem or come up with new ideas. #### **Benefit:** You can avoid potential “gotchas” down the road by enlisting others to help you discover your unknowns. Also, more than most other methods, brainstorming enables you to take in a wide amount of information at once, helping you figure out where you want to go from here. #### Useful for: Generating various ideas from a group of stakeholders in a short period and organise and prioritise those ideas #### Make sure to: * Designate a facilitator * Timebox the session * Establish criteria to evaluate ideas * Never allow criticism ### **Business Rules Analysis** Identify the rules that govern decisions in an organisation and that define, constrain, or enable organisational operations. ### **Collaborative Games** Develop a better understanding of a problem and/or stimulate creative solutions ### **Concept Modelling** Identify key terms and ideas of importance and define relationships between them ### **Data Mining** Identify relevant information and patterns ### **Data modelling** Understand entity relationship ### **Document Analysis** Review existing systems, contracts, business procedures and policies, standards and regulations to elicit requirements E.g. * Business Plan * Project Charter * Contracts * Statement of Work * Memos * Email * Business Rules Documentations * Existing older requirements documentation (if most are still valid) #### Useful when: * SME's are not available * Checking out what’s already there. Look at the user guides, previous requirements, and existing systems of their own organization. #### Drawback * Could take a long time and potentially what you are reading is out of date and it could mislead you ### **Focus Groups** Identify and understand ideas and attitudes from a group #### Useful when: * You haven’t gotten a lot of feedback from customers or users through Customer Service complaints, responses to the sales force, or any other avenue, and you need to explore their thoughts to chart your direction. ### **Interface Analysis** Understand the interaction, and characteristics of that interaction between entities (e.g. systems, organisations, people, roles, etc.) ### **Interviews** Ask questions of stakeholders to uncover needs, identify problems, or discover opportunities e.g. * What does the current system look like? * What are the challenges? #### Format/Types of Interview: * Formal / Informal * Individual / Group * Face to face / Phone / Video conference * Open ended questions to find information & gaps * Closed ended questions to confirm / validate #### **Benefit:** By exploring someone’s knowledge and needs in-depth, one-on-one, you ensure you understand the real, not just the perceived, need. #### Useful for: * To find answers * Help one to understand the problems #### Drawback: * Not a good way to reach common consensus ### **Mind Mapping** Generate various ideas from a group of stakeholders in a short period and organise and prioritise those ideas ### **Observation** Gain insight about how work is currently done, possibly in different locations and in different circumstances #### **Benefit:** You can figure out exactly where users are at the start of your project, and you can use your strengths to document it. ### **Process Analysis** Understand current processes and identify opportunities for improvement in those processes ### **Process Modelling** Elicit process with stakeholders during elicitation activities ### **Prototyping** Elicit and validate stakeholders' needs through an iterative process that creates a model of requirements or designs. As the saying goes "A picture is worth a 1000 words". Stakeholders generally love it. #### **Benefit:** You can make sure that what you’re designing is really what people need while you still have time to change it. #### Useful for: * when dealing Non technical stakeholders (like business owners and non technical end users) who will better relate to a visual representation to the end product * when working out feasibility with UI design * allows understand of customer needs and can make frequent changes to design at a relatively low cost #### Who creates them: * BA/PO * Paper/Whiteboard & pen * Any wireframing tool (e.g. Balsamiq, gomockingbird.com, etc.) * Dev * End product software itself * UI Designer * Designing tool (e.g. Adobe) #### Drawback * Works well only when delivery team (which includes the business decision maker e.g. PO) sits together and/or are readily available. (especially in Agile environment) ### **Survey/Questionnaire** Elicit business analysis information, including information about customers, products, work practices, and attitudes, from a group of people in a structured way and in a relatively short period of time #### Useful when: * You have a large audience to gather information from * Your interviewees are scattered around time zones, making a virtual meeting or focus group unfeasible. ### **Workshop** Elicit business analysis information, including information about customers, products, work practices, and attitudes, from a group of people in a collaborative, facilitated way. Usually a cross functional team: * Marketing * BA * PO * Developers * Testers * Project Management * SME #### **Benefit:** You can get your basic requirements done in a hurry. Also, everyone you invite can become invested in the project. #### Useful for: * Elicit requirement * Refine requirements #### Drawback: * Could take a long time (from a few hours to a few days)
Useful links: * For more structured discussion, some approaches to explore: * [6 Thinking Hats](https://mgrush.com/blog/debono-six-thinking-hats/) * [FMEA](https://asq.org/quality-resources/fmea)