Skill Hub — Business Analysis

Acceptance Criteria Working Skill

Define pass/fail standards before work starts, so that delivery disputes are replaced by verifiable evidence.

What this skill is for

Requirements without acceptance criteria are opinions. This skill turns requirements into testable statements that a developer can build against, a tester can verify, and a business owner can sign off on. The output is an Acceptance Criteria Set that removes ambiguity about what "done" means, prevents scope creep during testing, and gives AI agents a clear target for generating test cases or validation scripts.

When to use this skill

A requirement is approved and ready for implementation, but no one has defined how to verify it.
A user story is written and the development team asks "how will we know this is working?"
A change request is scoped and the approver wants to know what success looks like.
A test plan is being prepared and the testers need specific inputs and expected outputs.
A contract milestone is defined and the vendor and client disagree on whether it was met.
An incident fix is deployed and the business asks how to confirm the fix is permanent.

Real work situations

New credit limit check rule

A requirement states: "The system must enforce credit limits." The acceptance criteria must specify: given a customer with a credit limit of 50,000 EUR and an open order value of 45,000 EUR, when a new order of 10,000 EUR is created, then the system blocks the order with status "Credit block" and routes it to the credit team. Exception: if the order is marked "Emergency" and under 1,000 EUR, it proceeds with a warning and logs to audit. Without these criteria, developers build a generic block that either over-blocks or under-blocks.

Data migration: customer master

A requirement states: "Migrate all active customers to the new system." The acceptance criteria must specify: 100 percent of customers with status "Active" in the source system exist in the target system with matching account group, tax number, and payment terms. Zero duplicate account groups are created. All tax numbers pass country-specific validation. Migration completes within the 48-hour maintenance window. Without these criteria, the migration loads incomplete data that blocks invoicing.

Integration fix: IDoc processing

A requirement states: "Fix the IDoc failure rate." The acceptance criteria must specify: given a standard sales order IDoc from the e-commerce platform, when it is received by SAP, then it processes within 5 minutes, creates an order with the correct pricing, and posts a success status. Error rate must be below 0.1 percent over a 7-day period. Monitoring alert fires within 1 minute of any IDoc error. Without these criteria, "fixed" means different things to operations and development.

Inputs required

Approved Requirements Brief with a clear requirement statement.
System documentation showing current behavior, fields, and transactions involved.
Test data samples or production data extracts that represent normal and edge cases.
Stakeholder availability to validate that the criteria match their intent.
Non-functional requirements: performance, availability, security, compliance constraints.
Regulatory or audit constraints that affect what must be demonstrable.
Previous test plans or criteria from similar requirements (if available).

Questions to ask

How will you know this is working correctly? What would you look at, click, or measure?
What is the minimum acceptable result, not the best case or ideal scenario?
Which data will you use to test this, and where does that data come from?
Who will confirm this is correct, and do they have the authority to sign off?
What happens if it is 90 percent correct? Is that acceptable or a failure?
Which edge cases must be handled: new customers, large orders, missing data, system downtime?
What must remain unchanged? What existing behavior must not break?

Working method

Read the requirement statement. Ensure it is testable. If it contains words like "easy," "fast," or "user-friendly," rewrite the requirement first.
Identify the scenario, precondition, action, and expected outcome. For each requirement, break it into: what must be true before, what happens, and what must be true after.
Write Given/When/Then criteria for each scenario. Use the format: Given [precondition], When [action or event], Then [expected outcome].
Add non-functional criteria. For each requirement, specify performance, availability, security, and compliance thresholds.
List edge cases. Identify at least three: normal case, boundary case, and error case.
Define test data needs. State exactly what data is needed, in which system, and how to obtain or create it.
Identify who signs off. Name the person who will approve that criteria are met. Verify they have authority.
Document in an Acceptance Criteria Set. One set per requirement. Link to the Requirements Brief.
Validate with the requirement owner. Walk through each criterion and confirm it matches their intent.

Decision rules

