MES Requirements Specification: Lastenheft Structure & Checklist

What a MES requirements specification actually is — and why the document that most projects start with is the wrong one

A MES requirements specification (German: Lastenheft) is the customer-authored document that describes, in implementable detail, what a future Manufacturing Execution System must do to solve the customer's production-management problem. It is the reference artefact against which vendor proposals are compared, against which the subsequent functional specification (German: Pflichtenheft, the vendor's how-response) is written, against which acceptance tests are derived, and against which change requests during implementation are evaluated. A MES project without a serious requirements specification is not a project; it is an extended workshop that eventually gets a system installed, usually at three times the originally quoted budget, and the gap between what the customer expected and what was delivered is traceable, every single time, to a requirement that was either unstated or ambiguously stated in the document that was supposed to prevent exactly that gap.

I have been implementing machine data acquisition and MES projects since 1991, and I have read an embarrassing number of requirements specifications in that time. The single observation I have made that I would offer to anyone starting such a document today is this: the requirements specification is not the hard part of a MES project, but it is the part that, done poorly, makes every subsequent hard part harder by a factor of two or three. The cost of fixing a badly specified requirement after contract signing is roughly 10× the cost of specifying it correctly up front; after go-live it is closer to 100×. This is not a MES-specific observation — it is the well-established Boehm cost curve for software requirements — but it is particularly brutal in MES because MES projects cut across IT, OT, production planning, quality, and maintenance simultaneously, and a single ambiguous requirement can fork the project in five different directions before anyone notices.

Lastenheft vs Pflichtenheft — two documents with fundamentally different authorship and purpose

The confusion between these two documents is the single most common structural failure I encounter on the customer side, and in German-speaking MES procurement the two terms are often used interchangeably, which produces exactly the wrong organisational behaviour: customers write vague Lastenhefte that read like Pflichtenhefte, vendors write Pflichtenhefte that read like Lastenhefte, and nobody knows which document is binding. The table below fixes the distinction.

The critical consequence: the requirements specification makes vendors comparable; the functional specification makes delivery verifiable. These are not the same job. Conflating them produces documents that serve neither purpose, which is the state of perhaps half the MES requirements documents I have seen over three decades.

The nine-section structure — what a serious MES requirements specification contains

A MES Lastenheft that is fit for its purpose — comparing vendors, deriving acceptance tests, anchoring change-control discussions — organises around nine distinct sections. Each section has a defined question it answers and a defined output. Sections cannot be skipped without creating a predictable failure mode further down the project timeline.

Total target: 60–140 pages for a mid-scope Mittelstand project. Larger multi-plant or regulated environments extend to 200+ pages; single-line pilot scopes can be handled in 30–50 pages. Below 30 pages, the document is almost always underspecified in at least two of the nine sections.

Use cases — the format that disciplines the entire document

Section 3 (use cases) deserves separate treatment because it is the section that most strongly determines whether the remaining sections will be written well. A requirements specification built around use cases forces every downstream section — functional requirements, data model, interfaces, KPIs, NFRs — to answer the question "what does this have to do with the operational scenario we are trying to support?" A requirements specification built around feature lists produces the opposite: vendors receive a shopping list of functions without operational context and respond with boilerplate capability checks, which produces proposals that cannot be distinguished from each other.

Below is the use case template I use. Every significant operational scenario should be described with exactly these fields, and no others. Longer templates produce writing fatigue; shorter templates lose the detail that makes the use case actionable.

A serious MES Lastenheft contains 15–30 use cases. Covering fewer produces gaps that vendors discover in implementation; covering more produces writing fatigue without added information. The six use cases every MES Lastenheft must include, regardless of scope: order release and start, production feedback loop (cycles, counts, quality), changeover, stop / downtime classification, shift close / handover, and quality event and release. Beyond these six, which use cases are needed depends on the specific production environment and scope.

Functional requirements — the MoSCoW discipline and why "must" must be meant

