20170113 - information systems re … · 2017-01-23 · a system-automated business activity can...

© Fraunhofer IESE

REQUIREMENTS ENGINEERINGLECTURE 2016/2017

Dr. Joerg Doerr

Information Systems RE -Business Process and Data Analysis

© Fraunhofer IESE

2

AGENDA

Basics

Context Analysis

Business Process & Data Modeling

EPC

BPMN

UML

Use Case Analysis

Specific Challenges & Aspects

© Fraunhofer IESE

3

Logical Phases in Information Systems RE

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

4

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

5

Example “Addressed Tasks & Processes“ (Process Map)

Travel Application

Travel Booking

Travel Expense

Accounting

Travel Reporting

© Fraunhofer IESE

6

Logical Phases in Information Systems RE

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

7

BUSINESS PROCESS & DATAANALYSIS

Information Systems RE

© Fraunhofer IESE

8

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

9

Definition Business Process

„Business processes are connected sequences of business performances with the purpose of service / product creation. Output and result of the business process is a service / product, which is requested and taken by an internal or external customer.“ [Scheer]

„Business processes are connected sequences of business performances with the purpose of service / product creation. Output and result of the business process is a service / product, which is requested and taken by an internal or external customer.“ [Scheer]

Organizational procedures with the goal of „value generation“ are central!

© Fraunhofer IESE

10

Notations / Languages for Business Process Modeling

Event-driven Process Chains (EPC) – de-facto standard, widely usedespecially in Germany

Business Process Modeling & Notation (BPMN) – official OMG standard

UML Activity Diagrams (UML AD) – generic process notation, not specific for business processes

© Fraunhofer IESE

11

EPC-Elements in the ARIS House - Overview

Functional / SystemView

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

12

Element “Event“

Description

Trigger for a certain activity, which describes a certain status more precisely (precondition)

Result which is achieved after an activity was performed (postcondition)

Labeling convention

(Information) Object + status change

Request received

© Fraunhofer IESE

13

Element “(Business) Activity“

Create request

Description

Procedure, which is done to achieve a certain state

Labeling convention

(Performance) verb + (Information) Object

© Fraunhofer IESE

14

Element “Connector“

Description

For illustrating the information / control flow

For assigning elements to activities

Labeling convention

- non -

© Fraunhofer IESE

15

Element “Operator“

AND XOROR (OR AND)

Description

For describing parallel flows (AND)

For describing decisions or options

If only ONE option is possible (XOR)

If multiple options are possible (OR)

Labeling convention

- non -

© Fraunhofer IESE

16

Element “Organizational Object“

Organizational Unit

Role

Person (Position)

Forwarder

Project Manager

Long‐distanceTrucker

Description

Responsible for the performance of certain procedures

Taken by humans

Differentiation:

Organizational Unit

Role

Position / Person

Labeling convention

- non -

© Fraunhofer IESE

17

Element “Information Object“

Description

Used for information / data storage

Used as input and output of activities

Differentiation:

Entity: structured data, e.g., dataset from DB

Document: unstructured data, e.g., delivery note on paper

Labeling convention

- non -

Document

Entity

© Fraunhofer IESE

18

Element “System“

IT System

Database

Description

Used for tools in the process

Differentiation:

IT System: software system, which is used for the performance of certain activties

Database: software system only for data storage

Labeling convention

- non -

© Fraunhofer IESE

19

Element “Product“

Product

Description

Result of an activity or an entire business process

A product can also be a service

Labeling convention

- non -

© Fraunhofer IESE

20

Element “Risk“

Description

Possible threat for a process to not achieve the intended result

Used for illustrating / highlighting problems in the process

Labeling convention

- non -

Risk

© Fraunhofer IESE

21

Big Picture of EPC Elements

ActivityPrecondition orTrigger Postcondition

Problem Executing Instance

Applied SystemConsumed Data Produced Data

Product

© Fraunhofer IESE

22

EPC Modeling Rules

Assure

being syntactically correct

being less ambiguous

modeling in more comparable / repeatable way

…

© Fraunhofer IESE

23

Rule „Start Event“

An EPC model must always begin with an event, the so called start event

In the case of mutiple start events, they must be joined by connectors

Activity 1 Event afterActivity 1

Start Event Activity 1 Event afterActivity 1

© Fraunhofer IESE

24

Rule „End Event“

An EPC model must always end with an event, the so called end event

In the case of forks, there can be multiple end events

Event before lastActivity

Last Activity

Event before lastActivity

Last Activity End Event

© Fraunhofer IESE

25

Rule „Trivial and Obligatory Events“

In general, only events should be modelled which highlight important milestones, special preconditions for subsequent business activities (i.e., events, which do not occur automatically by the execution of an upstream business activity) or possible forks in the process

Trivial events should be omitted

Event 1 Activity 1 Event 2 Activity 2 Event 3

Event 1 Activity 1

