How should software acceptance criteria be defined, and what if they fail?
Acceptance criteria should be agreed with scope before development and written as precondition, action, expected result, and evidence. Cover complete workflows, migration, performance and capacity, security and access, compatibility, operations and recovery, and transferred assets. If a check fails, first distinguish an original-scope defect, missing client input or environment, approved change, and new improvement; then correct and retest, accept a safe part, or invoke exit. Neither blanket non-payment nor “basically usable” is a sound default.
| Area | Define | Evidence |
|---|---|---|
| Function/workflow | Roles, starting data, normal and exception paths | Case record, version, logs |
| Migration | Scope, mapping, cleaning, counts, business reconciliation | Source-target report, exception register, approval |
| Performance/capacity | Data, workload, network, P95/P99, errors | Scripts, environment, raw report |
| Security/access | Identity, roles, organization isolation, high-risk actions, vulnerability gate | Access matrix, tests, remediation retest |
| Operations/recovery | Monitoring, backup, restore, release, rollback, alerting | Restore exercise and runbooks |
| Assets | Source history, accounts, data, documents, licenses | Register, permission proof, independent deployment |
When planning milestones, resources, and acceptance, also compare How should the process and service scope of a large software project be defined?; the linked guidance adds context that should be considered in the same decision.
ISO/IEC 25010:2023 describes nine software product quality characteristics and can reveal missing quality dimensions; the model does not generate project thresholds. Regulated payment, medical, or industrial systems need additional industry requirements.
Instead of “users can refund,” a test might state: on a paid CNY 100 unshipped order, an authorized support agent requests CNY 30, finance approves, the payment sandbox is called, the cumulative refund becomes CNY 30, a separate ledger and audit event are created, an ordinary store user cannot approve, and repeated callbacks do not post again. It identifies state, amount, permissions, exception, and evidence.
Performance cases specify infrastructure, software version, data volume, workload model, warm-up, duration, and statistics. Wavesteam derives targets from expected peaks and cost and submits them for approval; it does not reuse another project's numbers. AI acceptance freezes cases, versions, scoring, refusal, and human review rather than saying “answers accurately.”
The SOW identifies provider environment, version, and deliverables and client accounts, authorized samples, interfaces, participants, and decision deadlines. Tests use redacted data where possible. One issue register holds all feedback. Supplier self-test precedes client acceptance. Modular acceptance for larger work still ends with cross-module journeys and final asset takeover.
For every failure, record ID, reproduction, expected and actual result, evidence, severity, owner, and date. Original-scope defects are corrected and rerun against the same case; client blockage pauses or replans according to contract; approved changes use their amended criteria; new improvements go to later evaluation. Severe failures affecting core work, security, or money close before acceptance. Minor residuals may use written partial acceptance, retention, and a dated fix plan.
If repeated correction still fails, escalate to scope reduction, independent testing, partial acceptance, alternative delivery, or termination, including source, data, and account transfer. Legal consequences follow the contract and professional advice. Wavesteam should build the evidence directory at scope confirmation and provide runnable versions, changes, results, and known issues at every milestone. Our transparent delivery standard describes the method, while the signed SOW and acceptance record govern.