Functional requirements form the largest section and produce the most scope-creep damage when written carelessly. The disciplined approach uses MoSCoW prioritisation: Must (non-negotiable, project fails without it), Should (important, workaround acceptable if delayed), Could (nice, low priority), Won't (explicitly out of scope for this phase). Every requirement carries a unique ID, a priority level, and acceptance criteria.

Teams where more than 50 % of requirements are classified as "Must" have almost certainly failed to prioritise. Vendors receiving such documents interpret them correctly: nothing is actually critical, because if everything is, nothing is. The single most useful discipline I enforce in requirements workshops: force the team to classify at most 40 % as Must, and watch what they fight over. That fight surfaces the real priorities.

Requirement quality criteria — IREB / ISO/IEC/IEEE 29148

Every individual requirement should satisfy the quality criteria established by IREB (International Requirements Engineering Board) and codified in ISO/IEC/IEEE 29148:2018 (Systems and software engineering — Life cycle processes — Requirements engineering). These are not academic abstractions — they are the criteria by which a requirement can be turned into a test case. A requirement that fails these criteria cannot be verified at acceptance, which means it cannot be enforced, which means it does not exist in any operational sense.

Data model & master data — the section projects die in

Section 5 is the section where requirements-specification quality most reliably predicts project outcome. A well-specified data model produces a project in which the first integration works on day one; a poorly specified data model produces a project in which integration problems surface in week five, at which point fixing them means reworking every adjacent section of the specification. The discipline is to name, in the Lastenheft, the mandatory data objects, their unique identification, their relationships, and their versioning rules.

The two fields that cause 80 % of data-model problems in MES projects are source of truth (which system is authoritative for each object — wrong answers here produce endless reconciliation disputes) and versioning rule for recipes and work plans (unversioned recipes make retrospective traceability mathematically impossible). Getting these right in the Lastenheft is worth more than every other data-model decision combined.

OEE definitions — the section most commonly skipped, most expensively relearnt

Section 7 subsumes OEE and KPI definitions, and it is the section I have seen skipped most often in otherwise-competent requirements specifications. The assumption — "OEE is standard, everyone knows how to calculate it" — is wrong. OEE has a canonical formula (Availability × Performance × Quality) but the operational definitions of each component vary by a factor of three depending on how planned time is defined, what counts as downtime, how micro-stops are handled, and which stop categories are excluded. A MES specified without an OEE definition arrives at go-live with an OEE number that all stakeholders interpret differently; the subsequent six months are spent reconciling the interpretations instead of improving the production.

A serious OEE specification in the Lastenheft looks like the following, and it takes 2–4 pages to write properly.

Interfaces — the specification matrix that prevents integration waste

Every interface between MES and any adjacent system should be specified at field level in a matrix, not in prose. The prose-based interface specification is where 70 % of integration surprises originate. The matrix approach forces precision, makes gaps visible during review, and produces a document that vendors can cost directly.

Every interface in scope deserves a matrix like this. A typical MES project has 4–8 interfaces (ERP, PLC/SCADA, QA, LIMS, BI, CMMS, HR/AD, Historian), each with 2–10 specific message types. A complete interface specification therefore produces 15–60 such matrices. The alternative — "the system shall be integrated with SAP via IDoc" — is not a specification; it is a wish.

Non-functional requirements — the section vendors exploit when you leave it vague

Non-functional requirements (NFRs) — performance, availability, security, offline capability, backup, update behaviour — are the section that most requirements specifications treat as an afterthought and that most vendors treat as a negotiation space after signing. Vague NFRs get translated into "commercially reasonable" in the functional specification, which translates into "whatever the vendor feels like providing" in operation. The fix is to specify every NFR with an explicit measurement methodology.

The Greenfield Fallacy — and why brownfield reality must be in the Lastenheft

