D1.1 Elicitation of Engineering and Business Requirements

Transcription

1 Horizon 2020 Acronym: Manutelligence Project No: Call: H2020-FoF-2014 Topic: FoF-05 - Innovative product-service design using manufacturing intelligence Type of action: RIA Duration: D1.1 Elicitation of Engineering and Business Requirements Type Deliverable Document ID: D1.1 Workpackage: WP1 Leading partner: VTT Matteo Cocco, Sergio Terzi, Pekka Puranen, Iris Author(s): Karvonen, Kim Jansson, Heidi Korhonen, Tapani Ryynänen, Claudio Violi, Reinhard Ahlers, Donatella Corti, Dissemination level: PUBLIC Status: Date: Version: Final Copyright Manutelligence Consortium Manutelligence N

2 Table of Contents Table of Contents... 2 Executive Summary Introduction and scope of this deliverable Scope Objectives of the deliverables Relations to the other WPs Structure of the deliverable Requirements engineering (RE) for Product Service System (PSS) Definition of Requirements Engineering (RE) for Product- Service Systems (PSS) Requirements Engineering (RE) Approaches for Product Service Systems (PSS) Requirements Engineering Approaches in Product Engineering Requirements Engineering Approaches in Service Engineering Requirements Engineering Approaches in Software Engineering Requirements Engineering Approaches in Product Service System (PSS) development Analysis of the RE approaches Requirements Engineering (RE) approach in Manutelligence Requirements engineering process in Manutelligence Requirements elicitation techniques in Manutelligence Pre- elicitation Elicitation Elicitation selection techniques Requirements elicitation in the pilot scenarios Automotive Description Questionnaire and interview report Process mapping at glance Pilot stories Unstructured list of requirements Intelligent student home Description Questionnaire and interview report Process mapping at glance Pilot Stories Unstructured list of requirements Cruise vessel Copyright Manutelligence Consortium Page 2 / 163

3 4.3.1 Description Questionnaire and interview report Preliminary Process mapping Pilot story Unstructured list of requirements FABLab/ADF Description Questionnaire and interview report Preliminary Process mapping Pilot stories Unstructured list of requirements Requirements from technical work packages General requirements Data requirements Data Consistency: the platform assures the consistency of data: data cannot be written violating the database own rules for valid data. If a certain transaction occurs that attempts to introduce inconsistent data, the entire transaction is rolled back Summary and Conclusion References Annex Copyright Manutelligence Consortium Page 3 / 163

4 Executive Summary The main purpose of the Manutelligence project is the development of a platform for Product- Service Design and Manufacturing Intelligence. The first question that arises from this statement is Why we have to develop a platform?. Basically a platform is an IT infrastructure that includes and integrates different IT applications conceived for creating, visualizing, managing, accessing and analysing data for supporting specific phases of the company business processes. Thus the answer is not trivial, the platform ensures a business infrastructure able to guarantee a reliable and correct source of data (Data management) as well as support business processes (workflow) using defined rules and methodologies. Although the development of a platform can solve many issues, in Manutelligence it will require a meticulous analysis of the business problems and processes in order to understand how the platform could support the development of the design process of products and services. Consolidated the role of the platform the second issue is about the contents, which data should be managed?. In Manutelligence the focus is on product and service life cycle information and data related to their analysis. Managing the products data is not a simple job however the PLM systems offer a valid support to the development of the design phases. On the other hand managing the development of services is still an open question and probably will require a specific data model analysis as well as a business model shift that will be explored in Manutelligence. Finally, related to the data model structure is important to define which features should have the platform. The idea is to define the requirements for the implementation using a scenariobased approach considering the needs of the four industrial pilots (Automotive, Ship, Student house, FabLAB). In conclusion, Manutelligence project has to answer to all these questions and have to define the data model and the dynamic interactions at the moment missed for integrating and providing a holistic product-service. Copyright Manutelligence Consortium Page 4 / 163

5 1 Introduction and scope of this deliverable 1.1 Scope This deliverable, is a part of Manutelligence WP1 Engineering and business requirements for holistic P-S development processes in the targeted application sectors. The overall objectives of the WP1 are to define, document and maintain a complete and exhaustive list of engineering and business requirements to be taken into account in order to guarantee an effective and efficient implementation of the Manufacturing Intelligent Engineering Platform. According to the DoA the main subject of this deliverable is the Elicitation (Task 1.1), which is the first phase of the obtaining requirements process. However, this process is not trivial indeed there is a complex discipline, named Requirements Engineering (RE), for this purpose. Therefore, this deliverable firstly presents an analysis of the state of art of the existing RE approaches suited for holistic Product Service, in order to identify which approach can be adopted in the scope of the Manutelligence project. Then, special emphasis is placed on the analysis of the requirements elicitation, in order to define the suitable techniques for gathering requirements. The idea is to apply the selected elicitation techniques addressing basically a top-down scenario-based approach considering as stakeholders the four industrial pilots detailed in WP6 and the technical work packages such as WP2 and WP5. The result of this first elicitation phase is a list of unstructured requirements from each industrial pilot and from the technical work packages. This deliverable only address the early phase of RE, later phases, which require analysis, structuration, refinements and validation of the requirements, are beyond the scope and are going to be considered in the following WP1 deliverables. Furthermore definitions of PSSs are given in the Glossary that is an appendix of D Objectives of the deliverables D1.1 contains the Elicitation of requirements. Therefore the following objectives have been determined for the deliverable: Overview of the general Requirement Engineering processes and approaches for PSS, including analysis of the domain-specific approaches. Selection and development of the Requirements Engineering methodology suited for the Manutelligence project; Copyright Manutelligence Consortium Page 5 / 163

6 Description of the requirements elicitation in Manutelligence, including the selected techniques; Report of the elicitation requirements applied in the pilot use cases; List of unstructured requirements coming from industrial pilots and from technical work packages. 1.3 Relations to the other WPs The main outcome of this deliverable is a list of unstructured requirements elicited from the industrial pilots defined in WP6 in which the AS IS and TO BE scenarios are deeply analysed and decomposed into sub use cases. Moreover technical requirements that the Manutelligence platform has to satisfy considering needs coming from Life Cycle Assessment (LCA) and Life Cycle Costing (LCC) tools are identified from the technical work package WP5. According to this structure these four work packages have a mutual interdependency as shown in Figure 1. WP1$ T1.1$ D1.1% Pre:elicita*on$ques*onnaire$ Elicita/on% Ques*onnaire$ Process$Mapping$ Pilot$Story$ D6.1%%D6.4%%D6.7%%D6.10% Pilot$objec*ves$and$ Benefit$ Scenario%defini/on% Challenges$ WP6$$ T6.1$ T6.2$ T6.3$ T6.4$ Pilots%(AS%IS%&%TO%BE)% Use$case$defini*on$ Glossary$$ First%list%of% unstructured% requirements% LCC/LCA$tool$ requirements$ WP2$ WP5$ T2.1$ T5.1$ Structure of the deliverable Figure 1 WPs interdependencies The structure of the deliverable is grouped into three major blocks, according to the objectives described in section 1.2 (Figure 2). Copyright Manutelligence Consortium Page 6 / 163

7 D1.1$ $Elicita,on$of$Engineering$and$Business$Requirements$$ Structure' Block'A' Introduc1on'' Requirements'Engineering' for'product'service' System' Block'B' Requirements'Elicita1on' Techniques'in' Manutelligence' Requirements'Engineering' process''in' Manutelligence' Block'C' Requirements' Elicita1on'in'the' pilot'scenarios'' Requirements'from' technical'work' packages''' Summary'and' Conclusion'' Figure 2 Deliverable Structure Block A has the function to give a preface to requirements elicitation in Manutelligence by integrating the topic into the project context. Objectives and tasks of the respective WP s are described and matched with the general process of Requirements Engineering. It consists of chapters 1 and 2, including the state of art of the Requirements Engineering (RE) for the product service systems (PSS) and the analysis of the identified RE approaches toward the overall objectives of the Manutelligence project. Block B is presenting the requirements engineering approach adopted in Manutelligence and the state-of-the art of requirements elicitation techniques. It includes conscious, unconscious and undreamt techniques as described in chapter 3. The state-of-the-art provides the scientific foundation for the selection of requirements elicitation approaches in the project according to the overall objectives and constraints of the Manutelligence project. Block C contains the reports and results of the elicitation techniques applied to the four Manutelligence use cases (chapter 4). Using the elicitation techniques a first list of unstructured requirements has been identified for each pilot. In addition also the requirements from technical work packages are elicited in chapter 5. The overall results will be structured and analyzed in the following tasks of the WP1. The last chapter is the conclusion of the deliverable. Copyright Manutelligence Consortium Page 7 / 163

