Business analysts work at the intersection of what the business needs and what can be built. Most of the tools for that intersection are about communication: interviews, workshops, specifications, process models. What gets less attention is the third source of evidence available in most organizations: the data the business generates every day, sitting in a warehouse or a database, describing what actually happens at a level of detail no interview can match.
A BA who can query that data doesn't have a different job. They have additional evidence. And additional evidence changes requirements, not always in the direction anyone expected.
The assumptions that pile up without data access
A business analyst working from interviews and workshops builds a picture of the business that reflects what stakeholders remember, what they notice, and what they prioritize. Those are real inputs. They're also partial ones. Human memory is selective, perception is shaped by salience, and the most articulate stakeholder in the room is not always the most representative one.
The gap between the described process and the actual process is a familiar problem in process modeling. The data version of that gap is: the described volume (how many customers, how many transactions, how many exceptions) and the actual volume, which the data knows exactly and the stakeholder approximates from experience. "Most of our customers do X" is a claim. SELECT COUNT(*) with a filter is a count.
Requirements built on approximate claims scale incorrectly. A system designed for "most customers" at a stakeholder-estimated 80% may be built for the wrong 80% if the actual proportion is 55%, or may need to handle far more edge cases if the actual proportion is 40%. Either way, the requirement changes when the data is consulted. The question is whether it changes before or after the system is built.
SQL as a BA tool, not a DE skill
SQL in a BA context is not about building pipelines, managing schemas, or optimizing query performance. It's about asking questions of the data and reading the answers critically. The specific skills that matter for a BA using SQL are narrower than the full data engineering competency:
- Counting and filtering. How many records match a condition? What share of the total does that represent? Are the numbers consistent across related tables?
- Distribution analysis. What does the spread of a value look like? Are the edge cases actually rare, or does "rare" mean 8% of transactions, which is a significant design constraint?
- Cohort and segment behavior. Do different customer segments, product types, or time periods behave differently? A requirement that treats all customers as equivalent may need to be split if the data shows meaningfully different behavior patterns.
- Data quality assessment. What percentage of a field is null? Are there values that shouldn't be there? How consistent are the identifiers across tables? These are requirements-adjacent questions: a field that's 30% null is a different design input from a field that's 0.1% null.
None of these require understanding query optimization, index design, or schema management. They require knowing how to write a SELECT statement, a WHERE clause, a GROUP BY, and a JOIN, and knowing how to interpret what comes back.
The hypothesis-before-query discipline
The most important habit in data-driven BA work is writing down what you expect to find before running the query. Not as a formal step, but as a check: if you don't have an expectation, you don't have a hypothesis, and without a hypothesis, a query result is just a number. A number without a hypothesis attached to it doesn't change anything because you don't know what it means for the question you're trying to answer.
The discipline looks like this: before querying order cancellation rates by customer segment, write down the expectation ("I expect cancellation rates to be similar across segments, around 5-7%, based on the stakeholder's description of the business"). Then run the query. If the result matches, the stakeholder's description is validated and the requirement can proceed on that basis. If the result doesn't match, the discrepancy is the finding: something in the data contradicts the mental model, and the requirement needs to be revisited.
The finding that doesn't match is more valuable than the finding that does, because it's the one that changes the requirement before anything is built.
Three validation patterns
Volume sanity check. Does the scope of the initiative match the actual data volume? A requirement for a feature that handles "high-volume customer requests" needs to be calibrated against what high volume means in this specific system. The query is simple: count the records in scope over a representative period, segment them by the dimensions that matter to the feature design, and compare to the stakeholder's description.
-- How many refund requests per month, by channel and status?
SELECT
DATE_TRUNC('month', requested_at) AS month,
channel,
status,
COUNT(*) AS request_count
FROM refund_requests
WHERE requested_at >= CURRENT_DATE - INTERVAL '12 months'
GROUP BY 1, 2, 3
ORDER BY 1 DESC, 4 DESC;A stakeholder who said "we get about two hundred refund requests a month" and a query that returns eight hundred is a discrepancy worth having before the requirement is finalized. The feature designed for two hundred processes the additional six hundred differently, or doesn't process them at all, depending on assumptions that just became visible.
Frequency distribution of edge cases. What proportion of transactions, customers, or records fall into the "exceptional" category that requirements often treat as marginal? The frequency distribution query reveals whether the edge case deserves its own requirement or whether it genuinely can be handled as an exception path.
-- Distribution of order value, to understand the "large order" threshold
SELECT
CASE
WHEN order_value < 100 THEN 'under 100'
WHEN order_value < 500 THEN '100-499'
WHEN order_value < 1000 THEN '500-999'
WHEN order_value < 5000 THEN '1000-4999'
ELSE '5000+'
END AS value_band,
COUNT(*) AS order_count,
ROUND(100.0 * COUNT(*) / SUM(COUNT(*)) OVER (), 1) AS pct
FROM orders
GROUP BY 1
ORDER BY MIN(order_value);If the "5000+" band turns out to represent 18% of orders by count and 67% of revenue, the "large order" use case isn't a marginal exception path. It's a primary design concern.
Cohort behavior comparison. Do the segments that the business describes as distinct actually behave differently in the data? A requirement that creates separate workflows for two customer types is worth questioning if the two types behave identically in every measurable dimension. Conversely, a requirement that treats two groups as the same is worth questioning if the data shows meaningfully different patterns.
The finding that changed the requirement
In the BA-04 A/B test project, the initial hypothesis was that a pricing change would have a uniform effect across customer segments. A segmented query before the test design was finalized showed that one segment had a significantly different baseline conversion rate, which meant that a simple aggregate result would mask the effect on that segment entirely. The test design was revised to ensure stratified sampling, which changed both the sample size calculation and the analysis approach. That revision came from a query, not from an interview.
The connection between BA and data skills isn't a new role. It's a BA who has one more instrument for validating the assumptions embedded in every requirement. The assumptions don't go away when a BA doesn't have data access: they just go untested. Untested assumptions are what requirements built on "most of our customers" and "usually about two hundred a month" are made of. The data doesn't always change the requirement. But when it does, and it does often enough to be worth checking every time, finding out before the build is the least expensive version of being right.