Improving users satisfaction by using requirements ...

Improving users satisfaction by using requirements engineering approaches in the conceptual phase of construction projects: the elicitation process 1

C. Mauger1, 2, T. Schwartz1, J.-Y. Dantan2, L. Harbouche1 Department of Service Science & Innovation, Public Research Center Henri Tudor, Luxembourg, Luxembourg 2 Laboratoire de Conception, Fabrication Commande, Arts et Métiers ParisTech, Metz, France ([email protected])

Abstract – The purpose of this article is to define an approach to improve consideration of users’ requirements in the early stage of a construction project. The input of the approach is the construction project appraisal and aims to produce a briefing program add-on relative to its business process needs and objectives. Requirements engineering is used as a basis for the proposed methodology, supported by the functional analysis, the quality function deployment and modeling languages. Its first application results focus on the requirements elicitation process. New kinds of information on the secondary school case study relative to its building were found, information missing from the current briefing program and sources of innovation and improvement. The conclusion deals with the importance to develop this kind of framework that could save time and bring more value to buildings through a business-building alignment. Keywords – Construction project, requirements elicitation, requirement engineering, users’ satisfaction

I. INTRODUCTION According to the literature, the Construction Industry suffered from several quality, cost, and delay problems that directly impact on customers’ and more particularly on users’ satisfaction. Most of them were related to the briefing process [1]. The briefing process corresponded to the conceptual phase of any project in Engineering. This phase precedes the design phase and consisted, inter alia, on defining the project framework and expectations through a statement of customers’ requirements [2]. This phase started with very fuzzy and incomplete information which was required to be gathered, analyzed and clarified. Its output was the functional requirements in the Mechanical Industry, and the system requirements specification in the Software Industry, that matched to the briefing program in the Construction Industry. The conceptual phase could be considered as the most important stage in an engineering project development cycle. Decisions made during this stage had significant impact on the performance, the reliability, the safety and particularly the cost of the final product. Indeed, compared to the growth of the project cost, the possibility of savings tended to decline faster from the design phase (Fig. 1). Moreover, the relative cost of changes in the conceptual phase was very low when almost 80% of the overall cost was engaged so it presented the greatest opportunity for improvement for any project.

Fig. 1. Evolution of costs during project life cycle.

Following their needs and practices, each Industry had developed its own tools and methods to manage the best this key phase. The Construction Industry possessed guides and practices [3, 4] that were considered inadequate and lacking in comprehensiveness [5, 6, 7, 8]. Research studies tried to fix them by adopting a few methodologies from other engineering domains. Some of the most advanced works in the construction industry were Kamara et al.’s works with their Client Requirements Processing Model (CRPM) [9] using the Quality Function Deployment (QFD) from the Mechanical Industry [10] and their prototype software ClientPro [7]. Other QFD attempts were found in literature [11, 12] but none of them had gone so far in the implementation of the methodology. The Functional Analysis (FA) and the Value Management (VM) approaches [13, 14], equally from the Mechanical Industry, were developed too. All of these attempts led to few practical applications. The missing point of these guides or attempts could be highlighted according to the UK report on the Construction Industry [15]. It identified five key drivers of improvement and one of them was “a focus on the customer”. A previous study on value 1 brought by infrastructure on secondary school objectives in Luxembourg had shown that this issue would be a source of improvement too. A first response was given by the Commission for Architecture and the Built Environment (CABE) in UK through a briefing framework [16]. Due to the specificities of Luxembourg, a small country and few secondary schools, and delay in these issues (almost ten years), it was not really possible to directly adapt this work. 1

value = ratio between function related to the business needs and infrastructure costs

The purpose of this study was to answer this question: how to gather and analyze customers’ requirements in construction projects? A literature review led to the finding that the Software Industry handled this process through the Requirements Engineering (RE) that seemed more customer-oriented than the QFD, FA, and VM from the Mechanical Industry. As a consequence, the methodology proposed in this paper was based on the structure of the RE supported by the different attempts and results of QFD, FA, and VM in the Construction Industry. This proposition could be seen as a complement to the work on CRPM about requirements elicitation and analysis. Its development was presented in section II. Section III presented the first results of this attempt on a case study. This paper ended with a conclusion integrating discussion in section IV. II. METHODOLOGY This approach focused on principles of the most common methods available in engineering: Information Modeling (IM), Functional Analysis (FA), Requirement Engineering (RE) and Quality Function Deployment (QFD). IM was added to help representation of the business process and information gathered. The methodology is divided into three main processes based on RE principles: • requirements elicitation; • requirements analysis; • requirements specification. Fig. 2 represented the development of the method with its inputs and outputs with the tools used or format of delivery. The requirements elicitation process (stage 1) aimed at gathering all the information about business and project needs and objectives. Reference [17] described this process with five principal types of activities (Fig. 3): 1) Understanding the application domain: “What are the purposes?” and “How does it work?” are the first questions to answer. A domain analysis from elicitation techniques would be practiced to do it.

