© Fraunhofer IESE

REQUIREMENTS ENGINEERINGLECTURE 2018/2019

Dr. Joerg Doerr

Information Systems REUse Case Analysis

© Fraunhofer IESE

2

AGENDA

Use Case Analysis

Specific Challenges & Aspects:Agile RE

© Fraunhofer IESE

3

How can Business Processes help to Determine theSystem Requirements?

Your ideas?

© Fraunhofer IESE

4

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

5

System Boundary

„The system boundary separates the system to be developed from its environment; i.e., it separates the part of the reality that can be modified or altered by the development process from aspects of the environment that cannot be changed or modified by the development process.“ [IREB]

In the information system domain, the system boundary separates the actual software system from its context, i.e., from the business environment / working environment.

Hence, the system boundary is defined via system responsibilities, i.e., the parts of the business processes that should be supported or even automated by a software

© Fraunhofer IESE

6

Remember the Onion Model

System Context

Software System

System Context Boundary

System Boundary

© Fraunhofer IESE

7

Defining the System Boundary

When defining the system boundary, requirements engineers have to be make the following decisions

„Which activities within the business processes are automated by the system?“ system-automated activities

„Which activities within the business processes are supported by the system?“ system-supported activities

“Which (further) interfaces exist between the system and its context?”

Note:

1. The system boundary is not always stable and may shift during a project, e.g., all functions to be provided by the system may not be clear at the beginning

2. However: A complete and precise definition of the system boundary is required at the end of the RE process!

© 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

Business Data

Describe (data) objects & documents with which the business processes and tasks work

Consist of classes (e.g., „customer“) and attributes (e.g., „name“)

Do not contain technical details such as format or data base schema

Should be described at a central point in the document

Business Data & Rules

© Fraunhofer IESE

10

Examples for Business Data from Exercise

Guest

Table

Reservation

Timeslot

Meal

Waiter

© Fraunhofer IESE

11

Table

ID

Business Data Modeling with UML

UML Class Diagrams are often used to model business data and their relationships

Guest

Timeslot

Dish Waiter

orders

reserves

serves

*

1..* 1..*

1..*

0..1 1

1

Working Hours

Begin

Price

Name

© Fraunhofer IESE

12

Business Rules

Express any kind of rules on business data or business processes

Types:

facts, things that are given

restrictions, things that are not allowed

conditional actions, things that are done when something has happened

conditional facts, things that become true when something has happened

conditional calculations, things that are calculated when something has happened

Business Data & Rules

© Fraunhofer IESE

13

Examples for Business Rules from Exercise

facts, things that are given

Each table has four seats.

restrictions, things that are not allowed

Reservations for tables must be done before 5 p.m.

conditional actions, things that are done when something has happened

When a guest comes more than 30 minutes later as his / her reservation time, the reservation is automatically deleted.

conditional facts, things that become true when something has happened

When a guest visits the restaurant for more than 3 times a month, he/she is a “gold guest”.

conditional calculations, things that are calculated when something has happened

If more than 10 dishes are ordered, the guest has only to pay 50% of the price.

© Fraunhofer IESE

14

USE CASE ANALYSISInformation Systems RE

© Fraunhofer IESE

15

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

16

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

17

Use Cases…

detail the system-supported activities (SSA) in a business process

describe the desired interaction steps that users or external systems have to make for performing the SSA

act as an “anchor” for other requirements

Interactions

© Fraunhofer IESE

18

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

Goal Goal and purpose of the use case (written as an extended user story or goal (state definition))

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 (Postcondition) & 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

19

Use Case Example (Part 1)SSA.1Name Enter exemption from premium payment

Goal As a case handler I would like to process an exemption from premium payment in order to relieve a policyholder from paying his/her premiums. The system shall check the feasibility of the desired exemption from premium payment and – in case it is feasible –process the exemption automatically in order to reduce work effort and sources of error.

Role B3. Case handler

Preconditions & input data

Request for exemption from premium payment (S1)

DescriptionIncl. called functions and exchanged data

1. The actor enters to the system that s/he wants to conduct a future exemption from premium payment and enters (at the same time) the insurance number of the policy.

2. The system calls the business function for future premium exemption and checks whether any 3rd party dues are existing on the policy (P1).

