© Fraunhofer IESE

Lecture:Requirements EngineeringWS 2016/2017

Summary

Dr. Joerg Doerr

© Fraunhofer IESE

2

Reflecting on RE …

© Fraunhofer IESE

3

Topics

Basics of RE

Definitions

Phases

Standards

© Fraunhofer IESE

4

Activities of Requirements Engineering

Elicitation

Identifying, gathering and consolidating of requirements from different sources and stakeholders

Specification

Systematically representing the elicited requirements in a certain quality

Validation & Negotiation

Checking whether the specified requirements reflect the actual stakeholder needs / goals / expectations

Management

Managing the existing requirements and their specifications over time

Note: Some publications distinguish five instead of four activitiesand add the analysis as an own activity.

© Fraunhofer IESE

5

Requirements Document Standards (2)

Standards tackle different levels of abstraction:

Problem Clarification

IEEE 1362-1998

Volere Template

Basis for Development

IEEE 830-1998

Volere TemplateProblem

description

Developerrequirements

Userrequirements

IEEE 1362-1998Volere

IEEE 830-1998Volere

© Fraunhofer IESE

6

Topics

Specification & Natural Language Requirements

Standards

Natural Language (Styleguide, Scenarios)

Use Cases

Sentence Pattern

© Fraunhofer IESE

7

Characteristics of Good Requirements (Documents) according to IEEE 830

correct

unambiguous (only one possible interpretation)

complete (all functional and non-functional requirements, all system reactions and unintended inputs are specified)

consistent (no inconsistencies, consistent use of terminology)

ranked for importance

verifiable (measurable and „testable“)

modifiable (clear structure, overview, no redundancy)

traceable (to design/test but also internally in user/developer documents)

(understandable)

© Fraunhofer IESE

8

Writing Guidelines for Requirements

Goal: Natural Language Requirements are easier to read and therefore easier to understand

Writing guidelines consider common problems, project-specific additions may be useful

Guidelines should be summarized into company-specific writing guidelines

© Fraunhofer IESE

12

„Satzschablone“ of Chris Rupp (Controlled NL)

© Fraunhofer IESE

13

Sentence Pattern in English…

© Fraunhofer IESE

14

Topics

Conceptual Modeling

Requirements Analysis

Goal Modeling

UML

© Fraunhofer IESE

15

Requirements Analysis as Part of Specification

Requirements Analysis is performed in order to analyze certain quality characteristics of requirements

Is Requirements Analysis then synonym to requirements V&V?

No! Analysis is concerned with an incomplete set of requirements, not discussed by the stakeholder. Requirements Analysis can be a very early activity.

Requirements validation should have a complete, agreed upon set of requirements as input. Therefore, it is also regarded as part of the specification.

© Fraunhofer IESE

16

Conceptual Modeling

Conceptual Modeling is performed by the requirements engineer (analyst) to understand the problem domain and the requirements.

Various models can be created to find out whether a problem domain or the requirements are understood well, i.e., whether the understanding of the requirements engineer is complete, consistent, and correct:

Goals

Data

Interaction

Structure

…

Note: The models created during conceputal modeling are not necessarily part of the requirements specification. But they can be part of the requirements specification.

© Fraunhofer IESE

17

Topics

Elicitation

Communication Model

Stakeholder Analysis

Interviews

Creativity Techniques

© Fraunhofer IESE

18

Objective Reality

PerceivedReality

Perception

Expression

Representation Interpretation

Personal Reality

Stakeholder Requirements Engineer

Representation

DocumentedExpression

Communication Model (Extended Version)

© Fraunhofer IESE

19

Importance

Influence

A B

C D

1

1

2

2

3

4

4

5

5

e.g., User

e.g., Customer

e.g., Project Manager

e.g., Developer

e.g., Support Service

© Fraunhofer IESE

20

Example: Stakeholder Onion Model

© Fraunhofer IESE

21

Principles of Creativity

Preexistingassociations

Newassociations

Free associationStruct. associationIntuition triggered

Concept formationAbstractionReductionAnalysisArgumentationConfrontationEmpirical eval.

AlienationAnalogyInductionTransferAdaptionAnalysisAbstractionReduction

InferenceReformulationForgetting Transformation Combination

Evaluation

Exploration

