The nine principles of requirements engineering

Requirements engineering (RE) comprises four types of activities: Requirements are elicited, documented, analysed and managed. Numerous techniques support these activities. According to the International Requirements Engineering Board (IREB)¹, nine principles are to be observed during the implementation, which are described in detail in the IREB Foundation Level Syllabus Version 3.0.1² and briefly summarised here:

Principle 1: Value-orientation

Requirements are a means to an end, not an end in itself!

Requirements engineering places a strong focus on the value creation of a development. The value of a specific requirement is equal to its benefit minus the cost of eliciting, documenting, validating and managing the requirement. The benefit of a requirement is determined by the degree to which it contributes to the development of a system that meets the wants and needs of the stakeholders while reducing the risk of undesirable developments and subsequent costs.

Principle 2: Stakeholder

RE is about satisfying the stakeholders’ desires and needs!

In order to understand the wishes and needs of stakeholders, stakeholder management is a core task in requirements engineering. Stakeholders are all persons or organisations that are directly or indirectly affected by the activities of a company or have an interest in these activities. In the context of system development, they may be users, customers, clients, operators or regulatory authorities. And of course, a stakeholder can also fulfil several roles at the same time.

For stakeholder roles with too many individuals or with unknown individuals, fictitious, archetypal descriptions – so-called personas – can be defined. Personas help to make assumptions and better understand the needs, attitudes and actions of potential users.

Basically, it is not enough to only consider the requirements of end users or customers, as this would certainly overlook critical requirements of other stakeholders. It is also important to realise that stakeholders may have different, possibly conflicting needs and viewpoints. Identifying and resolving such conflicts – ideally as early as possible – is an important task in the course of Principle 2.

Principle 3: Shared understanding

Successful systems development is impossible without a common basis!

For the successful development of systems, a common understanding between the parties involved – stakeholders, requirements engineers and developers – is essential. A distinction can be made between

• explicit understanding, which is jointly achieved through documented and agreed requirements, and
• implicit understanding, which is based on shared knowledge about needs, visions, context, etc.

Domain knowledge, previous successful collaboration, shared culture and values, and mutual trust are prerequisites for shared understanding, while geographical distance, outsourcing or large teams with high turnover are barriers.

In the lived practice of requirements engineering there are some practices like

• the use of glossaries,
• the creation and investigation of prototypes,
• the use of existing systems as a reference point,
• the joint estimation of efforts to implement requirements,
• or short feedback cycles,

that promote shared understanding.

Principle 4: Context

Systems cannot be understood in isolation!

Systems are embedded in a context. The system context describes the interaction of a system with its environment. The definition of system and system boundary, as well as relevant and irrelevant system environment, is important because it defines the aspects that need to be considered in the context of a development.

Initially, the system boundary is often not clear and over time it may even shift. Clarifying and respecting the system boundary and defining the scope are important RE tasks. Incidentally, in system specification it is not sufficient to consider only the requirements within the system boundary, because changes in the context can also affect system requirements.

Principle 5: Problem – Requirement – Solution

An inevitably intertwined triple!

Problems, requirements and solutions are closely intertwined and coexist. In addition to the familiar scenario with a stakeholder’s problem, the resulting definition of requirements and the development of solutions, e.g. in the form of features, there are also scenarios in which solution ideas generate user needs that have to be elaborated as requirements and translated into a concrete solution. Such a scenario typically applies to innovations.

Requirements engineers try to separate the triple of problem, requirement and solution as much as possible when thinking, communicating and documenting, because such a separation facilitates the processing of the RE tasks.

Principle 6: Validation

Non-validated requirements are useless!

To control the risk of dissatisfied stakeholders from the beginning, requirements must be validated.  It is necessary to check whether

• the wishes and needs of the stakeholders are sufficiently covered by the requirements,
• there is agreement on the requirements, and
• the context assumptions are reasonable.

Principle 7: Evolution

Changing requirements are no accident, but the normal case!

Requirements change continuously, for example due to

• changes in business processes,
• competitors introducing new products or services,
• customers changing their priorities or opinions,
• changes in technology,
• changes in laws or regulations,
• feedback from stakeholders during validation,
• discovered errors,
• changing needs, or
• feedback from system users asking for a new or changed feature.

Requirements engineers therefore pursue two contradictory goals: allowing meaningful changes and keeping requirements stable.

Principle 8: Innovation

