How to write a custom software requirements spec
A requirements spec for custom software names the outcome, the owner of each line, what this version leaves out, and who may accept a change. Write the spec first, so acceptance criteria have a document to match. A sentence with no outcome and no owner stays in discussion.
On this page
Write the spec before acceptance
Each line names four things: what counts as done, who owns the line, what this version will leave undone, and who may accept a change to the line. Leave any of the four blank and the sentence stays in discussion.
Acceptance criteria say how that same outcome will be shown in a demo or in user acceptance. That is covered in How to write acceptance criteria for custom software. This note stops at the spec you write before building starts. The delivery scope sits under Custom software, websites, and applications.
The standard asks for information items
ISO/IEC/IEEE 29148:2018, Systems and software engineering — Life cycle processes — Requirements engineering, was published as edition 2 in November 2018. The ISO catalogue page says this edition was reviewed and confirmed in 2024, so this version remains current, and that it is expected to be replaced by ISO/IEC/IEEE DIS 29148 within the coming months. The life-cycle table marks 16 February 2026 as the date the international standard moved to “to be revised”. The abstract says the standard specifies the information items the requirements processes produce, the required contents of those items, and guidelines for the format of the required and related information items. It applies regardless of project scope, methodology, size, or complexity.
The IEEE page says the standard was published on 30 November 2018 and lists the status Active Standard. The same page says it defines the construct of a good requirement, provides attributes and characteristics of requirements, and discusses iterative and recursive application through the life cycle. It also says information items for requirements engineering, and their content, are defined. That content can be added to the requirements-related processes in ISO/IEC/IEEE 12207 or ISO/IEC/IEEE 15288, or used on its own. The public pages do not list the information items by name. This note does not copy characteristic adjectives those pages do not list, and it does not quote a price. The four sections below are a way for a buyer to line the spec up before building starts.
Name the outcome and the owner
Write the outcome as a state someone else can match later: which role finishes which action on which screen, and which record the system keeps. The owner is the person who will confirm that the line is the one they need. Put the name on the line.
“Easy to use”, “stable”, or “fast” is not yet an outcome. If you have no measurement of your own, with a date, leave seconds out of the line. Class names, packages, and algorithms stay in the design note. The spec keeps the outcome and the person who will confirm the line.
Keep out-of-scope in its own section
Give this version its own section for work it will not do. Each item names what is left out for now, and which outcome would have to change, and who would accept it, if the item later comes in. Without that section, a wish from a meeting gets treated as a promise during the build.
Moving an item into scope means adding the outcome and the owner in the same edit, and changing the spec version. Deleting the sentence from the out-of-scope section, with no new outcome line, widens the scope without a record.
Record the version and who accepted it
Each version of the spec is an information item you can point to. A change is one record: who proposed it, who accepted it, which outcome changed, and whether the out-of-scope section changed with it. The person who accepts the change and the owner of the line may be the same person. The record still shows the two roles apart.
Keep the version in the Git history the team already uses, or in an equivalent record, with the date you read or edited it. A later reader has to be able to name the version the build started from. This note does not add a second numbering scheme beside the record you already keep.
Hand the spec to the acceptance list
The acceptance list is produced from the outcome lines. One outcome becomes one acceptance line, or one group of them. Acceptance adds how the outcome will be shown: a demo, or user acceptance. How to write that part stays in the acceptance note. This note does not rewrite it.
When the spec changes, the acceptance list changes in the same edit, and both point at the new version. Changing the spec on acceptance day so that it matches whatever was just shown removes the baseline for the next round. Out-of-scope items stay off the acceptance list.
When a shorter spec is the right spec
Skip a separate line for every label, colour, and internal function. Those sentences have no outcome of their own, and an owner will not confirm them one by one. Keep the count to what the owner can actually read and confirm.
While the owner is still unnamed, or the out-of-scope section is still empty, leave the list short. Name the person first, then add the lines that person will confirm, and write what this version will not do.
When to wait before building
When outcomes still say “easy to use”, a line has no owner, the out-of-scope section is empty, or nobody is named to accept a change, wait before building starts. Fix the spec, then schedule the build.
This note does not state a page count, a duration, or a service level. Those figures have to come from your own spec and change records, with the definition written down. Until that record exists, check the spec by whether every line has an outcome and an owner, whether out-of-scope is its own section, and whether a change names who accepted it and points at one version.