A Task-oriented Requirements Engineering Method for

Personal Decision Support Systems

A Case Study

Christian Kücherer and Barbara Paech

Institute for Computer Science, Heidelberg University, Im Neuenheimer Feld 205, 69120 Heidelberg, Germany

Keywords:

Decision Support System, DSS, Personal DSS, Requirements Speciﬁcation, Task-oriented Requirements

Engineering, TORE.

Abstract:

[Context and motivation] Personal Decision Support Systems (PDSSs) are information systems which sup-

port executives in decision-making by a decision- and user-speciﬁc data presentation. PDSSs operate on

current data with predeﬁned queries and provide a rich user interface (UI). Thus, a Requirements Engineering

(RE) method for PDSSs should support the elicitation and speciﬁcation of detailed requirements for speciﬁc

decisions. However, existing RE approaches for decision support systems typically focus on ad-hoc decisions

in the area of data warehouses. [Question/problem] Task-oriented RE (TORE) emphasizes a comprehen-

sive RE speciﬁcation which covers stakeholders’ tasks, data, system functions, interactions, and UI. TORE

allows an early UI prototyping which is crucial for PDSS. Therefore, we want to explore TORE’s suitability

for PDSSs. [Principal ideas/results] According to the Design Science methodology, we assess TORE for

its suitability of PDSS speciﬁcation in a problem investigation. We propose decision-speciﬁc adjustments of

TORE (DsTORE), which we evaluate in a case study. [Contribution] The contribution of this paper is three-

fold. First, the suitability of the task-oriented RE method TORE for the speciﬁcation of a PDSS is investigated

as problem investigation. Second, a decision-speciﬁc extension of TORE is proposed as the DsTORE-method

in order to identify and specify details of decisions to be supported by a PDSS. DsTORE is evaluated in a case

study. Third, experiences from the study and method design are presented.

1 INTRODUCTION

Today, data warehouses (DW) are standard technol-

ogy for decision support in companies. They are a

speciﬁc form of Decision Support Systems (DSSs)

which represents a subgroup of information systems.

As discussed in a recent overview by Hosack et

al. (Hosack et al., 2012), there is a large variety of

DSSs and an extensive history of research on DSSs.

At the same time, this research is ongoing and incor-

porates new trends such as social media or mobile

computing (Gao, 2013). Similarly, there is a grow-

ing ﬁeld of research focusing on the development

methodologies for DSS. Saxena (Saxena, 1991) is a

very early development methodology which empha-

sizes the understanding of decision tasks and proto-

typing. In a more recent review Gachet and Haetten-

schwiler investigate early and widely acknowledged

development processes of DSSs (Gachet and Haetten-

schwiler, 2006), focusing on either decisions or sys-

tem engineering or both. They also emphasize the im-

portance of an evolutionary approach which pays at-

tention to both, organizational and technical issues. In

the same vein Arnott (Arnott, 2010) develops a busi-

ness intelligence development approach starting from

a fundamental understanding of senior executives’ be-

havior. We are interested in Personal DSSs (PDSSs,

introduced in detail in Section 2.2) which are small-

scale systems that support decision-making of one or

a small group of executives with an exactly deﬁned

set of supported decisions (Arnott, 2008). While the

early approaches to DSS provide a general frame-

work, they do not describe a detailed requirements

engineering method. Whilst retaining the empha-

sis of these methodologies, we take the task-oriented

RE approach TORE (Paech and Kohler, 2004; Adam

et al., 2009) as our basis to develop a detailed re-

quirements engineering method for PDSSs. TORE

has proven useful for information systems and it sup-

ports a reﬁnement of requirements concerning all sys-

tem details up to the UI, and thus to early prototyping.

However, it has not yet been applied to PDSSs.

Kücherer, C. and Paech, B.

A Task-oriented Requirements Engineering Method for Personal Decision Support Systems - A Case Study.

DOI: 10.5220/0006325300990110

In Proceedings of the 19th International Conference on Enterprise Information Systems (ICEIS 2017) - Volume 2, pages 99-110

ISBN: 978-989-758-248-6

Table 1: Operational and decisional systems. (Left three columns acc. (García et al., 2016) and (Salinesi and Gam, 2009),

except rows structure of data and predeﬁned decisions).

Operational Decisional PDSS

Objective busin. operation busin. analysis speciﬁc busin. decisions

Main functions daily operations (OLTP) DSS (OLAP) decision-speciﬁc UI data presen-

tation, reporting

Decisions n/a un-,semi-,structured semi-, structured

Usage repetitive, predef. innovative, unexp. repetitive, predef.

Design orientation functionality subject subject

Kind of users clerk executives executives

Number of users thousands hundreds one to ten

Accessed tuples hundreds thousands hundreds

Data sources (dsrc) isolated integrated heterogeneous, isolated

Structure of dsrc structured structured un- and structured

Granularity atomic summarized atomic and summarized

Time coverage current historical current and historical

Access(work units) simple transact. complex queries simple queries

Size MB/GB GB/TB/Petabytes MB

With this recent scholarly background in mind,

the overall Research Question (RQ) of this paper is:

How can TORE be extended to support the RE of a

PDSS?. We follow the design science cycle described

by Wieringa (Wieringa, 2014) to answer this RQ. In

the problem investigation, we evaluate TORE’s suit-

ability to support the RE for PDSSs. In the treatment

design, we propose a decision-speciﬁc adaptation of

TORE (DsTORE). Finally, in the treatment validation

we evaluate DsTORE.

This paper is structured as follows. Section 2 in-

troduces PDSSs, presents the case for this study, and

offers a brief overview of TORE. Section 3 discusses

related work on RE for DSSs. The investigation of

TORE’s support for the RE of PDSSs is presented as

problem investigation in Section 4. The treatment de-

sign DsTORE is presented in Section 5. The treat-

ment validation is described in the form of a case

study in Section 6. The results of the problem in-

vestigation and case study are discussed in Section 7,

in which we also present the lessons that we have

learned. The threats to validity are discussed in Sec-

tion 8. Finally, the paper is concluded in Section 9 by

sketching some ideas of future work.

2 BACKGROUND

This section presents a brief introduction of PDSSs

and task-oriented RE as well as the case for our case

study.

2.1 Decisions and Decision Knowledge

A decision can be deﬁned as a choice that is made

between multiple alternative courses of actions, and

that in turn leads to a desired objective (Holsapple,

2008a). Alternatives have implications and decision-

making requires knowledge. For example, the prior-

itization of projects (choice) results in a precedence

of one project over others (alternatives) based on a

project’s importance, beneﬁt for operations, or the

