Software development scope template
A free functional spec template for software, features, user stories, acceptance criteria, assumptions and exclusions, with revisions and contingency built in.
No card needed. 2 clients and 5 quotes free forever. Unlimited teammates.
What this template is, and who it's for
This is a functional specification for a custom software or web-application build, a portal, an internal tool, an integration, a bespoke feature on top of a platform. It's for developers, technical agencies and product-minded freelancers who need to define what the software does precisely enough to estimate it, build it, and test whether it's finished.
It stops short of a technical design (architecture, data models) on purpose: it defines behaviour and acceptance, which is what a scope needs to be signable and testable.
How to use it
- 1Copy the block below as Markdown or PDF.
- 2List your features. Break each into user stories, and give each story testable **acceptance
criteria**, the conditions that prove it's done.
- 1Keep the Assumptions & exclusions, Revisions and Contingency sections, in software,
the unstated assumption is what blows the estimate.
- 1Review it with both the client and whoever will build it before you commit to a price.
The template
# Functional Specification, [Product / Feature Name]
Prepared by: [Your Name / Studio]
Client: [Client Company]
Date: [DD Month YYYY]
Version: [0.1 draft]
1. Summary
[One paragraph: what the software does, who uses it, and the problem it solves.]
2. Users / roles
- [Role 1, e.g. Admin: manages users and content]
- [Role 2, e.g. Customer: places and tracks orders]
- [Role 3, e.g. Guest: browses, cannot transact]
3. In scope (features)
Feature 1, [name]
As a [role], I want to [action] so that [outcome]. Acceptance criteria:
- [ ] [Given/when/then, or a clear, testable statement]
- [ ] [Validation / error handling behaviour]
- [ ] [Edge case that must be handled]
Feature 2, [name]
As a [role], I want to [action] so that [outcome]. Acceptance criteria:
- [ ] [Testable condition]
- [ ] [Testable condition]
Feature 3, [name]
As a [role], I want to [action] so that [outcome]. Acceptance criteria:
- [ ] [Testable condition]
4. Out of scope
Not included in this build (available as future work):
- [Feature / area, e.g. native mobile apps]
- [Feature / area, e.g. multi-language support]
- [Feature / area, e.g. reporting dashboards]
5. Non-functional requirements
- Performance: [e.g. pages respond within a reasonable target under expected load]
- Security: [e.g. authentication method, role-based access]
- Browser / device support: [list]
- Accessibility: [target, e.g. WCAG 2.2 AA for key flows]
6. Assumptions
- [Third-party API/account access provided by the client by date]
- [Existing data is in a usable, agreed format]
- [Design / UX is supplied, or included and capped at n screens]
- [Environments (staging, production) provided by date]
7. Exclusions & dependencies
- Third-party licence, API or hosting fees are the Client's cost.
- Content, data and credentials supplied by [date]; delays move the timeline.
- [Any component the Client or a third party is responsible for delivering.]
8. Revisions
Each feature includes [2] rounds of change during its build window. Behaviour changes after acceptance are handled as new work under change control.
9. Contingency
A contingency of [15%] (£[…]) covers reasonable unknowns inherent in a build. It is drawn on only with written approval; unused contingency is not charged.
10. Acceptance
A feature is complete when all its acceptance criteria pass in the agreed test environment and the Client signs off. Sign-off is per feature or per milestone as agreed.
Signed for [Client Company]: __________________ Date: __________ Signed for [Your Studio]: __________________ Date: __________
---
What makes a good software scope
- Write acceptance criteria, not wishes. "User login" is ambiguous. "User can log in with email
and password; three failed attempts locks the account for 15 minutes" is testable, and testable is what makes it buildable and billable.
- Name your assumptions loudly. In software, the estimate-killer is almost always an unstated
assumption: the API turned out to be undocumented, the data was messier than promised. Write them down and a broken assumption becomes a change request, not a loss.
- Keep behaviour separate from architecture. A functional spec defines what the system does.
Leave the how, frameworks, schemas, infrastructure, to a technical design so clients can sign the behaviour without wading through implementation.
- Add a bigger contingency than you would for a website. Custom builds carry more unknowns; a
10–20% buffer, agreed up front, is honest engineering, not padding.
- Version the document. Specs change. A version number and a change log stop two people building
from two different understandings.
Build this spec faster in ScopeDeck
A software scope is exactly the kind of document that shouldn't be re-typed between selling and building. In ScopeDeck you write it once as a Specification, seeded from your quote wording, and each feature's tasks roll into a combined delivery list you export as Markdown for your PM tool. Acceptance criteria, assumptions and exclusions stay attached to the sections they belong to, delivery inherits the context instead of reverse-engineering a PDF. Start free, no card needed.