3. The actor enters the following data: Request date from the request for exemption from premium payment Date of receipt of the request for exemption from premium payment (from the

optical archive) Approval of the exemption from premium payment, if no 3rd party dues are

existing or violated4. The system selects automatically the next possible date starting the exemption

from premium payment period (P2) based on the date of receipt. 5. …

Exceptions Case handler aborts the business function --> saves no data

Alternative descriptions -

…

© Fraunhofer IESE

20

Use Case Example (Part 2)

…Business rules P1: Check for 3rd party dues

P2: Term of exemption from premium payment P3: Possibility of exemption from premium payment P4: Minimum amount for exemption from premium payment according to general

insurance conditions P5: Letter of insurance intermediary

Quality requirements -

Business data & documents

D1: Data of exemption from premium payment S1: Request for exemption from premium payment S2: Letter of confirmation and copy of the letter S3: Letter of rejection and text module (depending on reason for rejection) and

copy of the letter

System functions F1. System selection of date starting the exemption from premium payment F2. Check, whether 3rd party dues are existing F3. Feasibility check of the exemption from premium payment F4. Store the data of the use case F5. Creation of letter and copy

Interfaces SST1: Printing Machine() SST2: Optical Archive ()

Results & output data Exemption from premium payment (has been accepted starting at a start date and for a specific period) or (has been rejected)

Letter of (confirmation and copy) or (rejection with text module according to reason for rejection and copy)

© Fraunhofer IESE

21

Creation of Use Cases

Identification of actors(especially identification of user roles)

For every actor: identification of tasks(every task is at least one use case)

Creation of a use case diagramcontains all actors and use cases

Detailed description of every use case

Optimization of the use cases to avoid redundancy

Priorization of use cases

Clustering of use cases

© Fraunhofer IESE

22

Actor

Is external to the software

Interacting with the system (active or passive)

An actor represents a human in a certain role or an external system, e.g.:

correct: system administrator

wrong: John Smith (what‘s his role?)

right: database application

© Fraunhofer IESE

23

Symbols

Use Cases in UML – Elements

RegistrationBooking

Case 1

Case 2

© Fraunhofer IESE

24

Task Overview: Use Case Diagram

Ordering

Consulting

Dispensing

Returning

Collecting

Registering

Deregistering

Counter employee

Publisher

Librarian

© Fraunhofer IESE

25

Use Cases in UML – Relationships

Inheritance

Include

Extends

Will be executed under certain conditions (option)

Clean roomClean suite

Provide room Clean room<<include>>

HandleOccupied Room Provide room<<extends>>

© Fraunhofer IESE

26

System Functions

Express any kind of functionality that is provided by the system

Are either

invoked by users in a step of a use case

invoked by a process engine in a business process (as an SAA)

by an external system via an interface

performed in batch mode

Note: System Functions are just one type of functional requirements

System Functions

© Fraunhofer IESE

27

System Responsibilities

To-be (Process) Situation

How Everything Fits Together

Business Process

Business Activity

System-supported Activity

System-automatedActivity

Interactions System Functions

is part of

is a

realizes realizes

is used in

Event-drivenProcess Chains

Business Rule & Dataworks on

Data & Rule Model

Rupp‘s Sentence Pattern

Tabular Use Case

© Fraunhofer IESE

28

Specific Aspect: RE in agile Settings

Especially in the Information Systems domain agile methodologies are popular

SCRUM is currently the most popular one

© Fraunhofer IESE

29

Requirements in Agile Settings (SCRUM)

Requirements are organized in Product Backlogs (ordered Featurelists)

One item in the product backlog is described by an epic (covering a partof the product (e.g., shopping basket in a webshop), a user story, an example and/or use cases.

The higher the priority of the requirement, the more fine grained is thespecification detail. Rule of thumb: the „upper“ 20% of the backlog aresmall user stories (fine grained), the remaining 80% are coarse-grained(i.e., epics)

The process of refining a backlog item is called backlog grooming.

© Fraunhofer IESE

30

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

31

Identifying Good Quality in User Stories

User Stories shall fulfill the INVEST principle:Independent, Negotiable, Valuable, Estimatable, Small and Testable.

© Fraunhofer IESE

32

Questions