Requirements Gathering Techniques

I've spent over 4,000 hours in stakeholder requirement-gathering meetings! Save hours of your life by asking these questions: 1. What do they plan to use the data for? 1. What initiative are they working on? 2. How will this initiative impact the business? 3. Is this for reporting or optimizing existing workflows? Understanding the purpose of the data helps you define its impact. 2. How do they plan to use the data? Will they access it via SQL, BI tools, APIs, or another method? 1. Do they have a workflow to pull data from your dataset? 2. Do they just do a `SELECT *` from your dataset? 3. Do they perform further computations on your dataset? This determines the schema, partitions, and data accessibility needs. 3. Is this data already present in another report/UI? 1. Is this data already available in another location? 2. Do they have parts of this data (e.g., a few required columns) elsewhere? Ensuring you're not recreating work saves time and avoids redundancy. 4. How frequently do they need this data? 1. How frequently does the data actually need to be refreshed? 2. Can it be monthly, weekly, daily, or hourly? 3. Is the upstream data changing fast enough to justify the required latency? Understanding frequency helps you determine the pipeline schedule. 5. What are the key metrics they monitor in this dataset? 1. Define variance checks for these metrics. 2. Do these metrics need to be 100% accurate (e.g., revenue) or directionally correct (e.g., impressions)? 3. How do these metrics tie into company-level KPIs? Memorize average values for these metrics; they’re invaluable during debugging and discussions. 6. What will each row in the dataset represent? 1. What should each row represent in the dataset? 2. Ensure one consistent grain per dataset, as applicable. 7. How much historical data will they need? 1. Does the stakeholder need data for the last few years? 2. Is the historical data available somewhere? Ask these questions upfront, and you'll save countless hours while delivering exactly what stakeholders need. - Like this post? Let me know your thoughts in the comments, and follow me for more actionable insights on data engineering and system design. #data #dataengineering #datastakeholder

How I Elicit requirements as a Business Analyst (for a brand new project in the planning phase) When a new project kicks off, I’m not diving straight into the details. Instead I start by setting the right foundation. Get clarity and structure first, and then move into documentation. Here’s my approach → Understand the business context. What are we trying to solve? Why now? If you skip this, you’ll end up capturing requirements with no real direction. → Map out key stakeholders. And don’t just talk to the usual suspects… bring in Legal, Compliance, Security, etc., early. Cross-functional input now = less rework later. → Break the project into logical categories. Before jumping into process maps or detail, I define the bones - the high-level steps or categories of the process or journey that your project is implementing. This structure helps guide future workshops and gives everyone a clear mental model of the scope. → Capture high-level requirements. Meet with stakeholders and start gathering their inputs. Use the categories above to guide discussions… and where it helps, co-design the high-level process to elicit requirements. I then use user stories at this stage; it keeps things outcome-focused, even when we’re still defining the “what.” → Document just enough. No 50-page BRDs here. I use Jira, Confluence and lightweight templates that the whole team can actually engage with. → Engage stakeholders to validate. Don’t assume your documentation speaks for itself. Walk stakeholders through what’s been captured… clarify assumptions, confirm priorities, and bring them along the journey. It’s the easiest way to spot gaps early and avoid those “wait… that’s not what I meant” moments later. → Baseline and prepare for the next phase. Once validated, baseline the high-level requirements and identify any dependencies or open items. This creates a clear handover point; setting you up for detailed requirements, solution design, or sprint planning in the next phase. → The goal at this stage? Clarity, alignment, and momentum - not perfection. If you follow these steps, I promise: → Your stakeholders are going to be happy → Requirements higher quality → Reduce risks of missed requirements → Much higher chance of project success If this resonated with you → that’s exactly what we teach in our BA Mentoring sessions in BA Bootcamp. We focus on practical skills that make your work clearer, your stakeholders happier, and your value stand out. As always, like, repost and add a comment if you found this interesting… How do you approach your requirements when you’re starting a brand new project?

