Functional specification template for software

Published 18 October 2026 · updated 22 October 2026

A functional specification describes what a piece of software will do — its features, screens, rules and data, as the people using it will see them — without saying how it will be built. It is the document a client signs off before development starts, and the one testers check the result against. Below is a free template to copy, a filled-in example, and how a functional specification differs from a BRD, a PRD and a technical specification.

What a functional specification document includes

• Document control: the version, its status, who wrote it and who has to sign it off.
• Purpose and scope: what the system or release is for, what is in, and what is out.
• Users and roles: who uses it and what each role may do.
• Functional requirements: one per block, each with an ID, the business need it answers to, a priority and acceptance criteria.
• User flows: the steps through each task, including what happens when one fails — a use case per task is one way to write them.
• Screens: wireframes, fields, validation and actions.
• Business rules the system enforces.
• Data: what is stored, what is required, how long it is kept.
• Integrations with other systems, and what happens when one is down.
• Notifications and reports.
• Non-functional requirements — speed, security, availability, accessibility — or a pointer to where they live.
• Assumptions, dependencies and open questions.
• Changes since the last version, and the sign-off.

The template

Copy it into Google Docs, Word or Confluence. Everything in square brackets is yours to fill in.

FUNCTIONAL SPECIFICATION

Project:    [project name]
Version:    [x.y]
Status:     [draft / in review / signed
            off]
Author:     [name, role]
Reviewers:  [names, roles]
Based on:   [business requirements],
            version [x.y]

1. PURPOSE AND SCOPE
   Purpose:       [what this system or
                  release is for, in two
                  sentences]
   In scope:      [features this document
                  covers]
   Out of scope:  [what it does not cover,
                  that someone might
                  assume it does]

2. USERS AND ROLES
   [role]:  [who they are, and what they
            may do]
   [role]:  [   ]

3. FUNCTIONAL REQUIREMENTS
   (one block per requirement; each says
   one thing)

   ID:           FR-[nnn]
   Feature:      [feature name]
   Requirement:  [what the system does, in
                 one sentence]
   Answers to:   [the business requirement
                 it serves]
   Priority:     [must / should / could]
   Acceptance criteria:
     Given [the starting state]
     When  [one action]
     Then  [the result anyone can see]

4. USER FLOWS
   [flow]:    [step], then [step], then
              [result]
   If it fails: [what the user sees, and
                what happens]

5. SCREENS
   [screen]:  [link to the wireframe]
   Fields:    [field, type, required or
              not, validation]
   Actions:   [each button, and what it
              does]

6. BUSINESS RULES
   RULE-[n]:  [a rule the system enforces]

7. DATA
   [entity]:  [fields, which are required,
              how long kept]

8. INTEGRATIONS
   [system]:  [what is sent or received,
              and when]
   If down:   [what the user sees, what is
              retried]

9. NOTIFICATIONS AND REPORTS
   [name]:  [who gets it, when, and what
            it contains]

