Requirements Management in Technical Projects

TL;DR

The effect

Deliveries that actually match the order, minimised project costs and full traceability.

The challenge

Technical requirements are often forgotten or misinterpreted between procurement and commissioning, leading to costly changes.

The solution

A systematic process for requirements management that traces requirements from the first draft to final inspection.

In complex multidisciplinary projects, requirements management is not an administrative chore – it is a critical control mechanism. Without a structured process for identifying, analysing and tracing requirements, the project risks scope creep, escalating costs and technical debt that burdens asset management for decades.

Why Requirements Are Often the Real Cause of Problems

In many technical projects, problems do not arise because the solution is technically deficient, but because it was never entirely clear what should actually be achieved, who owned the requirements and what role different documents played. Requirements are often documented, but they are not governing. They are difficult to verify, difficult to follow up and even more difficult to use when changes arise. In practice, they have become text, rather than a tool for governance.

A requirement that cannot be pointed out is in practice no requirement at all.

Requirements Start with Why the Document Exists

One of the most fundamental mistakes in requirements work is that documents are produced without their purpose being clearly defined. In many projects, documents called requirements specifications, technical descriptions or system documents are produced without it being clear whether the document should function as governance, procurement basis, contract appendix or verification foundation.

When the document’s purpose is not clear, the content follows suit. Requirements are mixed with background, goal formulations, explanatory text and sometimes even ready-made solution proposals.

What Distinguishes Goals, Requirements and Descriptions

A business goal describes why something should be done. It expresses a desired effect or direction, but is not verifiable in a technical sense.
A requirement describes what should be achieved. It is directed at someone other than the person formulating it and must be unambiguous, verifiable and binding. A correctly formulated requirement contains no solutions and no reasoning about why the requirement exists.
A description explains how something is intended to function or be performed. It can be technical or functional, but is not a requirement unless it is explicitly formulated as a verifiable “shall” requirement.

When goals, requirements and descriptions are mixed together, interpretative space arises. What the business perceives as binding may be perceived by the supplier as advisory.

Why Requirements Must Be Identifiable

A requirement that cannot be pointed out is in practice no requirement at all. For requirements to be followed up, verified and changed over time, they must be unambiguously identifiable. Each requirement needs a unique ID and/or sequence number.

A requirement with a sequence number can be referenced, linked to test cases, change requests and documentation. This makes the requirement a manageable information object rather than a formulation in text. Numbering is therefore not administration – it is a prerequisite for requirements management over time.

Abstraction Levels (URS, FRS, TRS)

In professional requirements management, the terms URS, FRS and TRS are often used. These should be understood as abstraction levels rather than fixed document types:

URS (User Requirement Specification) – describes the business’s needs. Technology-independent but verifiable.
FRS (Functional Requirement Specification) – describes which functions the system must have to fulfil the URS. Functional behaviour and logic, without locking technical solutions.
TRS (Technical Requirement Specification) – describes the technical requirements placed on the solution: architecture, performance, interfaces, integrations and technical standards.

Traceability as Quality Assurance

The core of professional requirements management is traceability. Every technical requirement in a TRS must be traceable back to a business need in the URS. In the same way, every delivery must be verifiable against its original requirement.

Without this traceability, change management becomes guesswork where consequence analysis often does not take place – which is the single largest source of technical debt being built into the facility during the construction phase.

ISO/IEC 29148 and What Professional Requirements Management Means

ISO/IEC 29148 describes what is required to work systematically with requirements throughout the lifecycle. The standard emphasises that requirements should be unambiguous, verifiable, traceable and consistently structured. A central principle is that requirements are not text passages, but information objects. Each requirement must be identifiable, referenceable, changeable and verifiable independently of which document it happens to be in.

Responsibility for Requirements in Technical Projects

Responsibility can be simplified to three main roles. The business owns “why” – they have the need and must ultimately be able to judge whether the solution fulfils its purpose. The project is responsible for translating the business’s needs into a feasible solution – developing FRS and TRS, coordinating design and managing suppliers. Suppliers are responsible for implementing according to the TRS and demonstrating that requirements are met.

When responsibility is not clear, gaps arise where requirements fall between the cracks.

Requirements, Verification and Validation

The abstraction level of a requirement is directly linked to how verification and validation are carried out.

Installation Qualification verifies that the solution is installed according to technical requirements and maps primarily to the TRS.

Operational Qualification verifies that the system performs its specified functions and maps to the FRS.

Performance Qualification verifies that the solution meets the business need in real operation and maps to the URS.

This shows clearly why business requirements cannot be written by the supplier. Whoever is to approve the value must own the requirements.

Linking requirements to tests

The URS is verified by the business assessing whether the need is met

The FRS is verified through functional testing

The TRS is verified through technical installation and inspection

Verification without clear requirements becomes a check of workmanship, not of need.

Contract Documents and the Dual Roles of Documents

In many projects, technical descriptions and system documents are used as combined documents for requirements, function and execution. In Swedish design-build contracts (ABT 06) this is common practice, and it is not wrong in itself.

The problem arises when these documents are expected to serve both as a description and as a verifiable requirements baseline. The requirements are there, but they are not identifiable as requirements.

A document can contain requirements without being a requirements document. It is the role of the content, not the title of the document, that determines its function in the requirements chain.

Common consequences of combined documents

Requirements cannot be traced to tests

Changes are handled informally

Discussions arise late in the project

Responsibility becomes unclear in a dispute

This is not a methodology problem but a structural problem.

Requirements as Information Objects Over the Lifecycle

Requirements are not static. They change when the business changes, when technology is replaced and when systems are rebuilt. To handle this, requirements must be treated as information objects with a lifecycle – linked to functions, technical solutions, tests and documentation.

Requirements work when they are separated from descriptive text, have a clear owner, can be verified, are traceable over time and are used even after the project ends. When these conditions are met, requirements become a governance tool, not administration.

Do you have control of your requirements – all the way to commissioning?

Inadequate requirements management is the most common reason technical projects overrun in both time and cost. In the role of technical owner’s representative and Owner’s Representative, HubMind helps you establish the structure that makes your requirements an active governance instrument for both project management, architecture and future asset management.

When Requirements Management Becomes a Governance Tool

A requirement is something that is to be fulfilled by someone other than the party stating it, and that can be verified.

Everything else is a goal, a description or a solution, even if it happens to sit in the same document.

Once this is clear, it also becomes clear why documents exist, who is responsible for what, and how technical projects can be governed through the entire lifecycle, from need to operation and change.

Reflection

A quick check of requirements maturity

Can you point to exactly which statements are requirements

Is it clear who owns each requirement

Can the requirements be verified without interpretation

Are the requirements used after commissioning

If the answer to any of these questions is no, there is most likely room for improvement.

David Nordin

See Full Bio