estimated budget (knowledge). Structured decision

problems have deﬁned criteria in order to make the

decision, known alternatives and implications, and re-

quire speciﬁc types of knowledge. By contrast, un-

structured decision problems are by their nature un-

expected, have unstable context and unknown alter-

natives, possess unknown criteria, and rely on situa-

tions in which none or an incomplete level of knowl-

edge is available (Holsapple, 2008a). Semi-structured

decision problems are in between. Decision knowl-

edge is taken from a data source, persisting data for

future access via interfaces or ﬁle access. Examples

of data sources are databases or documents such as

spreadsheets and text documents. A data source is de-

scribed through data source format, location, and con-

tent. For example a project list used by an executive

can be described using a spreadsheet (format), a URL

(location), and a list of projects (content). This is in

contrast with unstructured data, in which structured

data follows a formal deﬁnition of data types. Thus,

data sources of structured data are typically databases,

while semi-structured data is held in spreadsheets,

and unstructured data in text-documents.

2.2 Personal Decision Support Systems

In general DSSs support all kinds of decisions. Sali-

nesi et al. (Salinesi and Gam, 2009) provide a com-

parison of operational information systems (IS) and

DW (called decisional IS) which is adapted in (Gar-

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

100

Goal & Task

Level (GT)

Domain

Level (D)

Interaction

Level (I)

System

Level (S)

Stakeholders

Tasks

As-is Activities To-be Activities

System –

Respons.

Domain Data

System

Functions

Interaction

Data

UI Structure

GUI

Application Core

Navigation/

Sup. Functions

Dialog UI-data

Screen

Structure

Internal

Actions

Internal

Data

Architecture

Supported

Stakeholders

Goals

Data Sources

To-be Decision

Specific Subtasks

Categorization of

Subtasks

Legend:

DsTORE DP

DsTORE refined or

extended TORE DP

TORE DP

Figure 1: Decision Points of the TORE Framework (Paech and Kohler, 2004) and PDSS-speciﬁc extensions.

cía et al., 2016). DSSs in general cover a broad range

of different system types and incorporate a variety

of different techniques such as decision models or

artiﬁcial intelligence (Holsapple, 2008b; Arnott and

Pervan, 2005). The speciﬁcs of Personal DSSs have

been described by Arnott (Arnott, 2008). He sum-

marizes that PDSSs are developed for one or a small

group of managers with the goal to improve the pro-

cess and outcome of decision-making. The scope of a

PDSS is the support of one or a small number of deci-

sion tasks, where often semi-structured data based on

spreadsheets are used. The fact that PDSSs are small-

scale systems refers to the supported small number

of users and features and requirements. To delineate

PDSSs from DSSs in general, we add a third column

to Table 1. The objective of PDSSs is to support

decision-making within a deﬁned context. Its main

function is to provide speciﬁc and predeﬁned informa-

tion for structured and semi-structured decisions in an

overview UI or as a report to executives. In a similar

way to DW, the primary users are executives, who ac-

cess heterogeneous and isolated data sources at run-

time. In contrast to DW, usage is repetitive and pre-

deﬁned and the amount of accessed data is not exten-

sive. Altogether, the data and data sources of PDSSs

are quite complex, while their usage is rather simple.

2.3 Task-oriented Requirements

Engineering

Task-orientation focuses on the RE process and helps

to deliver software that satisﬁes user needs (Paech and

Kohler, 2004). As a conceptual framework, TORE

provides a conceptual model for RE and has been

successfully applied in a number of IS development

projects of different problem domains (Adam et al.,

2009). Important aspects of the requirements speci-

ﬁcation are determined in each of TORE’s 18 Deci-

sion Points (DPs), which are grouped into four levels

of abstraction, as shown on the left part of Figure 1.

Note that TORE’s DPs are distinct from decisions in

the context of DSSs. The goal & task level focuses on

stakeholders, goals, and tasks. Tasks are often activi-

ties within larger business- or management-processes,

but the latter of these is outside of the focus of TORE.

The domain level accommodates as-is and to-be ac-

tivities which reﬁne the tasks by subtasks that con-

tribute to the completion of a stakeholder’s task. Fur-

ther, this level contains system responsibilities (often

called system features), and domain data. The in-

teraction level determines how stakeholders will be

supported in their to-be-activities by the system. Fi-

nally, the system level determines UI details and in-

frastructure including the system architecture. TORE

does not ﬁx or prescribe artifact types for documen-

tation of the DPs. In particular, it is not necessary to

have a separate artifact for every DP, as lower-level

DPs contain decisions for corresponding higher-level

DPs. Several artifact types have often been used, as

is shown in Table 2 by their relation to the DP. The

artifact type task description according to Lauesen’s

Task&Support (Lauesen, 2005) describes stakehold-

ers’ tasks. Subtask templates are used to describe

the DPs As-is and To-be-activities. The DP Domain

Data is described with an UML class diagram or en-

tity relationship diagram, containing domain entities

and their relationships. The UI Structure Diagram

shows the navigation between workspaces for DP UI

Structure, where workspaces group system functions.

Virtual windows (Lauesen, 2005) describe the DP

Screen Structure by an high-level grouping and struc-

turing of the UI data in order to illustrate the informa-

tion needs for tasks early on in the RE process. The

UI Prototype reﬁnes the virtual window with the nav-

igation functions and dialogue and documents the DP

UI Data, Dialog and Navigation Functions.

2.4 The Case and Its Context

The case was selected on the basis of availability

as part of the research project Semantic Network of

Information Management in Hospitals (SNIK) (Jahn

et al., 2014). The project team develops, among other

A Task-oriented Requirements Engineering Method for Personal Decision Support Systems - A Case Study

101

Table 2: TORE Decision Point and supported artifact types

relevant for this study (Paech and Kohler, 2004). Rows

marked in grey are introduced in Section 5.

Level Decision Point Artifact

GT Stakeholders Tasks Task description

D As-is activities, To-be

activities

Subtask template

D Domain Data UML class diagram,

ER diagram

D Categorization of ST Task description

D To-be Decision spe-

ciﬁc ST

Decision speciﬁc

subtask template

I UI Structure UI structure diagram

I System functions Function description

I Interaction Data UML class diagram

I Interaction use case text

G UI Data UI Prototype, Vir-

tual window

G Screen Structure UI Prototype, Vir-

tual window

things (Schaaf et al., 2015), a dashboard for the CIO

of a hospital called CIO-Navigator (CION). The CIO

is the head of the Information Management (IM) De-

partment and is responsible for decision-making in

strategic, tactical, and operational IM. Thus, the CIO

role is located at management or executive level. The

