Requirements, Fit-Gap, and Specifications

Where scope is set and where projects are won or lost. As a developer you are not a passive recipient here — the quality of your challenge determines how much unnecessary work gets built.

Process workshops

The core activity of the design phase. A workshop walks through one end-to-end process with the people who actually do it.

Typical O2C workshop agenda (2–3 days):
  1. Current state: how do you take an order today? (with real examples)
  2. Pain points: what goes wrong?
  3. Standard system demo: here's how the product does it
  4. Fit-gap discussion: what works, what doesn't, and why
  5. To-be design decisions
  6. Open items and owners

Attend these. Ask questions. The developer who understands why the business needs something builds a better solution than the one who receives a spec.

Questions worth asking in a workshop

• “How many times a day does this happen?” (volume drives design)
• “What happens today if this goes wrong?” (error handling requirements)
• “Who else needs to know when this happens?” (integration and notification)
• “Show me a real example, including a difficult one.” (edge cases)
• “Is this a legal requirement or a preference?” (negotiability)
• “Is this how you’d do it if you were starting fresh?” (legacy workarounds)

That last one surfaces an enormous amount of unnecessary scope.

Fit-gap analysis

Requirement ──▶ Does the standard system do it?
                     │
        ┌────────────┼──────────────┬────────────────┐
        ▼            ▼              ▼                ▼
       FIT       CONFIGURABLE     GAP           NOT NEEDED
   No action     Config only    Build or       Challenge and
                                change process    remove

Classification is a real skill, and consultants disagree constantly:

Classification	Meaning	Effort
Fit	Standard does it	0
Fit with config	Configuration achieves it	Low
Gap — workaround	Standard functionality used differently, with a documented process	Low
Gap — extension	Sanctioned custom development	Medium
Gap — modification	Core change. Escalate	High + permanent
Gap — third party	Buy a specialist product	Medium
Gap — process change	The business adapts	Political, not technical

A common project finding: 30–50% of items initially classed as gaps turn out to be configurable. Someone has to check, and it’s usually cheapest for that someone to be a developer who knows the config layer.

The gap challenge questions

Before agreeing to build anything:

1. Why is this needed? What business outcome depends on it?
2. Is it a legal or contractual requirement? If yes, it’s non-negotiable. If no, everything is on the table.
3. How many users, how often, how much time saved? Quantify the value.
4. Does the standard do it differently but acceptably?
5. Is this a workaround for a limitation of the old system?
6. What happens if we don’t build it? (The answer is often “nothing much”)
7. Can it wait until Phase 2? A surprising amount can, and half of it is never asked for again.
8. Who owns it after go-live? Unowned customisations rot.

A useful framing: “If we build this, it costs 15 days now plus retesting at every upgrade forever. Is the process change genuinely worse than that?” That question, asked politely with real numbers, kills more unnecessary scope than any governance process.

MoSCoW prioritisation

MUST have     Legal requirement or the business genuinely cannot operate
SHOULD have   Important, painful workaround exists
COULD have    Nice to have, no material impact
WON'T have    Explicitly out of scope for this phase — written down

Everything is “must have” until you attach a cost and a date. The discipline is forcing the business to rank within “must have” — if everything is a must, nothing is prioritised, and the schedule decides for you at the worst possible moment.

The functional specification

Written by the functional consultant, describing what is needed:

FS-042 — Aged Stock Provision Report

1. Business requirement
   Finance needs a monthly report of inventory value by ageing bucket
   to calculate the IAS 2 obsolescence provision.

2. Process context
   Run at period end, before the provision journal is posted.
   Owner: Financial Controller.

3. Selection criteria
   Company code (mandatory), plant (optional, multiple),
   material group (optional), key date (mandatory, default = today)

4. Logic
   For each material/plant with stock > 0:
     - determine the last goods movement date (issues only, movement types 2xx/6xx)
     - calculate age in days = key date − last issue date
     - assign bucket: 0–180, 181–365, 366–730, >730
     - provision %: 0%, 25%, 50%, 100%
     - provision value = stock value × provision %

