Solution Validation Criteria
Key Takeaways
- Solution validation confirms a delivered solution meets the business need and delivers value, which is distinct from verifying that a requirement is well-formed.
- Acceptance criteria describe the minimum set of requirements a solution must meet to be acceptable to key stakeholders.
- Evaluation criteria support a broader comparative assessment of a solution or competing solution options against a set of standards.
- Findings recorded during validation activities such as UAT or pilots should be traceable back to a specific requirement or acceptance criterion.
- Entry-level business analysts typically support solution validation as part of a team rather than owning the final acceptance decision.
What Solution Validation Means
In the BACCM, a Solution is a specific way of satisfying one or more needs in a context. Once a solution — or a component of one — has been built, piloted, or delivered, the organization needs confidence that it actually satisfies the need it was meant to address. Solution validation is the set of activities that confirm a solution (or an increment of it) delivers the value stakeholders expect, rather than simply confirming that documentation was written correctly.
This is a distinct concept from requirements verification, which checks that a requirement is well-formed and internally consistent. Validation asks a different question: does the delivered solution meet the underlying business need and produce the intended outcome? A requirement can be verified as clear and complete and still fail validation if, once implemented, it turns out not to solve the real problem or stakeholders cannot use it as intended.
At the entry level, an ECBA-certified business analyst typically supports solution validation as part of a larger team rather than owning the final acceptance decision. That support work includes observing pilots, demonstrations, or user acceptance testing (UAT) sessions; comparing what was delivered against defined criteria; and capturing findings in a form the team and decision-makers can act on.
Recording Findings from Validation Activities
Whatever the validation activity — a pilot rollout, a UAT cycle, a stakeholder demo — the business analyst's job is to record findings objectively and traceably. A useful finding ties back to a specific requirement or acceptance criterion, states what was actually observed, and notes any evident gap between expected and actual results.
| Validation activity | Typical findings to record |
|---|---|
| User acceptance testing | Pass/fail against each acceptance criterion; defects found; workaround needed |
| Pilot program | Actual outcome vs. expected outcome; adoption issues; unanticipated side effects |
| Stakeholder demo | Stakeholder reactions; new or changed needs surfaced; unresolved questions |
| Solution walkthrough | Gaps between designed behavior and delivered behavior; missing edge cases |
Findings should avoid speculation about blame and instead describe facts: what was expected (tied to the requirement or criterion), what was observed, and — where evident — the likely cause of any gap. This traceable record is what allows the extended business analysis team, sponsors, or product owner to make an informed accept, reject, or rework decision, and it is also the raw material used later when assessing solution limitations or recommending follow-up actions.
Acceptance Criteria vs. Evaluation Criteria
BABOK Guide v3 names Acceptance and Evaluation Criteria as a specific technique, and candidates are expected to distinguish the two clearly, since they serve different purposes at different points in the work.
- Acceptance criteria describe the minimum set of requirements that a specific solution, or solution component, must meet to be acceptable to key stakeholders. They set a pass/fail bar — is this piece of work done and good enough to accept, or not?
- Evaluation criteria support a broader, comparative assessment — weighing a solution, or multiple competing solution options, against a set of standards such as cost, risk, strategic fit, or overall performance.
| Acceptance Criteria | Evaluation Criteria | |
|---|---|---|
| Purpose | Determine if a specific deliverable is good enough to accept | Compare and assess options or overall solution performance |
| When used | At sign-off points: end of an iteration, UAT, delivery of a component | When selecting among design options, or measuring ongoing solution value |
| Nature | Pass/fail, minimum bar | Comparative, often weighted across multiple factors |
| Example | "The system must calculate the discount correctly for all three customer tiers" | "Option A scores higher than Option B on cost, risk, and time-to-market" |
Applying Both Together
In practice these two sets of criteria work side by side. A user story written during elicitation might carry acceptance criteria (often phrased as "given/when/then" conditions) that the team checks at each iteration to decide whether the story is genuinely "done." Meanwhile, when the organization is choosing between several possible solution approaches — a topic covered in the next section — evaluation criteria are what let the team score and compare those options against each other on a level basis.
Both types of criteria should be traceable: acceptance criteria trace back to a specific stakeholder or solution requirement, so everyone understands exactly what "acceptable" means for that piece of work. Evaluation criteria trace back to the business objectives and value the initiative is meant to deliver, so a comparison of options is grounded in what the organization actually cares about rather than in personal preference. A business analyst who keeps this traceability intact — and who records validation findings against the right criteria — gives the team a defensible basis for every accept, reject, or needs-rework decision, and builds the record that later solution-evaluation work depends on.
Why the Distinction Matters in Practice
Mixing up acceptance criteria and evaluation criteria leads to two common mistakes. The first is treating a comparative standard as a hard pass/fail bar — rejecting a delivered feature because it scored lower than an alternative on a value comparison, even though the feature met every acceptance criterion it was built against. The second is the reverse: assuming a solution component that passed its acceptance criteria is automatically the best option, when a broader evaluation against competing approaches was never performed. Business analysts avoid both mistakes by being explicit about which type of criteria a decision actually uses, and by making sure both are documented and agreed with stakeholders before the corresponding activity begins — not written retroactively to justify a decision already made.
During user acceptance testing, a business analyst must determine whether a completed solution component is ready to be accepted by business stakeholders. Which type of criteria was most likely defined ahead of time to support this determination?
During a pilot rollout of a new solution, a business analyst observes that one of the expected outcomes was not achieved by the stakeholders using it. What is the most appropriate next step to properly support solution validation?