7.4 Acceptance and Evaluation Criteria Definition
Key Takeaways
- Technique 10.1 defines Acceptance Criteria as binary (Pass/Fail) conditions for accepting a requirement/story, and Evaluation Criteria as scoring scales for ranking alternative solutions.
- Acceptance Criteria apply to specific individual user stories, whereas the Definition of Done (DoD) is a global, invariant quality checklist applied across all deliverables.
- Acceptance criteria should be structured using either Scenario-Oriented formats (Behavior-Driven Development / Gherkin: Given-When-Then) or Rule-Oriented verification checklists.
- Effective criteria must be atomic, unambiguous, testable, and measurable, eliminating subjective terms like 'fast', 'user-friendly', or 'secure'.
- Evaluation criteria utilize multi-attribute scoring models with assigned weights to facilitate objective vendor selection and design option ranking.
7.4 Acceptance and Evaluation Criteria Definition
Quick Summary: Acceptance and Evaluation Criteria (BABOK® Guide v3 Technique 10.1) establish the objective standards used to determine whether a solution meets stakeholder requirements (Acceptance Criteria) and to compare and score competing solution options (Evaluation Criteria). Defining rigorous, testable criteria transforms subjective stakeholder expectations into unambiguous, verifiable quality benchmarks.
Purpose and Strategic Role of Technique 10.1
In business analysis, ambiguous requirements are the primary root cause of project failure, scope disputes, and failed user acceptance testing (UAT). If a requirement states that "The checkout page must be fast and easy to use," developers cannot know what performance to architect, and QA testers cannot write an objective test case.
BABOK v3 Technique 10.1 resolves this ambiguity by establishing two distinct types of criteria:
- Acceptance Criteria: The specific, measurable conditions that a delivered requirement, user story, or solution increment must satisfy to be accepted by business stakeholders. Acceptance criteria are Binary (Pass / Fail).
- Evaluation Criteria: The prioritized attributes, performance metrics, and scoring scales used to assess, compare, and rank multiple competing solution options, commercial software packages, or vendor bids. Evaluation criteria are Continuous / Scaled (Scoring & Ranking).
+-----------------------------------------------------------------------------------+
| Acceptance Criteria vs. Evaluation Criteria in BABOK v3 |
+-----------------------------------------------------------------------------------+
| DIMENSION ACCEPTANCE CRITERIA EVALUATION CRITERIA |
| ------------------------------------------------------------------------------- |
| Primary Purpose Validate operational delivery Rank & select alternatives|
| Decision Nature Binary (Pass / Fail) Comparative (Score 1-10) |
| Application Level Individual Story / Requirement Design Option / Vendor Bid|
| Target Question "Is this ready for release?" "Which option is best?" |
| Primary Authority Product Owner / Business SME Executive Steering Board |
+-----------------------------------------------------------------------------------+
Acceptance Criteria vs. Definition of Done (DoD)
A critical distinction in modern agile business analysis is the difference between User Story Acceptance Criteria and the Definition of Done (DoD):
┌─────────────────────────────────────────────────────────────────────────────┐
│ USER STORY ACCEPTANCE CRITERIA (Story-Specific & Dynamic) │
│ * Unique to a specific functional capability or user story. │
│ * Defines the specific business rules, boundary conditions, and outcomes. │
│ * Example: "Given a cart total over $50, when the user selects standard │
│ shipping, then the shipping fee is $0.00." │
├─────────────────────────────────────────────────────────────────────────────┤
│ DEFINITION OF DONE - DoD (Global, Invariant Quality Standard) │
│ * Applies uniformly to EVERY user story across the entire engineering team. │
│ * Represents non-functional quality gates, architectural standards, and │
│ governance compliance before any story can be marked 'Done'. │
│ * Example: Code peer-reviewed; unit test coverage >= 85%; automated QA │
│ regression tests passed; API documentation updated; security scan green. │
└─────────────────────────────────────────────────────────────────────────────┘
Structuring Acceptance Criteria Formats
BABOK v3 recognizes two primary formats for documenting clear, testable acceptance criteria:
1. Scenario-Oriented Format (Behavior-Driven Development / Gherkin)
The Given-When-Then structure from Behavior-Driven Development (BDD) provides a standardized, human-readable syntax that bridges business stakeholders, software engineers, and automated testing frameworks (e.g., Cucumber):
Scenario: Customer attempts withdrawal exceeding daily ATM cash limit
Given a customer has an active bank account with a $2,500 balance
And the customer's daily ATM withdrawal limit is $500
And the customer has already withdrawn $200 today
When the customer requests a cash withdrawal of $400
Then the ATM shall decline the transaction
And display the message "Withdrawal exceeds daily remaining limit of $300"
And eject the customer's debit card without dispensing cash
And log a security audit event with code SEC-ATM-402
2. Rule-Oriented / Verification Checklist Format
When modeling complex business rules, computational algorithms, or administrative screens, tabular checklists provide concise, structured specifications:
| ID | Verification Rule / Condition | Pass / Fail Criteria |
|---|---|---|
| AC-01 | Password Complexity | Minimum 12 characters, including >=1 uppercase, >=1 lowercase, >=1 numeral, and >=1 special character. |
| AC-02 | Failed Login Lockout | System locks account for 15 minutes after 5 consecutive incorrect password attempts within a 10-minute window. |
| AC-03 | Latency SLA | Authentication API responds within <= 250 milliseconds under a concurrent load of 1,000 requests/sec. |
Formulating Testable Criteria: Eliminating Ambiguity
To pass requirements verification and validation (Chapter 6), acceptance criteria must eliminate subjective adjectives and replace them with precise, quantifiable metrics:
| Subjective / Flawed Acceptance Criterion | Flaw Identified | Objective / Testable Acceptance Criterion |
|---|---|---|
| "The search results should load quickly." | Ambiguous ("quickly"); impossible for QA to test objectively. | "The product search API shall return the first 20 matching records within <= 400 milliseconds for a database of 1,000,000 SKUs." |
| "The mobile app must be easy to use for new customers." | Subjective ("easy to use"); unmeasurable. | "90% of first-time users shall complete onboarding registration without errors in <= 3 minutes during usability testing." |
| "The system shall be highly secure against cyber attacks." | Vague ("highly secure"); untestable. | "All data at rest shall be encrypted using AES-256, and data in transit shall enforce TLS 1.3 with zero OWASP Top 10 vulnerabilities." |
Formulating Evaluation Criteria for Solution Selection
When evaluating multiple candidate design options or vendor packages (Task 7.5 & 7.6), business analysts construct an Evaluation Framework with multi-attribute scoring scales:
- Define Evaluation Categories: Establish holistic evaluation dimensions, including Functional Capability, Technical Architecture, Usability, Vendor Viability, Total Cost of Ownership (TCO), and Implementation Timeline.
- Assign Relative Weights: Stakeholders assign percentage weights to each category based on strategic priorities (e.g., Security = 25%, Usability = 20%, Cost = 30%).
- Define Standardized Scoring Scales: Establish clear scoring rubrics (e.g., 1 = Does not meet, 3 = Partially meets with customization, 5 = Fully meets out-of-the-box).
- Calculate Weighted Scores: Aggregate scores mathematically to provide an objective ranking.
Enterprise Scenario: Mobile Wallet Identity Verification (KYC)
A FinTech enterprise is building a digital wallet and must comply with Know-Your-Customer (KYC) anti-money laundering regulations. The lead BA specifies both acceptance and evaluation criteria:
- User Story Acceptance Criteria (Gherkin):
- Scenario: User submits government passport photo for automated identity verification.
- Given: A user is on the identity verification screen and has taken a clear photo of their passport.
- When: The user clicks "Submit Verification".
- Then: The optical character recognition (OCR) engine must extract Full Name, Date of Birth, and Passport Number with >=99.5% accuracy in <= 2.0 seconds.
- And: If the photo is blurry (resolution < 300 DPI), the UI displays "Image quality too low; please retake photo in bright lighting."
- Definition of Done (DoD) Applied:
- OCR integration code reviewed by two senior developers.
- Automated unit test coverage at 92%.
- End-to-end security penetration test confirms biometric images are tokenized and encrypted under SOC 2 standards.
- Evaluation Criteria for OCR Vendor Selection:
- Weighted matrix evaluates Vendor Alpha vs. Vendor Beta across OCR accuracy (35%), API response latency (25%), price per API call (25%), and multi-language support (15%).
Key BABOK v3 Techniques for Technique 10.1
- Acceptance and Evaluation Criteria (10.1): Establishes pass/fail delivery thresholds and weighted scoring rubrics.
- Decision Analysis: Employs multi-attribute utility theory and decision matrices to evaluate scores.
- Metrics and Key Performance Indicators (KPIs): Defines quantifiable performance measures for acceptance.
- Reviews & Structured Walkthroughs: Validates criteria with product owners, developers, and quality assurance leads.
[!TIP] CCBA Exam Tip: Remember that Acceptance Criteria are binary (Pass/Fail) for a single requirement, whereas Evaluation Criteria are comparative/scoring for selecting among multiple alternative options. If a scenario asks how to rank three commercial vendors, the answer involves Evaluation Criteria; if it asks how a tester knows a story is ready for release, it involves Acceptance Criteria.
[!WARNING] CCBA Exam Trap: Do not confuse Acceptance Criteria with the Definition of Done (DoD). Acceptance Criteria change from user story to user story based on specific business functionality. The Definition of Done is a universal, static quality checklist (unit tests, linting, docs, deployment) applied identically to all user stories across the team.
In an agile development team, a business analyst is defining quality standards for the product backlog. The team establishes that every backlog item must have peer-reviewed code, pass automated security vulnerability scans, achieve 90% unit test code coverage, and include updated system documentation before being marked complete. Conversely, a specific user story has a requirement that 'a user must receive a password reset link via email within 30 seconds of request.' How are these two distinct standards classified in business analysis?
A business analyst is authoring requirements for an automated fraud detection feature. The initial draft requirement states: 'The fraud alert engine should be highly responsive and flag suspicious transactions quickly.' Which of the following revisions BEST transforms this statement into an unambiguous, testable acceptance criterion using Behavior-Driven Development (BDD) Gherkin syntax?
An enterprise is selecting a third-party commercial Customer Service Helpdesk software platform. The business analyst facilitates a workshop where stakeholders assign percentage weights to five key categories (Functional Fit: 30%, Usability: 20%, Security & Compliance: 20%, Vendor Financial Viability: 15%, 3-Year TCO: 15%) and rate three competing vendor proposals on a 1-to-5 scale across each category to calculate a total weighted composite score. Under BABOK v3 Technique 10.1, what is being utilized?