Activity 1 was performedwithout problems

Problems occured duringthe performance of

Activity 1

Activity 2 Event 3

Process will beterminated

Processterminated

© Fraunhofer IESE

26

Rule „Sequential Events and Activities“

Two events may never be directly sequenced

However, according to the previous rule, two business activities may directly be sequenced

Event 1 Event 2 Activity 1

Event 1 Activity 1 Activity 2 (withoutspecial precondition)

Event 1 Activity 1 Activity 2 (withspecial precondition)

Event 1 Activity 1 Event 2

© Fraunhofer IESE

27

Rule „Input and Output Connectors“

Each event and each business activity may not have more than one input and not more than one output connector

Event

Activity

Event

Event

Activity

Event

© Fraunhofer IESE

28

Rule „Forks“

When the control flow is split by a logical operator, the same operator must be used if the flow is joined again

Activity

Event

Event

Activity

Activity

Event

Event

Activity

© Fraunhofer IESE

29

Rule „Split Constraints“

At a split after an event, only the AND operator may be used

Event Event

Activity

Activity

Event Event

Event

ActivityActivity

Activity Activity

Event

Event Event

Activity

Activity

Event Event

Event

Activity Activity

Activity

Event

Activity

Event

Activity

Event Activity

Event Event

Event

Activity Activity

Activity

Event

Activity

Multiple Events Multiple Activities

XOR

OR

AND

© Fraunhofer IESE

30

Rule „Directed and undirected Connectors“

Information objects are connected to a business activity with a directed connector (expressing the data flow)

Organizational units, roles, positions and IT systems are connected to a business activity with an undirected connector

Activity

Input Output

Product

Activity

Input Output

Activity

Organizational Unit IT System Risk

Activity

Organizational Unit IT System RiskProduct

© Fraunhofer IESE

31

Rule „Operator Connectors“

Operators may never have multiple incoming and multiple outgoing connectors at the same time

© Fraunhofer IESE

32

Rule „Number of Performers“

Each business activity has to be cut in a way that it can be executed by one organizational unit or role at the most

Each business activity on the lowest abstraction level may only be executed by one role or position (meaning by one concrete person) and / or one IT system

However, multiple organizational units or roles can be involved (e.g., for the purpose of information, query, etc.)

Goods produced Deliver goods Goods at

customer site Goods produced Deliver goods Goods atcustomer site

ForwarderTruck DriverWarehouseman Head of Forwarder

© Fraunhofer IESE

33

Rule „Uniform Abstraction Level“

All business activities contained in a process model must be modeled on a uniform abstraction level. The more coarse-grained the responsible organizational unit, the higher the abstraction level of the process model

Goods produced Deliver goods Goods at

customer site

ForwarderGoods produced Commissionforwarder Load goods Transport goods Deliver goods Goods at

customer site

Sales Representative Truck Dirver

Goods produced Commissionforwarder Load goods Transport goods Deliver goods Goods at

customer site

Sales Representative Forwarder

© Fraunhofer IESE

34

Rule „Cut of a Business Activity“

After the execution of a business activity, a transactionally completed state should be on hand, which would have to be undone explicitly

If sequenced activities are performed by the same organizational unit / role and no forks or joins of branches occur, it should be checked if the two activities could be merged into one single activity

Goods producedSelect suitableforwarder

Forwarderselected

Send transportrequest to forwarder

Transportrequest sent to

forwarder

Sales Representative

Goods producedCommissionforwarder

Forwardercommissioned

Sales Representative

© Fraunhofer IESE

35

Rule „Independence of System-automated Activities“

A system-automated business activity can only follow a system-supported elementary business activity if it is started without human interaction within the system-supported elementary business activity, e.g., just by a timer event

However, it is allowed the other way round

Email orderreceived

Confirm receipt ofemail order Forward email order Process email order Email order

processed

ClerkEmail‐Manager

Email‐Client

© Fraunhofer IESE

36

Rule „Inspection and Decision Results“

If a business activity serves for an inspection or decision-making then the possible inspection / decision results have to be modelled explicitly with a subsequent XOR

Goods available Check goods Goods checked

Goods available Check goods

Goods OK

Goods not OK

© Fraunhofer IESE

39

Activities

An activity is work that is performed within a business process. It can be atomic (i.e., a task) or compound (i.e., a sub process)

© Fraunhofer IESE

40

Events

An Event is something that “happens” during the course of a business process. These Events affect the flow of the Process and usually have a trigger or a result. They can start, interrupt, or end the flow

© Fraunhofer IESE

42

Gateways

Gateways are elements used to control how Sequence Flows interact as they converge and diverge within a Process

All types of Gateways are diamond-shaped

Different internal markers indicate different types of behavior

All Gateways both split and merge the flow

A Gateway represents a place where control is needed

20170113 - information systems re … · 2017-01-23 · a system-automated business activity can...

Documents