Fig. 2. Stages of the methodology.

Fig. 3. Stage 1: the requirements elicitation process in detail.

2) Identifying the sources of requirements: Multiple sources were possible besides obvious sources like customers, users or subject matter experts. Each one of them brought different kind of information, more or less accurate. Customers known as the paying clients gave general information. On the other side, user clients gave detail information on their activities. FA provided interesting tools like the FAST and the interaction diagram to support this difference. 3) Analyzing the stakeholders: Stakeholders did not have the same importance or would not be affected in the same way by the construction project. This step permitted to refine and keep only relevant stakeholders. 4) Selecting the techniques, approaches and tools to use: RE provided a huge set of techniques, approaches and tools [18]. This step was often considered as a critical factor for this process success. Research had been done to help in choosing the “right” technique according to the situation [17, 19, 20]. 5) Eliciting the requirements from stakeholders and other sources: Application of the withheld techniques and approaches selected. All the information required is gathered at this step. Business and project information were from different types, there were users’ requirements, customers’ requirements and standards. They would be sorted and structured in the next stage. The requirement analysis (stage 2) aimed to refine and structure requirements in a reusable form. Tools from AF and IM were proposed to support this process and allowed requirements traceability during the project life cycle. Four steps could be defined (Fig. 4): 1) Sorting information: Analysis of information permits to separate customers’ requirements, users’ requirements and standards information.

Fig. 4. Stage 2: the requirements analysis process in detail.

2) Modeling information: Customers’ requirements would be formalize in a Functional Analysis System Techniques (FAST) through a FA of the organization. It gathered all the business objectives and non-functional requirements (e.g. performance). Users’ requirements would be modeled with use cases from Unified Modeling Language (UML). Current activities and functional requirements were gathered in this format. Standards information (e.g. sustainability or security of the building) would not be formalized but removed for the following steps. It was considered that the design team already had means of using them. 3) Structuring requirements: A reusable form implied considering an implementation of the requirements through a database. To simplify, we chose to follow Kamara et al. and turned towards current software (e.g. MS Access) instead of expert software for now. A first database model was designed to support all types of projects based on tasks to get activities and spaces. UML class diagram had been used to represent this (Fig. 5). 4) Validating requirements: A comparison between use cases and the last level of the FAST with a pivot table assured the completeness and concordance of the information in the database. The requirement specification (stage 3) process aimed to record requirements in a way that can be used by the designer (e.g. the architect in the construction industry). This process would be supported by part of a QFD matrix named house of quality (inspired from [10]). Seven stages could be identified (Fig. 6): 1) Voice of the Customer (VoC): Defined from customers’ requirements. It would be a result of the requirements analysis extracted from the database (stage 2). 2) Weighting of requirements: Represents prioritization of the requirements. 3) Voice of the Designer (VoD): Defined from design attributes used as input by the architect, seen as neutral-solution parameters. 4) Target Values (TV): Contains levels of performance required for each design attribute. 5) Relationship matrix: Defined relationships between VoC (i.e. requirements) and VoD (i.e. design attributes) with a weighting. 6) Design attributes correlation matrix: Possible interactions between the design attributes. 7) Weighting of design attributes: Prioritization of design attributes.

Fig. 6. Stage 3: the requirements specification process in detail.

