Functional Design Specification: Template + Example

Quick answer: A functional design specification describes what a system will do, in plain language, before anyone writes code or draws a wiring diagram. It says how the system behaves and how people interact with it — not how it’s built. Everyone signs it off, then engineering builds to it and testing proves it.

One thing most guides on this topic leave out: they explain what an FDS is and then never show you the structure. The template below is the part you actually need.

What Is a Functional Design Specification?

A functional design specification is a document that describes how a system will behave, in language a non-engineer can read and approve.

It answers three questions:

Question	Example
What does the system do?	“The pump starts when the tank level falls below 20%.”
How do people interact with it?	“The operator selects Auto or Manual on the HMI overview screen.”
What happens in each situation?	“On loss of level signal, the pump stops and Alarm A-104 activates.”

The critical rule: an FDS describes behaviour, not implementation. It says the valve closes. It does not say which PLC output card drives it, what the tag name is, or how the rung is written. Those belong in the design specification that comes next.

That’s not a stylistic choice. It’s what lets a plant manager, a QA reviewer, and a customer all read the same document and agree on it — none of whom read ladder logic.

What Is FDS?

FDS stands for Functional Design Specification. You’ll also see it written as:

• FS — Functional Specification
• FRS — Functional Requirements Specification
• SFS — Software Functional Specification

These are the same document under different names. Which one your organisation uses depends on industry and house style more than on any real difference. Pharmaceutical manufacturing tends toward “Functional Specification,” industrial automation toward “Functional Design Specification,” and software teams toward “Functional Requirements Specification.”

Pick one name and use it consistently across a project. Mixing them in the same document set causes exactly the confusion the FDS exists to prevent.

What Is an FDS Not?

Four things it gets mistaken for.

It’s not a requirements document. The customer’s requirements live in the URS. The FDS is the answer to those requirements.

It’s not a design document. It says what happens, not how it’s built. No tag names, no I/O addresses, no code structure, no hardware model numbers.

It’s not a test plan. But your test plan is written from it — more on that below.

It’s not a scope document or a contract. It may be referenced contractually, and it usually is, but its job is technical clarity rather than commercial terms.

The single easiest test: if a sentence in your FDS would have to change because you switched PLC brand, it doesn’t belong in the FDS. Switching from Siemens to Rockwell shouldn’t change what the machine does.

What Is the Difference Between a URS, FDS, and DDS?

This is the most common confusion in this subject, and getting it wrong causes real project damage.

Document	Question it answers	Written by	Language
URS — User Requirements Specification	What do I need?	The customer or end user	Business and operational
FDS — Functional Design Specification	What will the system do?	The supplier or system integrator	Plain, behavioural
DDS — Detailed Design Specification	How will it be built?	The engineering team	Technical

Worked through one requirement:

URS: “The system must prevent the tank from overflowing.”

FDS: “When the level transmitter LT-101 indicates 90% or above, the inlet valve XV-101 shall close within 2 seconds and high-level alarm A-201 shall activate. The valve shall remain closed until level falls below 85% and the operator acknowledges the alarm.”

DDS: “LT-101 is a 4-20mA input on slot 3, channel 2 of the analogue input card. The comparison executes in FB_LevelControl, scan-scheduled at 100ms. XV-101 is driven from DO slot 5, channel 7, fail-closed on loss of signal.”

Same requirement, three levels of detail. The FDS is the one the customer signs, because it’s the only one they can meaningfully review.

Where projects go wrong: the FDS gets written with DDS-level detail in it. The customer can’t review it, signs it anyway, and nobody discovers the misunderstanding until factory acceptance testing — which is the most expensive possible moment to find it.

Why Does the FDS Exist? The V-Model

The V-model is the framework connecting your specification documents to your testing. It’s the single most useful thing to understand about why an FDS matters.

Picture a V. Specifications run down the left side. Testing runs up the right. Each specification pairs with the test that proves it.

Left side (specify)	Right side (verify)
URS — user requirements	PQ — Performance Qualification: does it meet the user’s actual need?
FDS — functional specification	OQ — Operational Qualification: does it do what the FDS says?
DDS — detailed design	IQ — Installation Qualification: is it built and installed as designed?
Build