CIO is currently faced with the problem that he strug-

gles with distributed and scattered information in sev-

eral systems and documents. He requires this infor-

mation to make decisions related to the IM and for

each decision the CIO has to collect the necessary

data. By the use of CION, we enable the CIO to nav-

igate current data of the IM department and provide

him with the relevant set of information required for

decision-making of a predeﬁned set of recurring de-

cisions. According to the characteristics presented in

Table 1, CION is a PDSS.

3 RELATED WORK

For related work, we ﬁrst discuss two papers which

provide an overview of RE for DSSs and then we dis-

cuss goal-oriented RE approaches for DSSs.

Garcia et al. (García et al., 2016) present a com-

prehensive mapping study of 27 articles related to RE

for DSS. Although the title suggests DSSs, the search

terms and the identiﬁed literature focus on DW. The

authors conclude that there is a gap in the process of

creating the design of a DSS in a methodical man-

ner. In particular the business needs gain too lit-

tle attention during the RE process. They propose

to elicit business needs from stakeholders by asking

“what do you do and why?”. Another overview by

Salinesi and Gam (Salinesi and Gam, 2009) (not cov-

ered by Garcia et al.) provides a comprehensive dis-

cussion of 15 requirements engineering approaches

for DSSs, all of which are DW-speciﬁc. They found

three families of methodological processes. (1) Data-

driven approaches which are focused on the structure

of data sources to design multi-dimensional schemas.

However, these approaches do not cover decision

speciﬁcs. (2) Requirement-driven approaches which

focus on decision makers’ requirements. The weak-

ness of these approaches is that the availability of

data sources is not treated sufﬁciently so that user re-

quirements may not be realizable. (3) Mixed-driven

approaches are a combination of (1) and (2). Both

overviews again conﬁrm the need to understand the

business and stakeholder needs.

As the approaches of both overview papers focus

on DW, they support in particular the speciﬁcation of

DW data schema deﬁnitions, data marts for DWs, and

DW-speciﬁc ETL (extract, transform, load) processes,

which are not important for PDSSs. Thus, these new

RE approaches also do not provide a detailed task-

oriented guideline for PDSS development.

There are several goal-oriented RE approaches for

DSS. Again they focus on DW. They share the impor-

tance of the business and decision focus, but focus on

decision speciﬁcs for DW such as key performance

indicators (Pourshahid et al., 2014) or business strat-

egy and indicators (Barone et al., 2012; Topaloglou

and Barone, 2015). Giorgini, Rizzi and Garzetti pro-

pose with GRAnD (Giorgini et al., 2008) a goal-

oriented method which connects a decisional model

with a source schema. While this method provides a

detailed analysis of the goals and decisions, it does

not provide guidance for the UI design and early pro-

totyping with the user.

Altogether, we did not ﬁnd a requirements engi-

neering method for DSS in general and PDSS in par-

ticular which provides guidance for a seamless transi-

tion from the business level to UI details.

4 PROBLEM INVESTIGATION

This section describes the problem investigation, in

which we wanted to understand what decision spe-

ciﬁc information is missing in TORE to support the

speciﬁcation of a PDSS. In particular, we were inter-

ested in those decision details that are necessary for

PDSS requirement speciﬁcation yet inadequately rep-

resented in TORE’s DPs.

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

102

4.1 Design and Data Collection

We investigated the RE process for the speciﬁca-

tion of CION (cf. Section 2.4) based on the method

TORE. The supported stakeholder (TORE DP Sup-

ported Stakeholder) is the CIO of a particular hos-

pital. Firstly, we performed a pre-assessment of the

tasks and data of the IM department by a combined

task- and system analysis (Ammenwerth et al., 2015)

to gain an overview of the tasks and responsibilities of

the CIO and IM department (Kücherer et al., 2015).

The goal of the CIO is to provide a transparent view

of the operative and tactical data of the IM department

for IT-staff and visitors (documented in the TORE DP

Stakeholders Goals). The resulting artifact was a task

description according to Lauesen’s Task & Support

containing several CIO tasks. In consultation with the

CIO, we prioritized the tasks depending on their im-

portance and selected the ﬁrst two tasks project man-

agement, and change management for further inves-

tigation. These two tasks were further detailed by

a semi-structured interview (duration 2:15) with the

CIO which helped us to deepen and reﬁne our under-

standing of TORE’s DP Stakeholders Tasks and Do-

main Data wrt decisions. The reﬁned task description

and the meeting minutes were reviewed by the CIO.

During a document analysis based on screen-

shots, we analyzed two spreadsheets provided by the

CIO in order to understand their decision speciﬁcs.

These screen shots contained the majority of data nec-

essary for the investigated task project management

and change management. In an additional document

analysis based on operative ﬁles, we analyzed further

decision-speciﬁc documents in the form of spread-

sheets (cf. Figure 3) and text-documents. The docu-

ment analyses helped us to understand particularly the

decision-speciﬁc data. We did not visit the other DPs,

as the insights from these activities already provided

a good picture of the decision-speciﬁc requirements.

4.2 Results

The problem investigation shows that TORE’s DP

can capture a large amount of relevant requirements,

which have been gained during the interview. Some

details of important information about the CIO’s de-

cisions cannot be captured explicitly with the exist-

ing artifact types and DPs in TORE, explained in the

following. We identiﬁed ﬁve decision-speciﬁc pieces

of information which we postulate as criteria c

-c

These criteria will shape the treatment design in the

next section.

: Distinction of decisions from conventional

subtasks. We found subtasks with and without de-

ID: Subtask PM 3a: Prioritize projects of project

list

Actor CIO

Contribution Consider important projects in budget

planning.

Cause Next ﬁscal year starts in two months

Description Decision about order of new projects for

budget planning. Necessary step before

a project can start. The assigned pri-

ority depends on the project contribu-

tion...

Pre condition all project proposals for next ﬁscal year

are available. CIO knows goals and ne-

cessity of projects

Info-In urgency, proposed priority of pro-

poser (project proposal), project list,

controlling-list, remaining budget (dif-

ference calculation).

Post condition Changed priorities in project list. Bud-

get is transferred to new project.

Info-Out Priority of new project. Reprioritiza-

tion of existing projects in project list.

Figure 2: Subtask Project Prioritization in standard

template.

cision character. Some subtasks contain a decision

problem as a recurrent choice between several alter-

natives, each of which entails different implications

(cf. example in Sec. 2.2). Such subtasks are in partic-

ular relevant for a PDSS requirements speciﬁcation.

: Detailed description of the data necessary to

make the decision. Based on the information from

the pre-assessment and interview, we created the sub-