More of the same is not enough!

Good requirements engineering tries to inspire stakeholders. On a small scale, this is achieved by striving for useful, new functions and a positive >user experience, on a large scale by striving for disruptive ideas.

On the topic of innovation, it is advisable to take a look at the Kano Model. It describes the connection between customer satisfaction and the fulfilment of customer requirements by defining product features to which users react differently.

Principle 9: Systematic and disciplined work

We can’t do without in RE!

There is no one process or procedure in requirements engineering that works well in every situation. To ensure the quality of a system, the processes, practices and work products that best suit the situation must be chosen. Systematic and disciplined work means adapting the approach to the particular problem, context and working environment, and not stubbornly using the same processes and practices over and over again.

The interaction of the principles

A whole range of activities result from the above-mentioned nine principles in requirements engineering:

“Systematic and disciplined work” is only mentioned as principle 9, but it forms the basis for the requirements engineer profession. The IREB writes: “Agility and flexibility are not valid excuses for an unsystematic ad hoc style of working in RE.” Systematic work involves configuring the RE process for the current project and selecting the most appropriate techniques and practices. Discipline also means executing them cleanly.

Five principles concern requirements elicitation:

To ensure that the wants and needs of the stakeholders critical to success can be met (Principle 2), you need to identify and analyse them, and involve them in the requirements elicitation process. To avoid too much, you should prioritise the stakeholder (groups) so that the priorities of their requirements can also be derived from this.

Strictly speaking, the goal of requirements elicitation is not the documented requirements on paper, but above all a common understanding in the minds (principle 3). The requirements specification can contribute to this as a tool, but so can prototypes and short feedback loops. You must therefore explicitly include these in the requirements elicitation.

In addition to requirements, stakeholders need to consider together the context of the system, because systems cannot be understood in isolation (Principle 4).

Problems (in the application domain), requirements and solutions are closely linked, but must be kept strictly separate during elicitation and documentation (principle 5). All parties involved must always be clear about what they are (supposed to be) talking about.

Of course, requirements engineers should not be content with just logging the stakeholders’ wishes. He must strive to exceed the stakeholders’ expectations. To do this, he encourages creativity. One means of doing this can be to ask why and what for requirements. It may be possible to solve the underlying problem even better with innovative solutions Principle 8).

Three principles support the analysis of requirements:

Requirements engineering is not an end in itself, but should create added value (principle 1). Each individual requirement should also be evaluated according to its value contribution, i.e. benefit minus cost. The described system functionality or property can directly lead to more sales or cost savings, but also create benefits by reducing risks such as the risk of rework. Therefore, when analysing requirements, the requirements engineer should ask:

• What is the benefit of this requirement?
• Is it useful to do more requirements engineering or do we know enough?
• Is the residual risk, i.e. the risk of later rework or software errors that can arise from the details still missing in the requirements, acceptable?

Since requirements engineering is about satisfying the wishes and needs of the stakeholders (principle 2), the analysis of the requirements does not only include the verification whether one has completely and correctly derived the requirements from the problem and from this the solution, but also the validation, which checks whether the requirements and the solution actually fulfil the wishes and needs of the stakeholders. You can achieve this in particular through prototyping, reviews, scenarios or walkthroughs.

The IREB even goes so far as to claim that non-validated requirements are useless (Principle 6). This validation must take place as early as possible. Here you not only check whether the requirements meet the wants and needs of the stakeholders (Principle 2), but also whether there is a common understanding (Principle 3).

One principle supports the management of requirements:

As the context of the system and the needs of the stakeholders are constantly changing, we can certainly expect the requirements to change as well (Principle 7). But fixing bugs and gaps in the requirements also leads to changes. As a requirements engineer, you have to manage and control these. In doing so, you seek the right balance between “welcome improvements to the requirements” and “keep the requirements as stable as possible”. Validation of requirements leads to both changes and increased stability after the requirements have been quality assured in this way.

And this brings us back to Principle 9: Systematic and disciplined work. It is the basis for the principles of requirements elicitation and analysis. It is the basis for successful requirements engineering.

Notes:

If you are interested in more explanations, we recommend the free Requirements Engineering Whitepaper.

[1] IREB e.V.
[2] Syllabus IREB CPRE Foundation Level

Here in our t2informatik Blog you can find more articles from Dr Andrea Herrmann, including

t2informatik develops and modernises software as a service provider. Click here to learn more.