Part of the Mastering Fraud Solution Implementation series, in the preparation phase. Earlier articles asked what success means and who owns the outcome; this one turns stakeholder wishes into requirements that can survive delivery: measurable, prioritized, owned.

Most requirements do not fail loudly. They pass the status meetings, they get signed off, and only later does someone discover they were unmeasurable, unranked, or owned by no one. That discovery usually lands at UAT, the most expensive place to have it.

Three well-known sayings carry this article. All of them are old, and every requirements process I have seen, in nearly two decades of fraud implementations, violated at least one of them.

Figure 1: Stakeholder wishes become a requirements list only when they are measurable, prioritized, and owned.

"You can't improve something you don't measure"

Requirements and success criteria should originate from the business. But originating from the business is not enough: they have to be formulated as measurable outcomes, and measurable has a precise, practical meaning:

You can measure it today, and you can measure it again in the future, ideally without spending tens of hours to produce the number.

Both halves matter. If you cannot measure it today, you have no baseline, and without a baseline the post-implementation question "did it actually work?" becomes permanently unanswerable. You will be arguing feelings against feelings, and I will show you in a later post exactly how that argument ends. And if producing the metric takes tens of hours of manual digging and data points collection, it will be measured once, for the business case, and never again.

There is a useful diagnostic hiding in that rule: if a metric requires heroic effort to gather and put together, you have probably defined the wrong metric for this phase or it needs to be broken down. You are aiming too high, too early.

Good metrics are cheap, baseline-able, and boring: think fraud loss in basis points of throughput, false-positive decline rate, or median time-to-decision on an alert. The deceptively attractive ones are a different story. "Percentage of all fraud detected" sounds like exactly what you want, but you cannot measure the fraud you missed; the denominator is unknown and practically unknowable. Fraud examiners will recognize an old friend here: the dark figure. "Detect fraud we've never seen before": genuinely desirable, inherently unmeasurable as an acceptance criterion. "Improve customer trust": a worthy mission statement, not a requirement.

If a metric needs data you don't have, or effort you won't sustain, it is the wrong metric for this phase. Park it for the maturity level at which it becomes cheap to produce.

"If everything is a priority, nothing is a priority"

Collecting requirements across every stakeholder (a discipline from earlier in this series) reliably produces hundreds of items. Left unranked, that is not a requirements set; it is a letter to Santa Claus.

The discipline that converts the list into something deliverable is force-ranking, and it has to happen at two levels.

First, force-rank the requestors. This sounds impolite and is absolutely essential. When the analyst's UI wish collides with the architect's platform standard and the head of fraud's coverage expansion (and they will collide), someone must have decided, in advance, whose requirements carry more weight for this program's objectives. Otherwise the tie-breaker becomes volume: whoever shouts loudest, or attends the most meetings, wins. Priorities must be set by the business objectives of the organization, not by decibels.

Then force-rank the requirements themselves. Identify those you genuinely have to have: the ones the business case dies without. Everything else is explicitly negotiable: valuable, wanted, and tradeable against the timeline or competing/clashing requirements. This clarity is what lets you defend the go-live date when (not if) something has to give. (Long-time readers know where I stand on that trade: Don't trade the go-live date for more functionality.)

Functionality or time-to-value?

One more classification shapes every scoping decision downstream: is this program driven by functionality or by time-to-value? Deploying a net-new capability (real-time monitoring where there was none, replacing spreadsheets and email, racing a regulatory deadline)? Time wins: deliver quickly with less, because every month without the capability is unmitigated loss, and the organization can only discover its real requirements by operating something live. Elevating an existing, functioning capability? Then functionality can lead, because the current solution keeps carrying the load. In my engagements, the split runs perhaps 70-30 in favor of time. When in doubt, choose earlier and smaller.

"What is everyone's responsibility is no one's responsibility"

The third leg, and the one most often skipped: every requirement needs an owner.

Definition is a group act; ownership is a singular one. Requirements are defined collectively (that is where the richness comes from), but each one must be owned by a single accountable person who follows it through the project's lifecycle: into scope, through design, into testing, to validation and sign-off. Not necessarily the person who invented it; usually better if it isn't.

Why does this matter so much? Because unowned requirements have a predictable lifecycle: they enter the scope with enthusiasm, get silently reinterpreted during design, get descoped under pressure without anyone consciously deciding it, and resurface at UAT as "this isn't what we asked for." A requirement that is technically delivered but functionally hollow is one of the most common ways to fail quietly, and the only reliable prevention is a person whose name is attached to noticing.

This is where prioritization and ownership meet. On one program, requirements reconciliation exposed two legitimate but incompatible priorities. IT wanted the fraud implementation to wait until all planned middleware services were complete, avoiding a second round of integration, SIT, and regression testing. The business wanted the available fraud capabilities delivered on schedule, accepting that the missing services would be added and the testing repeated later. Neither position was wrong, but the program could not optimize for both. The decision was to prioritize time-to-value and proceed with the available services. Crucially, each deferred integration was then recorded as an explicit requirement with a named owner, target release, and testing commitment. The decision to defer was prioritization. What stopped that deferred work from quietly disappearing was ownership.

A related division of responsibility appears in The Art of Defining What and How: as far as practical, the customer should define what outcome it needs, while the vendor determines how the solution will deliver it. That division does not remove ownership. Each requirement still needs a named person on the customer side to preserve its intent as it moves through design, testing, validation, and sign-off. This series returns to how the What and the How stay aligned when the implementation phase begins.

The pattern behind all three

Notice what the three sayings have in common: each forces a decision earlier than feels natural. Measuring forces us to define success before we can hide behind adjectives. Ranking forces us to disappoint someone at the requirements whiteboard instead of at UAT. Owning forces a name against every promise while everyone still remembers making it.

That is the entire character of a well-prepared fraud program: decisions taken early, while they are cheap. The next post is about what happens when an organization refuses to decide at all, and asks for everything at once.

Try it this week: take your program's top five requirements and ask of each: can we measure it today, where does it rank, and whose name is on it? The gaps you find are your real project risk, visible early, while it's still cheap to fix.