task description prioritization of projects as

a subtask of the task project management, as is

shown in Figure 2. The documentation with a stan-

dard subtask template does not show explicitly the

data required by a decision. The domain data model

shows the entities, but not the relation between en-

tities and decisions. By way of an example, Fig-

ure 2 shows two deﬁcits: It cannot be explicitly doc-

umented, (a) how the remaining budget is calculated,

i.e. which entity-attribute pairs are used for the calcu-

lation, and (b) which information exactly is necessary

from the project list and the controlling list.

: Decision-speciﬁc rules to choose from al-

ternatives. Decisions always contain alternatives

(cf. Section 2.2). In some cases, the alternatives can

be chosen based on predeﬁned rules. To understand

decisions and their alternatives, it is essential to em-

phasize rules, if there are any. For example, the CIO

explained the rule to assign a priority to new projects.

Projects contributing to service protection receive pri-

ority one, contributions to service operation receive

priority two, and all other projects receive priority

three. This rule is not made explicit in Figure 2.

: Support of decision-speciﬁc patterns in data

for tables and summary ﬁelds. The document anal-

A Task-oriented Requirements Engineering Method for Personal Decision Support Systems - A Case Study

103

Running Projects total: 2 Year 2016 95.000 € 50.000 € 90

Pri

Proje

ct ID

Title Description

planned

start

planned

budget

assigned

budget

1 15-1 Server Virt. Migration … Q3/2015 120.000 € 90.000 € 260

16-17 Letter softw. Update phy… Q4/2016 15.000 € 0 € 25

2 16-3 Service Mngr Add KPI … Q2/2016 80.000 € 50.000 € 65

(a) Part of Project List

Account ID <ID>

Planned Service Total 120.000 € 7.544 €

Project

lead

Proje

ct ID

Title

Assigned

Budget 2016

Remaining

budget

J.Doe 15-1 Server Virtualization 40.000 € 21.000 €

A.Smith 16-17 Letter software 0 €

H.Simpson 16-3 Service Manager 80.000 € -13.456 €

(b) Part of Controlling List

Figure 3: Decision-speciﬁc Spreadsheets.

ysis has shown two reoccurring patterns in the data

that is required by the CIO to make a decision. First,

combinations of entity/attribute pairs from more than

one single entity are evident. Second, computed data

such as sums or any other kind of condensed data

is evident. For instance, the CIO needs to priori-

tize new projects, which might change the priority

of existing projects. Currently, for the decision re-

garding the priority of new projects the CIO requires

two documents which he presented to us after the in-

terview: (1) The spreadsheet project list, illus-

trated in Figure 3(a) contains all running, ﬁnished,

and planned projects. Each project is speciﬁed with

a title and priority, a planned start date, the estimated

budget and Human Resources (HR) effort, and an

approved budget. In the top row, there is the num-

ber of projects and the sum of planned and assigned

budget for projects running in year 2016. (2) The

controlling list which contains an overview of

all projects’ budget status as shown in Figure 3(b),

based on each project’s expenses (not shown here).

The list contains the project’s leader, ID, and title,

as well as the assigned budget in 2016 and the re-

maining budget. Again, there are single rows and

summary ﬁelds in the header, such as the total as-

signed budget in 2016 and the total remaining budget

(unused_budget) of all projects. It is important to

describe explicitly and model these decision-speciﬁc

data patterns (besides in UI prototypes), in order to

be able to aggregate all data in one model and check

for dependencies and consistencies. The domain data

model does not support the modeling of data combi-

nations from different entities or aggregations.

: Relation between content, format, and URL

for data sources. The problem investigation has

shown that executives work with spreadsheets con-

taining aggregated data (e.g. Figure 3(a), 3(b)) and

some text-documents. Their content and format is

known to frequent users. Spreadsheets and text-

documents represent heterogeneous decision-speciﬁc

data sources. In order to relate the patterns in data

) with their origin, we need to document and under-

stand these data sources. As explained in Section 2.2

this heterogeneity is speciﬁc to PDSSs. Thus, a de-

tailed description is an important input for system de-

sign decisions. Such a description should contain the

content in terms of entities, the format and the URL.

5 DsTORE - TREATMENT

DESIGN

The design of the DsTORE method addresses the de-

sign problem: Improve the TORE method by decision-

speciﬁcs c

-c

in order to gain a comprehensive and

structured speciﬁcation for PDSSs. Thus, the em-

phasis is to provide a more precise RE. This sec-

tion presents a short introduction of DsTORE as

TORE enhancement. In this stage, we ﬁrst intro-

duce new decision-speciﬁc DPs with related artifact

types (cf. the right side of Figure 1). In some cases,

we adapt DPs, indicated as dashed DPs in Figure 1.

DsTORE uses the same artifact types as TORE. There

are two extended artifact types, ﬁrstly the subtask de-

scription and domain data model, and secondly one

new simple data source model.

5.1 Goal & Task Level

The new decision-speciﬁc DP Categorization of sub-

tasks that fulﬁlls criterion c

is required to analyze

subtasks with the help of a categorization scheme

in order to ﬁnd subtasks which are decisions. Two

properties are used for categorization: the presence

of alternatives to choose from and the verb or sub-

stantive of the subtask, indicating a decision. Sub-

tasks can be a decision or a conventional subtask.

For the IM domain, we use a non-exhaustive model

encompassing 7 categories and distinguish objects

or situations (x) and subjects(y). In other domains,

the categorization scheme needs to be populated dif-

ferently. Decisions are Approval of x, Evaluation

of x or y, and Prioritization of x. Conventional

subtasks are Monitoring of x, Documentation of x,

Communication of x to y, and Support of x or y. Ex-

amples are the conventional subtask ’monitoring of

project progress’ classiﬁed as M and the decision ’ap-

proval of budget’ with the alternatives rejection or ap-

proval classiﬁed as A.

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

104

ID: Subtask PM 3a: Prioritize projects of project list

Actor CIO | Supporting Actors: project leader

Contribution Consider important projects in budget planning.

Cause Next ﬁscal year starts in two months

Description Decision about order of important projects...

Pre condi-

tion

all project proposals for next ﬁscal year are avail-

able. CIO knows goals and necessity of projects

Combined

Data

Attribute Entity

project.priority Project List Table Entry

project.start Project List Table Entry

... ...

budget.planned Project List Table Entry

Computed

Data

Attribute Entity Computation

budget.remai-

ning

Controlling

List Ta-

ble Entry

assigned budget -

sum(project ex-

penses)

<derived at-

tribute> un-

used_budget

Controlling

List

sum(budget.re-

maining, all pro-

jects))