📌 Dashboard Requirements Gathering 101 (How to Drive Real Decisions & Adoption) The success of a Data or BI project doesn’t start with the tool you pick or the stack you deploy. It starts earlier. It starts with something less exciting, but far more important: gathering clear business requirements. And yet, this is the step that gets skipped the most. Everyone wants to talk about architecture, pipelines, medallion layers, AI copilots… But if you don’t know what the business actually needs, none of that matters. So what does "gathering requirements" actually look like? It means sitting down with stakeholders and asking questions that sound simple on the surface, but change everything: ⤷ What decisions are you struggling to make today? ⤷ Where does data slow you down or create confusion? ⤷ Which KPIs, if you had them right now, would change how you run the business? These conversations are rarely neat. You’ll hear conflicting priorities, vague goals, and sometimes even silence. That’s normal. The job is to cut through the noise and translate it into something concrete. When you do that, everything else falls into place: 1) Data engineers know exactly which sources to prioritize. 2) Data Analysts stop debating vanity metrics and focus on useful KPIs. 3) Leaders understand what to expect once dashboards go live. And here’s what often gets overlooked: requirement gathering isn’t just about listing KPIs. It’s here to map business decisions to data, spot workflow bottlenecks, align with strategy, and create a shared language across business and technical teams. It’s where you discover that the sales team and the finance team define "revenue" differently. It’s where you realize that a monthly report isn’t enough, and what the business really needs is daily visibility. It’s where you uncover that the pain point isn’t the dashboard at all, but the manual process feeding it. Data platforms and BI tools will keep changing. Snowflake, Databricks, Fabric, Big Query, etc. They’ll evolve and new ones will appear. But the discipline of requirement gathering won’t. It’s the constant that ties technology back to outcomes. So if you’re about to start a new BI project, spend more time here than you think you need. It will save you months of rework later and it’s the best way to make sure your dashboards actually drive decisions. #BusinessIntelligence #DataStrategy

𝐖𝐡𝐚𝐭 𝐲𝐨𝐮 𝐬𝐡𝐨𝐮𝐥𝐝 𝐤𝐧𝐨𝐰 𝐛𝐞𝐟𝐨𝐫𝐞 𝐛𝐞𝐜𝐨𝐦𝐢𝐧𝐠 𝐚 𝐁𝐔𝐒𝐈𝐍𝐄𝐒𝐒 𝐀𝐍𝐀𝐋𝐘𝐒𝐓 Being a relatively new business analyst, I am coming to a realization that sometimes, it is less about  the amount of knowledge of tools and templates, and more about avoiding the traps that quietly ruin good projects. I identified some, and thought to share: 1. Skipping the BRD and jumping straight into the FRD You get excited and write a detailed FRD before anyone has even agreed on the actual business problem and you beautifully document solution to the wrong problem. Instead, start with the business why: goals, pain points, success metrics. Then move into how the system should work. 2. Treating all stakeholders the same You send updates to everyone, and long reports to people who’ll never read them. Meanwhile, the one person who can block the entire project feels unheard. Apply stakeholder mapping instead (refer to my previous post) 3. Going too deep, too early When you document every edge case on day one, or an 100-page FRD before the idea is even approved. You could start high-level, get alignment. Then iterate. Requirements gathering is a conversation, not a one-time brain dump. 4. Not validating requirements Writing everything all by yourself, then “handing it over” and moving on. It does not work like that, you have toL; ✅ Walk stakeholders through your understanding. ✅ Use wireframes, mockups, or simple flows. ✅ Get explicit sign-off before build.  5. Weak or missing documentation “I’ll explain it on the call” does not cut it because people forget, roles change, or new devs join. Please, try to document clearly. All of the BRD, FRD, use cases, flows, acceptance criteria for easy sharing with an assumption someone will read it without you in the room. 6. Asking “What do you want?” instead of “What problem are we solving?” You deliver exactly what they asked for, and nobody uses it. You have to keep asking “Why?” until you hit the real business problem. Then design the solution around that. 7. Ignoring constraints Some go ahead to gather so many requirements like time, budget, and tech limits don’t exist. Important to ask early if there is a budget, a timeline, or even regulatory constraints. 8. Using only one elicitation technique As a BA, you cannot stick to only interviews, workshops or surveys for elicitation. Mix methods from interviews, observation, workshops, to data analysis, prototyping. Different angles will give you a better picture. Most new BA mistakes come from rushing, assuming, and not communicating enough. The BAs who grow fastest are the ones who: ✔️ Take time to understand the problem ✔️Involve the right people ✔️Write clearly ✔️Validate often ✔️Ask “why?” and “what if?” ✔️Are humble, and can say boldly, “I’m not sure, let’s clarify.” 𝑰 𝒕𝒉𝒊𝒏𝒌 𝒕𝒉𝒆𝒔𝒆 𝒄𝒐𝒗𝒆𝒓 𝒕𝒉𝒆 𝒎𝒊𝒔𝒕𝒂𝒌𝒆𝒔 𝑩𝑨𝒔 𝒂𝒓𝒆 𝒎𝒐𝒔𝒕 𝒍𝒊𝒂𝒃𝒍𝒆 𝒕𝒐. 𝑫𝒐 𝒚𝒐𝒖 𝒕𝒉𝒊𝒏𝒌 𝑰 𝒂𝒎 𝒔𝒑𝒐𝒕 𝒐𝒏?

