Turn shop-floor problems into MES requirements
Translate production problems into observable MES behavior, with owners, priorities and acceptance tests that expose ambiguity before procurement.
Write MES requirements as observable production behavior with an owner and acceptance test. Start from a specific problem on the floor; a copied list of software features does not explain what your plant needs to do differently.
Observe work before collecting feature requests
Follow an order through release, preparation, execution, inspection and completion. Note where people wait, re-enter information, consult an unofficial document or resolve conflicting instructions. Ask operators what happens when the normal sequence fails. Record the problem without assuming software is the cause or the remedy.
Separate a process policy from its current implementation. A requirement to use an approved instruction is different from a preference to store it in a particular application. Make the decision objective visible so alternatives can be evaluated. If the problem is inconsistent master data, an MES screen alone may not solve it; the data ownership process needs attention too.
Use a scenario-based requirement format
A practical requirement states the trigger, actor, preconditions, expected action, exception and evidence. For instance, when an operator scans a material lot for an operation, the system should check its permitted status and record the accepted consumption. A rejected scan needs an intelligible resolution path, not only an error code.
| Field | Example question |
|---|---|
| Actor | Who needs to perform or approve the action? |
| Trigger | What starts the workflow? |
| Input | Which record and version are used? |
| Expected behavior | What must the configured system do? |
| Exception | What happens if the input is invalid? |
| Evidence | How will the team verify the result? |
Use stable requirement identifiers so tests and defects can refer to the same statement throughout procurement and implementation.
Prioritize consequences rather than enthusiasm
Distinguish mandatory controls from operational improvements and convenience preferences. Ask what happens if a requirement is absent and whether an approved alternative exists. A visually appealing dashboard may be helpful, while a required material check can be a gate. Do not collapse those differences into a single average score.
Record disagreement instead of forcing a premature consensus. Quality may need a record that production does not currently capture; IT may identify an unsupported identity dependency. Assign an owner to resolve the conflict. If a requirement is mandatory because of a regulatory or contractual obligation, retain the actual basis and have qualified personnel confirm applicability. Do not label preferences as legal requirements.
Add nonfunctional operating requirements
Specify response, availability, capacity and recovery expectations in the context of work. Rather than requesting a vague fast system, describe the operation that cannot wait and the acceptable behavior under the plant’s chosen constraints. Ask for evidence under representative load, device and network conditions.
Include accessibility, authentication, workstation environment, support, export and change management. A workflow can be logically correct but unusable with gloves, a shared terminal or a poor wireless connection. Avoid prescribing arbitrary thresholds without a process reason. Where the plant has not established a target, make that an open decision with an owner rather than filling the gap with an invented industry norm.
Keep traceability between requirement and proof
Create a matrix linking each mandatory requirement to configuration, test case, result and unresolved defect. Keep the test environment and version identifiable. A passing test on an early prototype may not establish the behavior of the final production configuration. Retest after changes that affect the requirement.
Use evidence appropriate to the risk. A screenshot can show a displayed instruction, but it cannot alone prove that an inventory transaction posted exactly once. That may require reconciled records on both sides of an interface. Define evidence before execution so the team does not discover after the pilot that the information needed for approval was never captured.
Control scope changes transparently
New requirements will appear as people see the workflow. Evaluate their reason, impact, cost and urgency rather than treating every addition as either essential or forbidden. A newly discovered safety or quality need deserves a different decision from a preference for another report layout.
Maintain a decision log that shows what changed, who approved it and which tests must be updated. Rebaseline the project when the scope materially changes. Do not continue reporting the original budget and timetable as if the implementation were unchanged. A controlled requirement set allows the sponsor to make an informed tradeoff between additional capability and the work required to prove it.
Take this to the working meeting
Choose one requirement and ask three people to interpret it independently: an operator, an implementation specialist and the person who will approve acceptance. Have them describe the expected result for an exception as well as normal work. Differences expose ambiguity early. Rewrite the statement and test until the intended behavior is shared, while preserving the decision that changed the requirement.
FAQ
Should requirements name a vendor feature?
Only when necessary to explain an existing constraint. Describe the required behavior so suppliers can propose an appropriate implementation.
Who owns requirements?
Business process owners should own the required behavior, with IT, OT, quality and security responsible for their constraints and evidence.
Can priorities change after the pilot?
Yes, when new evidence justifies it. Record the decision and its effect on scope, tests, cost and approval.
Continue your decision
- Design an MES pilot that earns a rollout
- MES ROI: separate cash benefits from saved time
- OEE for an MES pilot: fix the definitions first
- Operator adoption starts at the workstation
Use the pilot readiness to document your own inputs. Compare operating models on the comparison page.
Sources and scope
- NIST Smart Manufacturing — Official research context for manufacturing systems. The decision worksheets in this guide are editorial recommendations, not NIST requirements.
Examples are hypothetical and are not measured customer results, supplier quotations, or evidence of professional review. Prepared on October 30, 2026; confirm current requirements with the relevant official body and your responsible specialists.
