Software acceptance criteria describe the observable conditions a feature must meet before a business accepts it. They turn a broad request, such as make approvals easier, into a shared understanding of what users should be able to do. For Kenyan organisations commissioning a portal or business system, clear criteria help the delivery team demonstrate progress and help reviewers explain a problem without relying on personal preference.
This guide explains how to prepare software acceptance criteria with the people who perform the work. Explore Zama’s software development services and call 0725345345 to discuss your process. Bring one real workflow, its users and a sample record with private information removed so the conversation can move from general wishes to testable outcomes.
1. Start software acceptance criteria with a business task
Describe the task before describing the screen. A manager may need to approve an expense, a customer may need to check an order, or a receptionist may need to correct an appointment. Each task has a starting situation and a useful result. A page containing several buttons is not necessarily evidence that the underlying task works.
Ask what the user needs to know at the end. Should a request appear in the next person’s queue? Should a customer receive an acknowledgement? Should a report include the updated record? Software acceptance criteria should connect the action to its intended result rather than stop at the moment someone clicks a control.
2. Identify the people who can explain the rules
Invite representatives who understand the everyday process and its exceptions. The project sponsor can explain the objective, but a frontline employee may know why a request sometimes returns for correction. Include the person responsible for approving the business rule, especially where departments disagree about the expected sequence or permitted action.
Give each unresolved question an owner. Do not ask developers to invent operational policy merely because the project needs a quick answer. Software acceptance criteria should record agreed decisions and visible assumptions. Where a rule remains open, make that dependency clear before the team estimates or demonstrates the affected feature.
3. Describe the starting conditions
A test needs a known starting point. State which role is signed in, what record exists and which status it has. Include relevant conditions such as the selected branch or whether a previous approval is complete. Without those details, two reviewers can perform apparently identical actions and reach different results for legitimate reasons.
Keep the conditions specific enough to reproduce without making them unnecessarily complicated. Software acceptance criteria become easier to discuss when everyone can point to the same sample request and explain why a particular action should be available.
4. Write an observable expected result
Replace vague phrases such as works properly or feels intuitive with something a reviewer can check. For example, an authorised supervisor can return a submitted request with a reason, and the requester can see that reason when opening the record. This describes a result without prescribing every visual detail or implementation decision.
Ask how the reviewer will know the condition has been met. The evidence might be a changed status, a visible message, an entry in an appropriate history or a result in the next user’s queue. Software acceptance criteria should make success recognisable while leaving room for a sensible design that achieves the agreed outcome.
5. Include permission boundaries
Identify who may view, create, change or approve the information involved. A successful test by an administrator does not prove that the intended staff role can complete the task. Equally, a feature is not ready merely because everyone can access it. The business needs the right people to perform the right actions through the approved workflow.
Include a negative example, such as a user who should not approve their own request. Ask the technical team to demonstrate enforcement through the relevant access paths, not only by hiding a button. Software acceptance criteria should describe the boundary the business expects; detailed security testing remains a separate professional activity.
6. Define useful validation feedback
Decide what happens when required information is missing or inconsistent. A reviewer should know which field needs attention and what a valid correction looks like. If the user must select a department before choosing an approver, describe that dependency. Avoid an acceptance condition that allows a generic error while leaving the user unable to finish the task.
Test the correction as well as the rejection. Can the user fix the problem without losing unrelated information? Does the form preserve the intended selection? Software acceptance criteria should cover recovery because mistakes are part of ordinary work. An application that detects an error but offers no practical recovery still leaves the business process unfinished.
7. Cover changes of state explicitly
Many business systems move records through stages such as draft, submitted, reviewed and completed. Define the permitted transitions and who initiates them. Clarify whether a completed record can be reopened, whether reopening requires a reason and what happens to earlier decisions. These details often matter more than the colour of a status label.
Check what another user sees after the change. A requester and reviewer may need different information, but both should understand the current position. Software acceptance criteria should prevent a record from appearing complete in one place while another part of the workflow still treats it as waiting for action without explanation.
8. Specify the important exception paths
Choose exceptions that reflect the actual process. An approver may be unavailable, a customer may cancel, or a supporting document may need replacement. Describe the expected handling and who decides the next step. Do not try to list every imaginable failure before the basic workflow is understood, but do not postpone common exceptions until launch.
Separate a valid business exception from a technical fault. A rejected request is an expected decision; a failed save is a different problem. Software acceptance criteria should make that distinction so the team can choose appropriate messages, status handling and follow-up. A user should not mistake an unsuccessful save for a completed rejection.
9. Check notifications and follow-up actions
If the feature sends a message, identify the intended recipient, triggering event and information required. Ask what happens when a request is amended after a notification has been sent. A message can be delivered successfully while still leading the recipient to an outdated action. The test should connect the notification to the current record.
Avoid defining success solely as an email arriving. Check that the recipient can understand what needs attention and reach the relevant page with the appropriate permissions. Software acceptance criteria should also clarify whether a notification failure blocks the business action or creates a separate follow-up item, according to the agreed design.
10. Define reporting and export expectations
Where a workflow affects a report, identify the relevant scope and totals. State whether the report includes drafts, completed records or a selected period. A reviewer needs to compare like with like. A visible total is difficult to approve when nobody has agreed which records belong in it or which date determines inclusion.
Use a small example whose expected result can be calculated independently. Include one record that should appear and one that should be excluded. Software acceptance criteria should explain the reason for both. If an export is required, confirm which fields and filters must carry through rather than assuming that the download automatically matches the screen.
11. Agree the evidence and review process
Choose how the team will record results. A practical record contains the criterion, sample data reference, reviewer, observed result and any issue raised. Screenshots or short recordings can support the explanation, but they should not replace a clear statement of what happened. Keep sensitive information out of shared test evidence unless it is necessary and properly controlled.
Decide who can accept a condition and how disagreements are resolved. A developer’s demonstration, a tester’s check and the business owner’s acceptance may be separate steps. Software acceptance criteria are most useful when the review process is known before the demonstration, so nobody discovers at the end that an essential decision maker was absent.
12. Keep changes visible after agreement
Business understanding can improve during development. When a criterion changes, record what changed, why and who approved it. Ask the delivery team to explain the effect on scope, testing and timing before treating the new expectation as already included. This creates a clearer conversation than quietly replacing the original wording after work has been completed.
Retain the connection between the criterion and the affected feature. Software acceptance criteria should remain useful during later maintenance, not disappear after the launch meeting. A future reviewer can then distinguish a defect against an agreed behaviour from a new improvement that needs its own assessment and approval.
Worked example: returning a request for correction
Imagine a fictional organisation with requesters and supervisors. A requester submits a purchase request containing an incomplete item description. The supervisor needs to return it for clarification rather than approve or permanently reject it. The business first agrees who may return the request and what information the requester must receive.
One criterion could state that a supervisor viewing a submitted request can return it only after entering a reason. Another could require the requester to see that reason when reopening the returned record. A third could confirm that editing a returned request does not silently erase the earlier review history. Each condition describes a separate observable outcome.
The demonstration should include a missing reason, a valid return and the requester’s correction. The reviewer also signs in with a role that should not perform the supervisor action. Software acceptance criteria make this example repeatable without requiring a large production dataset or an argument about whether the screen looks finished.
Common questions from project teams
How many criteria should a feature have? Use enough to describe its meaningful outcomes and boundaries. A simple field change may need only a few checks, while an approval workflow may need several scenarios. Counting criteria is less useful than asking whether the important decisions are covered clearly.
Can criteria include usability expectations? Yes, but describe them in a way the team can evaluate. Specify the task, user context and expected assistance rather than simply demanding a user friendly screen. Include accessibility requirements with appropriate specialist input where needed.
Are software acceptance criteria the same as a full test plan? No. They describe agreed acceptance conditions. A test plan can include additional technical, performance, security and regression checks. Keep the relationship clear so business acceptance is not presented as proof that every technical risk has been tested.
Resources for planning a business system
Explore Zama’s custom web portal services when several roles need controlled access to one process. Review website maintenance services when planning support after launch. Discuss the actual scope, deliverables and responsibilities for your project rather than assuming that every service includes the same level of testing or ongoing change work.
Some organisations need an existing specialist platform rather than custom development. Compare Vega for retail operations, Prim for salon management, TAS for chama records and Saseni for writing order workflows. These external resources serve different purposes. Confirm any required integration directly instead of assuming that a link between websites means their data is connected.
For other workflows, explore JAAT and Dereva. Confirm each platform’s current services and suitability directly.
Prepare your first acceptance workshop
Choose one workflow that matters to daily operations. Bring a fictional sample, the names of the relevant roles and the questions that currently cause disagreement. Write the ordinary path first, then add permissions, corrections and common exceptions. Ask someone outside the original discussion to read the criteria and explain what they would test. Review unresolved questions together.
Contact Zama Web Experts or call 0725345345 to discuss the next step. Clear software acceptance criteria help your team make decisions before launch, record useful evidence during review and explain later changes. Start with observable outcomes and keep the conversation connected to the work your users need to complete.