Keywords

1 Introduction

Customers are looking for solutions and benefits, forcing the manufacturer to give increasing attention to understand and answer their problems over the whole life cycle. Product-Service Systems (PSS) emerge as a result through the integrated development, realization and application of tangible and intangible components for a common objective. Additionally, new levels of human-machine interaction have become possible and more widespread, paving the way for reliable, sustainable, technology-driven ecosystems [1]. As a result, Cyber-Physical Systems (CPS) integrate embedded systems, application systems, and infrastructure in complex networks [2]. They follow a holistic system approach, requiring the collaboration of different disciplines such as mechanical engineering, electrical engineering, and computer science for their realization [1]. The collaboration with stakeholders from different disciplines as partners during Requirements Engineering (RE) becomes more and more important. The high number of components involved in the system and its evolution along the life cycle require the RE approach to adapt to a volatile set of user requirements, evolving over the life cycle as the technical development continues and the needs of the different customers and stakeholders change over time.

Consequently, for CPS based PSS the need for continuous interaction between the development process and the requirement elicitation process is inevitable for ensuring a consistent and traceable elicitation and management of requirements [3]. This requires new elicitation approaches and tools, being more flexible, dynamic and considering future needs even before they have appeared, in order to reduce the costs and the quality challenges arising from this dynamic environment, i.e. there is a need for a collaborative approach of all stakeholders involved in the entire product life cycle. This article present the first results of a gamified approach for the requirements elicitation for CPS based PSS that can be applied in such dynamic environments. The work is based on a RE framework that enables a symbiotic specification of dynamic systems in a collaborative way along the whole value chain.

2 Methodology

For the development of the gamified approach, we combine literature review and action research. In a first step, the relevant characteristics of CPS based PSS and the RE process are identified. Secondly, several existing approaches that might serve as a good basis for the gamification will be assessed for their suitability. The main assessment criteria are to what extent the existing approaches and methodologies are transferable to CPS based PSS, as well as to what extent it appears likely that their re-use or adaption will contribute to improved quality of requirements elicitation. Thirdly, based upon this analysis, existing gamification approaches can be further developed or changed in order to address these points.

For the literature review, scientific papers were accessed through suitable portals (Scopus, Elsevier, Google Scholar etc.) searching for key words (serious games + requirement elicitation, product-service systems, cyber-physical systems, Requirements Engineering, dynamic systems) [4]. The relevance of the identified papers for this article was based on assessing the abstract, as well as by searching for the combination of elicitation, PSS and CPS in the full papers, considered being the most challenging, and that there is a need of tools supporting the process.

The work with four industrial use cases had a different methodical approach. The researchers have been involved in the specifications and development of the CPS/PSS scenarios. Design Science was the overall scientific approach in this work. More specific, action research was applied. The game has been developed using an agile software development approach.

3 Requirements Engineering Approaches for CPS Based PSS

From the PSS definitions, the main components to be covered in an integrated approach are tangible product and intangible service shares jointly fulfilling a users need [5, 6]. Additionally, IT components, such as software, are becoming more and more a distinct part of PSS [7], ultimately leading to the provision of services through CPS [8]. In order to derive the challenges for requirements elicitation for CPS based PSS, the specific characteristics of the separate components and their development processes are described below.

For product development, RE approaches have already been implemented with a high degree of formalization. Structured fundamental models exist that provide a general development procedure including RE. However, they focus almost exclusively on requirements development as the main process, which is only conducted at the beginning of the development approach, e.g. by specifying the product requirements document [9]. Sometimes, also aspects of requirements management are adopted, but without explicit instructions for implementation [10]. For requirements elicitation, first, the stakeholders are identified; however, procedures for the elicitation of requirements for product-related services are not described. Moreover, there are weaknesses in the derivation of requirements from the customers value chain processes, and cross-domain knowledge is not considered [11].

Models for the systematic development of services have been created [12]. However, no systematic procedures for the implementation of RE have been established, because the characteristics of a service, e.g. its complexity, pose greater challenges. Thus, service engineering procedures do not integrate a holistic RE until now, but focus more on methods like “trial and error” [13]. The elicitation process in service engineering comprises the tasks of identifying essential information – e.g. service ideas, possible customers and their expectations, and the sources of the requirements – and determining the goals, chances and risks. The procedures are service-domain specific; cross-domain knowledge is not considered. Furthermore, no precise methods for the elicitation are provided. Procedures for the requirements elicitation are described on a relatively general level [10].

