The Requirements Engineering Framework

1. What Is Requirements Engineering?

Requirements engineering is the disciplined process of defining, documenting, and maintaining the requirements for a system. It is not simply "gathering requirements" — it is a structured engineering activity with four core stages:

• Elicitation — identifying stakeholder needs, expectations, and constraints through interviews, workshops, document analysis, and observation.
• Analysis — examining requirements for completeness, consistency, feasibility, and conflicts. This is where ambiguities and gaps are identified before they become costly.
• Specification — documenting requirements in a structured, unambiguous format that can be understood by all parties and used as a basis for design and verification.
• Validation — confirming with stakeholders that the documented requirements accurately reflect their actual needs and that the set of requirements is complete and achievable.

Requirements engineering sits within the broader discipline of systems engineering, which manages the full lifecycle of complex systems from concept through to disposal. The key standards that govern this process include ISO/IEC/IEEE 29148 (requirements engineering) and the INCOSE Systems Engineering Handbook.

It is important to distinguish between different types of requirements:

• Functional requirements describe what the system must do — its behaviours, functions, and capabilities.
• Non-functional requirements describe how the system must perform — reliability, availability, maintainability, safety (RAMS), performance, and security.
• Constraints are imposed limitations on the design or implementation — regulatory mandates, interface standards, environmental conditions, or organisational policies.

2. The Requirements Lifecycle

Requirements are not a one-time deliverable. They evolve through a managed lifecycle that spans the entire project — from initial stakeholder engagement through to system acceptance. Understanding this lifecycle is critical to managing requirements effectively, particularly on programmes that run for years across large supply chains.

The typical requirements lifecycle follows this progression:

1. Stakeholder needs — high-level statements of what the end users, operators, or acquirers need the system to achieve. These are often expressed in operational language rather than technical terms.
2. Concept of operations (ConOps) — describes how the system will be used in its intended environment. This bridges the gap between stakeholder intent and engineering specification.
3. System requirements — technically precise statements derived from stakeholder needs, specifying what the system must do and how it must perform.
4. Subsystem and component requirements — system requirements decomposed and allocated to specific subsystems, assemblies, or components.
5. Verification and validation — evidence that each requirement has been met (verification) and that the system as a whole satisfies the original stakeholder needs (validation).
6. Acceptance — formal sign-off that the delivered system meets all contractual and regulatory requirements.

At each stage, requirements should be placed under baseline control. A baseline is a formally agreed set of requirements at a point in time. Changes to baselined requirements must go through a change control process — otherwise scope drift becomes invisible and unmanaged.

3. The V-Model: Connecting Design to Verification

The V-model is the most widely used framework for structuring systems engineering activities. It maps the relationship between design activities (the left side) and verification activities (the right side), with integration and build at the base.

The critical insight of the V-model is that every level of design has a corresponding level of verification. Requirements defined at each level on the left side must be verified at the matching level on the right side — and traceability connects them.

4. How to Write Good Requirements

A well-written requirement is the foundation of every successful engineering activity that follows. Poorly written requirements cause ambiguity, rework, disputes, and compliance failures. The INCOSE Guide for Writing Requirements defines the quality attributes that every requirement should meet:

Before and after: requirement quality in practice

This requirement is not verifiable (what is "fast"?), not unambiguous (what is "user-friendly"?), and violates the singular rule by combining two requirements into one statement.

This requirement is singular, measurable, verifiable, and unambiguous. A test can be designed to prove compliance.

This mixes a design solution ("use a modern database") with a functional need ("provide real-time reporting"), and combines two separate requirements into one. "Modern" is subjective and unverifiable.

The design decision (which database to use) is left to the designer. The requirement states the outcome that matters — data freshness — in a verifiable way.

Common pitfalls

• Mixing requirements with design solutions — state what the system must achieve, not how it should be built. The "how" belongs in design documentation.
• Vague quantifiers — words like "sufficient", "adequate", "reasonable", "timely", and "appropriate" are not verifiable. Replace them with measurable criteria.
• Compound requirements — if a requirement contains "and" or "or", it likely needs to be split into separate requirements, each independently traceable and verifiable.
• Passive or implied subjects — every requirement should clearly state which entity must perform the action (e.g., "The control system shall..." not "It shall be possible to...").

5. Requirements Elicitation and Gathering Methods

Requirements elicitation is the process of discovering what stakeholders actually need — which is often different from what they initially ask for. Effective elicitation uses multiple techniques to build a complete picture, because no single method captures all requirements.

6. Requirements Decomposition and Allocation

Decomposition is the process of breaking high-level stakeholder needs into progressively more detailed requirements that can be implemented and verified. Allocation is the process of assigning those requirements to specific systems, subsystems, components — or suppliers.