The consequence, and it’s the whole point: your OQ test protocol is written directly from your FDS. Every functional statement becomes a test case.

So a vague FDS produces a vague test protocol, which produces a system nobody can prove works. And an FDS statement you can’t test is a statement you’ll have to rewrite during validation, under time pressure, with the customer watching.

This pairing is why the “is it testable?” question below matters more than any formatting rule.

What Are the Key Elements of a Functional Design Specification?

Twelve sections. Not every project needs all twelve, but the ones you skip should be a decision rather than an oversight.

1. Document control. Version, author, approvers, revision history, and the date. Sounds like bureaucracy; it’s the thing that stops two people building from different revisions.

2. Introduction and purpose. What this document covers, what system it describes, and who it’s for.

3. Scope. What’s in, and explicitly what’s out. Undefined scope is the most common source of dispute at acceptance testing.

4. References. The URS this responds to, applicable standards, related drawings, and any prior documents.

5. Definitions and abbreviations. Every acronym, every tag prefix convention, every term that means something specific here.

6. System overview. A short narrative plus a block diagram. What the system is, what it’s part of, what it connects to.

7. Operating modes. Manual, Auto, Semi-Auto, Maintenance, Emergency Stop. Define each one, what’s available in it, and how you move between them.

8. Functional requirements. The core of the document — the sequences, the control logic, the behaviour. Usually the longest section.

9. Operator interface. HMI screen layout, navigation, what each control does, what each indicator means, security levels and who can do what.

10. Alarms and events. An alarm list with cause, priority, effect, and the action required. Plus how alarms are acknowledged and reset.

11. Interlocks and safety. What prevents what, under which conditions. Usually presented as a matrix.

12. Reporting and data. What’s logged, what’s trended, what’s reported, and retention requirements.

Two sections people skip and regret: operating modes and interlocks. Behaviour that’s obvious in Auto is often undefined in Manual, and that gap surfaces during commissioning.

Functional Design Specification Template (Copy This)

Copy this. Nothing is gated.

FUNCTIONAL DESIGN SPECIFICATION
Project:            ________________
Document number:    ________  Revision: ____
Prepared by:        ________  Date: ________
Reviewed by:        ________  Date: ________
Approved by:        ________  Date: ________

REVISION HISTORY
Rev | Date | Author | Description of change

1. INTRODUCTION
1.1 Purpose
1.2 Intended audience
1.3 Related documents (URS ref, standards, drawings)

2. SCOPE
2.1 In scope
2.2 Out of scope
2.3 Assumptions and constraints

3. DEFINITIONS AND ABBREVIATIONS
Term | Meaning

4. SYSTEM OVERVIEW
4.1 System description (narrative)
4.2 Block diagram
4.3 Major equipment list
4.4 Interfaces to other systems

5. OPERATING MODES
Mode | Description | Available functions | Entry condition | Exit condition
Manual      |  |  |  |
Auto        |  |  |  |
Semi-Auto   |  |  |  |
Maintenance |  |  |  |
E-Stop      |  |  |  |

6. FUNCTIONAL REQUIREMENTS
6.1 [Function area 1]
    FR-001  When [condition], the system shall [action] within [time].
    FR-002  ...
6.2 [Function area 2]
    ...
   (Number every statement. You will reference these in testing.)

7. OPERATOR INTERFACE
7.1 Screen hierarchy and navigation
7.2 Screen descriptions (one per screen)
    - Purpose
    - Displayed values and units
    - Controls and their effect
    - Security level required
7.3 Colour and symbol conventions
7.4 User roles and permissions
    Role | View | Operate | Configure | Administer

8. ALARMS AND EVENTS
Tag | Description | Cause | Priority | System effect | Operator action | Reset
A-101 |  |  |  |  |  |

9. INTERLOCKS AND SAFETY
9.1 Interlock matrix
    Condition | Prevents | Overridable? | By whom
9.2 Emergency stop behaviour
9.3 Safe state on power loss
9.4 Safe state on communication loss

10. REPORTING AND DATA
10.1 Logged values and frequency
10.2 Trends
10.3 Reports (content, format, trigger)
10.4 Data retention

11. TESTING REFERENCE
    Each FR number maps to an OQ test case.
    Traceability matrix attached as Appendix A.

