INFORMATICS 113:�REQUIREMENTS ANALYSIS �& ENGINEERING

What is RE?

Lecture 2

Some slides in this lecture adapted from https://www.ifi.uzh.ch/en/rerg/courses/hs23/re-i.html

Announcement

• Team formation during discussion Monday
• Teams are about 4 people and all must be in same discussion section

Text questions to (562) 684-8307

2

Canvas Quiz

​

​

​

Lecture 2: Lecture 1 Review

Text questions to (562) 684-8307

3

Today’s Lecture – What is RE?

• WHY requirements?
• WHERE do we need and use requirements?
• WHAT is RE?
• HOW do we do RE?
• WHO is a requirements engineer?

Text questions to (562) 684-8307

4

Today’s Lecture – What is this course about? What is RE?

• WHY requirements?
• WHERE do we need and use requirements?
• WHAT is RE?
• HOW do we do RE?
• WHO is a requirements engineer?

Text questions to (562) 684-8307

5

A communication and understanding problem

Text questions to (562) 684-8307

6

We need to know the requirements!

• DEFINITION. Requirement –
• A need perceived by a stakeholder
• A capability or property that a system shall have
• A documented representation of a need, capability, or property

​

Note: A stakeholder is a person or organization who influences a system’s requirements or who is impacted by that system (see Lecture 5)

7

Source: M. Glinz (2020). A Glossary of Requirements Engineering Terminology, Version 2.0. International

Requirements Engineering Board (IREB).

Today’s Lecture – What is this course about? What is RE?

• WHY requirements?
• WHERE do we need and use requirements?
• WHAT is RE?
• HOW do we do RE?
• WHO is a requirements engineer?

Text questions to (562) 684-8307

8

Where do we need and use requirements?

• In principle: For any kind of system
• In particular: for software-intensive systems

​

Text questions to (562) 684-8307

9

WHERE

Terminology: What is a system?

• DEFINITION. System –
• A coherent, delimitable set of elements that – by coordinated action – achieve some purpose
• The “thing” for which stakeholders have requirements
• A system may comprise other systems
• Requirements engineering is primarily concerned with systems in which software plays a major role

Text questions to (562) 684-8307

10

Requirements occur in various forms

• System requirements – what a system shall do
• Software requirements – a subset of system requirements
• Stakeholder requirements – what stakeholders want from their perspective
• User requirements – a subset of stakeholder requirements
• Business requirements – business goals, objectives, and needs of an organization

Text questions to (562) 684-8307

11

(See Lecture 8)

Today’s Lecture – What is this course about? What is RE?

• WHY requirements?
• WHERE do we need and use requirements?
• WHAT is RE?
• HOW do we do RE?
• WHO is a requirements engineer?

Text questions to (562) 684-8307

12

Case Study

Text questions to (562) 684-8307

13

WHAT

When building such a system…

• … we need to understand the problem and agree on what to build

➡ Requirements Engineering

​

The hardest part of software engineering is building the right thing.

Text questions to (562) 684-8307

14

Typical symptoms of inadequate RE

• Rushing straight into building the system
• Communication problems between involved parties
• The assumption that requirements are self-evident
• Inadequate RE education and skills

Text questions to (562) 684-8307

15

What is Requirements Engineering (RE)?

• Since its inception in the 1970s, the notion of Requirements Engineering has evolved:
• From a purely technical definition
• to the contemporary one which focuses on satisfying stakeholders’ needs and reducing development risk.
• We illustrate this evolution with a series of definitions.

Text questions to (562) 684-8307

16

The traditional definition of RE

• DEFINITION. Requirements Engineering (RE) [Traditional] –
• The application of a systematic, disciplined, quantifiable approach to the specification and management of requirements; that is the application of engineering to requirements.*
• Metaphor: upfront engineering
• Goal: complete, unambiguous requirements prior to design
• Smells: paper, process
• Reality check: Does this always work?

17

*[Adapted from the definition of Software Engineering in IEEE 610.12-1990]

Wait a minute – it’s about customers’ needs