In the IT sector, RE is widely recognized as a special discipline; RE “has begun to evolve from its traditional role, as a mere front-end in the software development lifecycle, towards becoming a key focus in the software development process” [14]. In direct comparison with product and service development, RE is integrated deeper and more comprehensive into software development [10]. Customer-integration is emphasized in the software engineering approaches, but the focus is laid upon the software domain – interdisciplinary requirements are not considered. The procedures provided for the identification of conflicts focuses solely on the software domain; interdisciplinary conflicts are not discovered. Negotiation with stakeholders is suggested to resolve conflicts and find a compromise [11].

4 Gap Analysis

According to [11], the literature about PSS development and design discusses the process of development only abstractly without going into detail. Firstly, the “organizational conditions are created in order to enable an integrated development of services and hardware/software”. The stakeholder needs – regarding products and services – are identified. Concrete techniques or methods are not mentioned. Current RE approaches are not able to handle the large number of different and conflicting requirements without exponentially increasing time and cost, as contradictions and interdependencies have to be assessed for a large number of requirements in various domains [15].

Based on this gap analysis, requirements elicitation for CPS based PSS has to be formal enough to describe the targeted system unambiguously and in a verifiable way, but has to have the flexibility to include non-formal inputs. The different stakeholder needs and changing requirements must be managed. As the functionalities of a PSS emerge from the cumulative interactions of the product, service and IT components, elicitation methods and tools have to be able to integrate the mechanical, service and IT domain for capturing requirements. These requirements have to be mapped subsequently to the different PSS elements, to be either fulfilled by a physical functionality or a cyber-service execution. Berkovich et al. [16] propose to apply the Domain-Mapping-Matrix (DMM) to relate the requirements with the PSS functions. This implies communication between stakeholders from different disciplines and that the following aspects have to be observed:

  • Complexity: Elicitation has to be able to handle a large number of interrelated product, service and IT requirements.

  • Distributed stakeholders: Elicitation has to be applicable for a large number of stakeholders that are typically separated spatially and organizationally. This involves the user, who defines the scope and purpose of the PSS, as well as specialized partners with distinct processes, which develop the individual system components.

  • Different disciplines: The elicitation approach has to be usable in multiple disciplines. Requirements exchange has to be supported in order to create a common view of the targeted system.

The following sections will describe how a gamified approach could support requirements elicitation to fulfill the preconditions above.

5 Gamification

A gamification of RE activities does not imply turning PSS development into a game. It means using game-based elements and mechanisms in this non-game environment with the purpose of employing the motivational properties of games [17]. Thus, the gamification components and elements need to be designed and adapted to the context of RE for cyber-physical Product-Service Systems. To do so, it is necessary to establish clear goals and rewards, mechanisms of progression, intermediary and final statuses, challenges, as well as avoiding to manipulate users into following certain patterns that are unlikely to take otherwise, relying too much on extrinsic motivational factors [18].

The objective of a gamified requirements elicitation would be to make the work routine of need identification more effective. The outcome of the game could be initial ideas, but also imply “options”, e.g. solutions for specific problems. One advantage of this approach compared to other current techniques is the motivating aspect, which could reduce the frustration in an idea generation process. The game can easily contain multiple and contradictory knowledge structures and promote discussion and reframing of ideas. At the same time, gamification provides incentives to change existing culture, routines and behaviour. Additionally, the game can develop explicit routines for team-based ideation work, together with a technological infrastructure that allows for communication about, and experimentation with more or less finished ideas, early stage innovations and concepts not yet implemented. The objective for the elicitation process would therefore be to play with different options in a virtual environment for discovering the limitation of the defined requirements as well as to use the virtual environment to support the ideation of new possible services. The final criteria for why incorporating gamification in elicitation is the possibility to provide the user with immediate feedback on how the decision or a change in a variable will influence the system configuration for validation.