Post condi-

tion

Deﬁned order, assigned priority of new projects.

Budget is transferred to new project.

Info out

Attribute Entity

project.priority Project List Table Entry

Rules Priority deﬁnition by project contribution: (high)

service protection; (medium) service operation;

(low) nice to have.

Figure 4: Decision Project Prioritization.

5.2 Domain Level

Decision-related subtasks are speciﬁed in the DP To-

be decision-speciﬁc subtasks and are documented

with the decision-speciﬁc subtask template. The

decision-speciﬁc subtask template extends TORE’s

subtask template to deﬁne the semantics for deci-

sion artifacts and fulﬁlls c

and c

. It covers de-

tails of a decision in four structured ﬁelds, which

are marked yellow in Figure 4. Combined data ex-

press necessary decision- and/or stakeholder-speciﬁc

data with entity/attribute pairs. Data aggregations,

e.g. of time or spatial data often used for decision-

making, are documented by computed data and in-

dicated by ’/’ for derived attributes in the Domain

Data Model (cf. Figure 5). Details of the computa-

tions, such as add, subtract, etc., are documented in

the column computation. The result of the deci-

sion is documented in the ﬁeld Info-out, again with

entity/attribute pairs. Rules describe which alterna-

tive will be chosen by the decision maker and un-

der which circumstances. The notation can be tex-

tual or formal, as is appropriate. Decisions require

speciﬁc domain data that is decided in the extended

DP Domain Data which uses additional stereotypes.

The attributes and entities need to be consistent with

those of the decision-speciﬁc subtask. The decision-

speciﬁc spreadsheets, as presented in the problem in-

vestigation (cf. Section 4), are modeled in the do-

main data with UML stereotypes. Lists, such as

the project list (cf. Figure 3(a)), are modeled by

stereotype «ListEntity». The «ListEntity» is re-

Project

<<ListEntity>>

Project List

projects total

/ sum of planned budget

/ sum of assigned budget

/ sum of man-day

0..*

contains planned

and running <

<<View>>

Project List Table

Entry

project.priority (,ID)

...

budget.planned

budget.assigned

project.estimated HR

<<ListEntity>>

Controlling List

account ID

/ sum of planned budget total

/ sum of remaining budget

<<View>>

Controlling List

Table Entry

project.leader

project.ID

project.title

budget.assigned

budget.remaining

Budget

planned

assigned

remaining

0..1

has a 

0..*

title

leader

description

start

priority

status

...

estimated HR

Ordered List

Figure 5: Part of Domain Data Model for Project

Management.

lated to the listed entities and to a «View» entity

which captures combined attributes. As an exam-

ple, both, the controlling list (cf. Figure 3(b))

and the project list (cf. Figure 3(a)) are modeled

in the domain data model in Figure 5. The class

«ListEntity» Controlling List holds computed

and non-repetitive attributes such as the sum

of planned budget and the sum of remaining

budget (i.e. the unused_budget of other projects)

which are located at the top of the list. The table rows

are modelled by the class «View» Controlling

List Table Entry . Classes of «View» might con-

tain attributes of several domain entities, e.g. the

ID of a project as attribute project.ID and the

remaining budget of the same project as attribute

budget.remaining for Controlling List Table

Entry.

5.3 Interaction Level

In the DP system functions, TORE focuses on the to-

be system functions. DSSs have a limited range of

typical system functions, cf. Holsapple (Holsapple,

2008b), and Power (Power, 2011). Therefore, we add

criterion c

: the RE speciﬁcation should consider typ-

ical PDSS-speciﬁc system functions explicitly. Ex-

amples of PDSSs system functions include creation

of reports, navigation to data sources, and document

export. We adapt the DP to use a decision-speciﬁc

predeﬁned set of system functions as a guidance to

support completeness and to avoid gold plating. This

set can be adapted according to the different types of

DSS. We also adapt the DP Interaction which is typi-

cally described by use cases. Since PDSSs provide a

dashboard-like UI with one screen for each decision,

a detailed description of interaction on this level is not

necessary. The UI-structure diagram sufﬁces to cap-

ture the navigation between the different workspaces.

A Task-oriented Requirements Engineering Method for Personal Decision Support Systems - A Case Study

105

Table 3: Overview of the Case Study’s activities, duration, and artifact creation effort. (T=Telephone), Duration in [h:mm].

ID Dur. Activity Decision Point / Description

Tasks of Treatment Validation Phase 1: project management, change management

1 1:20 Interview Categorization of Subtasks, To-be Decision Speciﬁc Subtask, UI Structure

2 1:20 Interview System Functions, Interaction Data

3 T1:30 Interview System Functions, Interaction Data, UI Data

4 1:45 Interview To-be activities, Domain data, Screen Structure

5 - Development Development of system prototype

6 1:00 Presentation System prototype in software

Tasks of Treatment Validation Phase 2. Task: IT Strategy

7 1:30 Interview Stakeholders Tasks, Categorization of Subtasks, To-be Decision Speciﬁc Subtasks, Do-

main Data, Interaction Data

8 1:30 Interview To-be Decision Speciﬁc Subtasks, Interaction Data

9 T0:45 Evaluation Eval.: interviews, artifacts, system prototype

5.4 System Level

The DP UI-Data and Screen Structure is documented

with a Virtual Window. Figure 6 shows the Vir-

tual Window of the subtask prioritize projects of

project list (as introduced in Figure 4). The Vir-

tual Window shows the arrangement of the decision-

speciﬁc subtask’s data. On the system level, there

is a new DP Data sources. In TORE, data sources

are left to software design. As argued for c

the consideration of data sources in DsTORE is

important. Data source description can be cap-

tured in a simple table with the rows entities,

format, and location, e.g. project, excel/csv,

http://filesrv1/2016/project-list.xlsx.

6 CASE STUDY: TREATMENT

VALIDATION

This section describes the design and results of the

two-phase case study to evaluate the treatment design

DsTORE. The case and it’s context is described in

Section 2.4, since it was relevant for the problem in-

vestigation.

Investment budget

plannedavailable

Project

Status

Priority

Change

Planned

Start

Urgent/

Essential

Service budget

Finished Projects

Project

name

Project-

start

Priority,

Date of

change

Project details as above

Status available planned

Project

Sum Projects

Department budget Year 2016 Year 2015 Year 2014

Plan is

Consumpt.[%]

Plan is

Consumpt.[%]

Plan-is

Consumpt.[%]

investment

budget

Projects /RT

Reserve

Service

budget

devices

organization

Maintenance Hardware

plannedavailable

available planned

Planned Projects

Sum Projects