APPENDIX A — TRACEABILITY MATRIX
URS ref | FDS ref (FR-xxx) | Test ref (OQ-xxx) | Status

Two notes on using it. Number every functional requirement from the start — retro-fitting numbers to a finished FDS is miserable and error-prone. And fill in section 5 before section 6, because most behaviour is mode-dependent and defining modes late means rewriting the functional section.

How Do You Write a Functional Statement That Can Be Tested?

This is the skill the whole document rests on, and almost no guide covers it.

A functional statement is testable if someone who didn’t write it can read it, perform the test, and get an unambiguous pass or fail.

Four rules:

1. Name the trigger. What specific condition causes this?

2. Name the action. What exactly happens?

3. Give a measurable value. A number, a time, a state — something observable.

4. One behaviour per statement. If your statement contains “and also,” split it.

Before and after:

Untestable	Testable
“The system shall be user-friendly.”	“Any screen shall be reachable from the overview screen in no more than 2 navigations.”
“The pump shall start automatically.”	“FR-012: When level in T-101 falls below 20%, pump P-101 shall start within 5 seconds, provided the system is in Auto mode and no interlock is active.”
“Alarms shall be clearly displayed.”	“FR-045: Unacknowledged high-priority alarms shall flash red at 1Hz in the alarm banner on every screen until acknowledged.”
“The system shall respond quickly.”	“FR-067: Screen transitions shall complete within 1 second under normal load.”
“The valve closes on high level and the alarm sounds and the pump stops.”	Split into FR-021, FR-022, FR-023 — three statements, three test cases.

Words that make a statement untestable: user-friendly, intuitive, robust, efficient, appropriate, adequate, as required, quickly, reliably, where necessary. Every one of these will be interpreted differently by the writer and the tester.

Use “shall” consistently. Convention across engineering specifications is that “shall” means a binding requirement, “should” is a recommendation, and “may” is optional. Mixing them casually creates arguments about what was actually committed to.

Functional Design Specification Example

Five worked examples in the format you’d actually write them.

1. Tank fill sequence

FR-101 When the operator presses START on the Tank Fill screen and the system is in Auto mode, the sequence shall begin at Step 1.

FR-102 Step 1: Inlet valve XV-101 shall open. If XV-101 open feedback is not received within 5 seconds, the sequence shall abort and alarm A-110 shall activate.

FR-103 Step 2: The sequence shall hold until level transmitter LT-101 indicates 85%.

FR-104 Step 3: XV-101 shall close. Sequence complete indicator shall illuminate.

FR-105 At any step, pressing STOP shall close XV-101 and place the sequence in Held state, retaining the current step number.

FR-106 From Held state, pressing START shall resume at the retained step. Pressing RESET shall return the sequence to Step 0.

Note what this does: it defines the abort path, the hold behaviour, and the resume behaviour. Most FDS sequences define only the happy path, and every problem in commissioning comes from the ones that don’t.

2. Motor start/stop

FR-201 In Manual mode, pressing START on the P-101 faceplate shall energise the motor starter, provided no interlock in the P-101 interlock group is active.

FR-202 If a start is attempted while an interlock is active, the start shall be inhibited and the interlock reason shall be displayed on the faceplate.

FR-203 Motor running status shall be derived from the starter auxiliary contact, not from the output command.

FR-204 If run feedback is not received within 3 seconds of the start command, the output shall de-energise and alarm A-220 (P-101 Failed to Start) shall activate.

FR-205 Loss of run feedback while running shall de-energise the output and activate alarm A-221 (P-101 Unexpected Stop).

FR-203 is the kind of statement that prevents a real class of bug — status derived from the command rather than feedback tells the operator the motor is running when it isn’t.

3. Alarm cause and effect

Tag	Description	Cause	Priority	System effect	Operator action
A-110	T-101 valve fail to open	XV-101 open feedback absent >5s after command	High	Sequence aborts to Step 0	Check valve and air supply, reset
A-201	T-101 high level	LT-101 ≥ 90%	High	XV-101 closes, inlet sequence inhibited	Acknowledge; sequence resumes below 85%
A-202	T-101 high-high level	LSHH-101 discrete input active	Critical	All inlet valves close, hardwired	Manual reset at panel required
A-220	P-101 failed to start	Run feedback absent >3s after start	Medium	Output de-energised	Investigate, reset on faceplate
A-310	LT-101 signal fault	Input <3.6mA or >20.4mA	High	Level control to Manual, inlet inhibited	Check transmitter and wiring

