# Assessing Digital Platform Requirements from Value Co-creation Perspective

Noor Jungerius, Baris Ozkan, Onat Ege Adali, Oktay Turetken

► To cite this version:

Noor Jungerius, Baris Ozkan, Onat Ege Adali, Oktay Turetken. Assessing Digital Platform Requirements from Value Co-creation Perspective. 23th Working Conference on Virtual Enterprises (PRO-VE), Sep 2022, Lisbon, Portugal. pp.631-644, 10.1007/978-3-031-14844-6_51 . hal-04641997

HAL Id: hal-04641997

https://inria.hal.science/hal-04641997v1

Submitted on 9 Jul 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Assessing Digital Platform Requirements from Value Co-Creation Perspective

Noor Jungerius ¹,ª, Baris Ozkan ¹,ᵇ, Onat Ege Adali ¹,ᵇ,Oktay Turetken¹,ᵇ

1 School of Industrial Engineering, Eindhoven University of Technology PO Box 513, 5600
MB Eindhoven, the Netherlands

ª l.e.jungerius@student.tue.nl, ᵇ {b.ozkan, o.e.adali@tue.nl, o.turetken}@tue.nl

**Abstract.** Digital platforms are transforming industries enabling value co-creation whereby actors exchange and recombine resources in the platform's service system. The digital platform requirements constantly change as the service system value propositions and the resource configurations improve and resource misconfigurations leading to negative value experiences are identified. Therefore, it is imperative for the platform designers to assess the extent to which their platform facilitates platform actors' desired value co-creation at a given time. This paper proposes a value proposition-driven platform requirements assessment method to address this need. More specifically, the method supports the elicitation of requirements based on the value propositions of the desired value co-creation of the digital platform. Subsequently, it supports the assessment of the platform based on these requirements. The method is developed following the design science research methodology, demonstrated in assessing a digital healthcare platform and evaluated by conducting a focus group study.

**Keywords:** Service Systems Engineering, Value Cocreation, Digital Platform, Requirements Engineering.

## 1 Introduction

Digital platforms have become more prominent over the past decade. They are increasingly conceptualized as the enablers of value co-creation, whereby a collaborative network of actors exchange and recombine heterogeneous resources in their service ecosystems [1]. Value propositions—the invitations to engage with the platform for the co-creation of value—are central to value co-creation and thus to the success of a digital platform [1], [2]. Many successful digital platform and value proposition examples can be given from the mobility (e.g., Uber), healthcare (e.g., PatientsLikeMe), and online marketplace (e.g., eBay) business domains, which reflect the multi-actor and the collaborative characteristics of value co-creation.

Despite its attractiveness, the digital platform as a complex and emerging technological artefact involves many design challenges, including identifying and managing platform requirements [2], [3]. These challenges are often related to multi-actor and value co-creative perspectives on requirements [4], as well as the need to manage the constant evolution of the platform service system for its survival [5]. Thus,
platform requirements that emerge due to changes in value propositions, resource reconfigurations, and actors should be identified in the ongoing platform design process. In parallel, resource misintegrations (e.g., system errors, missing information), which cause value co-destruction, should be eliminated to prevent negative value experiences [6]. Therefore, it is imperative for the platform designers to understand at a given time the extent to which the platform can satisfy the needs of the actors of the value co-creation. The traditional IS approaches and requirements evaluation criteria, such as the user acceptance or system quality, fall short of addressing the digital platform's multi-actor, value co-creative and dynamic nature [3], [7]. This paper proposes a method to guide the elicitation of platform requirements based on the desired value co-creation and the assessment of a deployed digital platform on these requirements.

To develop our method, we adopt a service systems engineering view [8] and consider the digital platform as a technology and a complex resource to enable one or more service systems [1], [5]. We follow the design science research paradigm [9] and follow the methodological guidelines and process proposed by Peffers et. al [10]. We demonstrate our method by applying it through a real digital health platform business case and evaluate it by conducting a focus group study.

The remainder of the paper is structured as follows. Section 2 presents the related work. Section 3 elaborates on the research design followed. Section 4 introduces the proposed method and demonstrates its application in a real business case. In Section 5, we present the evaluation of the method. Finally, Section 6 concludes the paper with the limitations of our study and the opportunities for future work.