© Fraunhofer IESE

22

Topics

Validation & Negotiation

Quality Assurance Basics

Inspections (for Verification)

Prototypes (for Validation)

Requirements Negotiation

Summary

© Fraunhofer IESE

23

Benefit of Perspective-Based Reading

Document with Errors

Low Overlap,High Coverage

Non-Perspective-Based Reading Perspective-Based Reading

High Overlap,Low Coverage

© Fraunhofer IESE

24

Example: Lo-Fi BTB Prototype with Changes

© Fraunhofer IESE

25

Requirements Negotiation

What:

Gaining a common and agreed-upon understanding of the requirements of the system to be developed among all stakeholders

When needed:

If there is no consent but a conflict among the stakeholders regarding the requirements (and as soon as this has been detected!)

E.g., „The system shall restart in case of failure“ vs. „The system shall shut down in case of failure“

Why needed:

If a contradiction / conflict is not resolved, the requirements of least one group of stakeholders are not fully satisfied

Resolving contradictions by negotiation increases overall acceptance!

© Fraunhofer IESE

26

Topics

Reqirements Management

Change Management

Traceability

Tool support

Prioritization

© Fraunhofer IESE

27

Activities of a Change Control Board

Receive change requests

Perform an impact analysis (consequences, effort, costs)

Review the change request accordingly

Accept or rejects the change request

Identify the necessary change measures (corrective, adaptive, hotfix)

Define requirement changes or new requirements

Prioritize and implements/plans the change

Control and validate the applied changes

© Fraunhofer IESE

28

Change Process

1. Requesting a change

2. Assessment of changes

E.g., reviewing traceability data

3. Acceptance and planning of changes

4. Realization of changes and validation

Core rules

Nobody changes requirements without approval for that change

This also goes for the project leader and requirements engineer

Change processes only apply to validated configurations/baselines

© Fraunhofer IESE

29

Classification of Traceability Relations

Vertical traceability

Artifacts from before or after the requirements specification (RS)

Pre-RS traceability: links between requirements and artifacts that are the basis for the requirements (origin)

Post-RS traceability: links between requirements and artifacts of subsequent development activities (realization)

E.g.: component, implementation, test cases

Horizontal traceability

Traceability between requirements

Mapping dependencies between requirements

Refinement, exclusion, alternative, …

© Fraunhofer IESE

30

Ad-Hoc Prioritization Techniques

Ranking technique

Top-ten technique

Single-criterion classification

E.g., mandatory, optional, nice-to-have

Kano classification

Likert scale

Cumulative voting

Hierarchical Cumulative Voting (HCV)

© Fraunhofer IESE

31

Analytical Prioritization Techniques

Analytical hierarchy process (AHP)

Cost-value-analysis

Quality function deployment (QFD)

Wiegers’ prioritization matrix

© Fraunhofer IESE

34

Cumulative Voting Method

100 points are distributed over the requirements

Advantages

Easy and fast to carry out

More differentiated evaluation than with the Likert scale method

The value “0” can be assigned

Disadvantages

Limited comprehensibility with high number of requirements and flat requirements hierarchy

Sa

b

aS

ii

n

i i

1

Punkte

Anf1: Das Tool soll kursive Schrift unterstützen. 30Anf2: Das Tool soll fette Schrift unterstützen. 40

Anf3: Das Tool soll farbige Schrift unterstützen. 0

Summe 70Rest 30

© Fraunhofer IESE

35

Hierarchical Cumulative Voting (1)

Cumulative voting across several requirement levels (for example abstraction levels)

Advantages

Improves comprehensibility

Abstraction levels are considered

Good results

Disadvantages

Ideally, lower levels should completely describe the higher levels

Punkte Punkte

Schriftart 70Anf1: Das Tool soll kursive Schrift unterstützen. 30Anf2: Das Tool soll fette Schrift unterstützen. 40

Farben 30Anf3: Das Tool soll farbige Schrift unterstützen. 0

Summe 100 70Rest 0 30

© Fraunhofer IESE

41

Topics

Informationsystems

Task-Orientation (TORE)

Context Analysis

Business Process & Data Analysis

Personas

Business Processes

Use Cases

Agile RE

© Fraunhofer IESE

42

The TORE Decision Framework (Version 2013 for BIS)

