What Are the Principles of Requirements Engineering?

The 9 Principles of Requirements Engineering. According to IREB^®

According to the 2020 International Requirements Engineering Board (IREB) Official Glossary, requirements engineering is a systematic and disciplined approach to specifying and managing requirements with the following objectives:

• Know the relevant requirements, establish consensus among stakeholders on the requirements, document the requirements according to specified standards, and systematically manage the requirements,
• to understand and document the wishes and needs of the stakeholders,
• specify and manage the requirements to minimize the risk that the system being delivered will not meet the wants and needs of the stakeholders.

In the new edition of the Certified Professional for Requirements Engineering (CPRE) curriculum, version number 3.0.1 of 2020, IREB also defined fundamental principles for requirements engineering for the first time. Such principles, as known for example from the agile manifesto, help to better internalize the objective of requirements engineering in general. 9 principles have been established that should apply to all tasks, activities and practices in requirements engineering.

The value of a requirement is determined by the benefit minus all costs for its determination, documentation, validation and management. The benefit is determined by its contribution

• to a system that fulfills the wishes and needs of the stakeholders.
• to reduce the risk of undesirable developments and their consequential costs in system development.

Thus, requirements engineering places a strong focus on the value creation of a development. This principle is also of great importance in agile methods (such as Scrum). Instead of working through a list of fixed requirements in a linear fashion, the value of the development is to be checked again and again in short cycles and requirements are to be adapted accordingly.

Requirements engineering should create, promote and secure a common understanding between stakeholders, requirements engineers and developers. IREB differentiates two forms of common understanding here:

• explicit (based on documented and agreed requirements)
• implicit (based on shared knowledge).

Of course, shared understanding also depends on factors such as team size, team distribution, turnover, culture, and values. Shared understanding can be improved through glossaries, prototypes, or existing reference systems. Short feedback cycles should be established to keep checking the common understanding.

In order to specify systems correctly, one must first determine the system context. The system context is relevant for defining and understanding the requirements. This is because systems are usually connected to their environment through interaction (e.g., via interfaces). The boundary between the system being developed and the surrounding context can also shift, which in turn affects the requirements. The system boundary also defines the scope of the system to be developed. If the scope is not delimited, a creeping increase of requirements, a so-called scope creep, can easily occur. There is room for maneuver within the scope boundary. The core task of requirements engineering is to detect shifts in the system boundary and to make resulting changes to the requirements.

Problems, requirements and solutions are closely intertwined. They cannot be addressed in isolation. Often the sequence is as follows: Stakeholders have a problem – then requirements are recorded, the fulfillment of which should solve or simplify the problem – finally a solution is delivered in the form of a system that meets these requirements. In the case of innovations, however, this chronology is not always correct because they usually do not arise from concrete stakeholder requirements; instead, solutions tend to emerge experimentally.

Requirements engineers should nevertheless strive to separate problems, requirements, and solutions as much as possible when thinking, communicating, and documenting. This facilitates the handling of requirements engineering tasks: Requirements elicitation, requirements documentation, requirements validation, and requirements management.

The system to be created must fulfill the wishes and needs of the stakeholders. Therefore, requirements that are not validated are useless. Validation must already begin in requirements engineering. It must be checked whether

• agreement on the requirements has been reached among the stakeholders
• the wishes and needs of the stakeholders are sufficiently covered by the requirements
• the context assumptions are correct and reasonable

Validation techniques include reviews such as walkthroughs or inspections and explorations such as prototyping, A/B tests, minimum viable products (MVP), or trial developments.

Systems and their requirements are constantly changing, they are subject to evolution. Changes to requirements are triggered by:

• changed business processes
• Competitors with new products/services
• changing wishes and priorities of stakeholders
• technological progress
• changes in laws and regulations
• feedback loops

Requirements engineers must therefore balance between two conflicting goals: allowing meaningful change and keeping requirements stable. The deciding factor in this decision is likely to be whether or not a change adds value.

The goal of good requirements engineering is not to satisfy stakeholders, but to inspire them. The “overfulfillment” of requirements often only succeeds with innovation. The Kano model illustrates this relationship between requirements and customer satisfaction very well.

Requirements engineering shapes innovative systems

• on a small scale by striving for exciting new functions and very good usability
• on a large scale by striving for changing (disruptive) new ideas.

Creativity techniques and methods from design thinking can be used to elicit requirements that help produce innovative solutions.

Systematics and discipline in requirements engineering improve the quality of the system to be created. This does not mean that there is only one correct process that should be used for all projects.

Requirements engineers should therefore

• adapt the procedures, practices, and deliverables they use to the problem, context, and work environment they are working in.
• do not always use the same process and practices.
• do not reuse processes and practices from previous successful requirements engineering activities without reflection.