If a requirement has no measurable outcome, rewrite the requirement before writing acceptance criteria.
If criteria require data that does not exist in test systems, flag a test environment gap.
If edge case handling is not specified, the criterion is incomplete.
If the sign-off owner is not the requirement owner, verify their authority to approve.
If non-functional criteria are missing, the deliverable may pass functionally and fail operationally.
If criteria can be automated, note the automation approach and tool.
If criteria conflict with existing system behavior, flag the conflict before implementation.

Deliverables

Acceptance Criteria Set — Per requirement. Contains scenarios, non-functional criteria, edge cases, test data needs, verification method, and sign-off owner. See template below.
Test Data Requirements — List of data needed, source system, creation method, and anonymization requirements.
Verification Plan — How each criterion will be checked: manual test, automated test, review, or demonstration.

Templates

Acceptance Criteria Set (compact)

---
artifact: Acceptance Criteria Set
id: AC-001
requirement: Link to requirement brief
status: draft | reviewed | approved
---

## Scenario: Normal case
Given <precondition>
When <action or event>
Then <expected outcome>

## Scenario: Boundary case
Given <precondition>
When <action or event>
Then <expected outcome>

## Scenario: Error case
Given <precondition>
When <action or event>
Then <expected outcome>

## Non-functional criteria
- Performance: <metric>
- Availability: <metric>
- Security: <requirement>
- Compliance: <requirement>

## Edge cases
- <Edge case 1>
- <Edge case 2>

## Test data requirements


## Verification method


## Sign-off owner

Quality checklist

Every requirement has at least one acceptance criterion.
Criteria are testable pass/fail statements, not open to interpretation.
Edge cases are covered: normal, boundary, and error.
Non-functional requirements have specific metrics or thresholds.
Test data is identified with source and creation method.
Sign-off owner is named and has authority.
No criterion contains implementation detail or solution design.

Common mistakes

Writing criteria that repeat the requirement without adding verifiability. Consequence: still no way to test. The criterion says "the system must be fast" instead of "the system must respond within 2 seconds."
Including implementation instructions in criteria. Consequence: constrains the solution unnecessarily. The criterion says "use index X" instead of "query returns in 2 seconds."
Forgetting edge cases. Consequence: production failures on exceptions that were never tested: missing data, large volumes, concurrent users.
Omitting non-functional criteria. Consequence: the deliverable passes functional tests but fails under load, lacks audit trails, or breaks compliance.
Not identifying test data. Consequence: testing is blocked because no one can create or access the required data.

Agent instructions

AI agents should use this skill to produce testable acceptance criteria before generating test cases, validation scripts, or implementation plans.

Never write acceptance criteria for a vague requirement. First clarify the requirement, then write criteria.
Use Given/When/Then format for functional criteria. Be specific about preconditions, actions, and outcomes.
Add specific metrics for non-functional criteria. Performance, availability, security, and compliance must have numbers or clear standards.
List at least three scenarios per requirement: normal case, boundary case, and error case.
Identify test data needs explicitly. State what data, in which system, and how to obtain it.
Name the sign-off owner. Do not leave approval ambiguous.
Produce an Acceptance Criteria Set per requirement. Link to the Requirements Brief.
Do not include implementation details in criteria. Criteria state what must be true, not how to build it.
Link to Atlas diagnostics when criteria relate to SAP validation. For example, incompletion procedure criteria should reference SAP Incompletion Procedure Diagnostics.

Related skills

Related Atlas pages

SAP Incompletion Procedure Diagnostics — Validation context for completeness criteria.
SAP Release Strategy Diagnostics — Approval workflow criteria context.
Delivery Billing Block Order-to-Cash Delays — Scenario with block/release criteria.

Verification status and limitations

This skill is a public working interpretation of acceptance criteria practices. It is not official ISTQB, BABOK, or SAP documentation. It focuses on enterprise software and SAP contexts where criteria must be verifiable by business owners, not just technical testers.

Known limitations: the skill assumes requirements are already elicited and approved. It does not cover exploratory testing, usability testing, or security penetration testing methodologies. Non-functional criteria may require specialized tools or environments that are not always available.