## 2 Related Work

Identifying and assessing software requirements in a multi-actor socio-technical system context has been an interesting field of research for decades [11]. A significant number of studies followed the conventional goal-oriented approaches and proposed requirement identification methods to bridge the business-level and software-level understandings of what a software system should do [12]. However, only a few studies explicitly account for the value propositions in the requirements identification and assessment process. Lessard et al. [4] adopt a service system view on value proposition design and propose a service systems metamodel and a goal-oriented requirements language for modelling service systems. In addition, they propose a heuristic to guide the elicitation of requirements for the service systems based on their metamodel. Immonen et al. [13] identify the digital services, ecosystem members, infrastructure, and capabilities as the core digital service ecosystem elements and propose a service requirement engineering method to support the development of a digital service. Adali et al. [2] proposed a method to identify platform requirements from value propositions by extending the VP-BSIM method such that requirements are generated the form of UML use cases. To our best knowledge, none of these proposals guides the assessment of deployed platforms based on the requirements derived from the desired value co-creation, which is manifest in the actors' value propositions. The present study addresses this gap.
# 3 Research Design

To perform our research, we adopted the design science research (DSR) paradigm [9] and followed the guidelines and process proposed by Peffers et al. [10]. Accordingly, this research is problem-initiated and involves the following DSR activities:

**Problem identification and motivation:** We provide our research motivation and problem in the introduction section of this paper.

**Identification of solution objectives:** In line with our research aim, we identify three objectives for our method: the method should support the elicitation of requirements of a digital platform based on the desired value co-creation (DO1), the method should support the assessment of a deployed digital platform on the elicited requirements (DO2), and the method should be satisfactory regarding the three criteria of the Technology Acceptance Model [14] namely, usefulness, ease of use, and the use intention of the method's target users (DO3).

**Design and development:** We followed a Situational Method Engineering (SME) approach [15] and applied the extension-based strategy to design and develop our method. Accordingly, the base method, the VP-BSIM, guides the transformation of a set of value propositions into modular, standardized, and contextualized actor resource reconfigurations by repurposing the business services paradigm in the context of service systems engineering [16]. The business services that the VP-BSIM generates describe the functionality of the overall service system; however, not in the form and detail of system requirements (i.e., platform requirements). Therefore, we extended the VP-BSIM with method chunks selected from Dubois et al. [17] to guide the translation of business services into platform requirements and to assess a deployed platform according to the requirements afterwards. To assess the identified platform goals (i.e. platform requirements) (design objective DO2) we adopted the assessment procedure proposed by Horkoff & Yu ([18] that allows the qualitative and interactive evaluation of requirements represented in goal models).

**Demonstration, Evaluation and Communication:** A design artefact should be demonstrated and evaluated according to selected evaluation criteria [9], [10]. The method was demonstrated through its application for a real digital healthcare data exchange platform business case. Subsequently, the method was evaluated in a focus group with practitioners using the guidelines proposed by Tremblay et al. [19] and according to the evaluation criteria set by DO3. The present paper communicates our DSR research as the last research activity of a complete DSR cycle.

# 4 Method Description and Demonstration

In this section, we describe the Extended VP-BSIM platform assessment method (Fig. 1) and demonstrate it in a business case. In Section 4.1, we briefly introduce the business case. In Section 4.2, we present the method steps and illustrate how we applied these steps to the business case.
<figure><img src="image_3.png" /><figcaption>Fig. 1. The Steps of the Extended VP-BSIM (with the original and extended steps)</figcaption></figure>

## 4.1 Business Case: Digital platform for the sharing of digital health data

The Dutch government aims to integrate the citizens into health data exchange. They enacted a new law stating that citizens have the right to freely access and control their health records and are entitled to an electronic copy. To collect all citizen health records and provide them with efficient and integrated mechanisms for health data access and control, the concept of “personal healthcare environment” (PGO in Dutch) platform was developed. We demonstrate our method in the PGO platform developed by a Dutch platform development company. We chose this business case as the company was already in need of assessing and improving the PGO platform according to the expectations of its stakeholders (i.e., platform actors). In the demonstration, the paper’s authors applied the method in consultation with employees from the company and other stakeholders, including the citizen users. During the demonstration, we focused on the “Control of own health data”, which was identified as the core service system value proposition by the platform development company.
## 4.2 The Assessment Method Steps and Demonstration

