Requirements, Specification and Project Stages
The functional specification, the I/O list, project stages and effort, change control, FAT and SAT, and what makes projects late.
Writing the specification
Start with what the machine must do, in words the customer, the electrical designer and the programmer all understand. Two documents are usually involved: the user requirements (what the customer needs: output, quality, operating modes, environment, standards) and the functional description (how the system will do it: the sequence, the interlocks, the faults and the displays). The second is checked against the first.
| Section | What it contains |
|---|---|
| Purpose and scope | What the machine does and what is outside the job (who supplies the conveyor, the air, the network) |
| Process and throughput | Product, cycle time, rate, batch size, changeover, the sequence of steps |
| Operating modes | Automatic, manual, set-up, maintenance, and how the machine moves between them |
| Faults and recovery | What must be detected, what the machine does, what the operator does; what happens after a power loss |
| Interfaces | To the line, the plant network, the MES, other machines, operators and maintenance staff |
| Environment and standards | Temperature, dust, washdown, altitude, voltages, the standards, markings and certificates required |
| Safety | The risk assessment and the protective measures chosen (see Machine Safety Systems) |
| Documentation and training | What is delivered at handover (see Documentation, Handover and Lifecycle) |
| Acceptance criteria | Exactly how each requirement will be shown to be met |
Worked example: a requirement that can be tested
- Poor: “The machine shall be fast and reliable.” There is no way to say whether it is.
- Good: “At least 45 parts per minute, with a stop rate below 2 per hour over a 4-hour run, measured at the SAT.” It has a number, a condition and a place where it is measured.
- In a specification of 42 requirements, a review finds 6 that cannot be tested as written (14 %). Each one is a future argument at acceptance: rewrite it now, with a number and a test.
- Write each requirement as a sentence with “shall”, give it a number, and link it to the test that shows it is met: a traceability table is the best tool against a disputed acceptance.
The I/O list and counting
Then list every signal. The I/O list drives the controller and card selection, the panel size, the cable count, the programming and the testing, and it must match the schematics, the program and the HMI tag for tag.
| Tag | Description | Type | Signal | Range / notes |
|---|---|---|---|---|
PB_Start | Start button | Digital input | 24 V DC | NO contact, panel door |
PB_EStop_OK | E-stop healthy feedback | Digital input | 24 V DC | From the safety relay, not a safety function |
PT_101 | Line pressure | Analog input | 4–20 mA | 0–10 bar, loop powered |
TT_201 | Oven temperature | Analog input | Pt100, 3-wire | 0–200 °C |
M_301_Run | Conveyor motor start | Digital output | 24 V DC | To the VFD run input |
XV_401 | Pneumatic valve | Digital output | 24 V DC | 1.5 W solenoid |
Worked example: counting and costing the I/O
| Signal type | Needed | With 20 % spare | Card size | Cards | Spare points |
|---|---|---|---|---|---|
| Digital inputs (24 V DC) | 64 | 77 | 16 per card | 5 cards | 16 spare |
| Digital outputs (24 V DC) | 40 | 48 | 16 per card | 3 cards | 8 spare |
| Analog inputs (4–20 mA) | 16 | 19 | 8 per card | 3 cards | 8 spare |
| Analog outputs (4–20 mA) | 4 | 5 | 4 per card | 2 cards | 4 spare |
| RTD (Pt100) inputs | 8 | 10 | 4 per card | 3 cards | 4 spare |
- 132 points across 16 cards. Rounding up to whole cards usually gives more than the 20 % spare asked for: check each row.
- Effort. At about 7 hours per point for design, wiring, programming and testing (a typical figure; use your own history), plus 160 hours of fixed work (specification, project management, documentation): 132 × 7 + 160 = 1 084 hours, or $92 140 at $85 an hour.
- Name signals consistently (ISA-style tags such as PT-101, or the project’s own convention) and use the same name in the schematic, the I/O list, the PLC program and the HMI.
- Agree responsibilities in writing: who supplies the field devices, who wires them, who writes the program and who owns the network and the safety design.
Stages and effort
| Stage | Main outputs |
|---|---|
| Specify | Functional description, throughput and cycle time, environment, standards, risk assessment, I/O list, budget and schedule |
| Design | Electrical schematics, panel layout, network and architecture drawings, bill of materials, software structure |
| Build | Panel assembly and wiring, programming of the PLC, HMI and drives, simulation and testing in the workshop |
| FAT | Factory acceptance test: demonstrate every function against the specification, with the customer if required |
| Install and commission | Mechanical and electrical installation, I/O checks, loop checks, site acceptance test (SAT), tuning |
| Handover | As-built drawings, program backups, manuals, spare parts list, operator and maintenance training |
Worked example: spreading 1 084 hours
| Stage | Share (typical) | Hours |
|---|---|---|
| Specify | 10 % | 108 h |
| Design (schematics, layout) | 20 % | 217 h |
| Panel build and wiring | 15 % | 163 h |
| Software (PLC, HMI, drives) | 25 % | 271 h |
| FAT | 5 % | 54 h |
| Install and commission | 20 % | 217 h |
| Handover and training | 5 % | 54 h |
Software and commissioning together take about half the effort. The early stages are cheap but decide the rest: 30 % of the hours go into specifying and designing, and the cost of a mistake found later grows steeply (see the figure below).
The schedule and the critical path
A schedule is the tasks, their durations and what each depends on. The critical path is the chain of tasks with no slack: a day lost on it is a day lost on the project. Everything else has float.
Worked example: an eight-task project
| Task | Duration | Earliest start | Earliest finish | Float | |
|---|---|---|---|---|---|
| A Specification and risk assessment | 10 d | 0 | 10 | 0 d | critical |
| B Electrical and layout design | 20 d | 10 | 30 | 0 d | critical |
| C Order long-lead parts (drives, enclosure) | 30 d | 30 | 60 | 0 d | critical |
| D Panel build and wiring | 15 d | 60 | 75 | 0 d | critical |
| E PLC, HMI and drive programming | 25 d | 30 | 55 | 20 d | |
| F FAT | 5 d | 75 | 80 | 0 d | critical |
| G Ship and install | 10 d | 80 | 90 | 0 d | critical |
| H Commission and SAT | 10 d | 90 | 100 | 0 d | critical |
- The project takes 100 days. The critical path is A → B → C → D → F → G → H: the long-lead order and the panel build, not the software.
- The software (E) has 20 days of float: it can slip that long without moving the end date, but a late start squeezes the FAT.
- Shortening the project means shortening the critical path: ordering the long-lead items earlier, buying a drive from stock, or building the panel in parallel with a second crew. Speeding up the software would change nothing.
- Re-check the path as the project moves: a delay on a non-critical task can use up its float and make it critical.
Change control
Changes are normal; uncontrolled changes are the problem. Agree a procedure at the start: every change is written down, its effect on cost, time and safety is assessed, and it is approved by the customer and the project manager before work starts.
Worked example: the cost of a late change
Adding a sensor and its wiring costs $400 if it is in the specification. Found at the design stage it costs about 3 times as much; at the FAT 20 times; at commissioning 50 times: $20 000 instead of $400 (the multipliers are a typical shape, not a law: panels get re-opened, drawings re-issued and tests repeated). This is the best argument for spending time on the specification and the review.
- Freeze the I/O list and the architecture at a named date, and treat later changes as variations.
- Review the design with the people who will test, install and maintain it: they find problems the designers cannot see.
- Record decisions and their reasons (a short log); it settles arguments months later.
FAT, SAT and the acceptance criteria
| Test | Where | Purpose |
|---|---|---|
| FAT (factory acceptance test) | The supplier’s workshop | Show that the equipment meets the specification before it ships, with simulated or real inputs and outputs, so that faults are fixed where tools and staff are at hand |
| SAT (site acceptance test) | The customer’s site | Repeat the important checks with the real wiring, utilities, product and operators |
| Run-in or trial | On site | Run for an agreed time or number of cycles to prove the rate, quality and reliability |
The criteria must be agreed before the build; the details of the tests are in Testing, Commissioning and Acceptance. Link payment to them.
Worked example: payment milestones
| Milestone | Share of the price |
|---|---|
| Order placed | 30 % |
| Design approved | 20 % |
| FAT passed | 30 % |
| SAT passed | 15 % |
| End of warranty period | 5 % |
| Total | 100 % |
Holding back 20 % until the SAT and the end of the warranty gives the supplier a reason to finish properly, and the customer a way to have defects fixed. Tie each payment to an event that can be shown, not to a date.
Responsibilities, contracts and risks
| Question | Who should answer it, in writing |
|---|---|
| Who supplies and installs the field devices, cables, air, power and network? | Customer and integrator, split by item |
| Who writes and owns the PLC, HMI and drive programs and the source files? | Agreed in the contract (the customer usually needs the source and the passwords) |
| Who carries out and signs the risk assessment, and who validates the safety functions? | The machine builder (see Machine Safety Systems) |
| Who is responsible for the network design, the IP addresses and the connection to the plant network? | Customer IT or controls, with the integrator (see Industrial Communication) |
| What is the warranty, the support period and the response time? | The contract |
Worked example: a simple risk register
| Risk | Probability | Delay if it happens (days) | Expected delay (days) |
|---|---|---|---|
| Late delivery of the drives | 40 % | 12 | 4.8 |
| Scope change by the customer | 50 % | 15 | 7.5 |
| Site not ready for installation | 30 % | 10 | 3.0 |
| Key engineer unavailable | 20 % | 20 | 4.0 |
| Total expected | 19.3 days |
On the 100-day schedule that is 19 %, so a contingency of 10 to 20 % is not padding but arithmetic. Put it at the end, name its owner, and use it deliberately.
What makes projects late
| Cause | Prevention |
|---|---|
| A vague or untestable specification | Numbers and tests for every requirement |
| I/O and architecture changing late | Freeze dates and change control |
| Long-lead parts ordered late | Order drives, enclosures and special devices at design approval (see the critical path) |
| Customer-supplied items late or wrong | List them, with dates and responsibilities |
| Software left until the panel is built | Program and simulate in parallel; test against a simulator at the FAT |
| Site not ready (no power, no air, no floor) | A site checklist signed before shipping |
| Safety discovered at the end | Risk assessment at the start (see Machine Safety Systems) |
| No time for documentation and training | Plan them as tasks with owners (see Documentation, Handover and Lifecycle) |
Related
- System Integration: the overview of this guide.
- System Architecture and Component Selection: turning the specification into an architecture.
- Testing, Commissioning and Acceptance: the tests that show the specification is met.
- Documentation, Handover and Lifecycle: what is delivered at the end.
FAQ
How much spare I/O should I plan for?
About 15 to 20 % spare points, plus spare panel space, power supply capacity and wire duct. Round up to whole cards and check the result per type.
What goes into a functional description?
The sequence, the operating modes, the interlocks, every fault and its response, the interfaces and the displays, written so that the customer and the programmer both agree on what the machine will do.
Why test at the factory as well as on site?
Faults are cheaper to fix at the factory, where tools, spares and staff are at hand and the line is not stopped. The SAT then only has to prove what depends on the site.
Who owns the PLC program?
It should be written into the contract. The customer normally needs the source files, the passwords and the right to modify them for maintenance.
References
- ISO/IEC/IEEE 29148, Requirements engineering; IEC 61131-3 (programming) and IEC 61512/ISA-88 (batch and recipe terminology).
- PMI, A Guide to the Project Management Body of Knowledge (critical path, risk and change control).
- IEC 60204-1 and ISO 12100 for the electrical and safety requirements that the specification must cite.
Last reviewed: October 2026. Hours, rates and delays are typical and illustrative: use your own history.