Running Projects

Sum Projects

Sum Budget

Figure 6: The virtual window for Project Management.

6.1 Design

The research objective is to identify the extent to

which DsTORE supports the RE of PDSSs. The

object of study is the application of the DsTORE

method. Therefore, we raise RQ.1: How well does

DsTORE support the speciﬁcation of requirements

for a PDSS? In phase one we re-visted the tasks

project management and change management (al-

ready investigated in the pre-assessment), but now us-

ing DsTORE artifact types for speciﬁcation. Miss-

ing information was additionally elicited. We used

four semi-structured interviews (activity 1-4) to elicit

the requirements with DsTORE, as shown in Table 3.

DPs visited are: Categorization of subtasks, As-is and

to-be, To-be decision-speciﬁc subtasks, UI Structure,

System functions, Interaction data, and Screen Struc-

ture. Table 5 shows which artifacts have been created

after the elicitation during the activities 1-4 and 7-8.

For each artifact the time needed for its creation is

given, including an internal review and a review with

the stakeholder. The task description of project man-

agement and change management were used from the

problem investigation. All other artifacts were newly

created.

The DP Navigation/Supporting Functions was not

relevant, since no supporting functions were neces-

sary. The DP Dialog was not relevant, since the dash-

board does not support complex dialogues. All sys-

tem DPs were reﬁned during the implementation of

the system prototype in activity 5, where two students

implemented a system prototype in .NET which in-

tegrates into SharePoint. We presented this system

prototype to the CIO in activity 6. In phase two

we investigated the CIO task IT-Strategy with activity

7-8. The DPs Stakeholders Task, Categorization of

subtasks, To-be decision-speciﬁc subtasks, Decision-

speciﬁc domain data, and Interaction data have been

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

106

visited in activity 7. In activity 8 we reﬁned the re-

quirements of DPs To-be decision-speciﬁc subtasks,

and Interaction data.

Table 4: Metrics of data collection for the case study - treat-

ment validation.

ID Description of metrics

m1 Time taken for the creation of artifacts

m2 Number & duration of interview sessions in total

m3 Stakeholder’s feedback to the interviews

m4 Stakeholder’s feedback to the artifacts

m5 Stakeholder’s acceptance of the system prototype

m6 Requirements engineer’s feedback

We performed the data analysis for both phases

after all interviews. To answer RQ.1, we used a

Goal Question Metric approach (GQM) (Van Solin-

gen et al., 2002). We study the following effects of

the application of DsTORE (see (Wieringa, 2014) for

similar distinctions): the efﬁciency in terms of the

time taken for artifact creation and the interviews (m1

and m2), the usability in terms of the ease of use of

the artifacts and the process for the stakeholder (m3

and m4) and the requirements engineer (m6), and the

utility in terms of the value of the outcome for the

stakeholder (m5). The data for these metrics was col-

lected in a semi-structured interview (activity 9). Ta-

ble 4 summarizes the metrics used to answer RQ.1.

6.2 Results

The creation of artifacts (m1) took 106 hrs in phase

one and 7 hrs in phase two, cf. Table 3. Four in-

Table 5: Overview of artifacts created (ID = Activity ID

referring to Table 3, ST=Subtask).

ID Decision Point Artifact Dur.

Categorization of ST Task description

56 h

Decision

speciﬁc ST

decision-speciﬁc ST

UI Structure UI structure diagram

Screen Structure Virtual Window

System functions function description

15 h

Interaction Data Domain Data Model

System functions UI structure diagram

23 hInteraction Data Domain Data Model

UI Data Virtual Window

Interaction UI Prototype

12 hUI Structure UI structure diagram

Screen Structure Virtual Window

Stakeholders Tasks Task description

3 h

Categorization of ST Task description

Decision speciﬁc ST decision-speciﬁc ST

Domain Data Domain Data Model

Interaction Data Domain Data Model

Decision speciﬁc ST decision-speciﬁc ST

4 h

Interaction Data Domain Data Model

Table 6: Metrics and CIO’s artifact rating (• difﬁcult, ◦ easy,

◦◦ very easy, ++ very important, + important, - less impor-

tant).

Artifact type simplicity import.

underst. comment underst.

Task description ◦ ◦ +

Categorization of

subtasks

• • +

Decision Speciﬁc

Task Description

• ◦◦ +

Data sources ◦◦ • ++

Workspaces ◦ • -

Virtual windows ◦◦ ◦ ++

UI Structure Dia-

gram

• • +

UI Prototype ◦◦ ◦◦ ++

terviews with a duration of approx. 7 hrs. were con-

ducted (m2) in phase one, and two interviews with a

duration of 3 hrs. in phase two. The CIO liked the in-

terviews of both phases and rated the semi-structured

execution of interviews as good (m3), since it gave

him room to discuss ideas. He suggested two im-

provements: the provisioning of a RE-process de-

scription with a graphical sequence upfront, and the

consultation of other departments’ experts in some

situations. The CIO found it sometimes difﬁcult to

provide all relevant decision information. It would

have helped him, if he had a prepared description of

decisions before the RE phase. The meeting minutes

and the correction iteration was good and helpful for

the CIO. The interview preparation and the review

was difﬁcult due to time restrictions. Especially for

phase two, the CIO rated the identiﬁcation of deci-

sions overall as good. For the task IT-strategy, the

CIO rated the description of decision-related informa-

tion as difﬁcult. He did not want to consider the def-

inition of the IT-strategy as a decision, although the

interview had identiﬁed 5 decisions. The CIO’s feed-

back to the artifacts (m4) is summarized in Table 6.

The CIO’s perception of artifacts did not change

between phase one and two. All decision-speciﬁc in-

formation was contained in the artifacts. The CIO

perceived the task description as important, and easy

to understand and comment on. However, he con-

sidered the Categorization of Subtasks as difﬁcult to

understand and comment on. Once the categoriza-

tion was done, the CIO understood its importance.

Initially, the CIO did not see the importance of the

Decision-speciﬁc Task Description, and hence, rated

the understanding as difﬁcult but easy to comment

on. After the ﬁrst review of this description, he rated

them as important. He perceived the description of

complex processes (such as decisions) as challeng-

ing. The CIO rated the description of data sources as

very easy to understand, but difﬁcult to comment on

A Task-oriented Requirements Engineering Method for Personal Decision Support Systems - A Case Study

107

(and ﬁll in), since he was not aware of detail knowl-

edge about URLs. The CIO perceived Workspaces

as a complex summary of task details and rated them

as understandable, but unimportant to him, since they

are an intermediate step to virtual windows. The

CIO perceived the UI Structure Diagram as a com-