The first three steps of our method comprise the original VP-BSIM steps, and Steps 4 and 5 represent the extension steps. In the following, we only the summarise the VP-BSIM method steps. For a detailed description of these steps, we refer the reader to the original VP-BSIM paper [16].

**Step 1- Elicit Goals that Actors pursue in the service system to Co-create Value:** The first step of the Extended VP-BSIM constitutes a value proposition-driven analysis to ensure that the business services to be identified enable the co-creation of value outlined by the system service value propositions. This step comprises two sub-steps: In the first sub-step, the service system value proposition is structured by defining the actors’ value contributions/propositions, co-production activities, and costs and benefits in the service system. For this, the service-dominant business model radar (SDBM/R) is employed [20]. In the second sub-step, each actor’s value proposition and co-production activities are decomposed into strategic and intentional dependencies using Strategic Dependency (SD) and Strategic Rationale (SR) models from the i* framework [11]. An SD model provides an intentional description of a process (i.e., value co-creation) in terms of a network of dependency relationships among actors. SR models describe the intentional relationships internal to actors, such as means-ends relationships. As such, the outputs of this step are SD and SR Models that define the strategic and intentional relationships between the actors of the service system.

**Application of Step 1:** The service system value proposition “Control of own health data” was transformed into an SDBM/R blueprint (Fig. 2). Next, SD and SR diagrams were created based on the service system proposition and the individual actors’ value propositions (Fig. 3 and Fig. 4).

<figure><img src="image_4.png" /><figcaption>Fig. 2. SDBM/R for the PGO platform under assessment.</figcaption></figure>
<figure><img src="image_5.png" /><figcaption>Fig. 3 Strategic Dependency model for the PGO platform under assessment.</figcaption></figure>

**Step 2- Identify the Business Capabilities that Enable the Service System to Make the Value Proposition:** The second step of the Extended VP-BSIM focuses on identifying the business capabilities actors need to apply and integrate within their service system to co-create value. This step uses Capability-Business Service Domain Mapping technique [21] to identify the business capabilities that fulfil the intentional and strategic interdependencies defined in Step 1. To identify the business capabilities, first, service domains — collections of tasks called service operations under an actor’s control—are defined. Then, each service operation under a service domain is matched with a business capability that facilitates the service operation in question. The output of this step is a set of business capabilities that enable the actors in the service system to co-create value as outlined by a value proposition. The output of this step is a service domain-business capability matrix provided at (tinyurl.com/2pt62vuf).

**Application of Step 2:** First, the service domains and service operations were identified by analyzing SR and SD diagrams. The process architecture of the PGO company was also analyzed for their verification. Next, the relevant business capabilities of the PGO platform stakeholders were defined and matched to the service operations. This step application resulted in the service domain - business capability matrix in Fig. 5.
<figure><img src="image_6.png" /><figcaption>Fig. 4 Strategic Rationale diagram for the PGO platform under assessment.</figcaption></figure>

**Step 3-Define Modular Business Services Composed of the Business Capabilities:**
The third and final step of VP-BSIM focuses on defining modular business services that describe the functionality of the service system. Furthermore, it formalizes each identified service with a description. This step uses Service Analysis with Feature Binding Technique [22] to compose the business capabilities identified in Step 2 into modular business services. The composition of the business capabilities into business
services is guided by the three design properties such that business services are
stateless, self-contained, and represent a domain-specific service. The business services
are specified using a template provided at (tinyurl.com/2pt62vuf). It should be noted
while the scope of the method in Steps 1 and 2 is the whole service system, in Step 3
the scope changes to a single actor (i.e., the actor utilizing the extended VP-BSIM to
identify its business services), and this step should be repeated for every actor.

*Application of Step 3:* In the demonstration, we applied this step for the actor PGO developer company. In Step 2, Data retrieval, Data transformation, Data viewing, and Data sharing were identified as the PGO developer’s business capabilities. The capabilities were evaluated on the three criteria for modularity, i.e., whether they rely on features or information that reside in another business service and represent a domain-specific service. After this evaluation, Data viewing and Data sharing were identified as modular business services, whereas Data transformation and Data retrieval were merged into one modular business service Data Preparation (Fig. 5). The business service descriptions can be found at (tinyurl.com/2pt62vuf).