8 2 Requirements engineering (RE) for Product Service System (PSS) 2.1 Definition of Requirements Engineering (RE) for Product-Service Systems (PSS) Pohl et al. (2007) pointed out that Requirements Engineering (RE) is seen as crucial factor in the development process [3]. RE is concerned with the identification of the goals to be achieved by the envisioned system, the operationalization of such goals into services and constraints, and the assignment of responsibilities for the resulting requirements to agents such as humans, devices, and software [31]. Requirements engineering is the process of discovering, documenting and managing the requirements [19], which is accompanying the planning and development of a system [2]. However the RE for PSS is slightly more complex because according to Berkovich (2014), integration of PSS into the organization requires a complete understanding of the customer business process as well as of the company support process. Therefore, RE for PSS has to define the requirements resulting from the business processes in order to support the developers. RE must be able to create a common understanding of the problem to be solved in all domains and handle the requirements to the entire PSS. The RE should figure out the customer requirements and translate them into the requirements to domain-specific components of PSS (software, hardware and service organization) [24]. The RE tasks has been defined by Pohl (2007), RE should therefore elicit all requirements, analyse and negotiate them, reach a sufficient agreement on the known requirements, and document them in accordance with the defined directions. Finally the requirements should be validated based on the requirements document, which further sets up the system specification [3]. On the other hand Tuli et al. (2007) described the life cycle of the PSS in four main phases, namely, customer requirements definition, customization and integration of products and services, deployment and post-deployment customer support [32]. In the analysis carried out by Berkovich et al. (2011) is clarified the role of RE in the lifecycle of PSS, in detail they contrast the task areas of RE and the life cycle phase of RE, keeping in mind the characteristics of PSS [14]. In the customer definition phase, the requirements to PSS are elicited and analysed. Having collected all relevant requirements, they are documented in a way that provides a common understanding for all domains participating in the development process. Thereby RE must identify existing product components and services and combine them in order to define a product structure that consists of tangible and intangible elements created for illustrating the PSS.. To achieve this, RE has to concretize the initial requirements written in the stakeholder language [14]. Concretization means to define quantitative or qualitative target information for each of the initial requirements. After the concretization the requirements are validated presenting them to the stakeholders in order to Copyright Manutelligence Consortium Page 8 / 163

9 explore whether or not they meet their wishes. The customization and integration of product and services, according to Tuli et al. (2007), comprises the coordinated and integrated development of the different components by the respective domains and they are combined in an overall solution [32]. During this implementation the requirements can change thus the RE has to collect all changes in the specification, identify their impacts on other requirements and components of the PSS, and finally measure the effects of the change. In the last phases the deployment and the post-deployment of customer support, the PSS is integrated into the value chain process of the customer (deployment) or the PSS is maintained, supported and disposed after the end of the product life cycle (post-deployment)[32]. In this phase the task of the RE is to update the current specifications and to keep them up-to-date [14]. 2.2 Requirements Engineering (RE) Approaches for Product Service Systems (PSS) According to the investigations given in D2.1 and to Strum and Bading (2008), the development of Product Service System is mainly affected by the coordination of the involved domains, such as product, software, and service engineering, by the different lifecycles of the components and their interdependencies, as well as by a high degree of customer interaction [1]. However in literature, there are several approaches in different domains concerning requirements engineering thus the target of this section is to point out: - what are the selected domain-specific approaches of RE, suited for PSS and - which of these can be used in the development process of PSS in Manutelligence. The definition of the domains to be considered for the requirements generation for PSS has been carried out by Müller et all. (2010), they considered four domains such as: Product development; Service engineering; Software engineering; PSS development; As PSS integrate products and services, the consideration of product development and service engineering is clear. As many functions of modern products and services are provided and supported by information and communication technologies, IT approaches for software development are obviously important. In addition, the existing PSS development approaches are in the scope of this analysis [2]. In order to have a better understanding of the subsequent analysis, the selected RE approaches are following briefly described Requirements Engineering Approaches in Product Engineering Most development approaches in product engineering take RE in first step of the development Copyright Manutelligence Consortium Page 9 / 163

10 process. For example, the methodology developed by Ulrich and Eppinger (2003) collects the requirements in hierarchical weighted list. The authors state that it is important to reveal implicit customer-needs and that a common product understanding between customer and engineering is absolutely necessary [3]. Ehrlenspiel (2002) defines an iterative process for eliciting the requirements. He suggests using checklists to support the customer interviews and to overcome misunderstandings between the customer and the engineer [5]. Cross (1996) suggests a goal tree, which is used to collect the initial requirements. During the development process the requirements are refined as the problem of understanding of the customer and engineers increases [6]. Pahl (2007) in his work proposed a sequential process model in which the engineering has to extract requirements from the customer wishes; however the customer often it is not able to express his requirements appropriately [7]. As a matter of fact, these methodologies are used to determine the stakeholders and their requirements for the solution. However the requirements gathered from stakeholders often are qualitative and imprecise, thus they must be concretized and translated into the language of the product developer, including quantitative and detailed information for the product development [7]. This step ensures that the stakeholder requirements are translated into design requirements that can be understood and implemented by designers. According to Berkovich (2011), although requirements concretization is one of the key elements in RE, it is not mentioned explicitly in the analysed approaches [3]. In addition, also conflicts between the requirements should be identified and mitigated as soon as possible [4]. The resolution of the conflict leads changes in the requirements that often are responsible for disrupting the product development schedule, increasing development costs, and failing to meet requirements [8]. Afterwards, the concretised requirements have to be validated by using for example simulation tools [3] and should be modularised in order to define modules and interfaces for further reuse in different products [5]. The majority of the identified approaches adopt the waterfall model such as that in Pahl (2007) [7]. However in practice, iterative processes such as spiral model are frequently used. In other words all the RE phases are performed iteratively and should be integrated into the development process [4] Requirements Engineering Approaches in Service Engineering Service engineering has been defined by Bullinger et al. (2003) as a systematic development and design of services using suitable models, methods and tools. The service engineering process can follow the traditional waterfall or the spiral approach however in both of them the RE represents a pivotal phase of the service development process. The identification of the requirements starts with the definition of the essential information about service idea, key clients, and source of requirements such as customer and suppliers [9]. To elicit the requirements the customer should imagine the service and should then express a hypothetical evaluation [10]. Also Müller (2010) in his analysis has identified a contribution proposing a checklist to discover stakeholders and influencing factors to analyze requirements for services Copyright Manutelligence Consortium Page 10 / 163

11 [2]. In the further phases of the RE the objectives, the changes and the risk are determined. According to Ramaswamy (1996) the initial requirements can be concretized by assigning them quantifiable attributes related to the implementation of the services [11]. The analyzed approaches do not focus on the identification and resolution of conflicts between the requirements. In addition in service engineering the benefit of modularization and reuse are recognized [4]. In conclusion, there are some RE models for service engineering. These models describe the RE process on a very high level: the only tangible statement is that the integration of stakeholders is an important factor for the development of service Requirements Engineering Approaches in Software Engineering According to Sommerville (2004) the RE in software development is a process of defining the relevant requirements, by identifying all stakeholders and their needs, and by documenting the requirements in the form of a specification that can be used for communication, further analysis and implementation [12]. Process activities include requirements elicitation, requirements analysis and negotiation and requirements validation [19]. These tasks are seen also as structural elements in the framework defined by Pohl (1994) [16]. Effectively, RE in software developments represents a separate discipline. In Figure 3 the RE process is depicted according to the definition given Sawyer and Kontoya (2001) [20]. Copyright Manutelligence Consortium Page 11 / 163

