As product service systems (PSS) have specific characteristics, they impose special requirements on requirements engineering (RE) that are initially explained by means of nine criteria. Based on that, main approaches of RE in product, software, and service engineering as well as integrated approaches are evaluated in terms of their suitability for PSS. The result shows different maturity levels of RE in all domains, being highest in product and software engineering. However, we must note a major deficit in the overall cooperation due to the individual concepts of the respective domains. A direct transfer to other areas, as needed for PSS, is not possible.
1 Introduction
Recently, manufacturing companies and service providers are faced with new challenges in terms of increasingly competitive pressure and more complex customer requirements. Offering goods or services is often not sufficient for companies to differentiate themselves from competitors (Leimeister and Glauner
2008). Further, customers do not want products or services per se, but they demand individual solutions of their problems. As a consequence, many vendors are changing their strategy from “product-centric” to “customer-centric” (Galbraith
2002), and becoming solution providers (Davies
2004). By supplying a customized and integrated bundle of hardware, software, and service elements, the customer problem is solved completely. These bundles are known as product service systems (PSS) or hybrid products (Becker et al.
2008).
A well-known example for PSS represents photocopiers in the context of the “performance-based pricing” model in the commercial sector (the user only pays for printed pages; he does not buy a photocopier and does not maintain it). In the IT industry, software as a service describes a widespread PSS (Böhmann et al.
2008). This business model includes standard software offered as a service, accessible via the Internet, and adapted to customer’s wishes (Böhmann and Krcmar
2007). Additionally, the hardware component, optimized in the computer center of the provider and utilized for high-performance data storage, also contributes to the market success of the solution (Grohmann
2007).
Motivation. The development of PSS is mainly affected by the coordination of the involved domains, such as product, software, and service engineering (PE, SE, SER, respectively), by the different life cycles of the components and their interdependencies, as well as by a high degree of customer interaction (Sturm and Bading
2008). In order to handle the resulting complexity, a complete understanding of the overall solution and its features is essential. In this connection, requirements engineering (RE) plays a key factor (Cheng and Atlee
2007). Its main tasks comprise the extensive identification of the solving problem in form of requirements and constraints, their management, traceability, and description in an adequate level of detail throughout all development stages (Hull et al.
2004, pp. 6–8). In literature, none of the RE approaches takes the requirements to PSS into full account. Moreover, a structured collection and analysis of the criteria for a successful RE concerning PSS do not exist.
Objective and contribution. The objective of this article is to point out all requirements that have to be fulfilled by the RE of PSS, and to determine the suitability of existing RE approaches for PSS. Thereby, the selection criteria are based on the main characteristics and RE tasks area in the lifecycle of PSS. They serve for the identification of research deficits in RE for PSS. The results of this work are a basis for future research in the area of RE for PSS, with the goal of creating an integrated requirements management for PSS and a development approach for PSS relying thereupon. To achieve this, first, a conceptual and logical connection between the requirements models of PE, SE, and DE needs to be achieved.
Preliminaries. The presented literature analysis is based on other publications, which either contain domain-specific analyses of RE approaches in product engineering (Berkovich et al.
2009c) as well as preliminaries of the analytical framework (Berkovich et al.
2009a), or refer to empirical studies of RE methods in practice and their challenges in the development of PSS (Berkovich et al.
2009b). Additionally, process models for the development of PSS were analyzed with regard to their coverage of the various life cycle phases and of the involved domains (Langer et al.
2010). Furthermore, a reference framework for an integrated RE model concerning PSS was developed (Berkovich et al.
2010). Picking up on this, the following article extends the present scheme of analysis significantly, by deriving it from a life cycle assessment of PSS and using it for the subsequent literature analysis. Even the criteria, as well as the referenced sources, were refined substantially and extended, respectively.
Structure. The structure of the rest of this paper is orientated towards the implemented steps.
Section
2 contains a methodology for the literature search and analysis. Section
3 introduces related works, after which Sect.
4 illustrates the different tasks of RE in the life cycle of PSS. Section
5 describes the derivation and explanation of the analysis criteria, with Sect.
5.1 describing the framework used to introduce the evaluation criteria of the analyzed literature in Sect.
5.2. Section
6 then summarizes the identified approaches in order to give an overview of the existing literature. Subsequently, the results of the literature analysis are presented in accordance with the criteria of Sect.
5. Section
7 then discusses the analysis and evaluates it. Section
8 concludes the article with a summary and outlook for future research.
2 Methodology
As the number of academic studies increases, systemic and exhaustive literature analyses become more and more important (Webster and Watson
2002). A literature analysis enables the collecting of existing experience and knowledge of one particular aspect derived from both science and practice, thus identifying gaps in research (Budgen and Brereton
2006).
To ensure the scientific value of a literature analysis, it is necessary to pay special attention to an intersubjectively verifiable study design and procedure (Torraco
2005). Accordingly, the analysis in this paper is based on the approach of Webster and Watson (
2002), which is characterized by the assignment of the concepts present to the respective authors. The procedure and structure of the paper, however, have been extracted from the approaches of Brereton et al. (
2007) and Kitchenham et al. (
2009). The individual steps of our approach are shown in the Appendix 1 (available online). Thus, the central question of the literature analysis is: “To what extent are the selected domain-specific approaches of RE suited for PSS?” and “Which of these can be used in the development process of PSS?”
Due to the different terms and understanding of RE in product, software, and service engineering, an individual literature search was performed for each domain. For searching the relevant literature, the portal “Google Scholar” was chosen, which covers a major part of the journals and electronic publications in informatics as well as in engineering. Meier and Conkling (
2008) have shown that 90% of the publications in engineering, published after 1990, are available in “Google Scholar.” In the field of computer science, important publishing companies (e.g., Elsevier) and non-profit organizations (e.g., ACM or IEEE) provide different articles in this section (Meier and Conkling
2008; Jacsó
2008).
All hits of the search portal were sorted by the frequency of their citations. Afterwards, the 100 most cited articles of each domain were examined and sorted into the following categories:
(a)
Articles that constitute a generic approach/process model: the generality and spread of the respective article comprised the selection criteria for this category (see Goeken and Patas
2010).
(b)
Articles describing a specific topic of RE: this category includes articles addressing specific topics of RE, such as different activities and techniques. Each article in this category is mapped to an RE activity proposed by the generic approaches.
(c)
Articles that do not consider RE: these papers are not considered here.
In
Tab.
1
the sources of the literature describing generic approaches are listed. The specific sources are referenced in the Appendix 1 (available online).
Table 1
Analyzed approaches
• | Vorgehenszyklus für die Lösungssuche (Ehrlenspiel 2002) | • | Requirements Engineering Framework (Pohl 1993, 2007) | • | Design and Management Service Processes (Ramaswamy 1996) | • | Integrated Product and Service Engineering versus Design for Environment (Lindahl et al. 2007) |
• | Engineering Design (Pahl et al. 2006) | • | Requirements Engineering Process (Kotonya and Sommerville 1998) | • | Key Concepts for New Service Development (Edvardsson and Olsson 1996) | • | Vorgehensmodell der hybriden Produktentwicklung (Spath and Demuß 2003) |
• | Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte (VDI 2221 1993) | • | Requirements Engineering Process (Lamsweerde 2009) | • | Ein Rahmenkonzept für die systematische Entwicklung von Dienstleistungen (Bullinger and Schreiner 2003) | • | Life Cycle Management of Industrial Product-Service Systems (Aurich et al. 2007) |
• | Product Design and Development (Ulrich and Eppinger 2003) | • | A Generic Process for Requirements Engineering (Hull et al. 2004) | • | Dienstleistungsproduktion (Frietzsche and Maleri 2003) | • | Rahmenkonzept zur Entwicklung von Product-Service Systems (Botta 2007) |
• | Erfassen und Handhaben von Produktanforderungen (Ahrens 2000) | • | Engineering and Managing Software Requirements (Aurum and Wohlin 2005) | • | Anforderungsanalyse für produktbegleitende Dienstleistungen (Husen 2007) | • | Systematische Überfuhrüng von kundenspezifischen IT-Lösungen in integrierte Produkt-Dienstleistungsbausteine mit der SCORE-Methode (Böhmann et al. 2008) |
Literature related to the topic of RE for PSS can be divided into two parts:
(a)
analyses and literature reviews of RE issues in the different domains that do not consider PSS, and
(b)
research and analysis of process models for the development of PSS.
The first category includes articles about analyses of existing literature on RE. Byrd et al. (
1992) have analyzed techniques for requirements elicitation and knowledge acquisition regarding their similarities and differences. Wieringa et al. (
2006) have developed a classification scheme for contributions to research on RE. The goal of their classification scheme is to detect the different types of scientific articles, but not to identify different topics within RE. Hickey and Davis (
2003) have collected several criteria by means of interviews that can be used by requirements analysts to select from a wide range of techniques for requirements elicitation. Thus, they focus on the selection criteria and not on comprehensively listing RE techniques.
The second category includes articles about literature analyses of process models for PSS. For instance, Gräßle and Dollmann (
2010) describe process models for the development of PSS, whereby they analyze the composition and structure of process models. Thus, they do not describe RE in detail, but only mention it as one important life cycle activity within the development process. It is thus not possible to derive criteria from this article for the structuring of task areas for RE for PSS.
The articles of the first section focus on software engineering; however, they cover only certain RE activities and primarily present criteria for the analysis of the RE techniques that are offered for the RE activities. However, none these articles includes a comprehensive analysis of the RE task areas. The publications of the second section, as well as our previous work (Langer et al.
2010), deal with the issue of process models that consider RE only rudimentarily. Single task areas of RE are not analyzed in these works.
4 Requirements Engineering in the Life Cycle of PSS
In order to clarify the role of RE in the life cycle of PSS, we contrast the task areas of RE and the life cycle phases of RE, bearing in mind the characteristics of PSS. RE has the goal of systematically determining the requirements to a product correctly and completely (Byrd et al.
1992). In this way, RE creates the basis for all following development steps (Spath and Demuß
2003). As errors in the requirements specifications often cause project failures and cost-intensive changes at a later point in time (Pohl
2007), RE is seen as a crucial factor in the development process. According to Pohl (
2007), RE should therefore elicit all requirements, analyze and represent them in a necessary degree of detail, reach a sufficient agreement on the known requirements, and document them in accordance with defined directions. If any changes in the requirements occur, RE should also offer corresponding measures to handle the changes.
According to Tuli et al. (
2007), the life cycle of PSS comprises four main phases, namely, customer requirements definition, customization and integration of goods and/or services, deployment, and postdeployment customer support. These phases and their relation to RE are described in the following section.
Customer requirements definition: In this phase, the requirements to the PSS are elicited and analyzed (Spath and Demuß
2003). Particularly, the customer needs are in the foreground of requirements elicitation, since they serve as a basis for the subsequent implementation (Sawhney
2006). By fulfilling this type of requirement as best as possible, PSS create high added value in the form of an individual
problem solution for the customer that cannot be realized by consuming standardized products or services. It is thus important to interact with the customer in the entire development process, from requirements elicitation to requirements validation (Tukker
2004). The elicited requirements must be validated and verified in cooperation with the customer (Tukker
2004).
Requirements emanating from the value creation processes of the customer must also be elicited because the PSS is
integrated into the value chain processes of the customers after its deployment (Böhmann and Krcmar
2007; Zellner
2008). The PSS has to be developed in a way that it can be integrated into the customer’s existing system environment.
Furthermore, the perspectives on the different domains have to be considered in requirements elicitation of PSS. This is attributable to the
bundling of material and immaterial components that are not recognizable as individual parts in the final solution, but they are formative for the characteristics of the PSS (Leimeister and Glauner
2008).
Having collected all relevant requirements, they are documented in a way that provides a common understanding for all domains participating in the development process. Based on the documented requirements, the modules that are understood as components of the PSS for the solution are designed. Additionally, the existing modules are evaluated for their reusability. In this context, modularization means that the PSS consists of different modules or components or partial services (Böhmann et al.
2008; Beverungen et al.
2008).
Although
modularization does not constitute a defining characteristic of PSS, it is essential for the reusability of the existing components as well as for a flexible adaptation of the PSS based on existing modules to changing customer wishes (Beverungen et al.
2009). Consequently, the modules can be standardized and recombined for creating various products. Therefore, RE must identify existing components and services, and combine them into modules in order to prevent their redevelopment.
In the next step, a product structure consisting of material and immaterial components is created to illustrate the complete PSS. To achieve this, RE has to concretize the solution-independent target properties (initial requirements) written in the language of the stakeholders. Concretization means the requirements are supplemented with detailed qualitative and quantitative information, and they are translated into solution-oriented design requirements that are divided according to hardware, software, and service elements and that are composed in the language of the developers (Husen
2007). If conflicts between the requirements arise, they have to be identified and resolved. After the concretization, the requirements are presented to the stakeholders in order to explore whether or not they meet their wishes.
Customization and integration of goods and/or services: According to Tuli et al. (
2007), this phase comprises the coordinated and integrated development of the different components by the respective domains, and they are combined in an overall solution.
The requirements can change during the implementation. Therefore, the RE has to gather all changes in the specification, identify their effects on other requirements and components of the PSS, and provide measures for handling the changes. In this context, it is important to trace the life cycle of each requirement through every phase of the development in order to identify the interdependences between all requirements and components of the PSS and to keep them updated.
Deployment & postdeployment customer support: In the phase of deployment, the PSS is integrated into the value chain process of the customer. The postdeployment phase focuses on supporting, maintaining, and disposing of the PSS after the end of the product life cycle (Tuli et al.
2007). For a successful implementation of both phases, the provider of the solution must know the prerequisites given by the customer. Due to these facts, an integrated development of all PSS components is essential (Spath and Demuß
2003). If subsequent changes in the requirements occur, the task of RE in that case is to update the current specifications and to keep them up-to-date.
The following paragraph shows an example for a PSS in the medical sector that illustrates the complexity of its development and the role of RE.
A former pure production enterprise that focuses on medical systems has recently provided an integrated solution for the sterilization of surgical instruments for hospitals, whereby the customer pays depending on the product usage. The main advantage of the integrated solution for the consumer is the decrease in fixed costs. The customer receives clean instruments for each operation coordinated with the schedule, which can be transmitted to the provider’s system through an interface. Consequently, the PSS should include an adequate software program integrated into the hospital information system, a service organization targeted towards the on-demand-needs of the customer needs, as well as sterilizing plants offered by the supplier and applicable for each customer solution. All these components describe an integrated bundle and can hardly be used separately.
A major challenge for RE during the development of this PSS was the concretization of, and coordination between, the requirements on goods and services. Based on the prerequisites given by the hospitals, the requirements concerning the center for sterilization of surgical instruments were derived, and used for, the definition of the service requirements (e.g., transport of the surgical instruments or consideration of all operating schedules in the planning of the provider). During requirements elicitation, different aspects comprising the size and sterilizing conditions of the transport boxes for the surgical instruments, as well the calculation of routes, cars, and drivers were taken into consideration. These temporal and localized requirements on the transport had to be adjusted with respect to the requirements on the integration of the provider’s software into the hospital information systems. As the numerous stakeholders had heterogeneous expectations, the resolution of conflicts in the specification was complicated, too. Particularly, the cross-domain links between the requirements represented a difficult task that could not be handled by applying traditional RE methods.
8 Summary and Conclusion
PSS represent a new trend on the market for hardware, software, or service providers. As they consist of various components that are produced by different domains, their development constitutes a major challenge. For successful development, RE becomes a key factor, and its role for PSS is thus investigated in this paper. Based on the characteristics and the different life cycle stages of PSS, the criteria for an effective RE are derived. Within the literature review, 15 leading RE process models and approaches of product, software, and service engineering, as well as five integrated approaches of PSS development, are analyzed for their compliance with the predetermined criteria. Thus, deficits in the existing approaches can be evaluated and additional research needs can be identified.
In this paper, the criteria for a successful RE are derived from the analysis of the characteristics and life cycle of PSS. In this context, a key feature of PSS constitutes the orientation towards the customer/individualization of solutions. Therefore, the requirements arising from the customer’s value creation process must be analyzed. Importantly, the stakeholders of the various domains have to be considered. Thus, the communication between the domains, as well as the consideration of service engineering, are essential parts of the entire RE process.
The analysis of the existing RE approaches for PSS shows that the necessity of a systematical RE is realized in all domains. However, the maturity level of the RE approaches varies widely in the single domains. In service engineering and in the integrated approaches, approaches for requirements management are hardly suggested or not tested. The concept of RE is developed furthest in product and software engineering, but only focuses on single domains. Approaches of cross-domain cooperation and communication are not mentioned explicitly in the analyzed approaches that imply approaches tailored to the respective fields. This impedes the cooperation between the domains, i.e., the use of the results of one domain in another. The different terminologies even obscure the view on possible commonalities. A further deficit constitutes the cross-linking of the RE approaches of the different domains. Despite conceptual and methodical analogies, the various terminologies complicate the cooperation.
In order to meet these challenges, sophisticated development techniques in the single domains can be adapted to PSS. This imposes a first step to cross-domain integration. Future research could target a comprehensive approach of RE that incorporates different perspectives on, and characteristics of, the domains as well as the attributes of the PSS. Similarities of the existing approaches have to be identified and summarized. The core concepts of such an approach could include a cross-domain cooperation, the integration of RE in the development process, and the handling of the different life cycles of the components. Consequently, further scientific research should focus on the creation of an artifact model and defining a structure for the documented requirements. On the basis of a common artifact model for all domains, the coordination of single approaches is possible.