Sample software decision record
See what a written engineering decision can contain before commissioning a build.
Illustrative sample. This is a fictional appointment-request workflow. It is not a client case study, a deployed product or a measured result.
01 · The problem and boundaries
A small service business receives appointment requests by email. Staff need one queue with an owner, status and history. The first release covers requests and confirmations; payments, medical records and automatic rescheduling are outside scope.
02 · Options considered
| Option | Advantage | Constraint |
|---|---|---|
| Configure an existing scheduler | A smaller implementation and operational burden. | Test whether its permissions and workflow fit. |
| Build a small web application | Control the queue and approval flow. | The business owns maintenance and support. |
| Build web and native mobile apps | Dedicated mobile interfaces. | More release and testing work before validating demand. |
03 · Proposed decision
Test an existing scheduler against the required workflow first. If it cannot meet the agreed access and approval needs, build a responsive web application. Defer native apps until a specific device capability or observed user need justifies them.
04 · Failure cases to design for
- A repeated request must not create duplicate appointments.
- A user must not read another organization’s requests.
- A failed notification must leave the request visible for staff follow-up.
- Staff must be able to correct a mistake with an attributable history.
05 · Acceptance evidence
- Demonstrate request creation, assignment, confirmation and cancellation using test data.
- Repeat a request after a simulated network failure and check the result.
- Attempt cross-organization access and verify it is rejected.
- Restore a backup in a test environment and document the steps.
06 · Measurement and handover
Measure the current time from request to staff response before choosing a target. Record the sample size and measurement window. Handover includes the repository, deployment instructions, access list, known limitations, operating costs and the agreed support boundary.
07 · When to revisit the decision
Revisit when the workflow changes, the chosen platform cannot meet a required control, or observed usage identifies a missing capability. Record the evidence and the replacement decision.