© Fraunhofer IESE

REQUIREMENTS ENGINEERINGLECTURE 2016/2017

Dr. Joerg Doerr

Information Systems RE

© Fraunhofer IESE

2

AGENDA

Basics

Context Analysis

Business Process & Data Modeling

BPMN

EPC

UML

Use Case Analysis

Specific Challenges & Aspects

© Fraunhofer IESE

3

BASICSInformation Systems RE

© Fraunhofer IESE

4

What is an Information System?

An information system is a collection of hardware, software, data, people and procedures that work together to produce quality information.

An information system commonly refers to a basic computer system but may also describe a telephone switching or environmental controlling system. Information systems involves resources for shared or processed information, as well as the people who manage the system. People are considered part of the system because without them, systems would not operate correctly.

Information systems are used to integrate and streamline business processes across organizational and geographical borders and to (partially) automate the input, storage, transmission, and transformation of business data.

© Fraunhofer IESE

5

How would you Elaborate the Requirements for an Information System?

© Fraunhofer IESE

6

Generic RE Process according to Core Activities

Elicitation DocumentationVerification &

Alignment

Management

© Fraunhofer IESE

7

Typical Questions in Practice when Merely Adhering to the Core Activities

What do I have to elicit and describe?

In which order?

What is the right degree of detail?

How do I know when I‘m done?

Who can contribute which information?

Where do I have to write certain information down?

© Fraunhofer IESE

8

Reference Objects for Requirements

Requirement

Stakeholder

Reference Object

has

concerns

Reference objects defines topics for which stakeholders have to make decisions regarding the design of a system ( decision points).

Reference objects defines topics for which stakeholders have to make decisions regarding the design of a system ( decision points).

Decision Point

addresses

© Fraunhofer IESE

9

Reference Objects & Decision Points…

support completeness

Decisions have always to be done in a project, either implicitly or explicitly. By keeping concrete reference objects in mind, corresponding decisions can be done explicitly and, thus, by stakeholder agreement rather than developers’ decisions.

support focusing & responsibility assignment

It is neither meaningful nor possible to discuss about all reference objects with all stakeholders at one point in time. Thus, by covering different decision points / reference objects in different meetings, discussions can be done in a more targeted way.

clarify level of detail

The reference objects clarify the degree of detail for corresponding requirements and hinder stakeholders from addressing too fine-grained issues.

© Fraunhofer IESE

10

Frameworks for Information System Development (1)

Purpose

Define and logically distinguish the reference objects and decision points that should be addressed and modelled when designing an (business) information system

Main Content

Responsible roles (WHO)

Supported tasks / functions / activities (WHAT)

Developed products / achieved goals (WHY)

Processed data and information (WITH WHAT)

Conducted processes / applied rules (HOW)

Triggers / events (WHEN)

© Fraunhofer IESE

11

Frameworks for Information System Development (2)

Examples

ARIS House (by A.-W. Scheer)

Zachman Framework (by J. Zachman)

TORE Framework (by B. Paech, K. Kohler, continuously enhanced by Fraunhofer IESE)

1. Scheer, A.-W.: ARIS – Modellierungsmethoden, Metamodelle, Anwendungen. 4. Auflage. Springer, 2001

2. Zachman, J. A.: A framework for information systems architecture. In: IBM Systems Journal. 26, Nr. 3, 1987

© Fraunhofer IESE

12

ARIS House (1)

WHO

WHAT

WHY

WITH WHAT

HOW

© Fraunhofer IESE

13

ARIS House (2)

IT Concept

Business Concept

Implementation

Business Concept

IT Concept

Implementation

Business Concept

IT Concept

Implementation

Business Concept

IT Concept

Implementation

Business Concept = Requirements

© Fraunhofer IESE

14

Zachman Framework

Copyright © 2013 Cambridge Technical Communicators

© Fraunhofer IESE

15

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

16

Task-oriented Requirements Engineering (TORE)

Idea:

System development should be driven from the goals to be achieved and tasks to be supported

Each system property can be motivated via step-wise refinement

not more or less than necessary

Assures a constructive achievement of (business) goals

Enables traceability as well as better communication between business and IT departments

Task-oriented Requirements Engineering (TORE) takes the stakeholders and their tasks & processes as the starting point for the requirements development.

Task-oriented Requirements Engineering (TORE) takes the stakeholders and their tasks & processes as the starting point for the requirements development.

© Fraunhofer IESE

17

Decision Points at the Project Level

What is the overall topic of the project?

Who are the stakeholders (e.g., departments, role, persons, etc.) that are affected by this topic?

Which goals is the project supposed to achieve? What should be the benefit at the end?

Which business processes and tasks are to be analyzed and addressed in the context of the project?

© Fraunhofer IESE

18

Decision Points at the Business Level

How are the business processes and tasks currently performed? What are their strengths and weaknesses?

How should the business processes and tasks be performed in the future in order to be able to achieve the project goals?

Which parts / steps of the to-be business processes and tasks should be supported or even automated by the system to be developed?

Which data and rules are relevant in the considered business processes and tasks?

© Fraunhofer IESE

19

Decision Points at the Interaction Level

How should users or external systems interact with the system to be developed for achieving the results of certain steps in the business processes?

Which system functions are needed for realizing the system responsibilities or interactions?

Which data are exchanged in these interactions?

How should data and system functions be grouped logically within the user interface? How should data be grouped within a document?

© Fraunhofer IESE

20

Simplified RE Process for Information Systems

The decision points do not prescribe a concrete RE process, but a simplified sequence of requirements development steps for information systems.

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

© Fraunhofer IESE

21

Interweaving with RE Core Activities

Elicitation and documentation is done “en bloc” for each decision point, e.g.,

Verification & Alignment is done at certain quality gates, e.g.,

Management is done continuously in parallel

Elicitation of To-be (Process)

Situation

Documentation of To-be (Process) Situation

Elicitation of System

Responsibilities

Documentation of System

Responsibilities

Documentation of As-is

(Process) Situation

Verification & Alignment of As-is (Process)

Situation

Elicitation of To-be (Process)

Situation

© Fraunhofer IESE

22

Strategies for Conducting Requirements Development

Sequential (Waterfall)

Parallel

Incremental

© Fraunhofer IESE

24

Sequential Requirements Development

AddressedTasks & Processes

As-is (Process) Situation

To-be (Process) Situation

System Responsibilities

System Functions

Complete requirements document at the end of the process.Easy to perform.

The larger the project, the later development can start.Inflexible changes.

© Fraunhofer IESE

25

Parallel Requirements Development

AddressedTasks & Processes

As-is (Process) Situation

To-be (Process) Situation

System Responsibilities

System Functions

As-is (Process) Situation

To-be (Process) Situation

System Responsibilities

As-is (Process) Situation

To-be (Process) Situation

System Responsibilities

Complete requirements document at the end of the process.Easy to perform. Fast(er).

Consolidation might be difficult. Finalization depends on the slowest branch. Inflexible changes.

© Fraunhofer IESE

26

Incremental Requirements Development

AddressedTasks & Processes

As-is (Process) Situation

To-be (Process) Situation

System Responsibilities

System Functions

As-is (Process) Situation

To-be (Process) Situation

System Responsibilities

System Functions

As-is (Process) Situation

To-be (Process) Situation

System Responsibilities

System Functions

Development can already start before requirements are complete.Stakeholders’ feedback on early implementations can be considered in subsequent increments.

Only partial requirements documents. Dependencies between increments must be considered. Crucial requirements must be addressed in the first increments.

© Fraunhofer IESE

27

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