2.

Fundamental Principles of Requirements Engineering

In this chapter, you will learn about nine basic principles of Requirements
Engineering (RE).

2.1 Overview of Principles

RE is governed by a set of fundamental principles that apply to all tasks, activities, and
practices in RE. A task is a coherent chunk of work to be done (for example, eliciting
requirements). An activity is an action or a set of actions that a person or group
performs to accomplish a task (for example, identifying stakeholders when eliciting
requirements). A practice is a proven way of how to carry out certain types of tasks
or activities (for example, using interviews to elicit requirements from stakeholders).
The principles listed in Table 2.1 form the basis for the practices presented in the
subsequent chapters of this handbook.

Table 2.1 Nine fundamental principles of Requirements Engineering

1 Value orientation: Requirements are a means to an end, not an end in itself

2 Stakeholders: RE is about satisfying the stakeholders’ desires and needs
3 Shared understanding: Successful systems development is impossible without a
common basis
4 Context: Systems cannot be understood in isolation
5 Problem, requirement, solution: An inevitably intertwined triple
6 Validation: Non-validated requirements are useless
7 Evolution: Changing requirements are no accident, but the normal case
8 Innovation: More of the same is not enough
9 Systematic and disciplined work: We can’t do without in RE

2.2 The Principles Explained

Principle 1 – Value orientation: Requirements are a means to an end, not an end

in itself
The act of writing requirements is not a goal by itself. Requirements are useful—and Value of requirements:
the effort invested in Requirements Engineering is justified—only if they add value benefit minus costs
[Glin2016], [Glin2008], cf. Section 1.2. We define the value of a requirement as being
its benefit minus its cost. The benefit of a requirement is the degree to which it
contributes to building successful systems (that is, systems that satisfy the desires
and needs of their stakeholders) and to reducing the risk of failure and costly rework
in system development. The cost of a requirement amounts to the cost for eliciting,
validating, documenting, and managing it.
Reducing the risk of rework during development is a constituent part of the benefit of Benefit from reduced
a well-crafted requirement. Detecting and fixing a missed or wrong requirement rework
during implementation or when the system is already in operation can easily cost one
or two orders of magnitude more than specifying that requirement properly right
from the beginning. Consequently, a significant amount of the benefit of requirements
comes from costs saved during the implementation and operation of a system.

Handbook for the CPRE Certified Professional for Requirements Engineering

Foundation Level - Version 1.0.0 Page 13/139
In other words, the benefits of RE are often long-term benefits, whereas the costs are
immediate. This must be kept in mind when setting up a new project. Reducing costs
in the short term by spending less for RE has a price: it considerably increases the risk
of expensive rework in later stages of the project.
The value of Requirements Engineering can be considered to be the cumulative value Value of Requirements
of the requirements specified. As customers typically pay for systems to be Engineering
implemented, but not for the requirements needed to do that, the economic value of
RE is mostly an indirect one. This effect is reinforced by the fact that the benefit of
requirements that stem from reduced rework costs is an indirect one: it saves costs
during implementation and operation.
The economic effects of Requirements Engineering are mostly indirect ones; RE as
such just costs.
To optimize the value of a requirement, Requirements Engineers have to strike a Optimizing the value of
proper balance between the benefit and the cost of a requirement. For example, requirements
eliciting and documenting a stakeholder’s need as a requirement eases the
communication of this need among all parties involved. This increases the probability
that the system to be built will eventually satisfy this need, which constitutes a
benefit. The less ambiguously and the more precisely the requirement is stated, the
higher its benefit, because this reduces the risk of costly rework due to
misinterpretation of the requirements by the system architects and development
teams. On the other hand, increasing the degree of unambiguity and precision of a
requirement also increases the cost involved in eliciting and documenting the
requirement.
Actually, the amount of RE required to achieve requirements with optimal value Influencing factors
depends on numerous factors given by the specific situation in which requirements
are being created and used. Obviously, the risk of building a system that eventually
does not satisfy the desires and needs of its stakeholders, which may result in failure
or costly rework, is the driving force that determines the amount of RE required. First
and foremost, the criticality of every requirement should be assessed in terms of the
importance of the stakeholder(s) who state the requirement (see Principle 2) and the
impact of missing the requirement (Figure 2.1).

