A custom software specification describes a task someone needs to finish: who starts it, what they enter, which rules apply and how you will check the result. Include permissions, exceptions, connections to existing systems and the scope of the first release. One worked process with clearly marked open questions is enough to start a discussion.
Choose a task that currently involves copying data or chasing approval in messages. If you are still deciding what to buy, start with our comparison of off-the-shelf and custom software. A specification then gives you a basis for requesting an estimate and agreeing how delivery will be reviewed.
What belongs in the first release?
Define where the process starts and when it ends. For a purchase request, that could cover an employee's submission, a manager's decision and a status view. Invoicing and payment are additional scope, even though they naturally follow the same business activity.
Mark each requirement as “first release”, “later” or “open question”. A feature awaiting a decision is not automatically included in the price. Name the person who will decide and the deadline, especially when the answer affects the estimate. Check priorities with the people doing the work and review an example of their current process.
You can summarise a user need in a sentence about the role, task and purpose. The GOV.UK guide to user stories recommends this structure. Then add the rules that turn that sentence into specific behaviour.
A template for one business task
Copy these questions and complete the answers for each important action. For an unknown detail, name the person who will check it.
Scroll the table sideways to see all columns.
| Item | What to record |
|---|---|
| Task and purpose | What does the user need to finish, and why? |
| Roles and permissions | Who can enter, view, change, approve and export data? |
| Inputs | Which fields are required, which values are allowed and where does the data come from? |
| Flow and outcome | What triggers the action, what happens next, and which record or status results? |
| Exceptions | What happens after an error, rejection, lost connection or repeated submission? |
| Checks | Which example data will you use to verify each expected outcome? |
| Scope and ownership | Is this in the first release, who approves it and which version is current? |
Worked example: requesting office equipment
This is a fictional internal application. Its amounts and rules illustrate a specification; they do not describe a client or an existing product. Task NAB-01 is: an employee requests equipment so that a manager can approve the purchase before an order is placed.
The first release covers one item per request, a decision and a status view. Supplier ordering, payment and email notifications are outside that scope. Users sign in with existing accounts the business prepares for testing.
Scroll the table sideways to see all columns.
| Requirement | Agreed behaviour |
|---|---|
| Roles | Employee Ana creates and views her own requests. Manager Milan views all requests and makes decisions. Ana cannot access other employees' requests or approve purchases. |
| Completed inputs | Item: wireless keyboard. Quantity: 2. Estimated unit price: EUR 45. Department: Operations. Reason: replace two faulty keyboards. Total: EUR 90, calculated by the application. |
| Input rules | Item, quantity, price, department and reason are required. The total is calculated and cannot be edited. Quantity is a whole number from 1 to 100; price is positive with no more than two decimal places. Department comes from a prepared list. |
| Normal flow | Ana submits the form. The application saves request NAB-104 as “Pending”, with its author and submission time. Milan opens and approves it. The status becomes “Approved”; his identity and the decision time are recorded. |
| Rejection | If the budget is unavailable, Milan selects “Reject” and enters “This purchase is outside this month's budget”. A reason is required. Ana sees “Rejected”, the explanation, the manager’s name and the decision time. |
| Invalid input | Submission fails when the purchase reason is missing. A message appears beside the field, other entries remain in the form and no request is created. |
| Repeated submission | Two clicks or a retry of the same submission after a lost connection return the same NAB-104. Only one request exists. For a deliberately new purchase, Ana opens a new form. |
| Later changes | A submitted request cannot be edited. Milan first rejects an incorrect pending request with a reason. Ana then creates a new request. Once decided, a request cannot be approved or rejected again. |
Agree the correction process before development. In this example, the previous request must be rejected before a new submission, so both purchases cannot remain open.
How do you write acceptance criteria?
Acceptance criteria describe the outcomes you will check for a particular requirement. For NAB-01, the business representative and development team can run these checks with test accounts. Each is a separate scenario; prepare a fresh “Pending” request for each decision check.
- When Ana submits the completed example, one request exists with a EUR 90 total and “Pending” status.
- When the reason is empty or quantity is 0, no request is created; the form displays the relevant error and retains the other entries.
- When Ana tries to open someone else's request or submit an approval decision, the application denies access and leaves the data unchanged.
- When Milan approves the request, Ana sees the decision, his name and its time. A second decision does not change the completed request.
- When Milan rejects without a reason, the status remains “Pending”. With the stated reason, it becomes “Rejected”; Ana sees the explanation, decision maker and time.
- When the same submission is repeated, including a retry after a lost connection, the list contains one NAB-104.
Accepting one action does not cover all application testing. The GOV.UK quality assurance guidance treats functional checks as part of broader testing that includes security, performance and accessibility. Agree who checks those areas and how findings will be recorded.
What does a screen mockup explain?
A mockup shows the arrangement of fields, buttons and messages. Add notes for required inputs, total calculations and the conditions that allow a decision. Include an empty view, an error and a completed request, linked to requirement NAB-01.
A clickable prototype can help employees walk through the task before development. Showing a successful submission does not demonstrate that data storage or access controls have been built. For a public business website, define its content and page structure separately through a website project brief.
For a project using AI search, add permitted sources and expected answers to the specification. Our guide to preparing documents for an AI assistant provides a fictional collection and proposed checks for versions, access and missing information.
Data, integrations and operating requirements
List the data you will import, its sources and the person who checks its accuracy. For an existing spreadsheet, record identifiers, empty fields and duplicates. Agree a trial import, export format and retention or deletion rules. Use fictional or anonymised examples in the initial specification.
If an approved purchase goes to another system, specify the sending trigger, fields and direction of transfer. Decide which system owns the status, who sees failed transfers and how retries avoid duplicates. Establish whether documentation and test access are available before estimating the integration.
Replace “the application must be fast” with a measurable condition. For example: with 20 concurrent users and 10,000 stored purchase requests, at least 95 of 100 list views load in under two seconds. Agree the test environment, device, network and measurement method. These numbers are illustrative; choose the actual target around the work. GOV.UK performance guidance connects testing to planned demand.
Add supported devices, keyboard operation, access management and the procedure for restoring a backup. State how much downtime or loss of recent changes the business can tolerate. Agree with the developer how these requirements will be tested and maintained.
Who approves changes, and what should you send for an estimate?
Name one person in the business who confirms the operating rules. For a proposed change, the development team records its effect on cost, timing and existing functions. Keep the previous version, new version number, reason and approval. Acceptance criteria should refer to the same version as the requirement.
For custom software development, prepare one completed task, a list of existing systems and a separate list of features for later. Include open questions in your free project estimate request. We can use those details to define the first release and identify the information needed for a proposal.