Most SAP consultants treat the functional specification as administrative drudgery to dispatch before getting to the real work. Rookie mistake. A well-written FS decides on its own whether the development fits in two sprints or whether the ABAP team sends the delivery back to you six times for clarification.
This guide targets functional SAP consultants, project managers and juniors who have to write, brief or audit an FS on an S/4HANA or ECC project. I write from the EAM and PP projects I see in the field, from watching FS documents that hold up and FS documents that spin out of control. I am not going to hand you a magic template: I am going to show you how to structure each WRICEF category differently, how to manage customer sign-off, and the seven traps that make a spec drift in delivery.
Why a sloppy FS gets rewritten three times during a project
The Standish Group, in its Chaos Report, regularly ranks the clear statement of requirements criterion among the top three success factors of an IT project, alongside user involvement and executive support. This is no revelation for anyone who has done two SAP projects. A vague FS mechanically generates BUILD rejections, failed acceptance tests and change requests that wreck the schedule. On a fixed budget, it is the project margin that pays the price.
Concretely, here is what an FS that is about to drift looks like. The business rules are described in a vague present tense: “the system checks availability”. Checks how, in what context, on which status? The developer will decide arbitrarily, acceptance testing will discover the gap three months later, the change request will land in the middle of UAT. Multiplied by forty WRICEF objects on a standard S/4HANA rollout, it becomes a wall.
The other classic symptom: the FS that talks solution before problem. You find references to specific BAPIs, Z* programs, custom transactions in it, while the underlying business need is not even described. The developer receives an implementation disguised as a specification. By the time he discovers that the real need could have been served by standard, it is too late, the scope is frozen.
No FS without at least three testable acceptance criteria. If I cannot write “the test passes when X equals Y and Z is in such a status”, I have not specified, I have described an intention. And an intention does not validate a UAT.
FS, TS, SFG, SFD: getting the definitions straight before writing
The vocabulary varies a lot between projects, and the confusion between FS, TS, SFG and SFD is a classic. Let us go through it properly, because the definition you adopt dictates who writes, who signs, and who owns responsibility for the deliverable.
FS versus TS: the functional or technical boundary
The functional specification describes the WHAT. Which business process, which business rules, which behavior expected on the user side. It is written in the language of the business, not in the language of ABAP. The technical specification describes the HOW. Which standard SAP objects are used, which enhancement points, which code structure, which table holds the persistence. It is written for the developer by the developer, or by a senior technical-functional consultant.
Functional specification (FS)
- Describes the business need: why we do it, for whom, in which process
- Written by the functional consultant, validated by the key user
- Contains business rules, exceptions, edge cases, acceptance criteria
- Signed off by the customer sponsor before build
- Readable by a non-developer, no pseudo-code, no table names except in an appendix
- Serves as the reference baseline for UAT acceptance testing
Technical specification (TS)
- Describes the implementation: which SAP objects, which enhancements, which code structure
- Written by the ABAP developer or the senior technical-functional consultant
- Contains class diagrams, BAPI signatures, chosen BAdIs, impacted tables
- Validated by the tech lead or the solution architect
- References the FS on each section for traceability
- Serves as the reference baseline for code review and unit tests
SFG versus SFD: when each one is relevant
The SFG, the general functional specification, gives the overall view. It describes the end-to-end business process, the actors, the main interfaces, without going into the detail of each screen. It is written at the start of the Explore phase, it serves as the basis for the business case and budget scoping. The SFD, the detailed functional specification, zooms in on each object to be developed or customized, with all the business rules, the exceptions, the mockups. It is written at the start of the Realize phase, one per WRICEF object.
On a properly sized project, you have one SFG per macro-process (for example Indirect procurement, Preventive maintenance, Sales order to invoice) and one SFD per WRICEF object (for example MTBF dashboard report, Outbound INVOIC IDoc interface to OMS, Custom BAdI on cost center determination). Many projects skip the SFG step and go straight to the SFDs. It is a short-term saving that costs dearly: without an overall view, the SFDs contradict each other, the processes overlap, and nobody detects the redundancies before integration testing.
Who writes, who reviews, who signs
The FS is written by the functional consultant after a workshop with the key user. The key user validates the business rules on the substance of the business. The ABAP developer reviews the technical feasibility before sign-off and flags any zone of ambiguity. The project manager reviews for schedule impact and inter-object dependencies. The customer sponsor signs to freeze the scope. Without a signature, the FS remains a draft, and any change is free. With a signature, any change goes through a formalized change request.
WRICEF: 6 categories, 6 different FS structures
WRICEF is the inventory of the things standard SAP cannot do for you. Workflows, Reports, Interfaces, Conversions, Enhancements, Forms. Each category has its own spec logic: an IDoc Interface FS has nothing in common with an ALV Report FS. The typical trap is to use a single generic template for all six. You end up with empty or off-topic sections, and you forget the sections that are truly critical for each category.
W as in Workflows: triggering events, branches, escalations
A Workflow FS necessarily describes: the triggering event (creation of a production order, breach of a stock threshold, approval of an order), the actors and their roles, the decision tree branch by branch, the escalation deadlines, the email or Fiori notifications, and the behavior in case of timeout. Reference transaction on the technical side: PFTC for standard tasks, SWDD for the workflow builder, SBWP for the business inbox.
R as in Reports: selection fields, ALV layout, authorizations
A Report FS describes: the selection screen fields (mandatory versus optional, default values), the business filters (plant, product line, period), the ALV output layout with column order, the totals and subtotals, the user variants, the target authorizations. Transactions: SE38 for the ABAP program, SQ01 for a SAP Query, SA38 for execution. For authorizations, I refer you to my article on SAP roles and authorizations.
I as in Interfaces: protocol, mapping, error handling
An Interface FS describes: the protocol (IDoc, RFC, REST, flat file), the field-by-field mapping with transformation rules, the frequency and the mode (synchronous or asynchronous), error handling (replay, alert, dead letter queue), monitoring, the fallback strategy if the interface is down. Transactions: WE30 for the IDoc type, WE60 for the documentation, SM59 for the RFC destinations, BD64 for the ALE distribution model.
C as in Conversions: legacy scope, transformation rules, cutover
A Conversion FS describes: the list of legacy entities to migrate, the expected volume, the legacy to SAP mapping with transformation rules, the default values when the legacy does not carry the information, the cutover strategy (big bang, wave, phased), the rollback. Tools depending on the context: LSMW on ECC, LTMC with its LTMOM on S/4HANA, or batch input for targeted loads.
E as in Enhancements: extension point, before-after behavior, regression scope
An Enhancement FS describes: the extension point used (BAdI, customer exit, enhancement spot, append structure), the standard transaction or program impacted, the behavior before and after custom, the regression scope (which other transactions touch the same extension point), the activation conditions (by company code, by plant, by user). Transactions: SE18 for the BAdI definition, SE19 for the implementation, CMOD and SMOD for the classic customer enhancements. Concrete example on the PP side: a custom batch determination rule typically goes through a BAdI.
F as in Forms: layout, print conditions, output channels
A Form FS describes: the output channel (printing, PDF, email, archiving to a document management system), the layout (zones, repeatable blocks, logos, display conditions), the fill variables, the languages to support, the triggering conditions (output determination), the copies (original, carrier, archive). Tools: SFP for Adobe Form Builder, SMARTFORMS for SmartForms, SE71 for legacy SAPscript (to be avoided in S/4HANA).
I have seen projects impose a single Word template for all FS documents. The result: the Form FS contained a “selection screen fields” section (useless, it is a Form, not a Report), and the Report FS had no “target authorizations” section (because the template came from a Workflow FS). Adopt six templates derived from a common skeleton, not a single one.
Structuring an FS that holds up in a project: the 9-section framework
Across all WRICEF categories, a solid FS holds in nine sections: five are common to all categories, four are specific to the WRICEF category. The framework I apply systematically.
- 1Frame the business need with the key user
A dedicated workshop, never by email. The goal is to understand the process before talking solution. Ask open questions: who triggers, when, in what context, what changes after the action, what must never happen. Expected output: a description of the process in five to ten sentences, validated out loud by the key user.
- 2Identify the target WRICEF category
Workflow, Report, Interface, Conversion, Enhancement or Form. The category determines the structure of the FS. If the need covers several categories (for example a Report that triggers a Workflow), split into two distinct FS documents linked by reference. One FS, one object.
- 3Document rules, exceptions, empty cases and acceptance criteria
For each business rule, list the corresponding exception. For each input field, list the behavior when the field is empty, null or out of range. Quantify the expected volume. Write the acceptance criteria in the format “when X then Y”, testable one by one. This is the content that separates a solid FS from a generic requirements brief.
- 4Have it reviewed in a triangle
Three reviews: key user to validate business consistency, ABAP lead to validate technical feasibility and flag zones of ambiguity, project manager to validate schedule impact and inter-object dependencies. Each reviewer signs off on their pass. No customer signature until all three reviews are closed.
- 5Obtain a scoped sign-off and archive
Customer sponsor signature on a frozen version (PDF with hash or DocuSign). Archiving in the project repo, on Solution Manager or on Confluence depending on the customer stack. The signed scope becomes the reference baseline: any later modification goes through a formal change request with impact analysis, re-estimation and a new sponsor agreement.
The four sections specific to the WRICEF category are added to the core of the FS: mockups for Forms, mapping for Interfaces, decision tree for Workflows, and so on. The matrix below summarizes which sections are mandatory by category.
| Section | Workflow | Report | Interface | Conversion | Enhancement | Form |
|---|---|---|---|---|---|---|
| Business context | mandatory | mandatory | mandatory | mandatory | mandatory | mandatory |
| Scope IN/OUT | mandatory | mandatory | mandatory | mandatory | mandatory | mandatory |
| Business rules | mandatory | mandatory | mandatory | mandatory | mandatory | mandatory |
| Acceptance criteria | mandatory | mandatory | mandatory | mandatory | mandatory | mandatory |
| Sign-off | mandatory | mandatory | mandatory | mandatory | mandatory | mandatory |
| Decision tree | mandatory | optional | optional | optional | mandatory | optional |
| Layout and screens | optional | mandatory | optional | optional | optional | mandatory |
| Data mapping | optional | optional | mandatory | mandatory | optional | optional |
| Error strategy | optional | optional | mandatory | mandatory | optional | optional |
| Extension point | optional | optional | optional | optional | mandatory | optional |
The 7 traps that make an FS drift in delivery
Seven recurring traps that I have seen repeat on almost every project. They silently kill the quality of the deliverable, because none of them raises a red alert when writing: they explode in delivery.
When your Report filters on a plant, what happens if the plant is empty? When your Interface receives an IDoc without the optional segment, how does the system react? An FS that only handles the nominal path is a shaky FS. For each input field, list the expected behavior on an empty value, on an out-of-range value and on a maximum-length value. The developer must be able to code without having to guess.
A Report FS without volume figures will collapse in production. 10 lines expected, the developer writes a simple SELECT loop. 10 million lines expected, you need a HANA-friendly approach with pagination, specific indexes, perhaps a CDS view. Quantify the order of magnitude from the FS onward: number of lines in selection, number of transactions at peak hour, number of IDocs per day. It is non-negotiable on the Interface and Conversion side.
“The system must work correctly” is not an acceptance criterion. A real criterion is written in the format “when condition X then result Y observable in Z”. Example on the Workflow side: “when a production order moves to status REL with a quantity greater than 10000, then an email is sent to the production manager within 60 seconds, visible in their SBWP inbox”. Testable, measurable, enforceable in acceptance testing.
The FS that announces “the system calls BAPI_PO_CREATE with the parameters EKKO-BUKRS and EKKO-LIFNR” is not an FS, it is a disguised TS. The underlying business need (create a purchase order for a selected company code and vendor) must be described BEFORE the solution. It is the developer who translates it into a BAPI in the TS, not the other way around.
The IDoc Interface goes down at 3 in the morning. What happens? Do the orders pile up in a queue, or do they go elsewhere, or are they rejected? Who is alerted, when, through what channel? The FS must document the behavior in degraded mode, otherwise the default code will be “we log and we wait for it to come back”, which translates into 24 hours of delay in production before a human sees the alert.
The MTBF Report FS from a 2022 project does not apply as is to the 2026 project of the same customer. The equipment has changed, the KPI has evolved, the acceptance rules have tightened. Copy-pasting saves two hours of writing and loses three weeks of delivery. Start again from the current need, even if the structure is familiar.
An FS handed to development without a customer signature is an FS that can be modified endlessly. Every meeting produces a new “small clarification” that becomes a parallel development. The signature with a frozen scope is the contractual tool that turns modifications into managed change requests. Without it, you carry the commercial risk of the project alone.
Validation workflow: from draft to customer sign-off
An FS goes through four states: draft, review, validated, signed. The standard review circuit mobilizes four roles. The RACI matrix I use by default, to be adjusted according to project governance.
| Action | Key user | Functional consultant | ABAP lead | Project manager | Customer sponsor |
|---|---|---|---|---|---|
| Business framing workshop | R | A | C | I | I |
| Draft writing | C | R/A | I | I | I |
| Business review | R/A | C | I | I | I |
| Technical feasibility review | I | C | R/A | I | I |
| Schedule and dependencies review | I | C | C | R/A | I |
| Frozen-scope sign-off | C | C | C | C | R/A |
| Post-signature change request | C | R | C | A | R/A |
For archiving, choose according to the customer stack: SAP Solution Manager (with its ChaRM module for ITIL-aligned Change Request Management) if the customer is full SAP, Confluence or SharePoint if the project documentation lives elsewhere. What matters is that the signed version is identifiable without ambiguity (version number, date, signatories) and that later versions are explicitly marked as post-signature revisions with a link to the change request.
On my EAM projects, the quality of an FS predicts schedule adherence better than the talent of the ABAP team.
Pierre Balbinot, functional SAP consultant
Practical SAP-side tools to write and brief an FS
To brief an FS, you need to dive into the SAP standard: understand how the target transaction works today, which enhancement spots exist, which table holds the persistence. The transactions by scoping phase:
| Scoping phase | Transaction | Usage |
|---|---|---|
| Explore a standard transaction | SHDB | Record the run of a transaction to understand the screen-by-screen sequence before specifying a variant |
| Explore a table | SE16N | Check the fields, the values in the database, the real volumes on sandbox |
| Scope an enhancement | SE18 / SE19 | List the BAdIs available on a domain, check the implementations already active |
| Scope a Workflow | PFTC | List the existing SAP standard tasks before creating custom ones |
| Scope a Form | SFP / SMARTFORMS | Check the existing standard Forms before creating Z* ones |
| Scope an IDoc Interface | WE60 | Read the documentation of a standard IDoc type before specifying the segments |
| Scope a Conversion | LTMC | Identify the standard S/4HANA migration object before coding custom |
On the document management side, two families of tools dominate: Solution Manager with its ChaRM module for full SAP projects with aligned ITIL governance, and the Atlassian stack (Jira for tracking, Confluence for the wiki) for multi-vendor projects. DocuSign or Adobe Sign cover legally binding electronic signature. Avoid the PDF attached to an email: impossible to trace the versions, impossible to find the last signed one in case of dispute.
Frequently asked questions about the SAP functional specification
Who writes the functional specification in an SAP project?
The functional SAP consultant writes the FS after a dedicated workshop with the business key user. The business side (customer) validates the business rules on substance. The delivery side (project) translates into technical feasibility. On agile projects, the equivalent role is the product owner for the need and the functional consultant for writing the spec.
What is the difference between an FS and an SAP TS?
The FS describes the WHAT: business need, business rules, expected behavior on the user side, acceptance criteria. The TS describes the HOW: standard SAP objects used, chosen BAdIs, Z* programs, impacted tables, code structure. The functional consultant writes the FS, the ABAP developer writes the TS. The TS references the FS on each section for traceability.
Should the customer sign off the FS before development?
Yes, sign-off is mandatory before the BUILD go-ahead. Without a signature, any change after build is free for the customer and costly for the project. The signature freezes the scope and forces later modifications to go through a formalized change request with impact analysis, re-estimation and sponsor agreement. It is the main contractual tool of delivery.
How do you structure an FS for an ABAP development?
Nine sections: business context, scope IN/OUT, business rules with exceptions and empty cases, mockups or layout, testable acceptance criteria, impact and dependencies, test strategy and data set, technical appendices (Tcodes, tables, candidate BAPIs), scoped sign-off. The four core sections (decision tree, mapping, layout, extension point) vary according to the target WRICEF category.
What does WRICEF contain and why does it change the FS structure?
WRICEF covers Workflows, Reports, Interfaces, Conversions, Enhancements, Forms. Each category has its mandatory sections: an Interface FS describes the IDoc protocol, the mapping and the error handling, a Report FS describes the selection fields and the ALV layout, a Form FS describes the output channel and the print conditions. A single template for the six categories produces shaky FS documents with empty or off-topic sections.
How long does it take to write an SAP FS?
Variable depending on the category and complexity: 0.5 to 2 days for a standard Report FS, 3 to 5 days for an IDoc Interface FS with complete mapping, 5 to 10 days for a complex Conversion or Workflow FS with business workshops included. Count in functional consultant person-days, excluding key user time and excluding the triangulated review.
How do you handle a change of need after the FS is signed?
A formalized Change Request process: description of the new need, impact analysis (build, test, schedule, inter-object dependencies), re-estimation in person-days and in schedule, customer sponsor agreement, signature of an amendment to the FS with a new version number. No silent modification and no verbal agreement. The change request is part of the project deliverable and must be archived with the original FS.
Is an FS mandatory for a simple SAP customization?
Not for standard SPRO customizing without significant business impact (creation of a movement type, adding a language, setting up a calendar). Mandatory for any custom development (Z* program, BAdI, custom IDoc, SmartForm, custom Workflow). Recommended even on standard customizing when the configuration touches a critical business process or when several teams are involved.
Keep reading
SAP Rollout guide: multi-site method with SAP Activate
Most project managers running their first SAP rollout discover after a few weeks that they are managing not an IT project but a transformation of the business operations. The technical...
Pierre B.
SAP Business Blueprint vs Fit-to-Standard: What Replaced It in SAP Activate
If you are starting an S/4HANA project in 2026 and searching for "SAP Business Blueprint", you are using vocabulary from fifteen years ago. The term still gets searched heavily, but...
Michael A.
SAP SD Pricing Determination: The Condition Technique
Sooner or later, on a project, a user shows you a sales order and asks why the displayed price is not the one they expected. You open the line, you...
Michael A.
SAP ECC vs S/4HANA: the key differences for your SAP career
If you look into SAP for your career, two acronyms keep coming up: ECC and S/4HANA. One is the older generation of SAP's ERP, the other is the current version....
Michael A.