Figure 2.1 Assessing the criticality of a requirement [Glin2008]

Handbook for the CPRE Certified Professional for Requirements Engineering

Foundation Level - Version 1.0.0 Page 14/139
In addition, the following influencing factors should be considered:
Effort needed to specify the requirement
Distinctiveness of the requirement (how much it contributes to the success
of the overall system)
Degree of shared understanding between stakeholders and developers and
among stakeholders
Existence of reference systems (that can serve as a specification by example)
Length of feedback cycle (the time between getting a requirement wrong
and detecting the error)
Kind of customer-supplier relationship
Regulatory compliance required
We summarize this issue in two rules of thumb:
The optimal amount of RE to be invested depends on the specific situation
and is determined by many influencing factors.
The effort invested into RE should be inversely proportional to the risk you
are willing to take.

Principle 2 – Stakeholders: RE is about satisfying the stakeholders’ desires and

needs
The eventual goal of building a system is that the system, when it is used, solves
problems that its users need to solve and satisfies the expectations of further
people—for example, those who have ordered and paid for the system, or those who
are responsible for security in the organization that uses the system. Therefore, we
have to figure out the needs and expectations of the people who have a stake in the
system, the system’s stakeholders [GlWi2007]. The core goals of RE are understanding
the stakeholders’ desires and needs and minimizing the risk of delivering a system that
does not meet these desires and needs; see Definition 1.2 in Section 1.2.
Every stakeholder has a role in the context of the system to be built—for example, Stakeholder roles
user, client, customer, operator, or regulator. Depending on the RE process used, the
developers of a system can also be stakeholders. This is frequently the case in agile
and in market-oriented development. A stakeholder may also have more than one
role at the same time. For every relevant stakeholder role, suitable people acting in
this role must be selected as representatives.
For stakeholder roles with too many individuals or when individuals are unknown, Personas
personas (fictitious characters that represent a group of users with similar
characteristics) can be defined as a substitute. For systems that are already in use,
users who provide feedback about the system or ask for new features should also be
considered as stakeholders.
It makes sense to classify the stakeholders into three categories with respect to the Classifying stakeholders
degree of influence that a stakeholder has on the success of the system:
Critical: not considering these stakeholders will result in severe problems
and probably make the system fail or render it useless.
Major: not considering these stakeholders will have an adverse impact on
the success of the system but not make it fail.
Minor: not considering these stakeholders will have no or minor influence on
the success of the system.
Handbook for the CPRE Certified Professional for Requirements Engineering
Foundation Level - Version 1.0.0 Page 15/139
This classification is helpful when assessing the criticality of a requirement (see
Figure 2.1) and when negotiating conflicts between stakeholders (see below).
It is not sufficient to consider only the requirements of end users and customers. Considering only end
Doing this would mean that we might miss critical requirements from other users and customers
stakeholders, which can easily lead to development projects that fail or overrun their does not suffice
budgets and deadlines.
Involving the right people in the relevant stakeholder roles is crucial for successful
RE.
Practices for identifying, prioritizing, and working with stakeholders are discussed in
Chapter 4.
Stakeholders in different roles naturally have different viewpoints [NuKF2003] of a Stakeholders have
system to be developed. For example, users typically want a system to support their different viewpoints
tasks in an optimal way, the managers who order the system want to get it at a
reasonable cost, and the organization’s chief security officer cares primarily about the
security of the system. Even stakeholders in the same role may have different needs.
For example, in the group of end users, casual users have user interface requirements
that may differ strongly from those of professional users.
As a consequence, it is not sufficient to just collect requirements from stakeholders. Managing
It is vital to identify inconsistencies and conflicts between the requirements of inconsistencies and
different stakeholders and to resolve these, be it by finding a consensus, by conflicts
overruling, or by specifying system variants for stakeholders who factually have
different needs; see Section 4.3.

Principle 3 – Shared understanding: Successful systems development is impossible