5. Output
   Material | Description | Plant | Qty | Value | Last issue | Age | Bucket | Prov % | Prov value
   Subtotals by bucket and by plant. Grand total.
   Export to Excel required.

6. Authorisation
   Only users with the Financial Controller or Cost Accountant role.

7. Volume
   ~85,000 material/plant combinations. Expected runtime < 5 minutes.

8. Open items / assumptions
   - Consignment stock excluded (confirmed with Finance, 2026-02-14)
   - Provision percentages to be maintained in a config table, not hardcoded

Good functional specs have: the business reason, exact logic, exact output, authorisation, and volume. If yours lacks any of these, ask before you build. “The spec didn’t say” is not a defence when the report is wrong.

The technical specification

Written by you, describing how:

TS-042 — Aged Stock Provision Report

1. Reference: FS-042 v1.2
2. Object type: Report (ALV / custom UI)
3. Objects to create:
     - Program/class: ZFI_AGED_STOCK_PROVISION
     - Selection screen structure
     - Config table: ZFI_PROV_BUCKET (company, bucket_from, bucket_to, pct, valid_from)
     - Authorisation object check: Z_STOCK_PROV
4. Data sources:
     - MARD/MBEW (stock and valuation) or the equivalent CDS view
     - MSEG filtered on movement types 2xx/6xx for last issue date
5. Algorithm:
     - Single aggregated query for last issue date per material/plant
       (avoid per-material lookups — 85k iterations)
     - Join to valuation in memory
     - Bucket assignment from the config table
6. Performance:
     - Target < 5 min for 85k records
     - Index check on MSEG (matnr, werks, bwart, budat)
     - Test with a full production data copy
7. Error handling:
     - No stock found → empty result with a message, not an error
     - Missing config for a bucket → hard error naming the missing range
8. Test cases: (listed, with expected results)
9. Transport/deployment plan
10. Rollback plan

Write the technical spec before coding. It’s where you notice that the functional spec is ambiguous, and it’s much cheaper to discover that in writing than in UAT.

Requirements traceability

Business requirement → Functional spec → Technical spec → Code object
                                                        → Test case
                                                        → UAT script
                                                        → Training material

A traceability matrix links these. It answers: “is every requirement built and tested?” and “why does this object exist?” — the second question being surprisingly hard to answer three years later.

Requirements anti-patterns

Anti-pattern	Why it’s bad
“Make it work like the old system”	Reimplements 20 years of workarounds
Requirements written as screen designs	Prescribes a solution, hides the actual need
“The system should be user-friendly”	Untestable
No volume or performance stated	You’ll find out in UAT
No error-case definition	Half the code is error handling
Sign-off by IT rather than the process owner	The wrong person approved it
Verbal requirements	They change, and nobody remembers
Gold-plating by the vendor or the developer	Scope creep from the supply side
A gap accepted without a challenge	Unnecessary permanent cost

The scope change process

Scope will change. Manage it rather than resisting it:

Change request raised
   → Impact assessment: effort, cost, timeline, risk, what it displaces
   → Change control board decision
   → Approved: baseline updated, plan updated, budget adjusted
   → Rejected: logged, and revisited in Phase 2

“Yes, and here’s what it costs and what it displaces” is a far better answer than “no”. It moves the decision to the person who should be making it.

Documentation that actually gets used

Most project documentation is written once and never read. The exceptions:

Document	Read by	When
Process flows	Everyone	Constantly
Configuration rationale	Support team	Every “why does it do that?”
Technical specs	The next developer	Every enhancement
Interface contracts	Both sides	Every change
Runbooks	Support	At 3am
Test scripts	Regression testing	Every upgrade
Authorisation matrix	Security, audit	Every audit
Data dictionary of custom fields	Everyone	Forever

Write these well. The 200-page blueprint document nobody opens after go-live is not where to spend your effort.

Next

• Data migration
• Extensibility and customization