Someone once handed me a data project with a single line of guidance. “Just make sure the data is clean before it hits the report.” I nodded like it meant something. It meant nothing. But nodding felt professional, so I nodded. What that project needed, and never got, was a set of data quality rules anyone could actually test.
Two weeks later the report was wrong and we were in a meeting arguing about whether cleaning the data had ever been my job. Nobody could win that argument. “Clean” was never defined, so it could not be met, measured, or tested. It was a wish wearing the costume of a requirement.
A requirement you cannot test is not a requirement. It is a hope with better grammar.
What “clean” is actually hiding
The word feels specific until you try to check it. Clean how? Clean by when? Clean to what standard? Zero errors, or good enough? On every field, or only the ones that matter?
A usable requirement answers those questions with three parts. Get all three and a machine can enforce it and a person can own it. Miss one and it quietly stops working.
The three parts of a usable requirement
Write them in this order. Each part closes a gap the one before it leaves open.
Part one: the rule
The rule is what a check answers with a yes or a no. No opinions, no vibes.
“The data should be correct” is not a rule. “Every order has a region code” is a rule. You can run it.
-- The rule, written as a test. Zero is a pass.
SELECT COUNT(*) AS failing_rows
FROM sales_orders
WHERE region_code IS NULL;Written that way, the rule can fail. And a requirement that can fail is one that can pass, which means it is finally real. If yours cannot fail a test, it was never a requirement. It was a mood.
Part two: the threshold
Here is where careful people quietly lose. They write the rule and silently assume the answer must be one hundred percent. Always.
Sometimes it must be. An order id that is supposed to be unique should be unique, full stop, because a duplicate directly overstates revenue. But for plenty of fields, chasing perfection is how you burn a month on the last stubborn half percent that nobody downstream would have noticed.
The threshold says how much deviation you accept. Ninety nine and a half percent of orders carrying a valid region might be fine for a territory report. One hundred percent of order ids being unique is the right call for anything that touches money. Decide the number on purpose and out loud, instead of accidentally promising perfection and then explaining every month why you missed it.
Part three: the owner
A rule and a threshold with no human behind them are decoration. The owner is a real person who can decide what the field means and approve a change to it. Not “the data team.” A name.
Why does this matter so much? Because the interesting failures are never “the value is missing.” They are “two teams define region differently and both think they are right.” Somebody has to be the tiebreaker. If the answer to “who owns the definition of region” is a shrug, the requirement dies the first time two people disagree, which is usually week one.
Do not forget the service expectation
There is a quiet fourth part. When must this data be ready, how fresh must it be, and how often is it checked? A correct value that lands an hour after the review is still a miss. Bake the timing into the requirement so nobody argues about it later.
Before and after
Watch a wish turn into a requirement.
Before: “The data should be correct.”
After: “order_id is unique across sales_orders, one hundred percent, owned by the sales data lead, checked on every load. Failures block the publish.”
The first version starts fights. The second one ends them. One is a feeling. The other is a line in a data contract that a machine enforces and a named person answers for. When the check fails there is no debate about whose job it is, what “correct” meant, or whether it is bad enough to matter. It is all right there in the sentence.
A quick test for your data quality rules
Take any expectation floating around your team right now. Say it out loud, then ask three questions. Can I write it as a check that returns a number? Have I decided what number counts as passing? Can I name the person who owns it?
Three yeses and you have a requirement. A shrug on any of them and you have a preference. And preferences do not survive contact with a busy quarter.
Clean is a feeling. A rule, a threshold, and an owner is a plan. Write the plan.
If you want to see rules, thresholds, and contracts come together into a full requirements pack, I build it step by step in my Pluralsight course, Define Data Quality Requirements.
Reference: Pinal Dave (https://blog.sqlauthority.com/), X