Here is the observation from thirty-five years of shopfloor implementation work that I would place above every other point in this article: almost every MES Lastenheft I have read is written as if the production environment is greenfield — modern machines, uniform PLC generations, clean data, consistent network infrastructure. Almost every production environment I have actually walked into is brownfield: 30 years of machine acquisitions, four or five PLC generations in parallel, machines from 1992 next to machines from 2024, some with OPC UA, some with Profinet, some with no digital interface at all, some with working Ethernet, some where the only connectivity option is a 24V digital I/O cable to a gateway. I call this The Greenfield Fallacy, and it is the single most predictable failure mode in MES requirements documents written by people who have not personally walked a shopfloor in the last six months.

A Lastenheft that does not explicitly enumerate the brownfield reality produces a vendor proposal that costs the project either 20–40 % in scope creep (when the reality is discovered during implementation) or 40–80 % in time overrun (when the integration approach has to be redesigned mid-project). The discipline that prevents this is a dedicated machine-connectivity appendix to section 2 (organisational & technical environment) that lists every machine in scope with: manufacturer, model, year of manufacture, PLC generation (Simatic S5 / S7 / TIA / Allen-Bradley / Mitsubishi / Omron / proprietary), available digital interfaces (OPC UA / Profinet / S7 / Modbus / digital I/O only / none), network connectivity (Ethernet / WiFi / none), and the target connectivity strategy (native OPC UA / retrofit gateway / digital I/O retrofit). This appendix is typically 3–10 pages for a Mittelstand plant and it prevents more integration surprises than any other section of the document combined.

From thirty-five years of reading and writing MES specifications — and from the particular habit of walking shopfloors before writing anything: the single implementation story I retell most often in requirements workshops is a Mittelstand metal-processing project we took on in the mid-2010s, where the customer had contracted a consultancy to write the Lastenheft before involving any MES vendor. The document was sixty-eight pages, competently structured, with good use cases and a plausible data model. It specified OPC UA as the machine-connectivity standard throughout, and it described the machine park in two paragraphs that said, essentially, "the plant operates modern CNC and press equipment." I met the production manager on-site in the third week of the project, after the contract was signed, and he walked me down the line. The first three machines were a CNC centre from 2019 with full OPC UA support, a press from 2008 with S7-300 that could be read via S7 protocol but had no OPC UA, and a press from 1994 with an S5 controller that had no digital interface of any kind. The machine park was 47 assets. Fourteen were OPC-UA-capable, eighteen were S7-or-similar retrofit targets, and fifteen required digital I/O gateway retrofit because they had no addressable PLC interface. The Lastenheft had specified a timeline and a cost that assumed the full 47 were OPC UA. We re-scoped the project in week four; the customer had to argue internally with their procurement department for another four weeks because the Lastenheft was the binding document and the re-scope looked like a vendor cash-grab; the production manager eventually got on a call with the consultancy that wrote the original document to explain that their "modern CNC and press equipment" description was, in operational terms, a fiction. The project eventually went live eleven months after original plan, at roughly 1.7× original budget, with a final connectivity split that was exactly what I had assessed in week three. What I tell customers in every requirements workshop since: a Lastenheft written without an asset-by-asset machine-connectivity inventory is a Lastenheft written against an imagined plant, not the one you actually operate. The inventory takes two to four days of walking the shopfloor with a clipboard and a photo camera. The alternative is a project that spends the first three months discovering what the specification should have stated in the first place. Of all the improvements I could recommend to a MES requirements specification process, adding the physical walk of the shopfloor before writing the document would rank above every structural, organisational, or template-related recommendation combined. The single most disrespected stage of MES procurement is the one where a trained engineer personally inspects the assets in scope; the single most respected deliverable is the document written without that inspection. This is backwards.

The five requirement antipatterns — patterns to recognise and refuse

Beyond the Greenfield Fallacy, a small set of requirement-level failure modes recurs in almost every requirements specification that has been written by someone without direct implementation experience. Recognising these in review catches most of the damage before contract signing.

VDI 5600 and ISA-95 — external standards that save authoring time

Two external standards are worth structuring the MES Lastenheft against, and the reason is not compliance — it is writing efficiency. Both standards have already enumerated the functional scope of a MES; using them as a checklist saves 20–40 % of the authoring time and reduces the probability of a functional gap to near zero.

