lecture: requirements engineering ws 2018/2019 · crowdsourcing as a model for problem solving: an...

© Fraunhofer IESE

Lecture:Requirements EngineeringWS 2018/2019

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

9

„Satzschablone“ of Chris Rupp (Controlled NL)

© Fraunhofer IESE

10

Sentence Pattern in English…

© Fraunhofer IESE

11

Topics

Conceptual Modeling

Requirements Analysis

Goal Modeling

UML

© Fraunhofer IESE

12

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

13

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

14

Topics

Elicitation

Communication Model

Stakeholder Analysis

Interviews

Creativity Techniques

© Fraunhofer IESE

15

Objective Reality

PerceivedReality

Perception

Expression

Representation Interpretation

Personal Reality

Stakeholder Requirements Engineer

Representation

DocumentedExpression

Communication Model (Extended Version)

© Fraunhofer IESE

16

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

17

Example: Stakeholder Onion Model

© Fraunhofer IESE

18

Principles of Creativity

Preexistingassociations

Newassociations

Free associationStruct. associationIntuition triggered

Concept formationAbstractionReductionAnalysisArgumentationConfrontationEmpirical eval.

AlienationAnalogyInductionTransferAdaptionAnalysisAbstractionReduction

InferenceReformulationForgetting Transformation Combination

Evaluation

Exploration

© Fraunhofer IESE

19

Topics

Validation & Negotiation

Quality Assurance Basics

Inspections (for Verification)

Prototypes (for Validation)

Requirements Negotiation

Summary

© Fraunhofer IESE

20

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

21

Example: Lo-Fi BTB Prototype with Changes

© Fraunhofer IESE

22

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

23

Topics

Reqirements Management

Change Management

Traceability

Tool support

Prioritization

© Fraunhofer IESE

24

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

25

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

26

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

27

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

28

Topics

Informationsystems

Task-Orientation (TORE)

Context Analysis

Business Process & Data Analysis

Personas

Business Processes

Use Cases

Agile RE

© Fraunhofer IESE

29

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

30

Logical Phases in Information Systems RE (1)

Stakeholder Project GoalsAddressed

Tasks & ProcessesProject Topic



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

31

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


RoleIT System

Product

ActivityDocument Role

IT System

Risk

Event

Event

Activity

Event


© Fraunhofer IESE

32

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

33

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

35

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

© Fraunhofer IESE

37

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

38

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

39

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,

© Fraunhofer IESE

40

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

41

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!

© Fraunhofer IESE

42

Thank you for attending this lecture!

Now: Your feedback for optimizing the lecture is appreciated

what was good…

what should be improved…