The first stage would be directly completed with the requirements analysis. Stages 2, 4, 5, 6 and 7 would be done due to information stored in the database through requests and constraints. Finally, stage 3 and the VoD could be informed by studying briefing program and meeting architects to know what they need to design the future building well. The output of this process would be an add-on of the briefing program containing the relationship between business process needs and objectives, and neutral-solution parameters (i.e. design attributes). III. RESULTS The first application of this methodology was done on the refurbishment and extension of the Lycée Technique de Bonnevoie (LTB), a secondary school in Luxembourg. This school was particularly interesting because of the major role of the psychological services and educational guidance (SPOS) and the irrelevance of the current building according to the school objectives and pupils profiles. This was translated by a poor occupancy rate, redundancy, and lack of adaptability and flexibility of the current spaces. Requirements were restrained to secondary school business process and objectives in order to evaluate the impact of new pedagogic methods on building requirements. In this paper, the results were limited to the requirements elicitation process due to advancement of the study. In fact, the analysis process was an ongoing work whereas the specification process was still at a preliminary state when this paper was written. This study and the service delivery were carried out at the same time. In the understanding the application domain step, a domain analysis led to highlight new pedagogic trends and related needs and methods (e.g. differentiated instruction2). This brought a first feeling about how the building would be able to support this new way of teaching and learning. 2

Fig. 5. Database sketch for requirement analysis.

Teaching and learning focused on differences between students’ capabilities.

Many sources (Fig. 6) were identified but limited to users because we focused on functional requirements, and a set of relevant document (Table I). These sources were the most accessible and relevant according to our purpose and schedule. The analysis of the users (i.e. part of the stakeholders) led us to retain the most relevant kind of users (e.g. teachers, SPOS staff). We reduced the amount of 100 lower cycle teachers to only 5 selected by the Director of the LTB in order to simplify the study. The first selected techniques were domain analysis, unstructured interviews, observation and brainstorming. Due to lack of experience in requirements elicitation, several techniques were used to deal with it at each step of the elicitation process (Table II). In hindsight, it appeared that we indirectly used other techniques because of our functional approach (e.g. group work, task analysis and scenarios). Each technique provided a different set of information according to its purpose to feed the study. During the elicitation stage, a first result was the possible link between building solution and business process needs through new functions of the building. Correlation between information from group work and interviews led to connect business needs to generic function that could be satisfy through building solution.

“Improve oversight” was one of the new functions that could be assigned to the building. It differed from “Assure security” function which already existed. This function came from several generic business needs (Table III). There were different ways to answer through the organization or the building. The idea here was to promote building solutions or principles when it is possible or, at least, to show to the architect a possible way to design the building. For example, he might prefer using see-through materials over concrete for external walls if it was possible and relevant to support oversight of the people. IV. CONCLUSION This paper proposed a methodology to improve user satisfaction in construction projects through a better support and integration of its business needs and objectives during the conceptual phase. This methodology was divided into three stages of which only the requirements elicitation results have been presented. The first application of the requirements elicitation process on a concrete case study had highlighted that the briefing process is very time consuming. Part of the TABLE I SOURCES WITHHELD AND TYPES Sources Potential Withheld Pupils Teachers X SPOS staff X Administrative staff X Management staff X Ministry of Education Educational laws and X regulations Institutional X documentation

Fig. 6. Part of the interaction diagram of the school building.

Type Clients

Users X X X X X

Standards

X X X

TABLE II TECHNIQUES WITHHELD FOR ELICITATION PROCESS Elicitation process steps Understanding the application domain Identifying the sources Analyzing the stakeholders Selecting the techniques Eliciting the requirements

Domain Analysis X X

Unstructured Interview X

Observation

Techniques Brainstorming Group Work

X X

X

X

X

Task Analysis X

Scenarios X

X X X

X

X

TABLE III FROM BUSINESS PROCESS NEEDS TO BUILDING SOLUTIONS Business process needs People have to feel safe at school Safety affects performance Young pupil needs benchmarks to have confidence

“Building” function

Type Organization

Improve oversight

Building

Areas of non rights are forbidden An oversight of relations between pupil is required

Equipment

Principle New resources New organization Different materials

Solution Hire monitors Set patrol Use see through materials

Different layout

Bring adults’ area and pupils’ area closer

New resources

Install closed-circuit television

