Functional Specs, Workshop Notes and Documentation With AI

Documentation takes a large share of a consultant's week: workshop minutes, requirement lists, functional specifications, configuration documents and change requests. AI can produce good first drafts in minutes, so you spend your time on the content and the client, not on formatting and wording.

Before anything: anonymise

Replace the client's name, company codes, plant names, vendor and customer names, prices and any personal data with neutral placeholders such as Client A, Plant 1000, Vendor X. The AI only needs the structure of the requirement, not the client's identity. Lesson 7 covers this in full.

From workshop notes to minutes

After a requirement workshop you usually have rough notes. Paste them (anonymised):

These are my rough notes from a procure-to-pay requirement workshop for
Client A (S/4HANA, MM):
"""
[paste notes]
"""
Turn them into:
1. Summary (5 lines)
2. Decisions made (bullets)
3. Requirements, numbered, each with: description, priority if mentioned,
   and whether it is standard or may need development
4. Open points with owner and due date ("Not decided" if not in notes)
Do not add requirements that are not in my notes.

The last line keeps the AI from inventing requirements. "May need development" is only a first guess for you to confirm.

Drafting a functional specification

Every project has its own template. Give the AI your template headings and the requirement:

Draft a functional specification using these sections: [paste your
template headings]. Requirement (anonymised): [describe the requirement,
business process, trigger, input, output, users, volumes].
For each section, write what you can from the requirement and mark gaps
clearly as [TO CONFIRM]. Do not invent table names, fields or system
behaviour; write [TO CONFIRM IN SYSTEM] instead.

You then fill the gaps with real object names from the system and confirm the behaviour with the client.

Good things to ask AI to add to a spec:

• Error handling and exception scenarios
• Authorisation considerations
• Test scenarios, including negative cases
• Assumptions and dependencies

Explaining a design to the business

Specs are often too technical for business users. Ask for a plain-language version:

Rewrite this design summary for business users who do not know SAP
terms. Explain what will change in their daily work, in 8 bullet points.

Keeping documents consistent

Large projects have dozens of documents with inconsistent terms. Paste two sections and ask:

Compare these two document sections. List inconsistent terms, numbers or
process descriptions, and suggest one consistent wording.

You can also build a project glossary: "From these documents, list SAP and business terms with a one-line definition each."

Change requests and status reports

Draft a change request from these notes: [notes]. Sections: background,
requested change, business justification, impact (process, data,
reporting, testing, training), effort assumptions [TO CONFIRM], risks.

Turn my weekly notes into a status report for the client project manager:
progress, next steps, risks and issues, decisions needed. One page.

Practice task

Take your latest workshop notes or a requirement you are working on. Anonymise it, generate structured minutes or a first spec draft using your project's template, and fill every [TO CONFIRM] from the system or with the client. Compare the time taken with your usual approach.

Key takeaways

• Anonymise client details before using any public AI tool.
• Turn rough notes into decisions, numbered requirements and open points.
• Draft specs in your own template, with gaps marked [TO CONFIRM] instead of invented objects.
• Use AI for plain-language versions, consistency checks, change requests and status reports.