MES Requirements Specification

In MES projects, two documents serve fundamentally different purposes and are frequently confused.

The requirements specification (German: Lastenheft) documents what is needed: goals, requirements, priorities, and acceptance criteria from the customer's perspective. The functional specification (German: Pflichtenheft) documents how the vendor will deliver: architecture, data flows, interfaces, implementation, and operations.

The key distinction: the requirements specification makes vendors comparable. The functional specification makes delivery verifiable.

Structure: MES Requirements Specification

A complete requirements specification for a MES project covers nine areas.

Goals and scope clarifies why a MES is needed, which plants and lines are in scope, and what is explicitly excluded.

Processes as use cases describes short scenarios rather than feature lists: starting an order, changeover, production, fault handling, quality, shift close.

Requirements are structured as must, should, and may – with acceptance criteria formulated in testable terms.

Data and master data defines which objects must exist: order, line, machine, product, material, batch, inspections – and which relationships are mandatory.

Interfaces describes at a functional level which data flows between ERP, QA, LIMS, SCADA, PLC, and BI – with frequency and ownership.

Roles and traceability establishes role matrix, approvals, change reasons, and audit trail requirements.

Reporting and KPIs defines OEE definitions, standard reports, drill-downs, and BI connectivity.

Non-functional and operations covers performance, availability, offline capability, security, backup, and update process.

Project and acceptance contains pilot and rollout plan, training, acceptance tests, and documentation scope.

Structure: MES Functional Specification

The functional specification is the vendor's response to the requirements document. It contains target architecture with components, deployments, data flows, and source-of-truth definition; implementation per use case with screens, workflows, rules, and error scenarios; detailed data model with IDs, versions, history, and time logic; interface design with mapping, triggers, error handling, and monitoring; role and authorization concept; KPI logic and reporting; and test, acceptance, and operations concept.

The 6 Areas That Must Be Specified Precisely

Interfaces are defined per data domain: source, target, direction, timing, and error cases. ERP to MES for products, orders, and confirmations. PLC/SCADA to MES for states, counters, and alarms. QA/LIMS to MES for inspection plans, results, and releases. And BI for export, historization, and access rights.

Data model and master data – projects fail here when specifications are vague. Mandatory objects, unique IDs, versioning for recipes and work plans, units, and time logic must be decided early.

OEE definitions must be fixed in writing: formula, planned time, downtime logic, micro-stops, planned stoppages, and fault catalog with mandatory logic. Teams that leave OEE undefined spend months debating numbers instead of causes.

Traceability clarifies granularity – order, lot, batch, or serial number – and which events must be traceable forwards and backwards: material batch, order, product, inspections.

Roles, approvals, and traceability defines who may do what, in which sequence, and with which blocking rules – and how changes to master data, categories, and recipes are documented.

Reporting is not "nice dashboard" but definition plus drill-down: standard KPIs with a single unified definition, drill-down paths from plant through line to individual event, export data model, and historization.

FAQ

Who writes the requirements specification – customer or vendor? The requirements specification is the customer's responsibility – it documents their own requirements and goals. In practice, experienced MES vendors help structure it, but the content must come from the customer. Leaving it entirely to the vendor eliminates the basis for comparing multiple offers.

Must a functional specification be in place before contract signing? Not necessarily complete, but the critical areas – interface design, data model, OEE definitions – should at least be outlined before signing. What remains unresolved after contract signing becomes expensive.

How detailed does a MES requirements specification need to be? Detailed enough that two different vendors can produce comparable offers from it – and that acceptance tests can be derived from it. Use cases as scenarios are often more useful than pure feature lists. Over-specification costs time without adding value.

What happens when requirements and functional specification drift apart during the project? This is the most common cause of scope creep, change orders, and project delays. A formal change control process that documents and evaluates requirement changes protects both sides.