Artifacts and Design Knowledge

What is understood by Design Knowledge and what forms can it take?

Edited by Carsten Wiecher and Regina Sonntag

DSR Artifacts and Design Knowledge

The Design Science Research (DSR) paradigm supports a problem-solving process in which knowledge and understanding about a problem area and potential solutions are expanded through the design and application of DSR artifacts (Hevner et al., 2004).

The goal of DSR is to develop design knowledge on how innovative solutions for important problems can be effectively created. Another central element of design knowledge is a proof of evaluation, which shows the extent to which the designed solution can solve the identified problem (vom Brocke et al., 2020).

For the description of the problem as well as the development and evaluation of the solution, Hevner et al. (2004) propose a DSR framework that is divided into three interrelated areas:

  1. A context, described by the fact that people (roles, capabilities, characteristics) within an organization (strategies, structures and cultures, processes) with existing technologies (infrastructures, IT applications, communication platforms, etc.) have an interest in an innovative solution to perform tasks derived from existing business goals.

  2. Research activities for the development of theories and artifacts and an evaluation of the extent to which the addressed problem can be solved with them.

  3. A knowledge base with foundations (theories, models, methods, etc.) that are suitable for the development of the solution and corresponding methodologies (data analysis techniques, validation criteria, etc.) for the evaluation of the results and expansion of the knowledge base.

This division is intended to support the addressing of a problem that is highly relevant for a specific context and, taking into account the existing knowledge base, enables a scientifically sound development of an innovative solution (Hevner et al., 2004). At the center is the developed artifact. Building on this, vom Brocke et al. (2020) describe that knowledge about a problem in a specific context as well as knowledge about possible solutions can exist independently of each other. Accordingly, design knowledge is created by relating the context and its dependent quality criteria (problem space) as well as the representations of possible solutions and their development process (solution space) through the evaluation of artifacts.

Figure 1 illustrates the individual components of design knowledge for a specific DSR project and shows how they are related.

Figure 1: Design Knowledge for a specific DSR project (vom Brocke et al., 2020)
Figure 1: Design Knowledge for a specific DSR project (vom Brocke et al., 2020)

The application of a DSR framework (e.g., according to Peffers et al., 2007) follows an iterative problem-solving process. In doing so, design knowledge in different forms can make a relevant contribution to problem-solving and accordingly expand the knowledge base. Gregor and Hevner (2013) propose a categorization into three different artifact levels, which differ in terms of abstraction and maturity:

  1. Level 1: Applicable instantiation (software, tools, implemented processes) (cf. Hevner et al., 2004)

  2. Level 2: Emerging/partial design theory (methods, models, design principles, technological rules) (cf. Chandra, Seidel, & Gregor, 2015)

  3. Level 3: Comprehensive design theory (cf. Gregor & Jones, 2007)

According to this categorization, a design theory can be developed bottom-up, starting with a new artifact (Level 1), whereby abstraction and maturity can increase with each iteration in the problem-solving process. An important aspect here is that the maturity within the design knowledge can relate to the respective artifact and also to the addressed problem (Gregor & Hevner, 2013). For example, the evaluation of a Level 1 artifact can be used to derive design principles and technological rules (Level 2), but can also lead to a reorientation or narrowing of the problem definition.

Examples of Manifestations

In Wiecher et al. (2019), a Level 1 artifact consisting of a modeling technique and modeling language is described. The artifact was applied in the development of embedded systems in the automotive context. The modeling technique aims to support system engineers in the analysis of requirements to identify contradictions in complex requirement specifications at an early stage and to reduce unnecessary development iterations (context and relation to a business goal). The basis for the development of the artifact is extensive preliminary work from the research fields of requirements modeling and software engineering (foundations/knowledge base).

Based on the application of the Level 1 artifact and the experimental results described in Wiecher et al. (2019), initial technological rules (e.g., to uncover contradictions in functional requirements, apply the method for automated requirements analysis) and empirical generalizations can be defined (e.g., the application of automated requirements analysis leads to contradictions being uncovered that would otherwise only be recognized at later stages of development). Here it becomes clear that new design knowledge arises bottom-up and iteratively. The application also serves to concretize the problem, which can be described, for example, by new requirements for the artifact to be developed (e.g., for the integration of the method into existing development processes, the specification of requirements in natural language must be supported).

References

Next

Last updated on Oct 17, 2024

comments powered by Disqus