What Defines a Good Requirements Management Process

The four logical activities of requirements engineering

Requirements engineering (RE) is traditionally divided into four key activities:

1. Identification of requirements
2. Documentation of requirements
3. Validation of requirements
4. Management of requirements

These four activities form the logical sequence in which requirements are created and developed.

However, this is not a process in the organizational sense, but rather logical steps in terms of content that are found in every project, regardless of the process model or tool used.

‍

1. Requirements analysis – understanding needs

Every project begins with the question: What actually needs to be achieved?

Requirements analysis is about understanding the needs, goals, and framework conditions of a system. Typical sources include stakeholder interviews, market analyses, standards, and existing products.

A common mistake at this stage is to jump to conclusions about solutions. Good requirements analysis means starting with the problem, not the solution. The goal is to achieve a common understanding among all participants of what the system should do – not how it does it.

2. Documentation of requirements – recording what has been understood

What is not recorded does not exist.

Identified requirements must be documented precisely, comprehensibly, and verifiably. Various formats are used for this purpose, from text-based descriptions and use cases to models and diagrams.

The documentation not only serves as a reference work, but also forms the basis for communication, coordination, and subsequent validation. Only here does the invisible become tangible: assumptions become explicit, contradictions become apparent, and priorities become clear. However, you can only document what has been determined beforehand. This already shows the logical dependency of the activities.

3. Validation of requirements – ensuring quality

Validation involves checking whether the documented requirements are correct, complete, and consistent – and whether they actually reflect what stakeholders really need.

Various techniques can be used for this purpose: reviews, prototyping, simulation, or tests at the requirement level. Validation is not a one-time step, but an iterative process that continually provides new insights.

This is precisely where it becomes clear: if gaps or conflicts are discovered during validation, you have to go back to the determination or documentation stage. Requirements engineering is therefore not a linear waterfall, but a dynamic cycle.

4. Requirements management – maintaining an overview

Once requirements have been approved and are actively in use, the actual requirements management process begins in the narrower sense.

This includes change management, versioning, traceability, and the maintenance of dependencies throughout the entire lifecycle.

Especially in modern development environments with agile or hybrid process models, management is crucial for maintaining an overview despite changes and parallel work.

This is where it is decided whether the project remains stable – or ends in chaos.

‍

From logical sequence to actual process

The four activities described above form a logical sequence, but they do not yet constitute a process in the organizational sense. It is clear, for example, that not all requirements are determined before documentation begins. Instead, the individual activities are repeated over and over again – each time for different sets of requirements.

A process therefore only emerges when these activities are combined with specific content, a time structure, responsibilities, and approval points.

A good process follows the principle of refinement and continuous validation.

The principle of “from rough to refined"

An effective requirements management process is based on the principle of gradual refinement.

This means starting with the big picture—the project idea, product vision, or system purpose—and gradually deriving more specific requirements from it, rather than getting lost in all the details right away.

This approach has three key advantages:

1. You never lose sight of the goal because all detailed requirements can be traced back to higher-level goals.
2. You ensure that nothing is forgotten by systematically working your way from “top to bottom.”
3. Changes can be tracked in a targeted manner because you understand how changes from top to bottom influence each other.

In practice, there are two central approaches to implementing the “rough to fine” principle: architectural refinement and functional decomposition.

Architectural refinement

Architectural refinement is based on the product breakdown structure (PBS), i.e., the structural design of the system to be developed. Starting with the overall system, the requirements are broken down step by step to the respective system, module, and component levels.

Example:

An automobile manufacturer starts with system requirements for the entire vehicle.

This results in module requirements for the braking system, lighting, or infotainment.

At the component level, specific requirements for brake discs, sensors, or control units follow.

This structuring enables clear responsibilities, supports traceability, and is essential for testing and risk analysis.

Functional decomposition

As an alternative or supplement to the architectural view, requirements can also be decomposed functionally – that is, along the functions that the system is to perform.

The focus here is on the question: Which function contributes to the fulfillment of the system purpose and how?

This results, for example, in requirements for “recognition,” “processing,” and “display,” which can later be assigned to specific architectural components.

A functional view is particularly suitable in early phases or for systems with many software-based components, as it helps to understand logical relationships before concrete physical structures are defined.

Combining both perspectives

In practice, combining both approaches is usually most effective:

The architectural structure provides the framework, while the functional structure describes the internal logic. Good requirements management combines both – for example, according to the Twin Peaks model, in which requirements and architecture are refined in parallel.

This creates an iterative process in which requirements influence the architecture on the one hand and are specified by it on the other.

‍

The process as a control instrument

A requirements management process is therefore much more than just a methodical sequence. It is the control instrument that ensures that requirements are created in a comprehensible, consistent, and quality-assured manner.

A good process includes:

• Clear roles and responsibilities (e.g., who is authorized to approve requirements?)
• Defined quality criteria for requirements
• Coordinated milestones with approvals and handovers
• Transparent communication channels between specialist departments and development
• Tool support that enables reuse, versioning, and traceability

This creates a process that is not only logical but also works in practice – in both agile and classic environments.

Iterations and feedback are part of the process.

A common misconception is that a defined process necessarily follows a linear path. In reality, requirements management is always iterative.

If it becomes apparent during validation that requirements are missing, you have to go back to the determination stage.

If new insights arise during implementation, you have to adapt the documentation and management.

These setbacks are not a sign of weakness – on the contrary, they are a hallmark of professional work. A good process deliberately allows for such feedback instead of suppressing it.

‍

A good requirements management process is not a product of chance

A good requirements management process combines structure, logic, and flexibility. It is based on the four activities of requirements engineering, follows the principle of “from rough to fine,” and integrates both architectural and functional perspectives.

The goal is not to plan every step perfectly, but to create a transparent and comprehensible process that allows for adjustments without losing sight of the big picture.

Those who achieve this lay the foundation for quality, efficiency, and innovation—and use requirements engineering not just as a mandatory exercise, but as a real success factor in product development.

‍