<figure><img src="image_7.png" /><figcaption>Fig. 5 Service domain - business capability matrix for PGO business case.</figcaption></figure>

*Step 4: Elicit Requirements Per Business Service:* The goal of this step is to elicit the requirements of the digital platform per business service in the form of a goal tree. For this, the elicitation technique proposed by Dubois et al. [17] is adapted. The goal tree for each business service is created using the template and the procedure in Fig. 6. The input of this step is the modular business services determined in Step 3.

For the modelling of the goal tree, the goal and task concepts from the i* framework
are used [11]. The top-level goal in the goal tree is the business service split into
purposes and the subsequent actions. The left branch describes the functional
requirements related to the purpose of business service execution. This purpose is
broken down into *actions*, modelled as tasks. The second step is to create the right
branch of the goal tree. For this branch, *the non-functional requirements* are elicited.
The starting point for this branch is the management of the business service. The
outcomes associated with this purpose are aligned with the *quality dependencies* as given in the SR model from Step 1. These outcomes in turn, are decomposed into actions. The output of this step is a goal model for each business service.

**Application of Step 4:** The PGO platform requirements per business service were identified by creating a goal tree for all three PGO-developed business services. The goal tree of the business service “Data preparation” is given in Fig. 7. Step-4 was developed to meet the first solution objective (DO1). Using the VP-BSIM outputs as inputs to this step ensured the desired value co-creation was considered throughout the process. Actions at the bottom of the goal tree can be traced back to the business services they support, and subsequently, the business services can be traced back to the desired co-created value. Therefore, traceability to the overall co-created value is established for every action. The template of the goal tree gave appropriate handles to elicit the requirements effectively. Moreover, eliciting the requirements per business service scoped the task of defining the requirements for a digital platform.

<figure><img src="image_8.png" /></figure>

1.1 Set business service unit as top-level goal.

1.2 Capture functional requirements.

1.2.1 Set execution of business service as first (functional) purpose.

1.2.2 Split the first purpose into actions.

1.3 Elicit non-functional requirements

1.3.1 Set the management of the business service as (non-functional) first purpose.

1.3.2 Split the first purpose into quality dependencies, modelled as outcomes.

1.3.3 Decompose outcomes into actions.

<caption>**Fig. 6** Goal tree template adapted from [17].</caption>

**Step 5: Assess Requirements with Current Digital Platform Based on Goal Achievement:** The goal of the fifth and last step is to assess the extent of fulfilment of the requirements by the deployed digital platform. For this, the qualitative and interactive evaluation method for goal-oriented models by Horkoff & Yu [18] is adapted. This step is executed as a workshop involving representatives of the actors of the service system (i.e., platform actors). Accordingly, the platform requirements
modelled in a goal tree per business service (Step 4) are labelled by assessing the level of achievement of the goal by the current platform. The labels are provided in

Table 1. This step is to be iterated for each goal tree. First, the participants label the tasks representing the requirements at the bottom of the goal tree. Next, the labels are propagated through the links to their corresponding actions, outcomes, or purposes. When one action, outcome, or purpose receives multiple labels (i.e., label bag), the rules in

Table 1 are used to determine the final label. Some items may require further assessment per the rules (i.e., human judgement).

<table><caption>**Table 1.** Assessment labels and the propagation rules adapted from [18]</caption><thead><tr><th colspan="6">Assessment Labels</th></tr><tr><th>Satisfied (Full)</th><th>Partially satisfied</th><th>Conflict</th><th>Unknown</th><th>Partially denied</th><th>Denied (Full)</th></tr></thead><tbody><tr><td>✓</td><td>✓</td><td>▲</td><td>?</td><td>✗</td><td>✗</td></tr><tr><th colspan="6">Rules for Label Propagation</th></tr><tr><th>Input</th><th>Resulting label</th><th></th><th></th><th></th><th></th></tr><tr><td>1. There is only one incoming label. Example: Only ✓</td><td>The label<br>Example: ✓</td><td></td><td></td><td></td><td></td></tr><tr><td>2. incoming labels are full and of the same polarity.<br>Example: { ✓, ✓ }</td><td>The full label<br>Example: ✓</td><td></td><td></td><td></td><td></td></tr><tr><td>3. All incoming labels are of the same polarity and a full label is present.<br>Example: { ✗, ✗ and ✗ }</td><td>The full label<br>Example: ✗</td><td></td><td></td><td></td><td></td></tr><tr><td>4. Labels are not all full or not of the same polarity.<br>Example: { ✗, ✓, ▲ }</td><td>Human judgement</td><td></td><td></td><td></td><td></td></tr></tbody></table>