12 Figure 3 - Iterative RE process for software engineering [20] As shown in the Figure 3, the RE is not a linear process but an iterative process. The outcome of the RE process is the requirements document and the system specification respectively. The phase of requirements acquisition can start once the aim of the project has been established [13]. According to the analyzed literature the process of software RE starts with the elicitation and capturing of the requirements [17]. The task of requirements elicitation is the identification of requirements sources and the elicitation of requirements according to the identified stakeholders and other requirements sources [14]. The elicitation is performed using different methodologies such as interview, questionnaire also observation, brainstorming, prototyping, mind-map and checklist [14]. In this phase, human activity is fundamental and it is necessary to identify users involved in the process and establish a relation between them and developers [20]. In the next step, the requirements should be analyzed and negotiated in order to detect and resolve conflicts, to discover the bounds of the system and elaborate system requirements to software requirements. Requirements analysis includes also requirements classification and priority, conceptual modeling, architectural design, requirements allocation and requirements negotiation [20]. In the subsequent documentation phase, also called requirements specification, essential information about the requirements (e.g. description, changes or responsibilities) should be specified [14]. In other words, the documentation should describe the structure, quality and verifiability of the requirements Copyright Manutelligence Consortium Page 12 / 163

13 document [20]. Pohl (2007) proposed a natural language based and model based form for specification. Model based documentations are based on languages such as UML [14]. During the requirements validation the requirements are checked for ambiguity and falsity [19]. The main goal of this task is to check if the requirements specify the system as the customer wants and needs it. The methods for validation presented by Sommerville and Kotonya (2001) are reviews, prototyping and testing. Pohl (2007) suggests inspection, reviews, walkthroughs, perspective-based reading and prototypes [14][20]. In conclusion, RE in software engineering is highly elaborated and many methods and process models are known [10]. Software RE is an iterative activity, which is performed throughout the entire software development process Requirements Engineering Approaches in Product Service System (PSS) development In literature, there are many approaches for the development of integrated products and services, however the RE in these studies seems to be barely considered. Berkovic et al. (2010) stated that the PSS development process consists of combination of hardware, software and service elements [10]. Aurich et al. (2007) proposed a process model for the lifecycle management of PSS. In the first phase of the model the organizational conditions are created in order to ensure an integrated development of services and hardware/software, then the requirements are elicited, analyzed and categorized [23]. Another new RE approach has been pointed out by Wiesner et al. (2013): their study implies the use of serious games for gathering requirements in a manufacturing service ecosystem [22]. The paper by Lindhal et al. (2007) highlights that a pivotal phase in the RE in PSS development is to identify the customer needs in term of goods and services [21]. Berkovich at al. (2014) recognizes the complexity of PSS development, thus they provided a requirements data model for the concretization of requirements, which specially addresses the problem of structuring, enabling traceability, and findings conflicts [24]. Müller et al. (2010) defined the guideline to elicit requirements on industrial product-service system [2]. According to the analyzed studies the topic of RE in integrated development for PSS is abstractly discussed without going into detail on the specific activities of RE Analysis of the RE approaches The importance of the RE in the development process is recognized by all the four disciplines of product, software, service and product-service. In detail, the RE in software engineering is consolidated in the development process and there are many approaches for gathering and managing requirements. Also in product engineering RE is widely adopted and integrated in the engineering process, however most of the methodologies consider RE only in the first phases of the process. Finally, service and PSS engineering are still young practices and lack support from systematic approaches that consider all the tasks of RE. Although there are many models, the abstraction of these models is really high so they are not relevant for Copyright Manutelligence Consortium Page 13 / 163

14 practical use [10]. Moreover, in the considered domains the RE is often implemented as an iterative process following the classical spiral approach. In order to define which of the analysed approaches are suited for the purpose of Manutelligence, the four RE domains are set in connection to the RE aspects considered in the description of action of the project. Table 1 summarizes the analysis results for the domain specific approaches and the integrated approaches for the development of PSS. The evaluation criteria are derived from the aspects covered in the description of action (DoA). Criteria Approaches of product engineering Approaches of service engineering Approaches of software engineering Approaches of integrated development of PSS Techniques for requirements elicitation (Task 1.1) Formal methods for requirements structuration (Task 1.2) Methods for requirements refinements and analysis (Task 1.3) Procedures for requirements validation (Task 1.4) Support the development of holistic P- S (Overall WP1) Completely covered Not Covered Partially covered Copyright Manutelligence Consortium Page 14 / 163

15 Table 1 Analysis of the Manutelligence aspects in the four RE domains Table 1 highlights the most significant differences and deficiencies of RE for the development of a PSS according to the aspects considered in the Manutelligence project. Firstly, RE in software engineering is most elaborated and seems to completely cover all the considered aspects meanwhile the RE for service and PSS development have the biggest gaps. Secondly, the literature analysis reveals that the existing integrated approaches for PSS development are still embryonic and do not properly cover all the relevant RE aspects needed in the Manutelligence project. Finally, the integration of the service is neglected in the software and product RE approaches, nevertheless it is barely considered in the service development and fulfilled in the integrated PSS approaches. According to these findings, it is necessary to develop a model with modelling methods and supporting tools for covering all the RE aspects required in Manutelligence project for the PSS development. This model should consider all the RE phases capturing changes and interdependencies between requirements. Furthermore, the model should be able to understand the holistic P-S and its interaction with software, products and service components along the whole development process. Therefore the aim in this section is to develop a crossdomain model in order to enhance the comprehension of the requirements and their handling. Copyright Manutelligence Consortium Page 15 / 163

16 3 Requirements Engineering (RE) approach in Manutelligence 3.1 Requirements engineering process in Manutelligence The main purpose of this section is to introduce a model for gathering requirements in the Manutelligence project and for better coping with issues that affect the development of a PSS. This model does not want to completely replace other methods but its purpose is to present a cross-domain approach able to solve some of the particular issues that affect the classical RE approaches. According to the analysed literature the idea is to have an iterative model based on the classical spiral approach in which each circle goes through the main four phases that compose the requirements process in Manutelligence: Elicitation (Task 1.1), Structuration (Task 1.2), Analysis and Refinements (Task 1.3) and Validation (Task 1.4). In each phase of the RE process the PSS dimension will be taken into account in order to ensure from the very beginning of the development the integration of the service package. Therefore mixing the spiral approach coming from the software and product RE domains with techniques capable to collect requirements in the service and PSS domains drives the definition of a cross-domain model that could be suitable for identifying a complete and exhaustive list of engineering and business requirements for the P-S development. These activities are crucial due to the fact that they provide foundations for the successful integration and exploitation of the Manutelligence platform, which is the target of the project and will encompass software, products and services components. The Figure 4 shows the abovementioned model. Figure 4 Requirements Engineering process model in Manutelligence Copyright Manutelligence Consortium Page 16 / 163

17 All the cycles are the same except the first one because it has the role to initialize the process introducing the context and a first list of requirements (Figure 5). Then the other cycle represents the continuous improvement of the requirements. The WP1 considers only the initialization phase because the further cycles start in parallel with the integration of the platform and are considered in other WPs. Figure 5 First cycle in the RE process in Manutelligence According to the DoA the four RE tasks are: Elicitation (Task 1.1): the elicitation represents the first phase of the requirements engineering process in Manutelligence, indicating the activities concerned with the identification and analysis of the real-world requirements. During this process heterogeneous tensions and opportunities coming from different stakeholders involved in the P-S development will be identified; Structuration (Task 1.2): the requirements extracted from the elicitation do not yet represent a knowledge base and cannot be used as a reference from the implementation of the platform, due for instance to their different formats and standards. Thus, the main objective of the structuration is to unify and integrate the information collected in the previous step from disparate sources and organize them into a common structure that can be used for analysis. Structuration includes also specific preparation activities of the information in order to reduce anomalies and inconsistencies, thus allowing an efficient and effective integration. Refinement and Analysis (Task 1.3): the target of this activity is to refine and verify the previous elicited requirements. The refinement consists in the assessment of the completeness, coherence and feasibility of the stakeholders requirements then identified requirements should be mapped across the P-S lifecycle. Indeed, the Copyright Manutelligence Consortium Page 17 / 163