without a common basis
System development, including RE, is a multi-person endeavor. To make such an The need for shared
endeavor a success, the people involved need a shared understanding of the problem understanding
and the requirements that stem from it [GlFr2015].
RE creates, fosters, and secures shared understanding between and among the parties
involved: stakeholders, Requirements Engineers, and developers. We distinguish
between two forms of shared understanding:
Explicit shared understanding is achieved through carefully elicited, Explicit and implicit
documented, and agreed requirements. This is the primary goal of RE in shared understanding
plan-driven processes.
Implicit shared understanding is based on shared knowledge about needs,
visions, context, etc. In agile RE, when requirements are not fully specified in
writing, reliance on implicit shared understanding is key.
Both implicit and explicit shared understanding may be false, meaning that people
believe that they have a shared understanding of an issue but in fact interpret this
issue in different ways. Therefore, we can never rely blindly on shared understanding.
Instead, the task of RE is to create and foster shared understanding and also secure
it—that is, assess whether there is a true shared understanding. To limit the effort
involved, it is vital to concentrate on shared understanding about relevant things—
that is, those aspects that lie within the context boundary of a system (cf. Principle 4).
Even with a perfect shared understanding, important requirements may still be
missed because nobody considered them. Figure 2.2 illustrates different situations of
shared understanding with a simple example of a couple that wants to install a swing
in their garden for their children [Glin2019]. The sticky note in the middle symbolizes
a written specification.
Handbook for the CPRE Certified Professional for Requirements Engineering
Foundation Level - Version 1.0.0 Page 16/139
 Figure 2.2 Different situations of shared understanding—illustrated with an example of a
couple that wants to install a swing for their children

Proven practices for achieving shared understanding include working with glossaries Achieving shared
(Section 3.5), creating prototypes (Section 3.7), or using an existing system as a understanding in RE
reference point.
The main means for assessing true explicit shared understanding in RE is thoroughly Assessing shared
validating all specified requirements (cf. Principle 6 and Section 4.4). Practices for understanding in RE
assessing implicit shared understanding include providing examples of expected
outcomes, building prototypes, or estimating the cost of implementing a requirement.
The most important practice for reducing the impact of false shared understanding is
using a process with short feedback loops (Chapter 5).
There are factors that constitute enablers or obstacles of shared understanding. For Enablers and obstacles
example, enablers are:
Domain knowledge
Domain-specific standards
Previous successful collaboration
Existence of reference systems known by all people involved
Shared culture and values
Informed (not blind!) mutual trust
Obstacles are:
Geographic distance
Supplier-customer relationship guided by mutual distrust
Outsourcing
Regulatory constraints
Large and diverse teams
High turnover among the people involved
The lower the probability and impact of false shared understanding and the better Relying on shared
the ratio between enablers and obstacles, the more RE can rely on implicit shared understanding
understanding. Conversely, the fewer enablers and the more obstacles to shared
understanding we have and the higher the risk and impact of false shared under-
standing for a requirement, the more such requirements have to be specified and
validated explicitly.

Handbook for the CPRE Certified Professional for Requirements Engineering

Foundation Level - Version 1.0.0 Page 17/139
Principle 4 – Context: Systems cannot be understood in isolation
Requirements never come in isolation. They refer to systems that are embedded in a
context. While the term context in general denotes the network of thoughts and
meanings needed for understanding phenomena or utterances, it has a special
meaning in RE.
DEFINITION 2.1. CONTEXT (IN RE): The part of a system’s environment being relevant for Context
understanding the system and its requirements.
The context of a system is delimited by the system boundary and the context
boundary [Pohl2010] (see Figure 2.3).
DEFINITION 2.2. CONTEXT BOUNDARY: The boundary between the context of a system and Context boundary
those parts of the application domain that are irrelevant for the system and its
requirements.
The context boundary separates the relevant part of the environment of a system to
be developed from the irrelevant part—that is, the part that does not influence the
system to be developed and, thus, does not have to be considered during
Requirements Engineering.
DEFINITION 2.3. SYSTEM BOUNDARY: The boundary between a system and its System boundary
surrounding context.
The system boundary delimits the system as it shall be after its implementation and
deployment. The system boundary is often not clear initially and it may change over
time. Clarifying the system boundary and defining the external interfaces between a
system and the elements in its context are genuine RE tasks.
The system boundary frequently coincides with the scope of a system development.
DEFINITION 2.4. SCOPE: The range of things that can be shaped and designed when Scope
developing a system.
Sometimes, however, the system boundary and its scope do not match (see Figure
2.3). There may be components within the system boundary that have to be reused
as they are (i.e., they cannot be shaped or designed), which means that they are out of
scope. On the other hand, there may be things in the system context that can be re-
designed when the system is developed, which means that they are in scope.
It is not sufficient to consider just the requirements within the system boundary.
First, when the scope includes parts of the system context, as shown in Figure 2.3, Considering context
context changes within the scope may impact the system’s requirements. For changes in RE
example, when a business process shall be partially automated by a system, it may be
useful to adapt the process in order to simplify its automation. Obviously, such
adaptation impacts the requirements of the system.

