Requirements engineering (RE) is the systematic and disciplined method of eliciting, documenting, reviewing and managing the requirements for a system. It is critical to the success of system development projects as it helps to understand the needs and wishes of stakeholders and ensure that the final system meets them.

The main tasks in RE include identifying the requirements, documenting them, validating them to ensure that they meet the actual needs, and managing the requirements throughout the lifecycle of the system. Tool support can also be used for these tasks to improve efficiency and accuracy.

In requirements engineering, we distinguish between functional requirements, quality requirements and constraints, each of which affects different aspects of a system.

A clear distinction between functional, quality requirements and constraints is important in order to define the solution space appropriately and avoid misunderstandings that could lead to undesirable developments.

Software-centric systems that combine hardware, software and organizational aspects are particularly complex. Requirements engineering helps to systematically capture and manage the diverse requirements of these systems.

While there is no universal process for requirements engineering, a suitable RE process tailored to the situation must be defined for each development.

Stakeholders influence or are influenced by the system to be developed and are therefore central to determining the system requirements.

A requirements engineer is responsible for the determination, documentation, validation and management of requirements and acts as a bridge between the problems and the possible solutions, or as a bridge between specialist departments/business and technology/IT.

A common understanding is crucial to ensure that everyone involved interprets the requirements and objectives of the project in the same way and to prevent undesirable developments.

The value of RE is determined by the benefits of the requirements in relation to the costs of their elicitation, validation and management. A key objective of RE is to minimize the risk of rework and failure.

Poor RE can lead to unclear, missing or incorrect requirements, which in turn can cause expensive rework, communication problems between stakeholders and ultimately project failure.

The Kano model helps to understand the customer perspective by categorizing features into delight factors, performance factors and basic factors, leading to a user-centric design.

The Kano model helps to identify not only obvious requirements, but also those that contribute to customer enthusiasm and stand out from the competition.

Basic factors are features that customers tacitly assume and take for granted. If these features are not implemented in the system, this leads to considerable dissatisfaction.

Performance factors are features that are explicitly requested by customers. Their number and quality in the system correlates directly with customer satisfaction. However, an excessive number can increase costs, which is why a cost-benefit analysis is important.

Delight factors are features that customers do not explicitly request because they do not know that they are possible in the system. Such features can positively surprise customers and clearly set a product apart from the competition.

Prioritization techniques help to identify the most important requirements and ensure that resources are used efficiently to implement the most valuable features.

Traceability refers to the ability to track the lifecycle of a requirement, from identification to implementation to maintenance, and is critical to the effective management of change.

Graphical models and diagrams are key tools in requirements engineering, as they visualize complex requirements and system structures and improve understanding and communication between stakeholders.

The IREB curriculum includes UML class diagrams for representing classes and their associations as well as entity-relationship diagrams (ERD) for modeling objects, attributes and relationships.

For function and process, the IREB recommends models such as UML use case diagrams, UML activity diagrams and data flow diagrams.

Yes, requirements engineering is also relevant in an agile context. Iterative RE processes are adaptable and can take changes or forgotten requirements into account in later iterations, which makes them particularly suitable for agile development processes.

Yes, IREB knowledge can be applied in both contexts. A strict separation of RE from system development is rarely possible, so flexibility in the application of knowledge is important.

In a waterfall project, more extensive techniques such as apprenticing or analogies are planned, whereas in an agile environment, techniques such as brainstorming, storyboarding and prototyping predominate.

The agile approach, such as Scrum, reacts more flexibly to changes, requirements are updated more frequently and are more closely intertwined with development, whereas waterfall processes are more plan-based and sequential.

UML class diagrams help to visualize class structures and their relationships to each other, which is important for the analysis and understanding of complex data structures in a system.

BPMN supports the precise representation and understanding of business processes, which is essential for the correct recording of functional requirements and processes in a system.

The decision to use an agile or waterfall model influences the choice of RE techniques, as agile models require an iterative and adaptable approach, while waterfall models favor a sequential and plan-based approach.

Pre-traceability refers to the ability to trace the origin of a particular requirement. This means that it is possible to trace where and how a requirement was determined and which sources were taken into account. This is particularly important for safety-critical systems, where process standards often require explicit traceability.

Post-traceability means being able to identify where and how a requirement is used within the system, e.g. in which modules, test cases or documentation it is implemented. This is also known as post-requirements specification traceability and is crucial for the management of requirements implementation.

Individual requirements must be clearly defined, unambiguous, complete and modifiable. They should not overlap with other requirements and should be structured in such a way that they can be modified without any loss of quality. It is also important that they are traceable, i.e. that their origin and use in the system can be clearly traced.