With the completion of this step, all actions, outcomes, and purposes have a label indicating the degree to which they are fulfilled. The output of the method's final step is a goal tree with labels indicating the assessment result of the goal tree.

**Application of Step 5:** In this final step, the deployed digital platform was assessed with the newly elicited requirements represented in goal trees (provided at (tinyurl.com/2pt62vuf)). For this, a workshop was held with representatives from the three most important PGO platform actors. All actions were discussed, assessed and labelled one by one. Finally, the action labels in the model were propagated, resulting in labels for the entire goal tree. The labels that needed a human judgment were reassessed. During the discussions, the participants also discussed the possible improvements to the platform, i.e., how the platform can fully satisfy the requirements derived from this business service. Fig. 7 shows the final goal tree, in which the top-level goal for the business service 'Data Preparation' was found to be partly satisfied by the current platform implementation. This step was incorporated to meet the second solution objective (DO2). Comparing the deployed digital framework with every action in the goal tree side by side enables the assessment of how the digital framework performs on every business service. The labels with their colours gave an efficient and logical overview of the performance of a digital platform on a certain business service.
<figure><img src="image_9.png" /><figcaption>Fig. 7 Assessed goal tree for business service ‘Data preparation’.</figcaption></figure>

## 5 Method Evaluation

In this section, we present the evaluation findings according to our third solution objective (DO3). A focus group of four participants (Table 2) was organized to evaluate the method, following the guidelines in [19]. The method was evaluated according to the three criteria: usefulness, ease of use and the intention to use. The focus group was moderated by the first author of this paper and guided by open-ended questions that reflect the three evaluation criteria.

<table><caption>**Table 2.** Participants of the focus group.</caption><thead><tr><td>Participant</td><td>Stakeholder Type</td><td>Function</td></tr></thead><tbody><tr><td>1</td><td>Citizen</td><td>Intended platform user, the primary platform beneficiary</td></tr><tr><td>2</td><td>Healthcare provider</td><td>IT consultant, responsible for implementing PGos at several mental health institutes in The Netherlands.</td></tr><tr><td>3</td><td>PGO developer</td><td>Managing director, actively involved in the implementation of the Gezondheidsmeter</td></tr><tr><td>4</td><td>PGO developer</td><td>Project manager, responsible for communication with citizens using PGos.</td></tr></tbody></table>

*Usefulness*: Overall, the participants considered the method effective in reaching the goal of eliciting the requirements and assessing a deployed digital platform. The participants agree that the method would be useful to arrive at a consensus when not all stakeholders agree on certain decisions concerning a digital platform. A strength of the method is the clear visualization of the goal tree. The participants deemed the template of the goal tree easy to follow, meaning it gives appropriate handles to elicit the requirements per category. Moreover, it was found successful in capturing problems within the deployed digital platform. However, as the actors are not modelled in the goal trees, the participants found it difficult to trace who was responsible for assessing an action in Step 5.
*Perceived Ease of Use:* All participants agreed that the method was easy to use and understandable. Participant-3 stated: "It took me a minute to fully understand it, but once I got the gist, it was very easy to use". They mentioned that the colours of the labels gave a good overview of the overall assessment of the goal trees. Moreover, the template of the goal tree was found easy to understand. The definition of the labels was not always found completely clear. Participant-3 mentioned this as a weakness: "Sometimes we used an orange conflict label when we could also use a green partially satisfied label. The criteria for when to use what label was not completely clear to me.". This issue was not considered a problem during the assessment, as the participants discussed the decision, but afterwards, when sharing the results with other parties that were not present at the assessment.