You Should Stop Gathering Requirements I was a BA for many years, and the phrase "gather requirements" always felt wrong to me. The verb “gathering” makes requirements work sound like a casual stroll through a garden, plucking insights like ripe berries for a pie. Software development isn’t that simple. If you’re strolling, you’re missing the point. Walk the Gemba, Not the Garden Requirements don’t sit on branches waiting to be harvested. They’re often buried, incomplete, or tangled in assumptions. You gotta go where the work is happening - to observe, question, and understand. In Lean, it’s about walking the gemba; visiting the place where value is created. Gathering Is Misleading The word “gathering” implies users know exactly what they need and are ready to hand it over if you'd just ask. But many describe symptoms, not root causes. They’ll share frustrations and describe pain points, but turning those into actionable requirements is a skill. Without deeper investigation, you risk building solutions to the wrong problems. “Gathering” is also too passive. It evokes a mindset that requirements will magically appear if you ask politely or hold enough meetings. The most critical needs are often hidden or unspoken, requiring deliberate effort and methods to uncover. Walking the Gemba When you walk the gemba, you stop relying only on what users say and start noticing what they do. Processes they take for granted. Workarounds that signal inefficiencies. Behaviors that expose unmet needs. Watch how work flows. Are there bottlenecks, delays, or handoffs? Observe how users interact with systems. Do they avoid certain features or rely on workarounds? Notice the environment. What cultural, technical, or physical constraints impact user behavior? By observing, requirements may naturally emerge - insights that no interview could reveal. These moments are invaluable because they expose real-world needs instead of theoretical preferences. Elicitation Walking the gemba isn’t just a philosophical shift. It’s supported by practical methods that help uncover and refine requirements. Shadow users as they work. Ask open-ended questions to uncover their actual processes. This is contextual inquiry. Facilitate process mapping to visualize workflows and find inefficiencies or opportunities for automation. Create mockups and prototypes to validate assumptions and get early feedback. Draft affinity diagrams to synthesize observations into themes and identify hidden patterns. Garden vs. Gemba When you treat requirements elicitation as “gathering,” you take what’s handed to you, accept surface-level statements, and move on without a deeper understanding. Walking the gemba, in contrast, is about observing firsthand, asking “why” to find root causes, and discovering what users actually need, not just what they can easily articulate. This builds empathy, strengthens alignment, and reduces rework. So, stop gathering requirements and start eliciting them.