• DEFINITION. Requirements Engineering [Customer-oriented] –
• Understanding and documenting the customers’ desires and needs.*
• Metaphor: Customer satisfaction
• Goal: Understand the customer
• Reality check:
1. Why not just code what the customer desires and needs?
2. Who is “the customer”?

18

*[M. Glinz (1998). Neulich beim Apéro. Column in Alphacon Forum No. 6 (1998) [In German]]

Where’s the value?

• DEFINITION. Requirements Engineering [Risk-oriented] –
• Specifying and managing requirements to minimize the risk of delivering a system that does not meet the stakeholders’ desires and needs.*
• Metaphor: Balancing effort and value
• Goal: Mitigate risk

19

*[M. Glinz (2003). Requirements Engineering. Keynote at the Annual Assembly of the Special Interest Group on

Requirements Engineering of the Swiss Association for Quality. September 2003 [in German]]

Risk-based RE

“We have no time for a complete specification.”

“This is too expensive.”

“We’re agile, so rough stories suffice.”

⬆ Wrong approach�

• Right question: “How much RE do we need such that the risk of deploying the wrong system becomes acceptable?”
• Rule: The effort spent for Requirements Engineering shall be inversely proportional to the risk that one is willing to take.

Text questions to (562) 684-8307

20

A contemporary definition of RE

• DEFINITION. Requirements Engineering –
• The systematic and disciplined approach to the specification and management of requirements
• with the goal of understanding the stakeholders’ desires and needs and
• minimizing the risk of delivering a system that does not meet these desires and needs.*

21

*[M. Glinz (2020). A Glossary of Requirements Engineering Terminology, Version 2.0. International

Requirements Engineering Board (IREB). https://www.ireb.org/en/downloads/#cpre-glossary]

Today’s Lecture – What is this course about? What is RE?

• WHY requirements?
• WHERE do we need and use requirements?
• WHAT is RE?
• HOW do we do RE?
• WHO is a requirements engineer?

Text questions to (562) 684-8307

22

How do we do RE?

Four major tasks:

• Eliciting the requirements
• Analyzing and documenting the requirements
• Validating the requirements
• Managing and evolving the requirements

Text questions to (562) 684-8307

23

HOW

The requirements engineer

• Mostly a role, not a job title
• The role is part of many job functions:
• business analyst
• system analyst
• product manager
• product owner
• application engineer
• software engineer
• systems engineer
• People act as requirements engineers if they:
• elicit, document, validate and/or manage requirements,
• have in-depth knowledge of RE
• can bridge the gap between problem and potential solutions

Text questions to (562) 684-8307

24

WHO

(and others)

Why is RE important (pre-work)?

• Saves time and effort from going down the wrong path
• Most SW systems fail because of poorly done RE
• Easier to make changes in RE phase than in later phases
• Ensures SW being developed aligns with customer’s real needs
• Provides the foundation/basis/understanding for development

25

Is requirements engineering worthwhile?

Systems development is an expensive and risky business.

​

Requirements Engineering

• helps understand the problem
• reduces the risk of failure or costly modifications in later development stages
• provides a proper basis for estimating development effort and cost
• is a prerequisite for testing the developed system properly

Text questions to (562) 684-8307

26

WHY

RE reduces cost and increases benefits

Requirements Engineering contributes to:

• Reducing error and rework cost
• Managing the development risk
• Meet stakeholders’ desires and needs
• Provide reliable estimates for deadlines and cost

Text questions to (562) 684-8307

27

Canvas Quiz

​

​

​

Lecture 2: RE Definition

Text questions to (562) 684-8307

28

Summary

• Systems development is an expensive and risky endeavor
• When developing software, we need to understand the problem and agree on what to build
• The hardest part of software engineering!
• RE consists of eliciting, analyzing, documenting, validating, managing, and evolving requirements
• RE reduces cost and helps ensure we meet stakeholders’ desires and needs

Text questions to (562) 684-8307

29

For Next Time

• Complete Lecture 3 Pre-Work: Case Study Questions
• Attend discussion Monday for team formation

30