10. NON-FUNCTIONAL REQUIREMENTS
   Performance:    [e.g. "search answers
                   within 2 s"]
   Security:       [roles, data
                   protection]
   Availability:   [hours, and what is
                   acceptable]
   Accessibility:  [the standard it meets]

11. ASSUMPTIONS, DEPENDENCIES, OPEN
   QUESTIONS
   [   ]

12. CHANGES SINCE THE LAST VERSION
   [x.y], [date]:  [what changed, why, and
                   the change request
                   number]

13. SIGN-OFF
    (one block per person)
   Name:      [   ]
   Role:      [   ]
   Decision:  [approved / approved with
              comments / rejected]
   Version:   [x.y]
   Date:      [   ]

Functional specification example

One requirement from a customer portal, filled in:

ID:           FR-014
Feature:      Invoices
Requirement:  A signed-in customer can pay
              any open invoice of their
              company by card.
Answers to:   BR-03: shorten the time
              invoices stay unpaid
Priority:     Must
Acceptance criteria:
  Given an open invoice for 1,250.00 EUR
  When  the customer pays it by card, and
        the bank approves the payment
  Then  the invoice shows "Paid" with
        today's date
  And   a receipt is emailed to the
        billing contact

  Given an open invoice
  When  the customer pays it by card, and
        the bank declines the payment
  Then  the invoice stays "Open"
  And   they see "Your bank declined the
        payment"

Business rule RULE-07:  Only users with
    the Billing role may pay an invoice.

More on writing the criteria in the acceptance criteria template.

Functional requirements examples

Each one says one thing a user or another system can see, and can be tested.

For a web application

• A user can reset their password through an emailed link that expires after one hour.
• A signed-in user sees only their own company’s data.
• After 30 minutes without activity, the user is signed out and returned to the sign-in page.

For an online shop

• A discount code is applied before tax, and the saving is shown on its own line.
• The order confirmation email lists every item, the delivery address and the total paid.
• An item that sells out while it is in a basket is flagged at checkout before payment is taken.

For a mobile app

• An unsent message is kept as a draft when the app goes to the background.
• With no connection, the app shows the last synced data and the time it was synced.
• Tapping a push notification opens the screen it refers to.

For a database and its data

• Deleting a customer keeps their invoices, marked “customer deleted”.
• Every change to a price is recorded with the old value, the new value, who changed it and when.
• An order number is never reused.

For reports

• The monthly sales report can be filtered by region and exported to CSV.
• The totals in a report match the sum of the rows shown.

For administration

• An admin can deactivate a user, and the user’s open sessions end within one minute.
• An admin can see who changed a user’s role, and when.

For notifications

• Customers get an email three days before a subscription renews.
• A user can turn off marketing emails without turning off invoices and receipts.

For integrations

• New orders reach the warehouse system within five minutes; a failed send is retried three times, then support is alerted.
• A payment the payment provider confirms twice is recorded once.

For the customer portal in these templates

• FR-014: A signed-in customer can pay any open invoice of their company by card.
• FR-015: A receipt is emailed to the billing contact after each payment.
• FR-016: One reminder is sent seven days after the due date for every invoice not paid in full.

Each needs its own acceptance criteria, and each says what the system does, not how. How functional requirements differ from business rules, constraints and the other kinds is in types of requirements and business rules vs requirements; to write them in a fixed pattern, see EARS.

Functional vs non-functional requirements

More examples by type, with a template: non-functional requirement examples.

Functional spec vs BRD, PRD and technical spec

The names overlap from one company to the next — some teams write a PRD that is really a functional specification. What matters is that “why”, “what” and “how” each have a home, and that each is written for the people who have to agree with it.

How to write a functional specification

1. Start from the business requirements. Every functional requirement names the business need it answers to; one that answers to nothing is scope nobody asked for.

2. Write for the person who signs. The client has to understand every line. Technical detail belongs in the technical specification.

3. One requirement says one thing, with an ID, so it can be discussed, tested and changed on its own.

4. Give every requirement acceptance criteria. They are what user acceptance testing checks at the end.

5. Write what is out of scope as carefully as what is in it.

6. Keep it as short as it can be. Length is not thoroughness:

   40 pages, every edge case, traceability matrix and all. technically thorough, completely unreadable for the people who needed to decide. they’d glaze over and defer, and nothing would move.

   — a business analyst, r/businessanalysis, June 2026

   A commenter on the same problem: “it was rare someone that mattered ever fully read a PRD past a certain length” (r/ProductManagement). Split it by feature, and give decision-makers a summary of what they are deciding.

7. Version it, and get it signed off on a version. The requirements sign-off template has the wording.

8. After sign-off, change it only through change requests, and record each one in the changes section — see change request vs pull request.

Who writes the functional specification?

Usually a business analyst or a product manager writes it, with the client or product owner; developers and testers review it for what they will build and check; and the client signs it off. That sign-off is the point of the document. A product owner’s advice to a newcomer, about their requirements document: “Make sure you get the stakeholders to sign off on that BRD, so that they can’t come back later and blame you if they requested the wrong thing or missed some detail you didn’t read out of their minds. This is your contract with them” (r/businessanalysis, May 2025).

Keeping a functional specification current

A signed-off specification starts to age as soon as development starts. The technical plan finds gaps — “You can also create a beautiful and perfect functional spec that becomes a swiss cheese of gaps when you create your technical implementation plan” (Hacker News, February 2026) — and the work moves into tickets. A commenter described a previous company that stopped writing specifications altogether — “just input everything to JIRA in the first instance, if a document was required we’d extract JIRA to a word doc and circulate” — and added: “They never nailed how to document changes/fixes/updates to functionality to a satisfactory degree though before I left” (r/businessanalysis, 2023).

Either way, the document the client signed and the system being built drift apart — that is spec drift. Three habits slow it down: record every approved change as a new version with its reason; keep the acceptance criteria next to the requirement they check; and when a requirement changes, find the tickets and tests built against the old one.

Where Specroot fits

This is the problem Specroot works on: a functional specification the client signs off as a version, which stays linked to the work built from it. Specroot for agencies and consultancies.