Thesis Vincent Verheggen | Colophon

About the title of this thesis: ‘Seeing is believing’ Seeing is believing is an idiom that was first recorded in 1639 by John Clarke in a collection of proverbs for schoolchildren (Oxford University press, 2016). It means ‘only visual evidence is convincing’. The essence of this idiom goes back to St. Thomas`s claim to Christ whereupon the later responded that there were those who had not seen but believed. Seen evidence however can be easily and correctly interpreted (Rohrer, 2000).

About the illustration on the front page: The illustration on the front page is based on an illustration made by Sergey Nivens © and is purchased from https://stock.adobe.com (#47136756)

Thesis Vincent Verheggen | Colophon Colophon

Seeing is Believing

Capturing functional product requirements with Augmented Reality within Dutch mega transport projects

Name: V.T.J. (Vincent) Verheggen Student number: 4032810 Email: [email protected]

University: Delft University of Technology Faculty: Faculty of Civil Engineering & Geosciences MSc Program: Construction Management & Engineering

Location: Delft Date: Oktober 2016

Graduation Committee Chairman Prof.dr.ir. M.J.C.M. Hertogh TU Delft, Civil Engineering

First Supervisor Dr.ir. G.A. van Nederveen TU Delft, Civil Engineering & Geosciences

Second Supervisor Dr. S.G. Lukosch TU Delft, Technology, Policy and Management

Company Supervisor Ir. K.J. Oijevaar PDEng ASEP HOCHTIEF Infrastructure Benelux

Company Supervisor Ir. D. Postma HOCHTIEF Infrastructure Benelux

Visitor address Visitor address Stevinweg 1 Eekholt 42 2628 CN Delft 1112 XH Diemen

iii

Thesis Vincent Verheggen | Colophon

Thesis Vincent Verheggen | Preface Preface

This thesis is the result of my graduation research, which I carried out to complete the master in ‘Construction Management and Engineering’ (CME) at Delft University of Technology.

Prior and during the master program I increasingly acquainted myself with new technologies and construction philosophies. During two internships, I discovered and began to appreciate the advantage of visual communication. It appeared to be a simple and explicit way to gain trust within project organisations. The convincing power of visual, combined with the philosophy Systems Engineering, laid the basis for this research.

I would like to thank the people that supported me during my thesis. My graduation committee from Delft University: Prof. dr. ir. M.J.C.M. Hertogh, Dr. ir. G.A. van Nederveen and Dr. S.G. Lukosch.

My external supervisors Ir. K.J. Oijevaar PD Eng ASEP and Ir. D. Postma from Hochtief Infrastructure are also to be commended: They supported me during my thesis research with their knowledge and their broad network.

Kenzo gave enthusiastic and professional feedback on the meeting on Friday. He persevered in dealing–and wheeling–with me. I want to thank Don for the formal and especially informal conversations and fun in and outside the office. Also, I learned much from his straightforward and strategic feedback.

I am also grateful to persons that had an unmissable background role: Sandra, CME’s secretary, and Arjan Keppel, the site superintendent of Hochtief Infrastructure.

Lastly, I would like to thank my family and friends for their unconditional confidence. Especially I want to thank Maaike, Anne, Philine, Jan-Peter, Thijs, Fokke and last but not least, my dearly loved, and inpatient, parents.

I hope that the thesis will inspire you and convince you of the importance of visualisation. Enjoy reading!

September 2016,

Vincent Verheggen

Thesis Vincent Verheggen | Preface

Thesis Vincent Verheggen | Summary Summary

Introduction The construction industry is often criticised for failing to deliver a technical solution that meets the client’s intentions. Communication between the contractor and client is difficult as the client has limited technical knowledge. It is necessary to clarify and understand the client’s expectations to ensure that the intended technical solution will be met.

One technique that can enhance communication of the technical solution during the development phase is Augmented Reality (AR): a visual aid that overlays the real world with corresponding digital information. Although AR is not new, recent technological advancements in hardware and software make this technique easily applicable.

Problem exploration Over the last decade, there has been a shift in the roles of the client and the contractor. The client, who previously was highly involved in the entire construction process, has taken a step back and now concentrates on the function the technical solution has to fulfil by means of functional requirements. Compared to technical requirements, functional requirements create a larger playground for the client and contractor.

Various technical solutions can fulfil the client’s functional requirements, but contractors often fail to deliver the technical solution to meet the client’s intent. The reason for this failure is that communication between client and contractor is problematic. The aids used by the contractor to communicate technical solutions cannot be used during development to provide full insight in the technical solution.

The research questions This research aims to answer the following research question:

How can contractors use Augmented Reality for verification of the technical solution, with respect to functional product requirements, in the development phase of mega transport projects in the Netherlands?

Two sub-questions are compiled. The two sub-questions are:

Sub-Question 1: How are technical solutions verified with respect to functional product requirements during the development phase?

Sub-question 2: How can Augmented Reality be applied to verify technical solutions during development?

vii

Thesis Vincent Verheggen | Summary

Literature study To answer both sub-questions, literature studies in the field of requirement management and AR were performed. These studies elaborate on the output specification, the requirements in the output specification, the specification process, the verification process and Augmented Reality. The literature studies lead to the following findings:

- Functional requirements are requirements that describe a function. These requirements are often ambiguous and unclear. - Technical requirements are derived from functional requirements during a specification process. - Verification of the technical solution with respect to the functional requirements is indirectly done by verification with respect to technical requirements. - Verification with respect to technical requirements can be done with four basic verification methods. These are, among others, Demonstration, Analyses, Inspection and Test. - Six AR applications can be distinguished. These are:

1. AR for position review This application allows the user to verify the position of one or multiple objects in order to choose the right alternative. 2. AR for interface review With interface review, the user can do a full scale design visualisation in order to analyse the properties of the virtual 3D model in the real environment. 3. AR for design review With AR for design review, the user can analyse the virtual 3D model on top of a marker, usually a construction plan. 4. AR for task support This application supports the user of AR during execution of onsite activities. This application can help to execute activities correctly or safely. 5. AR for site review AR for site review is used during onsite activities. Examples are verification of the planning or the realised objects. 6. AR for training After the technical solution is developed, this application of AR can train the user for operation and maintenance tasks.

- In the development phase, there are two AR applications that can be used for verification: ‘AR for design review’, and ‘AR for interface review’. These two applications can be used for verification because their main aim is to show the technical solution in the development phase.

Methods During the case study, several project documents of the SAAone project were analysed. The case study elaborates on the requirements, the verification process and the verification itself. Both research sub-questions were answered by analysing the output specification, the Verification and Validation manual and the requirement management system of the case study project.

viii

Thesis Vincent Verheggen | Summary

To validate and complement the answers from the literature study and case study, six experts were interviewed. The interviews consisted of two parts: the verification process (1) and verification with augmented reality (2). To validate that AR can be used for verification purposes, four AR prototypes were developed. After analysing the prototypes, the interviewees provided their opinion on the use of AR for verification.

Results The case study brought to light that the specification process is interwoven in the verification process of functional requirements. When the development phase begins, the functional requirements the client provides are translated into detailed verifications. The detailed verifications can be compared with derived technical requirements mentioned in literature. From the detailed verifications, the technical solution is derived. This process is visualised in Figure 1.

Verification of the technical solution is carried out with respect to criteria mentioned in the detailed verifications. An important role during verification is played by the Knowledge and Experience (K&E) of the people involved in the development and the execution of the verification. In Figure 1 the two K&E moments are indicated.

F = Functional requirement T = Technical requirement DV = Detailed verification K&E = Knowledge and Experience

Figure 1: Multiple translations are necessary to retrieve the technical solution from the functional requirements. It is expected that these transitions can be bypassed with AR.

Document inspection is often used as a verification method to verify the technical solution with respect to the detailed verification or technical requirements. With this method, a document such as a construction plan, is analysed whereafter it is used as evidence. Documents that are used for these purposes are called supporting documents.

The contractor analyses and communicates the technical solution during the development phase with the supporting documents. The technical solution is difficult

Thesis Vincent Verheggen | Summary

to understand for people who are unfamiliar with supporting documents. In addition, the information in the supporting documents is often not aligned with the judgement given by the verifier as this person’s knowledge and experience is used for verification.

The application ‘AR for design review’ can help overcome these problems as it can improve client’s understanding of supporting documents and facilitate the communication of functions. The verifier and the client can easily analyse the technical objects and judge whether these objects fulfil the specified functions. This application of AR can avoid mistakes resulting from the interpretation of the person who develops the verification and the person who executes the verification (the verifier).

Interviews are conducted in order to validate and complement the findings from the literature study and case study. The interviews provided a better view on several aspects that will be discussed below.

Part 1: Verification

Overall, the interviewees mentioned that the verification process places too much emphasis on technical requirements and that the verification of these detailed requirements is time consuming. Less attention is paid to verification with respect to functional requirements even though such verification is valuable as these requirements emerge early in the development phase and represent the true voice of the client. Therefore, verification should focus more on functional requirements.

Part 2: Verification with AR

Interviewees mention the following advantages of AR:

- Realistic character As AR places a virtual 3D model in the environment, the user gets a more realistic experience. The objects that represent the construction are placed in the environment are more real compared to the objects in visual models shown on computer screens. - Dynamic character The user experiences are dynamic; it is possible to freely analyse the virtual content from various angles. No experience with difficult software is required. - Interactive character The virtual content that is shown with AR interacts with the environment. Aspects in the environment can therefore be judged by the AR’s user.

According to the interviewees these advantages result in better communication, better expectations and increased trust between the client and the contractor. In addition, these advantages allow communication of functions. AR can be useful when it comes to verification of perceptual aspects such as functions.

Compared to verification with the computer, verification with AR supports the three advantages mentioned above to a higher degree. AR provides a more realistic, more dynamic and more interactive experience compared to computer visualisation.

Despite its many advantages, AR has some limitations. In addition to technical implementation issues, that will be solved over time, the use of AR can be challenging for three reasons:

Thesis Vincent Verheggen | Summary

1. The resistance to change. Implementation of innovation depends on how that innovation suits the values of the user. 2. It is possible for users to misunderstand the accurateness of the information in the virtual content. This problem also applies to computer verification. 3. The dynamic nature of AR may make it less suitable for repeatable and objective judgement. This requires an application that captures the conditions when the verification is carried out. Conclusion AR can help the client to understand the functions of the technical solution during the development phase. During this phase, the client can provide better feedback on these functions. Based on this feedback, the contractor can adjust the technical solution. With this feedback, it will be easier for the contractor to deliver a technical solution that meets the client’s intention.

AR can be used to verify requirements that contain subjective aspects, such as functional requirements. In addition, using AR for design review, with construction plans as supporting documents, can lift communication of technical solutions to a whole new level.

Despite AR’s advantages, verification with conventional supporting documents will still be necessary to verify the technical solution with respect to technical requirements provided by the client. Requirements concerning technical aspects such as ‘height’ and ‘width’ are difficult to prove with AR due to the detailed information.

In using AR, the contractor should ensure that the client understands what purpose the virtual 3D model within AR serves. The contractor should also be aware that a judgement must always be traceable and repeatable. To that end, the contractor should develop and use possibilities within AR that allow traceable and repeatable decision making.

Thesis Vincent Verheggen | Summary

xii

Thesis Vincent Verheggen | Table of Contents Table of Contents

Introduction ...... xviii 1.1 Context ...... 1 1.2 Problem exploration ...... 2 1.3 Research conducted on Verification and Augmented Reality ...... 4 1.4 Research object ...... 5 1.5 Objective ...... 8 1.6 Research Question...... 8 1.7 Relevance ...... 9 1.8 Methodology...... 9 1.9 Outline ...... 13

Literature Study ...... 15 2.1 Overview of the Chapter ...... 15 2.2 The Output Specification ...... 16 2.3 Requirements ...... 17 2.4 The Specification Process ...... 20 2.5 Verification ...... 25 2.6 Augmented Reality ...... 33 2.7 Sub-conclusion ...... 42

Case Study ...... 47 3.1 Overview of the Chapter ...... 47 3.2 Case Study Project...... 48 3.3 Requirements ...... 49 3.4 Verification Processes ...... 53 3.5 Practical Data from the Requirement Management System ...... 54 3.6 Sub-Conclusion ...... 61

Interviews ...... 65 4.1 Overview of the Chapter ...... 65 4.2 Selection of the Interviewees ...... 66 4.3 Interviewees ...... 66 4.4 Using Table Top Modelling ...... 67 4.5 Interview Procedure ...... 68 4.6 Measures ...... 72 4.7 Results ...... 73 4.8 Discussion of the Results ...... 78 4.9 Sub-Conclusion ...... 85

xiii

Thesis Vincent Verheggen | List of Abbreviations

Conclusions & Discussion ...... 89 5.1 Overview of the Chapter ...... 89 5.2 Conclusions...... 90 5.3 Discussion ...... 96

Recommendations ...... 99 6.1 Contractor and client ...... 99 6.2 Further research ...... 101

Reference list ...... 103

Appendix A: Orientation ...... 107 Appendix B: Supporting documents ...... 109 Appendix C: Interviews ...... 114 Appendix D: Interview protocol ...... 119 Appendix E: Summery transcriptions interviews ...... 123

List of Abbreviations

AR Augmented Reality CAD Computer Aided Design DBFM Design, Build, Finance, Maintain (contract) MTP Mega Transport Projects SE Systems Engineering SBS System Breakdown Structure SMART Specific, Measurable, Assignable, Realistic, Time-related RE Requirement Engineering RAMS Reliability, Availability, Maintenance, Safety RBS Requirement Breakdown Structure RWS Rijkswaterstaat TTM Table Top Modelling (subset within AR) V&V Verification and Validation

xiv

Thesis Vincent Verheggen | Glossary of terms Glossary of terms

Client The person or organisation responsible for commissioning and paying for the design and construction of a construction project (Kamara, Anumba, & Evbuomwan, 2002). In this thesis, Rijkswaterstaat is considered as client. (Dutch: ‘de klant’ or ‘Opdrachtgever (OG)’)

Contactor or The party responsible for carrying out the construction Contracting party project. In this thesis. Hochtief Benelux is considered as contractor. (Dutch: ‘aannemer’ or ‘Opdrachtnemer (ON)’)

Stakeholders The various parties involved during the construction process. Stakeholders in the context of this thesis are often municipalities, provinces or governmental organisations that influence decision making.

Supporting documents Document that have two purposes. They are used for analysing the technical solution and they serve as evidence that a requirement is met. Construction plans are often used as supporting documents.

Technical solution The technical product that is developed after the specification process. The following synonyms exist in the context of this thesis: (final) system, technical outcome, final solution, (final) design, construction.

Verifier The person responsible for carrying out the verification. In this thesis, this person is considered to be an employee of the contractor.

List of Figures

Figure 1: Multiple translations to retrieve the technical solution ...... ix Figure 2: Using augmented Reality for verification of the technical solution...... 1 Figure 3: From functional requirements to technical solution ...... 3 Figure 4: Verification of the technical solution ...... 3 Figure 5: Verification during the development and during the production phase ...... 7 Figure 6: Empirical research strategies (based on Hertogh and Westerveld (2010)) .....10 Figure 7: Research approach ...... 12 Figure 8: The different output specifications in the contract ...... 16 Figure 9: From functional requirement towards technical ...... 20 Figure 10: Three steps in the specification process ...... 20 Figure 11: The three steps of the Design Process ...... 21 Figure 12: The specification and design process...... 22 Figure 13: More requirements and less design freedom (Imbrechts, 2016) ...... 23 Figure 14: Division of requirements...... 23

Thesis Vincent Verheggen | List of Figures

Figure 15: The output specification in the specification and design process ...... 24 Figure 16: Left: The saw-toothed requirement tree. Right: The functional and technical requirements provided by the client ...... 25 Figure 17: Verification and validation (basic representation) ...... 26 Figure 18: The verification process (based on INCOSE (2011) ...... 27 Figure 19: Vee model including verification and validation ...... 28 Figure 20: Verification and validation positioned in the specification process ...... 29 Figure 21: Analysing position of furniture with Augmented Reality (Quay, 2013) ...... 33 Figure 22: Milgram’s Reality-Virtuality Continuum (positioned on the right is VR) ...... 33 Figure 23: Left: The virtual 3D model positioned on top of a marker (Chin, 2013), Right: Adjusting properties by covering markers (Magnani, 2010) ...... 34 Figure 24: The Microsoft HoloLens (Leswing, 2015) ...... 35 Figure 25: AR for positioning object or equipment (Behzadan & Kamat, 2005) ...... 36 Figure 26: AR for interface review during development (Cote, 2012; Mihai, 2014) ...... 37 Figure 27: AR for design review during development (Azuma et al., 2001)...... 37 Figure 28: AR for guidance during production (Bell, 2014) ...... 38 Figure 29: Left: AR for planning review during production (Elgohari, 2015). Right: AR for positioning review during production (Léon van Berlo & TNO, 2011)...... 38 Figure 30: AR for training (AR for Enterprise Alliance (AREA), 2015)...... 39 Figure 31: An example of information visualisation: two trend graphics (Rohrer, 2000) .39 Figure 32: Technical requirements cover only a part of the functional requirement ...... 42 Figure 33: Verification with respect to functional requirements ...... 43 Figure 34: Project SAAone (indicated in green) and 4 other SAA projects ...... 48 Figure 35: Identification numbers in the output specification ...... 50 Figure 36: requirement tree with functional and derived technical requirements ...... 52 Figure 37: Verification strategy project SAAone ...... 53 Figure 38: Interface of the requirement management system used at project SAAone ..54 Figure 39: Verification with respect to technical requirements, an example ...... 55 Figure 40: Development of the verification, an example ...... 56 Figure 41: Carrying out the verification, an example ...... 57 Figure 42. The translation of the functional requirement to object properties...... 57 Figure 43: Supporting documents used during document inspection...... 59 Figure 44: Specification of the functional requirement in project SAAone ...... 62 Figure 45: Left: Scan of the construction plan. Right: Analysing the virtual 3D model with AR-TTM (Kroll, 2016) ...... 68 Figure 46: Supporting document used in Part 2 of the interview (number 1, 2 and 3) ....70 Figure 47: AR-TTM markers used in Part 2 of the interview ...... 71 Figure 48: AR-TTM prototypes used in Part 2 of the interview...... 71 Figure 49: Photo taken by interviewee D in part 2 of the interview ...... 75 Figure 50: Verification and validation of technical and functional requirements ...... 78 Figure 51: Not meeting the expectation is the result of missing context...... 79 Figure 52: design freedom within the total amount of possible technical solutions ...... 80 Figure 53: Reduction of technical requirements and effort involved in the verification process as result of early verification...... 81 Figure 54: The AR experience...... 82 Figure 55: Impression of AR-TTM. Illustration based on (The Architecture, 2011) ...... 83 Figure 56: Functional and technical requirements of the client (letters F&T)...... 90 Figure 57: Verification of the technical solution with respect to the verification ...... 91

xvi

Thesis Vincent Verheggen | List of Tables

Figure 58: Influence of Knowledge and Experience (K&E) ...... 91 Figure 59: The position of AR in the construction process ...... 94 Figure 60: Using VR and AR (MS Hololens) (image: P. Glaudemans) ...... 108 Figure 61: Verzorgingsplaatsen DO ontwerp Hackelaar...... 109 Figure 62: Bewijsdocument leuningwerk K068 dek west ...... 110 Figure 63: Overzicht lichtmasten en HWA ...... 111 Figure 64: Integraal Inrichtingsplan - Deelgebied Hollandse Waterlinie...... 112 Figure 65: Kabellooptekening Verkeers Systemen ...... 113 Figure 66: Selection of the example requirements ...... 114 Figure 67: selection of functional requirements just above the transition from functional to technical ...... 115 Figure 68: Drawing the 3D model in the software sketch up ...... 116 Figure 69: Scale and amplify the supporting document for traceability ...... 117 Figure 70: A part of the supporting document that serves as marker for AR-TTM ...... 117 Figure 71: Scan the marker and analyse the 3D model on top of the marker ...... 118 Figure 72: AR prototypes that belong to requirements FN_00599, VG_00089, FN_00420, FN_02018 ...... 122

List of Tables

Table 1: Verification methods described by RWS ...... 32 Table 2: Findings of Chapter 2 with respect to the first sub-question ...... 45 Table 3: Findings of Chapter 2 with respect to the second sub-question ...... 45 Table 4: Requirement tree project SAAone, an example ...... 51 Table 5: The distribution between verification methods at project SAAone...... 58 Table 6: Findings of Chapter 3 with respect to the first sub-question ...... 63 Table 7: Findings of Chapter 3 with respect to the second sub-question ...... 63 Table 8: Background information of the interviewees...... 66 Table 9: Estimated knowledge of the interviewees with respect to verification and AR ..66 Table 10: Requirements used in Part 2 of the interview ...... 70 Table 11: Validation of the findings from Chapter 2 and 3 in order to answer SQ1 ...... 85 Table 12: Validation of the findings from Chapter 2 and 3 in order to answer SQ2 ...... 87 Table 13: Names of the interviewees of the orientation interviews ...... 107 Table 14: Four requirements and derived requirements that are part of the AR-TTM- prototypes...... 121

xvii

Thesis Vincent Verheggen | List of Tables

xviii

Thesis Vincent Verheggen | Introduction

Introduction

1.1 Context

The construction industry is often criticised for failing to deliver a technical solution that meets the client’s intentions (Egan, 1998; Kamara et al., 2002; Latham, 1994). Communication between the contractor and client is difficult as the client has limited technical knowledge.

A client communicates their intentions by providing design constraints by means of requirements to the contractor. With these requirements, the client describes the facility that they desire. The client is likely to express their needs in non-design terms. The contractor has to ‘translate’ these requirements and take these requirements into account during the development of construction projects. During and after the development of construction projects the contractor must ensure that the product that will be made, further referred to as the technical solution, is in accordance with the client’s requirements. To that end, the contractor uses a so called verification processes (Rijkswaterstaat, 2009b).

During verification processes, the contractor uses documents such as construction plans to verify the technical solution with respect to client requirements (Rijkswaterstaat, 2009b). Despite the availability of high-quality graphics systems, verification still relies on documents with physical 2D and 3D models of buildings and products. The contractor uses these supporting documents to communicate the obtained technical solution to the client and prove that requirements are met. The documents are typically static in structure and surface characteristics. In addition, they are inherently lifeless (Raskar, Welch, & Chen, 1999). It is expected that high-quality graphics systems, such as Augmented Reality (AR), can be used to communicate the technical solution better than the conventional documents.

AR is a unique and promising visual aid that overlays the real world with corresponding digital information (Zünd et al., 2015). This technique can possibly enhance communication of the technical solution during the verification processes. Although AR is not new, recent technological advancements in hardware and software have led to AR being used more widely (Azuma et al., 2001; Van Krevelen & Poelman, 2010).

Figure 2: Using augmented Reality for verification of the technical solution.

Thesis Vincent Verheggen | Introduction

Tomi Ahonen, deemed by Forbes as one of the most influential experts in mobile industry in 2012, argues that over one billion users will make use of AR by 2020 and that this technique will be the 8th mass medium used by then (Ahohen, 2012). An example of AR is given in Figure 2.

Although AR developers have proposed alternate advance solutions, the superiority of AR for design, and thereby verification purposes, is not yet proven (Navab, 2004). This thesis explores the opportunities and obstacles of AR in construction projects for verification of technical solution developed by the contractor. The thesis provides various applications of AR that can be used in the construction industry. This research uses ‘Table Top Modelling’ (TTM), an application of AR that can be used for verification, as a case to visualize computer models.

1.2 Problem exploration

In the past, the client had a prominent role during the development of construction projects. The client was responsible for the plan development, conditioning, engineering, design, and maintenance (Rijkswaterstaat, 2007). The contractor’s role was solely to build exactly what the client described.

Recently, a shift has taken place related to the roles of the client and the contractor. Where, traditionally, the client’s emphasis was on the entire development of construction projects, this emphasis has shifted towards plan development and conditioning (Rijkswaterstaat, 2009a). The engineering, design, construction and sometimes maintenance are now the contractor’s responsibility. With this shift, the client’s organisation becomes more flexible and relies on the strength and knowledge of the market during the development of construction projects. Contractors should distinguish themselves from others with innovative technical solutions (PIANOo, 2016).

In order to communicate information obtained in an early stage of the development phase, the client uses integrated contracts. These contracts describe how the contractor is involved during the Design, Build, Finance and Maintenance (DBFM). In a DBFM contract, the client mainly communicates which function the technical solution has to fulfil. The client uses functional requirements to communicate the function, which is encouraged by the 19th preamble of the guidelines on public procurement in the EU (PIANOo, 2015).

Compared to technical requirements, such functional requirements create a large playground for the client and contractor (Rijkswaterstaat, 2011). The contractor is free to come up with creative and innovative technical solutions within the design boundaries shaped by the functional requirements (PIANOo, 2016; Rijkswaterstaat, 2011). The contractor has to translate the functional requirements into technical solutions. The technical solution is the product that will be made by the contractor. This could be, for example, a design product or the final facility.

Thesis Vincent Verheggen | Introduction

For example:

Figure 3: From functional requirements to technical solution

To come to a technical solution, the contractor first derives technical requirements from the functional requirements (Rijkswaterstaat, 2013). Technical requirements describe the technical solution in more detail than functional requirements. Figure 3 shows the pathway from functional requirement to a technical solution. In this figure a practical example is provided. The function ‘safety’ can be interpreted on various different ways. The function is translated in the technical solution ‘speed signs’.

The function ‘safe’, provided in a functional requirement, is a function that can be interpreted in multiple ways. The contractor can choose several technical requirements and corresponding technical solutions such as ‘speed signs’ or ‘speed bumps’.

During a verification process, the contractor verifies a technical solution with respect to the derived technical requirements and the functional requirements (see Figure 4) (Rijkswaterstaat, 2009a). During the development phase, this can be done multiple times, allowing the contractor to steer the technical solution when requirements are not met.

Figure 4: Verification of the technical solution

The subjective characteristics of functional requirements makes it difficult to verify the technical solution with respect to these requirements as the function can be fulfilled by multiple technical solutions (see red arrow in Figure 4). The green arrow in Figure 4 indicates that it is easier to verify the technical solution with respect to technical requirements.

The reason that the subjective functional requirements are more difficult to verify compared to technical requirements, can be found, among others, in the aids used for communication (Kamara et al., 2002). Supporting documents play a role in the communication of the technical solution between contractor and client during the verification process. Not all aspects required by the client can be proven with visual tracing of diagrams and construction plans on supporting documents.

Thesis Vincent Verheggen | Introduction

Construction plans serve to communicate the technical solution with respect to technical requirements (green arrow Figure 4) but provide limited insight in the functional requirements. Construction plans make it relatively easy to prove that ‘speed signs’ were placed along the road. Construction plans are ill suited to prove that a technical solution is ‘safe’. For people with no or limited experienced in working with construction plans, it is even harder to verify the technical solution.

The contractor fails regularly to deliver a technical solution that can meet the intentions of the client (Egan, 1998; Kamara et al., 2002; Latham, 1994). The client does repeated calls for the construction industry to deliver better value-for-money. According to Kamara et al. (2002) “The client’s calls are in response to the criticism of the industry by client, who complain that they do not always get what they ask for”.

When a contractor fails to communicate and align a required function during the development phase, a client may not accept the preferred solution. This can result in negative financial and political effects for both client and contractor.

Recent examples of projects that were not accepted are the ‘Sallant-Twente’ tunnel, the ‘Roertunnels’ and the ‘Leidsche Rijntunnel’.

- The Sallant-Twentetunnel (N35): The project failed to deliver due to ‘communication’ issues. This resulted in a project delay of 1 year (Belzen, 2014). - The Roertunneltunnel (A73): The technical solution did not suffice for the function ‘safety’. This resulted in a project delay of 1 year. - The Leidsche Rijntunnel (A2): The tunnel could not fulfil the function ‘communication’. This resulted in a project delay of 1.5 years’ (Kuiken, 2012; Postumes, 2012).

Such consequences can be prevented through better communication and by providing insights in the technical solution during the development of construction projects. “It is necessary to clarify the objectives and exceptions of the client to ensure that they are understood from the perspectives of the client” (Kamara et al., 2002).

In this thesis, the use of Augmented Reality (AR) is analysed during verification processes with respect to functional requirements. It is expected that AR can provide better insight in the technical solution compared to conventional supporting documents, such as 2D construction plans, during the development of mega transport projects.

1.3 Research conducted on Verification and Augmented Reality

The verification processes are described by a number of companies, governmental institutions and universities. The Department of Defence of the United States of America and the NASA are only some of the institutes that elaborate on how verification can be done (Defense Acquisition Guidebook, 1999; Leonard, 1999; NASA, 2007). The handbook of the International Council on Systems Engineering (INCOSE) and the Systems analysis, Design and Development book of Wasson (2006) are prominent examples that academically describe verification.

Thesis Vincent Verheggen | Introduction

The role of visualisation for verification processes is hardly described. Multiple authors such as Sargent (1991), Rohrer (2000) Bouchlaghem, Shang, Whyte, and Ganah (2005) and Behzadan and Kamat (2005) describe the added value of 3D simulations and animations within visualisations for validation of the design. Although this thesis does not focus on validation, these authors provide some indirect information about the verification process.

Although Augmented Reality (AR) was developed in the ‘60s, industrial applications of AR developed by the military and aerospace industry remain unused until the ‘90s (Van Krevelen & Poelman, 2010). These days, most of the academic research is funded by governments and the entertainment industry. Publications regarding AR focus on topics that interest these groups. Consequently, there is a lack of publications on the industrial application of AR and in particular the industrial application in the construction industry (Navab, 2004).

The limited number of publications that do elaborate on AR in the construction industry focus on applications during production, inspection and renovation. The use of AR during development focuses on validation (not verification) during the development. Dong, Behzadan, Chen, and Kamat (2013) and Navab (2004) both describe the added value of AR for design validation, education and training. AR as aid for verification is hardly described in literature.

1.4 Research object

In order to create a clear understanding and a demarcation (scope) of the research described in this thesis, this section provides brief definitions of the core objects.

In this thesis, the use of Augmented Reality (§1.4.1) is analysed for verification (§1.4.2) of the technical solution. Verification is done with respect to product requirements (§1.4.3) during the development phase (§1.4.4) of mega transport projects (§1.4.5).

1.4.1 Augmented Reality

Azuma Azuma et al. (2001) and Dong et al. (2013) define Augmented Reality (AR) as a technique that enhances, or augments, the users view of the real world (environment) with virtual information.

This technique allows a user to view the combination of virtual information and the environment in the same space as the environment (Lawson & Pretlove, 1998; Piekarski & Thomas, 2002; Van Krevelen & Poelman, 2010). The user of this technique can immerse and interact with both virtual information and the environment in a natural way (Behzadan & Kamat, 2005; Bobrich & Otto, 2002).

1.4.2 Verification

Verification is a process that ensures that the system, its elements, and its interfaces conform the requirements (INCOSE). In other words: “that you build the system correctly” (Defense Acquisition Guidebook, 1999; INCOSE, 2011; ISO 15288, 2008).

Thesis Vincent Verheggen | Introduction

The handbook of INCOSE (2011) states that: “The purpose of the Verification Process is to confirm that the specified design requirements are fulfilled by the system. This process provides the information required to effect the remedial actions that correct non‐conformances in the realized system or the processes that act on it”. This definition is also used in the standard: ISO 15288 (2008).

Methods and predefined criteria are used during the verification process to guarantee that all parties involved know when a technical solution complies or does not comply with the requirements. When several people follow the same verification steps, the judgement must be the same: the technical solution complies or does not comply with the requirements.

The term ‘verification’ can often be found in combination with the term ‘validation’. The differences between both terms is difficult for many and the terms are used interchangeably (Rijkswaterstaat, 2009b). However, while the Verification and Validation (V&V) can be seen as separate processes, they can overlap considerably (NASA, 2007). This thesis will distinguish both terms and focus on the verification process. The meaning of the term validation will be given here in order to provide a full picture.

Validation ensures that the system fulfils the function required by the stakeholders. In other words: “that you build the right thing” (INCOSE, 2011). As such, it tests the performance of the technical solution within its intended operational environment, with anticipated operators and users (Defense Acquisition Guidebook, 1999). Validation guarantees that the system is the right solution for the problem that is given by the client.

The handbook of INCOSE (2011) describes the purpose of the validation as “to provide objective evidence that the services provided by a system when in use comply with stakeholders’ requirements, achieving its intended use in its intended operational environment.” This definition is also used in the standard: (ISO 15288, 2008)

An important side note to the definition given above is that validation is used to establish a level of confidence that the right thing will be build. Although the term ‘confidence’ is not taken into account in the INCOSE handbook, this term is described in combination with the term validation by other authors such as the Department of Defence and Wasson.

1.4.3 Product Requirements

There is a distinction between product and process requirements. Both categories of requirements are mentioned at their own place in the output specification (the contractual document between the client and the contractor).

This thesis focusses on product related requirements that are initiated by the client in order to create the practical technical solution. Often, product requirements are considered as more important than process requirements as financial and/or economic benefits are linked to product requirements.

Thesis Vincent Verheggen | Introduction

1.4.4 The Development Phase

According to the ISO 15288 (2008, p. 1) the full life cycle of systems include: Conception, Development, Production, Utilization and Support and Retirement of systems.

The emphasis of the verification process is during the development and the production phase. In these two phases are verified, respectively, the design and the finished construction.

The design on the construction plan that communicates the technical solution is verified multiple times during the development phase with respect to the requirements provided by the client. During verification processes in the production phase, the finished construction is judged with respect to the design (Amice (Vereniging voor oud KMA KLU officieren), 2014). It can be assumed that when the design was verified before, and the finished construction corresponds with the design, the finished construction will be according to the requirements (See Figure 5).

Figure 5: Verification during the development and during the production phase

The research in this thesis focuses on verification during the development phase. Verification during this phase is considered to be more important compared to verification during the production phase as:

- Changes in design can be made easily and are less costly (Stuurgroep 4P Systems Engineering, 2009). - Verification during the production phase is based on construction documents which are verified during the development phase. The same verification moments as shown in Figure 5 can be found in the Vee-model. This model is explained in §2.4.2.

1.4.5 Mega Transport Projects

The study focuses on Mega Transport Projects or ‘MTPs’. MTPs’ are seen as special projects within the total of construction projects. MTPs are defined by Dimitriou, Ward, and Wright (2013) in an international research on decision making. The definition used by these authors elaborates on the interwoven character of MTPs in society.

Thesis Vincent Verheggen | Introduction

According to Dimitriou et al. (2013), MTPs is “land-based transport infrastructure investments within and connecting major urban areas and metropolitan regions in the form of bridges, tunnels, road and rail links, or combinations of these. They are projects that entail a construction cost of over US$1 billion (at 1990 prices), completed since 1990 and are frequently perceived as critical to the ‘success’ of major urban, metropolitan, regional and/or national development”.

This thesis takes MTPs as its base because of their complex, uncertain, and risky character. Transport infrastructure projects are becoming larger in size and more and more complex. MTPs have a large influence on countries’ economies and their development. It is expected that AR can provide valuable insights in the technical solution so that the technical solution meets the client’s expectations.

1.5 Objective

The objective of this thesis is to provide knowledge of and insights in the use of Augmented Reality for verification of a technical solution with respect to functional product requirements during the development phase of mega transport projects for contractors.

With knowledge and insights on how Augmented Reality can be used for verification of the technical solution, it will be possible for contracting organisations to prevent misinterpretation of the functional requirements and avoid rejection of the technical solution. The objectives and expectations of the client can be communicated early in the development phase to ensure that they are understood from the perspectives of the client.

1.6 Research Question

The following research question was selected and formulated in such a way that the answer will yield information necessary for accomplishing the research objective stated in §1.5.

The research question (RQ) is:

RQ: How can contractors use Augmented Reality for verification of the technical solution, with respect to functional product requirements, in the development phase of mega transport projects in the Netherlands?

Sub-questions (SQ):

The first research sub-question aims to focus on the requirement management part of the research question: the verification process. It is necessary to know how verification is done in mega transport projects. Research sub-question 1 is:

SQ 1: How are technical solutions verified with respect to functional product requirements during the development phase?

Thesis Vincent Verheggen | Introduction

The second research sub-question focuses on the visual aspect of the research question: augmented reality. To know how contractors could make use of this technique, it is necessary to derive various applications of AR and pick the applications that can help to improve communication during the verification process. Research sub- question 2 is:

SQ 2: How can Augmented Reality be applied to verify technical solutions during development?

The efforts will result in a list of possible applications or forms of Augmented Reality that can be used for verification during the development phase.

An answer on both sub-questions (SQ1 and SQ2) will be given in the conclusion of each chapter. In Chapter 2 both sub-questions will be answered based on existing literature and in Chapter 3 with respect to a case study.

1.7 Relevance

Currently, the verification process in Dutch mega transport projects puts emphasis on technical requirements (Brekelmans, 2016) as technical requirements are easy to verify compared to functional requirements as they mention the technical solution (see §2.3.3).

Verification of the technical solution with respect to the functional requirements is more useful compared to verification with respect to technical requirements (Brekelmans, 2016). The reason why is that functional requirements arise early in the development process, are the basis for derived technical requirements and therefore better represent the ‘voice of the client’.

By making it possible to verify functional requirements, this will prevent parties such as contractors from operating strictly in their own interest. It will also decrease the likelihood that the overall function is missed (Stuurgroep 4P Systems Engineering, 2009).

This research focuses on functional requirements because these requirements are difficult to verify as they can be interpreted in multiple ways. By verifying technical solution with respect to functional requirements this moves emphasis from the technical requirements towards verification with functional requirements.

1.8 Methodology

A research methodology explains the principles and procedures of logical thought processes that are used for scientific research (Fellow, 2008). A research methodology serves two purposes (Leeuw, 1990):

1. To judge the quality of the research (§1.8.1) 2. To choose an appropriate research strategy (§1.8.2)

Thesis Vincent Verheggen | Introduction

1.8.1 Research Quality

According to Verschuren and Doorewaard (2010), the most significant decision when constructing a technical research approach is which approach must be taken. The research approach must elaborate on the gathering of relevant material and how these are processed into valid answers to the research question.

In order to determine the research approach, a set of core-decisions is taken. According to Fellow (2008) and Verschuren and Doorewaard (2010), a fundamental issue in designing research is to underpin the selection of quantitative, qualitative or combination of approaches. Other core-decisions include the selection of a breadth versus an in-depth approach and empirical vs desk research (Hertogh & Westerveld, 2010).

Figure 6 illustrates the five research strategies mentioned by Verschuren and Doorewaard in relation to the three core-decisions: bread vs depth, qualitative vs quantitative and empirical vs desk research. The core decision, quantitative vs qualitative is closely linked to the decisions to choose for empirical or desk research (Verschuren & Doorewaard, 2010).

Figure 6: Empirical research strategies (based on Hertogh and Westerveld (2010))

Answering this thesis’ research question requires an in-depth and qualitative approach, since its context involves complex processes. Additionally, this approach is necessary as many people are involved with each their own interest and opinions.

Figure 6 shows that the most fitting research approach is a ‘Field research’. According to Verschuren en Doorewaard (2010), qualitative research methods are frequently used here. Field research can contain of a case study approach, grounded theory and interviews. According to Fellows & Lui, a combination of approaches can be powerful to gain insights and results (Fellows & Liu, 2015; Flyvbjerg, 2006) and enrich the data

Thesis Vincent Verheggen | Introduction collection and analysis thereby improving the validity of the study (Hertogh & Westerveld, 2010). Using several research approaches will provide a fuller understanding of the research problem. In this thesis, the research question is answered with the help of a literature study, a case study and interviews.

Literature study A literature study was done first to understand the problem. A literature study, or desk research, cannot be found in Figure 6, because it is a non-empirical strategy and is often applied along with one of the empirical strategies (Hertogh & Westerveld, 2010).

Case study A case study was done to provide answers on the research sub-questions. According to South-Easy European Research Centre (SEERC) (2010), “A case study is an empirical inquiry that investigates a contemporary phenomenon within its real life context especially when the boundaries between phenomenon and context cannot be drawn clearly or unambiguously”.

A case study was chosen as it has a descriptive and exploratory form and aims to establish the operational link between one set of conditions (causes) and their effect. How and why questions are often used during a case study (South-Easy European Research Centre (SEERC), 2010).

The choice is made to execute a single case study. South-Easy European Research Centre (SEERC) (2010) mentions various rationales why one could choose for a single case study. A single case study can be chosen when the case or research is critical, unique, representative, revelatory or longitudinal. From the reasons mentioned, a single case is chosen for two reasons:

1. The revelatory character of the research. The use of AR for verification in the development phase of Dutch infrastructure projects is new and never done before which makes this research revelatory. Developing an AR application that would fit multiple construction projects would be too time consuming. 2. The representative use of requirements in construction projects. During the case study, several documents are analysed including the output specification. This document has the same scope and design in every mega transport project. Therefore, the project is representative and a single case study is applied. Interviews Interviews were conducted with various experts from in and outside the case study project to validate and complement the answers of the case study and the literature study. It is expected that interviewees provide an in-depth view on the complex verification process. They can enrich the findings from the literature study and case study with practical observations.

The following section will extensively describe the strategies in the order that they will be discussed in this thesis.

Thesis Vincent Verheggen | Introduction

1.8.2 Research Strategy

Figure 7 gives the order in which the research approaches described above were executed. Prior to the literature study, the problem was analysed during an orientation phase.

Figure 7: Research approach

After orientation and the literature study, a case study was done and interviews were conducted with six experts. Based on the framework presented in Figure 7, a more extensive explanation of the research approach is given below.

1.8.2.1 Orientation Ten personal meetings and five field-related events were used to become familiar with the subject. The events focused on topics such as verification and Augmented Reality. The events were organised by various interest groups such as INCOSE, KPTV, STUMICO and Rijkswaterstaat.

During the interviews and event visits, the problem described in §1.2 was defined. The names of the various interviewees and a small abstract of the visited events can be found in Appendix A: Orientation.

1.8.2.2 Literature study Chapter 2 contains a literature study, performed in order to provide a theoretical background on the subjects mentioned in SQ1 and SQ2. It will also provide answers on both sub-questions.

The following topics were investigated during the literature study:

- Output specification - Requirements - Specification process - Verification - Augmented Reality

1.8.2.3 Case study During the case study, project documents of the case study project were analysed, as described below. The aim of the case study is to answer SQ1 and SQ2 with respect to an existing mega transport project. Chapter 3 of this thesis elaborates on the case.

Thesis Vincent Verheggen | Introduction

The following documents or information sets were analysed during the case study:

- Output specification SAAone From the output specification, the requirements used in the project can be analysed. This information is described in §3.3. - Verification and validation manual SAAone From the project manual for verification and validation, the intended Verification and Validation (V&V) strategy became clear. The strategy is described in §3.4. - Requirement management system SAAone From this database, practical information was retrieved. The verifications that belong to requirements and the used verification methods were retrieved from this source. Information from this source can be found in §3.5.

These three documents were analysed because they contribute to the verification processes. The documents listed above give a good indication of the intended verification process, which information is provided by the client, and the execution of the verification process.

1.8.2.4 Interviews Experts were interviewed to validate and complement the answers given on the research sub-questions in the literature study (Chapter 2) and case study (Chapter 3). The interview consists of two parts. Part 1 elaborates on the verification processes while Part 2 considers the added value of AR during these processes.

In order to validate and complement the answers during the interviews, the interviewees were asked to review four AR prototypes and corresponding functional requirements. More information about the interview can be found in Chapter 4.

1.9 Outline

- Chapter 2 provides theoretical background information in the form of a literature study. This chapter will provide early answers to the research sub-questions mentioned in §1.6 with respect to literature. - Chapter 3 aims to answer the two research sub-question with respect to a case study project. First the case, project SAAone, will be described. Thereafter findings from the analysed project documents are given. - Chapter 4 elaborates on the interviews. Interviews are used to validate the findings of Chapter 2 and Chapter 3. In order to validate the answers, the interviewees review the use of four AR prototypes of Augmented Reality. - Chapter 5 provides a conclusion and discussion of the literature study, case study and interviews. - Chapter 6 gives recommendations on how Augmented Reality can be implemented in contracting organisations for verification of requirements. In addition, this chapter recommends areas for further research.

Thesis Vincent Verheggen | Introduction

Thesis Vincent Verheggen | Literature Study Literature Study

2.1 Overview of the Chapter

This chapter provides background information and early answers on the two sub- questions:

SQ 1: How are technical solutions verified with respect to functional product requirements during the development phase?

SQ 2: How can Augmented Reality be applied to verify technical solutions during development?

These questions will be answered based on international literature and more practical, field related literature. Most of the field related literature is made by Rijkswaterstaat (RWS), an important provider of infrastructure projects in the Netherlands.

This chapter will cover the following subjects:

- The output specification (§2.2) - Requirements (§2.3) - The specification process (§2.4) - The verification process (§2.5) - Augmented Reality (§2.6)

Thesis Vincent Verheggen | Literature Study

2.2 The Output Specification

An output specification is a document used by the client to communicate their demands to the contractor. The word ‘Specification’ merely refers to the act of "stating explicitly or in detail" or "being specific". The requirements in this document must be satisfied by a material, design, product, or service (Part, 1986).

The output specification is made by the client before a project is outsourced to a contractor and it elaborates on ‘what must be made’ and ‘how it must be made’. The output specification defines the solution space for the contractor (Rijkswaterstaat, 2009a).

One might think that an output specification is one single document, but in reality multiple output specifications can be distinguished. Requirements that are initiated by the client can be found in two output specifications (Rijkswaterstaat, 2014).

In one part, only requirements related to objects are mentioned. The requirements in this part are also called: product requirements. Requirements concerning management related topics are covered in the other part. These requirements are also called ‘process requirements’.

Important stakeholders, such as provinces and municipalities, provide requirements in an output specification via the client to the contractor. This output specification is often referred to as ‘implementation agreement’ (Dutch: Uitvoeringsovereenkomst (UVO)). The implementation agreement becomes part of the contract between the client and the contractor (Berg, 2016).

Figure 8 shows the three different output specifications and their initiators.

Figure 8: The different output specifications in the contract

The situation sketched in Figure 8 is similar for all mega transport projects in the Netherlands as the client, often Rijkswaterstaat, tries to communicate in a consistent way.

Thesis Vincent Verheggen | Literature Study

2.3 Requirements

The output specification consists of several hundreds of requirements. A requirement is a single documented, physical or functional, need that a particular design, product or process must be able to perform (Mahdavi, Martens, & Scherer, 2014).

Requirements can be classified into various categories in order to capture their intended use and objectives (Wasson, 2006). In addition, the requirements can be divided in functional and technical requirements.

This section will start with explaining the term ‘voice of the client’ whereafter the characteristics of good requirements are discussed. The concept of technical and functional requirements is explained thereafter. Although the problem definition already discussed the differences and characteristics between both requirements (§1.2), this section will explain the differences in more detail.

2.3.1 Capturing the Voice of the Client

According to Kamara (2002), the ‘voice of the client’, similar to the ‘voice of the customer’, is used to describe the “active and systematic process of establishing and incorporating the ‘true’ wishes of customers in the development of products”. It is necessary for the contractor to capture the voice of the client in order to deliver construction projects as intended. The client requirements include the wishes, expectations and perspectives of the client. The requirements describe the facility that is necessary to satisfy the client’s objectives or needs.

More focus on incorporating the ‘voice of the client’ is the result of repeated calls for the construction process to be more client-oriented (Egan, 1998; Kamara et al., 2002; Latham, 1994). Usually a product is developed with the intention to comply with the environmental needs and aesthetics constraints. The needs of the client are considered to be less important (Latham, 1994).

The increasing sophistication of clients and the recognition of their important role in the construction process made it necessary for contractors to deliver better value for money by renewing the focus on client requirements (Egan, 1998). It is necessary to understand the question behind the question. The contractor is responsible for developing innovative ways to capture the ‘voice of the client’ as ultimate responsibility –and blame– for a technical solution that does not meet the client’s needs is his (Saaty & Beltran, 1980).

2.3.2 Characteristics of good Requirements

Requirements should be written with care. When developing requirements, the following characteristics should be taken into account (INCOSE, 2011)(p78). A requirement must be:

- Necessary - Implementation independent - Clear and concise - Complete

Thesis Vincent Verheggen | Literature Study

- Consistent - Achievable - Traceable - Verifiable According to INCOSE (2011, p. 80) it is recommended to use forms of the verbs: ‘to be’ such as: shall, will and must. The use of subjective language, vague pronouns, ambiguous adverbs and adjectives, open ended non-verifiable terms, comparative phrases and loopholes should be avoided in order to prevent confusion.

2.3.3 Functional and Technical Requirements

The characteristics a project must meet can be achieved by a specification with a technical nature or a specification with a functional nature. In an output specification with a functional nature, functional requirements can be found. In an output specification a technical nature, technical requirements can be found.

2.3.3.1 Technical output specification with technical requirements A technical output specification consists of many technical requirements. The technical specifications give a precise description of the work, service or product that is required. The size, performance and features that the solution must meet are given in detailed requirements (also called ‘technical’ requirements).

For example: ‘The driving lanes on the highway A2 must have a width of at least 4.50 m’.

This way of specifying requirements is most commonly used. The disadvantage of a technical specification is a detailed breakdown of the elements provided by the client. This detailed breakdown makes that a lot of time is spent and costs are made by the contractor to fully understand and follow up the idea of the client. However, the advantage of a technical specification is that it is relatively easy for a client to assess tenders. Technical specifications are best suited for contracts awarded to the lowest price (PIANOo, 2015).

With a technical specification, the client takes the supervisory role and determines the level of detail of the construction process. The contractor has to come with the cheapest offer and has to provide a solution for the client’s problem in the way the client requires. This is a structured and organised process (PIANOo, 2016).

This traditional approach does not force the contractors to think along with the client and therefore, limits the freedom or creativity of the contractor. The contractor does not take responsibility for the entire project as he is only responsible for the design.

A prerequisite for success is that the client has knowledge of the entire project and is involved in the design and management of the environment. Traditional specifications only work when the client has and wants to keep full control. Additionally, the client has to know how to deal with risks, how to control and monitor the contractor. In practice this can only be done when the client has a design department and the desired knowledge (PIANOo, 2016).

Thesis Vincent Verheggen | Literature Study

2.3.3.2 Functional output specification with functional requirements According to Rijkswaterstaat (2011) “A functional specification is a document containing the aggregate of organised requirements and a description of the available solution space or the chosen solution with the solution margin that applies to a system [..]”. In other words, a functional specification consists of requirements that describe the function a system has to fulfil. Besides the function, the functional specification also provides the constraints and thereby defines the solution space.

When the client uses a functional output specification, the requirements in the specification are not yet specified in products, but in required outcomes. An example of a functional requirement is provided below:

For example: ‘The Highway A2 must be safe for road users to get from place A to place B’.

The client describes ‘what’ the system should do instead of how this should be met (Rijkswaterstaat, 2011). The focus is on the function of the object, the process and the area where the solution can be found. It is important that the client has no detailed expectations.

A functional output specification creates more freedom and stimulates creative innovative solutions for both client and contractor (PIANOo, 2015). In the example given above, the contractor has several options to meet the criterion ‘safety’.

Functional specifications stimulate the contractor to make use of his knowledge and experience. In addition, functional specifications reduce the likelihood of a monopoly, in which only one contractor can execute the project. Also, functional speculations reduce the risk of neglecting alternatives as functional specifications provide freedom (Rijkswaterstaat, 2011).

That the knowledge, experience and diversity of the market is used, implicitly suggests that less knowledge, experience and diversity of the client is needed. The specification process will be less intense for the client since making a functional specification is easy when compared to a technical specification.

But it is harder for the client to assess the different tenders. It is time consuming to fully understand and compare the different tenders. An objective assessment framework is necessary to guarantee an objective winner (PIANOo, 2016).

Note: A requirement cannot be fully functional or fully technical. A requirement is always somewhere in between functional and technical. Nevertheless, this thesis will simplify the situation and overlook the in-between characteristics. This thesis will further refer to functional and technical requirements.

Thesis Vincent Verheggen | Literature Study

2.4 The Specification Process

The specification process is an iterative process in the construction industry that is used in order to obtain the required technical solution.

The users’ needs, partly provided by functional requirements, are translated during the specification process into basic functional and quantifiable set of performance requirements that can be translated into design requirements (INCOSE, 2011, p. 83).

These requirements are technical which makes realisation easier. Figure 9 depicts functional and technical requirements as two extremes. The specification process translates the functional requirements into quantifiable performance requirements during the specification process. These requirements get a technical character.

Figure 9: From functional requirement towards technical

2.4.1 Various steps within the specification process

The specification process consists of three sub-processes which are independent from the level of detail (Leonard, 1999; Rijkswaterstaat, 2009a).

- The requirement analysis (problem parsing and naming the solution space); - Structuring and allocating information (creating the outline); - The design phase (recording choices and working out the solution).

Figure 10 illustrates the three sub-processes of the specification process in chronological order. Each sub-process will be described in more detail on the next page.

Figure 10: Three steps in the specification process

Thesis Vincent Verheggen | Literature Study

Requirements analysis According to (INCOSE, 2011, p. 72) the purpose of the requirement analysis is: “to transform the stakeholder, requirement‐driven view on desired services, into a technical view of a required product that could deliver those services.”

This analysis is done at the beginning of a project. It has as purpose to translate the requirements and wishes of the client into specific requirements. This is necessary as the information provided by the client is incomplete or not detailed enough to find the best solution (Rijkswaterstaat, 2009a).

In this process, it is important to understand “the question behind the question” and to discover what are the critical, important, conflicting and contradictory requirements. Examples of methods for finding these requirements are process analyses, functional analysis and life cycle analysis (Rijkswaterstaat, 2013).

Structuring and allocation of information As the clients’ needs become clear, it becomes more and more difficult for the designer to oversee the entire system. Often disciplines or parties contribute to only a part of the total system. Nevertheless, decomposition of the system is required to coordinate all of the participating parties. With decomposition, the system is divided into sub-systems and sub-sub-systems, which together form one overall system. This process can take place according to different aspects such as functionality, construction or geography. Structures for describing this are for example the System Breakdown Structure (SBS). The SBS is a structure which arranges all objects into a hierarchy (Rijkswaterstaat, 2009a).

The purpose of decomposition is to translate requirements into objects (function fulfillers) and to specify all information per object. Within this phase, functions of the system are named and objects are derived. An object can fulfil more than one function and a function can be fulfilled by multiple objects. The structure and cohesion between the objects is provided in this step. The result is a specification per object which serves as a basis for the design.

Design In the design phase, the object, as defined previously, will be further developed. In this phase, the functional objects are converted into tangible objects.

The design phase, can be divided in three steps, indicated in Figure 11 (Rijkswaterstaat, 2007, 2009a).

Figure 11: The three steps of the Design Process

The purpose of generating and reducing alternatives is to evaluate the different solutions for the system. Generating alternatives can be done via a brainstorm session. Selection of the optimal solution depends on the requirements and other criteria such as costs, planning and risks (Rijkswaterstaat, 2009a, p. 25). The effect of the

Thesis Vincent Verheggen | Literature Study alternatives can be evaluated with the help of a scoring matrix or trade-off matrix. During further development of the chosen alternative, the solution is specified and sized. This results in a final specification of the solution that consist of drawings, system specifications, arguments or considerations (Rijkswaterstaat, 2009a).

2.4.2 Multiple levels

It is impossible to derive the technical solution for a complex problem at once. Therefore, the solution is obtained by specification in multiple steps (Rijkswaterstaat, 2009a, p. 10).

The specification process as described in Figure 10 will be repeated until the technical solution represented by the design has the desired level of detail. When more detail is required, the output of the previous specification will be the input for a new specification. During the specification process, choices are made from coarse to fine, which makes this a top-down process.

When the desired level of detail is reached, production can start. The production of the technical solution is bottom-up. During production the sub-systems will be combined until a coherent system is developed. The descending line of the specification and the ascending line of the realisation together form the Vee model, illustrated in Figure 12.

Figure 12: The specification and design process.

This model was first developed by Rook (1986). In the Vee model, the project maturity proceeds from left to right. The core, the bottom of the Vee, depicts the point where the design is detailed enough to start construction (INCOSE, 2011). The red line indicates the involvement of the various parties. The specification process starts at the client and continues at the contractor. The production is entirely done by the contractor in the Vee model sketched above.

Thesis Vincent Verheggen | Literature Study

2.4.3 Development of new requirements

During the specification process, choices are made on how the function mentioned in the functional requirements must be fulfilled. These choices generate new information and conditions in the form of derived technical requirements. The solution space, the possible design freedom, decreases as result of the increase of derived technical requirements (Figure 13).

Figure 13: More requirements and less design freedom (Imbrechts, 2016)

Every time the solution becomes more detailed, new information will surface. New requirements are conceived from the new information. The triangle below (Figure 14), depicts the derived sub-requirements from the functional requirements. The figure also shows that derived requirements have a more operational character compared to the high positioned requirements which have a more strategic character.

Figure 14: Division of requirements.

The consideration to go into more detail is based on the estimate of the realisation, design, maintenance, in terms of time, money, quality and most important risks (Rijkswaterstaat, 2009a).

Although lower positioned requirements are derived from the higher positioned requirements, it is important to keep in mind that the total of the lower positioned requirements is not equal to the total of the higher positioned requirements (Rijkswaterstaat, 2013).

Thesis Vincent Verheggen | Literature Study

2.4.4 Deriving functional requirements during the requirement analysis

During the requirement analysis, the first of the three specification steps described above, functional requirements are translated into basic functions and quantifiable performance requirements. These obtained requirements are ‘technical’ and easy to use during development of the design.

According to INCOSE (2011) “These requirements need to be formally documented in a manner that defines the functions and interfaces and characterizes system performance […]”. Support from other disciplines (e.g. manufacturing, quality, verification, etc.) is required to ensure a complete set of derived requirements. Establishing such a set is a time consuming task. It must be done early since functional requirements form the basis for all design, manufacturing, verification, operation, maintenance and disposal efforts. These requirements have a major influence on the cost and schedule of the project (INCOSE, 2011).

2.4.5 The transition between client and contractor

It is often thought that the specification process is solely done by the contractor. This is only partly true. The client makes decisions before he provided the output specification to the contractor. The decisions made by the client can be seen as part of the specification process.

The output of the client’s specification process is the input for the contractor’s specification process. The output of the client is captured in the output specification (see Figure 15).

Figure 15: The output specification in the specification and design process The client is free to determine the level of detail of the requirements in the output specification. If the client opts for an integrated organizational structure where the design is the responsibility of the contractor (for example a D&B, DBFM, DBM contract), the client will outsource the work on a higher abstraction level. When the client provides fewer restrictions, the ‘cut’ is located higher in the specification process and the contractor has more design freedom.

In practice, the client takes the design freedom and his own risks into consideration when determining the level of detail of the specification (PIANOo, 2015). The client

Thesis Vincent Verheggen | Literature Study

provides some requirements in more detail than others. The saw-toothed requirement tree at the left side of Figure 16 depicts this.

Figure 16: Left: The saw-toothed requirement tree. Right: The functional and technical requirements provided by the client

The client can opt to communicate the functional requirements in addition to the derived technical requirement in the output specification (see right side Figure 16). By doing this, the client forces the contractor to provide the obtained technical solution and forces the contractor to provide the intended function. According to the specification process of the client the technical solution should contribute to the intended function. It is the responsibility of the contractor to ensure this.

2.5 Verification

A definition and brief explanation of the terms verification and the related term validation is given in §1.4.2.

Verification is much more than a process. “Verification encompasses the tasks, actions, and activities performed to evaluate the progress and effectiveness of the evolving system solutions (people, products, and process) and to measure compliance with requirements. The primary purpose of verification is to determine that system specifications, designs, processes, and products are compliant with requirements.” (INCOSE, 2011).

Note: Often written in literature is ‘verification of the requirements’. This is wrong as one often aims to judge the technical solution instead of the requirements (Figure 17). ‘Verification of the requirements’ is a pleonasm as verification is always affiliated with requirements. Therefore, it is better to say ‘verification of the technical solution’, or ‘system verification’.

2.5.1 The Difference between Verification and Validation

Although this thesis focuses on verification, validation is mentioned occasionally in order to distinguish the function of verification. This section indicates the differences between both processes.

During the verification process the technical solution, retrieved during the specification process (§2.4), is judged with respect to the specified design requirements mentioned in the output specification (INCOSE, 2011; ISO 15288, 2008).

Thesis Vincent Verheggen | Literature Study

During validation, the technical solution, retrieved after the specification process of the contractor, is judged with respect to this intended functions of the client, or the goal (Rijkswaterstaat, 2013). Figure 17 illustrates the differences between verification and validation.

Figure 17: Verification and validation (basic representation)

Engineers use the term verification and validation interchangeably without understanding the scope of their context. The following (practical and also basic) example provides insight in the difference between both terms (Wasson, 2006).

For example: Person A asks person B to build him an office. Person B starts building and when person B has finished the building, person B goes to person A for handover. Person A refuses to accept the building. According to person A, the building looks more like a residential house. Person B can objectively prove that the building he made is an office and not a residential house.

In the example above the technical solution (the building) can be verified: The technical solution objectively meets the demands of person A. However, as person A had another intended function in mind, the office cannot be validated.

The example sketched above demonstrates that verification reviews “that you build the technical solution right” and that validation reviews “that you build the right technical solution” (Defense Acquisition Guidebook, 1999; Wasson, 2006)

2.5.2 Verification processes

The verification process will be explained in more detail in this section. According to INCOSE (2011), the verification process contains two activities. These are:

- Plan verification - Perform verification During the development of the verification (plan verification), the verification is scheduled, confirmed, and verification enabling systems are installed. During the execution of the verification (performing the verification), the verification procedures are developed, verification activities are conducted and the result is documented.

Thesis Vincent Verheggen | Literature Study

Primary input for the verification process is the project baseline documented during the specification process. This include among others, the various requirements, verification criteria and the specification tree which mentions the relation between the requirements.

The output of the verification process is among others a verification strategy, verification design, verification procedure, verified system and a verification repport that mentions the findings of the verification. Figure 18 is based on INCOSE and mentions the input, activities and outputs of the verification process.

Figure 18: The verification process (based on INCOSE (2011) Two documents play an important role during the verification process: the verification plan and the verification report. The content of both documents is given in the following sections.

2.5.3 Verification plan

Meeting the requirements starts with a verification plan. In the verification, the contractor describes when and how to guarantee alignment with the requirements.

In the verification plan the following information can be found per requirement (Rijkswaterstaat, 2009b; SAAone, 2015):

- Description of the requirement (with requirement ID); - Reference to underlying derivative requirements; - Applicable principles in binding, informative and other documents; - When (date) the requirement must be met, the frequency and the verification moment; - Who is responsible for the verification; - How the verification needs to be done; - Which (obligatory) verification method is necessary; - Which Documents necessary for verification - this could me norms or guidelines; - Which Registration method needs to be used.

The verification report is exchanged with the client prior to the (design) activities and serves as evidence for complying with the requirements.

Thesis Vincent Verheggen | Literature Study

2.5.4 Verification report

Findings of the verification are described in the verification report. This report is based upon the verification plan and elaborates on the execution of the verification. It tells how the requirement is met and which document is used as evidence.

In the verification report the following information needs to be provided per object or per requirement (Rijkswaterstaat, 2009b; SAAone, 2015):

- Description of the requirement (with requirement ID); - Applicable principles in binding, informative and other documents; - Reference to the support document; - Which (obligated) verification method issued; - How the verification is done; - What the criteria were for verification; - How relevant risks are covered; - Who was responsible for the verification and who did the verification; - Possible actions for correction; - Revised verification if necessary.

2.5.5 Verification in the specification process

Figure 19 explains the verification processes with respect to the requirements in the earlier discussed output specification (§2.2) and specification process (§2.4) in the Vee model. This model was introduced in §2.4.2. Alongside the verification process, the validation process is indicated in this illustration.

Figure 19: Vee model including verification and validation

This illustration shows that verification of the technical solution takes place between the technical solution and the specified design requirements that are mentioned in the output specification. Validation takes place between the technical solution and the goal of the client.

Thesis Vincent Verheggen | Literature Study

Additionally, another verification moment is shown in Figure 19. Verification also occurs between the technical solution and the requirements that arise during the specification process: the derived technical requirements.

Section 2.2.3 explained that the output specification consists of both technical and functional requirements. In specific, functional requirements are made during the specification process. The technical requirements that are mentioned in the output specification are only changed to a minor extent during the specification process. The following example illustrates this.

For example: When the client wants a road with a width of 2.50 m (a technical requirement), the technical solution will not become more detailed during the specification process. The contractor is obliged to make a road with a width of 2.50 m.

A different situation occurs when the client provides a functional requirement, for example regarding the aspect ‘safety’. During the specification process, the choice is made that ‘safety’ can be achieved by ‘traffic lights’. A derived technical requirement arises that mentions the presence of ‘traffic lights’.

Verification of the technical solution is done with respect to the derived technical requirement (concerning ‘traffic lights’) AND the functional requirement ‘safety’.

The following illustration (Figure 20) is a simplified version of the illustration above and depicts the processes explained in the example. The technical solution is verified with respect to the technical and functional requirements mentioned in the output specification. In addition, the technical solution is verified with respect to the requirements that are developed during the specification process of the contractor.

Figure 20: Verification and validation positioned in the specification process

The goal of the client and the functional requirement show great similarities. According to Rijkswaterstaat (2009b, p. 28) top requirements (which are often functional requirements) follow directly from the goal of the client.

Thesis Vincent Verheggen | Literature Study

For example: A goal of the client can be to provide a safe connection for people between city A and city B. The client provides the functional requirement: the connection between city A and city B should be safe. In this case, the goal of the client occurs in the functional requirement and thus verification equals validation.

When we assume that the goal of the client and the functional requirement are the same, one can say that verification of the technical solution with respect to functional requirements of the output specification is similar to validation. This statement is easier to understand when looking at Figure 20. In this figure, the goal of the client and the functional requirements both have the same colour to indicate their similarities.

2.5.6 Ongoing character of Verification

Some people assume that Verification and Validation (V&V) is performed at the end of a lifecycle phase as part of systems acceptance. However, according to Wasson (2006) “V&V is performed at all system levels of abstraction and on each entity within a level”. When a decision is made, verification and validation can take place. Based on the outcome of the V&V, the next step in the development can be made more accurately.

When the verification processes indicate the technical solution does not meet expectations, mitigating steps can be taken. The solution can be steered into the right direction with verification. More verification moments result in a higher quality of the technical solution as mitigation measures can be taken immediately.

2.5.7 Verification Methods and Examples

As mentioned in the previous sections, verification ensures that the technical solution conform to the requirements sketched in the output specification and the self-derived requirements. To do this, verification encompasses tasks, actions, and activities (INCOSE, 2011).

There is a wide variety in literature on the various methods that can be used to do this. Most literature on verification methods can be found in the aerospace and military sector. This sub chapter will distinguish general verification methods from verification methods that are described and used in Dutch infrastructure.

2.5.7.1 Verification Methods in General According to Wasson (2006), there are four basic verification methods available to demonstrate that a system, product or service meets a specific requirement. These are the methods inspection, demonstration, test and analysis (INCOSE, 2011; NASA, 1995, 2007; Wasson, 2006).

The use of an unsuitable method can lead to inaccurate verification. Which verification method must be used is determined by the criticality of the elements under consideration and required safety (INCOSE, 2011). Most important in determining the right verification method is the potential risk.

Thesis Vincent Verheggen | Literature Study

The four verification methods described by multiple authors are explained below. Examples of the various verification methods, provided by Adams (2016), are given in order to provide context.

Inspection Inspection, also called ‘examination’ by Wasson, is a non-destructive examination that uses one or more of the five senses (visual, auditory, olfactory, tactile, taste) to inspect whether equipment and/or documentation meets the requirements. Physical manipulation and measurements are also covered in this method (Defense Acquisition Guidebook, 1999).

For example: An example of Inspection could be the visual inspection of a car to ensure that it has windows, air-conditioning and a steering wheel, and therefore can meet the requirements.

Demonstration Demonstration is often used in field bases applications and operational scenarios in the development or exploitation phases to test reliability, human engineering and maintainability. Demonstration shows that the use of a system or end product is as planned or can meet the requirements. Demonstrations can be done with physical models or mock-ups.

For example: Examples of the verification method demonstration is using the automatic switches in a car to check whether the windows can be opened and the air-condition is working properly.

Test During a test, data in the form of predefined measurements and results are collected to verify that the physical entity produces repeatable and predictable outcome(s). It needs to be ensured that the design or product will produce a specific and predefined output in order to prove that the design or product complies with the requirement specification (Adams, 2016).

Testing is one of the most expensive methods and therefore, is not often used. If methods such as analysis, inspection and demonstration can provide objective evidence to prove compliance, it is recommend to use these methods are as they are less expensive (Wasson, 2006).

For example: An example of testing can be accelerating a car to 100km/h and do a complete stop to verify that this can be done under 10 seconds.

Analysis Analysis includes the use of modelling and simulation as analytical tools (NASA, 2007). Analysis is the use of mathematical modelling and analytical techniques to predict the suitability of the design or product to the expectations of the stakeholder. It allows someone to make predictive statements about the performance of a product or system. For this verification method, data is derived from lower system structure end products.

Thesis Vincent Verheggen | Literature Study

Analysis is often used when a prototype is not available (NASA, 2007) or when testing is not cost-effective or feasible, similarity (see next paragraph) is not applicable and Inspection is not adequate (NASA, 1995).

Wasson (2006) describes the methods modelling and simulation as part of analysis. A model is a physical, mathematical, or logical representation of an end product that can be verified. Simulation is the manipulation of such a model. Modelling and Simulation (M&S) can be used to augment and support the verification process when analytical methods may be impractical and physical hardware and software cannot provide actual data (NASA, 1995; Wasson, 2006).

For example: An example of an analysis is the working of a car engine at a specific RPM for a predefined length of time. An analysis would be the monitoring of vibrations and temperature to verify the expected failure point of the engine.

Similarity The last used method for verification is Similarity. The SE Handbook (NASA, 1995) describes similarity as a reviewing process that checks if the product or design is similar or identical to another product or design that has previously been qualified to equivalent or more stringent specifications. Verification by similarity is often combined with the method Analysis. When differences in configuration, application or test conditions occur, analysis and additional testing is necessary to complete verification by the method of similarity (NASA, 1995). However, because every construction project is unique, it is difficult to compare the product with a similar product conducted in a previous project. For this reason, applying similarity as verification method is not always possible. The method similarity looks a lot like the method inspection. The difference between similarity and inspection is among others that inspection uses one of the five senses.

2.5.7.2 Dutch Infrastructure Sector Verification methods used in the Dutch transport infrastructure sector are described by Rijkswaterstaat (RWS). This governmental organisation provides many more methods than the five methods described by Wasson (2006). However, the methods described by RWS can all be classified within the methods of Wasson.

All methods that are listed in Table 1 are retrieved from the manual “Verificatie and Validatie” of Rijkswaterstaat (2009b).

Table 1: Verification methods described by RWS

Development phase Production phase Operation phase Analysis Demonstration Site inspection Audit Inspection Site measurement Calculation Check Monitoring Demonstration Entrance monitoring Document inspection Exit monitoring Document assessment Measurement Review Certificates Examination Test Modelling Simulation Reference Comparison

Thesis Vincent Verheggen | Literature Study

2.6 Augmented Reality

A definition of the technique Augmented Reality (AR) was given in §1.4.1. The information provided in this sub-chapter is retrieved from various authors that describe Augmented Reality in various sectors, including the construction sector. No information was found that describes the use of AR in the infrastructure sector, or more particular the Dutch infrastructure sector, suggesting that AR has yet to be implemented in this sector.

2.6.1 Difference between Augmented Reality and Virtual Reality

Virtual Reality (VR) and Augmented Reality (AR) are two major categories of 3D visualizations that can be used during construction (Dong et al., 2013). Both aids show virtual 3D contents, such as virtual 3D models. However, there are some important differences.

VR replaces the real world with an artificial one. Everything around the user is made with CAD software. The application of VR is to some extent limited to the combination of the real environment and how the real environment can be represented in virtual graphics. VR can be experienced with a Head Mounted Display (HMD). The technique can be used to review a model or simulation of different stages in the construction process and to collaboratively explore design options (Bouchlaghem et al., 2005).

While AR itself is not new, rapid technological advancements in hardware and software have led to AR being more widely used for public purposes. In figure 21 can be seen that AR is used for sales purposes.

Figure 21: Analysing position of furniture with Augmented Reality (Quay, 2013)

Milgram and Kishino (1994) describe AR as a mixture between the actual environment and the virtual one. The definition of AR that is used in this thesis is provided in §1.4.1.

Figure 22: Milgram’s Reality-Virtuality Continuum (positioned on the right is VR)

Thesis Vincent Verheggen | Literature Study

The position between real environment and virtual environment taken by AR becomes clear in the following illustration (Figure 22). In this illustration can be seen that AR consists of ‘real’ environment and ‘virtual environment’. The virtual models in AR are part of the ‘virtual environment.

According to Ahohen (2012), VR and AR are starting to come together since virtual models become more realistic. The difference between the environment and the virtual space is decreasing.

2.6.2 Allocation of Virtual 3D Models with Markers

In AR, a marker, such as barcodes, images, symbols or even 2D/3D shaped are used as a ticker for an action (Cowork Company, 2016). As the AR software recognises the marker, it will call the linked virtual model and place this model on top of the marker in the environment. In other words, markers are used in Augmented Reality (AR) to determine the position, the orientation and the virtual 3D model itself.

Figure 23 shows two examples of markers. The user can walk around, rotate, or reposition the marker. By doing so, the position and orientation of the 3D model will be changed relative to the environment.

AR can also be used without the use of a marker. With GPS, a compass and optionally environment recognition, a device can position the 3D model in the environment. Another option is that the user selects the 3D model before scaling and placing the model

Some AR software enables the use of multiple markers, showing multiple 3D models. This allows a user to analyse the position of multiple 3D models with respect to each other. In addition, this allows the user to interact with the model. Adding or hiding a marker can change, for example, the position or size of the 3D model in relation to the marker (see Figure 23).

Figure 23: Left: The virtual 3D model positioned on top of a marker (Chin, 2013), Right: Adjusting properties by covering markers (Magnani, 2010)

Thesis Vincent Verheggen | Literature Study

2.6.3 Required Hardware

AR is only possible with the support of certain devices, such as smartphones, tablets or glasses. On the screen of this device, the user can see the real environment, often captured with an on-board camera, combined with the virtual 3D model.

Tablets and smartphone merely always use the on-board cameras to capture the environment. A pair of glasses, a form of Head Mounted Display (HMD), with opaque glasses can also come with a camera to capture the environment. These glasses can be used to display Virtual Reality (with the camera off) and Augmented Reality (with the camera on). An example of a pair of state of the art glasses is the Microsoft HoloLens which is displayed in Figure 24.

Figure 24: The Microsoft HoloLens (Leswing, 2015)

2.6.4 Related Techniques

Augmented Reality can be combined with other techniques. Some examples are given below.

2.6.4.1 Simulation Augmented Reality (AR) is not limited to analysing static virtual 3D models. In a 3D model, it is possible to make a simulation by gradually changing the position or other properties of objects. This technique can be valuable for providing insight in a process, for example, the working of a motor.

2.6.4.2 Making use of human senses In addition to visual inputs, AR can also incorporate other senses, such as sound, smell, and tactile feedback. The user can evaluate a future highway with AR and using headphones can, for example, hear the highway’s noise.

2.6.4.3 Sensors AR can also be combined with sensors, such as a camera, microphone, ultrasound or passive infrared (PIR) sensor. The virtual model presented in AR can then respond to input data. An example is that a swiping motion of the hands can rotate, shift or change the 3D model within AR.

Thesis Vincent Verheggen | Literature Study

2.6.5 Applications

AR has multiple applications in the construction sector. Both Navab (2004) and Abboud (2014) provide various application categories. This subchapter provides 6 self-obtained application categories that are based on the categories that of Navab and Abboud. Each of the applications are classified according to the lifecycle phase where they are considered to be valuable.

2.6.5.1 Conception phase

AR for position review AR can help evaluate the position of one or multiple objects, to choose the right alternative at an early stage.

By rotating or moving markers with virtual 3D models, new design options can be analysed. The virtual models can be analysed in their environment and the position of the virtual models related to each other can be evaluated. The left photograph in Figure 25 illustrates how the position of two cranes on site can be evaluated. The example on the right shows two miniature figures that can be rotated or repositioned by rotating or repositioning the markers.

Figure 25: AR for positioning object or equipment during conception (Behzadan & Kamat, 2005)

Thesis Vincent Verheggen | Literature Study

2.6.5.2 Development phase

AR for interface review This application, also known as ‘full scale design visualisation in situ’ (Abboud, 2014), is most well-known. Mobile AR applications are available for public and commercial use. Prior to construction, a contractor or client can analyse how the objects in the virtual 3D models behave in the real environment. This can be done on site and in full scale. This allows non-experts to better understand the future situation in its environment.

Figure 26: AR for interface review during development (Cote, 2012; Mihai, 2014)

AR for design review Another possibility to analyse the virtual 3D model during the development phase is use ‘AR for design review’. This application can be used at a distance from the project location.

A practical application for ‘AR for design review’ is Table Top Modelling (TTM). This application is described in literature by Navab (2004) and his colleagues. AR-TTM allows the user to scan a marker and analyse the virtual 3D model on top of the marker such as described in §2.6.2.

The virtual 3D model shows information that is not presented on the floor plan. With this application, it is possible to show limitless virtual content (Abboud, 2014). This can vary between an ordinary 3D representation of what is sketched on the 2D floor plan or additional information such as information with a time component (4D simulation). Moving the camera allows the user to view the model from another angle, zoom in or zoom out. It is possible to scale the model up to life-size and even isolate layers or highlight objects of the structure. Figure 27 shows and illustration of TTM described by Azuma et al. (2001) and is retrieved from Navab’s paper: ‘Developing Killer Apps for Industrial Augmented Reality‘.

Figure 27: AR for design review during development (Azuma et al., 2001)

Thesis Vincent Verheggen | Literature Study

2.6.5.3 Production phase

AR for task support AR can be used for guidance during the production phase, for example, to help people execute work safely and correctly. The user can get live instructions from a tutor or previously defined guidance. An example is the use of AR for site workers to indicate safe areas (left side Figure 28). A site worker can get information of the areas he is allowed to enter. AR can indicate areas that are used by transport cranes and are risky.

Another example is the use of excavation works (right side Figure 28). With AR, site workers can see where existing pipes are located. Digging can be done more accurately without damaging other cables and pipes. Note that this is only possible when information on the existing situation is accurate and available in virtual 3D models.

Figure 28: AR for guidance during production (Bell, 2014)

AR for site review Early detection of schedule delay in field construction activities is vital to project management. AR can offer better insights in progress and planning. The left side of Figure 29 shows how AR can help identify objects that are delayed.

AR can also be used to review the work done on site. In this application, the virtual 3D model is presented on top of the environment. The user can review whether what is presented in the virtual 3D model is present and correct. In the example below on the right, a reinforcement bar is checked on site with respect to the 3D model.

Figure 29: Left: AR for planning review during production (Elgohari, 2015). Right: AR for positioning review during production (Léon van Berlo & TNO, 2011).

Thesis Vincent Verheggen | Literature Study

2.6.5.4 Support and retirement of systems

AR for training AR can help train employees, as well as help perform operation, repair or maintenance tasks. Training with AR allows a user with little or no prior knowledge to execute tasks. The user can consider many issues without being immersed in virtual space (Navab, 2004). This application is interesting for one of a kind situations. One can think of difficult assembly or safety and security situations in alternating environments. With this application, non-specialist workers can execute Figure 30: AR for training (AR for difficult tasks. Enterprise Alliance (AREA), 2015).

2.6.6 The Benefits

A virtual 3D model is a form of visualisation. Augmented Reality makes use of virtual 3D models and places them in an existing environment. Various authors have mentioned the benefits of virtual 3D models and visualisations in the construction sector. This section will highlight some of their findings.

Visualisation by means of virtual 3D models According to De Oliveira and Levkowitz (2003) a visualisation is a visual representation of data to support direct user interaction to explore and acquire insight into useful information embedded in the underlying data. Instead of visualising data it is also possible to visualise mental images.

Without the use of tools, people can only consider a limited number of issues at any one time. People can increase that number by identifying patterns in information and by thinking visually, can effectively process complex phenomena (Kamat & Martinez, 2001). But the ability to think visually differs from person to person. Visualisations can be an effective tool to communicate results in a short time and thereby gain a better understanding of a models’ behaviour (Rohrer, 2000) .

For example: Discovering a trend in numerical information is difficult. It is easier to discover a trend in a normal distribution graph (Figure 31). Visualisations provide us the possibility to focus on the interpretation of the results.

Figure 31: An example of information visualisation: two trend graphics (Rohrer, 2000)

Thesis Vincent Verheggen | Literature Study

Virtual 3D models are pictorial representations and manipulations of geometric data retrieved with Computer Aided Design (CAD). These models are therefore considered to be a visualisation. Virtual 3D models are used to perform calculations, renders and simulations. Rapid prototyping and the use of simulations are only some of the advantages of 3D models.

Virtual 3D models facilitate interdisciplinary understanding of complex construction projects (Bouchlaghem et al., 2005; Kamat & Martinez, 2001; Rohrer, 2000). With the help of 3D models, people can focus on interpreting results, as opposed to processing information (Rohrer, 2000). According to Robinson (1997), watching the virtual 3D model allows people to verify both the model’s logic and real-world behaviour.

Augmented Reality (AR) is a technique that makes use of visualisations. With AR, an observer can virtually augment the environment by placing in it a 3D model.

While virtual 3D models can help designers visualise a structure to see how the design will look, Augmented Reality can improve the understanding by helping construction teams to understand how the various systems interact with and in their environment.

A benefit of AR is that it eases the transition between 2D and 3D. Currently, the contractor can make use of 3D design software. The transition from the virtual 3D model to the 2D construction plan and from the 2D plan to the 3D built solution can be difficult and prone to error. Augmented Reality can help to better understand the design by showing the 3D model in the environment. (Green, 2016). AR provides a bridge between real-world activities and digital enhancements (Zünd et al., 2015)

Thesis Vincent Verheggen | Literature Study

2.6.7 Verification with Augmented Reality

According to Rohrer (2000), virtual 3D models play an important role during Verification and Validation (V&V), helping people understand results, communicate results, getting buy-in from nonbelievers, and achieving credibility for the visualisation. Rohrer states that the application of visualisation for V&V during development is most important.

Despite the added value of visualisation described in literature, only some construction related publications speculate about the use of Augmented Reality (AR) in the Dutch construction sector. Using AR for verification in particular is overlooked or only mentioned in passing in literature. There is as of yet no literature about the use of AR in Dutch mega transport projects.

2.6.8 Adoption of Augmented Reality

According to Klein and Sorra (1996), “Implementation is the process of gaining targeted organizational members' appropriate and committed use of an innovation”.

The effectiveness of an implementation effectiveness depends on the strength of an organization’s climate and the fit of that innovation to the values of the user (Klein & Sorra, 1996). Innovators have to find a balance between the most advanced technology within the user’s acceptance. This principle is coined MAYA. MAYA is an acronym for Most Advanced, Yet Acceptable (Hekkert, Snelders, & Wieringen, 2003). Users have to adopt new working methods and leave old assumptions and stereotypes behind (Abboud, 2014; Rogers, 2010).

Several new techniques and philosophies experienced resistance during their implementation. A good example of this related to the construction industry is the Building Information Modelling (BIM) philosophy. Although the benefits of this philosophy cannot be denied, implementation appears to be difficult.

The use of AR must be simple enough for users to learn and must stand on its own. The user must get a clearly see the technique’s benefits. This requires adequate training and specialist assistance in the implementation of new workflows (Abboud, 2014).

Thesis Vincent Verheggen | Literature Study

2.7 Sub-conclusion

This sub-chapter aims to provide early answers on both research sub-questions based on literature.

2.7.1 How are technical solutions verified with respect to functional product requirements during the development phase?

The sections §2.2- §2.5 discussed the output specification, requirements, specification process and verification process common in the development of Dutch mega transport projects.

Section §2.2 stated that the output specification is the contractual document between the client and the contractor. The client uses the output specification to communicate his needs and to provide functional or technical product requirements. Both types of requirements have their advantages and disadvantages. Requirements with a functional character allow the contractor to come up with creative solutions, but have a higher risk that the technical solution will not meet the client’s expectations. Technical requirements provide a detailed description of the product that the client demands. However, the knowledge and experience of the contractor is used to a limited extend, which could lead to more work and delays.

Functional product requirements are susceptible to interpretation as multiple technical solutions can fulfil the functions sketched in these requirements. Therefore, during a specification process, described in §2.4, technical requirements are derived from functional product requirements.

Verification of the technical solution is described in §2.5. Verification is done with respect to the requirements in the output specification (both functional and technical) and the technical requirements derived by the contractor.

When all technical requirements are met, the functional requirement is not necessarily met. Figure 32 depicts that other, not mentioned constraints may need to be considered in order to meet the functional requirement. It is up to the contractor to think of these constraints during the specification process.

Figure 32: Technical requirements cover only a part of the functional requirement

Figure 32 shows that the contractor’s specification process is indispensable in verifying the technical solution with respect to functional product requirements. Literature provides several pre-defined sets of methods that can be used in verifying the technical solution with respect to the derived technical requirements and the technical requirements (Figure 33). The most important methods for verification are, among

Thesis Vincent Verheggen | Literature Study others, demonstration, inspection, test and analysis (§2.5.7). The verification methods used in the Dutch infrastructure sector can be covered by these four methods.

Figure 33: Verification with respect to functional requirements

It is remarkable that most literature elaborates on how the specified, technical requirements provided by the client or developed by the contractor can be verified but omits an explanation of how the functional requirements of the output specification itself are verified during the development phase (see the note ‘not described’ in Figure 33). The definition of the verification process used by INCOSE states “The purpose of the Verification Process is to confirm that the specified design requirements are fulfilled by the system. […]” From this, it is unclear how the functional, non-specified requirements are verified.

A possible reason for this may be that verification of the technical solution with respect to the functional requirements during the development phase is similar to validation of the technical solution as the goal of the client often shows similarities with the functional requirements (§2.5.5).

The question arises how verification of the technical solution with respect to functional requirements is done in the field. Are functional requirements only indirectly verified, and if so, is it correct to assume that functional requirements can only be proven with validation methods? This is something that is researched in the next chapter: Case Study.

Thesis Vincent Verheggen | Literature Study

2.7.2 How can Augmented Reality be applied to verify technical solutions during development?

This sub-question can be answered with the help of §2.6. This paragraph shows that Augmented Reality (AR) is a technique that enhances, or augments, the users view of the real world (environment) with virtual information. Various applications of AR that can be used in the construction industry are (§2.6.5):

1. AR for position review 2. AR for interface review 3. AR for design review 4. AR for task support 5. AR for site review 6. AR for training

In the construction industry, the virtual information is often a virtual 3D model. Multiple authors have described the added value of visualisations or the added value of virtual 3D models during the development of construction projects (§2.6.6). Visualisation can help to identify patterns in information to process complex phenomena. The use of visualisation can be effective for communication and can lead to better understanding of the system. Literature suggests that virtual 3D models facilitate interdisciplinary understanding of complex construction projects.

Taking the benefits of visualisation into account, there is a potential value of AR for verification of the technical solution (§2.6.7.) However, not all of the AR applications mentioned in §2.6.5 can be used.

For verification, it is necessary that the technical solution is compared to the requirements. The application must enable communication of the technical solution. Only AR applications that facilitate communication of the technical solution are suitable.

Four of the six applications are considered to be useful for verification, as they can communicate the technical solution. These applications are:

- AR for position review - AR for interface reviews - AR for design review - AR for site review Based on the scope of this thesis, the focus lies on AR in the development phase (see the RQ and §1.4.4.). From the four mentioned methods ‘AR for interface review’ and ‘AR for design review’ can be used during the development phase for verification. ‘AR for position review’ and ‘AR for site review’ are applied in other phases

Thesis Vincent Verheggen | Literature Study

2.7.3 Summary of the findings

This section provides a summary of the observations with respect to both research sub-questions. This section is deliberately kept small to provide a good overview.

Sub-Question 1

Table 2: Findings of Chapter 2 with respect to the first sub-question

Section Findings §2.3 It is necessary to capture the voice of the client in order to deliver projects as intended. §2.3 The output specification is used by the client to communicate his needs. §2.3 Requirement from the output specification can be divided in functional and technical requirements. §2.4 Functional requirements are translated into technical requirements during the specification process of the client and the contractor. §2.5 Verification with respect to the derived technical requirement is easier compared to verification with respect to the functional requirement. The reason for this is that multiple technical solutions can be found during the specification process that meet the functional requirement. §2.5 Verification of the functional requirements self is done through verification of the technical requirement. According to literature, verification compares the technical solution with the specified design requirements. §2.5 Verification with respect to technical requirements can be done with four basic verification methods. These are: Demonstration, Analysis, Inspection and Test.

Sub-Question 2

Table 3: Findings of Chapter 2 with respect to the second sub-question

Section Findings §2.6 Six AR applications can be distinguished. Within these six applications, ‘AR for design review’, and ‘AR for interface review’ can be used for verification of the technical solution during the development of mega transport projects. §2.6 Adoption and implementation of innovation can be difficult.

Thesis Vincent Verheggen | Literature Study

Thesis Vincent Verheggen | Case Study Case Study

3.1 Overview of the Chapter

In this case study, several project documents of an existing mega transport project were analysed in order to answer the two research sub-questions:

SQ 1: How are technical solutions verified with respect to functional product requirements during the development phase?

SQ 2: How can Augmented Reality be applied to verify technical solutions during development?

This chapter starts with a brief overview of the case study ‘project SAAone’ in §3.2. After that, the chapter discusses the following subjects in order to answer the first sub- question:

1. Requirements at SAAone (§3.3) The output specification of project SAAone was analysed, resulting in an overview of the various requirements used in the project. It also discusses how the SAAone project distinguishes between technical and functional requirements. 2. Design verification process at SAAone (§3.4) The Verification and Validation manual of SAAone was analysed in order to learn more about their verification process. 3. Execution verification at SAAone (§3.5) The requirement management system of project SAAone was analysed in order to find out how verification is done in the field. SAAone does not use Augmented Reality for verification, which is why the use of Augmented Reality is only discussed in the conclusion of this chapter. The second sub- question, which elaborates on the use of Augmented Reality, will be answered based on the verification processes in project SAAone.

Thesis Vincent Verheggen | Case Study

3.2 Case Study Project

Project SAA Project SAA is considered a Mega Transport Project (MPT) within the Netherlands. It aims to improve the highway between Schiphol-Amsterdam-Almere (SAA) to guarantee the accessibility of the northern part of ‘The Randstad’. The Randstad is a major urban area in the Netherlands.

Project SAA consists of five sub-projects (Figure 34) (Rijkswaterstaat, 2016a). Rijkswaterstaat started with the expansion of the highway between Diemen and Almere Havendreef (A1/A6). The construction activities for project SAA are expected to be completed in 2020 (SAAone, 2016b).

Figure 34: Project SAAone (indicated in green) and 4 other SAA projects

SAAOne One of the sub-projects is the expansion of the highway A1/A6 between Diemen and Almere Havendreef (See green area in Figure 34). The amount of traffic increased extensively over the last couple of years. It is the objective of Rijkswaterstaat to reduce traffic congestion on the A1/A6 and improve the living conditions along the highway (Rijkswaterstaat, 2016b). Future developments such as the expansion of Almere also influence the accessibility of the Randstad (Rijksoverheid, 2016)

The expansion of the A1/A6 concerns construction activities over a distance of 20 kilometres. It encompasses an expansion to five driving lanes in each direction at the junction Diemen and another five driving lanes in each direction at the junction Hollandse Brug. Driving lanes on the A6 from the Hollandse Brug to the ring of Almere will be increased to four lanes in each direction. Along the entire trace, a tidal flow of two lanes will be constructed; the traffic direction on these lanes can be changed to create more capacity at peak hours. Besides transport infrastructure works, Project SAAone also includes some structural work. Some examples are an aqueduct underneath the river Vecht in the municipality of Muiden, the improvement of the junction Muidenberg and the construction of a new bridge across the Amsterdam- Rijnkanaal.

Rijkswaterstaat selected consortium SAAone to carry out the expansion of the highway A1/A6 Diemen-Almere Havendreef. The consortium was selected based on a type of

Thesis Vincent Verheggen | Case Study

contract called ‘Economisch Meest Voordelige Inschrijving’ (EMVI; Economically most beneficial tender) (Volker Wessels, 2016).

The project is executed as a Design, Build, Finance, and Maintain (DBFM) contract. In 2011 the project started and the expected finishing date of the construction is 2016. From that date, a maintenance period of 25 years will start. In this period, the consortium, which consists of Volker Wessels, Boskalis, HOCHTIEF and DIF, is responsible for the design, construction, finance and maintenance of the current and new highway (SAAone, 2016a).

3.3 Requirements

The information provided in this part arose after scrutinising the requirements in the output specification. It turns out that requirements have different sources and have a certain degree of functionality. The following two sections will elaborate on these characteristics.

3.3.1 Requirement Sources

Requirements in project SAAone have various sources. Requirements with the following sources are found (SAAone, 2015):

1. Requirements of RWS a. Output specification (Appendix 9, part 2) i. Functional requirements ii. Technical requirements (client derived requirements) b. Management specification c. Implementation agreement 2. Requirements of the contractor a. Risk Management Plan b. Traffic congestion Plan c. Basic Management Plan 3. Requirements from permits and exemptions 4. Requirements from SPC-EPCM agreement 5. (contractor) Derived requirements This thesis focuses on the requirements mentioned in the output specification (see number 1a in the list above). The contractor can, if necessary, translate these requirements into more technical requirements (see §2.4.4). The derived requirements that follow from the specification process of the contractor are indicated with the number 5 in the list above.

The degree of functionality of the requirements in the output specification will be discussed in the next sub-chapters.

Thesis Vincent Verheggen | Case Study

3.3.2 Functional and Technical Requirements

Requirements covered in the output specification can have a functional or technical character. This section describes how the degree of functionality can be determined.

The relation between the requirements provided by Rijkswaterstaat can be found by looking at the identification numbers. Figure 35 shows a part of the output specification of project SAAone. This figure shows that each requirement provided by Rijkswaterstaat has its own unique identification number (ID).

Figure 35: Identification numbers in the output specification

The identification numbers make it possible to analyse the link between requirements. The more technical requirements are often the ‘underlying requirements’ (Dutch: ‘onderliggend’). When these requirements are included in the output specification then they are the product of the specification process of the client, Rijkswaterstaat.

In addition to the technical requirements, RWS sees the need to communicate the higher positioned, more functional requirements.

A requirement tree indicates the functionality by linking all requirements to one another. An example of a part of a requirement tree with functional requirements and derived technical requirements of project SAAone is given in the example given below. This example indicates a transition between functional a technical requirement.

Thesis Vincent Verheggen | Case Study

For example:

The requirement tree in Table 4 is made from requirements found in the output specification of project SAAone.

Table 4: Requirement tree project SAAone, an example

A possible transition between functional and technical requirements within the output specification of Rijkswaterstaat is indicated with a blue line in the table above.

Requirement FN_00810 has a more functional character compared to requirement FN_02671. Where requirement FN_00810 elaborates on the road safety and appearance of a rest area, requirement FN_02671 reflects that the rest area needs to be decorated according to specific external documents. This is a more specific aspect compared with the relatively vague aspect ‘safety’.

The higher positioned requirements are not project specific, unlike the lower positioned requirements. Rijkswaterstaat is assumed to copy the higher positioned requirements from project to project. These requirements can serve as a structure for the lower positioned requirements.

Despite technical requirements begin derived from functional requirements during an internal specification process of RWS, verification of the functional requirements remains necessary due to the fact that the content covered in the lower positioned requirements does not necessarily represent the content of the higher positioned requirements.

Figure 36 depicts the requirements of the client and the contractor (blue and green). Also, this figure indicates the degree of functionality (functional or technical). This figure shows that sometimes the client provides functional requirements and sometimes technical requirements.

Thesis Vincent Verheggen | Case Study

Figure 36: requirement tree with functional and derived technical requirements

Requirements positioned in the bottom of the triangle are easy to verify. No interpretation freedom is left over.

The higher functional requirements, positioned in the top of the requirement tree, have a high impact on the design. These requirements are more difficult to verify as they can be met with multiple technical solutions. An example of such a requirement is ‘the road needs to be safe for traffic”. When the road is ‘safe’, technical aspects such as the width of the road are less important.

Thesis Vincent Verheggen | Case Study

3.4 Verification Processes

A verification process makes it possible to objectively determine whether the technical solution meets the requirements. The technical solution can be a document (design or execution document) or a realised object (for example a road or bridge). This sub- chapter elaborates on the verification strategy. The information given in this chapter is found in the Verification and Validation manual of project SAAone.

3.4.1 Verification Strategy

According to SAAone, the aim of verification is to prove that the technical solution can meet the client’s requirements and design constraints (SAAone, 2015). SAAone developed a verification strategy that consists of the following steps (SAAone, 2015)(p10):

1. Analysing requirements and if necessary deriving new requirements. 2. Linking the requirements to the future objects, activities and processes 3. Making a verification plan per requirement 4. Verifying work package activities with respect to the requirements 5. Verifying the technical solution with respect to the requirements 6. Checking that the technical solution and activities are executed according to plan 7. Mentioning discrepancies in requirements in order to meet the requirements.

Figure 37 provides an overview of the verification strategy of SAAone.

Figure 37: Verification strategy project SAAone

Thesis Vincent Verheggen | Case Study

3.5 Practical Data from the Requirement Management System

Having analyzed what kind of requirements are communicated and how SAAone aims to verify the technical solution with respect to these requirements, the actual verification process of functional and technical requirements can be analysed by examining the requirement management system.

3.5.1 Requirement Management System

The requirement management system contains the information from the requirement plan and report. In this database, the verification method is given for each verification and the authorisation person is mentioned. When the verification has been carried out the judgement can be found in this database.

SAAone’s system manages the relations between verification plan, verification report, objects, activities, results of the requirement analysis and allocation. This system, called VISE, is an online system and both contractor and client can make use of it. Information in VISE is linked to activities (work packages). Figure 38 illustrates the interface of the requirement management system of project SAAone.

Figure 38: Interface of the requirement management system used at project SAAone

Thesis Vincent Verheggen | Case Study

3.5.2 Verification with respect to Technical Requirements

It is necessary to know how verification with respect to the technical requirements is organised, before analysing the verification with respect to functional requirements in the next section.

To prove that the technical solution will meet the technical requirements, one or more verifications are conceived for each of the requirements. As is stated in §2.5.2, verifications are usually developed by the contractor.

For each requirement, one or more verifications are developed. Each verification consists of a method. Examples of verification methods are inspection, demonstration, analysis and test. Only when all verifications of one requirement are completed, the requirement is considered to be verified.

When the method inspection is chosen during the development phase, a registration type is provided. Often used registration types include: a construction plan (Dutch: Tekening), design rapport, list, construction plan, design nota, calculation, certificate and contract.

The following example provides the verification process of a technical requirement. The first part shows the requirement itself, the second part provides information from the verification plan and the last part gives the judgment written in the verification report. This example is retrieved from the requirement management system of SAAone.

For example:

Requirement from the output specification

Text from the verification plan

Judgment from the verification report Figure 39: Verification with respect to technical requirements an example

The verifier names a document in the required registration type that serves as evidence for the verification process. The judgement of this person is given in the verification rapport.

Thesis Vincent Verheggen | Case Study

This example shows that verification of the technical requirements is straightforward. The requirement mentions the presence of ‘parking lots’. The verification does the same and a construction plan is analysed on the presence of the ‘parking lots’.

3.5.3 Verification with respect to Functional Requirements

In the conclusion of the literature study the question arose whether, and how, verification of the functional requirements itself is done. The requirements management system of SAAone shows that the technical solution is verified with respect to the technical requirements. The technical solution is also verified with respect to functional requirements.

Verification regarding functional requirements is done in a similar way as verification with respect to technical requirements. In both verifications, the same verification methods are used. Although functional requirements are subjective, verification is made possible by making the verification task detailed.

Functional requirements can be verified by describing in detail the (verification) task that needs to be executed in order to carry out the verification during the development of the verification (1) and during the execution of the verification (2).

1. Development of the verification In order to verify a functional requirement, the functional requirement is translated into a detailed verification. This verification can be compared with a technical requirement.

An example of the development of a verification that belongs to a functional requirement is given in the example underneath. The example consists of a requirement used in project SAAone.

For example:

Requirement from the output specification

Text from the verification plan

Figure 40: Development of the verification, an example

Requirement FN_00809 is translated into more tangible objects and properties. The function ‘clean’ is translated into a detailed verification that mentions the presence of ‘bins’. It is remarkable that the verification only elaborates on the aspect ‘clean’ mentioned in the requirement and does not elaborate on the aspect ‘safety’.

2. Carrying out the verification

Thesis Vincent Verheggen | Case Study

The information in the requirement management system shows that another translation is made during the verification process to make the verification more detailed. An example is given below.

For example:

Text from the verification plan

Judgement from the verification report

Figure 41: Carrying out the verification, an example

In the example provided above, the verifier checks whether the resting area is designed according to the described ‘road safety’ and the presence of ‘bins’ by means of a document inspection. As road safety has a broad understanding, the verifier translates road safety into more tangible objects and properties during execution of the verification. Road safety is translated into ‘safe crossings’ and ‘separation of the road and sidewalks’.

Figure 42. The translation of the functional requirement to object properties.

Figure 42 illustrates the translation that takes place during the development and execution of verifications of functional requirements. By means of the detailed verifications, the functional requirements can be verified.

The transition from functional requirement to detailed verification is difficult to trace. It is conceivable that the functions ‘safe’ and ‘clean’ are translated according to the experience and knowledge of one who formulates the verification and one who

Thesis Vincent Verheggen | Case Study executes the verification. The choices that are made could possibly find their origin in the experience and knowledge gained during education or projects that earlier carried out.

3.5.4 Verification Method

Verifying the technical solution on compliance with the functional and technical requirements in the output specification can be done with standard methods. In literature, four standard methods are defined (§2.5.7)

The verification method is an important part of the verification activity (Rijkswaterstaat, 2009b). During the development of the verification plan each requirement will receive a verification method. Verification methods used in project SAAone are mentioned in Table 5. These methods show similarities with the methods mentioned in Chapter 2. Each of the methods of SAAone can be grouped in one of Wasson’s four basic verification methods.

Table 5: The distribution between verification methods at project SAAone.

Verification methods used at SAAone Number 1 Non-completed verification methods 1527 2 Analysis 1316 3 Audit 8 4 Calculation 248 5 Certification 575 6 Document Inspection 20237 7 Incoming Inspection 1838 8 Inspection 3152 9 Examination 6979 10 Measurement 5094 11 Verification through underlying requirements 557 12 Modelling 14 13 Monitoring 109 14 Reference 25 15 Test 1111 16 Output control 9 Grand Total 42799

A grand total of 42799 verifications are performed at project SAAone. In the requirement management systems, each verification must be performed and therefore consists of a verifier, supporting document, object, work package, etc. Such a large number of verifications takes up a lot of time and effort.

Table 5 shows that the method ‘document inspection’ is the most applied method for verification, namely 20237 times of the 42799 times.

Thesis Vincent Verheggen | Case Study

3.5.5 Document Inspection

The previous section brought to light that ‘document inspection’ is the most used verification method at project SAAone. To perform a document inspection, a ‘supporting document’ is analysed with respect to the criteria mentioned in the verification. Thereafter this document serves as evidence that the technical solution is met.

In order to gain more knowledge about supporting documents, some of the supporting documents of project SAAone were analysed. Most of the supporting documents appeared to be construction plans or design notes.

The following illustration gives an indication of supporting documents that were analysed and used as evidence. The type of document used depends on the aspects mentioned in the requirement and the project phase. The following types of supporting documents are found at project SAAone:

- Photograph - 2D construction plan - 2D construction plan derived from a 3D plan - Render from the virtual 3D model - Artist impression

a b

c d

Figure 43: Supporting documents used during document inspection.

Figure 43 shows some of the supporting documents that are used in project SAAone. In the left upper corner (a) and the right bottom corner (d) of Figure 43, a coloured construction plan is visible, the right upper corner (b) shows a photograph and the illustration in the bottom left corner (c) of Figure 43 is a render from the virtual 3D model.

A construction plan is quite often used as supporting document. A construction plan is easy to use for the verification method document inspection as this document is often made with construction or legislation purposes. The information presented on the

Thesis Vincent Verheggen | Case Study construction plan can be drawn directly in 2D (such as visible in the construction plan of Figure 43) or can be derived from a virtual 3D model.

An analysis of the supporting documents show that the judgement of the verifier is often difficult to trace. Appendix B provides several requirements and their corresponding verification, judgement and supporting documents. In the supporting documents presented in this appendix, the judgement mentioned by the verifier can rarely be derived from the supporting documents.

As an example, the verifier mentions the presence of ‘bins’ and proves this on a supporting document. In the supporting document (SAAONE-OWE-TEK-300091, Appendix B) used by the verifier, bins are difficult to find an are not covered in the legend of the document. It is therefore concluded that this document is made with another purpose than verification.

It seems that documents that are used for verification purposes are initially made with other purposes, for example, construction or legislation purposes. For laypeople, unfamiliar with construction plans, aspects mentioned by the experienced verifier are hardly or not at all visible in the supporting documents. It is therefore difficult for these laypeople to provide their opinion about the technical solution provided on the supporting documents. They cannot say whether the solution presented on these documents meets their expectations.

Why do mega transport projects still rely on construction plans with 2D visualisations instead of virtual 3D models? This is something to find out during the interviews in Chapter 4.

Thesis Vincent Verheggen | Case Study

3.6 Sub-Conclusion

This sub-chapter aims to give answers on both research sub-questions by means of information retrieved in project documents.

3.6.1 How are technical solutions verified with respect to functional product requirements during the development phase?

Requirements in the output specification of project SAAone have a functional or technical nature (§3.3.2). Technical requirements in the output specification are the product of the (internal) specification process of the client. They provide the minimum design constraints that are necessary to meet the functional requirement based on the interpretation and vision of the client.

The technical requirements in the output specification of project SAAone are always project specific. The functional requirements often serve as a structure for the lower positioned requirements and are vaguer. These requirements are expected to be copied from project to project.

A predefined verification strategy is used during project SAAone in order to verify the requirements of the output specification (§3.4). All requirements, those provided by Rijkswaterstaat and the self-obtained requirements and corresponding objects and activities, are collected in an online requirement management system. This system also contains a description of how a verification needs to be executed, including the verification methods, and the outcome of the verification.

In analysing the requirement management system, it became clear that verification of the technical requirements from the output specification is straightforward (§3.5.2). The question whether the functional requirements themselves are verified can be answered. In project SAAone, the functional requirements are verified by developing a detailed verification (§3.5.3).

The functional requirement is specified in two steps. First, the functional requirement is translated into a Detailed Verification (DV). Secondly, the interpretation of the verifier during the verification makes the requirement specific. During the development and execution of the verification, the technical solution is specified. The verification process of functional requirements can therefore be seen as part of the specification process.

In verifying functional requirements, the Knowledge and Experience (K&E) of both the developer and executor of the verification is important (§3.5.3). The two steps in which K&E are used to make the functional requirement specific are indicated in Figure 44.

The verification methods used can also be found in the requirement management system. The most used verification method in project SAAone is the method ‘document inspection’ (§3.5.4). This method verifies the technical solution with respect to the criteria in the verification with the help of supporting documents. These documents are provided as evidence that the requirement has been met.

Thesis Vincent Verheggen | Case Study

Figure 44: Specification of the functional requirement in project SAAone

The judgement of the verifier can rarely be retrieved by non-experts from the supporting documents. It seems that documents that are used for verification purposes are initially made for other purposes than verification (§3.5.5), such as for construction or for legislation purposes. For laypeople, unfamiliar with a construction plan and other technical communication aids, it is difficult to find the aspects mentioned by the verifier on the supporting documents. It is therefore difficult for these people to say whether the solution presented on these documents corresponds with their expectations.

Another constraint of supporting documents is that they only communicate technical aspects. They can, for example provide information about the width of the road (e.g. 4,50 m) but not about the function (e.g. the road needs to be safe for road users to get from point A to point B).

3.6.2 How can Augmented Reality be applied to verify technical solutions during development?

Augmented Reality is not used during project SAAone. Nevertheless, based on the way verification currently takes place, it can be determined which AR application can be helpful for verification in project SAAone.

This chapter found that the most used verification method is ‘document inspection’. This verification method has several disadvantages. First, analysing the technical solution for people who are unfamiliar with construction plans is difficult as construction plans need to be read. Secondly, only technical aspects can be retrieved from these documents. The supporting documents used for document inspection provide limited insight in functions.

It also became clear that verification of the technical solution takes place between the technical solution and the detailed verification that is derived from the functional requirement (see figure 44).

From the applications that are considered to be helpful for verification during the development, the applications ‘AR for design review’ can help to improve verification in project SAAone in two ways:

Thesis Vincent Verheggen | Case Study

1. This application of AR can improve the information provided on the supporting document with augmented information in a way that non-technical people can also judge the technical solution. As discussed in §3.5.5, the judgement of the verifier is often based on personal knowledge and experience. With better communication, this knowledge and experience can be better applied. 2. This application of AR can provide better insight in the function that is communicated by means of functional requirements, as it visualises that functional aspects are met. An example is that the client can see that the rest area alongside a high way is ‘clean’ or ‘safe’.

3.6.3 Summary of the findings

This section will provide an overview of this chapter’s most important conclusions, answers and observations.

Sub-Question 1

Table 6: Findings of Chapter 3 with respect to the first sub-question

Section Findings §3.4 The specification process is interwoven in the verification process of functional requirements. Development of the verification can be seen as part of the specification. §3.5 Knowledge and experience of the person who develops the verification and the person who executes the verification (the verifier) are important when defining functional requirements. §3.5 Supporting documents are often used as evidence for verification of the technical solution during the development phase. §3.5 The information in the supporting documents does not properly connect to the findings / judgement of the verifier. Verification of the technical solution is difficult for laypeople.

Sub-Question 2

Table 7: Findings of Chapter 3 with respect to the second sub-question

Section Findings §3.5 From the two AR applications that can be used for verification during the development phase of SAAone, the application ‘AR for design review’ is considered to be suitable to use for verification after the findings in Chapter 3. ‘AR for design review’ can: - Improve the understanding of supporting documents: it can support knowledge and experience of the verifier and the client. - Facilitate the communication of functions. The verifier and the client can see easily how the function is fulfilled.

Thesis Vincent Verheggen | Case Study

3.6.4 A Bridge to Chapter 4

With the findings provided in Table 2, 3, 6 and 7, the two research sub-questions and research question can be answered. Nevertheless, in the next chapter, interviews will be used to verify and complement the findings from Chapter 2 and 3. Thereafter the answer on both research sub-questions and the research question will be given.

The interview in Chapter 4 consists of two parts.

1. The first part validates and complements the findings and answers on the first sub- question given in Chapter 2 and 3. 2. The second part aims to validate the findings and answers on the second sub- question. It does this by testing the use of AR for verification with the application ‘AR for design review’. Four prototypes are used that serve as a case. It is expected that this application of AR provides better communication of information. It will be easier for people who are unfamiliar with supporting documents such as construction plans to provide their opinion on the technical solution.

In addition, it is expected that this application AR provides insight in the function better than conventional visual techniques presented on supporting documents. By using AR, the observer can verify the technical solution with respect to functional requirements.

Thesis Vincent Verheggen | Interviews Interviews

4.1 Overview of the Chapter

Six experts were interviewed to validate and possibly complement the answers on the sub-questions provided in the literature study and case study. The interviews served to determine whether ‘AR for design review’ can add value to the verification process of functional requirements.

Each interview consisted of two parts. In the first part, interviewees were asked to provide their opinion on the verification process in Dutch mega transport projects. The aim of this part was to validate and complement the answers and observations given in Chapter 2 and 3 on the first sub-question.

The second part of the interview sought to validate the use of AR for verification with respect to functional requirements. To do this, four prototypes of AR were developed and used as an example. The interviewees provided their opinion on the use of Augmented Reality for verification of the technical solution based on the prototypes.

This chapter starts with a selection and background of the interviewees (§4.2 & §4.3). Section 4.4 provides an explanation of the tool ‘Table top modelling’ (TTM). The procedure for conducting the interview and questions that are asked during the interview are covered in §4.5. A description of how the data of the interviews was analysed and processed is described in the section ‘Measures’ (§4.6).

The results, in the form of statements of the interviewees, are given in §4.7 and will be discussed in §4.8. In the sub-conclusion the validity of the findings retrieved from Chapter 2 and Chapter 3 will be discussed (§3.6.3).

Thesis Vincent Verheggen | Interviews

4.2 Selection of the Interviewees

Six interviewees participated, each with more than five years of working experience.

The interviewees were selected based on requirement management or AR. Two interviewees work on behalf of Rijkswaterstaat, an important client of mega transport projects in the Netherlands. Two of the selected interviewees work for large contractors that develop these mega transport projects. These interviewees have, just as the interviewees that work for RWS, experience in requirement management. Two interviewees were selected based on their knowledge on implementation of new software and techniques in the infrastructure sector.

Most of the interviewees were recommended by the company that facilitates this graduation project or employees of TU Delft involved with this research.

4.3 Interviewees

The background information of the selected interviewees can be found in Table 8:

- The interviewee’s profession - The sector the interviewee works in - An estimation of the years of working experience - The company the interviewee works for - The place the interview was conducted - The date the interview was conducted

Table 8: Background information of the interviewees.

# Function Company Years of Company Place Interview sector experience Date A Design Contractor More than 5 SaaOne (Volker Project Office 08-6-2016 manager Wessels InfraDesign) SAAone, Diemen B Contract Client More than 5 Hochtief, (Former) Office Hochtief, 14-6-2016 manager RWS Diemen C ICT expert Contractor More than 10 Volker infra Design Office Van Hattem en 17-6-2015 Balkevoort, Woerden D Team Client More than 20 RWS Office RWS, Utrecht 23-6-2016 manager SE E General Contractor More than 20 Infranea Office Infranea, 29-6-2016 manager / consulting Werkendam F Project Contractor More than 25 SaaOne (Hochtief) Project Office 5-7-2016 manager SAAone, Diemen

In addition, the knowledge on the mains subjects was estimated:

- Available knowledge of verification - Available knowledge of Augmented Reality (AR)

Table 9: Estimated knowledge of the interviewees with respect to verification and AR

A B C D E F Knowledge of Verification + +/- + + + + Knowledge of AR + - + - + -

Thesis Vincent Verheggen | Interviews

The participants in the interviews were labelled with letters for privacy reasons. Each participant is indicated with a letter from A to F. In §4.7 the letters are assigned to the opinions of the different participants. By doing so, the opinion of the participant and quotes are less easy to trace and the interviewees stay to a certain extent anonymous.

4.4 Using Table Top Modelling

The AR application ‘AR for design review’ was used as an example during Part 2 of the interviews. The motivation to use this application is twofold:

- The application can be used for verification during the development phase Chapter 2 shows that this application can be used for verification during the development phase, together with ‘AR for interface review’ (§2.7.2) - Improves the readability of the supporting documents From §3.5.3, it became clear that knowledge and experience of the verifier is indispensable in judging the technical solution. The outcome of the verification process is therefore not good traceable. AR makes that the client and other stakeholders can better understand the technical solution to form a judgment when they are in possession of accurate and precise information.

In order to test the AR application for verification, a tool named ‘Table Top Modelling’ (TTM) is used. TTM is a practical tool that can be used to carry out the application AR for design review. The next section will explain the mobile application of this tool as used during the interviews.

4.4.1 The Application for Table Top Modelling

During the interviews, the free software application ‘Augment’ was used in combination with an educational license to carry out TTM.

Augment was founded in 2011 and now has more than 200 clients in 36 countries and is leader in the augmented reality space. With their AR application, Augment lets users experience AR. Their software is used as a sales solution. In addition, the software is used for Omni-commerce (a business model used by companies to increase user experience), marketing, Business-To-Business (B2B) sales and design validation of daily products such as cars and furniture. According to their webpage, their application supports better communication as it lets partners and clients communicate the design of a product. According to Augment (2016), the application allows all stakeholders to “quickly reach a full appreciation of the vision by removing the guesswork”.

The service provided by Augment makes use of an online database where the user can upload the virtual 3D content and a 2D marker. With the help of an online platform the user can link the marker to the virtual content. After this is done, the user can scan a marker or select a virtual model in order to analyse the virtual 3D model in the environment or on top of the marker. The user will see the virtual content by looking on an LCD screen of a tablet or smartphone while the environment is captured with the camera of the tablet or smartphone (Figure 45).

Thesis Vincent Verheggen | Interviews

Figure 45: Left: Scan of the construction plan. Right: Analysing the virtual 3D model with AR-TTM (Kroll, 2016)

The application made by Augment is user-friendly and made for non-experts. Users that are non-experienced can download the application on their smartphone and tablet and get convinced of the use of the product. Nevertheless, a virtual 3D model is necessary and in order to get this model ICT knowledge is necessary.

4.4.2 Developing the Prototypes

Several steps are taken in order to develop the four prototypes that match the requirements:

1. Selecting the requirements that serve as a case 2. Developing the virtual 3D model that belongs to the requirement 3. Adding an animation to the 3D model (optional) 4. Adjusting the supporting document that belongs to the 3D model 5. Selecting the marker on the supporting document 6. Linking the marker and the 3D model on Augment’s platform (see §4.4.1) 7. Downloading the Augment application for tablet and verifying it works A more detailed explanation of the use of AR-TTM and the development of the AR models/content can be found in Appendix C.

4.5 Interview Procedure

The interviews consisted of two parts: Verification processes (Part 1), and Verification with Augmented Reality (AR) (Part 2). This section will discuss the questions per part and the prototypes used in Part 2 of the interview.

Thesis Vincent Verheggen | Interviews

4.5.1 Interview Questions

Part 1: Verification processes The first part of the interviews elaborates on how requirements are currently verified. This process was analysed before in the literature study and case study. The goal of this part is to underpin the problem and to reinforce/validate the answer on the first research sub-question. The interviewees were asked to provide their opinion on the verification process. This part of the interview had a semi-structured character. The following questions were used as guidance:

- Do requirements in the output specification have a functional or rather technical character? - What is the advantage of providing functional and technical requirements? - Is the goal of the requirement clear? - How are verification processes executed in your field? - What are the problems during the verification process? - Are any actions taken as response to this problem? - Which phase of the construction project emphasises the verification process? - What methods are used for verification? - Are there methods that are more commonly used than others?

Part 2: Verification with Augmented Reality This part of the interview was also semi-structured. It examined the benefits of AR for verification during the development phase. To research the added value of AR, the interviewees analysed four prototypes that make use of the AR application ‘AR for design review’. They analysed the prototypes with respect to four corresponding functional requirements.

The interviewees were asked about their opinion on the use of AR in the verification process after the prototypes were shown. The aim of this was to validate the answers given in the Chapters 2 and 3 on the second sub-question. After they were shown the prototypes, they were asked the following questions:

- Does AR improve the understanding of information such as the technical solution? - Can AR be used for verification with respect to functional product requirements? - What are possible advantages of using AR for verification of the technical solution with respect to functional requirements? - Do you foresee disadvantages of using AR for verification/validation? - Are there any requirements that have more potential for the use of AR during verification and validation compared to others? (For example, functional or technical requirements, type of object discussed in the requirement) - What are advantages and disadvantages of AR for verification compared to verification with the help of a virtual 3D model shown on a computer screen?

4.5.2 Prototypes used during Part 2 of the interview

This section discusses the prototypes used during Part 2 of the interview. As discussed in the previous section, in Part 2, the interviewees analysed four prototypes with the AR Table Top Modelling (TTM) tool.

Thesis Vincent Verheggen | Interviews

Each prototype corresponds with a set of requirements from project SAAone. The selected requirements can be found in Table 10. Selection of the requirements is described in more detail in Appendix C.

Table 10: Requirements used in Part 2 of the interview

# Category Number Requirement text 1 Signalling FN_00599 All entrances to the reversible lanes must have a movable barrier and, of both sides of this barrier automatic gates should be placed. FN_00766 The automatic gate must cover the whole entrance so that it is impossible to drive along the gate. 2 Appearance VG_00089 The infrastructure must comply with the Ambition Document ‘Appearance’ (Dutch: Vormgeving) E-07327 Where possible, the control boxes that regulate the reversible lanes must be merged with control boxes of other systems. Placing boxes with another size of colour next to each other is not allowed. 3 Positioning FN_00420 The road signs must inform road users on the appropriate route, conform Directive CROW 222, CROW 262 and the New guidelines for road signs. OR_03286 On the reversible lanes of the highway A9 the place ‘Haarlem’ must be position above ‘Shiphol’. 4 Control FN_02018 The infrastructure of RWS must obtain current video images of the traffic on the reversible lanes so the VC has clear sight on the direction of the traffic. FN_02983 All cameras that are necessary for opening the reversible lanes need to be position in in the direction of the opening of the reversible lanes.

Sets of two requirements were selected as there is a smooth transition from technical to functional requirements (§2.3.3). It is supposed that the provided two requirements will be on the transition from functional to technical. It will be easier to use such a kind of requirement instead of a fully functional requirement.

Each set of requirements corresponds with a supporting document. The supporting documents originate from SAAone. The supporting documents are displayed in the Figure 46. The requirements indicated in Table 10 with the numbers 1 and 4 have the same supporting document: Number 1 in Figure 46.

1 2 3

Figure 46: Supporting document used in Part 2 of the interview (number 1, 2 and 3)

Figure 47 shows an area of the supporting document that is used as marker. The interviewees have to scan the marker on the supporting document with the tablet in order to see the virtual 3D model on top of the marker. Note that marker Number 1 and 4 are from the same supporting document (Document 1 in figure 46).

Thesis Vincent Verheggen | Interviews

1 2

3 4 Figure 47: AR-TTM markers used in Part 2 of the interview

Figure 48 shows the view of the interviewee with the tool TTM after scanning the markers. The virtual 3D model is placed on top of the marker, which in turn is part of the supporting document. More information about the development of the prototypes can be found in Appendix C.

1 2

3 4 Figure 48: AR-TTM prototypes used in Part 2 of the interview

Thesis Vincent Verheggen | Interviews

4.6 Measures

The following approach was generally adopted in order to carry out the interviews and analyse the data:

1. Initial contact with interviewees The interviewees were approached by email or phone. The goal of the interview was communicated to the interviewee in advance as well as the fact that no preparation for the interview was required. Most of the interviews took place in the office of the interviewee. 2. In-depth interviews The interviews were conducted in Dutch, as it was expected that interviewees could better express themselves in in their native language. The conversation was recorded on tape in order to transcribe the interview. 3. Transcription After the interview took place, it was transcribed, word for word. Only some repeating words are filtered out in order to make the transcripts more legible. 4. Summary of the transcript The transcripts covered multiple pages and therefore a summary was made, including the most important parts. This summary can be found in Appendix E. 5. Recognizing patterns in the different transcripts The information provided by the interviewees did not entirely match the questions made in advance, as the interview had a semi-structured character. The information provided by the interviews and written down in the summary is therefore categorised according to recurring aspects. 6. Aligning and combining the findings Information of the various interviewees with respect to each aspect were listed. Double opinions were removed and some answers were combined to provide a clear overview. The outcome of this step can be found in the next section: Results.

Thesis Vincent Verheggen | Interviews

4.7 Results

In this section the results are provided. The results of the interviews are the answers given by the interviewees on various subjects. The results are given per part of the interview.

4.7.1 Part 1: Verification processes

This part of the interview has a semi-structured character. The questions that are made in advance were only partially answered (§4.5.1). The letters A to F refer to the names of the interviewees.

Problems with verification processes Interviewees gave different answers when asked about complications during the verification processes. Most of the answers discuss the focus on the technical requirements:

B: The contractor focuses too much on verification of the technical requirements. As a result, the overall goal is lost. A/B: Lots of paper work is involved in verification as result of the enormous number of technical requirements. One forgets that each technical requirement needs to be verified and validated. F: There are too many requirements and corresponding verifications that add no or little value to the technical solution. It is often unnecessary to provide these requirements. For example, a requirement that states that the road has to facilitate traffic.

According to the interviewees, the problems mentioned here all relate to the content of the requirements. Overall, the interviewees mention the ambiguous character of requirements in the output specification. They say among other things that:

A/E: The interpretation of requirements is often difficult. A/B/E: The context that has to evoke the underlying goal of the requirement, in other words the question behind the question, is not or poorly communicated along with the requirement.

Context of requirements Interviewees repeatedly mentioned the lack of context as initiator for the problems. Interviewee D provides the following statement:

D: “A requirement does not stand on its own. A requirement is the consequence of an implicit or explicit choice of the client. Sometimes, you can see the choice in the design documents but often you cannot”.

According to interviewee B, this lack of context has several reasons:

B: - The client is afraid that providing context along with the requirement creates rights for the contractor - The client is not sure that his information is correct. It is therefore not convenient to provide context

Thesis Vincent Verheggen | Interviews

- The client does not know which information is useful for the contractor. Therefore, the client provides no context - The client has only limited time to transfer a lot of information. During the specification process of the client, many decisions are made. The time and aids are not sufficient to communicate the context One often assumes that the initiator of missing context is the client. Nevertheless, interviewee E mentioned an interesting point about the role of the contractor

E: - Wrong interpretation can not only be blamed on the client but, but also on the contractor. The contractor seeks a way to distinguish himself from competitors

Verification with respect to functional requirements In Chapter 2 is stated that it is difficult to understand how functional requirements are verified. Interviewee F provides some clarification:

F: Verification becomes easier and more important when the degree of functionality decreases. Verification with respect to functional requirements is difficult and therefore rarely done.

Recommendations The interviewees were asked to provide recommendations for improving the requirement processes. They say among other things that:

D: Early verification is helpful Early in the development, the specification consists mainly of functional requirements, as technical requirements have yet to be derived. Compared to technical requirements, functional requirements represent the goal of the client to a greater extent. Early verification means verification with respect to the functional requirements. When verification with respect to functional requirements is possible, this decreases the likelihood that the overall goal will be missed. F: Focus on ‘specials’ According to Interviewee F, more attention must be paid to so-called specials. Specials are activities or objects that are new for the project organisation and therefore have a high risk of failure. Too much attention is paid to activities and objects that are routine. F: Insight in the relation between requirements When the relation between client’s requirements is better understood, the contractor has a better idea of the degree of functionality and therefore how much design freedom there is. The relation between requirements is seen as context. With more or better information, the contractor can develop a better technical solution.

Verification methods The interviewees all mentioned that the method ‘document inspection’ is most often used. According to interviewee E, document inspection is used often because this method allows the client to process the outcome of the verification process in his own systems. This information could be valuable for management and maintenance purposes.

Thesis Vincent Verheggen | Interviews

4.7.2 Part 2: Verification with Augmented Reality

This section will provide the answers given in Part 2 of the interview. This part is considered as most important. Where Part 1 elaborated on the problems that occur during verification processes, this part examines how Augmented Reality might solve these problems. As this part of the interview also had a semi-structured character, not all questions mentioned in §4.5.1 are discussed.

Overall response on the AR-TTM Prototypes Every interviewee had a neutral to positive response with respect to the AR-Table Top Modelling (TTM) prototypes. Interviewees with limited knowledge of new visual techniques were more positive compared to the interviewees with knowledge about recent visual techniques.

A/C: Positive about the technique but saw some implementation issues. B/E/F: Neutral positive. D: Very positive, took pictures of the AR-TTM application which indicated his enthusiasm (see Figure 49).

Figure 49: Photo taken by interviewee D in part 2 of the The next part of this section will provide more insight in the interview advantages and disadvantages of AR.

AR advantages The interviewees mentioned many advantages of the AR technique. Not all the advantages mentioned by the interviewees were visible in the prototypes. Nevertheless, the prototypes were a good starting point and proof of concept. The following advantages of AR were mentioned by the interviewees:

A/B: Experience the ‘AR experience’ is often mentioned by the interviewees. The user can observe the model to a much greater extent compared to conventional communication aids. Analysing the virtual 3D model can be entertaining. The user gets the idea that he is immersed in a world the given virtual 3D model is part of.

The following (more or less practical) advantages are considered to be part of the AR experience:

C: Interactive character The users mention a feeling of freedom as result of the interactive character of AR. Interaction with the environment often provides better insights in the technical solution. A/E: Realistic character AR is even more realistic compared to other visual techniques. The environment of the virtual 3D model is real and not made with CAD software. The observer has the feeling that he can ‘touch’ the solution. E: Dynamic character It is possible to walk around the model or observer the model from different angels. This could provide a better insight in the solution.

Thesis Vincent Verheggen | Interviews

The three advantages mentioned above contribute to other advantages, such as:

A/B/E/F: Better communication With AR, a better understanding of the technical solution is possible. Information can be communicated more effectively with the help of images. Especially for laypeople, it is made easier to think visually. E: Better expectations of the technical solution When the technical solution is communicated without misinterpretation the client will have a better understanding of what can be expected. When the client sees that the solution does not meet his expectations early on, measures can be taken. D: Increasing trust When the client thinks that the information provides a full image of the technical solution, he can be sure that no mistakes will be made. The client will then trust the contractor.

Advantages compared to computer visualisations What are the advantages of AR-TTM compared to a virtual 3D model presented on a computer screen? The interviewees that had experience with new visual techniques could provide an answer on this aspect.

C/E: Using the environment creates a realistic experience With AR, the virtual 3D model is positioned in the real environment. The environment can provide better insights on aspects of the virtual 3D model. It is for example possible to gain a good understanding of the dimensions of the 3D model by comparing it with the environment. When analysing a virtual 3D model on computer, the environment is not drawn or it also consists of virtual 3D objects. These objects are perceived as less realistic compared to the real environment. C/E: Interactive character According to Interviewee C and E, AR allows the user to easily interact with the technical solution. The user of AR can walk around the model or rotate the AR device to analyse certain aspects of the virtual 3D model. Analysing the virtual 3D model on a computer requires knowledge of the CAD software to show different angels. Analysing the virtual model with an AR device feels ‘natural’.

Requirements that benefit by verification with AR-TTM According to the interviewees, AR is especially interesting for verification of requirements with aspects mentioned in functional requirements.

Mentioned are: RAMS-SHEEP aspects (B), Design/appearance aspects (A/B), Interfaces (A), Processes (A/D/E) and Safety (E). Interviewee E summarises that AR is suitable to verify requirements that elaborate on perceptual/subjective aspects.

Thesis Vincent Verheggen | Interviews

Risks of using AR for verification Although the use of AR has many advantages in the verification process, there are also downsides. Two risks are mentioned that can occur when using AR for verification:

1. According to Interviewee D and E, a risk of using AR is misunderstanding the accuracy of the information in the virtual content. For example, a user of AR analyses a model that consists of the trees species. It was the intention of the developer of the virtual 3D content to indicate the position of trees and not the species. The developer of the virtual content randomly chose a tree species and accidently choose the species Oak. 2. Another risk is mentioned by Interviewee A. Verification is a legal process and each objective verifier should come to the same judgement. Verification with respect to functional requirements is already difficult. Interviewee A questions whether the dynamic character of AR contributes to the verification process of functional requirements.

Technical limitations of Augmented Reality Some interviewees foresee some problems in implementing AR in the construction industry. Interviewee A has experience with implementing AR in the construction industry, and mentioned the following possible implementation issues of technological nature.

1. It is difficult to find a good reference point when using AR outside. Allocating the virtual 3D model is difficult. 2. The size of the virtual model (that can be expressed by the number of polygons) presents another problem. Often virtual 3D models are too heavy to run with hardware on small AR devices. 3. The scale of infrastructure projects is huge. This contributes to the size of the virtual 3D model.

AR for verification Interviewee C is involved in the implementation of new visual techniques in the construction industry. He provides the following recommendations for using AR:

- Support interaction Use an AR device that supports interaction such as touching, walking, pointing. The use of a tablet only partly supports interaction with the virtual 3D model. - Allow multiple users There is value in allowing multiple users to make use of AR at the same time. Users can interact and communicate with each other and discuss the technical solution. Improve workflow It is valuable that the corresponding virtual 3D model is loaded when a requirement is selected. During the interviews the models and requirements had to be separately selected. - Do not use markers Place the model in the room without a marker. The use of a supporting document has several limitations: the scale, the future of markers and the last limitation is the effort that is required to link the marker and the model.

Thesis Vincent Verheggen | Interviews

4.8 Discussion of the Results

Although the answers given by the interviewees are often self-explanatory, this section will discuss some of the answers that are relevant to answers the research sub- questions and the research question.

4.8.1 Part 1: Verification processes

Verification with respect to technical and functional requirements It is difficult to understand the relation between verification and validation of functional and technical requirements. The interviews led to a better understanding of this relation. Both technical requirements as functional requirements can be verified and validated.

The results of the interviews indicate that it is easier to verify a technical solution with technical requirements than with respect to functional requirements, due to the broad interpretation of these requirements. Figure 50 depicts this.

ease Figure 50: Verification and validation of technical and functional requirements

Validation is discussed apart from verification in this thesis. The definition of validation is given in §1.4.2 in combination with verification. In §2.5.5 is stated that verification with respect to functional requirements shows similarities with validation as the goal of the client is often described in the functional requirement. It can be stated that the research of this thesis, which focuses on verification with respect to functional requirements, is therefore also focussing on validation of the technical solution. The line in the upper part of the box between verification and validation is dotted as result of the seminaries.

The verification method ‘document inspection’ From the interviews appeared that supporting documents are often used as the client can process the outcome of the verification process easily in his systems. This confirms the findings from the Case Study in Chapter 3 (§3.5.5). A virtual 3D model, analysed with the help of a computer, could be too dynamic to use for verification. A judgment based on a computer model may differ from person to person as the viewing angle differs.

Thesis Vincent Verheggen | Interviews

Problems with the provided requirements Interviewees suggested that one reason why a technical solution may fail to meet a client’s expectation is a lack of context. The problem with functional requirements is that they can be interpreted in multiple ways during the specification process. When the client provides enough context along with the functional requirement the contractor knows how to interpret the functional requirement.

This way of reasoning is illustrated in Figure 51.

Figure 51: Not meeting the expectation is the result of missing context.

That multiple technical solutions can be used to meet the functional requirement makes verification of the technical solution with respect to these requirements so difficult.

Context One of the interviewees gave various reasons why context is not fully provided to the contractor during the development phase. The provided reasons can be attributed to ignorance of the client about which information is valuable for the contractor and distrust between the client and the contractor. Providing context appears to be dangerous and can often be associated with legal consequences. It is possible that the client is afraid that when he provides information this information can be used against him.

Some might think that functional specification and providing information is contradictory. Providing more information does not have to mean that there is less design freedom. The following paragraph will highlight the information that must be provided and the information that must be omitted in a functional specification.

Context information can be divided in two parts: information that describes the boundaries of the design freedom and the information that describes the client’s wishes. Providing wishes that describe preferences will decrease the design freedom of the contractor. Therefore, only information that describes the boundaries of the technical solution must be communicated. The wishes of the client must be omitted to promote freedom. Figure 52 illustrates the design freedom within the total amount of technical solutions.

From all the information provided by the client, it is difficult to distinguish wishes from information that describes the ‘design boundaries’. The border can therefore be better illustrated as a blurred line (see right side Figure 52). In order to meet the expectation of the client and still be able to use functional requirements, it is recommended to involve the client during the specification process of the contractor in the development phase. It is expected that the client can distinguish additional information from the information that is important for the technical solution.

Thesis Vincent Verheggen | Interviews

wishes

Figure 52: design freedom within the total amount of possible technical solutions

When the technical solution lies beyond the boundaries of the design freedom, the client can raise the alarm and the contractor can adjust the technical solution.

Interviewee E mentioned that wrong interpretation of requirements can not only be attributed to a client who provides unclear requirements. An unclear distinction between context information and the boundaries of the design freedom can be favourable for the contractor. The contractor seeks the boundaries of the design freedom in order to distinguish himself from other competitive parties during tendering. When the client is involved during the specification process, this problem will be tackled as well. The solution developed by the contractor will be positioned in the middle of the design freedom (see figure 52).

How to verify functional requirements The client translates some functional requirements into technical requirements during the internal specification process. Both, functional and technical requirements, are provided to the contractor. The derived technical requirements tell something about the interpretation of the functional requirement. However, the sum of the underlying technical requirements is not fully equal to the functional requirement. The technical requirements can therefore not be used to verify the solution with respect to the functional requirement.

An interesting thought is that for verification of the technical solution with respect to the functional requirement, the technical solution does not need to be verified, but the solution needs to be verified with respect to the choices made during the specification process. Questions such as: are the right choices made during the specification, and, do these choices provide the right technical requirements, must be asked. The client generally has a better view on aspects of the technical solution and should therefore be involved during the specification process to communicate his expectation.

Thesis Vincent Verheggen | Interviews

Early verification The interviewees mention that early verification will result in less effort and fewer mistakes during the production and operation. The reason for this is that, early in the development phase, more functional requirements are used as technical requirements have yet to be derived from these requirements. Functional requirements represent the overall goal of the client entirely or better than technical requirements. Interviewees mention that too much attention is placed on technical requirements.

When verification is done early in the construction process, the emphasis of the verification process will shift from the technical requirements towards the more functional requirement. Less effort is required in the entire verification process (see area under the graph in Figure 53).

Figure 53: Reduction of technical requirements and effort involved in the verification process as result of early verification

4.8.2 Part 2: Verification with Augmented Reality

Overall opinion about the use of AR for verification All the interviewees had a neutral to positive response with respect to the Augmented Reality (AR) Table Top Modelling (TTM) prototypes. Interviewees familiar with AR were less positive compared to the interviewees who were unfamiliar with such new visual techniques. This difference may be due to the novelty effect.

Advantages of using AR for verification The interviewees mentioned many advantages of AR. Most heard is the ‘AR experience’. The AR experience combines several advantages such as the dynamic, interactive and the realistic character of the observation.

Thesis Vincent Verheggen | Interviews

According to the interviewees, these advantages could lead to better communication of the technical solution. In an early phase, the client can point out that the technical solution does not meet his expectations. An action can be taken to change the expectation, the requirements or the technical solution. Another advantage is that when the client has the feeling that he is heard and involved in the design and it becomes clear that a certain technical solution is not possible, the client is more likely to understand this.

Figure 54: The AR experience leads to an increasing trust between the client and contractor

One of the reasons that context is limited provided along with the requirements is distrust between the client and contractor (see Part 1 of the interview). When a client feels that he is involved (as result of AR), trust between him and the contractor grows. As a result, his list of requirements will contain fewer technical requirements and more functional requirements, allowing the contractor more design freedom and maximizing creativity

AR for Subjective Requirements Most interviewees mention the use of AR for verification with respect to functional requirements or validation. According to §2.5.5, there are commonalities between verification with respect to functional requirements and validation. AR will be less suitable for verification of the technical solution with respect to technical requirements as technical aspect often require a high level of detail in the visualisation.

Interviewees mention the possibility to verify requirements with RAMS-SHEEP criteria and other subjective aspects with AR. Examples are requirements concerning safety, appearance and interfaces.

In addition, interviewees mention the potential value of AR for requirements that elaborate on dynamic processes. It is possible within AR to simulate an animation of the process. An example of this is the closing procedure of a tunnel in case of emergency. One can provide a better judgement with AR compared to a static 2D supporting document.

Two potential problems for using AR for verification A potential problem of AR is that clients may misunderstand the accurateness of the information in the virtual content, for example, the trees species mentioned by Interviewee D and E. The developer of the virtual 3D content wanted to indicate the position of trees and not the species. He randomly chose a tree species and chose the preferred specie Oak. The user of AR may be dissatisfied as he draws unintended conclusions based on the information. This disadvantage is not limited to AR and also occurs verification is done with the help of 3D models on a computer screen.

Thesis Vincent Verheggen | Interviews

This problem can be solved by clear communication of the function of the virtual 3D model within AR. Practical objects that need be evaluated and must be taken into account can be highlighted in the virtual 3D model. By doing this the user knows the accuracy of the virtual content.

Another potential problem is mentioned by interviewee A. Verification is a legal process and it must be at all times objective and repeatable. When an objective person repeats the verification, the outcome must be the same. AR may be too dynamic to allow a verifier to come to the same conclusion. An observer can, for example, analyse the virtual 3D model in the environment from different viewing angles.

This problem can be solved by using print screens or snapshots within AR. Computer design review software such as Autodesk Navisworks makes use of print-screens. A user can easily trace the judgement within this software based on these print screens or snapshots that are previously made.

AR verification in 2025 In Part 2 of the interview, participants used a tablet to analyse the virtual models with AR. A tablet has, as mentioned by Interviewee C, limitations for full experience of AR. For example, the observer is not free to use his hands during observation as he has to hold the tablet. When using AR in the future for verification, it would be better to make use of a Head mounted display (HMD). Unfortunately, the use of a HMD was not feasible in this thesis.

Taking this, other recommendations and the solution for both problems mentioned above into account, Figure 55 represents how verification of a technical solution is done by 2025.

Interface of the user: Selection of the requirement and possibility to track verifications.

Figure 55: Impression of future AR-TTM.

Thesis Vincent Verheggen | Interviews

One can see in the illustration:

- No marker is used No visible marker on the supporting document is used; the virtual 3D model is placed in the middle of the room, for instance, on a conference table as the use of a marker has several disadvantages: o Development of a marker will be time consuming, o The scale of the supporting document makes the virtual content small o Difficult to find the marker (the right spot within the construction plan) for the interviewee - The workflow is improved As it is time consuming to present the virtual 3D model and then search for the corresponding requirements, by 2025, when a user selects a requirement on the AR device, the corresponding virtual 3D model is automatically loaded. - Free movement is allowed Users are free to use their hands and feet by making use of a head-mounted display (HMD). The users can freely walk around the model and point to aspects displayed. Note that that the use of an HMD affects the costs and ease of using AR for people with little experience. - The attitude of multiple users can be seen There are multiple users in one room that analyse the model at the same time. It is recommended that users can see, besides the model and the environment, also the other observers. When the attitude of the other users is visible, the user can better understand, based on the attitude of the other observer, whether the technical solution meets the expectations. It must be noted that analysing the attitude of other users is difficult as AR glasses cover the eyes of the users. Therefore, this future ‘thought’ to some degree contradicts the recommendation: ‘Free movement’ is allowed. - Objectivity is supported Users must be able to highlight or encircle objects within the virtual 3D model. This is necessary as AR has a dynamic character while verification is a strict and repeatable process. By doing this, it is immediately clear which aspects are of importance for meeting the requirement. It must be possible to make print screens and highlight object. Only then is it clear for people on which aspects users based their judgement. - Other information sources are supported Other senses than sight such as hearing, smell, taste and touch can be used to enhance the experience and even better analyse the technical solution.

Thesis Vincent Verheggen | Interviews

4.9 Sub-Conclusion

This chapter can be seen as a validation of the findings retrieved from Chapter 2 and Chapter 3. The following two tables mention the findings of the interviews. Topics that were validated during the interviews are indicated with the letter ‘V’. If findings are not validated it means that the aspect is not discussed (‘ND’) during the interview.

Sub-Question 1: How are technical solutions verified with respect to functional product requirements during the development phase?

The interviews had a semi structured character. For this reason, the validity of the findings from chapter 2 and 3 was determined after the interviews were conducted.

Table 11: Validation of the findings from Chapter 2 and 3 in order to answer SQ1

Section Findings Valid. §2.3 It is necessary to capture the voice of the client in order to V deliver projects as intended. §2.3 The output specification is used by the client to communicate ND his needs. §2.3 Requirement from the output specification can be divided in V functional and technical requirements. §2.4 Functional requirements are translated into technical V requirements during the specification process of the client and the contractor. §2.5 Verification with respect to the derived technical requirement is V easier compared to verification with respect to the functional requirement. The reason for this is that multiple technical solutions can be found during the specification process that meet the functional requirement. §2.5 Verification of the functional requirements self is done through ND verification of the technical requirement. According to literature, verification compares the technical solution with the specified design requirements. §2.5 Verification with respect to technical requirements can be done ND with four basic verification methods. These are: Demonstration, Analysis, Inspection and Test. §3.4 The specification process is interwoven in the verification ND process of functional requirements. Development of the verification can be seen as part of the specification. §3.5 Knowledge and experience of the person who develops the ND verification and the person who executes the verification (the verifier) are important when defining functional requirements. §3.5 Supporting documents are often used as evidence for V verification of the technical solution during the development phase. §3.5 The information in the supporting documents does not properly V connect to the findings / judgement of the verifier. Verification of the technical solution is difficult for laypeople. ND: not discussed during the interviews V: validated based on the interviews

Thesis Vincent Verheggen | Interviews

None of the findings were contradicted by the interviewees. However, some findings about less relevant aspects were not discussed during the interviews. That findings were not discussed during the interview does not mean that these are not valid.

In addition to the findings mentioned in Table 11, the interviews also provided new information. The following findings were retrieved from the interviews with respect to the first sub-question

- Too much focus lies on the technical requirements. Each requirement needs to be verified which is time consuming - The method document inspection is often used by the client to manage documents in his internal system - Problems in the verification process can be attributed to ignorance and distrust between the client and the contractor. Providing context appears to be dangerous and can often be associated with legal consequences. - That multiple technical solutions are possible to meet a functional requirement makes verification of the technical solution with respect to these requirements so difficult. - More context will lead to a technical solution that is in line with the expectations of the client. The client has to make sure to communicate ‘design constraints’ instead of wishes. The client is the only one that can properly distinguish both forms of information. It is therefore recommended to involve the client in the development phase. - To verify the technical solution with respect to the functional requirement, the technical solution does not need to be verified (with respect to the functional requirement), but the solution needs to be verified with respect to the choices made during the specification process. - In order to meet the expectation and still be able to use functional requirements, the client should be involved during the contractor’s specification process in the development phase. The validated findings plus the additional findings provide a lot of insight in the verification processes of mega transport projects.

Thesis Vincent Verheggen | Interviews

Sub-Question 2: How can Augmented Reality be applied to verify technical solutions during development?

Just as the findings that help to answer sub-question 1, the findings that help to answer sub-question 2 derived from chapter 2 and 3 are indirectly validated. The validity of the answers is determined after the interviews were conducted.

Table 12: Validation of the findings from Chapter 2 and 3 in order to answer SQ2

Section Findings Valid. §2.6 Six AR applications can be distinguished. The application, ‘AR ND for design review’, and ‘AR for interface review’ can be used for verification of the technical solution during the development of mega transport projects. §2.6 Adoption and implementation of innovation can be difficult V §3.5 From the two AR applications that can be used for verification V during the development phase of SAAone, the application ‘AR for design review’ is considered to be suitable to use for verification after the findings in Chapter 3. ‘AR for design review’ can: - Improve a client’s understanding of supporting documents: it can support knowledge and experience of the verifier and the client. - Facilitate the communication of functions. The verifier and the client can see easily how the function is fulfilled. ND: not discussed during the interviews V: validated based on the interviews

The division of six AR applications was not discussed during the interview as they were not considered to be of importance. In addition to the validated findings, several other findings emerged from the interviews. The following findings have to do with the second sub-question.

- Advantages of AR are: the dynamic, interactive and realistic character. These advantages result in better communication, better expectations and eventually increased trust between the contractor and the client. Compared with computer verification, AR supports interaction better and is more dynamic - Requirements that elaborate on perceptual/subjective aspects are especially suited for verification with AR - Potential problems of verification with AR are: o Misunderstanding about the accurateness of the information in the virtual content o The dynamic character of AR might be ill-suited for objective repeatable judgement - Technical problems are, among others: o The lack of a good reference point o The size of the virtual model (e.g. polygon count) o The scale of the model - Several mitigating measures can be taken in order to improve the use or AR for verification such as the use of no marker, multiple users and other information sources (e.g. sound & smell).

Thesis Vincent Verheggen | Interviews

Thesis Vincent Verheggen | Conclusions & Discussion Conclusions & Discussion

5.1 Overview of the Chapter

This section critically examines the findings from the three previous chapters together. The chapter will start with a conclusion (§5.2) whereafter a discussion is given (§5.3).

In the section ‘Conclusion’ an answer will be provided on both research sub-question before an answer is given on the research question.

The section ‘Discussion’ starts with comparing the findings from Chapter 2 Literature study, with the findings from Chapter 3 and Chapter 4. Research limitation will be given in §5.3.2. This section elaborates on possible influential factors during this research. The last section will provide several (creative) thoughts about what has been learned.

Thesis Vincent Verheggen | Conclusions & Discussion

5.2 Conclusions

After presenting the findings, this section will answer both research sub-questions.

5.2.1 Sub-Question 1

How are technical solutions verified with respect to functional product requirements during the development phase?

To know how a technical solution is verified with respect to functional requirements, it is necessary to know how the technical solution is retrieved from the functional requirements.

The client provides both functional (F) and technical (T) requirements to communicate his needs to the contractor. The technical requirements are the product of a clients’ internal specification process (see Figure 56).

F = Functional requirement T = Technical requirement DV = Detailed verification Figure 56: Functional and technical requirements of the client (letters F&T).

In order to come to the technical solution, a contractor translates those functional requirements into technical requirements during a specification process. These all come together in a technical solution.

In practice, the technical requirements come in the form of a detailed verification. A detailed verification consists of technical criteria and can be compared with a technical requirement. The detailed verification is an interpretation of the functional requirement and is made according to knowledge and experience of the person who develops the verification. Finding the right interpretation for the functional requirements is difficult as the functional requirements are ambiguous and unclear.

Verification of the technical solution can be done during and after the development phase to make sure that the technical solution meets the requirements. When verification is done early in the development phase, the client can signal where the technical solution fails to meet his expectations, preventing a possibly unsatisfactory outcome. At this early stage, functional requirements have yet to be derived.

Thesis Vincent Verheggen | Conclusions & Discussion

Four basic methods can be used to verify a technical solution with the criteria mentioned in the detailed verification. Verification of the functional requirement does not occur in practice (see Figure 57).

Figure 57: Verification of the technical solution with respect to the verification

The method most commonly used to verify the technical solution on the criteria in the detailed verification is ‘Document Inspection’. In this method, the verifier or client provides his opinion about the extent to which the technical solution meets the criteria. To do this, the verifier analyses a document, often is a construction plan. When the verifier considers that the technical solution meets the criteria in the detailed verification, the document is entered as evidence. The document becomes a ‘supporting document’.

It is difficult to understand how a verifier comes to a judgement. There is a discrepancy between the information provided on the supporting documents and the judgement given by verifier. The judgement cannot be based solely on the supporting document as this document is made for another purpose than verification. The verifier evaluates the technical solution with respect to the detailed verification based on experience and knowledge.

It is also difficult for the client and other stakeholders to analyse the technical solution using only the supporting document as these people are to some extent unfamiliar with working with supporting documents such as construction plan.

It can be concluded that Knowledge and Experience (K&E) of the designer, verifier and other stakeholders influence the verification process at two steps during a project, namely (see Figure 58):

1. During the translation from functional to detailed verifications 2. When judging the technical solution with respect to the detailed verification.

Figure 58: Influence of Knowledge and Experience (K&E) of the stakeholders, verifier and designer.

There are two important disadvantages regarding the use of the supporting documents during execution of the verification method document inspection:

1. The supporting documents provide limited insight in the extent to which the technical solution is aligned with the criteria from the detailed verification. Supporting documents are made with other purposes than verification. For people

Thesis Vincent Verheggen | Conclusions & Discussion

unfamiliar with supporting documents, it is even harder to provide a judgement based on the supporting documents. 2. The supporting documents are used to verify the criteria that are provided in the detailed verification or technical requirements. These documents provide insight in the technical aspect and limited insight and evidence that the technical solution meets the functional requirement. For example, a supporting document, such as a construction plan with 2D illustrations can provide good insight in quantitative criteria but not in the functions.

It is important to point out that the technical solution is developed (or translated) according to the knowledge, experience and therefor interpretation of the verifier and the person that develops the verification. Translation is prone to interpretation mistakes. When verification is done with respect to functional requirements the potential interpretation mistakes can be avoided (See figure 60)

5.2.2 Sub-Question 2

How can Augmented Reality be applied to verify technical solutions during development?

AR has many advantages for reviewing the design during its development. With it, a user can experience a combination of various advantages such as the dynamic and interactive character and its realism. This will result in better and easier communication of the technical solution.

There are multiple conceivable applications possible for using AR in the construction industry. From the six applications that were defined, the AR applications ‘AR for design review’ and ‘AR for interface review’ can be used for verification in the development phase. Of these, ‘AR for design review’ has two important benefits:

Firstly, the application ‘AR for design review’ can complement information presented in supporting documents. This will improve readability for people unfamiliar with such documents. Those people can better judge a design by using ‘AR for design review’ to make better use of their knowledge and experience. The user will experience more freedom to examine the model and will therefore get a better perception of the technical solution.

Secondly, AR can be used for requirements that elaborate on perceptual/subjective aspects. AR makes it possible to verify the technical solution with respect to functional requirements. AR is less suited to providing evidence with respect to technical requirements.

Using AR for verification also has a number of, mainly technological, downsides, such as:

- Difficulty of finding a good reference point for the virtual 3D model - The size of the virtual 3D model in terms of processing power required - The scale of the virtual 3D model

Thesis Vincent Verheggen | Conclusions & Discussion

As technological development marches on, these technical implementation issues are expected to be solved in time. There are two non-technical issues that must be taken into account when using AR for design review for verification. These are:

1. The accuracy of the information There is a change that the user of AR analyses the virtual content with the wrong intent. The tree species example in §4.7.2 demonstrates the risk that is involved by using visual techniques for verification. 2. The dynamic character of AR AR has proven to be dynamic and interactive. These characteristics can be hard to match with the legal nature of verification. These technical and non-technical challenges have led to the following recommendations when using ‘AR for design review’ for verification (§4.8.2):

- Do not make use of an AR marker - Improve the workflow by letting the user select requirements instead of letting the user select the virtual 3D model - Consider free movement - Support objectivity - Allow multiple observers to use AR concurrently - Support other information sources

5.2.3 Research Question

The research question is answered in two parts

1. The benefits of AR for design review 2. The practical implementation of AR for design review

The benefits of Augmented Reality for design review The application ‘AR for design review’ is valuable and can be used for verification of the technical solution with respect to functional requirements. Applying ‘AR for design review’ has two important advantages:

Firstly, it makes analysing the technical solution and understanding the judgment of the verifier easier for laypeople unfamiliar with supporting documents. With AR, these people can provide their opinion on the technical solution, without having to struggle with supporting documents. They read the supporting documents, using the virtual model placed on top of it.

When the client can fully understand the technical solution during the development phase, it is possible to provide a better judgement. When the technical solution does not meet the client’s expectations, the client can mention this so a contractor can take measures to ensure that the final technical solution meets the expectations.

Thesis Vincent Verheggen | Conclusions & Discussion

Secondly, it may be difficult to use AR for technical requirements, for example the width of a road, but AR can provide insight in functional aspects such as ‘safety’ and ‘appearance’. AR appears to be an effective tool to communicate the functions mentioned in functional requirements.

Technical requirements are still necessary to come to the technical solution. Nevertheless, with the use of AR the focus in the verification process will shift from technical requirements towards functional requirements.

Chapter two discussed how verifying functional requirements in the development phase resembles validation when the function provided in the functional requirement and the goal of the client are the same. Therefore, we can conclude AR has major potential for validation of the technical solution.

In other words, AR can be used to see whether the technical interpretation of the functional requirements is correct. It is possible to analyse the technical solution and to see if the sum of the technical requirements meets the functional requirement. This is illustrated in Figure 59; the yellow circles represent client requirements; the green circle represents a technical aspect or requirement within the design freedom of the contractor.

F = Functional requirement T = Technical requirement DV = Detailed verification

Figure 59: The position of AR in the construction process

Some may wonder what advantage AR offers to verification with the help of a computer. The answer is that while models presented on computer screens have a dynamic, interactive and realistic character, these characteristics are better expressed in AR. Virtual 3D models analysed with a computer remain static in structure and surface characteristic. The use of computers for verification is good. Nevertheless, AR can be seen as a next step.

Thesis Vincent Verheggen | Conclusions & Discussion

Practical implementation of AR for design review The application ‘AR for design review’ was tested during interviews, using a Table Top Modelling Augmented Reality (TTM-AR) application. If a contractor wants to use a similar application, he should follow the steps given below.

1. Analyse the requirements from the output specification Part 2 2. Select requirement that are functional and could have multiple technical solutions. 3. Develop the verification by making a verification plan per requirement a. Translate the functional requirement to a detailed verification b. Choose the method ‘inspection with AR-TTM 4. Work out the design. Make sure to draw everything in CAD, virtual 3D 5. Develop an AR-TTM application for the project that supports objective and repeatable judgement 6. Analyse the virtual 3D models with AR-TTM together with the client 7. Mention discrepancies in the requirements by adding notes in the virtual 3D model. Step 6 can be compared with step 6 of the specification process of SAAone. Step 6 of SAAone suggests ensuring that the technical solution and activities are executed with respect to the verification plan. The technical solution in step 6, described above, is compared with the function. The translation from functional requirement into technical requirement is bypassed, as is the translation from technical solution to technical requirement.

Note that the steps above do not make use of a marker. Normally a 2D construction plan will serve as supporting document. From this document a marker is retrieved. However, the use of a marker is discouraged as:

- The scale of the supporting document is too small - The scale of the technical solution is too large - It is time consuming to link the marker and the virtual 3D model

To conclude Technology evolves and AR’s technical challenges will be resolved in time. While implementation of this new technique may not be easy and several non-technical issues need to be remedied, AR can add much to the verification process. With AR, a client can experience a technical solution, comment on it, provide contextual information or clarification where necessary and thereby prevent a possible disappointment. As the relationship between clients and contractor’s changes, with clients increasingly relying on the technical know-how and creativity of contractors, it becomes increasingly important for clients and contractors to communicate effectively. AR can serve as a great tool to achieve that aim.

Thesis Vincent Verheggen | Conclusions & Discussion

5.3 Discussion

This section will briefly discuss the differences found between literature and the case study project. In addition, this section will mention the research limitations.

5.3.1 Comparison with Literature

Chapter 2 of this thesis explained various subjects based on information found in literature. Chapter 3 and Chapter 4 provided information about these aspects based on an existing projects and the opinion of six experts. This section provides various interesting differences between literature, the case study and the interviews. This section will highlight some of these differences according to the order they are discussed in Chapter 2.

§2.4 Specification process The specification process is widely described in literature. This process can often be found in combination with literature that describes the system engineering philosophy.

An iterative specification process such as described in literature does not exist. The specification of the requirements in the output specification is done in the background during various processes, including in the development of the verification and the execution such as described in §3.5.3.

§2.5 Verification processes The first two steps from the verification strategy of SAAone are:

- Analysing requirements and, if necessary, deriving new requirements - Linking the requirements to the future objects, activities and processes These steps can be compared to the specification process as discussed in the literature (§2.4). The steps mentioned in literature are Requirement analysis and Structuring and Allocation of information.

In step 3 of the verification strategy of SAAone, a verification plan is made per requirement. In this step a verification method is determined that suits the verification of the requirement and is comparable with verification processes discussed in §2.5.2. Steps 4, 5 and 6 in the verification strategy of project SAAone look similar to each other. These steps can be compared to the activity ‘perform verification’ mentioned in §2.5.2.

Along with the specification steps, literature provides four standard methods that can be used for verification (§2.5.7). These are: test, demonstration, analysis and inspection.

In practice several other methods are used for verification (§3.5.4). A total of 16 verification methods are used. Each of the methods used in project SAAone can be grouped under one of the four standard verification methods mentioned in literature. The verification method ‘document inspection’ is most often used in SAAone. This method can be grouped under the method ‘Inspection’, mentioned in literature. Methods such as demonstration, analysis and test are used to a smaller extent in the development phase.

Thesis Vincent Verheggen | Conclusions & Discussion

5.3.2 Research Limitations

The aim of this section is to predict which decisions could possibly have had an influence on the results of this thesis.

The use of Table Top Modelling An important choice is the use of the application ‘AR for design review’ during the interviews (§4.4). This application was used during the interviews by using the practical tool Augmented Reality Table Top Modelling (AR-TTM). The question arises if other applications would have result in other results or if other applications would be more suitable to test how AR can be used for verification.

The application described in §2.6.5 ‘AR for Interface review’ can next to AR for design review also be used for verification as with this application the user can gain a better understanding of the technical solution. As the thesis focusses on the problems related to the readability of the construction plans the choice is made to research the use of the application ‘AR for design review’. It is expected that the results that are gained by using AR-TTM can also be applied on the application ‘AR for interface review’. Advantages such as the realistic, dynamic and interactive character during validation are likely for this application as this application has the same characteristics as the application AR for design review.

The selected requirements Not all requirements of the case study project were shown to the interviewees. Four requirement sets of project SAAone were used during Part 2 of the interview. The four requirements sets were considered as a good representation of the total number of requirements. Each set consists of another category requirement (signalling, appearance, positioning and control). The selection of the requirements set was done in steps that are further discussed in Appendix C.

A limitation of this research is that the four selected sets of requirements are originating from four categories. In project SAAone requirements can be classified in various other categories. Although not can be guaranteed that AR can also be applied on other categories of requirements than mentioned above, verifying requirements of the four categories is valuable

The use of a tablet as Augmented Reality device As indicated by one of the interviewees, the use of a particular Augmented Reality (AR) device can influence the results. During the interviews a tablet was used as AR device. When taking the definition given in §1.4.1 of AR into account, a tablet can be used to provide the AR experiences but there are more devices possible such as a Head Mounted Display (HMD) in the form of a glass. It is expected that the results of this study will be different for a HMD. The use of a HMD has got its advantages and disadvantages. The advantage is that the user can freely use hands. The disadvantage is that such a device is less affordable and difficult to use for laypeople. Additionally, such a device covers the eyes of the user while eyes are an important aspect in non- verbal communication. Taking the disadvantages into consideration, the choice is made that a HMD is not effective to use for this research.

Thesis Vincent Verheggen | Conclusions & Discussion

The number of interviewees Six interviews were conducted for this thesis. The aim of this thesis was to generate a broad overview of the verification process and the AR technology. It is not the goal of this thesis to generate findings that are applicable for each and every project. It is however the aim to provide aspects that need to be considered when using AR for verification. As the aim was not a quantitative evaluation of the value experts attribute to AR, the small number of interviewees poses no limitation.

The Interpretation of the researcher The results of the case study and the interviews are interpreted by the researcher. This is a side effect of the chosen research method. The influence of the researcher’s perspective on the results cannot entirely be excluded.

In this research is aimed to minimalize the influence of the researcher’s perspective by communicating the interview protocol, the selection process of the requirements and development of the prototypes (Appendix C and D). Additionally, the summaries of the transcriptions are provided in Appendix E. Providing those information allows the reader to trace the results and observations.

Thesis Vincent Verheggen | Recommendations Recommendations

This chapter provides, in the first section, several recommendations for contractors and professionals in the field. In the second section, some recommendations will be given for further research.

6.1 Contractor and client

Contractor Contractors should use Augmented Reality to involve the client in the design and strengthen the relation and trust between both parties during the development phase. In using AR, there are some technical restrictions that need to be solved prior to the use of this technique for verification.

- Use AR-TTM for subjective aspects Functional requirements that concern subjective aspects can be verified with AR-TTM: e.g. the safety or appearance, not the width of a road. - Clarify the virtual model’s purpose when using AR Providing the purpose is vital. Users must be prevented from drawing conclusions based on aspects visible in the virtual 3D model that are outside the scope of the virtual 3D model. - Develop virtual 3D models for AR-TTM Make sure that during the development phase the software is used to an extent that models can be generated that can be analysed within AR. Take into account the size of the virtual 3D model and the scale of the model.

The points mentioned in §4.7.2 must be taken into account when using AR for verification. These are:

- Do not make use of a marker when making use of AR for verification. The use of a marker has several disadvantages that are mentioned in in the conclusion of this thesis: o The supporting document is too small in scale o The scale of the technical solution is too big o It is time consuming to link the marker and the virtual 3D model - Improve workflow by making it possible to select requirement in the AR application - Consider free movement by making use of a head mounted display. The disadvantage is that a Head Mounted Display (HMD) is more expensive and difficult to use compared to mobile phones and tablets - Support objectivity. Support tracking of the verification with movie or snapshot - Allow multiple users to use the application at the same time - Support the use of other information sources

Thesis Vincent Verheggen | Recommendations

During this research, six interviewees were spoken to at length. Although the aim of the interviews was to uncover problems with verification and examine the use of AR as a solution, the interviewees often came up solutions outside the scope of this research. The following aspects need to be taken into account according to the interviewees:

- Focus on functional requirements rather than technical requirement. Functional requirements do to a greater extent represent the voice of the client. - When taking technical requirements into account focus on the ‘one of a kind’ situations. Client The client can also make some improvement in the way he communicates the requirements: - Provide only necessary requirements. Currently, numerous requirements are provided that do not contribute to the technical solution but require considerable amount of time. o Some functional requirements are too functional and wide to contribute to the technical solution. These are the requirements that can be found at the top of the requirement tree. It is assumed that these functional requirements serve as structure for the technical requirements. They provide the design of the output specification. It is possible that these requirements are copied from other projects. These wide and functional requirements can lead to technical requirements that do not cover the intention of the client. Make sure to minimalize the number of these requirements o Multiple technical requirements are provided. It is assumed that these requirements are provided as there is a distrust between the client and contractor. These requirements provide logic constraints. An example is that the client communicates in a requirement that the hand needs to be ‘firm enough’ to use. - The client should clearly describe the context along with the requirement to the contractor. Decisions made by the client that are laid at the basis of the technical requirements should be communicated to the contractor. By doing this, the contractor can come to the expected technical solution. - Clarify the relation between the requirements. Currently, the relation is only visible by a unique identification number. By making the relation more explicit, a contractor knows which requirements influence each other. The relation with other requirements can be seen as a form of context.

100

Thesis Vincent Verheggen | Recommendations

6.2 Further research

There are two recommendations for further research. These are:

- Research the use of AR for interface review. In this research project, the decision was made to focus on the application ‘AR for design review’, as this method improved the readability of the supporting document for people unfamiliar with these documents. Another application that can be used for verification with respect to functional product requirements in the development phase is the application ‘AR for interface review’ (§2.6.5). This application is also interesting as it allows people to see the design in its environment in the development phase. Other applications of AR can be applied in later phases and therefore have limited effect on managing the expectations of the client. - Research how expression can be communicated with AR. In Chapter 4 of this thesis two recommendations are done. Firstly, it is recommended to use a Head mounted display (HMD) instead of a tablet or mobile phone. An HMD has the advantage that the user can freely use his hands and feet’s. The second recommendation which is done in Chapter 4 concerns the use of AR with multiple persons at the same time. It is argued that the users can communicate easier when they can communicate non-verbal. These recommendations are in some way contradictory. A HMD allows the user to move freely, but the use of a HMD decrease the ability to analyse the behaviour of the other observers as the eyes are covered. It is therefore recommended to find a way to use AR and still be able to see the eyes of the other observers. A possible solution is a high tech iris lens. Research can be done to the possibilities and advantages that come with an AR iris lens.

101

Thesis Vincent Verheggen | Recommendations

102

Thesis Vincent Verheggen | Reference list Reference list

Abboud, R. (2014). Opportunities and Obstacles for Mobile AR in Design, Construction, and Post-Completion. (Scholarship thesis), NAWIC International Women’s Day Scholarship Recipient 2013. Adams, C. (2016). What are the four fundamental methods of requirement verification? Retrieved from http://www.modernanalyst.com/Careers/InterviewQuestions/tabid/128/ID/1168/Wh at-are-the-four-fundamental-methods-of-requirement-verification.aspx Ahohen, T. (2012). AR the 8th mass medium. Retrieved from https://www.youtube.com/watch?v=EvyfHuKZGXU Amice (Vereniging voor oud KMA KLU officieren). (2014). Introductie extended systems engineering methodiek. AR for Enterprise Alliance (AREA). (2015). BOSH annouces expanded suppot for augmented reality in automotive service, repair and training Retrieved from http://thearea.org/bosch-announces-expanded-support-for-augmented-reality-in- automotive-service-repair-and-training/ Augment. (2016). About Augment. Retrieved from http://www.augment.com/about-us/ Azuma, R., Baillot, Y., Behringer, R., Feiner, S., Julier, S., & MacIntyre, B. (2001). Recent advances in augmented reality. Computer Graphics and Applications, IEEE, 21(6), 34-47. Behzadan, A. H., & Kamat, V. R. (2005). Visualization of construction graphics in outdoor augmented reality. Paper presented at the Proceedings of the 37th conference on Winter simulation. Bell, J. (2014). World uses for augmented reality Retrieved from https://www.theprimacy.com/blog/finally-4-real-world-uses-for-augmented-reality/ Belzen, T. v. (2014, November 25). Weer ict-problemen tunnel. Cobouw. Retrieved from http://www.cobouw.nl/artikel/1026441-weer-ict-problemen-tunnel Berg, M. v. d. (2016, January 21) Orientation interview/Interviewer: V. Verheggen. Bobrich, J., & Otto, S. (2002). Augmented maps. International Archives of Photogrammetry Remote Sensing and Spatial Information Sciences, 502-505. Bouchlaghem, D., Shang, H., Whyte, J., & Ganah, A. (2005). Visualisation in architecture, engineering and construction (AEC). Automation in construction, 14(3), 287-295. Bouw Informatie Raad (BIR). (2015). BIM marktdag: Samenwerkken in BIM - Liever vandaag dan morgen. Retrieved from http://www.bouwinformatieraad.nl/2015/11/ Brekelmans, S. (2016, April 18). Systems engineering: stop de verkramping. Cobouw. Retrieved from http://www.cobouw.nl/artikel/1626966-systems-engineering-stop- de-verkramping Chin, R. (2013). Now available: eDrawings for iOS with Augmented Reality. Retrieved from http://blogs.solidworks.com/solidworksblog/2013/02/augmented-reality-in- edrawings.html Cote, S. (2012). Augmented reality for subsurface utilities: further improving perception. Retrieved from http://communities.bentley.com/other/old_site_member_blogs/bentley_employees/ b/stephanecotes_blog/archive/2012/06/18/augmented-reality-for-subsurface- utilities-further-improving-perception Cowork Company. (2016). Mobiele Augmented Reality. Retrieved from http://www.slideshare.net/squio/mobiele-augmented-reality De Oliveira, M. C. F., & Levkowitz, H. (2003). From visual data exploration to visual data mining: a survey. Visualization and Computer Graphics, IEEE Transactions on, 9(3), 378-394. Defense Acquisition Guidebook. (1999). Product verification requirements for launch, upper stage, and space vehicles MIL-STD-1540D.

103

Thesis Vincent Verheggen | Reference list

Dimitriou, H. T., Ward, E. J., & Wright, P. G. (2013). Mega transport projects—Beyond the ‘iron triangle’: Findings from the OMEGA research programme. Progress in planning, 86, 1-43. Dong, S., Behzadan, A. H., Chen, F., & Kamat, V. R. (2013). Collaborative visualization of engineering processes using tabletop augmented reality. Advances in Engineering Software, 55, 45-55. Egan, J. (1998). Rethinking Construction, Construction Task Force Report for Department of the Environment, Transport and the Regions: HMSO, London. Elgohari, T. (2015). The integration between 4D simulation, Mobile technology and Augmented reality for automating construction progress monitoring and communication. Retrieved from https://www.linkedin.com/pulse/integration- between-4d-simulation-mobile-technology-reality-elgohari Fellows, R. F., & Liu, A. M. (2015). Research methods for construction: John Wiley & Sons. Flyvbjerg, B. (2006). Five misunderstandings about case-study research. Qualitative inquiry, 12(2), 219-245. Green, E. (2016). Using Augmented Reality for Construction. Retrieved from http://www.engineering.com/BIM/ArticleID/11473/Using-Augmented-Reality-for- Construction.aspx Hekkert, P., Snelders, D., & Wieringen, P. C. (2003). ‘Most advanced, yet acceptable’: Typicality and novelty as joint predictors of aesthetic preference in industrial design. British journal of psychology, 94(1), 111-124. Hertogh, M. J. C. M., & Westerveld, E. (2010). Playing with complexity. Management and organisation of large infrastructural projects: AT Osborne/Transumo. Imbrechts, P. (Producer). (2016). SE + BIM = integrated BIM. Retrieved from http://ie- academie.be/sites/ie-academie.be/files/uploads/5_peter_imbrechts_infranea.pdf INCOSE. (2011). Systems Engineering Handbook. International Council on Systems Engineering (INCOSE), 1-384. ISO 15288. (2008). ISO 15288 Systems engineering International Standards Organisation. Jong INCOSE. (2016a). Niewsbrief, 2e jaargang, editie 1. In J. INCOSE (Ed.). Jong INCOSE. (2016b). Niewsbrief, 2e jaargang, editie 2. In J. INCOSE (Ed.). Kamara, J. M., Anumba, C. J., & Evbuomwan, N. F. O. (2002). Capturing client requirements in construction projects: Thomas Telford. Kamat, V. R., & Martinez, J. C. (2001). Visualizing simulated construction operations in 3D. Journal of computing in civil engineering, 15(4), 329-337. Kennisplatform Tunnelveiligheid. (2016). 9 en 23 maart 2016: bijeenkomsten Virtueel testen. Retrieved from http://www.kennisplatformtunnelveiligheid.nl/bijeenkomsten/106-23-maart-2016- 2e-sessie-bijeenkomst-virtueel-testen Klein, K. J., & Sorra, J. S. (1996). The challenge of innovation implementation. Academy of management review, 21(4), 1055-1080. Kroll, M. (2016). AR: A new way to learn! Retrieved from https://extension.org/2016/06/27/ar-a-new-way-to-learn/ Kuiken, A. (2012, January 18). Tunnel A2 bij Utrecht gaat in februari eindelijk open. Trouw. Retrieved from http://www.trouw.nl/tr/nl/4492/Nederland/article/detail/3126658/2012/01/18/Tunnel- A2-bij-Utrecht-gaat-in-februari-eindelijk-open.dhtml Latham, M. (1994). Constructing the team: final report of the government/industry review of procurement and contractual arrangements in the UK construction industry: HMSO, London. Lawson, S. W., & Pretlove, J. R. (1998). Augmented reality for underground pipe inspection and maintenance. Paper presented at the Photonics East (ISAM, VVDC, IEMB).

104

Thesis Vincent Verheggen | Reference list

Leeuw, A. d. (1990). Een boekje over bedrijfskundige methodologie: management van onderzoek. Assen/Maastricht: Van Gorcum. Léon van Berlo, & TNO (Producer). (2011). BIM and Augmented Reality on the construction site: a future perspective. Retrieved from https://www.youtube.com/watch?v=9oxPIlowgVE Leonard, J. (1999). Systems engineering fundamentals: DTIC Document. Leswing, K. (2015). Microsoft HoloLens hands on: It’s early, but it’s already nifty. Retrieved from https://gigaom.com/2015/01/21/microsoft-hololens-hands-on-its- early-but-its-already-nifty/ Magnani, M. (2010). Flash Augmented Reality Demo With Multiple Markers. Retrieved from https://www.youtube.com/watch?v=HfaGih85ZJg Mahdavi, A., Martens, B., & Scherer, R. (2014). eWork and eBusiness in Architecture, Engineering and Construction: ECPPM 2014: CRC Press. Mihai. (2014). World’s First Augmented Reality Architecture Application : Sara. Retrieved from http://freshome.com/2010/01/19/world%E2%80%99s-first-augmented-reality- architecture-application-sara/ Milgram, P., & Kishino, F. (1994). A taxonomy of mixed reality visual displays. IEICE TRANSACTIONS on Information and Systems, 77(12), 1321-1329. NASA. (1995). NASA systems engineering handbook: Books Express Publishing. NASA. (2007). NASA systems engineering handbook Books Express Publishing. Navab, N. (2004). Developing killer apps for industrial augmented reality. IEEE Computer Graphics and Applications, 24(3), 16-20. Oxford University press. (2016). Oxford Reference. Retrieved from http://www.oxfordreference.com/view/10.1093/acref/9780199539536.001.0001/acr ef-9780199539536-e-1936 Part, E. (1986). Form and Style for ASTM Standards. Philadelphia: American Society for Testing and Materials. PIANOo. (2015). Vraagspecificaties in de GWW. Retrieved from https://www.pianoo.nl/markten/gww/inkopen-gww/vraagspecificaties-in-gww PIANOo. (2016). Specificeren. Retrieved from https://www.pianoo.nl/inkoopproces/fase- 1-voorbereiden-inkoopopdracht/specificeren Piekarski, W., & Thomas, B. H. (2002). The tinmith system: demonstrating new techniques for mobile augmented reality modelling (Vol. 24): Australian Computer Society, Inc. Postumes, N. (2012, January 18). Tunnel A2 gaat eindelijk open - rijd er virtueel alvast doorheen. NRC. Retrieved from http://www.nrc.nl/nieuws/2012/01/18/tunnel-a2- gaat-eindelijk-open-rijd-er-virtueel-alvast-doorheen-a1448529 Quay, A. (2013). IKEA Augmented-Reality 2014 Catalog Lets You See Furniture In Your Home. Retrieved from http://designtaxi.com/news/359753/IKEA-Augmented- Reality-2014-Catalog-Lets-You-See-Furniture-In-Your-Home/ Raskar, R., Welch, G., & Chen, W.-C. (1999). Table-top spatially-augmented realty: bringing physical models to life with projected imagery. Paper presented at the Augmented Reality, 1999.(IWAR'99) Proceedings. 2nd IEEE and ACM International Workshop on. Rijksoverheid. (2016). MIRT gebieden: A1/A6/A9 Schiphol-Amsterdam-Almere. Retrieved from http://mirt2016.mirtoverzicht.nl/mirtgebieden/project_en_programmabladen/402.as px Rijkswaterstaat. (2007). Leidraad voor Systems Engineering binnen de GWWSector (Vol. 1). Rijkswaterstaat. (2009a). Leidraad voor Systems Engineering binnen de GWWSector (Vol. 2). Rijkswaterstaat. (2009b). Werkwijzebeschrijving 000444 Verificatie en Validatie. Rijkswaterstaat. (2011). Functional specification guide.

105

Thesis Vincent Verheggen | Reference list

Rijkswaterstaat. (2013). Leidraad voor Systems Engineering binnen de GWWSector (Vol. 3). Rijkswaterstaat. (2014). Stappenplan van projectopdracht tot Vraagspecificatie. In Rijkswaterstaat (Ed.), SE voor RWS projecten. Rijkswaterstaat. (2016a). A1/A6/A9/A10 Schiphol-Amsterdam-Almere. Retrieved from http://www.rijkswaterstaat.nl/wegen/projectenoverzicht/a9-a10-a1-a6-schiphol- amsterdam-almere/index.aspx Rijkswaterstaat. (2016b). A1/A6: Diemen – Almere Havendreef. Retrieved from http://www.rws.nl/wegen/projectenoverzicht/a1-a6-diemen-almere- havendreef/index.aspx Robinson, S. (1997). Simulation model verification and validation: increasing the users' confidence. Paper presented at the Proceedings of the 29th conference on Winter simulation. Rogers, E. M. (2010). Diffusion of innovations: Simon and Schuster. Rohrer, M. W. (2000). Seeing is believing: the importance of visualization in manufacturing simulation. Paper presented at the Proceedings of the 32nd conference on Winter simulation. Rook, P. (1986). Controlling software projects. Software Engineering Journal, 1(1), 7. SAAone. (2015). Deelmanagement plan/PVA V&V SAAone. SAAone. (2016a). SAAone. Retrieved from http://www.saaone.com/SitePages/SAAone.aspx SAAone. (2016b). Welkom op de website van SAAone. Retrieved from http://www.saaone.com/SitePages/Home.aspx Saaty, T. L., & Beltran, M. (1980). Architectural design by the analytic hierarchy process. Design Methods and Theories, 14(3/4), 124-134. Sargent, R. G. (1991). Simulation model verification and validation. Paper presented at the Proceedings of the 23rd conference on Winter simulation. South-Easy European Research Centre (SEERC). (2010). Single and Multiple-Case Study Designs IS493 1. Retrieved from http://www.seerc.org/dsc2010/misc/Single_and_Multiple_Case_Study_Designs.pdf STUMICO (vereniging voor ICT in de bouw). (2016). Virtual + augmented reality (workshop). Retrieved from http://www.stumico.nl/agenda-info/virtual-augmented- reality/ Stuurgroep 4P Systems Engineering. (2009). Verificatie & Validatie - Evaluatie, projectervaringen rondom het V&V-proces. The Architecture, E. a. C. A. M. P. (2011). How Augmented Reality Can Change Our Industry. Retrieved from http://aecmarketingprogressive.blogspot.nl/2011/03/how- augmented-reality-can-change-our.html Van Krevelen, D., & Poelman, R. (2010). A survey of augmented reality technologies, applications and limitations. International Journal of Virtual Reality, 9(2), 1. Verschuren, P. J. M., & Doorewaard, H. (2010). Designing a research project (Vol. Second edition,): Lemma. Volker Wessels. (2016). Projecten: SAAone. Retrieved from http://www.volkerwessels.com/nl/projecten/detail/saaone Wasson, C. S. (2006). System Analysis, Design, and Development: Wiley interscience. Zünd, F., Ryffel, M., Magnenat, S., Marra, A., Nitti, M., Kapadia, M., . . . Sumner, R. W. (2015). Augmented creativity: bridging the real and virtual worlds to enhance creative play. Paper presented at the SIGGRAPH Asia 2015 Mobile Graphics and Interactive Applications.

This reference list is based on the guidelines mentioned on the following webpage: http://tulib.tudelft.nl/wp-content/uploads/2012/10/Citation-table8.pdf

106

Thesis Vincent Verheggen | Appendix A: Orientation Appendix A: Orientation

Prior to the main research, several people are spoken to understand the Verification and Validation (V&V) processes and the problems that are involved in these processes. In addition to the orientation interviews five events of various groups are visit to learn about V&V and Augmented Reality (AR).

Orientation interviews

Table 13 provide the names of the interviewees. The interviews are conducted prior to the case study and interviews with experts.

Table 13: Names of the interviewees of the orientation interviews

# Name Company Date interview Place interview 1 SAAone 19-2-2016, 28-4- Project office SAAone, (Designmanager) 2016, 4-5-2016, Diemen 2 Volker Wessels Infra 21-1-2016 Restaurant Hema, Gouda Design 3 SAAone 5-11-2015 Company office Hochtief, Diemen 4 Hochtief Germany 21-12-2016 Company office Hochtief, Essen, Germany 5 Semmtech 15-1-2016 Company office Semmtech, Hoofddorp 6 RWS 14-1-2016 Company office RWS, Utrecht 7 RWS 14-1-2016 Company office RWS, Utrecht 8 RWS/Balance 7-4-2016 Company office Balance, Rotterdam 9 SAAone (surrounding 21-1-2016 Project office SAAone manager) Office, Diemen 10 Infranea/Neanex 16-3-2016, 7-4- Aula, TU Delft, Delft 2016 11 SAAone (lightning 15-3-2016 Project office SAAone, engineer) Diemen 12 SAAone visualisation 10-5-2016 Project office SAAone, expert Diemen

Orientation events

Various events are visited in the orientation phase of this research. A list of the events and a description can be found below. The description is provided in Dutch.

Rijkswaterstaat: BIM Marktdag Op 20 november 2015 heeft Rijkswaterstaat een BIM-marktdag georganiseerd in Maarsen. Op deze dag waren bijna 300 directie- en managementleden van aannemers en ingenieursbureaus aanwezig (Bouw Informatie Raad (BIR), 2015).

De dag werd geopend met een interactieve plenaire sessie door Cees Brandsen en Herman Winkels (beide Rijkswaterstaat) en Patrick Buck en Johan Schouten (beide ProRail). In de middag was er de gelegenheid was om enkele workshops te volgen. De volgende workshops zijn bezocht:

107

Thesis Vincent Verheggen | Appendix A: Orientation

- Gluren bij de buren. Opdrachtnemers die al met een BIM-contract werken delen ervaring (Marc den Heijer van Ballast Nedam en Kenzo Oijevaar van Hochtief) - Hoe organiseren andere bouwbedrijven hun BIM-kennis? Wat doen de verschillende BIM-academies? - Uitwisseling van informatie op basis van open standaarden; hoe ziet RWS dat? Op deze dag bleek dat BIM steeds meer neigt naar Informatiemanagement. Waar voorheen het visuele aspect van BIM een belangrijke rol speelde kan er nu ‘ge-BIM t’ worden zonder visueel model. De raakvlakken tussen BIM en SE worden kleiner.

INCOSE-NL: SE-implementatie in de organisatie Op 15 december 2015 heeft Jong INCOSE een avondlezing van INCOSE-NL verzorgd. Hiervoor is Miranda van Ark bereid gevonden om haar visie te geven op de implementatie van SE. Miranda van Ark, bekend van de 3e versie van de Leidraad voor SE en het KIES traject binnen ProRail, sprak vanuit haar haar brede ervaring bij implementatietrajecten (Jong INCOSE, 2016a).

KPT (Kennis platform Tunnelveiligheid): Themabijeenkomst Virtueel testen Op 23 maart 2016 werden er bij Movares in Utrecht presentaties gegeven over virtueel testen in tunnels. De presentaties werden gegeven in samenwerking met de bedrijven COB, Movares, Soltegro en Altran. De marktpartijen presenteerden hier enkele opstellingen voor virtueel testen en er werden demonstraties gegeven. De presentaties en demonstraties gaven voldoende stof tot het voeren van een discussie na afloop van het evenement (Kennisplatform Tunnelveiligheid, 2016).

Jong INOCSE: Themabijeenkomst raakvlakken BIM & SE Dinsdag 10 mei 2016 is door Jong INCOSE een themabijeenkomst georganiseerd genaamd: ‘BIM en SE: de raakvlakken en verschillen’. De bijeenkomst werd bezocht door circa 30 jonge professionals. Na de aftrap, waar BIM vanuit het oogpunt van Arcadis en Rijkswaterstaat werd toegelicht, startte het interactieve gedeelte van de bijeenkomst. In groepjes werden de raakvlakken en verschillen tussen BIM en SE besproken. Conclusie: BIM en SE kennen verschillen, maar hebben ook zeker veel raakvlakken (Jong INCOSE, 2016b).

STUMICO, Workshop VR & AR in de bouw Op 14 juni 2016 was er een workshop georganiseerd door de vereniging STUMICO (ICT in de bouw) over de toepassingen van Virtual Reality (VR) en Augmented Reality (AR). Tijdens deze workshop hebben enkele bedrijven hun kijk op ontwikkelingen kunnen toelichten en was er de mogelijkheid om enkele VR en AR-brillen te gebruiken waaronder de MS Hololens (STUMICO (vereniging voor ICT in de bouw), 2016).

Figure 60: Using VR and AR (MS Hololens) (image: P. Glaudemans)

108

Thesis Vincent Verheggen | Appendix B: Supporting documents Appendix B: Supporting documents This appendix provides several examples of requirements, the corresponding Verification (V) and the Verification Task (VT) (the judgement of the verifier).

Requirement: FN_00810

NL: Verzorgingsplaats dient verkeersveilig en schoon te zijn. ENG: The rest area needs to be safe for traffic and clean.

V-21041

Method: Document Inspection Workpackage: WPA-01953 | WPA (Ontwerp DO, Verzorgingsplaats Hackelaar (A1 noord)) How: Controle op tekening op verkeersveiligheid en op aanwezigheid afvalbakken Registration type: TEK – Tekening When: After final Design (Dutch: DO)

VT-21622 Description of the Verkeersveilig: voetgangers gescheiden van wegverkeer, verifier: oversteekplaatsen met zebrapad. Afvalbakken volgen in UO Supporting SAAONE-OWE-TEK-300091: Verzorgingsplaatsen DO document: ontwerp Hackelaar

Figure 61: SAAONE-OWE-TEK-300091: Verzorgingsplaatsen DO ontwerp Hackelaar.

It is difficult to distinguish the sidewalks from the road as both have the same colour. Distinguishing the sidewalks from the road is necessary as separated sidewalks and roads are mentioned in the aspects mentioned by the verifier.

In addition, it is difficult to find ‘bins’. They are not included in the legend of the document. Aspects mentioned in the requirement are not covered in the inscription of the document. Therefore, it can be concluded that this is made for other purposes than verification (e.g. construction purposes, legislation purposes, etc.).

109

Thesis Vincent Verheggen | Appendix B: Supporting documents

Requirement: VE_00751

NL: Kruisingen dienen ter plaatse van niveauverschillen voorzien te zijn van een leuning. Daarbij dient te worden voldaan aan de eisen zoals genoemd in de ROK. ENG: Crossings located at different levels should be equipped with a handrail. The requirements mentioned in the ROK needs to be followed up.

V-52274 Method: Inspectie Work package: WPA-04282 | Afbouw dek west Randelementen & Vandaalscherm - K068 (Uitvoeren randelementen (incl. leuning), K068 Havendreef excl. Taludbestrating en Stootplaten) How: Foto maken van aanwezigheid leuning en opmeten of de hoogte juist is. Registration type: ALG - Algemeen When: Na Realisatie

VT-53918 Description: Na plaatsing van het veiligheidsscherm incl leuning is er een foto gemaakt door de uitvoering. Supporting document: SAAONE-UCI-BEW-100136: Bewijsdocument leuningwerk K068 dek west (foto)

Figure 62: SAAONE-UCI-BEW-100136: Bewijsdocument leuningwerk K068 dek west

The proper height of the handrail is not mentioned in the verification nor during carrying out the verification (making the picture). In this photograph it is not clear what exactly the handrail is and the photograph does not display the height of the handrail and therefore cannot be used for verification.

110

Thesis Vincent Verheggen | Appendix B: Supporting documents

Requirement: VE_00751

V-68197 Method: Document Inspectie Work package: WPA-05217 | WPA (Ontwerp UO, Hollandse Brug over Gooimeer) How: Controle op aanwezigheid van leuning bij niveauverschil op tekening. Registration type: TEK – Tekening When: Na uitvoering en oplevering (UO)

VT-70181 Description: Op de tekening is te zien dat aan de buitenzijden de brug van leuningen is voorzien. Supporting document: SAAONE-OCD-TEK-300705, K059 - Overzicht lichtmasten en HWA

Figure 63: SAAONE-OCD-TEK-300705, K059 - Overzicht lichtmasten en HWA

It is difficult to discover the handrail on the construction plan as there are more sections presented. This plan is made for construction and not for verification purposes. It is difficult to discover different levels/heights in the drawing. It also unsure what can be seen as a ‘transition in heights’.

111

Thesis Vincent Verheggen | Appendix B: Supporting documents

Requirement: ER_01930

NL: Ecologische verbindingen dienen op de projectgrens zodanig op de omgeving te zijn aangesloten dat functies van de ecologische verbindingen projectgrensoverschrijdend kunnen worden uitgeoefend, zoals aangegeven in Hoofdstuk 9 van de Leidraad Faunavoorzieningen bij Infrastructuur, RWS/ProRail, Deel 3. ENG: Ecological connections around the project boundary have to connected to the surrounding area to allow ecological connectivity. This is specified in Chapter 9 of the Leidraad Faunavoorzieningen bij Infrastructuur, RWS/ProRail, Deel 3.

V-38722 Method: Document Inspectie Work package: WPA-02603 | WPA (Ontwerp DO, Landschappelijke inpassing) How: - Registration type: RAP - Rapport(age) When: Na Definitief Ontwerp (DO)

VT-39909 Description: Op de tekeningen is te zien dat op ecologische verbindingen over de projectgrenzen geen belemmerende objecten zijn voorzien. De doelsoorten kunnen via lijnvormige elementen (bomenrij, struweel, sloot) hun weg vervolgen. Ze worden door het gebied geleid. De functies van de ecologische verbindingen worden hierdoor gehandhaafd. Supporting SAAONE-OLI-ONO-100004: Integraal Inrichtingsplan - document: Deelgebied Hollandse Waterlinie en 6 andere documenten met dezelfde strekking maar voor een andere locatie.

Figure 64: One of the plans in SAAONE-OLI-ONO-100004: Integraal Inrichtingsplan - Deelgebied Hollandse Waterlinie.

The judgement of the verifier cannot be done with the renders/images presented in the design plan and presented above. It is expected that the verifier had contact with the designer or based his judgement on experience.

112

Thesis Vincent Verheggen | Appendix B: Supporting documents

Requirement: FN_02936

NL: De Infrastructuur RWS dient conform het "Bedienprotocol Wisselbaan SAA" te voorzien in wisselbaan berm DRIPs, één voorafgaand aan elke wisselbaantoegang, welke bij opening van de toegang de via de wisselbaantoegang te bereiken bestemmingen aangeeft. (DRIP = Dynamic Route Information Panel) ENG: Infrastructure RWS needs to be in accordance with the " Bedienprotocol Wisselbaan SAA " and have to include information panels for swap lanes on the side of the highway. One panel needs to be positioned in front of each swap lanes and have to indicate the lane destination.

V-37391 Method: Documentinspectie (2x) Work package: WPA-04966 | WPA (Ontwerp UO, Informatiepaneel (DRIP)) How: Check 1:1000 tekeningen en locaties opnemen in ontwerpnota. Registration type: ONO – Ontwerpnota en TEK - Tekening When: Na Uitvoering en Ontwerp (UO)

VT-38657 Description: Let op; naar aanleiding van UO2.0 is een aanvullende ontwerpnota SAAONE_ODV-ONO-300068 opgesteld waarin de aanpassingen tov UO1.0 zijn omschreven. Dit document staat boven de oorspronkelijke ontwerpnota. Zie paragraaf 4.3 (Plaatsbepaling) en tabel 3, waarin Bermdrips zijn opgenomen ten behoeve van de wisselbaan. De betreffende DRIPs zijn te vinden in kabelloop- / installatietekening SAAONE-ODV-TEK-300051, bladen 01, 04, 06, 14, 21 en 24 Supporting SAAONE-ODV-TEK-300051-2.0 Kabellooptekening document: Verkeers Systemen [SYS-UO-TEK-VS-04] en 25 andere documenten met dezelfde strekking maar een andere locatie.

Figure 65: SAAONE-ODV-TEK-300051-2.0 Kabellooptekening Verkeers Systemen [SYS-UO-TEK-VS-04]

The information panel is not visible on the construction plan. The information facilities are not mentioned in the inscription that is provided with the construction plan. It is expected that the construction plan is made for other purposes than verification.

113

Thesis Vincent Verheggen | Appendix C: Interviews Appendix C: Interviews

Selection of requirements

In order to test the use of AR during verification the interviewee had to judge 4 AR prototypes. Each of the prototypes belonged to a set of corresponding requirements. This sub-chapter describes the selection of the corresponding requirement. The selection of the requirements is done prior to the development of the 3D models.

The goal of the selection was to find a set of requirements that can, in combination with the virtual 3D model, be analysed during interviews for the use of verification.

Requirements are selected in 3 steps:

1. Selecting useful requirements 2. Grouping selected requirements according to their subject 3. Choosing one requirement of each group Figure 66 shows the selection process. The three steps taken during the process are described in detail below.

Figure 66: Selection of the example requirements

Step 1: Selecting useful requirements During step 1, a selection out of 750 requirements is made of all product requirements in the output specification of SAAone. The selection took place according to the following selection criteria:

- Requirements just above the transition from functional to technical - Vague/ambiguous requirements that lead to discussions - Requirements that deal with complex situations

114

Thesis Vincent Verheggen | Appendix C: Interviews

Functional and technical requirement provided by the client

Figure 67: Selection of functional requirements just above the transition from functional to technical

In Chapter 3 is described that functional requirements are important as they provide the ‘true voice of the client’. The expectation is that by managing the requirements around the transition from functional to technical, derived technical requirements are managed indirectly. Figure 67 illustrates the position of the chosen requirements.

There are a few exceptions:

- Requirements about non-visible properties are not selected - Requirements about maintenance related aspects are not selected The reason that requirements with these characteristics where not chosen is that it is expected by forehand that corresponding AR prototypes are impossible. For example, the traffic noise, an invisible property, is difficult to express with the AR tool used. From the 750 requirements 110 requirements met the criteria given above.

Step 2: Grouping the selected requirements according to their subject The selected requirements were grouped the following four groups:

1. Signalling; 2. Design; 3. Positioning; 4. Systems. Step 3: Choosing one requirement of each group From each group one requirement is selected.

Table 14 shows the selected requirements. Note that next to the functional requirement, a more technical requirement is provided. The reason for this is that requirements are not entirely functional or technical but requirements gradually transform from functional to technical.

115

Thesis Vincent Verheggen | Appendix C: Interviews

Making the prototypes

Several steps are taken in order to develop the four prototypes that match the requirements:

1. Developing the virtual 3D model 2. Adding an animation to the virtual 3D model (optional) 3. Adjusting the supporting document 4. Selection of the marker 5. Link the marker and the virtual 3D model 6. Download the application and verify the working The steps will be described below:

1. Making the virtual 3D model AR shows augmented information. The chosen AR application, AR-TTM uses virtual 3D models. Therefore, the first step taken is retrieving a 3D model that provides insight in the situation sketched in the requirement.

In first instance it is logic to use the 3D model of SAAone. SAAone worked out several aspects of the design in 3D. In general, SAAone uses several different 3D models that differ in the degree of detail. Some accurate models are used for construction purposes. Other models are used for visualisation purposes. These models are stripped down versions of the model used for construction.

t appears to be difficult to derive a model for the AR-TTM out of a 3D model of SAAone. When using this application, the 3D model needs to fit exactly over the 2D construction plan. The models of SAAone is bigger in size compared to the 2D construction plan. To be able to use the SAAone model, modification is required.

Additionally, the SAAone models including the visualising were too heavy to run on the AR software.

Therefore, the choice is made to make a replica of the required aspect based on the models with the software Sketch up. This software, developed by Google, allows the user to draw quick and simple 3D object. An example of a finished 3D model made in Sketch up can be seen in Figure 68. Once the 3D model was made, it was saved as obj. file and uploaded on the Augment sever.

Figure 68: Drawing the 3D model in the software sketch up

116

Thesis Vincent Verheggen | Appendix C: Interviews

2. Adding an animation to the 3D model (optional) An option is to add animations to a virtual 3D model. You can then, for example, analyse the working of an engine or the closing procedure of a safety barrier. To add animation, the 3D model is imported in the software MA3D that supports the use of animations. After the animation is added the model is saved as obj. file.

3. Adjusting the supporting document In this third step, modifications are made on the supporting document that is used by the verifier. The scale of the plan is increased with the help of the software Photoshop.

During tests prior to the interviews appeared that the objects, described in the requirements, where sometimes not visible on the plan. Therefore, the AR-TTM application was not able to scan marker. Figure 69 illustrates that a supporting document is scaled up so that the object described in the requirement, in this case road signs, can be scanned with the AR application.

Figure 69: Scale and amplify the supporting document for traceability

4. Deriving the marker from supporting document An area within the supporting document is selected to function as a marker. This can be seen in Figure 70.

Figure 70: A part of the supporting document that serves as marker for AR-TTM

Just as the virtual 3D model from step 1, the marker is uploaded on the Augment server.

117

Thesis Vincent Verheggen | Appendix C: Interviews

5. Link the marker and the 3D model The Augment application enables the user to link the marker to the virtual 3D model. This can be done on an online platform of Augment.

6. Download the application and verify the working The last step is to download the Augment software for the AR device. The application is available for IOS and Android. After the application is downloaded it is necessary to check if the Augment application recognises the marker and presents the chosen model. Also, it is necessary to verify if the 3D model presented on top of the marker has the right scale and position. In Figure 71 can be seen that the marker, in this case part of a construction plan, is scanned whereafter the 3D model can be analysed with a tablet.

Figure 71: Scan the marker and analyse the 3D model on top of the marker

118

Thesis Vincent Verheggen | Appendix D: Interview protocol Appendix D: Interview protocol

- Toelichting in welk kader het interview plaatsvindt, - Het onderwerp van mijn afstuderen nader toelichten, - Vraag hoeveel tijd de informant heeft, - Vraag toestemming voor opnamen van het gesprek.

- Leg uit: Dit interview bestaat uit 2 delen:

1. Verificatie momenteel 2. Verificatie met Augmented Reality

Introductie

In dit deel wordt de respondent gevraagd naar zijn ervaring met betrekking tot verscheidende onderwerpen zoals V&V en AR. Dit deel is oriënterend van aard. Het doel van dit deel is de respondent leren kennen. Aan de hand van de antwoorden van de respondent kan het interview in deel 2 en 3 worden bijgestuurd. Ook kan de betrouwbaarheid van de antwoorden in deel 2 en 3 bepaald worden aan de hand van de antwoorden in dit deel.

Vragen die aan bod kunnen komen zijn:

Achtergrond - Wat is uw functie? - In welke sector werkt u voornamelijk actief? - Hoeveel jaar werk ervaring heeft u?

Kennis en ervaring m.b.t. onderwerpen thesis - In hoeverre bent u bekent met het verificatie proces? - In hoeverre bent u bekent met AR? o Welke toepassingen van AR zijn bij u bekend? o Ziet u AR als onderdeel als een visueel middel dat gebruikt kan worden voor communicatie?

Naar gelang de respondent de vragen positief beantwoord kan er verder worden doorgevraagd. Vragen als: ‘kunt u hier meer over vertellen?’, ‘kun je daar een voorbeeld van geven?’ en ‘wat bedoelt u precies daarmee?’ zijn hiervoor mogelijke vragen. Dit deel van het interview heeft in tegenstelling tot deel 2 en 3 een meer open karakter.

119

Thesis Vincent Verheggen | Appendix D: Interview protocol

Deel 1: Het verificatie proces

In dit deel wordt de respondent gevraagd om uit te leggen hoe het verificatie proces in zijn werk gaat. Het voornaamste doel van dit deel is om het probleem, beschreven in Hoofdstuk 1, te onderbouwen en informatie verkregen uit de eerder gedane document inspectie (Hoofdstuk 2) te verrijken met praktische kennis uit Hoofdstuk 3. Dit deel heeft in tegenstelling tot Deel 1 een meer gestructureerd karakter.

De vragen zijn:

Eisen

- Hebben eisen in de output specificatie een meer technisch of een meer functioneel karakter? Waar kan je dit aan herkennen? - Waarom wordt er functioneel en waarom wordt er technisch gespecificeerd? - Welke eisen zijn lastig aan te tonen? - Is het bij het achterliggende doel van de eis altijd duidelijk?

Verificatie

- Hoe verloopt het verificatie proces? - Wat zijn de problemen in het verificatie proces? - Hoe werden de problemen veroorzaakt? - In hoeverre zijn de problemen gelieerd aan functionele eisen? - Wat wordt er gedaan om problemen omtrent verificatie op te lossen? - Wat is het gevolg van de aanpassingen?

- Waar ligt de nadruk in het verificatie proces? - Welke methodes worden er gebruikt voor verificatie? - Zijn er methodes die vaker voorkomen dan anderen? - Waarom wordt document inspectie vaak gedaan aan de hand van constructietekeningen? - Is het mogelijk om verificatie te doen met andere visuele middelen dan een 2D constructietekening? Zo ja, welke visuele middelen zouden kunnen helpen in het verificatie proces? - Kan verificatie gedaan worden met een 3D model op de computer? Waarom wel of waarom niet?

120

Thesis Vincent Verheggen | Appendix D: Interview protocol

Deel 2: Verificatie met Augmented Reality

In dit onderdeel past de expert zijn kennis en ervaring toe. Het doel van dit deel is meer inzicht verkrijgen in de mogelijkheden van de AR ‘table top modelling tool’ voor product V&V.

Alvorens ingegaan wordt op AR-TTM wordt de informant een indruk gegeven over de toepassing van de AR ‘table top modelling tool’ voor V&V van product eisen. Er worden 4 AR-voorbeelden (prototypes) getoond bij 4 voorbeeld eisen. Deze vier voorbeeld eisen hebben allen een onderliggende, afgeleide eis die meer technisch van aard is. De volgende eisen, en afgeleide eisen, worden gebruikt.

Table 14: Four requirements and derived requirements that are part of the AR-TTM-prototypes.

# Categorie Nummer Eisen tekst 1 Signalering FN_00599 Alle ingangen van de wisselbaan dienen voorzien te zijn van een VEVA met aan beide zijden hiervan een afsluitboom ("afrijboom en aanrijboom"). FN_00766 De afsluitboom dient de gehele ingang af te kunnen sluiten, zodat het niet mogelijk is om langs gesloten afsluitbomen te rijden. 2 Vormgeving VG_00089 Infrastructuur RWS dient te voldoen aan het Ambitiedocument Vormgeving. E-07327 Waar mogelijk dienen schakelkasten van het Wisselbaan Verkeerssysteem samengevoegd te worden met schakelkasten van andere systemen. Het naast elkaar plaatsen van schakelkasten van verschillend formaat of kleur mag niet voorkomen. 3 Positionering FN_00420 De Bewegwijzering dient weggebruikers te informeren over de te kiezen en te nemen route, conform Richtlijn bewegwijzering CROW 222, Richtlijn toeristische bewegwijzering CROW 262 en Nieuwe Bewegwijzering Autosnelwegen OR_03286 Op de locatie A9 4.377Re en A9 4.164zRe dient Haarlem " boven "Schiphol" opgenomen te worden op de bewegwijzering van de wisselbaan. 4 Regeltechniek FN_02018 De Infrastructuur RWS dient actuele beelden in te winnen ten behoeve van het schouwen van de wisselbaan door de VC. FN_02983 Alle camera's voor het schouwen van het open te stellen deel van de wisselbaan dienen bij het schouwen in de rijrichting van het open te stellen deel gericht te zijn. *VEVA = moving barrier (Dutch: verplaatsbare vangrail)

De volgende vier modellen worden getoond bij de bovenstaande eisen d.m.v. AR ‘top modelling tool’.

121

Thesis Vincent Verheggen | Appendix D: Interview protocol

Onderstaande afbeelding laat zien welke vier AR-modellen de respondent te zien krijgt via AR-TTM. Het beeld in de afbeelding kan de respondent waarnemen via een tablet.

1 2

3 4

Figure 72: AR prototypes that belong to requirements FN_00599, VG_00089, FN_00420, FN_02018

De intentie van de eisen en bijbehorende AR-modellen, is de informant een indruk geven over de mogelijkheden die de AR ‘table top modelling tool’ te bieden heeft bij verificatie van product eisen. In een bredere context is er de intentie om de respondent te laten zien wat nieuwe visuele technieken kunnen doen bij verificatie. De voorbeelden bieden een oriëntatiepunt bij het beantwoorden van de onderstaande vragen. Ook kunnen de voorbeelden een discussie over de toekomstige mogelijkheden van de AR ‘table top modelling tool’ voor V&V faciliteren.

- Draagt AR (en specifiek de ‘table top modelling tool’) bij aan het beter begrijpen van informatie? - Denkt u dat AR (en specifiek de ‘table top modelling tool’) gebruikt kan worden voor verificatie van product eisen? - Voorziet u voor-of nadelen bij het gebruik van de AR (en specifiek de ‘table top modelling tool’) voor verificatie van product eisen? - Zijn er specifieke eisen waar AR (en specifiek de AR ‘table top modelling tool’) extra tot zijn recht komt in het verificatie proces? (  Hoog/laag, type eis, type object) - Wat zijn voordelen of nadelen van verificatie met AR (en specifiek de ‘AR table top modelling’) vergeleken met verificatie met behulp van het 3D model?

122

Thesis Vincent Verheggen | Appendix E: Summery transcriptions interviews Appendix E: Summery transcriptions interviews

The summaries of the transcriptions are written in Dutch. The entire transcription and audio files can be provided by the author of this thesis.

Interview met persoon A

Deel 1  Achtergrond: o Ontwerpleider SAAone o Meer dan 5 jaar werkervaring o Verantwoordelijk voor uitvoeren werkpakket integraal ontwerp  Kennis m.b.t. verificatie en Augmented Reality (AR): o Veel kennis van het verificatie proces. Autoriseert verificaties o Veel kennis van nieuwe technieken zoals AR. Lid STUMICO

Deel 2  Huidige problemen in het verificatie proces zijn: o Verwijzing naar externe richtlijnen of normen o Verwijzing naar meerdere bewijsdocumenten o Verschillende interpretatie van eisen door verschil in kennis en ervaring van stakeholders in het V&V-proces o Informatie is niet altijd makkelijk aan objecten te koppelen o Veel papierwerk o Vaak document inspectie als verificatie methode o Documenten lastig te interpreteren voor niet experts o Achterliggende doel van een (technische) is vaak niet gegeven o Vooraf opgedane kennis (door de OG) wordt niet doorgegeven aan de ON

Deel 3  Voordelen bij het gebruik van AR-TTM bij Verificatie en Validatie (V&V): o Het ontwerp wordt realistischer o Je beleeft het ontwerp (“beleving”) o Interactie is mogelijk o Navigeren met de handen en voeten draagt bij aan vrijheid o Makkelijk om technische informatie te delen met niet technici  Potentie van AR-TTM voor ontwerp validatie bij: o Eisen die betrekking met raakvlakken hebben (werd in deel 1 genoemd) o Eisen die betrekking hebben op vormgeving  Problemen bij het toepassen van AR-TTM voor V&V zijn: o Ontbreken van een goed referentiepunt (werd in deel 1 genoemd) o De omvang/grootte van het model (MB`s) (werd in deel 1 genoemd) o Schaalgrote van infra projecten, Schaalgrote op de tekening is klein met als gevolg een klein model wat lastig te analyseren is