StakeholdersProject Level

Business Level

InteractionLevel

As-is (Process) Situation

To-be (Process) Situation

System Responsibilities

Business Data & Rules

System FunctionsInteractionsInteraction Data

& RulesLogical UI Structure

System Level

Requirements-relevant decisions for BIS

Internal Functions Internal DataSystem ArchitectureApplication Core

GUI LayoutSpecific GUI

FunctionsDialogs GUI DataGUI

Project GoalsAddressed

Tasks & ProcessesProject Topic

© Fraunhofer IESE

43

Logical Phases in Information Systems RE (1)

Stakeholder Project GoalsAddressed

Tasks & ProcessesProject Topic

As-is (Process) Situation

To-be (Process) Situation

System Responsibilities

Business Data & Rules

System Functions

InteractionsInteraction Data

& Rules

Logical GUI Structure

Step 1: Context Analysis

Step 2: Business Process & Data Analysis

Step 3: Use Case Analysis

© Fraunhofer IESE

44

EPC-Elements in the ARIS House - Overview

Functional / System

View

Product / Service View

Organizational View

DataView Control View

Who?

What?Withwhat?

Why?

How?

Role Role

Role

Role

Role

Role

Role

Organizational Unit

Organizational Unit Organizational Unit Organizational Unit

Role

Role

Data

Data

Data

Activity

Activity Activity

Activity

Domain

IT System IT SystemIT System

IT System

IT System

IT System

IT System

IT System

IT System

IT System

IT System

IT System

Product Product Product

To-be (Process) Situation

RoleIT System

Product

ActivityDocument Role

IT System

Risk

Event

Event

Activity

Event

As-is (Process) Situation

© Fraunhofer IESE

45

Use Case TemplateSSA.<Number>Name Name of the use case

Goal Goal and purpose of the use case (written as an extended user story)

Role Reference to the role that enacts the interaction

Preconditions & input data

Conditions in the system that need to/must be met for executing the use case and needed input data and input documents

DescriptionIncl. called functions and exchanged data

Process of the regular interaction

1. The actor …

2. The system …

Exceptions Behavior in case of exception; per exception one description

Alternative descriptions Alternative processes (alternatives to the previous description)

Business rules Reference to business rules that are relevant while executing the interaction

Quality requirements Quality requirements that affect the whole process or single steps within the process (interaction)

Business data & documents

Reference to all relevant business data and documents

System functions Reference to system functions that represent the steps executed by the system

Interfaces Reference to interfaces, that are accessed while executing the interaction and its steps

Results & output data Status of the system, that is valid after successfully executing the interaction and its steps, as well as output data and documents

© Fraunhofer IESE

46

User Stories

User Stories are written on sheets of paper (e.g., sticky notes) orelectronically in tools.

Front side uses a sentence pattern:„As a <<role>> I want <<function>> so that I can <<goal/rationale>>.E.g.: As a sales person I want to see the sum of my purchase so that I can pay my bill.

The rear side contains the acceptance criteria when a user story can beconsidered accepted by the stakeholders.

© Fraunhofer IESE

47

Topics

Embedded Systems

Characteristics

Cleanroom / Box Structures

4-VM

SBS

SCR

© Fraunhofer IESE

48

Embedded System Software Specification

Specification model• What does the specification contain?• What should be documented?

Logical system model• What is the system?• Where is the system boundary?• What should be considered ?

Specification processes• What steps to perform and how?• Cleanroom software engineering

• Sequence-based Specification

Specification methods• How to document?

• Tables• What language to use?

• SCR

© Fraunhofer IESE

49

Specification model

Logical System Boundary

Environment

Controller System Boundary

I(t) O(t)M(t) C(t)SOFIN OUT

REQ, NAT

Input Device Boundary

Output Device Boundary

© Fraunhofer IESE

50

Function based specification

Incremental development by refinement

Verification to check if refinement satisfies abstraction

Recursive usage in the same order

© Fraunhofer IESE

51

Sequence Response Equivalence Trace

(Empty) Null D1S Light On 2, 3T Illegal D1B Illegal D1C Illegal D1G Illegal D1D1 The security alarm is initially deactivated

Security alarm: Enumeration, Sequences of length 0 and 1