Most Business Analysts are using ChatGPT wrong! And the culprit is not ChatGPT itself… it’s the prompt. I often see BAs type something generic like “Write me a BRD” and then complain the output looks average. But here’s the truth: ChatGPT is only as good as your prompt. Think of prompts like requirements elicitation. If you ask a stakeholder a vague question, you’ll get vague answers. If you structure your questions with context, constraints, and expected outcomes → you get clarity and quality. How prompts work: Prompt = Requirement gathering question ChatGPT Output = Stakeholder’s answer Refined Prompt = Well-defined requirement with scope and constraints 🛑 Example of a Bad Prompt (BA space): ❌ “Write functional requirements for an eCommerce application.” Result: Generic, textbook-style requirements that don’t match your project. ✅ Example of a Good Prompt: “I am a Business Analyst documenting functional requirements for an eCommerce application that allows users to: 👉 Browse products by category, 👉Add to cart, 👉Checkout using credit card & PayPal, 👉Track order history. Write functional requirements in a numbered list format with clear ‘system shall’ statements.”* Result: Specific, actionable requirements that actually resemble what you’d put in your SRS. Pro tip for BAs: When using ChatGPT, treat your prompt like a mini-BRD: add context, purpose, stakeholders, scope, and expected format. The richer your input, the sharper your output. BA Helpline

After two decades heading Professional Services in SaaS, I've noticed something: requirements gathering is where most projects fall apart before they begin. The pattern repeats constantly. We send documentation. We schedule discovery calls. We ask about workflows and business rules. Then we wait. The truth? Customer contacts are swamped with daily operations. Even with a dedicated project manager, getting clear requirements is an uphill battle. Why Traditional Requirements Gathering Fails → The "Lift and Shift" Approach - Replicating old configurations sounds straightforward. Reality check: if your new platform mirrors the old one exactly, why switch? You'd still need detailed access to every workflow, automation rule, and custom field. → The Observation Method - Watching teams in action works on paper. Scheduling it? Nearly impossible. → The Top-Down Strategy - High-level leadership goals sound great until you need granular implementation details. The Real Problem The core issue isn't tools or templates. It's asking busy people to document processes they've never explained before.Like asking someone to write their exact coffee-making routine. They do it daily, but explaining every step? Completely different task. 3 Strategies That Actually Work → Start with Pain Points, Not Wish Lists Focus on current frustrations, not future wants. People describe pain easier than ideal workflows. Ask questions like: -"What happened when your system crashed during month-end close?" -"What manual task do you hate doing weekly?" → Explore Worst-Case Scenarios Edge cases reveal real requirements. Try: -"What happened when your CEO needed urgent approval but three approvers were out?" -"What happens when customers see conflicting information?" → Focus on Existing Metrics Current metrics reveal what matters. Ask about outcomes they already measure, not imagined features. →The Bottom Line The best requirements sessions feel like conversations where customers finally discuss what's not working. What's worked for you in gathering requirements effectively?

Defining the scope of a project involves a series of tools and techniques aimed at identifying what needs to be achieved and ensuring that all project requirements are clearly understood. Here’s an overview of each tool and technique: 1. Expert Opinion 👨🏫 Purpose: Consult subject-matter experts to gather insights about the project’s needs and requirements. Application: Direct inquiries to experts who have relevant knowledge and experience. 2. Focus Group 🎯 Purpose: A small group of 8 to 12 subject-matter experts is gathered to discuss and provide feedback on a specific topic. Application: A facilitator leads the session to generate ideas, capture requirements, and focus on key project aspects. 3. Brainstorming 💡 Purpose: A method for generating ideas and solutions through open discussion. Ideas are created without immediate judgment, allowing for creativity. Application: Once ideas are generated, they can be categorized and refined. 4. Mind Mapping 🧠 Purpose: A visual tool that captures ideas and organizes them into a structured diagram. Application: Flow Chart: To illustrate processes or workflows. Custom Structures: Any type of structure can be mapped to organize ideas. 5. Affinity Diagram 📊 Purpose: A technique for organizing ideas and information into groups based on their natural relationships. Application: Ideas can be classified by names, categories, or even sizes to find common themes. 6. Facilitated Workshop 🗣️ Purpose: A collaborative session that involves more than 8 to 12 people. It's similar to brainstorming but on a larger scale. Application: Ideas are generated, categorized, and often voted on to determine their importance. 7. Documents 📄 Purpose: Review and analyze project documents, such as the Project Charter, to identify high-level requirements. Application: Analyze documents like business cases, benefit management strategies, and lesson plans to define and categorize project needs. 8. Prototype 📐 Purpose: Create a tangible or digital model to demonstrate potential solutions or products. Application: Present prototypes to clients for feedback and refinement before final development. 9. Storyboarding / Story Map 🗺️ Purpose: Especially in Agile, story mapping is used to create a Minimal Viable Product (MVP) by visualizing requirements and identifying what is needed to meet core objectives. Application: Story maps are aligned with marketing or business goals to streamline product development. 10. Value Stream Map 📉 Purpose: A Lean technique to analyze the flow of project tasks, identifying which tasks add value and which do not. Application: Remove non-value-adding tasks to enhance project efficiency. 11. Context Diagram 🌐 Purpose: A visual representation that shows the project environment, illustrating how different elements interact. Application: Use diagrams to understand the relationships between various parts of the system or project context.