VDI 5600 (Fertigungsmanagementsysteme / Manufacturing Execution Systems, VDI-Gesellschaft Produktion und Logistik) is the German MES functional standard. Part 1 defines eleven MES function areas: detailed planning, resource management, operational data collection, performance analysis, quality management, information management, HR management, order management, materials management, data acquisition, and energy management. Structuring section 4 (functional requirements) against these eleven areas produces a document that is exhaustively complete without redundancy. Every German-speaking MES vendor has read VDI 5600 and responds efficiently to documents structured around it.

ISA-95 (ANSI/ISA-95, IEC 62264) is the international MES integration standard. Its principal contribution to requirements specification is scope disambiguation: it defines Level 4 (enterprise business planning, ERP), Level 3 (manufacturing operations management, MES/MOM), Level 2 (SCADA/HMI), and Level 1 (PLC/sensors/actuators). A Lastenheft that explicitly states which ISA-95 level(s) are in scope, and what is delegated to adjacent levels, eliminates the most common scope-boundary argument in MES projects: "is this an MES function or an ERP function?"

Change control — the process that saves the document from itself

The requirements specification is a living document during the project. Requirements change, gaps surface, new information becomes available. Without a formal change-control process, the Lastenheft becomes obsolete within weeks of contract signing and the project reverts to email-driven scope management — which is the most expensive project-management mode ever invented.

FAQ

Who writes the MES requirements specification — customer or vendor?
The customer is responsible for the Lastenheft. It documents their requirements and goals, and the content must come from the customer organisation. Experienced MES vendors can help structure the document and review it, but leaving authoring entirely to the vendor eliminates the basis for comparing multiple offers — which is the principal reason the Lastenheft exists. The vendor then writes the Pflichtenheft (functional specification) as their how-response.

Must a functional specification be complete before contract signing?
Not fully complete, but the critical areas — interface design, data model, OEE definitions, and NFR commitments — should at least be outlined before signing. What remains unresolved after signing becomes expensive to change. A common pragmatic approach: sign a framework contract covering price and scope principles, and require a detailed Pflichtenheft as a deliverable in the first 4–6 weeks of the project, with a formal acceptance gate before full implementation begins.

How detailed does a MES requirements specification need to be?
Detailed enough that (a) two independent vendors produce comparable proposals from it, and (b) acceptance tests can be derived from every requirement. For a mid-scope Mittelstand project, that typically lands at 60–140 pages. Use cases as scenarios are often more useful than pure feature lists. Over-specification costs time without adding value; under-specification costs implementation budget.

What is the MoSCoW discipline?
MoSCoW classifies each requirement as Must (non-negotiable, go-live blocker), Should (important, workaround acceptable), Could (nice to have), or Won't (explicitly out of scope for this phase). A serious Lastenheft has 30–40 % Must, 35–45 % Should, 15–25 % Could, and an explicit Won't list. Documents where more than 50 % is classified Must have failed to prioritise — which vendors read correctly as an absence of real priorities.

What is The Greenfield Fallacy?
The pattern in which a MES requirements specification is written as if the production environment is new, uniform, and fully OPC-UA-capable, while the actual shopfloor contains machines from 30+ years of acquisitions with 3–5 different PLC generations and 20–40 % of assets without any digital interface. Almost universal. Prevented by an asset-by-asset machine-connectivity inventory appendix, written after a physical shopfloor walk.

What is The Feature-List Lastenheft?
The pattern in which requirements are written as a bullet list of 400+ features without operational context — "System shall support OEE", "System shall support SPC". Produces vendor proposals that cannot be distinguished from each other. Prevented by structuring requirements around 15–30 use cases, from which functional requirements are derived as acceptance criteria.

What is The Unmeasurable Requirement?
A requirement that contains adjectives without quantification — "intuitive", "user-friendly", "modern", "fast". Cannot be converted to a test case, which means it cannot be verified at acceptance, which means it cannot be enforced. Every such requirement must either be quantified (response time, click-count, error rate) or deleted.

