Most SAP landscapes carry hundreds or thousands of custom programs whose original functional documentation is long gone. The developer who wrote them has moved on, the spec was never updated after the third change request, and now someone needs to know what a program actually does: before an S/4HANA move, during an AMS handover, or when an auditor asks. Reconstructing a functional specification from the code itself, reverse-engineering it, is one of the most useful and least documented skills in SAP work. Here is a method that makes it repeatable rather than heroic.
What is a functional spec, and when do you need to reverse-engineer one?
A functional specification describes what a program does in business terms: its inputs, its outputs, the rules it applies, and the effect it has on the system. A technical spec describes how. You need to reconstruct one whenever the code has outlived its documentation and a decision now depends on understanding it:
- S/4HANA readiness: you cannot decide keep, retire, or rebuild for a custom object you cannot describe.
- AMS onboarding: a new support team inherits programs no one can explain.
- Knowledge loss: the original developer has left and took the context with them.
- Audit and compliance: someone has to state, in business language, what a program does to the data.
Do you start by reading the code or reading the data?
Start with the data and the boundary, not line one of the code. A program is a contract between its inputs and its outputs, and you understand a contract faster from its edges than from its interior. Before reading the logic, answer three questions:
- What goes in? The selection screen, variants, and parameters define the inputs.
- What comes out? A list, an ALV grid, a file, a posting, an update to a table. That is the program's purpose in one sentence.
- What does it touch? The tables and views it reads and writes, visible from the Data Dictionary and the declared data sources.
Only once you know the boundary does the internal logic become readable, because you now know what it is for.
A repeatable six-step method
- Establish the boundary. Document the inputs (selection-screen fields, variants, parameters) and the outputs (report, download, update, message). Inputs plus outputs equal the program's contract.
- Map the data sources. List the tables and views read, the keys and joins, and the sequence. Group them by business object (the document header, its items, the master data it enriches from) rather than by table name, so the map reads in business terms.
- Trace the processing. Follow the path from input to output and record each transformation: the validations, the calculations, the selections and filters, the status changes. This is the body of the spec.
- Separate business rules from plumbing. The functional spec captures intent, not implementation. "Skip items where the delivery is complete" is a business rule and belongs in the spec. A nested loop or a performance optimisation is plumbing and does not. Keeping these apart is what makes the result a functional spec rather than a paraphrase of the code.
- Capture the side effects. Note everything the program changes or emits: table updates, documents posted, files written, calls to other programs or interfaces, and the authorization checks that gate them. Side effects are where reverse-engineering most often misses risk.
- Validate with a human SME. A reconstructed spec is a hypothesis until a functional expert confirms it against how the business actually runs. Reading the code tells you what it does; only a person who knows the process can tell you whether that is what it is supposed to do.
What makes a reverse-engineered spec trustworthy?
Three things: traceability, validation, and honesty about the unknowns.
- Traceability: every rule in the spec should point back to the place in the code it came from, so a reviewer can check it.
- Validation: an SME has signed off that the reconstructed behaviour matches business intent.
- Explicit unknowns: dead code, unreachable branches, and behaviour you could not confirm are listed as open questions, not quietly omitted. A spec that hides its gaps is more dangerous than one that names them.
The traps that catch people
- Dead code and unreachable branches that look like live rules.
- Copy-paste variants: three programs that are 90 percent identical, where the 10 percent is the whole point.
- Hardcoded values standing in for configuration.
- Undocumented enhancements and BAdI implementations that change behaviour from outside the main program.
- The "temporary" fix that became permanent and now carries a rule no one remembers.
Where does AI help, and where does it not?
Reading code and drafting a first-pass spec is exactly the kind of patient, mechanical work AI is good at: it can read a long program far faster than a person and produce a structured first draft. Two conditions decide whether that draft is worth anything.
First, it has to be grounded in the system's own truth, the SAP Data Dictionary, so that a table, a field, or a where-used relationship is read from the system rather than guessed. Second, it has to be verification-gated: the draft is a starting point a human SME confirms, never an answer taken on faith. Used that way, AI removes the slow first pass and leaves the expert to do the judgement. Used without grounding or a human gate, it produces confident documentation that is wrong, which is worse than none.
The short version
- Reverse-engineer a functional spec whenever a decision depends on a custom program you can no longer describe.
- Start from the boundary (inputs and outputs), then the data, then the logic.
- Separate business rules from plumbing, and capture the side effects.
- Trust comes from traceability, SME validation, and naming the unknowns.
- AI can draft the first pass if it is grounded in the Data Dictionary and confirmed by a person.
Prashanth P.M, PMP, is leads SAP delivery at a SAP Partner company. The team builds C16, an AI platform for SAP operations.
Bluesky