Handbook for the CPRE Certified Professional for Requirements Engineering

Foundation Level - Version 1.0.0 Page 18/139
 Figure 2.3 System, context, and scope

Second, there may be real-world phenomena in the system context that a system shall Mapping real-world
monitor or control. Requirements for such phenomena must be stated as domain phenomena
requirements and must be adequately mapped to system requirements. For example,
in a car equipped with an automatic gearbox, there is a requirement that the parking
position can be engaged only when the car is not moving. In the context of a software
system that controls the gearbox, this is a domain requirement. In order to satisfy this
requirement, the controller needs to know whether or not the car is moving.
However, the controller cannot sense this phenomenon directly. Hence, the real-
world phenomenon “car is not moving” must be mapped to a phenomenon that the
control system can sense—for example, input from a sensor that creates pulses when
a wheel of the car is spinning. The domain requirement concerning engaging the
parking position is then mapped to a system requirement such as “The gearbox
control system shall enable the engagement of the parking position only if no pulses
are received from the wheel spinning sensors.”
Third, there may be requirements that cannot be satisfied by any system Domain requirements
implementation unless certain domain requirements and domain assumptions in the and domain
context of the system hold. Domain assumptions are assumptions about real-world assumptions
phenomena in the context of a system. For example, consider an air traffic control
system (ATS). The requirement “R1: The ATS shall maintain accurate positions for all
aircraft controlled by the system” is an important system requirement. However, this
requirement can be met only if the radar in the context of the ATS satisfies the
requirements of correctly identifying all aircraft in the airspace controlled by the
radar and correctly determining their position. In turn, these requirements can be
satisfied only if all aircraft spotted by the radar respond properly to the interrogation
signals sent by the radar.
Furthermore, requirement R1 can be met only if certain domain assumptions in the
context of the ATS hold—for example, that the radar is not jammed by a malicious
attacker and that no aircraft are flying at an altitude that is lower than the radar can
detect.
RE goes beyond considering the requirements within the system boundary and
defining the external interfaces at the system boundary. RE must also deal with
phenomena in the system context.
Consequently, RE must also consider issues in the system context: RE has to consider the
context
If changes in the context may occur, how do they impact the requirements
for the system?
Which requirements in the real-world context are relevant for the system to
be developed?

Handbook for the CPRE Certified Professional for Requirements Engineering

Foundation Level - Version 1.0.0 Page 19/139
 How can such real-world requirements be mapped adequately to
requirements for the system?
Which assumptions about the context must hold such that the system will
work properly and the requirements in the real world will be met?

Principle 5 – Problem, requirement, solution: An inevitably intertwined triple

