Integrated PSS Roadmapping Using Customer Needs
and Technology Change Likelihood
Marcus Vinicius Pereira Pessôa
and Akshath Gowda
Abstract—A product roadmap depicts the vision and direction of a product offering over time. It is a guiding strategic document as well as a plan for executing the strategy, which communicates the why and what behind the product’s development. Fulfilling the market demand for solutions composed of products and services requires new approaches for roadmapping. This article presents a method for the definition and managing of a product-service system (PSS) roadmap based on both the market needs and the technology change likelihood. In this way, an integrated management of the PSS’s product and service shares is performed, which also supports the shift from different PSS types (product-, use- or performance-oriented). The proposed approach is based on the acceptance, ephemerality, importance, operationalize, and urgency variables: importance and urgency relate to market requirements, accep-tance, and operational relate to technology choices, and ephemer-ality relates to how both the requirements and/or technologies are likely to change in a given time horizon. To illustrate and evaluate the approach, a roadmap is developed for a home appliance. The results show the proposed method’s efficiency for both setting the product architecture and defining and managing the roadmap.
Index Terms—Engineering management, program
management, requirements management, research and
development management.
I. INTRODUCTION
T
HE FOURTH industrial revolution is triggering changes beyond the shop floor. One of these changes is the shift from pushed products to pulled and personalised solutions, which might be composed of a mix of products and services [1]. Product-service systems (PSS) are one way to approach the combination of products and services. Although personalization is not a requirement for PSS, it can support the setting of a long-term relationship between the PSS user and provider [2]. In business-to-business applications, it is called an indus-trial product-service system (IPS2), whereas in business-to-consumer applications, it is called a PSS. In this article, these applications are referred to universally as PSS.PSS variety and changes motivated by evolving customer needs and evolving solution-supporting technologies call for
Manuscript received July 23, 2019; revised March 10, 2020 and July 31, 2020; accepted September 7, 2020. Review of this manuscript was arranged by Department Editor R. Phaal. (Corresponding author: Marcus Vinicius Pereira
Pessôa.)
Marcus Vinicius Pereira Pessôa is with the University of Twente, 7522 NB Enschede, The Netherlands (e-mail: m.v.pereirapessoa@utwente.nl).
Akshath Gowda is with the Brahm Works Pvt. Ltd., Bengaluru 560022, India (e-mail: akshathrg@gmail.com).
Color versions of one or more of the figures in this article are available online at https://ieeexplore.ieee.org.
Digital Object Identifier 10.1109/TEM.2020.3024581
a roadmap that both incorporates foreseen changes and is a managerial tool to proactively and effectively support responses to these changes. Current PSS roadmapping approaches, though, consider the evolution of products and services separately [3], [4], lack a practical description [5], or are limited to technology changes and does not cover market changes [6]. This limits the resulting roadmap and does not consider the evolution from products to services and vice versa.
This article’s objective is to present a new method for defining and managing a PSS roadmap, where the main contribution is to support integrated evolution among products and services, while also supporting managing the shift from different PSS types (product-, use- or performance-oriented).
The proposed method considers the change likelihood of market needs and technologies and is based on the acceptance, ephemerality, importance, operationalize, and urgency (AEIOU) variables: importance and urgency relate to market require-ments, acceptance, and operational relate to technology choices, and ephemerality relates to how both the requirements and/or technologies are likely to change in a given timeframe [7]. The PSS modular structure should facilitate these changes, whereas the product roadmap includes indicators to trigger the changes. To illustrate and evaluate the approach, a roadmap is developed for a smart home appliance.
To achieve the proposed objective, the design research methodology [8] is adapted. Section II clarifies the challenges for uncertainty-related PSS roadmapping. A literature review on tackling these PSS roadmapping challenges forms part of the descriptive study, which is conducted in Section III. Once a clearer picture of the state of the art is taken, a prescriptive study is executed in Section IV, proposing the change likelihood-based roadmap method. After applying and verifying practicability through an example, a second descriptive study is conducted in Section V. Section VI reflects on the method’s capacity to solve the initially identified challenges, and Finally, Section VII concludes this article.
II. FROMPRODUCTS TOSOLUTIONS
By shifting from products toward solutions, value can be delivered through any combination of products and services offered according to diverse business models, which is the case of the PSS. In PSS manufacturing firms, revenue shifts from only selling physical products to that obtained from also selling services, where the value delivered ranges from more products to more service shares [2], [9], [10]. PSS benefits are not limited to PSS providers and customers, and the whole society can take
advantage of its sustainability impact due to reducing resources consumption and pollution [11]. In PSS, the interrelations be-tween the physical products and nonphysical services need to be considered proactively during the development process [12]. PSS business models’ spectrums range from product-oriented and use-oriented to performance-oriented. In the product-oriented model, the product’s ownership is kept by the customer, and complimentary services are offered [13]. In use-oriented and performance-oriented models, product ownership stays with the manufacturer, which profits by guaranteeing product availabil-ity and agreed performance levels, respectively. Adopting PSS business models, particularly use- and performance-oriented models, is a challenge to traditional firms; it involves adapting products and services while keeping the business profitable [14]. Successful PSS relies on a life-cycle-long relationship be-tween its provider and the customer [2]. This relationship acts like a fulcrum and guarantees both revenue and information that enable and sustain the PSS. Changeable PSS support long-term relationships by reducing the likelihood of obsolescence and the impact of cascade changes [7]. Changeability means the system’s modules have built-in robustness against small use variations, adaptability to different user experiences and new technologies, and flexibility for updates and upgrades [15], [16]. Sometimes, systems are designed for adaptability by including design-in architecture options [17]. Designing changeable PSS requires roadmapping because the designers need to consider actual and future use and possible technology scenarios.
One good example of solution-creating that fits the PSS spectrum is the Apple business model, which is capable of “owning the consumer” [18]. Apple drives consumers to and holds them in its ecosystem by integrating content (software, media, and apps) and hardware (laptops, phones, and tablets) into a business strategy of bringing the best user experience to its customers through its innovative products and services. The continuous updating, upgrading, and releasing of new versions guarantee an enduring relationship with customers.
III. LITERATUREREVIEW
Although this article is focused on product (more specifi-cally PSS) roadmapping, it cannot be detached from technol-ogy roadmapping once both are interlaced. Additionally, by coordinating and aligning product and technology roadmaps, companies can invest in new products that are expected to have greater sustainability and can focus more directly on enhanc-ing the company’s core competencies. [19] As a consequence, roadmapping aligns short-term product development decisions to long-term strategy by deciding in which technologies to invest and in which order to follow market-expected evolution. Companies such as Motorola [20] and Phillips [21] use it to gather information from a wide variety of sources and develop dynamic short-, mid-, and long-term plans for R&D investments as well as new product and process developments.
A literature review was conducted to understand how PSS roadmapping is being performed and to obtain insights from other roadmapping approaches (not specific to PSS). Roadmap-ping that deals with PSS, modularity, variants, and customization
TABLE I
SEARCHQUERY(KEYWORDGROUPING)
was investigated. The list of search query keywords is given in Table I.
In the context of roadmapping related research, Alcantara and Martens [22] highlight the relevance of the topics of cus-tomization and product-service roadmaps, which clearly points to the business interest in dealing with personalized and smarter solutions that integrate products and services.
Although changeability is an important challenge to PSS, dealing with changes is also an important challenge in the context of product families and products with several variants [23]. Therefore, investigating how roadmapping deals with these aspects is important. High product variety is driven by the dif-ferences among new technologies and the pressure on costs and sustainability [24], [25]. Companies often use variants within their product portfolio to support personalization, new legisla-tion, error correclegisla-tion, proactive adaptation to improve design quality, and unforeseen changes required to remove undesirable characteristics [26].
Although a high product variety is preferred, the additional complexity (different strategies, processes, production steps or/and production lines, and the challenge of managing change) and related costs are unwanted [27]. The variants’ related com-plexity might lead to uncontrolled change propagation (a change avalanche) on a scale that cannot be brought to a satisfactory conclusion [28], [29]. A way to deal with changes is through modularization to segregate the effects of some foreseen change drivers into specific parts/modules of the product [7]. This can be done by defining a product family based on a platform with common and more stable modules and thus having most of the changes in the modules that do not compose the platform [30]. In this study’s case, a product planning roadmap was set to manage the evolution of product variants [31]. Consequently, the roadmapping of modular products was also investigated.
A search in the Scopus database was performed on April 10, 2019, using the search query presented in Table I. The search was limited to peer-reviewed articles written in English and published in journals or conference proceedings, and with no date limit set. The search resulted in 67 articles. After an individual assessment conducted by reading for alignment to the topic relevance in the titles and abstracts, 35 articles were selected. From these, the authors had access to 28, which were analyzed in full. Four papers were included after the snowball process applied to the reading of the original 28 articles, totaling 32 articles in the final sample.
Fig. 1 gives an overview of how the 32 analyzed articles related to the terms in the query (note that some articles included more than one term). One aspect that stood out was the small
Fig. 1. Articles analyzed by year and by related search terms.
number of PSS-related works and the reduced discussion about variants.
The analysis aimed to identify roadmapping meth-ods/approaches in the literature that dealt with products and services, handled customization and variants, suggested how to define a solution’s modular structure, and/or tackled the issue of changes. The following questions guided the analysis.
1) How is roadmapping of PSS being performed? 2) How are change triggers being defined?
3) How does roadmapping deal with change propagation, particularly in the case of products with several variants? A. Roadmapping and PSS
Although they do not consider PSS but instead specifically deal with service roadmaps, Nakamura et al. [3] proposed a service offering evolution in terms of customer needs’ levels the offering fulfils (material, information, cognitive, knowledge, and mind levels) and the expansion of user segments (indi-viduals, organizations, or the society), and in terms of which customer value phase the offering covers (delivery, adaptation, or cocreation). The resulting roadmap would be created by considering evolution through these dimensions and according to the dynamic shift of user needs and service user segments driven by customer value generation.
An et al. [4] show how to use quality function deployment (QFD) for developing an integrated product-service roadmap. They deploy user needs to product and service “modules.” At the top of the QFD, they also show how product and service modules relate. They deal with the parallel evolution of product and services but do not explicitly consider the evolution from products to services.
Geum and Park [5] work with technology roadmaps for PSSs. They consider three levels (technology, product, and service) and the different PSS business models where the technologies are first deployed at the product level and reach the services through the product. As the PSS shifts from being product-oriented to use- and performance-oriented, the authors also consider the value delivered through the product to be later delivered by the service, but not the way around. Unfortunately, their study lacks a practical description of how to use the proposed framework.
Geum et al. [6] studied the strategic development and planning of product-service integration. This article suggests a customiza-tion framework for product-service roadmapping according to the technological interface involved and provides practical guid-ance for its implementation based on the technology role and the roadmapping format. The proposed approach focuses on how a firm can customize or tailor the generalized structure of the product-service integrated roadmap for firm-specific practical situations. The authors consider six different scenarios for how technology can enable/facilitate product-service integration and suggest six types of roadmaps, which include evolution from product toward services and vice versa. Although it is very comprehensive, the article does not tackle changes in the market with the same depth as it does changes in technology.
Scalice et al. [32] presented a method for transforming tech-nology roadmap outputs into a module-based plan. The proposed method combines two methods of modular design to transform the products listed on the roadmap into a list of modules, providing a new roadmap based on module releases. A new set of module drivers is provided to deal with the market side of technology roadmapping. Although they are not the article’s focus, PSS product and service shares can be represented as different modules and can benefit from their approach.
Sauer et al. [33] described how modularity is implemented in a roadmapping framework so that, from a set of standalone roadmaps, each can be used as an interconnected module. The resulting roadmap shows a broad landscape of corresponding developments in technologies, products, applications, markets, and societies.
B. Change Triggering
Hussain et al. [34] proposed “scenario-driven roadmapping,” where they use scenario planning for first identifying plausible images of the general environment and then use the scenarios for technology roadmapping. In this process, they consider “flex points,” which are critical developments that would signal transi-tions along particular pathways and support effective monitoring of the environment over time. By developing scenarios as a distinct initial step, cognitive bias in the identification of the “flex points” can be minimized, improving the overall decision-making.
Although not directly related to PSS, Lee and Park [31] proposed approaching product and technology roadmapping based on eight standardized roadmaps (four for product and four for technology). To plan the evolution based on market and technology change likelihood (external drivers), it is nec-essary to combine a product driver roadmap and technology trend roadmap to a product family roadmap (internal strategy) and product evolution roadmap. Variations are represented in a similar way to how product families are handled, where different products can be part of a family.
Phaal et al. [35] proposed a roadmap architecture according to the perspectives of markets, products, and technologies, and which helps defining the evolution against time (“know-when”) from “the why” (purpose), “the what” (delivery), “the how” (resources) related to these perspectives. One weakness of this
TABLE II
ANALYSISFROM THELITERATUREREVIEW
1Do not explicitly consider the evolution from products to services and vice versa. 2Only during the roadmap monitoring.
is not accommodating future options/changeability, but making tradeoffs and taking decisions based on the scenarios’ uncer-tainty and the company’s risk appetite [36]. It is also important to remember that this architecture mentions products and services and shows how their delivery could be synchronized, but it does not discuss how to deal with products and services combined.
This architecture is further discussed in Phaal and Muller [37], who emphasize the relation among the roadmap time horizon and the expected change rate, where higher change rates must relate to shorter term roadmaps (so that risk and uncertainty are kept at a certain level).
Gerdsri et al. [38] presented a framework for assessing the impact of changes in relevant internal and external factors and determining the need for revising the roadmap. Although they propose encompassing the use of market/business-related and technology-related factors, their method is not used during roadmap creation but only for monitoring.
C. Change Propagation
Savolainen and Kuusela [39] discussed the issue of roadmap-ping products with several possible variants, where the product modular architecture and the possible module/parts variants present the challenge of roadmapping both in terms of time and place. Their approach aims at solving the challenges of schedul-ing and synchronizschedul-ing the diverse roadmaps for modules/parts and guaranteeing a smother product development and launch. They do not deal with issues related to the module/parts version’s features’ scope setting through the roadmap.
Hamraz et al. [40] used function behavior structure (FBS) [41] to model change propagation and support uncertainty reduction together with risk management in design. It is interesting that they observe that a PSS roadmap should deal with change prop-agation, particularly in the case of PSS, where interfaces among parts of products might become interfaces among products and services.
D. Conclusion From the Literature Review
The shift from more standardized products to personalized solutions has two implications. First, value delivery through a solution is an emergent property from the product and service shares that compose it. Second, the personalization requires offering solution variants that result from combining the product and service shares. This satisfies the individual needs of different customers.
In the literature review, none of the methods found were able to comprehensively combine the market and the technology change likelihood into PSS roadmapping. Table II relates the literature to the relevant aspects of this research. The objective is not only to cover products and services but consider them as modules from an integrated PSS. In this way, the roadmap planning can include uncertainty in the market and technology scenarios, and both to determine the appropriate PSS changeability features and support the function implementation evolving from product to service and vice versa.
IV. CHANGE-LIKELIHOOD-BASEDPSS ROADMAP
The proposed change-likelihood-based roadmapping method aims to support PSS roadmapping by setting a strategy for accommodating changes, reducing the change cascading effect, and explicitly including the possibility of PSS product shares evolving to service shares and vice versa. In this way, the resulting roadmap can support the long-term relationship among PSS providers and users.
Roadmapping must offer a framework to visually integrate market, product, and technology evolution. The proposed ap-proach considers market and technology evolution uncertainties when they will pull or push the PSS’s function evolution. The PSS performs a set of functions that are implemented as either products or services and that can be directly perceived by the cus-tomer or can be a part of the backstage infrastructure/supporting
Fig. 2. Market evolution and technology and product roadmaps (adapted from [32], [35], [36]).
processes (see Fig. 2). The PSS roadmap here proposed repre-sents the planned evolution of the whole PSS functional structure in a given timeframe. The main difference from the traditional product roadmapping approach is that the approach in the current study considers products and services in an integrated fashion in the sense that value delivery can be interchanged from product to service shares through the PSS roadmap.
In the proposed method, similar to Hamraz et al. [40], the change driver’s impact is analyzed in terms of their impact on functional, behavioral, or structural levels. According to the FBS framework [41], a system or product performs functions according to a certain behavior, which is implemented by a structure. The PSS’s product and service shares will be treated as different types of modules as in [32] and [33].
Relevant PSS perspectives are considered in a similar fash-ion as Nakamura et al. [3], where the change drivers’ impact estimation is performed using the appropriate AEIOU variables [7]. These variables support 1) the initial prioritization of the requirements and the setting of a strategy for fulfilling them and 2) the setting of a modularization strategy to define a flexible and changeable solution. In the former case, the variables EIU are used, whereas in the latter case, the variables AEO are applied, where (A) acceptance: favorable reception or approval by the customers of an alternative for providing a particular function; (E) ephemerality: the likelihood of change due to changes in the customer/market expectations (E-mkt) and/or technology (E-tec); (I) importance: the importance given to each value item by each stakeholder; (O) operationalize: how easy it is for the company to produce, in the case of a product, or perform, in the case of a service, a particular alternative (i.e., the related technology might not be dominated by the company, thus imposing additional risks); and (U) urgency: how soon the customer expects a certain value item to be delivered.
Requirement prioritization is similar to the Wiegers’ method [42], which evaluates each requirement according to its value to the customer. The prioritization uses a four-level scale (not applicable, low, medium, and high), thus maintaining compat-ibility with the Kano model by using a value-oriented prioriti-zation [43]. The variables’ values definition, however, is empir-ical and dependent on the evaluators’ experience and available knowledge (market research, customer surveys, technological forecast, etc.), and it is not possible to guarantee that the two people/groups or the same person/group in different moments
will come to the same conclusions. These are common issues with requirement prioritization [44].
The AEIOU variables provide a richer way to manage un-certainty and risk. Whereas traditional methods rely only on probability and impact [45], which are considered in variables E and I, respectively, the AEIOU are capable of discerning some specific and roadmapping-relevant information, which are the risk sources related to AOU and the E separation into E-mkt and E-tec. By monitoring these variables, it is possible to identify triggers for evolving PSS functions, similar to the “flex-points” that Hussain et al. [34] proposed.
The final roadmap setting determines the coordinated evolu-tion of several PSS’s subsystems (in terms of both product shares and service shares) in a way that is triggered by the changes in market and or technologies, and in a similar fashion as the “flex points” from [34]. The structuring of these dimensions through correlation matrices (similar to [4]) also has the potential to make the roadmapping process more practical.
The proposed roadmapping method consists of seven steps (see Fig. 3). Steps 1 to 6 are executed after starting each devel-opment cycle, and Step 7 is performed during the develdevel-opment cycle. Step 7 also gives input to Step 1 from the next iteration (see Fig. 4).
A. Identify the Change Drivers
The first step is identifying which change drivers come into effect during the planned roadmap horizon. This step is closely integrated into the company’s strategic management process once the strategy defines how the company plans to face the foreseen changes in the market and technologies. While defining the company’s strategy for the market and product, strategic planning includes performing market surveys, doing technology forecasts, and analyzing the products’/competitors’ history in the market. These are some good sources for identifying relevant change drivers and for later determining the AEIOU variables’ values and monitoring.
The change drivers can be categorized as [46] follows: 1) Dynamic marketplace: Indicated by number of
competi-tors, strength of competition, degree of uncertainty of cus-tomer needs, duration of product life cycles, use scenarios, or similar factors [16].
2) Technological evolution: Indicated by, for example, tech-nology half-life, new technologies, or similar factors. Changes can be caused internally, for example, due to errors in the technical functions of a product [47]. 3) Variety of environments: Changes made in laws,
stan-dards, and regulations as well as society after products are launched, weather, new company strategy, social/political factors, diversification, etc., [48], [49]
B. Estimate the Change Drivers’ Impact on Requirements The requirements are the base elements in the roadmapping method because they bind the PSS functions’ definition, and the requirements’ change evolution determines how the function implementation will evolve over time. Because requirements can be defined at different levels, from business requirements
Fig. 3. Proposed roadmapping method’s steps.
Fig. 4. Iterative use of the method.
to detail requirements, the level considered here is stakeholder requirements, which are requirements for a system that can provide the functions users and other stakeholders need in a defined environment [50]. It is important to highlight that at this level, the requirements relate to PSS functions; nevertheless, they will be further implemented as a product or service.
This step is related to the company’s marketing and marketing intelligence processes and is integrated into the product manage-ment process. The requiremanage-ments, as stated by the stakeholders, are the basis for defining, designing, and developing the PSS so-lution roadmap. Changes at the functional level mean the stake-holders that deal with the system except different interactions. These changes are main drivers for evolving the solution through time, and these drivers’ forecast is necessary for performing the roadmapping.
The value of E-mkt for each requirement is estimated in terms of the change time horizon and impact. Fig. 5 shows an example of these two aspects combined rating, where
1) The time horizon is considered as short term (the change horizon is smaller than one development cycle), medium
Fig. 5. Time horizon× impact matrix.
term (the change horizon is bigger than one and smaller than two development cycles), or long term (the change horizon is bigger than two development cycles). Require-ments that are expected to change in the short term should be ideally postponed to future product versions.
2) The impact is considered as high (a new function that might require new interfaces with the other functions’ implementation), medium (a new function that maintains the other functions’ implementation), or low (a similar interaction to be executed in a changed scenario). The impact also gives some direction to the PSS implemen-tation, in the sense that lower impact might be absorbed by embedding robustness to the changes, while modular strategies (i.e., product platforms and families) are coupled to higher impact changes.
3) A requirement that is estimated to have changes in the short term and has high impact receives a higher E-mkt value, in this case “9.”
C. Apply Requirement Guidelines
Considering all the stakeholders interested in the solution, the importance and urgency they assign to having each requirement delivered is estimated (high, medium, low, or no). As a result, the following guidelines are proposed with the objective of
Fig. 6. Possible strategy development based on E-mkt, I, and U.
Fig. 7. Preliminary roadmap based on E-mkt, I, and U.
determining which requirements will be implemented in each version of the solution:
G1) Requirements with short-term E-mkt and lower I and U should be postponed for later versions of the solution. G2) Requirements with higher U must be implemented
re-gardless of the other variables.
G3) Requirements with higher I must be implemented in the first/next version of the solution, and requirements with lower U might have their delivery postponed to further PSS upgrades/updates.
G4) In case of low U and short-/medium-term E-mkt, besides postponing, careful requirement monitoring is required in case it quickly becomes obsolete.
G5) In case of delivering likely-to-change requirements, it is preferable to implement them through services or software rather than through hardware.
Fig. 6 summarizes the strategy for the development by con-sidering variables E-mkt, I, and U combined. It offers some guidance for determining when to postpone the delivery of a requirement, when a modular architecture helps in coping with expected changes, and when a robust design might be capable of absorbing the changes. These are important results that inform the company’s design and development process and help shape the PSS architecture.
A preliminary roadmap that only considers requirement de-velopment can be set by applying the guidelines in Fig. 7. In this way, it is possible to plan which features will be offered by different product versions through time (see Fig. 6).
Once E-mkt, I, and U are estimated, the circumstances that led to them must be monitored to ensure roadmap adjustment
to the new scenario. The roadmapping management is further described in Section IV-G.
D. Estimate the Impact on the Functions’ Embodiment Once the sequence for requirements delivery through the product versions is set (what), it is now necessary to determine how this delivery will happen through time. This step includes conducting functional analysis to determine the PSS’s essential functions, which are those that the product, system, or service to be designed must satisfy, no matter what physical components, service processes, or business model might be used. When defining the functions, an important aspect is guaranteeing inde-pendent functions and clear interfaces to determine an adaptable, functional architecture [51], [52], which will make the evolution from products to services and vice versa in the roadmap easier. In sequence, the solution space is explored for alternative behaviors and related structures for functions’ embodiment. Changes in the behavior and or structure mean implementation of new technology is needed. Good alternatives are those that better deal with changes, thus making it easier for PSS to evolve. The alternatives are then graded according to different risk dimensions represented by the variables A, E (E-tec), and O. For example, an alternative might present the best value deliv-ery capacity but might be riskier to develop or might require educating the customer (the customer might not be ready to accept it). As a consequence, the development team will need to balance the expected change before obsolescence (related to E-tec) and expected revenue, the time needed to educate the customer (related to A), and expected costs, and the time needed to master a technology or process (related to O) and expected revenue.
The value of A for each considered alternative relate to the stakeholders’ acceptance level. For each stakeholder, the alter-native needs to be rated as acceptable (there are no restrictions), requiring maturation (some education and/or time is needed for the stakeholders to become completely at ease with it), or unacceptable (the alternative must be discarded).
The value of E-tec for each requirement is estimated in terms of change time horizon and impact (Fig. 4):
1) The time horizon is considered as short term (the change horizon is smaller than one development cycle), medium term (the change horizon is bigger than one and smaller than two development cycles), or long term (the change horizon is bigger than two development cycles). Nonma-ture technologies, which are expected to change in the short term, should be ideally postponed to future product versions.
2) The impact is considered as high (changes that cascade to other modules), medium (behavior changes within the module), or low (structure changes within the module). In case of higher impact, alternatives based on service or software are preferred to those based on hardware. The value of O for each alternative relates to the company’s capacity to use/produce it. Each alternative should be rated as ready (there are no restrictions), requiring adaptation (some education and/or time is needed for the stakeholders to become
completely at ease with it), or unacceptable (the alternative must be disregarded).
This step’s execution is closely integrated into the marketing process, the product design, and development process, and the research and development process (in case the company has it). At the same time, the former has a key role in helping to determine the A-value, the other two support defining O and E-tec values.
E. Apply Guidelines for the PSS Architecture
The solution/PSS architecture guidelines support the deci-sions of 1) which functions should be implemented through the PSS product or service shares; 2) which functions should evolve from being implemented by product to being implemented by service shares; and 3) deciding the architecture flexibility, robustness, and modularity, to provide the necessary change-ability to the solution. As a result, the following guidelines are proposed:
G6) Alternatives (either product or service) with higher acceptance by customers are preferred.
G7) Functions that embed higher likelihood of change (E-tec) should be implemented in less coupled modules, which are easier to remove or change in the future. In this case, services or software are preferred.
G8) If the best choice (capable of delivering more value) for implementing a function is a service, but the interested stakeholders are not yet ready to accept it (low A), the implementation of this function should be segregated in a product module, which is easier to swap to a service when the stakeholders become ready.
G9) If the best choice (capable of delivering more value) for implementing a function is a product, but the likelihood of change (E-tec) is still high, the implementation of this function should be segregated to a module easier to change (such as service or software) when the tech-nology becomes more stable.
G10) The easier to become operational, the less risky the alternative is. An alternative with higher O might be preferable for guaranteeing the timely release of the first PSS version; lower O but better alternatives can be pursued for later PSS upgrades.
F. Set the Roadmap
The setting of the roadmap results from applying the guide-lines. It includes how the function implementation evolves through the product/PSS versions according to the market (I, E-mkt, and U), the technology evolution, and environment trig-gers (A, E-tec, and O). The roadmap should also explicitly show how products can evolve to services and vice versa.
The change-likelihood-based roadmap first defines the re-quirements that are going to be a part of each product ver-sion’s development scope (applying guidelines from step 4). The change drivers that determine the changes should be monitored to confirm the change needs in future versions. In sequence, the technology-related expected changes determine challenges and
Fig. 8. Resulting roadmap.
opportunities for the possible functions’ embodiment alterna-tives in each of the product’s versions. Embodiment alternaalterna-tives delivering more value to customers or reducing the product cost might trigger the release of new PSS versions regardless of whether any requirement is added.
Fig. 8 illustrates the roadmap where major versions are defined by different functionalities, and intermediate versions result from new implementations that deliver the same func-tionality.
G. Manage the Roadmap
One major challenge for most organizations is keeping a roadmap alive and up to date [38]. Roadmap management aims to guarantee that will reflect actual marketing and technol-ogy scenarios. This step requires monitoring change drivers and revising assumptions that determined the AEIOU values. Opportunities are then identified that trigger the evolution of the PSS functions’ implementation. It is particularly important for checking whether some long- and medium-term expected changes have shifted to a different timeframe.
The management also includes roadmap accuracy monitoring (time and alignment to market). It is also important to keep track of AEIOU values accuracy whenever a product version hits the market. Deviations on these values and related deviation trends might require revising the rationale behind the developed roadmap.
This step also requires other areas/processes in the company. Inputs from strategic planning and particularly from marketing intelligence, research, and development, and customer relation-ship management are crucial for understanding how the cus-tomer needs and technological landscape are changing.
V. SMART COFFEEMAKEREXAMPLE
The example’s objective is to apply the proposed change-likelihood-based roadmapping method and show its practica-bility. This example is based on three Siemens coffee maker
Fig. 9. Analyzed coffee makers.1
models. This scenario was chosen because 1) Siemens is a well-known manufacturer of a household coffee machine, offering simple manual coffee machines to fully automated and smart models, and 2) commercial and technical documentation was available for analysis on Siemens’ website.1
A smart coffee maker is a type of smart appliance, which means it includes modern computer and communications tech-nology that enable automatic or remote control operations based on user preferences or external signals and that allow it to function in a better, faster, cheaper, and more energy-efficient way. On successfully providing smart appliances, companies face the challenge not only of investment costs but also of resisting the temptation to push technology to customers and clearly understand why and when the technology is opportune. Companies also need to provide services to support the use of new products and systems and establish consumer trust and develop the market [53].
The chosen models were the TC60101GB manual coffee maker, the EQ.3 s100 automatic coffee maker, and the EQ.9 plus connect s700 SMART coffee maker (see Fig. 9). In the example’s fictitious scenario, the company is planning to evolve its product base from manual to automated coffee makers. In this scenario, the technologies available are already mature enough (although still expensive) to support the development of smart appliances, but the market is not yet fully prepared to consume these products. Therefore, the roadmap will start from the automated model as an intermediate version and end at the smart appliance. Consequently, a roadmap sequencing the versions from the manual to the smart coffeemaker will be defined according to the expected evolutions of the market (customer needs and technology acceptance) and technological (availability and affordability) scenarios.
A. Identify the Change Drivers
A comparison was made of the features of the three different Siemens coffee makers: TC60101GB, EQ.3 s100, and EQ.9 plus connect s700. Table III shows how these features compare and the possible change drivers. The features were listed on Siemens official website.
1[Online]. Available: https://www.siemens-home.bshgroup.com
Fig. 10. Analyzing the requirements.
B. Estimate the Change Drivers’ Impact on Requirements In this example, the stakeholder requirements (see Table IV) were derived from the features listed in Table II. In this way, the requirements were those that were necessary to evolve from a manual coffee model to a smart model. This strategy for deriving the requirements led to a requirement set that included functional rather than nonfunctional requirements. This limitation did not affect the example’s objective.
The requirements’ E-mkt was estimated by considering the change drivers’ time horizon and the possible impact of each of them [see Fig. 10(a)]. This estimation used the values from the change time horizon× impact in Fig. 5. The choice of these values was arbitrary and aimed at allowing for a good differen-tiation among the values calculated for each requirement. The E-mkt was calculated as the sum of change drivers’ time horizon versus impact values. By analyzing the related change drivers, the requirements more likely to change were found to be RQ 1, 2, 4, and 8.
C. Apply Guidelines for the Requirements
In the example, the only stakeholder considered for defining the requirements’ importance and urgency was the customer, and the ratings of high, medium, low, and not interested were used. Fig. 10(b) shows 1) the ordered results, where priority was given to I, then U, and finally E-mkt; and 2) the decision about which requirements will be considered in each of the following product’s versions according to the application of the guidelines.
1) From G1, RQ 1, 11, and 12 should be considered for future versions of the product: The results show that they are very likely to change, possibly because customers do not have a clear need for them.
2) From G2, RQ 8 must be offered in the first version of the product, but the number of coffee varieties could be more limited and could be expanded in the next versions. 3) From G3, RQ 2 must be offered in the first version of the
product, but further understanding of the change drivers is needed in order to prioritize which configuration alter-natives will be offered first and how.
TABLE III
FEATURESFROM THEEXAMPLE’SCOFFEEMAKERS2,3,4
4) RQ 4 can be postponed for the next version of the product, but further understanding is needed of the change drivers to prioritize which parameters’ adjustment should be offered
2[Online]. Available: https://www.siemens-home.bsh-group.com/ae/ products-list/coffee-machines/filter-coffee-machines/TC60101GB#!
3[Online]. Available: https://www.siemens-home.bsh-group.com/uk/ productlist/coffee-machine/automated-freestanding/eq3-fully-automatic-bean-to-cup-coffee-machine/TI301209RW
4[Online]. Available: https://www.siemens-home.bsh-group.com/uk/ productlist/coffee-machine/automated-freestanding/eq9-fully-automatic-bean-to-cup-coffee-machine/TI9573X9RW
first. This is necessary to solve the conflict between the three guidelines.
5) From G4 RQ 1, 11, and 12 must have their evolution monitored to avoid keeping obsolete requirements in the set.
Consequently (see Fig. 11), the coffee maker V1 will include most of the features directly valued by the customer, although it will have no customization capabilities and fewer coffee choices. V2 includes more coffee choices and customizations and delivers better coffee by guaranteeing the water quality. Finally, V3 includes smart features.
TABLE IV
FEATURES ANDREQUIREMENTS FOREVOLVINGFROM THEMANUALCOFFEEMAKER
Fig. 11. Preliminary roadmap.
D. Estimate the Impact on the Functions’ Embodiment A general functional structure for a coffee machine is shown
Fig. 13. Impact on the functions’ embodiment alternatives.
automated, and smart coffee machines. In this step, only the “select/customize coffee variety” function’s alternatives for im-plementation were analyzed.
A1) Analog selection: Use of physical buttons or knobs for selecting the coffee variety.
A2) Digital selection: Use of a touchscreen for selecting the coffee variety.
A3) Remote selection: Use of a remote interface or app for selecting the coffee variety.
A4) Digital customization: Use of a touchscreen for cus-tomising the desired coffee recipe.
A5) Remote customization: Use of a remote interface or app for customising the desired coffee recipe.
A6) Coffee customization community: A coffee customiza-tion community service for exchanging, experimenting, and rating coffee recipes.
Fig. 13 shows the requirements relating to the function “se-lect/customize coffee variety.” Once the function aims at deliver-ing these requirements, the E-mkt also indicates the function’s change likelihood. It also shows to which extent each of the alternatives support delivering the complete requirement set (total) and the requirements prioritized for the version 1 (V1) of the PSS. Finally, it presents each alternative’s qualitative values for A, E-tec, and O.
E. Apply Guidelines for the PSS Architecture
These guidelines led to the following conclusions related to the function “select/customize coffee variety” (Fig. 7 illustrates conclusions 1 to 3):
1) According to G5, A2 is preferred, whereas A1 is discarded because of low acceptance.
2) According to G6, the function should be implemented through service or software, which confirms the dropping of A1.
3) Although, according to G6 and G7, A6 should be pre-ferred, G9 confirms that A2, A4, and A5 may be better choices for the first version of the product while the company works on improving A6’s O.
4) According to G6 and G8, the function should be imple-mented in an easier to swap module (either product or service), but the company is not ready yet to go for A6. F. Set the Roadmap
A product roadmap was then set. Fig. 14 details how the im-plementation of the function “select/customize coffee variety”
Fig. 14. Smart coffee maker roadmap.
is going to evolve according to the monitoring of the market, technology, and environment, and how the product versions will incorporate this evolution.
V1) By using A2, the coffee maker will allow digital selec-tion. Although it delivers less value, it has high A and O and low E-tec, which opens the company’s doors to this new market and gives room for capacitating the company’s team and infrastructure to exploit the new technologies.
V2) By using A4, customization is possible. Although the company has the technology (high O), some maturing of the technology is still expected (low E-tec), and it might require some marketing actions to prepare the market (medium A).
V3) By using A5, remote customization is possible. This move requires technology choices to become more stable and the company to be able to deal with them. This choice delivers good value and has medium A, which might have increased after launching V2 with customization capabilities.
V3.1) By using A5+A6, services are added to the solution. This move requires more maturity from the market, the technology, and the company.
To support this roadmap, the “select/customize coffee vari-ety” function implementation should be segregated to a module that facilitates its evolution, thus giving more flexibility to the solution and reducing the cascade change effect. Considering this function delivers several high E-mkt requirements, the more software and service its implementation is based on, the higher its flexibility is, the quicker the company can respond to the market’s needs, and the lower is the impact/cost for evolving the product.
G. Manage the Roadmap
Managing the roadmap is based on monitoring the change drivers and revising the assumptions that determined the AEIOU values. To check the method capacity, two scenarios will be considered.
1) V2 and V3 are both based on the need for more ma-ture markets and technologies. By monitoring the change drivers and related assumptions, it is possible to determine
TABLE V
IDENTIFIEDCHALLENGESCOVERAGE
that these maturities were achieved earlier and that the company should skip V2 and develop V3.
2) A change in one of the previous driver-related assumptions can also be tracked to all the versions that were based on it. In this way, it is possible to identify all the versions impacted by the change. The full mapping of all the func-tions’ implementations (see Fig. 8) also makes it easier to determine the impact of changing requirements.
VI. REFLECTION
The proposed change-likelihood-based roadmapping method’s contribution to support PSS roadmapping can be set by analyzing to which extent it covers the PSS roadmap challenges and by the strengths and weaknesses perceived during its application.
The PSS roadmapping challenges identified point to the need to better deal with the integration among products and services and better manage changes in case of variations. Table V faces these challenges and indicates whether the proposed method covers them. It also compares the here proposed approach to the other approaches found in the literature (as in Table II). Because of the extensive spectrum of PSS (product-based, use-based, and performance-based and their variations), the presented example is limited, and the achieved conclusions require further valida-tion. Nevertheless, the example shows good management of the modules’ implementation evolution and the handling of both product and service implementations.
By analyszng the above application example, the method’s perceived strengths (S) and weaknesses (W) when addressing PSS roadmapping were found as follows:
S1) By setting the roadmap based on independent PSS functions with clear interfaces, the method implies an adaptable PSS architecture, which is easier to evolve and more robust to changes in the forecasted variable’s values determined in the initial roadmap.
S2) By basing itself in the relation among requirements, functions, and structure, the roadmap creates a two-way relationship with the company’s product development process (PDP). In this way, perceived changes in the AEIOU variables might become inputs to the PDP, and the PDP outputs might easily (also due to the function independence and clear interfaces) become part of fu-ture PSS versions.
S3) The method has its steps described in a practical way, which makes it easy to implement.
W1) Once roadmapping deploys the product strategy, and the product development contributes to executing it, keeping them synchronized might become a challenge. This is because all the roadmapping planning must be made using carefully defined functions.
W2) Related to W1, new functions might become necessary and might impact the other functions. This situation was neither discussed nor evaluated in the application. W3) The AEIOU variables’ values definition is empirical and
dependent on the evaluators’ experience and available knowledge. Therefore, it is not possible to guarantee that two people/groups or the same person/group in different moments will come to the same conclusions.
VII. FINALREMARKS ANDCONCLUSION
In this article, a new method for the definition and manage-ment of PSS roadmaps based on the change likelihood of market needs and technologies was proposed. Roadmapping usually delivers a planned evolution of technologies and its inclusion in the products that are then offered to the market. This plan is highly related to the expected future state of markets and technologies, so considering their related change drivers’ change likelihood and impact is important.
The proposed method has seven steps that were described in a comprehensive way and illustrated with an example. The smart appliance example (coffee maker) demonstrated the method’s applicability, and its practical description showed its repro-ducibility in different use scenarios.
The method differs from previous work by taking into account the market, technology, and environment change drivers and by representing their influence in the roadmap through the AEIOU variables. While traditional methods for risk and uncertainty representation mainly deal with the probability and impact of a change or risk, which are considered in variables E and I, respec-tively, the AEIOU are capable of discerning some specific and relevant roadmapping information, which are the risk sources related to AOU and E’s separation into E-mkt and E-tec. The drivers that lead to the AEIOU values also define the monitoring needs to guarantee that the roadmap reflects the actual reality.
The change drivers’ impact on the PSS requirements was then analyzed. A preliminary roadmap is set, which determined the
requirements to be included in each product version’s functions. By considering their change time horizon and impact, important insights can be found into the ideal modular architecture to handle these changes. In sequence, the best fit implementation for delivering these requirements is determined. In this way, product and service modules/parts contribute indiscriminately to the functions’ implementation, which shows no restriction regarding adding new modules or a shift from product to service modules and vice versa.
The method contributes to the roadmapping theory and to PSS roadmapping practice by covering both market and tech-nology changes. It plans the evolution of the PSS’s function implementation to either products or services in an integrated way. We observed that the proposed guidelines, based on the AEIOU variables, were effective for roadmap planning and can deal with challenges related to the complexity of a modular product and avoid the technology push effect. This article also adds value to the practice because the method is presented in a detailed and comprehensive way, thus allowing its application by practitioners.
Limitations to our research include the lack of a compre-hensive case and a real scenario. The case also involves partial coverage of the functions’ implementation change from products to services and vice versa. Therefore, validating the method re-quires more practical applications, which would, in turn, require further testing and refinements. Another limitation is the lack of benchmarking (process and results’ performance indicators) to other approaches by comparing their results for the same case.
Further work is necessary to validate the method in other conditions and for real applications, particularly products with variants. It is necessary to investigate whether the method can be adapted to set the roadmap for PSS families, where each of the PSS’s versions aim at different customers and deliver differ-ent values despite being supported by the same PSS platform. Finally, a more elaborate process for roadmap monitoring can be incorporated.
REFERENCES
[1] M. Pessoa and J. Jauregui-Becker, “Smart design engineering: A literature review of the impact of the 4th industrial revolution on product design and development,” Res. Eng. Des., vol. 31, pp. 175–195, Jan. 2020. [2] H. Meier, R. Roy, and G. Seliger, “Industrial product-service
systems-IPS2,” CIRP Ann.—Manuf. Technol., vol. 59, no. 2, pp. 607–627, 2010. [3] K. Nakamura, A. Kameoka, T. Fujiwara, and N. Kamada, “A service
concept framework based on the Maslow’s needs hierarchy and its applica-tion to typical types of service: Service value driven service roadmapping taking into account the dynamic service domain shift,” in Proc. Portland
Int. Conf. Manage. Eng. Technol., 2007, pp. 2769–2776.
[4] Y. An, S. Lee, and Y. Park, “Development of an integrated product-service roadmap with QFD: A case study on mobile communications,” Int. J. Serv.
Ind. Manage., vol. 19, no. 5, pp. 621–638, 2008.
[5] Y. Geum and Y. Park, “Development of technology roadmap for product-service system (TRPSS),” in Proc. IEEE Int. Conf. Ind. Eng. Eng. Manage, 2010, pp. 410–414, doi:10.1109/IEEM.2010.5674480.
[6] Y. Geum, S. Lee, D. Kang, and Y. Park, “Technology roadmapping for technology-based product-service integration: A case study,” J. Eng.
Technol. Manage., vol. 28, pp. 128–146, 2011.
[7] M. V. P. Pessôa and J. M. J. Becker, “Directives to support the design of changeable (I) PSS,” in Proc. 21st Int. Conf. Eng. Des., 2017, pp. 121–130, [Online]. Available: https://www.designsociety.org/publication/39617/ directives_to_support_the_design_of_changeable_ipss.
[8] L. T. M. Blessing and A. Chakrabarti, DRM, a Design Research
Method-ology, vol. 1. New York, NY, USA: Springer, 2009.
[9] J. M. Tholke, E. J. Hultink, and H. S. J. Robben, “Launching new product features: A multiple case examination,” J. Prod. Innov. Manage., vol. 18, no. 1, pp. 3–14, Jan. 2001.
[10] T. S. Baines et al., “State-of-the-art in product-service systems,” Proc. Inst.
Mech. Eng. B, J. Eng. Manuf., vol. 221, no. 10, pp. 1543–1552, 2007.
[11] A. Tukker, “Eight types of product service systems: Eight ways to sustain-ability?,” Bus. Strateg. Environ., vol. 260, no. 13, pp. 246–260, 2004. [12] J. C. Aurich, C. Fuchs, and C. Wagenknecht, “Life-cycle-oriented design
of technical product-service systems,” J. Clean. Prod., vol. 14, no. 17, pp. 1480–1494, 2006.
[13] O. Mont, “Clarifying the concept of product–service system,” J. Clean.
Prod., vol. 10, pp. 237–245, 2002.
[14] M. V. P. Pessôa and J. M. J. Becker, “Overcoming the product-service model adoption obstacles,” Proc. CIRP, vol. 64, pp. 163–168, 2017. [15] A. Richter, T. Sadek, and M. Steven, “Flexibility in industrial
product-service systems and use-oriented business models,” CIRP J. Manuf. Sci.
Technol., vol. 3, no. 2, pp. 128–134, 2010.
[16] E. Fricke and A. P. Schulz, “Design for changeability (DfC): Principles to enable changes in systems throughout their entire lifecycle,” Syst. Eng., vol. 8, no. 4, pp. 342–359, 2005.
[17] A. Engel and T. R. Browning, “Designing systems for adaptability by means of architecture options,” Syst. Eng., vol. 11, pp. 125–146, 2008.
[18] J. Montgomerie and S. Roscoe, “Owning the consumer-getting to the core of the Apple business model,” Account. Forum, vol. 37, no. 4, pp. 290–299, 2013.
[19] I. J. Petrick and A. E. Echols, “Technology roadmapping in review: A tool for making sustainable new product development decisions,” Technol.
Forecast. Soc. Change, vol. 71, no. 1/2, pp. 81–100, 2004.
[20] C. H. Willyard and C. W. McClees, “Motorola’s technology roadmap process,” Res. Manage., vol. 30, no. 5, pp. 13–19, 2017.
[21] P. Groenveld, “Roadmapping integrates business and technology,” Res.
Technol. Manage., vol. 50, no. 6, pp. 49–58, 2007.
[22] D. P. Alcantara and M. L. Martens, “Technology roadmapping (TRM): A systematic review of the literature focusing on models,” Technol. Forecast.
Soc. Change, vol. 138, pp. 127–138, 2019.
[23] K. Park and G. E. Okudan Kremer, “An investigation on the network topology of an evolving product family structure and its robustness and complexity,” Res. Eng. Des., vol. 30, pp. 381–404, 2019.
[24] H. ElMaraghy et al., “Product variety management,” CIRP Ann.—Manuf.
Technol., vol. 62, no. 2, pp. 629–652, 2013.
[25] D. Tsutsumi et al., “Towards joint optimization of product design, process planning and production planning in multi-product assembly,” CIRP Ann., vol. 67, no. 1, pp. 441–446, 2018.
[26] T. L. Flanagan, C. M. Eckert, J. Smith, T. Eger, and P. J. Clarkson, “A functional analysis of change propagation,” in Proc.14th Int. Conf. Eng.
Des., 2003.
[27] I. C. Wright, “A review of research into engineering change management: Implications for product design,” Des. Stud., vol. 18, no. 1, pp. 33–42, Jan. 1997.
[28] Y. Fu, M. Li, and F. Chen, “Impact propagation and risk assessment of requirement changes for software development projects based on design structure matrix,” Int. J. Proj. Manage., vol. 30, no. 3, pp. 363–373, Apr. 2012.
[29] P. Shankar, B. Morkos, and J. D. Summers, “Reasons for change prop-agation: A case study in an automotive OEM,” Res. Eng. Des., vol. 23, no. 4, pp. 291–303, Oct. 2012.
[30] S. K. Fixson, “Modularity and commonality research: Past developments and future opportunities,” Concurr. Eng. Res. Appl., vol. 15, pp. 85–111, 2007.
[31] S. Lee and Y. Park, “Customization of technology roadmaps according to roadmapping purposes: Overall process and detailed modules,” Technol.
Forecast. Soc. Change, vol. 72, pp. 567–583, 2005.
[32] R. K. Scalice, J. O. da Silva, J. N. Ostetto, and G. A. de Paula, “Modular deployment using TRM and function analysis,” Technol. Forecast. Soc.
Change, vol. 92, pp. 1–11, 2015.
[33] A. Sauer, A. Thielmann, and R. Isenmann, “Modularity in roadmapping— Integrated foresight of technologies, products, applications, mar-kets and society: The case of ‘Lithium Ion Battery LIB 2015,”
Technol. Forecast. Soc. Change, vol. 125, pp. 321–333, 2017, doi:
10.1016/j.techfore.2016.08.017.
[34] M. Hussain, E. Tapinos, and L. Knight, “Scenario-driven roadmapping for technology foresight,” Technol. Forecast. Soc. Change, vol. 124, pp. 160–177, 2017, doi:10.1016/j.techfore.2017.05.005.
[35] R. Phaal, C. J. P. Farrukh, and D. R. Probert, “Developing a technology roadmapping system,” in Proc. Portland Int. Conf. Manage. Eng. Technol., 2005, pp. 99–111, vol. 2005.
[36] R. Phaal, C. J. P. Farrukh, J. F. Mills, and D. R. Probert, “Customizing the technology roadmapping approach,” in Proc. Portland Int. Conf. Manage.
Eng. Technol. Technol. Manage. Reshaping World, 2003, pp. 361–369.
[37] R. Phaal and G. Muller, “An architectural framework for roadmapping: To-wards visual strategy,” Technol. Forecast. Soc. Change, vol. 76, pp. 39–49, 2009.
[38] N. Gerdsri, S. Puengrusme, R. Vatananan, and P. Tansurat, “Conceptual framework to assess the impacts of changes on the status of a roadmap,”
J. Eng. Technol. Manage., vol. 52, pp. 16–31, 2019.
[39] J. Savolainen and J. Kuusela, “Scheduling product line features for ef-fective roadmapping,” in Proc. 15th Asia-Pacific Softw. Eng. Conf., 2008, pp. 195–202.
[40] B. Hamraz, N. H. M. Caldwell, and P. John Clarkson, “A multidomain engineering change propagation model to support uncertainty reduction and risk management in design,” J. Mech. Des., vol. 134, no. 10, 2012, Art. no. 100905.
[41] J. S. Gero and U. Kannengiesser, “The situated function–behavior– framework,” Artif. Intell. Des., vol. 25, no. 4, pp. 373–391, 2004. [42] K. Wiegers, “First things first: Prioritizing requirements,” Softw. Dev.,
vol. 7, pp. 48–53, 1999.
[43] P. Achimugu, A. Selamat, R. Ibrahim, and M. N. R. Mahrin, “A systematic literature review of software requirements prioritization research,” Inf.
Softw. Technol., vol. 56, pp. 568–585, 2014.
[44] A. Herrmann and B. Paech, “Practical challenges of requirements pri-oritization based on risk estimation,” Empir. Softw. Eng., vol. 14, no. 6, pp. 644–684, 2009.
[45] Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 5th ed., 2013.
[46] J. H. Saleh, K. S. Marais, D. E. Hastings, and D. J. Newman, “The case for flexibility in system design,” INCOSE Int. Symp., vol. 12, no. 1, pp. 1049–1061, 2002.
[47] T. A. W. Jarratt, C. M. Eckert, N. H. M. Caldwell, and P. J. Clarkson, “Engineering change: An overview and perspective on the literature,” Res.
Eng. Des., vol. 22, no. 2, pp. 103–124, 2011.
[48] W. Bauer, F. Elezi, M. Roth, and M. Maurer, “Determination of the required product platform flexibility from a change perspective,” in Proc. 9th Annu.
IEEE Int. Syst. Conf., 2015, pp. 20–26.
[49] K. Karthik and K. J. Reddy, “Engineering changes in product design— A review,” IOP Conf. Series, Mater. Sci. Eng., vol. 149, 2016, Art. no. 012001.
[50] ISO/IEC/IEEE. Systems and Software Engineering System Life Cycle
Processes, ISO/IEC 152882008(E) IEEE Std 15288-2008 (Revision IEEE
Std 15288-2004), 2008.
[51] P. Gu, M. Hashemian, and A. Y. C. Nee, “Adaptable design,” CIRP Ann., vol. 53, no. 2, pp. 539–557, 2004.
[52] M. E. Sosa, S. D. Eppinger, and C. M. Rowles, “Identifying modular and integrative systems and their impact on design team interactions,” J. Mech.
Des., vol. 125, no. 2, pp. 240–252, Jun. 2003.
[53] S. Kim and J. S. Baek, “Diagnosis of current smart home appliance development process for application of PSS design methodology,” in Proc.