*Intention to Use:* Overall, the participants evaluated the method less positively with respect to this criterion than the other two. The participants found the method more suitable for the use of requirement engineers, who would use an elicitation and assessment tool in their work. However, participant-2 acknowledged the added value of the method by stating: "I am charmed by the simplicity of the method."

Based on the evaluation findings, two directions were identified for the improvement of the method: (1) *Establishing traceability between requirements by visualizing actor dependencies:* The lack of visualization of the actor dependencies in the goal trees resulting from Step-4 of the method was considered a limitation of the method. To improve the method, further extensions that allow visual traceability could be investigated, such as creating additional SD and SR diagrams or incorporating goal tree actions into specification models such as UML activity diagrams [17]. However, when considering this, the ease of use for users who are not experts in requirements engineering should not be forgotten, and method complexity should be avoided. (2) *Improvement of assessment labelling:* An evaluation finding was that some labels could be used interchangeably and cause communication issues when not documented. An additional documentation substep in Step 5.1 could improve the method on this aspect.

# 6 Conclusion and Future Work

In this paper, we proposed a method for the assessment of a digital platform based on the requirements identified from the desired value co-creation to be enabled by the platform. To develop the method, we adopted design science research and extended the VP-BSIM method by applying situational method engineering. We demonstrated the method by applying it for the assessment of a personal healthcare environment platform and evaluated the method in a focus group study.

The scientific implication of our study is establishing links between high level value co-creation concerns and low-level platform requirements by adopting a service system engineering approach. Our method encompasses the entire process for the assessment of a digital platform on the desired value co-creation. The practical implication of our research is the methodological guidelines provided for the practice of the platform development in which multi-actor design and value co-creation are central concerns.

Our research is subject to several limitations. In the evaluation, the focus group was limited to four attendees of three actor types. Another limitation is that our evaluation
was based on a single instantiation of the method. Applying the method to multiple and different contexts and having more participants will provide more findings and evidence concerning the validity and utility of our method. Additionally, the intention to use could be evaluated more precisely when more requirements engineers are involved in the focus groups.

Future research would ideally investigate the improvement directions as stated above. Additionally, the method is intended for the assessment of a deployed digital platform. However, the method might also prove to be useful when a platform is yet to be designed, for example, in greenfield development, when one starts a business from scratch. The method might assist business developers in creating a platform that adheres to the intended value co-creation and involves all stakeholders in the development process. The method can also be applied to “from the scratch” platform development projects to evaluate if the method is indeed useful for these situations. Finally, future research can investigate incorporating the aspects of participatory and human-centred design methods[23] into the method for the enhancement of collaborative decision making.

# 7 References

[1] R. F. Lusch and S. Nambisan, “Service Innovation: A Service-Dominant Logic Perspective,” *MIS Quarterly*, vol. 39, no. 1, pp. 155–175, Jan. 2015, doi: 10.25300/MISQ/2015/39.1.07.

[2] O. E. Adali, B. Ozkan, O. Turetken, and P. Grefen, “Identification of Service Platform Requirements from Value Propositions: A Service Systems Engineering Method,” presented at the PRO-VE, France, 2021.

[3] M. de Reuver, C. Sørensen, and R. C. Basole, “The Digital Platform: A Research Agenda,” *Journal of Information Technology*, vol. 33, no. 2, pp. 124–135, Jun. 2018, doi: 10.1057/s41265-016-0033-3.

[4] L. Lessard, D. Amyot, O. Aswad, and A. Mouttham, “Expanding the nature and scope of requirements for service systems through Service-Dominant Logic: the case of a telemonitoring service,” *Requirements Eng*, vol. 25, no. 3, pp. 273–293, Sep. 2020, doi: 10/ghndjz.

[5] M. Blaschke, K. Haki, S. Aier, and R. Winter, “Capabilities for Digital Platform Survival: Insights from a Business-to-Business Digital Platform,” 2018, p. 17.

[6] G. Laud, L. Bove, C. Ranaweera, W. W. C. Leo, J. Sweeney, and S. Smith, “Value co-destruction: a typology of resource misintegration manifestations,” *Journal of Services Marketing*, vol. 33, no. 7, pp. 866–889, Jan. 2019, doi: 10.1108/JSM-01-2019-0022.