Rule: Do not extend the sequence IF

the response is “illegal” OR IF

the sequence is declared equivalent to a previous sequence

ELSE extend

© Fraunhofer IESE

52

Elements of the SCR model

Mode class State machine defined on monitored variables Equivalence class of system statesMode: Value / state of a mode classMonitored and controlled variables

Conditions Predicate (Boolean valued function) on a single system state

condition(window): (windowState = DOWN) {True, False}

Events Predicates on two system states

event(WindowMovement): [(windowState = DOWN) AND (windowState’ = UP)] {True, False}

Tables Relations between modes, events and conditions

Terms Internal to specification for complexity management Functions of monitored variables, modes or other terms

© Fraunhofer IESE

53

Topics

Crowd-RE

Crowd-Sourcing

Crowd-based RE

© Fraunhofer IESE

54

General Literature

Klaus Pohl, Requirements Engineering: Fundamentals, Principles, andTechniques, Springer, 2010 (English)

Klaus Pohl, Requirements Engineering: Grundlagen, Prinzipien, Techniken, Springer, dpunkt.Verlag, 2008 (German)

Chris Rupp, Klaus Pohl, Requirements Engineering Fundamentals: A Study Guide for the Certified Professional for Requirements Engineering Exam - FoundationLevel - IREB compliant (Englisch), 2015 (English)

Sommerville, Sawyer, Req. Engineering: A good practice Guide, Wiley, 1997 (English) Ian Sommerville, Software Engineering Addison Wesley, 1995 (English) Davis, Software Requirements, Prentice Hall, 1993 (English) Endres, Rombach, A Handbook of Software and Systems Engineering, Addison Wesley,

2003 (English) G. Versteegen et al., Anforderungsmanagement, Springer Verlag, 2004 (German) Dörr, J.; Adam, S.; Eisenbarth, M.; Ehresmann, M.; Implementing Requirements

Engineering Processes: Using Cooperative Self-Assessment and Improvement, IEEE Software, Year: 2008, Volume: 25, Issue: 3; Pages: 71 - 77

© Fraunhofer IESE

55

References – Information Systems RE

More information on BPMN: http://www.bpmn.org/

More information on TORE:http://re-magazine.ireb.org/issues/2014-4-steady-flight/tore/

Cockburn, Alistair “Writing Effective Use Cases” Addison-Wesley, 2001, ISBN: 0-201-70225-8

© Fraunhofer IESE

56

References – Embedded RE

S. Prowell et al., Cleanroom Software Engineering - Technology andProcess, Addison Wesley, 1999 (English)

Prowell, S.J.; Poore, J.H.; Foundations of sequence-based softwarespecification, IEEE Transactions on Software Engineering, Year: 2003, Volume: 29, Issue: 5, Pages: 417 - 429,

Constance L. Heitmeyer, Ralph D. Jeffords, and Bruce G. Labaw. 1996. Automated consistency checking of requirements specifications. ACM Trans. Softw. Eng. Methodol. 5, 3 (July 1996), 231-261.

© Fraunhofer IESE

57

References – Crowdsourcing / Crowd-RE

Origins of Crowdsourcing

Howe, J. (2006). The rise of crowdsourcing. Wired, 14(6).

Malone, T. W., Laubacher, R. & Dellarocas, C. (2009). Harnessing crowds: Mapping the genome of collective intelligence. MIT Sloan Research Paper No. 4732-09.

Principles of crowdsourcing

Brabham, D. C. (2008). Crowdsourcing as a model for problem solving: An introduction and cases. The International Journal of Research into New Media Technologies, 14(1), 75–90.

Surowiecki, J. (2004). The wisdom of crowds. New York: Anchor.

Lanier, J. (2010). You are not a gadget: A manifesto. New York: Alfred A. Knopf.

RE and Crowdsourcing

Sutcliffe A. & Sawyer, P. (2013). Requirements elicitation: Towards the unknown unknowns. Rio de Janeiro, Brasil: RE 2013, Research Track.

© Fraunhofer IESE

58

Fraunhofer IESE offers a lot more possibilities than this lecture:

Other lectures (e.g., product lines)

Hiwi-jobs, also in in (industry) projects

Projects

Bachelor and master theses

Seminars

And last but not least a start for your career!