A-202 is hardwired rather than software — worth stating explicitly, because it changes how it’s tested and whether software can defeat it.

4. Interlock matrix

Interlock condition	Prevents	Overridable	By whom
T-101 level ≥ 90%	XV-101 open	No	—
T-101 level ≤ 5%	P-101 start	Yes	Maintenance role, logged
E-Stop active	All motor starts, all valve opens	No	—
P-101 local isolator off	P-101 start	No	—
Comms fault to remote I/O	Auto mode entry	Yes	Engineer role, logged

The “overridable” and “by whom” columns are the ones that get left out, and they’re the ones auditors ask about.

5. HMI screen behaviour

FR-401 The Overview screen shall display current level, mode, and running status for T-101 and P-101.

FR-402 Selecting the P-101 symbol shall open the P-101 faceplate as a modal popup.

FR-403 Mode selection controls shall be visible to all roles but enabled only for Operator role and above.

FR-404 Configuration values shall be editable only by Engineer role and above. Each change shall be recorded in the audit log with user, timestamp, old value, and new value.

FR-405 Equipment symbols shall follow the colour convention in Section 7.3: green running, grey stopped, red faulted, flashing red unacknowledged alarm.

Which Standards Apply to an FDS?

Which standards apply depends heavily on your industry. The ones most likely to be relevant:

Standard	Covers	Relevant when
GAMP 5 (ISPE)	Good practice for validating automated systems	Pharmaceutical, biotech, medical devices — any regulated manufacturing
ISA-88 (S88)	Batch control models and terminology	Batch processes: pharma, food and beverage, specialty chemicals
ISA-95 (S95)	Integration between enterprise and control systems	MES/ERP interfaces, plant-level data
IEC 61511	Functional safety for the process industry	Safety instrumented systems, SIL-rated functions
IEC 61131-3	PLC programming languages	Referenced by the DDS more than the FDS

Two practical points.

In GAMP 5 contexts, the FDS is a formal validation deliverable, not just an engineering document. It has to be approved, version-controlled, and traceable both to the URS above it and the OQ protocol below it. The traceability matrix isn’t optional there.

Safety functions usually live in a separate document. If your system has SIL-rated safety functions, those typically belong in a Safety Requirements Specification governed by IEC 61511, not in the general FDS. Reference it; don’t absorb it.

Standards get revised. Cite the edition you’re working to — “GAMP 5 Second Edition” rather than just “GAMP 5” — and confirm which version your client or regulator expects.

What Is a Traceability Matrix?

A traceability matrix links every user requirement to the FDS statement that answers it, and every FDS statement to the test that proves it.

URS ref	Requirement	FDS ref	Test ref	Status
URS-012	Prevent tank overflow	FR-201, FR-202	OQ-014, OQ-015	Passed
URS-013	Operator can stop the fill at any point	FR-105, FR-106	OQ-016	Passed
URS-021	All configuration changes recorded	FR-404	OQ-031	Open

It does two jobs. It proves nothing was forgotten — every URS line has an FDS answer. And it proves nothing was invented — every FDS statement traces back to a requirement somebody asked for.

That second one matters commercially. An FDS statement with no URS reference is scope you’re building for free, and the matrix makes it visible before you build it rather than after.

Who Should Review and Sign Off an FDS?

The FDS is worthless unless the right people actually read it.

Who should review, and for what:

Reviewer	Checking
End user / operator	Does this match how we actually work?
Process or production engineer	Is the sequence correct for the process?
Controls engineer	Is this buildable as written?
QA / validation (regulated industries)	Is it traceable and testable?
Safety	Are interlocks and safe states correct?
Project manager	Does it match the contracted scope?

Three things that make reviews work:

Give reviewers a specific question. “Please review” gets skimmed. “Please confirm section 5 matches how you run the plant on night shift” gets read.

Get an operator in the room. The person who runs the equipment finds more real problems in an hour than anyone else finds in a week — they know what actually happens when things go wrong.

