Identify the Research Questions is Domain 1 of the IIBA Certification in Business Data Analytics (CBDA). It carries 20% of the 75-question exam, so roughly 15 questions [1]. The Guide to Business Data Analytics covers it in section 2.1 with seven tasks: define the problem, understand stakeholders, assess the current state, define the future state, formulate research questions, plan the approach and select techniques [2]. The exam checks one habit above all: don't jump to a solution.
Identify the Research Questions at a glance
Domain 1 is the "why" of an analytics initiative: it turns a vague business symptom into questions the data team can answer. The guide says the research questions "provide focus for the data analytics team and shape the work that follows" [2].
| Item | Detail |
|---|---|
| Exam weight | 20% (Domain 1) [1] |
| Exam format | 75 multiple-choice, scenario-based questions, 2 hours, online remote proctored only [1] |
| Approximate questions | About 15 (20% of 75, my calculation) |
| Guide section | 2.1, tasks 2.1.1 to 2.1.7, case study 2.1.8 [2] |
| Main output | A concrete, agreed list of research questions in plain language, plus the plan to answer them |
Last verified: November 2026 (exam facts on the IIBA CBDA page).
Two other domains share the top weight of 20%: Interpret and Report Results and Use Results to Influence Business Decision Making [1]. So Domain 1 is not "the intro chapter". It is a full fifth of your score.
The seven tasks of Identify the Research Questions
The tasks are iterative, not a strict sequence. The guide says this directly in 2.1.1, and I think it is the first thing to remember [2]. Below is each task with its purpose, what the analyst does, what comes out and where candidates slip.
2.1.1 Define Business Problem or Opportunity
Purpose. Understand the real problem or opportunity before anyone talks about models. The guide calls it "often the first step" of an analytics initiative [2].
What the analyst does. Facilitates discussions to elicit, observe and analyze the context, in parallel with stakeholder identification. Typical techniques here are interviews, job shadowing, surveys and workshops [2]. The input can be a problem (a sudden drop in internet sales) or an opportunity (a manufacturer that wants to predict and avoid equipment outages) [2].
Key output. A defined business problem or opportunity that may lead to one or more research questions. The guide notes that a business problem is usually a higher-level description than a research question [2].
Exam mistake. Choosing the answer where the team starts building a model because the sponsor is in a hurry. The guide names this exact risk: urgency creates a tendency to jump into a solution focus, which can end in a misdiagnosis of the problem [2].
2.1.2 Identify and Understand the Stakeholders
Purpose. Know who asks, who owns the data and who decides. Each stakeholder group has different needs, asks different types of questions, wants results in different volumes and timings, and has a different level of analytics experience [2].
What the analyst does. Answers five questions before the work starts: who the stakeholders are, what they know about analytics, which part of the project interests them, which communication methods fit and when to communicate [2]. Techniques include brainstorming, interviews, and reviewing process flows and org charts.
Key output. A stakeholder view with a data angle: who creates the relevant information, who is exposed to the data, and which decision-makers the insights will influence. Stakeholder matrices, onion diagrams and personas show it [2].
Exam mistake. Listing only business users. The guide stresses that you need to understand the custodians and consumers of data, not just the sponsor [2].
2.1.3 Assess Current State
Purpose. Set a baseline. The guide says the current state results "set a baseline and context for making a change" [2].
What the analyst does. Studies capabilities, resources, processes, the value chain and how data flows. From the analytics side, it also means checking what the existing data already points to. Typical models: business model canvas, organizational, scope and process models [2].
Key output. Evidence-based context, plus a read on whether the organization has the appetite, budget and expertise for analytics [2].
Exam mistake. Accepting a leader's explanation as fact. The guide's example: a leader says internet sales fell because of low customer engagement, but that statement does not conclusively link the two. The analyst looks for evidence in the data [2].
2.1.4 Define Future State
Purpose. Describe what success looks like. The future state must be clear, achievable with available resources, shared by key stakeholders, and backed by measurable objectives [2].
What the analyst does. Facilitates the choice of metrics with decision-makers: strategic and operational KPIs, sometimes industry-specific ones such as average revenue per user (ARPU) in telecom or store footfall in retail [2]. The analyst also sets the scope of the analytics effort and records how the vision changes, because defining the future state is continuous and iterative.
Key output. In the guide's words, "a clear understanding of the business objectives and the value" the business wants from the effort [2]. Scope models and stakeholder maps support it.
Exam mistake. Picking a "standard" metric without business context. More on this in the fraud example below.
2.1.5 Formulate Research Questions
Purpose. Agree on the questions the analytics will answer, before detailed work starts. The questions come from business needs [2].
What the analyst does. Facilitates the move from a long brainstorm list to a short list of specific, highest-value questions, and brings the team to consensus. The guide's retail example turns one need, "improve customer experience", into four questions: two descriptive, one predictive and one prescriptive [2].
Key output. A concrete list of research questions in plain language, reviewed with all stakeholders. The guide says good analytics questions "are clearly stated and do not use technical language" [2].
Exam mistake. Thinking the analyst writes questions in statistical terms here. Restating them in mathematical language happens later, in Perform Data Analysis (2.3.4), by data scientists [2].
2.1.6 Plan Business Data Analytics Approach
Purpose. Decide how the analytics work will be done.
What the analyst does. Checks the capabilities and capacity of the organization, separates quick wins from longer efforts, classifies the questions as descriptive, diagnostic, predictive or prescriptive, and keeps traceability from business needs to research questions and their sources [2]. Brainstorming, functional decomposition and estimation help here.
Key output. An approach. Its formality is up to the organization: a planning template or visual models on a shared wiki are both fine [2]. For complex work, the guide describes three stages: proof of concept (feasibility), pilot (integration and quality issues) and production (business value) [2].
Exam mistake. Treating the plan as fixed. Planning is iterative, and each of the six domains has its own planning element [2].
2.1.7 Select Techniques for Identify the Research Questions
Purpose. Pick the techniques that fit the situation. The guide gives a short, non-exhaustive list (next section) [2].
Exam mistake. Assuming the list is complete or mandatory. The guide says it is "a small, but useful, set" [2].
Section 2.1.8 is a case study, not a task. Marsha, a consultant in an investment bank, gets an eager trading-floor manager who wants predictive analytics after a conference. She asks to pause, runs interviews and process modelling first, and then holds a discovery workshop with root cause analysis, 5 Whys and a business model canvas to frame research questions [2]. If you remember one story from Domain 1, I think it should be this one.
Techniques used in Identify the Research Questions
Most Domain 1 techniques come from the BABOK Guide, and three come only from the analytics world. The table follows section 2.1.7 [2]; for the last three I use the chapter 3 technique names (the 2.1.7 table words them as "Hypotheses Formulation and Testing" and "Problem Reframing and Shaping").
| Technique | How Domain 1 uses it | Reference |
|---|---|---|
| Business Model Canvas | How the enterprise creates value, with a data view | BABOK 10.8 |
| Concept Modelling | Organize business vocabulary, start data requirements | BABOK 10.11, Guide 3.3 |
| Decision Modelling and Analysis | Decision hierarchy with trees, tables, networks | BABOK 10.16, 10.17, Guide 3.8 |
| Document Analysis | Minutes, reports, past analytics projects | BABOK 10.18 |
| Interviews and Workshops | The problem from each stakeholder's view | BABOK 10.25, 10.50 |
| Metrics and KPIs | Many initiatives exist to explain or optimize KPIs | BABOK 10.28 |
| Organizational Modelling | Capabilities and which group asks which questions | BABOK 10.32 |
| Prioritization | Focus on the most urgent questions | BABOK 10.33 |
| Process Modelling and Analysis | Where data is created and consumed | BABOK 10.34, 10.35 |
| Risk Analysis and Management | Risks from decisions and assumptions | BABOK 10.38 |
| Root Cause Analysis | Probable causes, intuition for the questions | BABOK 10.40 |
| Scope Modelling | Boundaries of the analytics engagement | BABOK 10.41 |
| Stakeholder List, Map, or Personas | Who generates and consumes data | BABOK 10.43, Guide 3.16 |
| Exploratory Data Analysis | Quick look at available data to build intuition | Guide 3.11 |
| Hypothesis Formulation and Testing | Turn an SME opinion into a testable premise | Guide 3.12 |
| Problem Shaping and Reframing | Restate the problem from several perspectives | Guide 3.15 |
The guide's reframing example is useful: "identify high-value customers" can mean lifetime value, highest spending, or interest in high-value purchases [2]. Three different research questions hide in one phrase.
Related reading on certificate.tips: root cause analysis and the 5 Whys and stakeholder lists, maps and personas.
How it works in practice: two worked examples from the guide
The two examples in section 2.1 show why the domain is iterative: the current state changes the question, and the business context changes the success metric [2].
Example 1. The bicycle company forecast (2.1.3). A family-owned bicycle maker must commit orders to suppliers six months before the season, with no early signal of demand. The first research question looks obvious: what factors influence the forecast [2]. A current state analysis can change it in two ways:
- If the business model could change (local suppliers, local assembly), the question becomes "which factors keep quality, pricing and sales", not "how to improve the forecasting model".
- If historical data shows a clear seasonal pattern around long holidays, the question becomes a study of seasonal patterns to upgrade the model.
Without the current state, the team would only assess the existing forecasting model [2]. That means the current state is not paperwork. It decides which question is worth answering.
Example 2. Fraud detection success criteria (2.1.4). Classifying card transactions as fraud or not is a binary classification problem. Standard measures are precision, recall, specificity and accuracy [2]:
| Measure | Formula |
|---|---|
| Precision | TP / (TP + FP) |
| Recall | TP / (TP + FN) |
| Specificity | TN / (FP + TN) |
| Accuracy | (TP + TN) / (TP + FP + TN + FN) |
If stakeholders decide false positives are not a concern, precision can be the metric to maximize. If they define success as the actual cost to the company, the trade-off between fraud caught and the cost of false positives and false negatives matters, and precision is not the right metric [2]. The analyst's job is to explain that choice in business terms. My take: this is the most "technical" spot in Domain 1, and it is still a business decision.
What practitioners say about the research question stage
Practitioners outside IIBA describe the same failure the guide warns about: work starts before the question is clear. Five sources from different backgrounds:
- An editor's analytics poll. In a 2016 poll of analytics readers, 40% named problem definition as the greatest danger point of a data project, ahead of data sourcing at 25.7% [3]. The author's summary: "Mess up the first stage and nothing that follows will fix the mistake" [3].
- A data scientist looking back at his internship. He skipped goal setting and did not question the data. Two weeks of cleaning and analysis later, he found that he had "made a wrong assumption of the data" [4].
- A lead data scientist at an analytics consultancy. He treats a clear problem as one of three legs of any analytics project, next to data and the ability to act, and uses the Netflix Prize as a warning: the winning model was too complex to implement, and the business problem had changed by the end [5].
- An analyst who passed CBDA in 2022. He notes the certification is about how business analysis supports analytics, not in-depth data science or mathematical models, and found per-domain mock sets the most useful part of his preparation [6].
- A software developer who passed CBDA. He felt "a little bewildered" about where to start, put in about 8 hours of study on top of trainer-led sessions, and found mind maps helped most [7]. This is a training provider's success story, so read it with that in mind.
I see the same pattern in Domain 1 questions. The wrong options are rarely silly. They are reasonable actions done too early.
What the exam looks for in Domain 1
The exam rewards the analyst who facilitates and checks evidence, not the one who builds fastest. Patterns to watch for:
| If the scenario says... | The guide's answer leans to... |
|---|---|
| Sponsor wants a model now | Define the problem and engage the right stakeholders first (2.1.1) |
| A leader "knows" the cause | Look for evidence in data before accepting it (2.1.3) |
| Choose a success metric | Ask how the business defines success; context decides (2.1.4) |
| Write the research question | Plain language, agreed by all stakeholders (2.1.5) |
| Restate the question as a hypothesis or formula | Later, in Analyze Data (2.3.4) |
| Classify the question | Descriptive, diagnostic, predictive or prescriptive (2.1.6) |
| Unclear feasibility | Proof of concept before pilot and production (2.1.6) |
So the rule I use for myself: if one option skips a step of 2.1 to save time, it is probably the distractor.
How to prepare for Identify the Research Questions
Read section 2.1 twice: once for the task list, once for the examples. Then:
- Write the seven task names from memory, with one output each.
- Retell the bicycle and fraud examples in your own words.
- Learn the four question types with one example each, from the retail case in 2.1.5.
- Practice scenario questions. Our Domain 1 research questions drill is built for this, and the 6-week CBDA study plan shows where Domain 1 fits in your schedule.
- Check the exam format and weights in the CBDA exam guide, then try a timed run on the CBDA exam simulator.
Check yourself: CBDA practice questions
Four short questions, checked against section 2.1 of the guide.
1. A sales director says: "Online sales dropped. Build us a churn prediction model this month." What should the analyst do first?
A. Start collecting customer data for the model B. Facilitate discovery of the business problem with the right stakeholders C. Choose precision as the success metric D. Ask the data scientist to restate the request as a hypothesis
Answer: B. 2.1.1 warns against jumping into a solution focus. A and C act on an undefined problem. D belongs to Analyze Data.
2. Which statement best describes the relationship between a business problem and a research question?
A. They are the same thing B. A research question is broader than a business problem C. A business problem is usually higher-level and may lead to one or more research questions D. Research questions are written before the business problem
Answer: C. This is the guide's own wording in 2.1.1.
3. A bank defines success of a fraud model as the actual cost to the company of missed fraud and false alarms. Which metric is the weakest choice to optimize alone?
A. Precision B. A cost-based measure of errors C. A trade-off of false positives and false negatives D. A measure agreed with stakeholders
Answer: A. In 2.1.4 the guide says that when success is the actual cost, precision will not be the right metric.
4. Which activity is NOT part of Plan Business Data Analytics Approach?
A. Identifying quick wins versus longer-term efforts B. Determining whether questions are descriptive, diagnostic, predictive or prescriptive C. Maintaining traceability from business needs to research questions D. Restating research questions in mathematical language
Answer: D. Data scientists do that in Perform Data Analysis (2.3.4). A, B and C are listed in 2.1.6.
Key takeaways
- Domain 1 is 20% of the CBDA exam, about 15 of 75 questions [1].
- Seven tasks in section 2.1, plus a case study; they are iterative, not sequential [2].
- Business problem first, then plain-language research questions agreed by stakeholders.
- Current state can change the question; business context decides the success metric.
- Mathematical restatement of questions happens later, in Analyze Data.
FAQ
What is the Identify the Research Questions domain on the CBDA exam?
It is Domain 1 of the IIBA CBDA exam and section 2.1 of the Guide to Business Data Analytics. It covers how an analyst turns a business problem or opportunity into clear research questions and plans the analytics approach. It carries 20% of the exam.
How many tasks are in CBDA Domain 1?
The guide lists seven tasks: Define Business Problem or Opportunity, Identify and Understand the Stakeholders, Assess Current State, Define Future State, Formulate Research Questions, Plan Business Data Analytics Approach, and Select Techniques. Section 2.1.8 is a case study, not a task.
How many CBDA questions come from Identify the Research Questions?
IIBA publishes the weight, not the count. Domain 1 is 20% of a 75-question exam, which is about 15 questions. Interpret and Report Results and Use Results to Influence Business Decision Making have the same 20% weight.
Do I need statistics for Domain 1?
Only a little. You should understand success measures such as precision, recall, specificity and accuracy, and when each fits the business goal. Deeper statistics belong to Analyze Data.
What is the most common Domain 1 trap?
Jumping to a solution. Scenarios often offer a fast, technical action, such as building a model or picking a standard metric, before the problem, stakeholders and success criteria are clear. The guide favours facilitation and evidence first.
Sources
- IIBA: Certification in Business Data Analytics (CBDA)
- IIBA: Guide to Business Data Analytics, 2.1 Identify the Research Questions
- InformationWeek: Where Analytics Projects Go Wrong (2016)
- Towards Data Science: How to Ask the Right Questions as a Data Scientist
- Elder Research: The Three-Legged Stool of an Analytics Project (white paper)
- Medium: Business Data Analytics Certification (2023)
- Techcanvass: CBDA certification journey of Ivan (2024)