Requirements Engineering
Lecture 1 – Introduction
Terminology
• Requirement (IEEE):
1. A condition or capability needed by a user to solve a problem or achieve an objective
2. A condition or capability that must be met or possessed by a system or system
component to satisfy a contract, standard, specification, or other formally imposed
documents
3. A documented representation of a condition or capability as in 1 or 2
• Requirement (IREB):
1. A need perceived by a stakeholder
2. A capability or property that a system shall have
3. A documented representation of a need, capability or property
• Requirements engineer: A person who — in collaboration with stakeholders — elicits,
documents, validates, and manages requirements.
• Requirements engineering: A systematic and disciplined approach to the specification
and management of requirements with the following goals:
1. Knowing the relevant requirements, achieving a consensus among the stakeholders
about these requirements, documenting them according to given standards, and
managing them systematically,
2. Understanding and documenting the stakeholders’ desires and needs,
3. Specifying and managing requirements to minimize the risk of delivering a system
that does not meet the stakeholders’ desires and needs.
Pohl’s three dimensions of RE
• Specification
o Deals with the degree of requirements understanding
o From vague / opaque requirements . . .
o To a specification that is unambiguous, complete, verifiable, etc.
o To classified requirements (functional vs. non-functional, vital vs. desirable, etc.)
o The page should be faster → The profile page shall be loaded on any Android
v7+ device within 10ms
1
, • Representation
o Deals with how the knowledge about the system is expressed:
▪ Informal (e.g., natural language): easy to read, inherently ambiguous
▪ Semi-formal (e.g., class diagrams): provide a good overview, weak
semantics
▪ Formal (e.g., first-order logic): precise, but more system-oriented
• Agreement
o Deals with the degree of agreement reached on a specification
o From personal views on the system, to a common system spec
▪ Do the same terms mean the same concept to all stakeholders?
▪ Do the stakeholders agree on the functions to deliver?
Lecture summary
• RE is the key to software quality
• Poor RE may result in failure
Lecture 2 – Fundamentals and Processes
Fundamentals of RE
• What is RE?
o To make sure that a software solution correctly solves a given problem, we
must first correctly understand and define the problem to solve.
• RE is about… Discover, understand, formulate, analyze and agree on:
o what problem should be solved
o why such a problem needs to be solved
o who should be involved in the responsibility of solving that problem
• Problems and solutions
o RE focuses on the problem, not the solution
▪ Problem space: where the problem exists
▪ Solution space: build software
o The world: things that have an effect on our life
o The machine: solution space (payment record, as customer you don’t care, it has
no effect on their life)
o Shared phenomena: relevant both to world and machine
o RE is concerned with the machine’s effect on the surrounding world and the
assumptions we make about that world
o RE is solely concerned with world phenomena, including shared ones
▪ RE focuses on requirements and assumptions
▪ Software design focuses on machine phenomena
o E.g. assumptions are like physics laws/ that the courier will deliver the item →
not specified in system, just assume it is like this.
2
,• Systems
o A system is a set of components interacting with each other to satisfy some
global objectives
▪ intrinsically composite
▪ can be seen as a whole through the global properties emerging from
component interactions
▪ e.g. Marktplaats:
• Components: sellers, buyers, shipping companies, payment
subsystem, e-mail systems, the software for managing items and
bids, etc.
• Global properties: satisfaction of buyers getting access to items,
auction rules regulating the system, trustworthiness,
relationships
o The task of requirements engineers is to investigate the problem world:
▪ System-as-is, which exists before the machine is built;
▪ System-to-be, when the machine will be built and operated
o When we do RE, there is always a system-as-is (not always technical)
o Example (e-auction):The system-as-is is a standard auction system with no
support for electronic bidding. The system-to-be is intended to make items
biddable from anywhere at any time through Internet auctions
• The software-to-be (part of system-to-be)
o The system-to-be consists of two sub-components:
1. Software-to-be: the machine to be built
2. Environment that surrounds the software-to-be, and includes
• People and business units
• Physical devices
• Legacy software (cannot easily be changed)
• Defining RE
o Requirements Engineering: A coordinated set of activities for exploring,
evaluating, documenting, consolidating, revising and adapting the objectives,
capabilities, qualities, constraints and assumptions that the system-to-be should
meet based on
▪ problems raised by the system-as-is
▪ and opportunities provided by new technologies (generative AI, when
you want to include large language models )
• Three dimensions of RE
3
, o Why
▪ All these “whats” are there for a reason.
▪ Identify, analyze, refine the system-to-be’s objectives
• to address analyzed deficiencies of the system-as-is
• in alignment with business objectives
• taking advantage of technology opportunities
▪ Challenges:
• Acquire domain knowledge
• Evaluate alternative options (don’t commit too prematurely to
one solution)
• Evaluate technology opportunities
• Handling conflicts
▪ Example: Train control: Alternatives for satisfying avoid train collisions
→ ensure that there will never be two trains on the same block; ensure
that trains on the same block will always be separated by some worst-
case stopping distance
o What
▪ Services, constraints, assumptions about system-to-be
▪ Identify & define the system-to-be’s functional services (features)
• to satisfy the identified objectives
• according to quality constraints: security, performance, . . .
• based on realistic assumptions about the environment
▪ Challenges:
• Identify the right set of features
• Specify these precisely for understanding by all parties
• Ensure backward traceability to system objectives
▪ When you define a what, it is not just a statement of “the system should
do this”. It should also consider how well and how the functions should
be delivered.
▪ Example: library management: One key function for a library
management software is a query service. The definition of such a
function should
• be comprehensible both by library staff and by the students
• provide evidence that the objectives of increased coverage,
information accuracy and wider accessibility will be met
4
Lecture 1 – Introduction
Terminology
• Requirement (IEEE):
1. A condition or capability needed by a user to solve a problem or achieve an objective
2. A condition or capability that must be met or possessed by a system or system
component to satisfy a contract, standard, specification, or other formally imposed
documents
3. A documented representation of a condition or capability as in 1 or 2
• Requirement (IREB):
1. A need perceived by a stakeholder
2. A capability or property that a system shall have
3. A documented representation of a need, capability or property
• Requirements engineer: A person who — in collaboration with stakeholders — elicits,
documents, validates, and manages requirements.
• Requirements engineering: A systematic and disciplined approach to the specification
and management of requirements with the following goals:
1. Knowing the relevant requirements, achieving a consensus among the stakeholders
about these requirements, documenting them according to given standards, and
managing them systematically,
2. Understanding and documenting the stakeholders’ desires and needs,
3. Specifying and managing requirements to minimize the risk of delivering a system
that does not meet the stakeholders’ desires and needs.
Pohl’s three dimensions of RE
• Specification
o Deals with the degree of requirements understanding
o From vague / opaque requirements . . .
o To a specification that is unambiguous, complete, verifiable, etc.
o To classified requirements (functional vs. non-functional, vital vs. desirable, etc.)
o The page should be faster → The profile page shall be loaded on any Android
v7+ device within 10ms
1
, • Representation
o Deals with how the knowledge about the system is expressed:
▪ Informal (e.g., natural language): easy to read, inherently ambiguous
▪ Semi-formal (e.g., class diagrams): provide a good overview, weak
semantics
▪ Formal (e.g., first-order logic): precise, but more system-oriented
• Agreement
o Deals with the degree of agreement reached on a specification
o From personal views on the system, to a common system spec
▪ Do the same terms mean the same concept to all stakeholders?
▪ Do the stakeholders agree on the functions to deliver?
Lecture summary
• RE is the key to software quality
• Poor RE may result in failure
Lecture 2 – Fundamentals and Processes
Fundamentals of RE
• What is RE?
o To make sure that a software solution correctly solves a given problem, we
must first correctly understand and define the problem to solve.
• RE is about… Discover, understand, formulate, analyze and agree on:
o what problem should be solved
o why such a problem needs to be solved
o who should be involved in the responsibility of solving that problem
• Problems and solutions
o RE focuses on the problem, not the solution
▪ Problem space: where the problem exists
▪ Solution space: build software
o The world: things that have an effect on our life
o The machine: solution space (payment record, as customer you don’t care, it has
no effect on their life)
o Shared phenomena: relevant both to world and machine
o RE is concerned with the machine’s effect on the surrounding world and the
assumptions we make about that world
o RE is solely concerned with world phenomena, including shared ones
▪ RE focuses on requirements and assumptions
▪ Software design focuses on machine phenomena
o E.g. assumptions are like physics laws/ that the courier will deliver the item →
not specified in system, just assume it is like this.
2
,• Systems
o A system is a set of components interacting with each other to satisfy some
global objectives
▪ intrinsically composite
▪ can be seen as a whole through the global properties emerging from
component interactions
▪ e.g. Marktplaats:
• Components: sellers, buyers, shipping companies, payment
subsystem, e-mail systems, the software for managing items and
bids, etc.
• Global properties: satisfaction of buyers getting access to items,
auction rules regulating the system, trustworthiness,
relationships
o The task of requirements engineers is to investigate the problem world:
▪ System-as-is, which exists before the machine is built;
▪ System-to-be, when the machine will be built and operated
o When we do RE, there is always a system-as-is (not always technical)
o Example (e-auction):The system-as-is is a standard auction system with no
support for electronic bidding. The system-to-be is intended to make items
biddable from anywhere at any time through Internet auctions
• The software-to-be (part of system-to-be)
o The system-to-be consists of two sub-components:
1. Software-to-be: the machine to be built
2. Environment that surrounds the software-to-be, and includes
• People and business units
• Physical devices
• Legacy software (cannot easily be changed)
• Defining RE
o Requirements Engineering: A coordinated set of activities for exploring,
evaluating, documenting, consolidating, revising and adapting the objectives,
capabilities, qualities, constraints and assumptions that the system-to-be should
meet based on
▪ problems raised by the system-as-is
▪ and opportunities provided by new technologies (generative AI, when
you want to include large language models )
• Three dimensions of RE
3
, o Why
▪ All these “whats” are there for a reason.
▪ Identify, analyze, refine the system-to-be’s objectives
• to address analyzed deficiencies of the system-as-is
• in alignment with business objectives
• taking advantage of technology opportunities
▪ Challenges:
• Acquire domain knowledge
• Evaluate alternative options (don’t commit too prematurely to
one solution)
• Evaluate technology opportunities
• Handling conflicts
▪ Example: Train control: Alternatives for satisfying avoid train collisions
→ ensure that there will never be two trains on the same block; ensure
that trains on the same block will always be separated by some worst-
case stopping distance
o What
▪ Services, constraints, assumptions about system-to-be
▪ Identify & define the system-to-be’s functional services (features)
• to satisfy the identified objectives
• according to quality constraints: security, performance, . . .
• based on realistic assumptions about the environment
▪ Challenges:
• Identify the right set of features
• Specify these precisely for understanding by all parties
• Ensure backward traceability to system objectives
▪ When you define a what, it is not just a statement of “the system should
do this”. It should also consider how well and how the functions should
be delivered.
▪ Example: library management: One key function for a library
management software is a query service. The definition of such a
function should
• be comprehensible both by library staff and by the students
• provide evidence that the objectives of increased coverage,
information accuracy and wider accessibility will be met
4
