1. Make success and failure observable
People interpret “it should work well” differently. Describe who must be able to complete which task with which inputs, then define the observations that distinguish a pass from a failure.
The planner must be able to enter staffing needs and working conditions, review a plan that satisfies mandatory constraints, and review and confirm the result after making changes.
Success criteria also include operational requirements such as mandatory constraints, data integrity, and access permissions. New evidence may justify changing the criteria, but record why they changed.
2. Distinguish different kinds of evidence
Code existing, code running with specified inputs, and a user completing real work are different observations. State what each piece of evidence establishes so that the next decision rests on a clear basis.
| What to verify | Relevant evidence |
|---|---|
| Computation and conditions | Input validation, mandatory constraint checks, results, and limitations |
| The complete workflow | Execution records from input through calculation, comparison, revision, and confirmation |
| Real-world use | Task completion and user acceptance in the intended operating environment |
An experiment with fictional data provides evidence for that setting. Do not extend it into a claim that the solution has been used or accepted in a real customer environment.
3. Examine success and failure paths
Check invalid inputs, conflicting constraints, calculation timeouts, result revisions, interruptions, and recovery. An unsupported request differs from a supported problem with no feasible solution. If a solution has not yet been found, show that uncertainty clearly.
Speeding up one screen or calculation can increase the burden elsewhere. Compare the before and after using the same user scenario, and check for new errors and manual work.
Try it yourself
Choose a fictional booking, delivery, or staffing task and describe these three checks.
- One successful workflow the user must be able to complete
- One failure situation the system must explain clearly
- One condition that requires a separate check in the real operating environment
What makes a useful verification statement?
Be specific about the inputs, situation, action, and expected result. Beyond “an invalid capacity prevents calculation,” describe whether the planner can understand which field was rejected and why.