A functional specification document (often shortened to "functional spec" or "FS") describes what a
system, process, or customization is supposed to do before anyone builds it. It exists to answer three
questions for everyone involved: what's the overview, what problem are we actually solving, and how are
we solving it. That's what lets an end user and a developer read the same page and agree on the outcome.
Functional specs matter most when something new enters an ERP project, because every customer's
processes are a little different, and out-of-the-box software rarely covers a fully customized workflow
on its own.
Every functional specification is built around three parts. Tap each card to see what it means in practice.
1
Overview
Tap to flip
The big picture. What system or process this document covers, and who needs to
read it, so every stakeholder starts from the same context before the details show up.
2
Problem
Tap to flip
What's actually broken or missing. The specific gap between how the ERP works
out of the box and how your business actually operates.
3
Solution
Tap to flip
Exactly how it will work. The configuration, workflow, and UI/UX detail developers
build from, and the part end users sign off on before work starts.
When Do You Actually Need One?
Does anything below sound familiar?
Your ERP's default workflow doesn't match how your team actually works
You're asking a developer or VAR to build a custom feature or integration
More than one department needs to agree on how a new process will run
A past project didn't match what was verbally agreed to
You're evaluating vendors or writing an RFP and need documented requirements
If two or more of those sound familiar, that's the signal a functional spec earns its keep. See how we scope and write ours on the
Functional Specification service page.
How a Functional Spec Actually Gets Built
This is the process our team runs on every custom ERP workflow. Tap a step to expand it.
Before anything gets written down, we pin down exactly what the customization or optimization is
meant to achieve, so the rest of the document has a clear target.
Stakeholders, end users, and solution architects get in a room (virtual or otherwise) to work through
the process together. We wrote a full breakdown of why these sessions matter in
Designing Your ERP Success: Why Workshops Matter.
We document how the process actually runs today (not how it's assumed to run), so nothing gets
lost in translation.
New processes and workflows get mapped out in detail, showing exactly how work will move through
the system once the customization is live.
Configuration and workflow requirements, the desired UI/UX, and project scope and timeline
expectations all get written down in language both end users and developers can act on.
The finished document gets reviewed by everyone with a stake in the outcome, so accuracy gets
checked before a single hour of development is spent.
What Happens If You Skip It?
Skipping the functional spec doesn't remove the requirements-gathering step — it just moves it later,
into development, where changes cost more and take longer. It's the same risk we cover in
ERP Isn't All or Nothing: Smart Phased Rollouts Protect Your Project:
projects that skip planning steps tend to run into scope creep, mismatched expectations, and rework.
A functional spec pairs naturally with the discovery work done in a
feasibility study and the structure
set up during
solution design and project kick-off.
Together, they're what keep a custom ERP build from becoming a guessing game.
A functional spec describes what the system should do, in language end users and business
stakeholders can understand. A technical spec describes how developers will build it:
code structure, APIs, database changes. The functional spec typically comes first and informs
the technical spec.
It's usually written by a solution architect or business analyst who can translate what end users
need into requirements a development team can execute, built collaboratively with input from
the people who'll actually use the system day to day.
Usually not. If you're using standard, out-of-the-box functionality, the software's existing
documentation covers "what it does." Functional specs earn their value specifically when a
process, workflow, or feature is being customized.
A feasibility study asks
whether and how an ERP initiative should happen at all: scope, readiness, effort. A functional
spec picks up after that, defining exactly how one specific customization or workflow will work.
It depends on how many stakeholders and processes are involved, but expect it to run alongside
your design and rediscovery workshops rather than as a separate phase tacked onto the end.
Ready to Turn Requirements Into a System That Works?
We'll help you document exactly what needs to be built (and why) before a single hour of development starts.
Johans Saavedra is an ERP industry veteran with over 31 years of experience across Acumatica, Dynamics SL/GP, and Sage. Specializing in system implementations, T-SQL, and custom report design, Johans has led major enterprise tech initiatives worldwide—including engineering an Amazon integration that processed 20,000 daily orders for NYC's Mohawk Group. A Computer Science graduate and certified bilingual professional (English/Spanish), Johans enjoys scuba diving, basketball, and traveling outside of work.