plex and overloaded representation and rated them

as difﬁcult to understand and comment. He recom-

mends to hide workspace details and focus the nav-

igation between them. The UI Prototype gives the

most detailed description of the system-to-be and al-

lows to check whether the UI contains the necessary

information. It was rated as very easy to understand

and comment and as a very important artifact. The

CIO rated the developed system prototype (m5) as

useful, appropriate, and applicable with a good user

friendliness. However, a more detailed system test is

yet to be done by the CIO to identify missing data

or other gaps. He deﬁnitely will employ the proto-

type. The requirements engineer (m6) rated the de-

tailed understanding of the artifact types and their re-

lations to each other as very important to structure the

interviews. The requirements engineer needs to un-

derstand the RE process to choose an appropriate se-

quence of DPs to visit and artifacts to create. During

the RE phase, s/he must keep all artifacts consistent,

which is challenging. The DsTORE artifacts enabled

a detailed understanding of the decisions. The speciﬁ-

cation was extremely helpful to guide the developers

during the implementation of the prototype, in par-

ticular the knowledge of the required data and their

origin. Therefore RQ.1 can be answered as follows:

DsTORE supports the speciﬁcation of requirements

for a PDSS adequately. It allows an early and contin-

uous stakeholder feedback, emphasizes the decision-

speciﬁc data, and decision-speciﬁc UI prototyping.

7 DISCUSSION

In this section, we discuss the results of the DsTORE

evaluation and possible improvements to DsTORE, as

well as lessons learned and general experiences with

the method adaptation.

Discussion of DsTORE: The problem investigation

shows that TORE as a structured RE framework pro-

vides the basis for the speciﬁcation of a PDSS. This

is not surprising as PDSS share some properties with

IS (cf. Table 1). The missing decision-speciﬁcs are

provided by DsTORE. Small adaptations in DsTORE

help to understand decisions and to gain a detailed

speciﬁcation of all PDSS aspects. The treatment val-

idation shows that DsTORE is accepted by the stake-

holder and the requirements engineer, although there

is potential for improvement.

The effort of 106 hrs to create the artifacts is very

high, but decreased signiﬁcantly in phase two based

on the prior experience. Four interviews with 7 hrs

and two interviews with 3 hrs is a reasonable effort.

Based on the CIO’s feedback, the semi-structured in-

terviews are adequate to elicit requirements and al-

low a creative discussion. The results show that the

CIO views atomic decisions as part of larger business-

or management processes which are also important

to him. It therefore appears interesting to study the

relations of tasks and their atomic decisions to man-

agement processes. The CIO rated only the artifact

workspaces as less important for him. We used the

workspace to structure the virtual windows. In the

future, workspaces might be used only by the require-

ments engineer while the structure is discussed with

the stakeholder directly in the virtual windows. The

CIO’s rating emphasizes the importance of the data

sources and the UI. The CIO’s suggestions do not

concern the DPs, but rather the execution of the inter-

views, which can easily be improved. E.g. decisions

can be identiﬁed on the task level with the CIO with-

out specifying details, and can then be detailed with

external experts. The latter can also supply the data

source details. The categorization of subtasks can be

done initially by the requirements engineer and pre-

sented to the CIO for review. The artifacts’ consis-

tency can be improved by a yet to deﬁne tool support.

Both, CIO and requirements engineer, missed a RE-

process description covering activities and artifacts.

This can easily be provided in the future.

Lessons Learned: The following sequence is help-

ful for creating some of the artifacts of DsTORE.

(1) task and subtask (2) detailed decision descrip-

tion (3) domain data model (4) virtual windows (5)

workspaces (6) UI Structure Diagram (7) UI Proto-

type. A template for the naming of subtasks should

be used, i.e. <verb | nominalized verbs> <object>.

Synonyms for similar verbs should be avoided. Dur-

ing the elicitation of the to-be decision-speciﬁc sub-

task description, it is important to continuously ask

the stakeholder which data exactly is necessary for

the decision. It is important to distinguish explicitly

between domain entities and attributes, as this is not

done directly by the stakeholder. The speciﬁcation of

rules is often awkward, especially when they are com-

plex, or have not been formulated previously. It was

helpful for us to assure that attributes of rules can be

mapped to the domain data model. It is worth the ef-

fort to assemble the results of the decision description

into virtual windows as early as possible.

General Experiences with Method Adaptation:

During the treatment design we developed several fur-

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

108

ther artifact types, which we ﬁnally discarded or sim-

pliﬁed, so that they could ﬁt into DsTORE artifact

types. The design science process helped to structure

the adaptation of TORE into problem identiﬁcation,

speciﬁc adaptations, and their evaluation. It forced

us to create explicit justiﬁcations for the adaptations.

Further, it forced us to collect explicit feedback from

the stakeholders involved in the method execution. It

is important to discuss the adaptations with indepen-

dent experts not involved in the method execution.

8 THREATS TO VALIDITY

The threats to validity are structured according to

Runeson et al. (Runeson and Höst, 2009). Construct

Validity considers whether the study measures what

it claims. The artifact types of DsTORE were not yet

ﬁxed during phase 1. As all DsTORE DPs as pre-

sented in Section 5 were applied in treatment val-

idation, we believe that the DsTORE artifact types

that have been temporarily used and discarded do not

distort the ﬁnal results. Internal Validity considers

causal relations of investigated factors, i.e. effects of

unknown factors that inﬂuence an investigated fac-

tor. Training obviously affected the effort and the

opinion of the stakeholders. The effort decreased be-

tween the case studies, owing to training effects of the

requirements engineer and CIO. We asked the CIO

about his opinion in activity 9, after he had gained

the experience. The system test and the implementa-

tion of the results of the case study, phase two, might

change the evaluation. However, we consider this as

unlikely. External Validity describes the generaliz-

ability of the ﬁndings and the transfer of study results

outside the study. The case studies are based on a sin-

gle case only. The case study involved only one per-

son. DsTORE is speciﬁc to PDSSs and the transfer-

ability to other DSS types is unclear. Reliability con-

siders the inﬂuence of the speciﬁc researcher and in-

dicates threats to validity for a repetition of the study.

The main threat to reliability is that the ﬁrst author

(as requirements engineer) had much inﬂuence on the

development and process of the case study, in partic-

ular during the interviews and the data analysis. We

mitigated this by continuous discussion with the 2nd

researcher.

9 CONCLUSION

In this study, we presented a problem investiga-

tion, DsTORE as the treatment design which extends

TORE to support requirements engineering for PDSS,

and a case study that evaluates DsTORE in the case of