We decided to use “Unity” as game engine [19], so that the player can get an individually adapted end user scenario without having the need of reprogramming. The game is as much as possible adapted to the known business environment of the industrial cases, with a direct and participatory involvement of stakeholders. Based on these considerations, the gamified environment needs to:

  • Involve all stakeholders independent from location or organization, which could be done using internet-based games.

  • Mirror the working environment for each role sufficiently, which requires an analysis of each stakeholders work processes.

  • Support the users possibility to contribute to a disruptive innovation, e.g. by providing support for out-of-the-box thinking without limiting ideas.

  • Visualize the consequences of the defined requirement, e.g. for other requirements and the resulting solution.

The above-mentioned boundaries lead to the following consideration on how to prepare a gamified environment. In the engine, we mapped the existing to-be scenarios and the preliminary user requirements. These requirements are included as functions, where the player can change the variables. We use narrative story telling for leading the player through the game play. It is facilitated and the roles are similar to those in their own companies.

6 Use Case

The gamification approach has been successfully applied in three industrial PSS use cases and is currently being prepared for an additional cyber-physical Product-Service System scenario. The company is a vendor for the aviation sector, which offers fully integrated solutions for surveillance systems, certified according to aviation standards. Customers are airlines, which retrofit their aircraft with the buyer furnished surveillance solutions from the vendor. It generates video streams, which are stored on a memory cartridge within the Central Video Unit (CVU/DVR). The idea is to use this product and extend it with different services. The scenario is depicted in Fig. 1 below.

Fig. 1.
figure 1

Cabin Video Surveillance System (CVSS) scenario

Based on a to-be analysis and a first specification of the end user needs, the following restrictions for service development have been identified:

  • The product in the aircraft (CVU/DVR) must not be modified.

  • The product outside of the aircraft - as for instance the Ground Station (where the data are viewed) – can be modified. For the service-based Aircraft Surveillance System modifications of the hardware (e.g. internal hard drive to copy the data to) as well as software are required.

  • In addition, processes within the company has to be re-viewed and re-organized, thus resulting in several as well as radical changes.

Thus, the requirements need to be defined for a fuzzy area, since it is expected that the service the aircraft vendor would like to offer will be customized and in addition, since nothing similar exists, be adaptable to still uncovered needs. The game play starts with a screen that allows the players to enter their name and role (e.g. production, sales etc.) according to their position in the company. Through storytelling, they get the task to develop a cyber-physical Product-Service System, e.g. for an airline that wants a specific service. The players are then able to specify requirements for support in this process from the perspective of their role. They have the possibility to look into an existing repository for similar already existing ideas and requirements or write their own. The different players look at the challenge from different perspectives and provide ideas for the other roles requirements. The results are then displayed by the game and can be rated by all players. Based on the ratings, the players discuss the best ideas to create an integrated solution. This ends the game and it can be restarted iteratively to discuss more requirements and ideas.

The game scenario has been implemented as described above. Additional game mechanics related to KPIs (costs, time, quality, and possible market price), interaction and collaboration could be added. Letting the player first play around with the system and the data that can be collected will make him aware of the CPS environment and its limitations. Furthermore, in order to foster the creativity and to think out of the box, different events may trigger the game play in future releases, and the players are obliged to use tools (like a modelling tool for products or services) in the phase where they are normally not used – e.g. in the test phase. The idea is here to support the critical thinking and to let the player verify that the tool is flexible enough to react on future needs.

7 Conclusion

This paper first outlines the challenges that are related to the requirements elicitation process of CPS based PSS. It discusses the challenges that arise from the fact that the requirements for such complex systems being applied in a dynamic environment need to involve distributed stakeholders from different disciplines. The second part of the article presents a gamified approach for PSS. The approach has been applied in three industrial use cases with good results.

It is able to meet the needs defined in Sect. 5, with regards to the gaps identified in Sect. 4. Gamification is able to involve all stakeholders in a servitization scenario. While the approach currently only includes company roles, it is no problem to extend it to third party suppliers, service providers and the customer. As it is playable over the internet, also distributed partners can be involved. The role model also allows the game to sufficiently mimic the working environment of the players from different disciplines by simulating specific tools, office spaces and work processes. Disruptive innovation is supported by giving the player the freedom to enter ideas independently from existing solutions and share them beyond domain borders. Finally, the ideas are discussed collaboratively by all stakeholders, thus taking into account their needs to define a suitable solutions despite the inherent complexity.

Future research and development needs to strengthen simulation as game component, to give the players a more realistic environment and prediction of results. This would strengthen the feedback to the players and contribute to more dynamic and detailed requirements as an outcome.