123

Thesis Vincent Verheggen | Appendix E: Summery transcriptions interviews

o Bij het weergeven van één object (bijvoorbeeld portaal) mis je de raakvlakken o Voor verificatie moet de informatie waarop de beslissing gemaakt is beschikbaar blijven. AR zou hiervoor te dynamisch kunnen zijn o Klant is huiverig voor nieuwe technieken

Interview met persoon B

Introductie  Achtergrond: o Voormalig contractmanager RWS o Meer dan 5 jaar werkervaring o Verantwoordelijk voor opstellen contracten  Kennis m.b.t. verificatie en Augmented Reality (AR): o Gemiddelde kennis van het verificatie proces o Weinig kennis van nieuwe technieken zoals AR

Deel 1  Huidige problemen in het verificatie proces zijn: o Er wordt functioneel gespecificeerd op zo`n manier dat er maar een technische oplossing mogelijk is. o Te veel focus op technische eisen. Men vergeet het overkoepelende doel. o De ON is niet bekent met het achterliggende doel van de eis o De verwachting wordt niet goed gecommuniceerd in de eisen o Veel tijd en papier werk o De OG-schets niet altijd zijn behoefde goed. Er moet worden uitgegaan dat de ON zijn behoefte goed geschetst heeft in het contract.

 Technisch specificeren heeft te maken met het afdekken van het risico dat de ON iets anders realiseert. Functionele eisen worden gebruikt om te voorkomen dat de OG iets vergeet. Vaak wordt er dus een mix gegeven van functionele eisen én technische eisen.  Context wordt niet gecommuniceerd omdat: o De OG bang is dat er aan informatie verscheidende rechten kunnen worden ontleend, o De OG is niet zeker of de informatie klopt. o De OG weet niet welke informatie de ON nodig heeft. o De korte tijd waarin de OG veel informatie moet overdragen aan de ON,  V&V gebeurt voornamelijk gedurende ontwerp, uitvoering, en opleverdossier

Deel 2  Potentie van AR Table Top Modelling (TTM) bij Verificatie en Validatie (V&V) o Bij het in beeld brengen van extra en specifieke informatie, o Interessant voor validatie, eisen die je in een 3D/BIM-model zou kunnen aantonen zou je ook kunnen aantonen met AR-TTM. Denk aan eisen die betrekking hebben op ruimte of vormgeving.  Een onderliggende eis is er omdat de bovenliggende eis te vaag is. De bovenliggende eis zorgt vaak voor een goede opbouw van de eisenboom. Vaak is

124

Thesis Vincent Verheggen | Appendix E: Summery transcriptions interviews

een onderliggende eis een verbijzondering van de bovenliggende eis. In deze eis beschrijft de OG wat hij wil op basis van zijn kennis en ervaring!  De reden achter de eis is vaak niet aanwezig bij de ON. De context ontbreekt. Het is daarom ondenkbaar dat bij het aantonen van een bovenliggende eis, de onderliggende eis vervalt.  Nieuwe visualisatie technieken kunnen gebruikt worden om informatie en context van beslissingen van de ON naar de OG te communiceren. De OG kan op een makkelijke manier kijken of de informatie overeenkomt met zijn doel. Het komt vaak voor dat het doel van de klant niet goed verwoord is in zijn eigen eisen. Vooral eisen over RAMS- SHEEP-criteria, (de meest functionele, hoog gepositioneerde eisen) zijn hiervoor interessant.  AR is een beleving.

Interview met persoon C

Introductie  Achtergrond o Specialist civieltechnische informatica o Meer dan 10 jaar werkervaring o Implementatie van nieuwe technieken in de bouw  Kennis m.b.t. verificatie en Augmented Reality (AR) o Veel kennis van het verificatie proces o Veel kennis van nieuwe technieken zoals AR, lid van STUMICO.

Deel 1 Geen informatie

Deel 2  AR is geschikt voor ontwerp V&V,  De redenatie dat nieuwe visuele technieken kunnen zorgen voor V&V van functionele eisen is goed en gaat steeds meer leven bij verschillende bedrijven.  AR is interessant voor: o Training/ Instructie van specials (niet veel voorkomende activiteiten) o V&V/opsporen van fouten omdat: . AR goed geschikt om een gevoel voor ruimte te krijgen.  Voor goede V&V met AR is nodig: o Een apparaat dat interactie ondersteund (lopen, aanraken, wijzen). o Meerdere kijkers met AR-apparaten; o Een modeleur die al het grafische geweld verzorgt; o Voor de kijker is het niet alleen mogelijk om het model te zien, maar ook de gezichten van de andere personen die mee helpen bij de V&V.  Over de AR-TTM-voorbeelden: o Zorg dat je eisen kan selecteren in de software in plaats van de modellen. o Een tablet is een slappe vorm van AR. Geef daarom in de thesis duidelijk aan dat een tablet een beperkte vorm van AR is. o Bij het gebruik van AR-TTM is het gebruiken van een constructietekening als marker niet handig. “Je moet af van het idee dat je een tekening of marker nodig hebt.” Als rede hiervoor zegt Persoon C het volgende:

125

Thesis Vincent Verheggen | Appendix E: Summery transcriptions interviews

o Een papieren constructietekening ouderwets; er worden projecten uitgevoerd zonder papieren tekening, o Koppeling model aan marker brengt extra werk met zich mee, o Gebruik van marker maakt het geheel statisch.  Voordelen AR t.o.v. 3D model op de computer: o Geeft een groter ruimtelijk gevoel o Is een beleving o Ondersteund interactie  Vaak wordt verondersteld dat een hogere laag in de eisenboom een lagere laag vertegenwoordigt (zie probleemstelling). Zorgen dat een onderliggende laag beter een bovenliggende laag verwoord kan met behulp van nieuwe visuele technieken zoals AR. Het is noodzakelijk om alle technische eisen af te tikken maar om echt te zien of het totaal van de onderliggende eisen de intentie van de bovenliggende eis, de functie of het doel, vertegenwoordig zijn nieuwe sterke visuele technieken zeer geschikt.  Een visueel model draagt bij om een totaalbeeld te krijgen. Echte harde informatie is het niet maar vertrouwen van de klant kan ermee worden behaald.

Interview met persoon D

Introductie  Achtergrond o Teamleider Systems Engineering RWS o Meer dan 20 jaar werkervaring o Kwaliteit en contractmanagement. Auteur van leidraad voor Systems Engineering.  Kennis m.b.t. verificatie en Augmented Reality (AR) o Veel kennis van het verificatie proces o Weinig kennis van nieuwe technieken zoals AR

Deel 1  Vroegtijdige V&V is nuttig. Hier kan winst mee behaald worden  “Een eis staat niet op zichzelf. Een eis is een gevolg van een keuze die de OG impliciet of expliciet maakt. Soms zie je de keuze terug in ontwerpdocumenten maar heel vaak ook niet”. Een eis draag vaak een context

Deel 2  Het gebruik van nieuwe visuele technieken voor verificatie van functionele eisen zorgt voor meer inzicht in de onderliggende, meer technische eisen (als deze gegeven zijn).  Als onderliggende eisen nog niet gespecificeerd zijn kan het gebruik van nieuwe visuele technieken geschikt zijn om het ontwerp verder of juist niet verder te specificeren. Nieuwe visuele technieken kunnen zo invloed hebben op de diepgang van de specificatie. Het kan zichtbaar worden dat een onderliggende laag eisen en objecten niet geïnitieerd hoeft te worden. In dit geval zorgen nieuwe visuele technieken voor minder eisen. Het zichtbaar worden dat een onderliggende laag

126

Thesis Vincent Verheggen | Appendix E: Summery transcriptions interviews

eisen en objecten niet geïnitieerd hoeft te worden is in feite ook V&V maar gericht op de specificatie.  Nieuwe visuele technieken zijn voornamelijk interessant voor ontwerp validatie. Ze zorgen ervoor dat de stakeholders in een vroeg stadium betrokken kunnen worden over wat er gaat komen. Visualisaties wekken ook een vertrouwen en zijn goed voor communicatie van complexe informatie. Met name processen kunnen goed geverifieerd en gevalideerd worden middels nieuwe visualisatie technieken. Denkbare voorbeelden zijn: beweging van auto`s, systemen, mensen.  Nieuwe visuele technieken toepassen voor verificatie van technische eisen kan enkel als de achtergrond/context van een eis bekend is.  Visualisaties gebruiken als bewijsdocument voor V&V van alle typen eisen brengt ook risico`s met zich mee. Voorbeeld type boom, hoe teken je een boom zonder aan te geven welke type boom je bedoelt. Dan helpt een visualisatie niet.  Met nieuwe visuele technieken kunnen sommige functionele eisen beter geverifieerd of gevalideerd worden in vergelijking met conventionele middelen.  Positief over de AR-voorbeelden. Vooral model valideren is nuttig met AR.  Nieuwe visuele middelen gaan een grotere vlucht nemen dan we nu denken. Voor de aannemer zou het altijd een overweging blijven tussen wat het kost en wat de voordelen ervan zijn.

In een aanvullende email (24-6-2016) schrijft D: “Visualisaties kunnen helpen bij verificatie of validatie van een eis. Daarmee is V&V van 'onderliggende' eisen niet afgedekt. In een ontwerpslag kan visualisatie helpen bij de ontwerpbeslissing, zodat je dan er bijvoorbeeld voor kiest om niet verder door te specificeren (de visualisatie geeft vertrouwen dat je risico's afdekt). Ik zie dit analoog aan Rams-analyses; ook daar gebruik je ze als V&V op een eis of in de ontwerpslag”.

Interview met persoon E

Introductie  Achtergrond o General manager Infranea, een advies bedrijf in de GWW-bouw o Meer dan 20 jaar werkervaring o Verantwoordelijk voor contact met de klant en nieuwe contracten.  Kennis m.b.t. verificatie en Augmented Reality (AR) o Veel kennis van het verificatie proces o Veel kennis van nieuwe technieken zoals AR

Deel 1  Doel van een eis is duidelijk maar beleving/interpretatie vaak niet. Dit is het gevolg van ontbrekende context en de wil van de ON om zich te onderscheiden ten opzichte van zijn concurrenten. De eis wordt hierdoor op de proef gesteld en zo breed mogelijk geïnterpreteerd  Veel gebruikt middel om context te communiceren zijn de vraagmomenten gedurende de tender. Het stellen van vragen is een tactisch en strategisch spel  De piek van V&V zit tegen het einde van elke fase. Er wordt wel gedurende de fase zelf al rekening mee gehouden dat een eis aangetoond moet worden

127

Thesis Vincent Verheggen | Appendix E: Summery transcriptions interviews

 De rede dat de methode ‘document inspectie’ veel gedaan wordt is omdat de OG de informatie kan verwerken in zijn eigen systemen  Eisen kunnen gekoppeld worden aan objecten (koppeling tussen de 3D omgeving en de eisenbeheer omgeving). Dit gaat vooral op bij verificaties omdat dit vaak over technische eisen gaat. Functionele eisen zou je ook kunnen koppelen aan objecten alleen kan je deze eisen vaak niet bewijzen met het model zonder de functionele eis af te leiden

Deel 2  Nieuwe visuele technieken zoals simulatie, VR of AR kunnen het wel mogelijk maken om functionele eisen in je model aan te tonen.  Goed mogelijk met nieuwe visuele technieken zijn eisen waar je iets van kunt vinden (waar een belevingsaspect bij hoort): o Veiligheid o Vormgeving o Dynamische processen o Inpassing o Capaciteit  Nieuwe visualisatie technieken zijn goed omdat ze in een vroeg stadium technische informatie kunnen communiceren en daarmee verwachtingen kunnen afstemmen  Een manier om concreet te communiceren is om mensen die in een vroeg traject betrokken waren mee te nemen gedurende de rest van het project  Het meeste voordeel bij nieuwe visuele technieken valt te halen bij validatie omdat het daar om verwachtingen gaat  Voordeel van AR is dat: o Een model op een beeldscherm heeft nog een beperkte ruimtelijkheid o Dimensies en diepte kunnen zichtbaar worden door AR en VR o Makkelijk geïnterpreteerd kunnen worden door mensen die niet technisch onderlegd zijn. Mensen denken in plaatjes o Door een beleving het ontwerp realistischer wordt. Dynamisch, je hebt zelf invloed op wat je bekijkt  Een foto impressie kan doelbewust gemanipuleerd worden. De beleving vanuit een verschillende positie kan totaal anders zijn  Als er overeenstemming bereikt wordt over het functionele begrip is het niet nodig om extra die diepte in te gaan met de specificatie  Het model moet dus een mate van betrouwbaarheid communiceren. Er moet gezegd worden waarvoor een model gebruikt moet worden

Interview met persoon F

Introductie  Achtergrond: o Discipline leider bij SAAone o Meer dan 25 jaar werkervaring o Projectmanager bij Hochtief  Kennis m.b.t. verificatie en Augmented Reality (AR): o Kennis van het verificatie proces o Weinig kennis van nieuwe technieken zoals AR

128

Thesis Vincent Verheggen | Appendix E: Summery transcriptions interviews

Deel 1  Bij technische eisen speelt validatie een minder belangrijke rol dan bij verificatie. Bij functionele eisen validatie een belangrijke rol  De rede voor functioneel specificeren is omdat de OG niet goed weet wat hij wil  Een aannemer krijgt betaald voor het uiteindelijke doel. Validatie is daarom belangrijk. Verificatie is meer voor het interne proces van de ON  Betalingen zouden los moeten komen bij validatie in plaats van verificatie  Er wordt doorgeslagen in het geven van technische eisen. Vaak is boerenverstand al genoeg om te bepalen of iets goed of slecht is  V&V is gescheiden van de uitvoering  Voor V&V zou het goed zijn om meer te focussen op de ‘specials’  Vaak wordt er een verwijzing naar externe eisen opgenomen in technische eisen  Vaak is het niet duidelijk of een eis technisch, functioneel, is. De relatie met andere eisen is niet inzichtelijk. Door het inzichtelijk maken van de relatie zou je weten welke ontwerpvrijheid

Deel 2  VR en AR zou binnen project SAAone onder BIS en BIM vallen  Visualisatie zorgt ervoor dat je direct kan zien wat de gevolgen zijn van die interpretatie  Momenteel is het visuele model gescheiden van het constructieve model  Visualisaties maken het makkelijk voor niet technische om technische informatie te begrijpen. Simulatie is hierbij erg belangrijk  Bij technische eisen mist de context. De context blijkt meestal wel uit de functionele eisen

129

Thesis Vincent Verheggen | Appendix E: Summery transcriptions interviews

130

Thesis Vincent Verheggen | Appendix E: Summery transcriptions interviews

131