Should the Lastenheft reference VDI 5600 and ISA-95?
Yes. VDI 5600 provides an exhaustive functional checklist that saves authoring time and reduces the probability of a functional gap. ISA-95 disambiguates scope between ERP (Level 4), MES (Level 3), SCADA (Level 2), and PLC (Level 1), preventing the most common scope-boundary argument in MES projects. Both are broadly recognised by German-speaking and international MES vendors; structuring the document against them reduces vendor interpretation effort.

How does the Lastenheft relate to the MES RFP?
The Lastenheft is typically the central technical annex to the MES RFP. The RFP is the commercial and procurement wrapper (procurement instrument, evaluation criteria, timeline, commercial terms); the Lastenheft is the technical content against which vendors respond. Separating them cleanly allows procurement to own the RFP and operations to own the Lastenheft, which matches the natural responsibility split in most organisations.

What is the Brownfield Connectivity Inventory?
A dedicated appendix to the environment section that enumerates every machine in scope, asset-by-asset, with manufacturer, model, year of manufacture, PLC generation, available digital interfaces, network connectivity, and target connectivity strategy. Takes 2–4 days of shopfloor walking for a typical Mittelstand plant. Prevents the single largest category of MES integration surprise. I have not seen a project over-budget when this appendix was done properly; I have seen dozens over-budget when it was skipped.

What about change control after contract signing?
A formal change-control process is non-optional for MES projects. Requirements change, gaps surface, new information arrives. Without formal change control, the Lastenheft becomes obsolete within weeks. Minimum elements: structured change-request template, named approval board, three-class impact classification, versioning of the requirements specification, and traceability from changes to affected test cases.

Related: MES: definition, functions & benefits · MES software compared · MES RFP · OEE · OEE software · MESA-11 · Composable MES · Downtime reason catalog · Alarm management · Industrial data historian · Digital shift log · Shop floor control · Recipe management · Change control · E2E traceability · Predictive quality · Schedule adherence · On-Time Delivery · Process documentation · A3 problem solving · MDE · BDE · Production metrics · Production control · Production planning · Alarms · Process data · For COOs & plant managers · For production managers. External references: VDI 5600 (German MES functional standard) · ISA-95 / IEC 62264 (international MES integration standard) · ISO/IEC/IEEE 29148:2018 (Requirements engineering) · IREB (International Requirements Engineering Board) · Boehm, B. (1981), Software Engineering Economics — foundational cost-of-change-by-phase curve.

About the author

Martin Brandel

MES Consultant and Project Manager at SYMESTIC. Dipl.-Ing. Nachrichtentechnik. 35+ years of industrial automation and MES implementation. Automation engineer at Ing. Büro Jürgen Albert (1991–1995) programming warehouse management, material-flow control, and plant control with Simatic S5 and COROS visualisation. Automation engineer at Hermos AG (1995–2000) leading commissioning of conveyor systems, process technology, and paint lines on major projects in Eastern Europe and China. Joined SYMESTIC (then ODEVIS GmbH) in 2000; Head of Automation Engineering (2000–2018) with responsibility for the software standard for process plants in the beverage and wood industries, Simatic S5 to S7/TIA retrofit programmes, CE conformity assessments, and the foundations of machine connectivity that underpin today's SYMESTIC Cloud MES platform. Since 2019 MES Consultant and Project Manager: full project ownership from first customer enquiry through assessment, requirements specification, connectivity strategy, data acquisition setup, KPI configuration, training, and go-live. Particular expertise in brownfield machine-connectivity assessment — walking shopfloors, inspecting PLC generations asset-by-asset, and producing connectivity inventories that prevent the integration surprises that kill MES projects. Expertise: MDE, BDE, machine connectivity, PLC programming (Simatic S5/S7/TIA Portal), retrofit, OPC UA, IoT gateway integration, brownfield connectivity, process control systems, material flow control, MES project management, process engineering, CE conformity. · LinkedIn