Writing a technical specification: how open to make it, its sections, the parts of a good requirement, and the maintenance requirements usually missed
How to write a technical specification for plant and equipment: functional, performance and prescriptive specifications and where design risk sits, the sections of a specification, the parts of a good requirement with its verification and acceptance criterion, the words that make requirements untestable, and the maintenance and handover requirements most often missed. With a drawing of one requirement written in full.
Key takeaways
- A technical specification states what an item must do, achieve or be, measurably, so a supplier can design and price it and the owner can prove it was delivered.
- Performance specifications, which say what must be achieved rather than how to build it, are the usual choice for equipment. Prescriptive specifications move the risk that the design works onto the owner.
- Every requirement should be one numbered shall statement, with its conditions, how it will be verified, what counts as a pass, and where it came from.
- Words such as adequate, as required, etc and best practice make a requirement impossible to test. Replace each with a value, a condition, a list or a named standard.
- Maintenance and handover data belong in the specification as requirements. Access, spares, manuals and data for the CMMS are much cheaper to specify than to chase after delivery.
A new pump arrives on site, is installed, and cannot deliver the flow the plant needs. The specification asked for a pump suitable for the duty, of adequate capacity, built to best practice. The supplier met every word of it. The duty point, the slurry properties and the test that would prove the flow were in a design report the supplier never saw, and nothing in the contract required them.
This guide covers writing a technical specification for plant and equipment: how open a specification should be, its sections, the parts of a good requirement, the words that make requirements untestable, and the maintenance and handover requirements that are usually missed. It sits beside the guides to engineering study phases, where specifications are written, and factory and site acceptance testing, where they are proved. The standards named are reference points.
How open, and one good requirement
The first decision is how open the specification should be. A functional specification says what the item is for. A performance specification says what it must achieve, measurably, under stated conditions. A prescriptive specification says how it must be built. The more prescriptive the specification, the more the owner carries the risk that the design will do the job.
Whatever the kind, the specification is made of requirements, and the quality of each requirement decides whether the item can be accepted against it. A good requirement is numbered, says one thing with shall, states its conditions, and says how it will be verified and what counts as a pass.
If the requirement does not say how it will be tested, it will be argued about at acceptance.
Functional, performance or prescriptive
Most equipment specifications are performance specifications with prescriptive requirements where the owner has good reason: a site standard for motors, a make of instrument the site already spares, a material proven in the duty. Each prescriptive requirement should have that reason written beside it, because each one narrows the field and moves risk.
| Kind | What it says | Example | Risk and freedom |
|---|---|---|---|
| Functional | What the item must do, in the owner's terms | A conveyor to move crushed ore from the crusher to the stockpile, around the clock | Most design freedom, most design risk with the supplier |
| Performance | What the item must achieve, measurably, and the conditions it works in | 2,500 t/h of ore at 1.8 t/m³, 24 hours a day, at site ambient conditions | The usual choice for equipment. Suppliers compete on how |
| Prescriptive | How the item must be built: materials, makes, dimensions, methods | A 1,200 mm steel cord belt, with a named make of drive and idler | Least design freedom. The owner carries the risk that the design works |
The sections of a specification
A specification is easier to write, price and check when the same things are always in the same place. The scope and battery limits come first, because every other section depends on what is and is not supplied. Site and operating conditions are written once, so requirements can refer to them instead of repeating them.
| Section | What it covers | Why it matters |
|---|---|---|
| Scope | What is supplied, what is not, and where the boundaries are | Battery limits and interfaces, drawn as well as written |
| Site and operating conditions | Climate, altitude, power supply, duty, materials handled | One place for conditions every requirement depends on |
| Requirements | Function, performance, design, materials, safety, maintainability | Numbered, one requirement each, with how each is verified |
| Standards | The standards that apply, with editions, and which takes precedence | Named once, not scattered through the text |
| Documents and data | Drawings, manuals, spares lists, data for the CMMS, and when each is due | Handover data is a requirement like any other |
| Inspection and testing | Hold points, factory and site acceptance tests, and who witnesses them | Ties each requirement to the test that proves it |
| Deviations | How the supplier proposes a departure and how it is approved | Departures written down, never assumed |
Writing each requirement
Each requirement is one statement that can be checked. ISO/IEC/IEEE 29148 lists the characteristics of a good requirement: necessary, appropriate, unambiguous, complete, singular, feasible, verifiable, correct and conforming. Four verification methods cover almost everything: inspection, analysis, demonstration and test. Choosing the method when the requirement is written is what makes the acceptance test plan possible.
| Part | What it holds | Example |
|---|---|---|
| Identifier | A unique number, so the requirement can be referred to, traced and tested | REQ-031 |
| Statement | One requirement, using shall, stating what and how much | The conveyor shall convey 2,500 t/h of ore |
| Conditions | Under which conditions it applies | At a bulk density of 1.8 t/m³ and design belt speed |
| Verification | How compliance will be shown: inspection, analysis, demonstration or test | Test: a performance test at commissioning |
| Acceptance criterion | What result counts as a pass | Average of 2,500 t/h or more over four hours of design feed |
| Source and rationale | Where it came from and why it exists | Design basis, section 3, sized for the plant's nameplate rate |
Words to take out
Most untestable requirements come from a short list of words that feel precise and are not. A read through for them before issue removes most of the arguments at acceptance.
| Word or phrase | The problem | Write instead |
|---|---|---|
| Adequate, sufficient, suitable | Says nothing that can be tested | State the value: capacity, rating or margin |
| As required, where necessary | Leaves the decision to whoever reads it | Say when it is required |
| Etc, and so on, including but not limited to | An open list cannot be checked for completeness | List what is required |
| And/or | Two requirements that disagree on whether both apply | Write each requirement separately |
| Minimise, maximise, as low as possible | No point at which it is met | State the limit that must be met |
| Best practice, industry standard, good engineering practice | Means different things to each reader | Name the standard and clause |
| Should, may, will | Not a requirement, or ambiguous | Use shall for requirements, and say plainly what is for information |
Maintenance and handover requirements
The requirements most often missed are the ones the maintenance team will live with for decades. Access for inspection and removal, lifting points, isolation points, spares commonality with the site's existing equipment, and condition monitoring access are design requirements, and the maintainability review is too late to add them if the specification did not ask.
Handover data is the other gap. Manuals, drawings, a spares list with part numbers, recommended maintenance tasks, and the equipment data the asset register and CMMS need, tagged to the site's tagging convention, should each be a requirement with a format and a due date. Chasing them after the final payment rarely works.
Where specifications go wrong
- Copied from the last project, with requirements that no longer apply and conditions from another site.
- Requirements that cannot be tested, because they use adequate, suitable or best practice.
- The duty and conditions in a design report rather than in the specification.
- Standards listed without editions or an order of precedence, so they conflict.
- Prescriptive requirements with no reason recorded, narrowing the field for nothing.
- No requirements for handover data, spares or maintenance access.
- Requirements with no verification method, so the acceptance test is designed after delivery.
Common questions
What is a technical specification?
A technical specification is the document that states the requirements an item, system or service must meet: what it must do, how well, under which conditions, and to which standards, with how each requirement will be verified. It is written by or for the owner, issued with the tender or purchase order, and becomes part of the contract, so the supplier designs and prices to it and the owner accepts the item against it.
How do you write a technical specification?
Start from the design basis and the owner's needs, decide how open the specification should be, and set out the scope and battery limits first. Then write the site and operating conditions once, and each requirement as a numbered shall statement with its conditions, verification method and acceptance criterion. Name the standards that apply and their order of precedence, list the documents and data required, and set the inspection and test plan. Have someone outside the team read it as a supplier would.
What is the difference between a performance and a prescriptive specification?
A performance specification says what the item must achieve, such as capacity, availability or efficiency under stated conditions, and leaves the supplier to decide how. A prescriptive specification says how the item must be built, with materials, makes, dimensions and methods. Performance specifications let suppliers compete on design and leave design risk with them. Prescriptive ones give the owner control and move the risk that the design meets the need onto the owner.
What should be in a technical specification template?
Sections for the scope and battery limits, site and operating conditions, the requirements grouped by function, performance, design, materials, safety and maintainability, the standards that apply, the documents and data to be supplied, inspection and testing, and how deviations are proposed and approved. A requirements table with an identifier, statement, verification method and acceptance criterion for each requirement keeps them testable.
What makes a good requirement?
It states one thing, uses shall, is measurable, and says under which conditions it applies. It can be verified by inspection, analysis, demonstration or test, with a stated pass criterion. It is necessary, feasible and consistent with the other requirements, and traceable to where it came from. ISO/IEC/IEEE 29148 sets out the characteristics of good requirements in general, and they apply as much to plant as to software.
Key terms
Plain-language definitions from our glossary for the concepts this article leans on.
Standards and further reading
- ISO/IEC/IEEE 29148:2018 Systems and software engineering, life cycle processes, requirements engineering (ISO / IEC / IEEE)
- ISO/IEC/IEEE 15288:2023 Systems and software engineering, system life cycle processes (ISO / IEC / IEEE)
- IEC 62381:2024 Automation systems in the process industry: factory acceptance test (FAT), site acceptance test (SAT) and site integration test (SIT) (IEC)
Related case studies and tools
- Operational readiness for a new plant asset (case study)
- Structural design and certification of transport frames (case study)
Related reading
Working through something like this?
See how we approach these initiatives, or tell us what you are dealing with.