Delivering impactful data projects starts with understanding the requirements! Here’s how to become better at gathering requirements: 1. 𝗦𝘁𝗮𝗿𝘁 𝘄𝗶𝘁𝗵 𝗦𝘁𝗮𝗸𝗲𝗵𝗼𝗹𝗱𝗲𝗿 𝗖𝗼𝗻𝘃𝗲𝗿𝘀𝗮𝘁𝗶𝗼𝗻𝘀: Begin by having detailed conversations with your stakeholders. Understand their goals, challenges, and what they hope to achieve with the data project. This sets a clear direction from the start.     2. 𝗔𝘀𝗸 𝘁𝗵𝗲 𝗥𝗶𝗴𝗵𝘁 𝗤𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀: Find answers to questions like, “What problem are we trying to solve?”, “What decisions will this data influence?”, and “What are the main metrics to track?”. These questions help to clarify the scope and objectives.     3. 𝗗𝗼𝗰𝘂𝗺𝗲𝗻𝘁 𝗘𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴: Keep detailed notes from your stakeholder meetings. Document requirements, assumptions, constraints, and expected outcomes. A well-documented requirement list ensures everyone is on the same page. Develop a requirements template to standardize your approach, making sure you cover all bases and don’t miss any critical details.     4. 𝗖𝗹𝗮𝗿𝗶𝗳𝘆 𝗮𝗻𝗱 𝗖𝗼𝗻𝗳𝗶𝗿𝗺: Regularly check in with stakeholders to confirm your understanding. Use techniques like paraphrasing their requirements and asking for confirmation to ensure accuracy.     5. 𝗜𝗱𝗲𝗻𝘁𝗶𝗳𝘆 𝗗𝗮𝘁𝗮 𝗦𝗼𝘂𝗿𝗰𝗲𝘀: Determine where the necessary data will come from. Understand the data sources, availability, and quality to ensure you have the right data to meet project requirements.     6. 𝗗𝗲𝗳𝗶𝗻𝗲 𝗦𝘂𝗰𝗰𝗲𝘀𝘀 𝗠𝗲𝘁𝗿𝗶𝗰𝘀: Clearly outline what success looks like. Establish KPIs and benchmarks that will measure the effectiveness of your analysis and the impact of your project.     7. 𝗜𝘁𝗲𝗿𝗮𝘁𝗶𝘃𝗲 𝗙𝗲𝗲𝗱𝗯𝗮𝗰𝗸: Build in regular feedback loops throughout the project. Present interim findings to stakeholders and adjust requirements as necessary. This iterative process helps refine the project and keeps it aligned with stakeholder expectations. By becoming great at gathering requirements, you’ll ensure your data projects are more focused, aligned with business goals, and in the end more impactful. What’s your top tip for gathering requirements effectively? ---------------- ♻️ Share if you find this post useful ➕ Follow for more daily insights on how to grow your career in the data field #dataanalytics #datascience #requirementsengineering #projectmanagement #careergrowth