Using empirical knowledge and studies in the frame of design science research

Authors:
Ilia Bider;Paul Johannesson;Erik Perjons
Affiliations:
DSV, Stockholm University, Stockholm, Kista, Sweden,IbisSoft AB, Stockholm, Stockholm, Sweden;DSV, Stockholm University, Stockholm, Kista, Sweden;DSV, Stockholm University, Stockholm, Kista, Sweden
Venue:
DESRIST'13 Proceedings of the 8th international conference on Design Science at the Intersection of Physical and Virtual Design
Year:
2013

Citing 4
Cited 0

Design science as nested problem solving

Proceedings of the 4th International Conference on Design Science Research in Information Systems and Technology
User acceptance of information technology: toward a unified view

MIS Quarterly
The contingent effects of management support and task interdependence on successful information systems implementation

MIS Quarterly
Design science in information systems research

MIS Quarterly

Quantified Score

Hi-index	0.00

Visualization

Abstract

The focus of this research in progress is relationships between Design Science Research (DSR) on one hand, and Empirical Research (ER) on the other. More specifically, it is devoted to investigating which tasks included in a DSR project should/could require conducting ER studies or using already existing ER knowledge. The paper presents a methodology for enumerating DSR tasks and gives examples of logical analysis of some of them to determine requirements or usability of ER studies or ER-related knowledge for completing these tasks. The enumeration of DSR tasks is done by considering possible trajectories of DSR projects in a specially constructed state space. The latter consists of two subspaces; one is the space of specific situations, problems and solutions, the other --- of generic situations, problems and solutions. The first subspace represents test cases used for validating DSR hypotheses that the second subspace represents. In the terms of this space, DSR is considered to be a way of generating and testing hypotheses for future adoption. The project trajectory is identified via movements within and between subspaces. Examples of such movements are: generalization of a specific situation/problem, designing a generic solution, evaluating the results of implementing a solution in a specific situation.