problem was due to the huge amount of information that could be gathered, and the lack of explicit framework to gather it which led to redo part of the process. Current practices avoided the problem by considering a small sample of information, forgetting part of the requirements related to the users and the customers’ business, and focusing on costs and building’s aesthetics. Structuring the elicitation process allowed gathering more information whereas a customer or business oriented approach permitted the requirements team to produce new kind of information no less important or relevant. The proposed methodology mostly originally from the RE concerning the elicitation process gave the possibility to combine both of them. It allowed innovating through a business-building alignment by reconsidering information given based on customers’ objectives in the briefing program. It resulted in a reengineering that could increase value of the building (e.g. more innovation possible and less cost). Nevertheless, even if gathering a huge amount of information would lead to a better definition of the project, the analysis of it would be even more time consuming if done in paper form. Considering this, it became necessary to think about a software implementation of the information for the next processes of the methodology. REFERENCES [1] A. T. W. Yu, Q. Shen, J. Kelly, and K. Hunter, “Comparative study of variables in construction project briefing-architectural programming”, in Journal of Construction Engineering and Management, February 2008, pp. 122-138. [2] M. R. Abdul-Kadir, A. D. F. Price, “Conceptual phase of construction projects”, in International Journal of Project Management, Ed. Elsevier Science Ltd, 1995, Vol. 13, No 6, pp. 387–393. [3] Luxembourg Building Ministry, “Modular concept for Secondary School”, 2006. [4] E. Neufert, Les éléments des projets de construction, 7th edition, Ed. Dunod, 1996. [5] P.S. Barrett, J. Hudson, C. Stanley, “Good practice in briefing: the limits of rationality”, in Automation in Construction 8, 1999, pp. 633-642. [6] S. D. Green, and S. J. Simister, “Modeling client business processes as an aid to strategic briefing”, in Construction Management and Economics, 1999, pp. 63-76. [7] J. M. Kamara, C. J. Anumba, N. F. O. Evbuomwan, Capturing client requirements in construction project. Thomas Telford, 2002. [8] Q. Shen, H. Li, and P.-Y. Hui, “A framework for identification and representation of clients requirements in the briefing process”, in Construction Management and Economics, 2004, pp. 213-221. [9] J. M. Kamara, C. J. Anumba, and N. F. O. Evbuomwan, ‘‘The importance of clients’ requirements processing in concurrent engineering.’’ in Flexible Automation and Intelligent Manufacturing: Proc., 7th Int. Conf., W. G. Sullivan and M. M. Ahmad, eds., European Process Industries Competitiveness Center (EPICC), University of Teesside, Middlesbrough, U.K., 228–238.

[10] J. M. Kamara, C. J. Anumba, N. F. O. Evbuomwan, “Client requirements processing in construction: A new approach using QFD”, in Journal of Architectural Engineering, 1999, pp. 8 - 15. [11] L. P. Lima, C. T. Formoso, M. E. S. Echeveste, “Client requirements processing in low-income house-building using visual displays and the house of quality”, in Proceedings IGLC-16, Manchester, 2008. [12] L. A. Gargione, “Using quality function deployment (QFD) in the design phase of an apartment construction project,” in Proceedings IGLC-7 , University of California, Berkeley, CA, USA, 1999. [13] C. Gobin, “Analyse fonctionnelle et construction”, in Techniques de l’ingénieur C3052, 2003, 15p. [14] X. Luo, Q. Shen, “A computer-Aided FPS-Oriented Approach for Construction Briefing”, Tsinghua science and technology, vol. 13, no. S1, pp 292-297, October 2008. [15] Egan, J., Sir. "Rethinking Construction (The report of the Construction Task Force to the Deputy Prime Minister, John Prescott, on the scope for improving the quality and efficiency of UK construction)", Department of the Environment, Transport and the Regions, [Task Force report], 22nd July 1998. [16] Department for Education and Skills, “Briefing Framework for Secondary School Project”, in Building Bulletin 98, UK, 2008. [17] D. Zowghi, C. Coulin, “Requirements elicitation: A survey of techniques, approaches, and tools,” in Engineering and Managing Software Requirements, A. Aurum, C. P. Wohlin, NJ: Springer-Verlag Berlin Heidelberg GmbH & Co. K, 2005, ch. 2, pp 19-46. [18] C. R. Coulin, “A Situational Approach and Intelligent Tool for Collaborative Requirements Elicitation,” Ph. D. dissertation, Computing Sciences, University of Technology, Sydney, Univervité Paul Sabatier, Toulouse III, 2007. [19] Hickey, A. M., Davis, “An ontological approach to requirements elicitation technique selection” in Ontologies A Handbook of Principles, Concepts and Applications in Information Systems, Raj Sharman, Rajiv Kishore and Ram Ramesh Integrated Series in Information Systems. Ed SUNNY Buffalo, 2007, ch. 14 pp. 403–431. [20] T. Tsumaki, T. Tamai, “Framework for matching requirements elicitation techniques to project characteristics”, in Software process improvement and practices, Vol. 11, 2006, pp 505-519.