Study guide
7.4 Acceptance and Evaluation Criteria Definition
CCBA Certification of Capability in Business Analysis Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Introduction & CCBA Exam Foundation
1.1 CCBA Exam Structure, Eligibility & IIBA Framework 1.2 The Business Analysis Core Concept Model (BACCM™) 1.3 Requirements Classification Schema & Architecture 1.4 CCBA Competency & Proficiency Levels (Level 2 — Skilled)
2 Chapter 2: Business Analysis Planning and Monitoring
2.1 Plan Business Analysis Approach (Task 3.1) 2.2 Plan Stakeholder Engagement (Task 3.2) 2.3 Plan Business Analysis Governance (Task 3.3) 2.4 Plan Business Analysis Information Management (Task 3.4) 2.5 Identify BA Performance Improvements (Task 3.5)
3 Chapter 3: Elicitation and Collaboration
3.1 Prepare for Elicitation (Task 4.1) 3.2 Conduct Elicitation (Task 4.2) 3.3 Confirm Elicitation Results (Task 4.3) 3.4 Communicate Business Analysis Information (Task 4.4) 3.5 Manage Stakeholder Collaboration (Task 4.5)
4 Chapter 4: Requirements Life Cycle Management
4.1 Trace Requirements (Task 5.1) 4.2 Maintain Requirements (Task 5.2) 4.3 Prioritize Requirements (Task 5.3) 4.4 Assess Requirements Changes (Task 5.4) 4.5 Approve Requirements (Task 5.5)
5 Chapter 5: Strategy Analysis
5.1 Analyze Current State (Task 6.1) 5.2 Define Future State (Task 6.2) 5.3 Assess Risks (Task 6.3) 5.4 Define Change Strategy (Task 6.4)
6 Chapter 6: Requirements Analysis and Design Definition — Modeling & Architecture
6.1 Specify and Model Requirements (Task 7.1) 6.2 Verify Requirements (Task 7.2) 6.3 Validate Requirements (Task 7.3) 6.4 Define Requirements Architecture (Task 7.4)
7 Chapter 7: Requirements Analysis and Design Definition — Design & Value
7.1 Define Design Options (Task 7.5) 7.2 Analyze Potential Value and Recommend Solution (Task 7.6) 7.3 Estimation Techniques & Solution Trade-Offs 7.4 Acceptance and Evaluation Criteria Definition
8 Chapter 8: Solution Evaluation
8.1 Measure Solution Performance (Task 8.1) 8.2 Analyze Performance Measures (Task 8.2) 8.3 Assess Solution Limitations (Task 8.3) 8.4 Assess Enterprise Limitations (Task 8.4) 8.5 Recommend Actions to Increase Solution Value (Task 8.5)
9 Chapter 9: Essential BABOK Techniques
9.1 Core Elicitation & Analysis Techniques 9.2 Process, Data & Non-Functional Requirements Modeling 9.3 Financial Analysis & Business Case Techniques 9.4 Prioritization & Scope Techniques 9.5 Root Cause & Decision Analysis Techniques
10 Chapter 10: Underlying Competencies & Perspectives
10.1 Analytical Thinking, Problem Solving & Systems Thinking 10.2 Behavioral Characteristics, Communication & Interaction Skills 10.3 Business Acumen, Solution Knowledge & BA Tooling 10.4 The Five BABOK Perspectives in Practice
11 Chapter 11: CCBA Exam Mastery & Scenario Strategy
11.1 Deconstructing CCBA Scenario Questions & BABOK Logic 11.2 Common Traps, Distractors & Subtle BABOK Distinctions 11.3 Comprehensive 8-Week Study Plan & Exam Day Strategy
7.4 Acceptance and Evaluation Criteria Definition
Key Takeaways Explain This Topic AI
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.
Last updated: August 2026
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.