Problems, their solutions, and requirements are closely and inevitably intertwined Why problems,
[SwBa1982]. Every situation in which people are not satisfied with the way they are requirements, and
doing things can be considered as the occurrence of a problem. In order to eliminate solutions are
that problem, a socio-technical system may be developed and deployed. Requirements intertwined
for that system must be captured in order to make the system an effective solution to
the problem. Specifying requirements does not make sense if there is no problem to
solve or if no solution will be developed. Neither does it make sense to develop a
solution that is searching for a problem to solve or for requirements to satisfy.
It is important to note that problems, requirements, and solutions do not necessarily
occur in this order. For example, when designing an innovative system, solution ideas
create user needs that have to be worked out as requirements and implemented in an
actual solution.
Problems, requirements, and solutions can be intertwined in many ways: Forms of intertwinement
Hierarchical intertwinement: when developing large systems with a multi-
level hierarchy of subsystems and components, high-level requirements lead
to high-level design decisions, which in turn inform lower-level
requirements that lead to lower-level design decisions, etc.
Technical feasibility: specifying non-feasible requirements is a waste of
effort; however, it may only be possible to assess the feasibility of a
requirement when exploring technical solutions.
Validation: prototypes, which are a powerful means for validating
requirements, constitute partial solutions of the problem.
Solution bias: different stakeholders may envisage different solutions for a
given problem, with the consequence that they specify different, conflicting
requirements for that problem.
The intertwinement of problems, requirements, and solutions also has consequences Consequences of
for the development process for a system: intertwinement
Strictly separating RE from system design and implementation activities is
rarely possible. Therefore, strict waterfall development processes do not
work well.
Nevertheless, Requirements Engineers aim to separate problems,
requirements, and solutions from each other as far as possible when
thinking, communicating, and documenting. This separation of concerns
makes RE tasks easier to handle.
Despite the inevitable intertwinement of problems, requirements, and solutions,
Requirements Engineers strive to separate requirements concerns from solution
concerns when thinking, communicating, and documenting.

Handbook for the CPRE Certified Professional for Requirements Engineering

Foundation Level - Version 1.0.0 Page 20/139
Principle 6 – Validation: Non-validated requirements are useless
When a system is developed, the final system deployed shall satisfy the stakeholders’ Why we need early
desires and needs. However, performing this check at the very end of development is validation
very risky. In order to control the risk of unsatisfied stakeholders from the beginning,
validation of requirements must start during RE (see Figure 2.4).

Figure 2.4 Validation [Glin2019]

DEFINITION 2.5. VALIDATION: The process of confirming that an item (a system, a work Validation
product, or a part thereof) matches its stakeholders’ needs.
In RE, validation is the process of confirming that the documented requirements
match the stakeholders’ needs; in other words, confirming whether the right
requirements have been specified.
Validation is a core activity in RE: there is no specification without validation.
When validating requirements, we have to check whether: Things to validate
Agreement about the requirements has been achieved among the
stakeholders (conflicts resolved, priorities set)
The stakeholders’ desires and needs are adequately covered by the
requirements
The domain assumptions (see Principle 4 above) are reasonable—that is, we
can expect that these assumptions can be met when the system is deployed
and operated
Practices for validating requirements are discussed in Section 4.4.

Principle 7 – Evolution: Changing requirements are no accident, but the normal

case
Every technical system is subject to evolution. Needs, businesses, and capabilities Evolution is inevitable
change continuously. As a natural consequence, the requirements for systems that are
expected to satisfy needs, support businesses, and use technical capabilities will also
change. Otherwise, such systems and their requirements progressively lose their
value and eventually become useless.
A requirement may change while Requirements Engineers are still eliciting other
requirements, when the system is under implementation, or when it is deployed and
being used.
There are many reasons that lead to requests to change a requirement or a set of Reasons for changing
requirements for a system, for example: requirements

Handbook for the CPRE Certified Professional for Requirements Engineering

Foundation Level - Version 1.0.0 Page 21/139
 Changed business processes
Competitors launching new products or services
Clients changing their priorities or opinions
Changes in technology
Feedback from system users asking for new or changed features
Detection of errors in requirements or detection of faulty domain
assumptions
Requirements may also change due to feedback from stakeholders when validating
requirements, due to the detection of faults in previously elicited requirements, or
due to changed needs.
As a consequence, Requirements Engineers must pursue two seemingly contradictory Enabling change while
goals: preserving stability
Permit requirements to change, because trying to ignore the evolution of
requirements would be futile.
Keep requirements stable, because without some stability in the
requirements, the cost for change can become prohibitively high. Also,
development teams cannot develop systematically if requirements change
on a daily basis.
Requirements Engineers need to manage the evolution of requirements. Otherwise,
the evolution will manage them.
Change processes for requirements that address both goals are discussed in Section
6.7.

Principle 8 – Innovation: More of the same is not enough