[7] K. Haki, M. Blaschke, S. Aier, and R. Winter, “A Value Co-creation Perspective on Information Systems Analysis and Design,” *Bus Inf Syst Eng*, vol. 61, no. 4, pp. 487–502, Aug. 2019, doi: 10/ghm4sr.

[8] T. Böhmann, J. M. Leimeister, and K. Möslein, “Service Systems Engineering,” *Bus Inf Syst Eng*, vol. 6, no. 2, pp. 73–79, Apr. 2014, doi: 10/f5vz43.

[9] Hevner, March, Park, and Ram, “Design Science in Information Systems Research,” *MIS Quarterly*, vol. 28, no. 1, p. 75, 2004, doi: 10.2307/25148625.

[10] K. Peffers, T. Tuunanen, M. A. Rothenberger, and S. Chatterjee, “A Design Science Research Methodology for Information Systems Research,” *Journal of Management*
*Information Systems*, vol. 24, no. 3, pp. 45–77, Dec. 2007, doi: 10.2753/MIS0742-1222240302.

[11] E. S. K. Yu, Ed., *Social modeling for requirements engineering*. Cambridge, Mass: MIT Press, 2011.

[12] J. Horkoff et al., “Goal-oriented requirements engineering: an extended systematic mapping study,” *Requirements Eng*, vol. 24, no. 2, pp. 133–160, Jun. 2019, doi: 10.1007/s00766-017-0280-z.

[13] A. Immonen, E. Ovaska, J. Kalaoja, and D. Pakkala, “A service requirements engineering method for a digital service ecosystem,” *Service Oriented Computing and Applications*, vol. 10, no. 2, pp. 151–172, 2016.

[14] F. D. Davis, “Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology,” *MIS Quarterly*, vol. 13, no. 3, p. 319, Sep. 1989, doi: 10.2307/249008.

[15] J. Ralyté, R. Deneckère, and C. Rolland, “Towards a Generic Model for Situational Method Engineering,” in *CAiSE*, Berlin, Heidelberg, 2003, pp. 95–110.

[16] O. E. Adali, B. Ozkan, O. Türetken, R. A. Gilsing, and P. Grefen, “A Method to Transform Value Propositions of a Service System into Business Services,” presented at the ECIS 2021, 2021.

[17] E. Dubois, S. Kubicki, S. Ramel, and A. Rifaut, “Capturing and aligning assurance requirements for business services systems,” in *Business System Management and Engineering*, Springer, 2012, pp. 71–92.

[18] J. Horkoff and E. Yu, “Evaluating goal achievement in enterprise modeling–an interactive procedure and experiences,” in *IFIP Working Conference on The Practice of Enterprise Modeling*, 2009, pp. 145–160.

[19] M. C. Tremblay, A. R. Hevner, and D. J. Berndt, “The Use of Focus Groups in Design Science Research,” in *Design Research in Information Systems*, vol. 22, Boston, MA: Springer US, 2010, pp. 121–143. doi: 10.1007/978-1-4419-5653-8_10.

[20] O. Turetken, P. Grefen, R. Gilsing, and O. E. Adali, “Service-Dominant Business Model Design for Digital Innovation in Smart Mobility,” *Bus Inf Syst Eng*, vol. 61, no. 1, pp. 9–29, Feb. 2019, doi: 10.1007/s12599-018-0565-x.

[21] T. Kohlborn, A. Korthaus, T. Chan, and M. Rosemann, “Identification and Analysis of Business and Software Services—A Consolidated Approach,” *IEEE Transactions on Services Computing*, vol. 2, no. 1, pp. 50–64, Jan. 2009, doi: 10.1109/TSC.2009.6.

[22] J. Lee, D. Muthig, and M. Naab, “An Approach for Developing Service Oriented Product Lines,” *Limerick, Ireland*, Sep. 2008, pp. 275–284. doi: 10.1109/SPLC.2008.34.

[23] K. Freire, D. Sangiorgi, and others, “Service design and healthcare innovation: From consumption to co-production to co-creation,” in *Service Design and Service Innovation conference*, 2010, pp. 39–50.