Software requirements connect a business problem with behaviour that a team can build and verify. A user story helps explain who needs to do something and why. Acceptance criteria describe the conditions under which the required behaviour is considered complete. Neither replaces decisions about data, permissions, integrations and operational support.
This guide is for a small business preparing or reviewing a software specification. It turns broad requests into reviewable examples without assuming that every project needs a large formal document.
Describe the task and its purpose
Start with a real user role, the task and the reason it matters. For example, a dispatcher needs to identify incomplete collection requests so that missing information can be obtained before a vehicle is allocated. That establishes context; it does not yet specify the fields, permissions or allocation rules.
Distinguish a user need from a proposed interface. A request for a dashboard may conceal several tasks involving prioritisation, access and exception handling. Ask what decision the person must make and what information is required. A simpler list may be sufficient when a complex visual dashboard adds little value.
Define scope and boundaries
Record what the first release includes, what it excludes and which existing systems remain responsible for related work. Describe the actors and their responsibilities. If an external booking system remains authoritative, the new application should not quietly become another competing source of availability.
List assumptions and unresolved decisions separately from agreed requirements. Assign an owner to each question that could affect the design or estimate. Treat an assumption as something to verify, not as a fact that becomes binding because it appears in a document.
Make data rules explicit
Define required fields, formats, identifiers and relationships. Explain how duplicates, missing values and corrected records are handled. Include retention and deletion requirements where relevant, with the responsible review owner. A label such as customer details is too broad to establish what the application may collect or change.
Specify state changes and their consequences. A request moving from draft to submitted might become visible to staff, trigger a notification and prevent certain edits. Describe those effects individually. A status name alone does not establish the rules attached to it.
Write testable acceptance criteria
Use concrete conditions and observable outcomes. An example might state that a request lacking its collection postcode remains incomplete, displays a clear explanation and does not enter the allocation queue. Include what happens to entered information and whether the user can resume the task.
Avoid criteria such as easy to use or fully secure without a way to evaluate them. Define representative tasks, access boundaries and quality expectations. Where a requirement concerns performance, state the workload and measurement conditions rather than quoting an unexplained target.
Include exceptions and permissions
- Who can create, view, edit, approve or cancel a record?
- What happens when an integration is unavailable?
- How are duplicate submissions detected or reconciled?
- Which actions require a review before taking effect?
- What information is shown when validation fails?
- How can staff recover from an interrupted task?
Test access restrictions through the underlying service, not only by hiding buttons. A user who cannot see an edit control should also be unable to perform the same action through another request path. Describe the intended boundary for each important operation and record the expected failure response.
Specify integration responsibilities
Identify the connected service, exchanged data, trigger, authentication method and failure handling. Record whether an acknowledgement means the data was received or the business action was completed. Those meanings can differ. Include retry rules, duplicate protection and the owner of unresolved exceptions.
Define which system owns a value when the same information appears in several places. If both a CRM and booking application can change a customer record, the project needs an agreed reconciliation rule. Calling the systems integrated does not settle conflicts or establish a complete workflow.
Keep requirements traceable as decisions change
Give important requirements stable identifiers and relate them to their user need, acceptance checks and delivery decisions. Record the reason for a change and the affected dependencies. A revised requirement can alter tests, training, support and an estimate as well as the visible interface.
Use a proportionate change-control process. Distinguish a clarification from additional scope, assess the effect and obtain the right decision before implementation. Preserve the agreed version, so everyone can identify what is being built and which later proposals remain unresolved.
Review requirements with examples
Walk through a normal task, an exception and a permission boundary with the people who perform the work. Ask them to explain the outcome they expect. Contradictions often become visible through an example that would remain hidden in a broad feature list.
For a fuller first-release document, read our software requirements specification guide. Giraffe Digital's digital strategy service can connect the specification with business priorities, existing systems and a practical delivery roadmap.