While RE is concerned with satisfying the stakeholders’ desires and needs, Requirements Engineers
Requirements Engineers who just play the role of the stakeholders’ voice recorder, are not the
specifying exactly what the stakeholders tell them, are doing the wrong job. Giving stakeholders’ voice
stakeholders exactly what they want means missing out on the opportunity of doing recorders
things better than before.
For example, imagine the following scenario. An insurance company wants to renew Example of how it could
the reporting system for its agents. The most frequently used report is a table with 18 work
columns, which is about twice as wide as the screen when displayed on the agents’
laptop computers. Viewing this report thus requires a lot of scrolling. The
stakeholders therefore want to be able to zoom in the report, using plus and minus
buttons on the screen. In this situation, good Requirements Engineers will not just
record this as a requirement. Instead, they will start to ask questions. It turns out that
the company is going to replace the agents’ laptops with tablets. Hence, implementing
two-finger gestures instead of the required buttons will make zooming much easier.
Furthermore, it turns out that three columns in the report can be eliminated with a
slight change to the reporting rules, which the company agrees to make. Also, only six
columns of the report are always needed; the remaining columns are used only in
special cases.
Taking this into account, the Requirements Engineers would suggest that the
stakeholders require that (1) the report shall show the same information as in the
current system, minus the content of the three eliminated columns; (2) when the
report is opened, only the six important columns are displayed in full width, while the
other columns are collapsed to minimal width; and (3) that agents can expand a
collapsed column by tapping its header (and collapse it again with another tap).
Handbook for the CPRE Certified Professional for Requirements Engineering
Foundation Level - Version 1.0.0 Page 22/139
This way, the agents will get a system that does not simply add a workaround for
viewing an oversized report. Instead, the system will solve the agents’ problem with
an innovative feature for filtering information and will also feature an intuitive means
of zooming.
This is how innovation emerges. Good Requirements Engineers are innovation- Innovation awareness
aware: they strive not just to satisfy stakeholders but to make them happy, excited, or
feel safe [KSTT1984]. At the same time, they avoid the trap of believing that they know
everything better than the stakeholders do.
Good Requirements Engineers go beyond what their stakeholders tell them.
On a small scale, RE shapes innovative systems by striving for exciting new features Shaping innovative
and ease of use. Beyond that, Requirements Engineers also need to look for the big systems in RE
picture, exploring with the stakeholders whether there are any disruptive ways of
doing things, leading to large-scale innovation [MaGR2004].
Section 4.2 discusses several techniques for fostering innovation in RE.

Principle 9 – Systematic and disciplined work: We can’t do without in RE

RE is not an art but a discipline, which calls for RE to be performed in a systematic As a discipline, RE calls
and disciplined way. Regardless of the process(es) used to develop a system, we need for systematic and
to employ suitable RE processes and practices for systematically eliciting, disciplined work
documenting, validating, and managing requirements. Even when a system is
developed in an ad hoc fashion, a systematic and disciplined approach to RE (for
example, by systematically fostering shared understanding, see Principle 3) will
improve the quality of the resulting system.
Agility and flexibility are not valid excuses for an unsystematic, ad hoc style of work
in RE.
However, there is neither a universal RE process nor a universal set of RE practices No “one size fits all”
that work well in every given situation or at least in most situations: there is no “one
size fits all” in RE.
Systematic and disciplined work means that Requirements Engineers: What Requirements
Engineers need to do
Configure an RE process that is well suited for the problem at hand and fits
well with the process used for developing the system (see Chapter 5).
From the set of RE practices and work products available, select those that
are best suited for the given problem, context, and working environment
(see Chapters 3, 4 and 6).
Do not always use the same process, practices, and work products.
Do not reuse processes and practices from past successful RE work without
reflection.

2.3 Further Reading

Glinz [Glin2008] discusses the value of quality requirements and of requirements in

general [Glin2016].
Glinz and Wieringa [GlWi2007] explain the notion and importance of stakeholders.
Glinz and Fricker [GlFr2015] discuss the role and importance of shared
understanding.

Handbook for the CPRE Certified Professional for Requirements Engineering

Foundation Level - Version 1.0.0 Page 23/139