18 analysis implies the evaluation of the relation to the added value for the Manutelligence platform development, integration and exploitation. These activities ends with the definition of a document containing the technical requirements. Requirements validation (Task 1.4): the validation purpose is to show the actual requirements to the stakeholder involved in the P-S life cycle in order to understand if the actual definition fits their needs. This deliverable D1.1 focuses on the Elicitation phase and techniques, which are detailed in the following sections. 3.2 Requirements elicitation techniques in Manutelligence Pre-elicitation Pre-elicitation phase has been represented in the overall process as a Red Point (Figure 6). The purpose of this pre-activity is to introduce the context of the company to the Requirement Engineer who has the role of leading the stakeholder involved in the P-S life cycle to a solution based on its needs. Figure 6 Pre-Elicitation This phase has been designed to guide Requirements Engineer to find a solution for the following difficulties: Understand client wishes Manage client expectations Clear object identification Copyright Manutelligence Consortium Page 18 / 163

19 For accomplishing this purpose it is necessary to identify the context in which the Manutelligence project will be developed. To do this, it is necessary to gather some information related to the company in order to identify into the process issues that need to be solved. These issues do not represent requirements or needs that the project has to provide, but they just give an idea about context and objective important to guide the project to satisfy client needs. As previously explained, the stakeholder may does not have a clear idea on what he needs to solve his problem. For this reason, a previous assessment on the process work could facilitate the identification of improvements areas. Moreover, in case of complex project such as Manutelligence it is not easy to identify in a big set of requirements what is important and what it is not. Focusing on these areas will help Requirements Engineer to increase stakeholder satisfaction and achieve project objectives. In order to address these topics a solution proposed by the model is to use a short questionnaire to investigate about the understanding of the holistic P-S and what are the stakeholder expectations from the project. This it is a kind of close interview technique in which the stakeholder answers to a predefined set of questions. The results from the questionnaire will highlight the gaps between theory and practice. Areas with a great gap will represent the main areas on which spend more commitment in order to achieve client satisfaction. The questionnaire used in the four pilots is reported in the Annex Elicitation The elicitation is the first step for the initialization of requirement process [25]. Requirements elicitation is defined as a process to understand a problem and its application domain [12]. Müller et al. (2010) stated that this phase includes the retrieval, the awareness of the relevant issue and the formulation in order to document and model requirements [2]. The success of the requirements elicitation activity gives high impact on the achievement of the correct application [29] (Figure 7). Copyright Manutelligence Consortium Page 19 / 163

20 Figure 7 Elicitation In this phase the Requirements Engineer aim is to gather user requirements. User requirements describe both functional and non-functional requirements without any technical description. Only specification about external behavior of the software, design and characteristics will be provided so far. Before starting to describe the activities concerned in this phase, it is necessary to clarify the meaning of elicitation. Elicitation is defined as: Acquisition of information from a group of people in a manner that do not disclose the intent of the interview or conversation In our case it does mean that we do not have to explain to the interviewee the purpose of the inquiry, but the point is that often it happens that stakeholders do not have an IT background as well as they do not know what is a PSS. This condition may lead to a situation in which stakeholder is unable to properly explain why, what, or which functions the system should include into the set of requirements. This phase has been designed to consider the following issues in the Manutelligence project: Understand client desiderata Communicate stakeholder need vs Requirements Engineer Avoid failure in gain user commitment Difficulties in articulate what stakeholders really want from the system Manage stakeholder expectations Different stakeholders have different needs As this previous list of issues may suggest, this phase has been designed with a strong emphasis on the stakeholder s point of view. This decision is due to the importance of Copyright Manutelligence Consortium Page 20 / 163

21 stakeholder s commitment and involvement in the initial phase. From this point of view it is possible to classify requirements in three different strands: l CONSCIOUS: a conscious requirement is something that the stakeholder is particularly aware of. So, it will be easy to retrieve this kind of requirements from the client. l UNCONSCIOUS: An unconscious requirement represents a requirement that the client desires but for some reason he is unable to express or he just forgot to elicit. This is the main problem regarding unconscious requirements. Often it happens that the stakeholder knows a lot about his domain and unfortunately this leads him to make a lot of assumptions. Worse, sometimes it is hard to elicit requirements due to a low level in client commitment caused by clients assumption that any new product will maintain the currents status. l UNDREAMT: an undreamt requirement is a requirement that stakeholders are unable to express because they think they are not possible or because they are new ideas that have occurred to them. Undreamt of requirements are even more difficult to discover. These are the ones that surface after the new system has been in use for a while. "I didn't know that it was possible otherwise I would have asked for it.". As a matter of fact the developers or the external stakeholders such as technical specialists will elicit many of these undreamt requirements. They can improve a lot the system quality and completeness in requirements because they are the owners of the knowledge, the so called how to do. In Figure 8 the best way to accomplish this activity is represented: it starts with gathering conscious requirements and then starts gathering all the others in parallel. The Elicitation phase starts with the conscious requirements that are important for increasing the Requirement Engineer domain knowledge. Then, the other two steps could be conducted in parallel in order to create synergies between them. Copyright Manutelligence Consortium Page 21 / 163

22 CONSCIOUS' UNCONSCIOUS' UNDREAMT' Figure 8 - Elicitation sub-processes Object of this model is to provide not only a new approach in gathering requirements but also provide practical requirements elicitation techniques that may help to collect specific kind of requirements for PSS development. According to Hickey et al. (2003) requirements elicitation techniques are the means by which systems analysts determine the problems, opportunities, and needs of the stakeholders, so that systems developer can construct systems that actually resolve those problems, leverage those opportunities, and/or address stakeholders needs [27]. According to the classification given by Burge (2001) many methodologies and techniques exist, all with the common aim to assist analysts in understanding needs. Due to the duration of the Elicitation task (6 months) and to the availability of the resource involved in the Table 2 the most suitable practical elicitation tools and techniques for the Manutelligence project are matched towards the three identified sub-process [28]. Elicitation Techniques Sub-processes Result Interview & Questionnaire Pilot stories Process mapping Document & System analysis Focus Group Conscious Conscious Conscious Unconscious Unconscious Depending on the question asked Procedures followed, rationale. Mapping of the process, requirements source. Information from existing systems and documents Procedures, difficulties encountered during the interaction. Copyright Manutelligence Consortium Page 22 / 163

23 Apprenticing Unconscious Extract the tacit knowledge Brainstorming Undreamt Idea, information and requirements from collective mind Table 2 Selection of elicitation techniques classified towards the identified sub-process Table 2 reports the suitable elicitation techniques, in term of usability, that are mentioned in literature for the Manutelligence project Elicitation selection techniques Many requirements problems are due to poor requirements elicitation, including the resulting requirements being ambiguous, incomplete, not verifiable, inconsistent, irrelevant, and not correct because they do not reflect the stakeholders needs and objectives. These problems rise from issues of scope, communication and requirements volatility. There are elicitations techniques, which address some of these issues. However, no technique is comprehensive enough to adequately cover all of these issues in detail. Rather than advocating one technique over the others, a better approach to requirements elicitation is to synthesize the various methods and techniques into a methodology [30]. In the Manutelligence project according to the time constraints and to the resource available, our purpose is to use in the initialization phase mainly conscious techniques in order to find out the first list of requirements and for gathering all the possible information about the PSS, which could be suitable for developing the integrated platform. The selected elicitation techniques that are used in this first iteration cycle are described in what follows Interview and Questionnaire Interview and Questionnaire are probably the most common way for gathering requirements. Interview is when you have the opportunity to talk with an expert about a bounded area of subject matter. In other words, it is better to go to the interview with a well-formed intention of what you wish to achieve. In this way the Pre-Elicitation phase plays an important role in defining the final scope of the interview. This kind of interview is called Open interview. Questionnaires are very important technique in requirements elicitation techniques, questionnaires helps to get the information from many peoples, analyst can gather opinions from two ways: to get statistical evidence for an assumption, or to gather opinions and suggestions [28]. In Manutelligence a comprehensive questionnaire has been developed with the purpose of investigating the industrial practices in product and service (P-S) development and data management in the four pilots. However the product and service development process is a complex environment, in which many actors collaborate and share their Copyright Manutelligence Consortium Page 23 / 163