a PDSS, in order to show its basic feasibility. The re-

sults are encouraging to continue with the following

future work: First, we will extend the prototype with

the task IT-strategy. After the system test with the

CIO, this prototype will be put into operation at the

hospital. Second, we will consolidate the improve-

ments of DsTORE as we have sketched above. Third,

as data play a prominent role, we will explore how an

ontology can support the RE process. In carrying out

this last aspect, we rely on the SNIK domain ontol-

ogy (Schaaf et al., 2015) for IM in hospitals. We want

to elaborate, how this knowledge can be used in com-

bination with DsTORE to further improve the require-

ments elicitation and speciﬁcation. Fourth, we believe

that it would be interesting to investigate whether and

how the presented approach also supports the speciﬁ-

cation of other types of DSSs.

ACKNOWLEDGEMENTS

We thank the involved CIO for his time and moti-

vated collaboration and the SNIK project team for

their intensive cooperation. This work was sup-

ported by DFG (German Research Foundation) under

the Project SNIK: Semantic Network of Information

Management in Hospitals, Grant no. 1605/7-1 and

1387/8-1.

REFERENCES

Adam, S., Doerr, J., Eisenbarth, M., and Gross, A. (2009).

Using Task-oriented Requirements Engineering in

Different Domains – Experience of Application in

Research and Industry. Proceedings of 17th IEEE

International Requirements Engineering Conference

(RE’09), pages 267–272.

Ammenwerth, E., Haux, R., Knaup-Gregori, P., and Winter,

A. (2015). IT-Projektmanagement im Gesundheitswe-

sen. Schattauer, Stuttgart, 2. edition.

Arnott, D. (2008). Personal Decision Support Systems. In

Burstein, F. and Holsapple, C., editors, Handbook of

Decision Support Systems 2, chapter 43, pages 127–

150. Springer-Verlag Berlin Heidelberg.

Arnott, D. (2010). Senior executive information behaviors

and decision support. Journal of Decision Systems,

19(4):465–480.

Arnott, D. and Pervan, G. (2005). A critical analysis of

Decision Support Systems research. Journal of Infor-

mation Technology, 20(2):67–87.

Barone, D., Topaloglou, T., and Mylopoulos, J. (2012).

Business Intelligence Modeling in Action: A Hospital

Case Study. In Jolita Ralyte, Franch, X., Brinkkem-

A Task-oriented Requirements Engineering Method for Personal Decision Support Systems - A Case Study

109

per, S., and Wrycza, S., editors, Advanced information

systems engineering, pages 502–517.

Gachet, A. and Haettenschwiler, P. (2006). Development

processes of intelligent decision-making support sys-

tems: review and perspective. In Intelligent Decision-

making Support Systems, pages 97–121. Springer.

Gao, S. (2013). Mobile decision support systems research:

a literature analysis. Journal of Decision Systems,

22(1):10–27.

García, S., Romero, O., and Raventós, R. (2016). DSS from

an RE Perspective: A systematic mapping. Journal of

Systems and Software, 117:488–507.

Giorgini, P., Rizzi, S., and Garzetti, M. (2008). GRAnD: A

goal-oriented approach to requirement analysis in data

warehouses. Decision Support Systems, 45(1):4–21.

Holsapple, C. W. (2008a). Decisions and Knowledge. In

Burstein, F., editor, Handbook on Decision Support

Systems 1, chapter 2, pages 21–53. Springer.

Holsapple, C. W. (2008b). DSS Architecture and Types.

In Burstein, F., editor, Handbook on Decision Support

Systems 1, chapter 9, page 854. Springer.

Hosack, B., Hall, D., Paradice, D., and Courtney, J. (2012).

A Look Toward the Future: Decision Support Systems

Research is Alive and Well. Journal of the Association

for Information, 13(Special Issue):315–340.

Jahn, F., Schaaf, M., Paech, B., and Winter, A. (2014). Ein

semantisches Netz des Informationsmanagements im

Krankenhaus. In Informatik 2014, volume LNI P-232,

pages 1491–1498.

Kücherer, C., Jung, M., Jahn, F., Schaaf, M., Tahar, K.,

Paech, B., and Winter, A. (2015). System Analysis

of Information Management. In Informatik 2015, vol-

ume LNI P-246, pages 783–796, Cottbus, Germany.

Lauesen, S. (2005). User interface design.

Pearson/Addison-Wesley, Harlow;Munich.

Paech, B. and Kohler, K. (2004). Task-driven requirements

in object-oriented development. In J. D. Leite, J., ed-

itor, Doorn, Jorge H. Perspectives on Software Re-

quirements., volume 753, pages 1–25. Kluwer Aca-

demic, 2004. Print.

Pourshahid, A., Johari, I., Richards, G., Amyot, D., and

Akhigbe, O. S. (2014). A goal-oriented , business

intelligence-supported decision-making methodology.

Decision Analytics Journal, 9(1):1–36.

Power, D. J. (2011). What are the features of a document-

driven dss? Technical report, DSS News. Accessed:

2016-08-08.

Runeson, P. and Höst, M. (2009). Guidelines for Conduct-

ing and Reporting Case Study Research in Software

Engineering. Empirical Softw. Eng., 14(2):131–164.

Salinesi, C. and Gam, I. (2009). How speciﬁc should Re-

quirements Engineering be in the context of Decision

Information Systems? In RCIS 2009: Proceedings of

the Third International Conference on Research Chal-

lenges in Information Science, pages 247–254, Fez,

Morocco. IEEE.

Saxena, K. B. C. (1991). Decision support engineering: a

DSS development methodology. In Proceedings of

the 24th Annual Hawaii International Conference on

System Sciences (HICSS ’91), volume 3, pages 98–

107.

Schaaf, M., Jahn, F., Tahar, K., Kücherer, C., Winter, A.,

and Paech, B. (2015). Entwicklung und Einsatz einer

Domänenontologie des Informationsmanagements im

Krankenhaus. In Informatik 2015, volume LNI P-246

of Lecture Notes in Informatics, Cottbus, Germany.

Topaloglou, T. and Barone, D. (2015). Lessons from a Hos-

pital Business Intelligence Implementation. Proceed-

ing from CAiSE 2015, pages 19–33.

Van Solingen, R., Basili, V., Caldiera, G., and Rombach,

H. D. (2002). Goal question metric (gqm) approach.

Encyclopedia of software engineering.

Wieringa, R. J. (2014). Design Science Methodology

for Information Systems and Software Engineering.

Springer Berlin Heidelberg, Heidelberg, Germany;

New York, USA; Dordrecht, The Netherlands; Lon-

don, UK.

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

110