Freeze it after sign-off. Changes after approval go through formal change control with a revision number. An FDS that quietly drifts is worse than no FDS, because people build from different versions believing they agree.

Where Can I Find Templates for Functional Design Specifications Online?

Four sources, with honest trade-offs.

1. The template above. It’s complete, it’s free, and it isn’t behind a signup form. Start there.

2. Your own past projects. Usually the best source, because it already reflects your house conventions, your client’s expectations, and the lessons from your last commissioning. If your organisation has done this before, that template beats anything generic.

3. Your client’s template. In regulated industries and large end users, the client often mandates their own format. Ask before you write anything — rewriting a finished FDS into someone else’s structure is a week you won’t get back.

4. Industry bodies and vendors. ISPE publishes guidance in the GAMP 5 context. Major automation vendors publish specification templates aligned to their platforms. System integrator associations sometimes share examples.

Two cautions about template hunting.

Most free templates online are empty section headings. They give you a table of contents, not a specification. The value is in knowing what a good functional statement looks like — which is why the examples above matter more than the structure.

Watch for templates built for the wrong document. A lot of pages titled “functional specification template” are actually software requirements templates, and they’ll steer you toward user stories and acceptance criteria rather than sequences and interlocks. Check that the example content matches your domain before adopting the structure.

8 Mistakes That Ruin an FDS

1. Implementation detail in the FDS. Tag names, I/O addresses, and code structure belong in the DDS. Their presence means the customer can’t review it.

2. Untestable statements. “User-friendly,” “robust,” “as required.” Every one becomes an argument during OQ.

3. Unnumbered requirements. You can’t build a traceability matrix from prose.

4. Only the happy path. Define abort, hold, resume, and fault behaviour. That’s where commissioning problems live.

5. Undefined operating modes. Behaviour that’s obvious in Auto is often undefined in Manual.

6. No safe state on power or comms loss. Two specific questions that need two specific answers.

7. Sign-off without an operator. The people who run the equipment find the real problems.

8. Silent revisions. Changes after approval need a revision number and change control, or people build from different documents.

FDS Checklist

• [ ] Document control complete, with version and approvers
• [ ] Scope states what’s out, not only what’s in
• [ ] Every URS requirement has a corresponding FDS statement
• [ ] Every functional statement is numbered
• [ ] Every statement has a trigger, an action, and a measurable value
• [ ] One behaviour per statement
• [ ] “Shall,” “should,” and “may” used consistently
• [ ] No implementation detail — would survive a change of PLC brand
• [ ] All operating modes defined, with entry and exit conditions
• [ ] Abort, hold, resume, and fault paths defined for every sequence
• [ ] Alarm list includes cause, priority, effect, and operator action
• [ ] Interlock matrix includes overridability and by whom
• [ ] Safe state defined for power loss and comms loss
• [ ] HMI security roles and permissions specified
• [ ] Traceability matrix attached
• [ ] Reviewed by an operator, not only by engineers
• [ ] Applicable standards cited with edition

How Writegenic AI Fits In

An FDS is a document, and writing it is where the project time goes. The engineering decisions take a workshop; turning them into a complete, consistently structured, reviewable document takes considerably longer.

Writegenic AI is an AI writing platform with 300+ templates and support for 120+ languages, including a set built for technical and project documentation:

• AI for Project Management — drafting project and engineering documents from structured inputs
• Requirements management plan generator — for the requirements process your FDS answers to
• Project management tools — templates for the surrounding deliverables
• AI Prompt Generator — build one reusable prompt encoding your section structure and statement format, so every FDS comes out consistent
• 120+ languages — useful on international projects where the client reviews in their own language

Where the line sits, clearly. A writing tool turns your decisions into a complete document and keeps ten specifications consistent with each other. It cannot decide what the sequence should be, know that this client’s operators always override that interlock, or judge whether a statement is testable in your specific test environment. Those are engineering judgements, and in a regulated context a named person has to approve them.

Draft the document with the tool. Keep the engineering.

Start with Writegenic AI free.

Frequently Asked Questions

Related reading: Requirements Management Plan · Risk Assessment Plan Template · Risk Response Strategies · AI for Project Management