Business Acceptance Criteria
What are Business Acceptance Criteria?
Business Acceptance Criteria (BAC) are statements of the conditions a solution must meet to be accepted by business stakeholders. They define what “done” looks like from a business perspective — not how the solution is built, but what it must achieve.
For example, if you’re building a login feature, a BAC might be:
- Users must be able to log in using their email address and password
- Users must receive a clear error message if they enter incorrect credentials
- Users must be redirected to their dashboard after a successful login
BACs help everyone involved — from developers to business stakeholders — agree on what needs to be delivered and when it can be considered finished. They prevent misunderstandings about scope and create a shared definition of success.
BACs are referenced using the prefix AC- — AC-1, AC-2, and so on.
Given / When / Then
Business Acceptance Criteria in ArchRepo can be recorded as free-text or in Given / When / Then format. Given/When/Then is the preferred format where possible. See Given / When / Then for background.
Benefits of Given / When / Then Format
- Clarity and Structure: A clear, standardised format that breaks each criterion into preconditions (Given), actions (When), and expected outcomes (Then).
- Testability: Naturally translates into automated tests — each statement can be directly converted into a test scenario.
- Reduced Ambiguity: Explicitly stating the context, action, and expected result eliminates confusion and ensures everyone interprets requirements the same way.
- Better Communication: Bridges the gap between technical and non-technical stakeholders. Business analysts, developers, and testers can all understand and contribute.
- Traceability: Each criterion becomes a discrete, trackable item that can be verified independently.
- Living Documentation: Given / When / Then statements serve as both requirements and test documentation.
Free-text description is also available — useful for narrative context or where the Given/When/Then structure does not fit naturally.
BAC vs Implementation Acceptance Criteria
ArchRepo has two levels of Acceptance Criteria:
| Business Acceptance Criteria (BAC) | Implementation Acceptance Criteria (IAC) | |
|---|---|---|
| Focus | Business outcomes and user value | Technical correctness and build specification |
| Audience | Business stakeholders, product owners | Developers, testers, solution architects |
| Level | High-level — what must be true | Low-level — exactly how it must behave |
| Prefix | AC- | IAC- |
A single BAC can link to one or more IACs. The IAC specifies the implementation detail that delivers the BAC’s business outcome.
See Implementation Acceptance Criteria for the lower-level technical counterpart.
ACs and AI Agents
Acceptance Criteria are valuable in standard engineering.
They are also highly effective as inputs to AI code generation agents. Providing well-structured Given/When/Then criteria in your prompt gives the AI agent a precise, verifiable specification — reducing ambiguity and improving the quality of generated code and tests.
Links to Use Cases, Scenarios, and Rules
BACs can be linked to the model items that motivated them:
- Use Cases — the use cases that this BAC applies to
- Business Scenarios — the business scenarios that this BAC must support
- Business Rules — the business rules that this BAC enforces or implements
These inbound relationships mean that when viewing a use case, scenario, or rule, you can navigate directly to the associated acceptance criteria.
Exporting ACs
Within each Model Item’s specification, scroll down to the Acceptance Criteria section and click the Export button to export the criteria for that item.
Fields Reference
See Business Acceptance Criteria Fields for a description of each field and guidance on what to record.