Software Specification Template: A Full Worked Example for a System or App

TL;DR: A useful software specification covers eleven sections: goal and metrics, users and roles, main flows, screens, business rules, permissions, data and integrations, non-functional requirements, analytics, out of scope, and open questions. Below is a copyable template with a filled-in example for each section, taken from a CRM for a service company. Define permissions, business rules, accessibility and data integrity precisely. Leave interface choices that have several good answers for a working version.

What this document is for

Search for a software specification template and you mostly find a table of contents: empty headings with no hint of what goes under them. This one comes filled in, so you can copy the structure and see what a finished section looks like.

The specification is the document your team builds, tests and estimates from. It comes out of the discovery phase. If you run a tender, it becomes the attachment that lets every vendor price the same system. (Writing the tender itself is covered in our RFP guide.) This article covers the document itself.

Our running example is fictional: an air-conditioning service company with a 12-person call center, 2 dispatchers and 40 field technicians. Today everything runs on spreadsheets, phone calls and WhatsApp groups. The company wants a CRM that manages each service call from the first phone call to the invoice.

Use one test for every line you write. If a developer, a QA engineer and a product manager can each check it and agree on the result, it is a requirement. Otherwise it is a wish.

The template, section by section

1. Goal and success metrics

What to write: the business problem in two or three sentences, the goal, and two to four metrics with today's value, a target and a date. Metrics tell you whether the project worked. They also settle arguments about priorities.

Example: "Customers call the center to ask when the technician will arrive. Dispatchers schedule from a spreadsheet. Some repairs need a second visit because the technician arrived without the right part. Goal: manage every call in one place and let customers see the arrival time themselves."

2. Users and roles

What to write: each type of user, how many there are, what they do in the system and on which device. These roles become the columns of the permissions matrix in section 6.

3. Main flows

What to write: for each flow, who starts it, what triggers it, the steps, the end state, and what happens when something goes wrong. Most specs skip the exceptions, and that is where schedules slip.

Main flow: a service call, end to end

1. A customer calls. The agent finds them by phone number or creates a new customer.
2. The agent opens a call: fault type, unit, address and urgency.
3. The system suggests time slots by area and availability. The agent books one with the customer.
4. The customer gets a text with the booking and a tracking link.
5. The dispatcher assigns a technician or approves the system's suggestion.
6. The technician taps "On my way," and the customer gets an update with an estimated arrival time.
7. The technician records the repair, parts and photos, gets the customer's signature and closes the call.
8. The system issues an invoice and sends it to the customer.

Exceptions to cover: a part is missing (the call moves to "waiting for part" and a return visit is booked), the customer isn't home, the customer cancels, and a technician calls in sick at 7 a.m. with six visits booked.

4. Screens

What to write: each screen, who uses it, what it lets them do and on which platform. At this stage, describe what the screen must allow. Its design can wait.

5. Business rules

What to write: each rule as a condition and a result, with an ID and an example. The ID lets tickets and tests point to the rule. A rule that says "per company policy" leaves someone to guess.

6. Permissions matrix

What to write: actions against roles. Define each permission on the data itself. Hiding the Export button protects nothing if the API still returns the full customer list.

7. Data and integrations

What to write: the main entities and their key fields, the source of truth for each piece of data, what may never be deleted, and what moves over from existing systems. For each integration: direction, what moves, when, and what happens when the other side is down.

Example: customer, address, unit, service contract, call, visit, part and technician. One data-integrity rule worth copying as is: a call is never deleted. It is canceled with a reason, and every status change is kept in its history with the user's name and the time.

8. Non-functional requirements

Last checked: September 2026. This is general information, not legal advice.

What to write: numbers. "The system should be fast" can't be tested. "Customer search by phone returns a result within one second" can.

Privacy. A CRM holds a database of personal data. In Israel that brings it under the Privacy Protection Law and the Privacy Protection (Data Security) Regulations. Amendment 13 to the law took effect on August 14, 2025 and tightened enforcement. Your team can't guess which data you truly need or how long to keep it. Write it in the spec.

Accessibility. In Israel, IS 5568 is based on WCAG 2.0 at level AA, and the service accessibility regulations require it for websites that serve the public. In our example, the customer tracking page is such a service. Write down the level, the screens in scope, who tests and when, and who writes the accessibility statement. For products sold abroad, name the standard each market expects. Accessibility added just before launch means reopening screens that are already built.

9. Analytics

What to write: which events the system records, so you can measure the goals from section 1. A metric with no recorded event behind it is one you can't measure after launch.

10. Out of scope

What to write: what this version will leave out, stated plainly. This section prevents many arguments halfway through the project.

• Full inventory management (in version 1 the technician only records which parts were used)
• A customer app in the app stores
• Card payments in the field
• Fully automatic dispatch (the system suggests, the dispatcher decides)

11. Open questions

What to write: everything still undecided, who answers it and by when. A spec with zero open questions usually means someone made decisions quietly.

What to specify up front, and what to decide on a working version

With AI agents doing much of the implementation, you reach a version people can run much earlier, and interface changes cost little. We wrote about this in what "that's not what I asked for" really costs. For your spec, it means each line needs its own level of detail. Some things are binding, so define them precisely. Others are easier to judge on a real screen.

The rule of thumb: anything that can hurt a user, money or data gets defined up front. Anything with several good answers gets tested on a working version.

Frequently asked questions

What is the difference between a software specification and a requirements document? A requirements document (PRD) mainly describes what the product must achieve and why. A specification adds what the team needs to build it: flows, screens, business rules, permissions, data and non-functional requirements. In small and mid-size projects they are usually one document, and this template covers both.

Who writes the software specification, the client or the development company? Usually both, together. You bring the business knowledge: the processes, the rules and the users. The development company brings the right questions, experience with exceptions and the technical requirements. At Globalbit this is part of our product strategy and design work.

How much does a software specification cost? Our discovery phase, which produces the specification, costs $5K to $15K depending on the size of the system. Our discovery phase guide covers what you get and when you can skip it.

Do you still need a specification when developing with AI agents? Yes, and it gets shorter and more focused. Define the binding parts explicitly: permissions, business rules, accessibility and data integrity. Test interface choices that have several good answers on a working version.

Is there a CRM specification example? The example in this article is one: a CRM for a service company with a call center, dispatchers and field technicians. If you are specifying a sales CRM, look at our Sales Copilot CRM first, then specify only what it leaves uncovered.

Want a second pair of eyes on your spec, or help writing it? Talk to us.