Machine Design #43: Automation Requirements — How to Write Them So FAT Does Not Become a Debate
Specifications often contain a sentence like:
The machine must run stably, change models quickly, and be easy to maintain.
The builder reads one meaning into that sentence. The machine owner imagines another. At FAT, both sides start asking:
- Stable for how long?
- Which models are in scope?
- From which event is “fast” measured?
- Who performs the changeover?
- How is “easy to maintain” demonstrated?
This is not only an acceptance-meeting problem. It is a requirement defect that appeared at the beginning of the project.
A stronger chain is:
Stakeholder need → operating context → requirement → acceptance criterion → verification method/gate → evidence → baseline/change
This article explains how to write automation-machine requirements that are clear, measurable, and traceable. The framework does not replace a contract, an applicable industry standard, the machinery risk assessment, or project-specific safety requirements.
1. Separate need, requirement, constraint, and design decision
These concepts are often mixed together.
Stakeholder need
A need describes the problem or result a user expects.
Example:
Production needs to switch between models without depending on a programming engineer.
A need clarifies the objective, but it is not yet sufficient for acceptance.
Requirement
A requirement is an obligation the system must satisfy, with enough scope and conditions for verification.
For example:
In the specified state and operating conditions, the machine shall allow an authorized user to perform a changeover between the in-scope models according to the referenced acceptance criteria.
Constraint
A constraint limits the solution:
- Installation dimensions.
- Available utilities.
- Applicable standards.
- An approved component family.
- A mandatory interface.
- Environmental or security limits.
A constraint should have a source and rationale. Not every preference is a constraint.
Design decision
A design decision is how the engineering team chooses to satisfy the requirement:
- A common base with change parts.
- A servo or pneumatic actuator.
- A QR code or recipe selector.
- One sensor or two sensors.
If a design decision is written as a requirement too early, the solution space is locked before trade-offs are reviewed.
2. Requirements state WHAT; design decides HOW
Weak requirement:
The machine shall use a servo to reach position quickly.
This already selects a solution, but it does not say which position, how quickly, for which load or model, what accuracy and repeatability are required, or how the result will be verified.
A better requirement starts with the outcome:
The mechanism shall reach the in-scope positions under the defined load conditions and meet the referenced limits for time, accuracy, and repeatability.
The design team can then compare a servo, cylinder, cam, or another concept. Sometimes HOW truly is a constraint, such as a customer-approved platform needed for spare parts, skills, or cybersecurity. Record it as an approved constraint instead of pretending it is a performance requirement.
3. Each requirement should contain one clear obligation
Conjunctions can hide several obligations:
The machine shall feed parts automatically, verify orientation, reject nonconforming parts, record data, and warn when parts are low.
If four parts pass and one fails, what is the requirement status? Split it into manageable behaviors:
- Feed the part.
- Confirm orientation.
- Route a nonconforming part.
- Record the data.
- Warn about a low-feed condition.
Splitting does not mean creating thousands of fragments. Aim for one clear subject, one primary obligation, a related set of conditions, and a verification route that can be managed.
4. Write operating context before numbers
A number without context is easy to misread. For example:
Cycle time ≤ X seconds.
Define the model, material condition, start and end events, operator time, upstream/downstream waiting, machine mode, utilities, environment, and retry or reject handling.
Accuracy also needs an explicit quantity, datum, measurement condition, tool and method, sample or duration plan, and acceptance rule. Not every detail must fit in one sentence. A requirement may reference a controlled definition, data sheet, or verification specification. The context must belong to the managed baseline, not be scattered through chat messages.
5. Replace ambiguous words
Words that often create disputes include fast, stable, accurate, user-friendly, easy to maintain, robust, low-defect, fully automatic, compatible, compliant, when needed, and reasonable.
These words are not forbidden. Convert them into observable characteristics.
“Easy to maintain”
Define access to wear parts, replacement time and tools, whether datum is retained after replacement, restoration and verification steps, diagnostic information, and spare-part identification.
“Runs stably”
Define the duration and run profile, model mix, stop classification, alarm and retry rules, output quality, and the agreed availability or throughput definition.
If the meaning is not agreed, do not make it an acceptance criterion yet.
6. Give each requirement an identity and source
Important requirements should have a unique ID, statement, source or owner, rationale when needed, assumptions, priority or applicability, verification method or gate, related requirements, and revision/status.
An ID lets the team trace a need to a design item, a risk or control, a test case, and evidence. Do not use a Word line number or a spreadsheet row position as a permanent identity if sorting can change it.
7. Source and rationale answer different questions
The source identifies who or what created the obligation: a contract, approved user need, applicable standard, risk assessment, interface agreement, or internal platform rule.
The rationale explains why the requirement exists. It helps the team understand intent and assess change, but it must not hide a second requirement.
For example, the requirement may call for confirmation that a change part matches the selected model. Its rationale is to prevent a recipe from running with incompatible hardware. If someone proposes removing the sensor to cut cost, the rationale shows that the risk needs another control; it is not permission to delete the requirement silently.
8. Make assumptions visible and close them
Requirements often work only when an assumption is true: parts are clean, pressure stays in range, upstream sends one part, the operator selects the correct model, or the network remains available.
For every important assumption, record an owner, confirmation method, due date or gate, impact if false, and replacement requirement or design action. An unconfirmed assumption must not quietly become an acceptance criterion.
9. Assign a verification route while writing
Ask: after the machine is built, what evidence will show that this requirement is met?
Common routes are inspection, analysis, demonstration, and test. Gates may include design review, FAT, FIT, SAT, SIT, safety validation, production trial, or field verification.
If no route comes to mind, the requirement may be vague, an aspiration, missing context, infeasible, or mixing several obligations. Not every requirement needs a test, but every important requirement needs a reasonable evidence route.
10. Verification and validation are different
Verification asks whether the product meets the written requirement. Validation asks whether the requirement and solution meet the stakeholder need in the real use context.
For example, verification can show that changeover meets the documented time. Validation asks whether the workflow suits operator capability, layout, and production reality. A requirement may verify as pass and still fail to solve the real need, so stakeholder review must not happen only when FAT is signed.
11. Cover normal, abnormal, and recovery behavior
Specifications often describe the happy sequence: a part arrives, the mechanism clamps, the robot moves, and the part is released. Real machines also face missing or misoriented parts, missing feedback, utility interruption, an operator stop, communication loss, model mismatch, E-stop, and restart.
Requirements should cover behavior when conditions are invalid, the safe or recovery state from the risk assessment, alarm and diagnostics, ownership of retry/reset/restart, and preservation or cancellation of work in progress. If abnormal behavior is decided only during PLC programming, the requirement baseline is incomplete.
12. Interface requirements need both sides to agree
“Machine A connects to Machine B” is not enough. Define the boundary, exchanged data/signals/material/energy, direction and ownership, states and sequence, timing and timeout, error and retry, recovery and resynchronization, version compatibility, and relevant security constraints.
Detailed tags, addresses, and sensitive topology belong in a controlled interface specification, not in a public article. FIT and SIT often expose incomplete interface requirements, but it is better to find the ambiguity before both teams code against different assumptions.
13. Do not write requirements only for cycle and accuracy
A machine that runs for years also needs requirements for maintainability, usability, data, security, and handover.
Maintainability includes access, replaceability, restoration, diagnostics, and wear/spare identification. Usability includes roles, permissions, prompts, feedback, error prevention, and labels. Data requirements define events, timestamps, sources, retention, export, and data quality. Security requirements cover accounts, remote-support boundaries, backup/configuration protection, and logging. Handover requirements cover documentation, training, backup/restore, baseline, and open items.
If these characteristics have no requirement, they become “nice to have” items that disappear when the schedule is tight.
14. Safety requirements must trace to risk assessment
Avoid a generic sentence such as:
The machine shall be safe and achieve PL d.
It does not identify the hazard, safety function, process used to determine the required performance level, operating mode, stop and restart behavior, or validation route.
Safety requirements must be derived from the risk assessment and applicable standards. Do not assign PLr, SIL, or category merely because a previous project used the same value. Requirements, design, and validation records must trace to one another.
15. Turn one vague sentence into a requirement set
Start with:
The machine shall change models quickly, prevent mix-ups, and be easy to operate.
First define the need: trained production operators must change an in-scope model without an engineer and without creating the wrong product.
Then define context: model list, change parts, recipe, tooling, starting and ending machine state, operator role, and utilities.
Split the obligations into model selection, hardware compatibility confirmation, loading the correct recipe revision, preventing start on mismatch, guiding the operator, meeting the agreed changeover time, and recording the event.
Finally attach verification: inspect the logic and interface, demonstrate the workflow, test a mismatch, measure changeover time, and cover both FAT and SAT when the site workflow affects the result. The number must be agreed from the production need and real conditions; it should not be invented for the article.
16. Baseline requirements before starting change
After review, identify the revision, open issues and assumptions, approval authority, traceability status, and verification coverage.
After baseline, a change needs a request, reason, impact assessment for design, software, risk, test, documents, cost, and schedule, approval, updated traceability, and a retest or revalidation route.
If a requirement changes by email but the matrix and test plan do not change, FAT may still test an obsolete baseline.
17. Automation requirement review checklist
- [ ] Is the need and stakeholder clear?
- [ ] Does the requirement state WHAT rather than lock HOW without rationale?
- [ ] Does each line have one primary obligation?
- [ ] Does it have a unique ID and source?
- [ ] Are operating context, mode, model, material, and boundary clear?
- [ ] Have ambiguous words become observable characteristics?
- [ ] Does every assumption have an owner and closure gate?
- [ ] Are acceptance criteria and a verification route defined?
- [ ] Is the requirement feasible and free of contradiction?
- [ ] Is it traceable up to the need and down to design and test?
- [ ] Are normal, abnormal, and recovery behaviors covered?
- [ ] Are interface ownership, timing, error, and recovery clear?
- [ ] Are maintainability, diagnostics, data, security, and handover covered?
- [ ] Does the safety requirement trace to the risk assessment?
- [ ] Are baseline and change processes clear?
Conclusion
FAT should not be the first place where both sides define what “pass” means.
A good requirement has a source and identity, states the required outcome in operating context, avoids locking the solution unless it is a real constraint, carries an acceptance criterion and evidence route, traces to need, design, risk, test, and evidence, and is baselined under change control.
With that chain in place, FAT and SAT become evidence collection. They stop being negotiations about what “fast,” “stable,” or “easy to use” was supposed to mean.
References
- ISO/IEC/IEEE 29148:2018 — Requirements engineering: https://www.iso.org/standard/72089.html
- IEEE — IEEE/ISO/IEC 29148-2018: https://standards.ieee.org/ieee/802.1Q/6937/
- NASA — How to Write a Good Requirement: https://www.nasa.gov/reference/appendix-c-how-to-write-a-good-requirement/
- NASA — Requirements Verification Matrix: https://www.nasa.gov/reference/system-engineering-handbook-appendix/
- IEC 62381:2024 — FAT, FIT, SAT and SIT: https://webstore.iec.ch/en/publication/67572
View all MINATA technical articles