24 knowledge, using different methods and tools. The questionnaire has been structured in order to cover the holistic P-S development, indeed the sections are: Part 1. Part 2. Part 3. Part 4. Design process at glance; Managing knowledge in a design and development context; Managing the development of the PSS; Evaluating the lifecycle of the PSS. The complete pre-elicitation questionnaires as well as the complete elicitation questionnaires are reported in the Annex Process Mapping The process mapping is the analysis of how client is currently working in order to retrieve requirement useful to build the future system The second purpose of this technique is to clearly identify all requirements sources. Once traced the model, it is possible identify all information, people or documents related to the final purpose. There is a wide range of modelling methods, each of them have different characteristics for satisfy different needs in description modelling. In Figure 9 it has been reported a comparison analysis between three methods designed for different purposes. Figure 9 Model Method comparison At this stage it is necessary to use an easy language to read in order to make the model readable for everybody and capable to capture a high level detail. For these reasons probably the most suitable method for the Manutelligence project is the standard model language EPC (Event Process Chain - or the IDEF0. Copyright Manutelligence Consortium Page 24 / 163

25 Pilot stories The pilot story is a customer and user centric methodology, useful to understand the whole domain of the project. A pilot story basically is a storytelling with a description of how user will interact with the Manutelligence platform rather than how it works internally or how it will be designed. Basically the pilot story is built on the TO BE scenarios. This technique should be the last to be implemented because needs a precondition for its application: product vision. A product vision represents a sketch of the future product, the overarching goals of the project and the overall architecture. Luckily in the Manutelligence project the vision is strongly consolidated thus since the first initialization phase, therefore for each of the pilot a story can be defined. Copyright Manutelligence Consortium Page 25 / 163

26 4 Requirements elicitation in the pilot scenarios 4.1 Automotive Description One of the aims of Ferrari is to enhance for the end users the so-called Ferrari experience, this experience is basically composed by the pleasure of riding a Ferrari and the thrill of drive that the car can provide. These elements of the experience are not trivial to be managed and the implementation requires a specific designed vehicles and services. Effectively, the flavour of the experience is strongly related to the delivered product (performances, quality, etc.) as well as to the related services (pilot courses, programmed maintenance etc.). Thus the purpose of the automotive pilot within Manutelligence is to integrate the various phases of the Ferrari design process demonstrating how the use of a platform can boost the Ferrari experience supporting the development of new P-S as well as the management of the existing P-S. Therefore the various aspects of P-S, such as the specific P-S requirements and certain design changes, should be considered from the very beginning of the development process and managed in the Manutelligence platform. In addition particular data model should be implement and integrated with IoT technologies for creating the infrastructure for managing data from field. The elicitation in the automotive pilot has the purpose of extracting the requirements for achieving these challenging objectives and places the basis for the correct implementation of a platform capable to support the P-S design Questionnaire and interview report Pre-elicitation questionnaire The first contact with Ferrari has been the pre-elicitation questionnaire in order to understand the overall context as well to assess the knowledge about Product-Service. According to the given answers, Ferrari consider the study of requirement one of the most critical activities in each discipline mainly if it is considered the holistic product-services. Effectively, at the end of the day the final product is only one divided in sub group while the related services could be various. Therefore, for Ferrari these aspects should be considered in the definition of the requirement for holistic product-service. Considering the actual scenario, Ferrari recognizes the importance of offering to their customer not only a car but also a service related in order to enhance the Ferrari experience. The Ferrari expectations from the Manutelligence platform are to achieve a large integration between the working groups in order to reduce the number of loops and to achieve the project objectives with less time in order to offer a product-service at low costs and high quality. The target is also to reduce largely the prototypes and design faults mainly on the customer side. Copyright Manutelligence Consortium Page 26 / 163

27 Moreover, another goal is to define and implement a virtual and physical design validation supported by the platform, considering from the early prototype to the final product the possibility to retrieve data from field Questionnaire and interviews The product and service development process in automotive is a complex environment, in which many actors collaborate and share their knowledge, using different methods and tools. In order to overcome these difficulties, the questionnaire and the interviews in Manutelligence has been designed with the purpose to investigate the industrial practice in product and service (P-S) development and data management. The final target of these activities is to make easier the understanding and the gathering of the business and engineering requirements. In the following sections the answer to the questionnaire and to the interview are reported according to the four main areas tackled. Part 1 - Design process at glance Ferrari designs and manufactures sports cars that are synonymous of speed and performance. Due to the fact that the Ferrari sports cars are among the most prestigious automobiles in the world, the market interaction is basically twofold: the cars are designed and build to customer performance specification (ETO) or build to customer specification from a stock of existing components (ATO). This implies that the design/development process varies from highly customised process (Company designs one-of-a-kind solutions, receiving detailed requests from the customer) to simply customised (Company designs dedicated solutions, selecting the most suitable combination of options according to the specific customers needs). Nevertheless, from the interviews is also clear that the marketing has an important role as well the R&D, therefore the design process can be sometimes also market pull (Company designs different product solutions, receiving requests and specifications from the internal Marketing department, which make analysis of the market trends and customer behaviours) or technology push (Company designs different product solutions, pushed by the R&D and technical departments, to be sold in the market). As a matter of fact Ferrari in the design process Ferrari considers as a paramount the customization and the product functionality and performance (aesthetic, speed, weight and security). Other important aspects considered are innovation, legal requirements and the RAMD (Reliability, Availability, Maintainability and Durability). On the other hand ROI, Manufacturability, TTM (Time to Market) and environmental Issues are less taken into account. As stated before the design process in automotive is a complex environment therefore many actors take part in this process, effectively in Ferrari all the roles are in the design loop from Marketing staff to Production engineering. In addition also external stakeholders are involved such as designer partner, supplier, and seldom customer. Considering the typical day of a designer/ engineer, according to the given answers, they Copyright Manutelligence Consortium Page 27 / 163

28 spent around half of their working time for retrieving data/information from traditional and digital resources, around 20% for coordination, collaboration and documentation and only 30% of their time is spent for added value activities. Part 2 - Managing knowledge in a design and development context The Ferrari designers and engineers, during the new product development, rely approximately on 50% on the knowledge coming from previous projects. The main sources of knowledge are related to the personal experience, to carry over project, or to written rules defined by external parties/manuals/standards and textbook. For supporting the development of a car, many tools are required, in Ferrari all the authoring tools are fully established as well as the virtual prototyping and CAE tools, also a PDM and an ERP are in place. In summary the main tools used and their integration are depicted in Figure 10. PROTYPES set-up ITINERIS FLUMAT VIRTUAL CAR VIRTUAL PERFORMANCE PHISICAL PERFORMANCE PROTYPES MODIFICATIONS ITINERIS? Product Structure PART PROD PHISICAL TEST PLAN PRE-SERIES set-up VPM/CAD AS 400 BAAN AFFI RELAYABILITY PLAN & DELIVERY PRE-SERIES MODIFICATIONS PMCC SCHEDULING TIME/fixed COST WEIGHT ASSESSMENT PRODUCT COST / CALCULATION Figure 10 - Tools used for supporting the product development process The Figure 10 shows that there is not so much integration between the used tools as a consequence the data handled are stored in different systems such as PDM, AS400, file systems and ERP. When there is the need to learn more about the products in the market, Ferrari searches the information in all the available sources such as third parties data bases, social networking services, special discussion forums, specialised weblogs, print-media product reviews, maintenance and repair reports and product embedded sensors. The main reference framework that are followed by Ferrari to manage product related data are: Copyright Manutelligence Consortium Page 28 / 163

29 STEP AP (203, 214, 224, 233); DF; IGES; Part 3 - Managing the development of product- service systems Nowadays, Ferrari considers pivotal enhancing the customer loyalty and enriching the product functionalities, for these reasons services such as product delivery, spare part delivery and commissioning are already offered to their customers. In addition, services related to the maintenance and to the end of life of the product are now being explored for a future development. However technological infrastructure and the human resources are seen as critical elements to be manage in the implementation of the PSS. Part 4 Evaluating the lifecycle of a PSS Regarding the lifecycle of the PSS, Ferrari is more interested to the aspects related to the lifecycle cost (LCC) rather that the environmental issues. Effectively the sustainability impacts are barely consider unless for legal constraints. As a consequence the life cycle assessment (LCA) is not even performed Process mapping at glance The Ferrari product development process is divided in the following phases (Figure 11). Figure 11 - Ferrari product lifecycle This process is quite complex and it takes months from the beginning to the end. According to the objectives of the Manutelligence project only a specific part will be considered as shown in Figure 12 Copyright Manutelligence Consortium Page 29 / 163

30 Figure 12 - Ferrari product development process considered in Manutelligence In detail in the concept phase many activities are performed in order to define the product characteristics and the target parameters to achieve. The main documents produced in this stage are the Product briefing, Product Specification, Product Grid and the product sheet. Based on the outcomes of the Concept phase, in the preparation phase the target parameters are detailed and structured, moreover the first geometrical studies are performed in order to verify the functional, dimensional and performance feasibility. Afterwards the product configuration variants and related rules star to be defined and virtual and physical prototype are developed with the purpose to validate specific solution. In parallel style studies are developed and the top-level technical bill of materials (BOM) is defined. The preparation phase ends when the Delibera Impostazione Modello is approved and the outcomes of this phase feed the development phase. The outputs of the preparation phase are the preliminary BOM, geometrical reference models, geometrical parameters, and first DMU simulation. Starting from these documents the Engineering department develop the end item design in detailed in order to finalize CAD Models and to release the product. The product variants and the related rules are completed as well as the technical BOM is finalized. In addition, the official approval process of the end items is performed in this phase as well as the official change process. Geometrical models are exported for running DMU/CAE analysis and in the meanwhile physical tests are executed using spare cars (Muletti, Mulotipi and prototypes). The development phase is over, once the Delibera Avanserie is approved. The following picture shows the mapping of the described process using the EPC diagram ( Copyright Manutelligence Consortium Page 30 / 163

31 Briefing( Product( Specifica2on( Concept( phase( Product( Grid( Requirements( Defini.on( Concept( Leader( Style( Development( Product(( Sheet( Analysts( Prepara.on( phase( Feasibility( studies( Cost( Analysis( Func2onal( BOM( Architecture(and( components(plan( (CAD(model)( Prototype( Development( DMU(1( CAS( Model( Feasibility( studies( Style( Designers( Analysts( Designers( Design(of( Mulo.pi(and( DMU(2( DMU(n( Delibera( impostazione( modello( approved( Development( Phase( Designers( Car(model( design( EBOM( CAD( Model( Aerodynamics( report( Stress( analysis( Crash( Analysis( Virtual( Prototype( Virtual(Test(and( CAE(Analysis( Virtual(Test( Valida.on( Analysts( Test(Rig( Staff( Test(Drive(( Staff( Physical( prototype( Physical(Test( and(prototype( realiza.on(( Physical(Test( Valida.on( MuleB( Mulo2pi( Prototypes( Analysts( Designers( Final(design( Delibera( avantserie( approved( Figure 13 Automotive Process Mapping Copyright Manutelligence Consortium Page 31 / 163

32 4.1.4 Pilot stories The marketing department of Ferrari wants to offer to their most important customers a service for enhancing and consolidate the Ferrari experience. In detail the idea of the head of marketing, Mr. John, is to produce few Ferrari GT equipped for racing and to sell, to the top customers, the exclusive right to use them in race sessions, on different circuit, for a limited period of time (2 years). The Ferrari experience is enhanced from the presence in place of dedicated mechanical and automotive engineers, all-inclusive journey and the chance to retrieve field performance data during the races. The product development process in Ferrari starts whit a concept briefing among the head of marketing Mr. John, the concept leader Mr. Claude, the president Mr. Ezio and the Team Leader mr. Jack. Around a table Mr. John presents his idea and they start to discuss about the product characteristics, and how the racing car should look like according to the requested performance. Obviously, in term of product development these requests from the marketing department are very different from the typical cars ordered by customers. Effectively, developing cars for being used in races and ensuring connected services it is not trivial and it requires a specific management of the product and service requirements. The output of this first phase is a Preliminary Target, which is a document (Word, Excel etc.) that includes a list of very high-level product and service requirements. Mr. Claude stating from this document starts to think how the high-level requirements could be translated in technical requirements, considering also the fact that some of the requirements are connected to the service offered and not only to the product itself. In this process Mr. Claude considers also the budget depicted by the cost analyst, the style studies and obviously the former and the current project initiatives. From the Word and Excel documents, attached in the Platform, Mr. Claude can manually or automatically parse the P-S requirements by key words and then import them in the database thanks to the module Requirements Central of the Manutelligence Platform. In detail, the requirements are captured and decomposed into structures aimed to drive downstream design requirements update. After the requirements are captured and stored in the database, the project teams lead by Mr. Claude can use a robust structure navigator and rich text editor to browse, view and modify the requirements without losing any of the original formatting. Each users can always view the updated list of requirements, allowing an advanced requirements traceability. The product team composed by analysts and designers starts to define in the Engineering BOM management of the Manutelligence Platform the top-level product architecture, with the target to implement a standard product structure as the framework to optimize the design process for new product concepts (archetype). In addition also the classification and the Copyright Manutelligence Consortium Page 32 / 163

33 codification of parts is defined. According to the required feature and to the upper level architecture the engineering bill of materials (ebom) is automatically generated and the team can assign to the system and subsystem the requirement specification. In this phase also the processes for designing, providing and managing services are mapped and data model for collecting service information are defined in the platform and linked to the top-lever architecture. The requirements management is also part of the system engineering approach thus the product team using the platform can also flow down and trace the Requirements to Functional, Logical down to Physical structure (RFLP) being able to adopt a system approach from Vehicle level to System level. Due to seamless integration among the BOM, related technical document and the authoring CAD the designers can perform the first studies (preliminary simulation) through multi-engineering model simulation and design taking the requirements as target parameter to achieve. In this phase, Mr. Claude starts also the technical configuration activities, due to the fact that the considered vehicles have to be more a racing that a leisure cars the useless components are are removed from the different configurations, using the CATIA V6 in variant management, in order to reduce the overall weight. In addition one of the main requirement is to gather data from field with the aim to provide to drivers, real-time feedback on their performances, for this reason Mr Claude includes in the variants also the IoT devices. In this phase Mr. Claude defines also the variant mapping strategies for tests, in detail he identifies a subset of system and subsystem configuration functional to perform tests and he assigns to them the specific target parameters. The preparation phase ends when the design structure of components is released to the person in charge of the development of the vehicle, Mr. Ron. Mr. Ron and his team, according to the test strategy, start to analyze the design structure of components and the preliminary BOMs including the specific BOM defined only for tests. The role of the Engineering team is to develop using Designer Central the end item details and the official drawing used for releasing the product. The changes process and the approval are properly managed within the system though formalized processes. In addition, when all the geometries are ready the team also analyzes the geometrical reference models and the target parameters. It is really important in term of experience that all the designed components address the target parameters defined, in fact the pleasure of riding and the thrill of drive are strongly related to the overall vehicle performances (i.e. max speed, steering angle, acceleration etc.). However only validating the design through a specific virtual and physical tests strategy can be possible to assess if all the requirements are addressed and as a consequence ensuring to the final customers the most challenging experience. Copyright Manutelligence Consortium Page 33 / 163

34 For these reasons the virtual tests and the CAE analyses are performed and controlled by Mr. Claude and Mr. Ron though the SIMULIA module of the Manutelligence platform in which it is possible, thanks to the digital continuity, directly retrieve the test strategy as well as the test BOM and finally to check if the target parameters are achieved. On the other hand Mr. Claude controls also the physical tests, using the platform he is able to define, build and maintain necessary prototype for the test execution. In detail, the prototypes are traced from the definition to its realization and its maintenance, in addition also the spare parts allocation, installation and disassembly is managed. Therefore the physical tests are performed on the workbench or using spare cars (Muletti e Muolotipi) and car prototypes. Finally, the physical tests are completed with the On Rig and On Road test in which the whole designed vehicle is verified. The performances of the prototype are monitored with an IoT devices installed on board which gather data from field. The data are collected into the Manutelligence platform thanks to the IoT central. The installed IoT devices are the same that will be used from the drivers for retrieving racing performance data. Moreover the IoT central can manage, thanks to the different data models implemented, also this kind of data, providing to the driver analysis, statistics and dashboard for assessing for example the average lap time, the max speed achieved and the covered paths on the circuit. Also the vehicle balance is stored and linked to the performances in order to have a list of possible configuration that could be chosen for the further racings. During this phase the virtual and physical test results are constantly compared, these analyses are performed using the 3Dlive product dashboard in order to verify if the product and service target parameters are achieved, if yes the system or subsystem are validated otherwise a change processes and corrective actions are needed. Using the dashboard it is also possible to control quality, time and cost KPIs. Once all the systems and subsystem are tested and validated Mr. Claude releases to the industrialization department and the cars are realised and equipped for racing. Before the cars are completed, the drivers are invited in Maranello and they can see the work in progress and through the commercial configurator of the platform, they can define some finishing features Unstructured list of requirements Taking into account all the outcomes from the different elicitation techniques used, a first list of unstructured requirements for the Ferrari pilot has been defined and described as user statements / desired issues. # Unstructured requirements 1 Creation and set up of the top-level product architecture considering the configurations and variants Copyright Manutelligence Consortium Page 34 / 163

35 2 The unit of the top-level architecture should be the classified object. Each object should have linked the needed and related documents. 3 Need of strong traceability of product requirements, target parameters and validation activities. In addition the services requirements should be taken into account form the very beginning of the project. 4 At the moment the logical structure in not formalised and is described manually. This should be formalised and automatic in order to allow the carry over form the concept phase. 5 Feedbacks from virtual and physical tests should be collected, stored and analysed. 6 The data held in Excel, Word and Power Point file should be embedded and managed in the platform. 7 The definition of the engineering bill of material (EBOM) and the connection to the other derived BOM for simulation and manufacturing should be managed. 8 The product requirements must be managed in a better way in term of structure and evolution along the project. A proper change process should be implemented for tracking modifications. 9 The alignment between the various BOM should be automatic, at the moment there are integration issues between the different systems. It would be great have the technical BOM based on the logical BOM. 10 Most of the test results are saved in separated files, spread on different folders and servers; then, aligning information between documents requires a huge manual effort. This must be automatic. 11 Formal product requirement management is needed, since it is not possible to track the changes and their impacts. 12 Nowadays, costs and weight are not managed in the legacy system, they are stand alone in Excel, and these aspects should be also considered and integrated in the platform. 13 A common platform is needed for centralise the activities. 14 The engine department is weak integrated with the rest of the enterprise; the Copyright Manutelligence Consortium Page 35 / 163

36 platform should reduce this gap. 15 Modification impacts on carry over parts should be reduced. 16 The management of product configurations must be improved. 17 The very early test results should be consolidated to feed and shorten the later complete car validation. 18 A global formal view (e.g. in the form of a dashboard) for physical and virtual test could be useful for improving the whole validation process. 19 Field data from prototype should be collected, structured, stored and analysed. 20 In prototyping the as build should be linked to the as planned. 21 It is important to know which spare part is mounted on a specific prototype. At the present there is no way to trace such parts. 22 The Test Plan and the general Project Plan are not integrated, and they should be. 23 Environmental issues should be assessed along the design process at the moment only legal aspects are considered. Table 3 List of unstructured list of requirements for the Automotive pilot Copyright Manutelligence Consortium Page 36 / 163

37 4.2 Intelligent student home Description The driver of the smart home pilot in Manutelligence is the project partner Lindbäcks. Lindbäcks produces, builds and sells prefabricated, wooden apartment houses which are up to 8 levels tall. Based on these products the smart homes pilot has defined services for the different partners involved in the home living process chain: Services for home configuration Services for production Services for living Services for recycling The new services start with the definition and planning of a new house together with the future owner or end user. Some further services support the production and assembly processes. Finally all data collected via the home definition and building processes can be used later on to offer additional services for the end user and the Figure 14 - Internet-of-Buildings Box (IoB) facility management. The central point for all home services are the information stored within the house. As a first approach a concept of an Internet-of-Buildings box (IoB Box) has been outlined. The Internet-of-Buildings bases on the Internet-of-Things and will alter the way to operate buildings, to manage budgets and to improve sustainability. Building automation and management is being reshaped by the combination of a diverse set of intelligent equipment, standard communication protocols and a demand for future proof infrastructure. This offers the opportunity to change the way of operating buildings in the future. Beside the box inside the building a platform is necessary to control and analyse all the data. The Manutelligence information platform operated at the manufacturer should support all the services defined but also the production processes. The platform will be a combination of software modules (existing as well as new ones) and their interaction. A first requirement list has been developed and described within this document. Only some selected services will be realised during the Manutelligence project. Copyright Manutelligence Consortium Page 37 / 163

38 4.2.2 Questionnaire and interview report Questionnaire The content of the questionnaire was discussed by phone as a first step. Based on that discussion and a visit at the production site of LINDBÄCKS the questionnaire was completed and submitted as a draft version to LINDBÄCKS. It was discussed internally, adapted and a final version has been submitted for this deliverable. The construction process for smart homes is very much based on the knowledge of previous projects. There are only some few systems supporting the product definition and design process by now. Most of the knowledge is in the heads of the employees. This might be changed by testing new ways of product definition and also new defined services within the Manutelligence project. The answered questionnaire is focussing on the smart home pilot but not restricted to it. It is for sure that some of the answers will be changed based on the further discussions and experience within the project and the partly realisation of the pilot Interview According to the answers given in the pre-elicitation questionnaire it is possible to understand that Lindbäcks wants to: 1. Use the platform for supporting the customization of the prefabricates and enabling pay-per-use (using avatar-room); 2. Develop control services and managing accesses; In order to further investigate the Lindbäcks scenarios the following questions have been handed out: 1. Which is your business model? The general business model is to extend the selling of houses and flats with additional services. Lindbäcks has two kinds of customers. There is the buyer (owner) and the end-user (resident) of a house 1. It could be the same person. Therefore, the services will have two focuses: 1) The maintenance can be optimized by additional measurement information. Maintenance can be planned in advanced and can be organized just in time. Water leakages (e.g. in bathrooms) can be detected more quickly. This is a service which can 1 House is synonymous to fleet, appartment, etc. Copyright Manutelligence Consortium Page 38 / 163

39 be offered to the owner of the house to provide home worth for a long time. Business model: The house owner will pay a monthly fee and therefore he will get an immediate repair and maintenance service. [Extended warranty period can be discussed based on the online monitoring of the house]. 2) End users of houses are changing over time. All end-users have different requirements. Therefore pay-per-use services can be integrated into a house. Business model: The user books only services he needs at a special time (e.g. different services depending on the season, weather or other parameters. It can be a pay-by-month solution. Beside the additional services all data (also additional measurements) will also be used to improve the design and production of new houses. Additional services will be defined based on the collected end user data (which features of the house are frequently used and which ones are used very little?). The measurement of user data can perhaps improve the life time of the apartment (humidity, temperature per room, etc.). 2. Which services would you like to sell whit the pay-per-use? The definition of new services has not been completed, but some pay-per-use services could be: Additional floor heating e.g. in the bath room Improved heating accounting (in the moment end apartments pay more for heating than apartments in the middle of a block) Roller blinds only in summer or only for some rooms Remote home control opportunities (heating, close windows remotely, alarm messages, etc.) Rent paintings for a period of time for the walls Select furniture (chairs, beds, sofas)/tiles/wallpapers for a period of time For common laundry rooms the pay per amount of detergent can be realised. Cleaning service can be ordered and played per use. For small apartments storage space can be offered by pay-per-use and the delivery from the storage space to the apartment can be ordered as a service Items (not used every day) can be leased per use (e.g. noodle machines, clothes,, etc.) delivered from the storage room. These are some examples for pay-per-use services. Business models will be defined during the project to evaluate these services. 3. What you mean for the avatar-room? How do you foresee the implementation? Copyright Manutelligence Consortium Page 39 / 163

40 A platform for the data collection, exchange, evaluation and operation is needed. This will be a topic of Manutelligence discussions/specifications. In the moment only a supplier of Lindbäcks is able to read remotely heat meters etc. and to evaluate the data. 4. Is the customization of the room dynamic or static? In other words there are completely customizable room (dynamic) or a set of predefined room configuration that could be chosen (static)? In the moment the customization of the rooms are static. There are a set of completely customizable rooms which can be selected or adapted (shift or leave out walls). Future discussions are also focusing on selected dynamic rooms, but there are several technical problems to solve. n/a 5. If dynamic, which are the boundaries? What could be configured? Process mapping at glance The process mapping includes all steps from the definition and design until the end of life of intelligent student homes. In the future we are not going to restrict the intelligent homes to students. Therefore we call it much more general smart homes. The homes considered in Manutelligence are based on houses with a high degree of workshop prefabrication. The 3-D modules are shipped to the final construction site for the final assembly and commissioning. The following IDEF0 diagrams ( illustrate the processes. Copyright Manutelligence Consortium Page 40 / 163

41 Figure 15: Lifecycle model for smart home living Figure 16: Design processes Some of the necessary functionalities for the different processes are mentioned within the process descriptions. It has to be checked which functionalities are already working in a proper way and which needed to be developed or adapted during the project. Some of the functionalities will become part of the Manutelligence platform especially those that can be applied to different pilots and different industries. Copyright Manutelligence Consortium Page 41 / 163

42 Figure 17: Building the volume modules (workshop pre-fabrication) Figure 18: Building the house at construction site Copyright Manutelligence Consortium Page 42 / 163

43 Figure 19: Using the house by the customer The recycling of the smart home has not been specified in detail. In general the requirements are considered within the design process but Manutelligence will not focus on special solutions for recycling so far, as the lifetime of Lindbäcks houses is up to several decades. 4.3 Pilot Stories Astrid & Nils live in a small apartment close to Stockholm. They saved some money and the financing conditions for their still existing financing gap are quite good. They started to analyse the house building market and found the well-structured and informative Internet site of LINDBÄCKS. There are some user-friendly applications to support the configuration of their new home considering their available budget and the estimated life-cycle costs. Service Line 1: Configuration and order support On that LINDBÄCKS Internet site Astrid & Nils found an apartment configuration tool (including virtual 3D presentation, modules and furniture of previous projects and furniture, etc.). It allows potential customers to define very easily a virtual apartment along their ideas by using pre-defined design elements. Electronic catalogues from different suppliers are available to choose and combine the facility installations (bathroom fixtures, kitchen furniture, banisters, electrical installation items etc.). Copyright Manutelligence Consortium Page 43 / 163

44 Figure 20 - Apartment configuration tool After the first very rough design Astrid & Nils started the price calculation module on the website. By changing design elements (additional walls, additional electrical outlets, enlarged bath room, etc.) the price will be adapted automatically. Some additional home features can be rented from LINDBÄCKS on a pay-per-use basis. This reduces the initial investment for the customer. Some examples for pay-per-use features are: Additional floor heating e.g. in the bath room Improved heating accounting (in the moment end apartments pay more for heating than apartments in the middle of a block) Roller blinds only in summer or only for some rooms Remote home control opportunities (heating, close windows remotely, alarm messages, etc.) For small apartments storage space can be offered by pay-per-use and the delivery from the stage space to the apartment can be ordered as a service After reaching the rough price expectations and for special requests they can arrange a meeting with the LINDBÄCKS sales department via the calendar doodle module on the web site. Together with the LINDBÄCKS sales persons Astrid & Nils finalises the apartment design including all individual wishes. Purchase price, life cycle costs and the environmental footprint (life cycle assessment) of the new apartment will be calculated. For all new defined items the costs and environmental figures cannot be calculated at this stage but will be shownin a separate list as additional costs not considered in the actual calculation. All data generated by the apartment configuration tool will be stored on the internal Manutelligence information platform at LINDBÄCKS. The next step is the price calculation considering all circumstances like: Detailed design of additional components to fulfil the individual wishes of the customer Logistical requirements to set up the building on site Considering requirements of the production line caused by customer individual wishes Copyright Manutelligence Consortium Page 44 / 163

45 The customer will be informed about the adapted and precise price calculations. The additional components will be uploaded to the component data base (modules of the apartment) and can be used by the apartment configuration tool for future customers. An official offer will be send to the customers Astrid & Nils. After clarification of the detailed customer questions the order will be signed. Figure 21 - Service for smart home configuration Service Line 2: Follow up production and on- site assembly After the order has been received the detailed design and the production planning starts. Predefined room modules will be used (as part of the standards) for the production planning combined with the planning for the new modules not available as standard. Based on the part lists of the apartment configuration tool the lists will be separated and send to the selected suppliers. The production progress can be followed by Astrid & Nils via the production completion module (example: planning completion start production pre-production completion concrete platform completion set-up at site final delivery) on the web site. Photos of the growing building will be shown on a weekly basis to integrate the customer into the building process. Build a house becomes an adventure for Astrid & Nils by attending the construction progress via the production completion module on the website. While following the progress Astrid & Nils become additional advertisements for additional house components and features, which they can order subsequently. The promotion is not restricted to the house itself but includes also room amenities (like sofas, tables, etc.). The promotion module on the website offers new marketing opportunities during the house building process. Internally, all failures and problems will be stored in the Manutelligence information platform and analysed to improve the product. Product and process information will be stored on the Manutelligence information platform but also inside the building. An Internet-of-Buildings Box (IoB box) will be installed in every home and offers all information necessary for maintenance and repair. The same box takes care on all pay-per-use services. Copyright Manutelligence Consortium Page 45 / 163

46 Service Line 3: Service for smart home living After Astrid & Nils have moved into their new home they can connect their phone, tablet or computer to the Internet-of-buildings box (IoB Box) and can order additional services (all pay-per-use services), monitor their consumption data (water, gas, electrical power, etc.) or control facilities remotely (open/close windows, remote temperature control, activate alarm systems). Simultaneous life cycle costing calculation can offer optimization proposals to the end user. The external facility management will receive the consumption data for accounting and some condition data (temperature, humidity, flooding, etc.) to plan service and repair activities. The data will also be used by the LINDBÄCKS design department to improve the construction over the time. To optimise the services the data can also be used to analyse the resident s habits. Service technicians can access the Internet-of-buildings box (IoB Box) to use the stored measurements for failure analysis. Additionally, all design drawings and bills of material are stored in the box to support repair and refitting activities. Service Line 4: Service for recycling The services for recycling are not in the focus of the Manutelligence project. Nevertheless all Figure 22 - Service for smart home living stored data can be used to optimise the recycling process and to plan the reuse of some house parts. 4.4 Unstructured list of requirements Phase Designing List of requirements Product configurator with house variants 3-D Viewer for virtual walks through the house Rough cost calculation based on configurator data & previous projects Copyright Manutelligence Consortium Page 46 / 163