A typical decomposition hierarchy looks like this:

1. Stakeholder requirements — "The railway shall transport 30,000 passengers per hour in peak periods."
2. System requirements — "The signalling system shall support a minimum headway of 90 seconds between trains."
3. Subsystem requirements — "The interlocking shall process route requests within 2 seconds of receipt."
4. Component requirements — "The route processor module shall handle a minimum of 50 concurrent route requests."

Each level adds technical detail while maintaining a traceable link to the level above. When requirements are allocated to suppliers in a supply chain, each supplier needs visibility of the requirements allocated to them, the parent requirements driving those allocations, and the verification evidence expected.

This is where requirements management becomes a supply chain coordination challenge. In a multi-tier supply chain, the principal contractor decomposes and allocates requirements to subcontractors, who may further decompose and allocate to their own suppliers. Without a shared platform, each tier works from a different version of the truth.

7. Requirements Traceability

Requirements traceability is the ability to follow a requirement in both directions — forward from stakeholder need through to design, implementation, and verification evidence; and backward from any artefact to the requirement that drove it.

Why traceability matters

• Impact analysis — when a requirement changes, traceability shows every downstream artefact affected: designs, tests, supplier allocations, and acceptance criteria.
• Verification coverage — traceability reveals which requirements have been verified and which have not. Gaps in verification coverage are gaps in compliance.
• Audit evidence — regulated industries require demonstrable traceability. Standards such as DO-178C (aerospace), EN 50126 (rail), ISO 26262 (automotive), and IEC 62304 (medical devices) all mandate requirements traceability as a condition of certification or approval.
• Change control — traceability makes change requests assessable. Without it, the impact of a proposed change is a guess.

The requirements traceability matrix

A requirements traceability matrix (RTM) is the most common tool for documenting trace links. It maps each requirement to its source (upward trace), its design implementation (downward trace), and its verification evidence (forward trace). In a well-managed project, the RTM is a living document that evolves with the requirements baseline.

In practice, maintaining an RTM in spreadsheets becomes unmanageable beyond a few hundred requirements — particularly when multiple parties across a supply chain need to contribute verification evidence. This is where dedicated requirements management tools replace manual methods.

8. Verification vs Validation

Verification and validation are related but distinct activities. Confusing them is one of the most common errors in requirements engineering — and the consequences are significant.

Verification methods (IADT)

There are four recognised methods of verification, commonly referred to as IADT:

• Inspection — visual examination of a work product to confirm it meets requirements. Used for physical characteristics, labelling, and documentation completeness.
• Analysis — using mathematical models, simulations, or analytical techniques to demonstrate compliance. Used when testing is impractical or insufficient (e.g., structural load calculations).
• Demonstration — operating the system to show that it performs as required, without requiring detailed measurement. Used for functional capabilities and user-facing behaviours.
• Test — exercising the system under controlled conditions and measuring the results against defined acceptance criteria. The most rigorous method, used when quantitative evidence is required.

Each requirement should specify which verification method applies and what the acceptance criteria are. This should be defined during requirements analysis — not left until the test phase. A requirement that cannot be verified by any of these methods is not a well-formed requirement.

9. Requirements Engineering and Project Management

Requirements engineering and project management are deeply interconnected. Requirements define the scope of work. Scope drives schedule, budget, and resource planning. When requirements change — and they always do — cost and schedule change with them.

The relationship works in both directions:

• Requirements define scope — the set of baselined requirements is the definitive statement of what the project must deliver. Without a stable baseline, scope is a moving target.
• Change control protects the plan — every change to a baselined requirement should be assessed for impact on schedule, cost, and risk before approval. This is the formal link between requirements management and project control.
• Gate reviews rely on requirements — approval milestones (preliminary design review, critical design review, test readiness review) are structured around demonstrating that requirements have been addressed at each stage.
• Risk management is requirements-driven — assumptions, constraints, and dependencies are risk items that attach to requirements. Tracking them alongside requirements — rather than in a separate risk register — keeps them visible and actionable.

Research consistently shows that the number one cause of project cost overruns in complex industries is poor requirements management — not poor estimation, not technical failure, but requirements that were unclear, incomplete, or uncontrolled. See industry-specific data on our About page.

10. Applying This Framework in Practice

Understanding requirements engineering methodology is one thing. Implementing it across a real project with multiple suppliers, evolving scope, and regulatory obligations is another. Most teams know that requirements matter — the challenge is having a structured way to manage them without drowning in spreadsheets or heavyweight tools that nobody uses.

Reqi is built on the framework described in this guide. It provides a shared platform where project teams and their supply chain can manage requirements with full traceability, track compliance in real time, and surface risks — assumptions, constraints, and dependencies — before they become problems. Learn more about how Reqi works across regulated industries.