REQUIREMENTS ENGINEERING

LECTURE 2016/2017

Dr. Jörg Dörr

Introduction

© Fraunhofer IESE
The ReqMan Framework (2013)

Specialized for IS Domain

© Fraunhofer IESE
RE-Process – Abstract Overview

Source: Houdek, RE in Master SE for ES

© Fraunhofer IESE
 Motivation & Overview

ROLE OF COMMUNICATION

© Fraunhofer IESE
Requirements Engineering can Avoid Typical Problems

 Non-consideration of stakeholders
 Unclear or missing requirements
 Insufficient documentation and (change) management of requirements
 Insufficient negotiation
 Missing distinction of requirements and design decisions
 Insufficient relationship with testing activities

© Fraunhofer IESE
But Why is Requirements Engineering Still So
Problematic?

 Customers expect fast delivery of final product („no time for

requirements!“)
 Stakeholder assume that many requirements are clear and do not have to
be discussed (implicit requirements)
 Communication problems due to different expectations and background
knowledge
 …

© Fraunhofer IESE
The Importance of Communication...

© Fraunhofer IESE
The Role of Communication

 Language is the most important means for communication in RE

 Common glossary is essential
 Similar backgrounds facilitate communication
 Media must fit the project context
 Filtering and transformation of information affect effective
communication

 Requirements Engineer is mediator between the „worlds“

10

© Fraunhofer IESE
 Communication Model

Stakeholder Requirements Engineer

Perception Representation Interpretation Representation

Objective Perceived Expression Personal Documented

Reality Reality Reality Expression

11

© Fraunhofer IESE
Characteristics of a Good Requirements Engineer

 Analytic thinking
 Empathy
 Communication skills
 Conflict resolution skills
 Moderation skills
 Self-confidence
 Persuasiveness

 Domain knowledge
 Technical knowledge (inkl. SE Knowledge)

12

© Fraunhofer IESE
 Motivation & Overview

REQUIREMENTS TYPES

13

© Fraunhofer IESE
Requirements Types

 Functional Requirements
 A requirement concerning a result of behavior that shall be provided by
a function of a system (or a component or service).
 Quality Requirements
 A requirement that pertains to a quality concern that is not covered by
functional requirements.
 Constraints
 A requirement that limits the solution space beyond what is necessary
for meeting the given functional requirements and quality
requirements.
 Non-functional Requirements
 Quality Requirements + Constraints
14

Note: Some publications consider non-functional requirements as quality requirements only.

© Fraunhofer IESE
The Importance of Quality Requirements

 Quality requirements are essential for product / project success

 Quality requirements enable

 well-founded design decisions
 subcontracting
 early quality assurance
 differentiation at the market

 Neglecting quality requirements can cause

 low product quality
 costly rework
 delivery problems
and finally a loss of reputation
15

© Fraunhofer IESE
Types of Quality Requirements (ISO 9126)

 Security and Accuracy

 Reliability
 Usability
 Efficiency
 Modifiability
 Portability

16

© Fraunhofer IESE
Types of Quality Requirements (ISO 25010)

 Quality in Use (relative to human use)  Product Quality (intrinsic)

 Effectiveness  Functional Suitability
 Efficiency  Performance Efficiency
 Satisfaction  Compatibility
 Freedom of Risk  Usability
 Context Coverage  Reliability
 Security
 Maintainability
 Portability

17

© Fraunhofer IESE
In any Case…

 Quality requirements should be described in a quantified or operationalized

way!

 Bad examples
 The system shall be highly reliable.
 The system shall be secure.

 Better examples
 The system shall have an availability of 99,5% on average a year with a
maximum downtime of 4 hours. (Quantification)
 The system shall allow only authenticated and authorized users an access.
Authentication shall be made with an user name and a password of at least
8 characters. (Operationalization)
18

© Fraunhofer IESE
Reference Objects for Requirements

 Typically, requirements do not address a system as a whole but logical or

physical parts of the system
 Functions
 Components
 Data concerns
Requirement Reference Object
…
or the supported context has
 Users
 Tasks & processes Stakeholder
 Goals
…
 Reference objects define discussion topics and a logical order among them
19

© Fraunhofer IESE
Reference Objects

 support completeness
 decisions regarding reference objects must always be made in a project
 the only questions is whether this is done implicitly or explicitly
 support focusing
 it is neither meaningful nor possible to address all aspects at the same
time
 define requirements classes
 e.g., user interface requirements, business process requirements, data
requirements, …

20

© Fraunhofer IESE
Task-Oriented Requirements Engineering (TORE)

 Task-oriented Requirements Engineering (TORE) takes stakeholder and

their tasks as reference objects for starting the requirements analysis

 Idea:
 System development should be driven and motivated by (business) tasks
to be supported
 Each system capability / property can be traced back to them
 not more or less functionality than actually needed
 Goal achievement can be assured constructively
 Facilitates communication between stakeholders and developers

21

© Fraunhofer IESE
The TORE Framework

Requirements Decisions

Goal & Supported Stakeholder‘s Stakeholder‘s

Task Level Stakeholders Goals Tasks

Domain
System
Level As-is Activities To-be Activities
Responsibilities
Domain Data

Interaction
Level System Functions Interactions Interaction-Data UI-Structure

System
Level GUI Navigation/
Dialog UI-Data Screen-Structure
Supported Functions

Application Core
Internal Actions Architecture Internal Data

22

© Fraunhofer IESE
 Motivation & Overview

REQUIREMENTS ENGINEERING
IN DEVELOPMENT APPROACHES
23

© Fraunhofer IESE
Development Approaches

 (Rational) Unified Process

 INCOSE
 NASA Handbook
 Scrum
 XP
 …

24

© Fraunhofer IESE
Unified Process

25

© Fraunhofer IESE
INCOSE Systems Engineering Handbook

Source: Incose Systems Engineering Handbook, Version 2.0

26

© Fraunhofer IESE
NASA Systems Engineering Handbook

Source: NASA Systems Engineering Handbook, December 2007

27

© Fraunhofer IESE
Scrum

28

Source: ADM 2002

© Fraunhofer IESE
XP - Practices

Common
Acceptance Ownership
Test

Unit Test

On-Site Simple Design Refactoring Planning

Customer Game

Pair Programming

Metaphor
Programming
Short Increments Standards
40 hour week
Continuous Integration
29

© Fraunhofer IESE
Questions

30

© Fraunhofer IESE