Requirements processing for building design: a systematic review

Abstract

Problems in buildings can often be traced back to the requirements processing in the design phases. In building design, requirements processing is mainly discussed under the term briefing and is a critical and a problematic process. This study focus on the design stage and aims to summarize and analyze requirements’ processing concepts and practices by a systematic review. The main problems, guidelines, tools and methods were analyzed and compared to the requirements engineering and management approaches. The findings indicate lack of consensus about key concepts and about the coverage of requirements processing, lack of applied methods and lack of practitioners’ knowledge. From the gaps, we proposed a definition for the key concepts, and scheme of this whole requirements processing in building design and indicate recommendations for future research, which can guide important contributions, especially if supported by practical experiences.

Keywords
Requirements processing; Building design; Design management; Construction

1 Introduction

It is widely believed that the requirements processing is both critical to the successful delivery of construction projects and problematical in its effectiveness (Shen et al., 2004). Problems in buildings can often be traced back to the requirements processing in the design phases. This difficulty is recurrent due to the complex and iterative nature, and to the great number of stakeholders involved in this type of project (Kamara et al., 1999; Rezgui et al., 2003; Jallow et al., 2014). Requirements are functionalities that a product or service has to incorporate to meet demands or to achieve the objectives of the parties involved in a project (Parviainen et al., 2005), and whose management and fulfillment are essential to the project success. The goal of managing requirements is to ensure that the benefits envisaged at the start of the project are realized at the completion and all the way through the life of the facility (Jallow et al., 2014).

The major body of knowledge about requirements come from the Software Engineering (SE) researches, mainly based in two sub-areas. The first, Requirements Engineering (RE), explores the stages through which the requirements perform during the project: (i) elicitation, (ii) analysis and prioritization, (iii) specification, and (iv) validation (Bray, 2002; Sommerville, 2007). The second, Requirements Management (RM), includes requirements documentation, storage, communication, tracking and traceability in such a way to allow an easy and reliable requirements change management (Bray, 2002; Sommerville, 2007). Although SE has many differences from Architecture, Engineering, Construction and Facilities Management (AEC/FM) area, its generic and consolidated concepts can bring important conceptual contributions

In this research, we will call this whole process as requirements processing, as RE and RM are not usually dissociated in AEC/FM studies. Requirements processing is mainly explored under other terms, especially as “briefing” (Barrett et al., 1999; Kamara et al., 2001; Luck et al., 2001; Rezgui et al., 2003; Hansen & Vanegas, 2003; Ryd, 2004; Yu et al., 2005; 2006; Sterry & Sutrisna, 2007; Bendixen & Koch, 2007; Luo & Shen, 2008; Luo et al., 2010; 2011; Jensen, 2011; Chandra & Loosemore, 2011; Zarooni et al., 2011; Elf et al., 2012; Tang et al., 2013; Tang & Shen, 2013). For most of the authors who use the term “briefing”, this is assumed as a process of identification, articulation, definition and registration of design requirements that takes place in the initial stages of the project, such as the planning and preliminary studies (Luo et al., 2011; Yu & Shen, 2013). However, some authors state that briefing occurs dynamically throughout design, construction and through-life of a facility (Luck et al., 2001; Othman et al., 2004; Jensen, 2011; Jallow et al., 2014), a position which is more similar to the SE view.

As long as good requirements processing practices help stakeholders to form adequate relations and make valuable decisions for a project (Tang et al., 2014), some researchers have also used value management techniques for considering requirements in construction projects (Yu et al., 2005; 2008; Luo et al., 2010; 2011). These techniques enable the project team to identify the best values and derive suitable solutions to fulfill the client’s requirements (Leung et al., 2002; Shen & Chung, 2002; Yu et al., 2005; Luo et al., 2010; 2011).

Despite all of these approaches provide important and complementary contributions to studies on requirements processing for building design, the previous literature analysis indicated some problems, such as: different understandings regarding the coverage of requirements processing activities and its relationship with the design process; different definitions for key concepts; few papers in international scientific journals with a broad and consistent theoretical review. Until now, the lack of common understanding among researchers on this theme seems to affect the research development in terms of standardization, dissemination of solid concepts and of the proposition of reliable solutions. Thus, as a necessary step back, this paper presents a systematic review which research question is: what are the main academic contributions involving requirements processing concepts and practices for the building design in the last fifteen years?

The goals are: (a) to identify and analyze the main problems, guidelines, tools and methods proposed in the literature and (b) to indicate the main gaps that remained. Furthermore, we bring some theoretical contributions. As a delimitation, even understanding that the requirements processing follows the whole project life cycle, this study focus on the design phase.

This systematic review is a first step within a larger research (Pegoraro, 2016) that aims to propose practical improvements to the requirements processing for building design in alignment with the skills of the practitioners. The main contribution of this specific paper is the synthesis of the literature content, and the identification of potential routes for theoretical and practical advances.

2 Research method

A systematic review was developed to make a broad and consistent contribution to this research field. This type of research method uses literature as an input viewing to collect all the evidence that can be classified within pre-determined eligibility criteria, in order to answer a specific research question (Higgins & Green, 2011). By supplying a reliable synthesis based on this evidence, the systematic review’s premise is that science is cumulative and that the knowledge generated makes decision-making easier (Higgins & Green, 2011). In this research a systematic review protocol was followed (Biolchini et al., 2005) because it presents an appropriate and clear structure. The stages developed and their results are shown in Figure 1.

Figure 1
Protocol of the systematic review. Adaptation from Biolchini et al. (2005).

2.1 Question formalization

The research question must be clear and aligned with the objective of the systematic review. Based on the arguments presented in the introduction, the research question is: what are the main academic contributions involving requirements processing concepts and practices for building design in the last fifteen years? The period was delimited by the time in which the research on the topic was intense and because it included the current research, without excluding studies with major theoretical contributions.

The nature of the researches was not previously determined, as to whether they were theoretical or applied, since the contributions of both types would be relevant. Likewise, no types of practices of greater interest were delimited, since they were all to be considered. “Practices” were taken to be the set of mechanisms, procedures, tools, methods, and related actions which can be used to implement RE/RM.

Based on the question and the literature that was previously known by researchers, the keywords and their correlated terms were identified. The research argument was established based on the keywords. In test runs, a great number of software engineering papers was observed in the results, since in this field there are many studies on the requirements and architecture of software. Therefore this area was excluded already in the argument through the Boolean operator NOT.

2.2 Database selection

The second part of protocol aims to define the scientific databases. The bases chosen were Science Direct, Emerald, Taylor & Francis, ASCE Library and ISI Web of knowledge. These electronic databases were chosen due to their relevance to the research topic and scope, and according to the criteria (i, ii, iii) shown in Figure 1.

2.3 Paper selection and information extraction

At first, criteria were established to refine the searches in the databases (i, ii, iii and iv), as shown in Figure 1. Next, the papers were examined according to criteria (v) and (vi) – firstly, through the titles and keywords, and, secondly, through the abstracts. In case of duplicated publications (criterion vii), the most complete was considered. Based on the final papers, 12 secondary references were included according to criteria (viii) and (ix) of the Figure 1 and 48 references remained. In addition, to complete the review, we brought some contributions from SE literature.

For content analysis, the important objective information of each reference was extracted through information forms and organized in a spreadsheet. The labels used were: the database; reference; title; publication year; paper origin country; project life cycle stage; theoretical or applied study; objective; results; the principal emphasis of the study; RM activities studied; RE stages studied.

2.4 Discussion procedures

In order to find the AEC literature contributions to the theme, the discussion was based on the analysis of the relationship between the findings of the information extraction with RE steps and RM activities (from SE literature) through matrices. In addition, AEC requirements processing problems were compared to the solutions (guidelines, tools and methods) to identify lack of connections. Finally, we indicate main gaps and recommendations for future research.

3 Information extraction and analysis

The focus of this section is to present the most important concepts and practices found in the references obtained through the information forms. After an overview, the following sub-sections provide an outline of selected studies divided into four groups.

3.1 Overview

From the references, we found an average of 3.13 papers published per year, without significant peaks. In the period from 2007 to 2014 the proportion of papers with an applied approach, beyond theoretical perceptions, increased from 48% to 72.7%, which we see as a research evolution. Moreover, instead of importing practices from the manufacture area, the most current references often focuses on the identification of critical factors in the briefing process, and also in the correlation of building design with value management concepts (Yu et al., 2005; 2006; Tang & Shen, 2013; Yu & Shen, 2013). This change in the approach increases the understanding of the intrinsic problems of construction and the benefits to be generated by the use of more specific and appropriate practices.

The most cited authors in the references of this review were Barrett & Stanley (1999) - 16 citations; Kamara et al. (2002) – 10 citations; Kelly & Duerk (2002) - 8 citations; Othman et al. (2004) – 6 citations; Kamara & Anumba (2001a) – 6 citations; and Kamara & Anumba (2001b) – 5 citations. They include important theoretical studies, followed sometimes by case studies or by propositions of tools. That is why many recent authors still go back to them as references for recent proposals. Concerning the keywords, the most cited in the references is “value management” (484 times), followed by “requirements engineering” (90 times), “briefing” (72 times) and “requirements management” (42 times). The count of keywords was made based on the articles; thesis and books were not included because they are much more extensive than articles and could overbalance the result according to their subjects.

In order to contribute to the understanding of the scenario and to advance the analysis of content, the references were arranged according to their focus into four correlated groups (Figure 2). The proportion of studies per group is shown in the Table 1.

Figure 2
Diagram of relations between research groups.

Table 1
Distribution of research studies per group.

Research group	References	Number of papers	%
Problems and critical factors in the Requirements Processing	(Barrett & Stanley, 1999; Barrett et al., 1999; Kamara & Anumba, 2001a; Yu et al., 2006; Soetanto et al., 2006; Jensen, 2011; Elf et al., 2012; Tang et al., 2013; 2014; Yu & Shen, 2013; Jallow et al., 2014).	11	23%
Guidelines for the Requirements Processing	(Chinyio et al., 1998; Kamara et al., 1999; 2001; 2002; Luck et al., 2001; Hyams, 2001; Leung et al., 2002; Kelly & Duerk, 2002; Othman et al., 2004; Shen et al., 2004; Ryd, 2004; Yu et al., 2005; 2007; 2008; Arayici et al., 2006; Yu, 2006; Luck & McDonnell, 2006; Sheer et al., 2007; Sterry & Sutrisna, 2007; Chung et al., 2009; Thyssen et al., 2010; Chandra & Loosemore, 2011; Zarooni et al., 2011; Jay & Bowen, 2011; Tang & Shen, 2013).	25	52%
Tools and techniques for the Requirements Processing	(Kamara et al., 2000; Kamara & Anumba, 2001b; Shen & Chung, 2002; Rezgui et al., 2003; Hansen & Vanegas, 2003; Bendixen & Koch, 2007; Luo & Shen, 2008; Bluyssen et al., 2010; Luo et al., 2010; 2011).	10	21%
Methods for the Requirements Processing	(Wandahl, 2004; Shen et al., 2013).	2	4%

The main contributions of each group are discussed in the next section. It is noted that although the papers were grouped according to their focus, possible contributions to the other three groups were considered and cited when relevant.

Additionally, in order to analyze which part of requirements processing each paper addresses and contributes, we considered that requirements are intermittently developed through four stages during a project: (i) elicitation, (ii) analysis and prioritization, (iii) specification, and (iv) validation (Bray, 2002; Sommerville, 2007). We found the stages (i), (ii) and (iii) introduced in the oldest studies of this review (Kamara et al., 1999; 2002; Kamara & Anumba, 2001b). Although the approach to them was not so clearly defined and combined by most subsequent authors and a few studies deepened in the fourth stage when dealing with design reviews and feedback (e.g. Shen et al., 2013). The following description of each stage was achieved by means of content analysis.

The activities of the first stage are based on the collection and organization of information for the project, identification of the stakeholders and their demands, and subsequent transformation of wishes and needs into requirements (Chinyio et al., 1998; Barrett et al., 1999; Bray, 2002; Shen et al., 2004; Sommerville, 2007). Elicitation activities are presented in 89.6% of the papers and there is a notable focus on performing these activities in the initial phases of the design process.

In the second stage, analysis and prioritization, the requirements must be examined, combined, and the importance of each of them must be evaluated (Bray, 2002; Shen et al., 2004; Sommerville, 2007). This RM stage was mentioned in 66.7% of publications. Conflicts among requirements often occur on this stage (Bray, 2002), especially in projects with numerous stakeholders, which is typical of building projects (Rezgui et al., 2003; Shen et al., 2004). Therefore it is essential to have a good basis for decision-making in order to solve such conflicts without impairing the project (Soetanto et al., 2006).

In the third stage, specification, the requirements must be transformed into neutral design solutions (Kamara et al., 1999). Activities related to the requirement specifications are explored in 50% of the papers. Again assertive decision–making on the solutions is essential to be worked on (Soetanto et al., 2006).

Finally, in the fourth stage, validation, the design solutions should be evaluated by verifications and feedbacks (Bluyssen et al., 2010; Shen et al., 2013). Some alternatives of good practices will be presented next in this paper, but only 12.5% of studies discuss this stage.

Concerning the RM activities, although there are studies geared to the requirements’ documentation, communication, tracking, traceability and change management (e.g. Jallow et al., 2014), most of the researches poorly considered all of them. Usually they are associated with the construction of the brief, not considering the whole design process and even less the whole project life cycle. Requirements are open to changes and the RM activities should enable such changes to be evaluated and implemented (Jallow et al., 2014). We have found lack of guidelines on how they could be continuously performed without losing the track of the requirements.

3.2 Problems and critical factors

Among the problems to perform requirements processing activities, the most cited are the difficulties in accommodating the requirements of all involved, and the lack of open, effective and formal communication. Concerning the first one, it is basically due to the high number of stakeholders (Jallow et al., 2014) and the poor definition of the project’s objectives and priorities (Barrett et al., 1999; Rezgui et al., 2003). Concerning the second one, the lack of channels and common language are recurrent problems that hinder the communication between stakeholders (Jallow et al., 2014) and it causes many avoidable losses in time, budget and value generation (Yu et al., 2006; Tang et al., 2013; Shen et al., 2013; Jallow et al., 2014). The open communication was the most important factor according to a survey with specialists that indicated thirty-seven critical factors for the success of the briefing process (Yu et al., 2006).

The generation of unclear information is another critical factor that can promote a very negative impact on requirements management and value generation (Yu et al., 2006). Information clearness is a quality to be permanently sought, from the definition of the objectives of the organization and project, throughout the identification stakeholders, requirements and actions to be taken to manage them (Yu & Shen, 2013). Through a survey based on case studies, researchers concluded that indeed, often the documents that record the demands (briefs) are not based on clear evidence, do not formalize the clients’ demands adequately and do not prescribe measurable targets (Elf et al., 2012).

As to the later aspect, some authors identified the lack of inclusion of end users throughout the design development (Soetanto et al., 2006; Jensen, 2011). So, it becomes difficult to evaluate to what extent the design solutions serve their needs and wishes (Jensen, 2011). Analyzing the criteria used by clients, designers and consultants in project decisions, marked differences were noted in the perception of their importance (Soetanto et al., 2006). Some authors state that there is a tendency to change the focus of the clients’ needs to the designers’ preferences, as the design is being developed (Chinyio et al., 1998; Kamara et al., 2000). Consequently, changes during the design process are often mistreated (Chandra & Loosemore, 2011). Moreover, even when the clients are included, sometimes they do not know how to express their wishes and collaborate with the design development (Barrett et al., 1999; Wandahl, 2004). The project team has to guide inexperienced clients, because late or wrong requirements might bring many losses (Barrett & Stanley, 1999).

In this sense, there are authors who indicate that human failures due to lack of knowledge, experience and training are base-problems in requirements processing (Barrett et al., 1999; Bluyssen et al., 2010). In parallel, there is a need of frameworks, and specific and applied methods/tools to support the requirements processing activities, which are still too manual, decentralized, non-systematic, and paper-intensive (Jallow et al., 2014).

3.3 Guidelines

Most of the guidelines identified are prescriptive and are associated to the well-known problems in the design process, such as difficulties in generating value (Chinyio et al., 1998; Kamara et al., 2001; Leung et al., 2002; Othman et al., 2004; Shen et al., 2004; Yu et al., 2005; Sterry & Sutrisna, 2007; Thyssen et al., 2010; Chandra & Loosemore, 2011; Jay & Bowen, 2011; Tang & Shen, 2013) and in communication (Ryd, 2004; Arayici et al., 2006; Luck & McDonnell, 2006; Sheer et al., 2007; Chung et al., 2009; Bluyssen et al., 2010).

Value management is a fertile field for research on requirements, since its main objective is to develop solutions that will generate value when responding to the clients’ requirements (Leung et al., 2002; Shen & Chung, 2002; Yu et al., 2005; Luo et al., 2010; 2011). Shen et al. (2004), for example, propose shaping a structure to process the clients’ requirements by expressing them in the format of functional terms and in their organization according to a how-why logic. Other researchers in the field found variables that have impact on value generation via the requirements (Yu et al., 2005). When developing and validating a theoretical structure based on these variables, it was concluded that the most significant of them was “Client representation” (Yu et al., 2007). This means that it is necessary to ensure adequate representation of the clients involved in the project, in order to allow identifying the needs completely and preventing distortion of the demands (Yu et al., 2007).

It is acknowledged that decisions made during the initial phases of design are critical to value generation, and these definitions must be consistent enough to guide project development (Ryd, 2004; Soetanto et al., 2006). However, the identification of requirements should not stop in these phases, it must evolve as the project develops (Jensen, 2011; Jallow et al., 2014). Limiting the uptake of requirements to the initial stages makes the formal processing unfeasible and prevents interaction among the stakeholders (Othman et al., 2004). Case studies have shown that the opinions and changes provided by the clients may lead to improved results (Othman et al., 2004). These findings reinforce that requirements processing is a continuous and dynamic process.

In order to improve the RM process, it is necessary a formal, centralized and integrated structure to register and distribute information produced by those parties (Jallow et al., 2014). These authors propose an integrated model to guide the execution of RM activities, based on the continuous requirement identification, a requirement web-based repository and a requirement change management system. In this sense, the use of web-based collaborative environments was recognized in studies about work plans (Sheer et al., 2007) and extranet network systems (Chung et al., 2009). These structures complement the informal registration and face-to-face meetings, and can improve efficiency in communication and trust in the work of those involved and. Concerning the conditions for face-to-face communication and interaction between the parties involved, some authors propose sequences of workshops during the project (Thyssen et al., 2010). It is necessary, however, to watch out for the promotion of discussions, debates and conflicts that are really constructive (Leung et al., 2002; Chandra & Loosemore, 2011).

A RE approach was also used for the development of a Computer Integrated Construction (CIC) system (Arayici et al., 2006) through which collaborative working can be undertaken. The focus is on integrating requirements’ information over the project life cycle, but the authors themselves say that, although many CIC systems have been developed, they usually do not go beyond the limits of technology transfer (Arayici et al., 2006). In general, it can be seen that even in the most recent research, few authors in this group use IT resources (Arayici et al., 2006; Sheer et al., 2007; Chung et al., 2009; Bluyssen et al., 2010).

As a complement, some authors seek inspiration in other industries. Kamara et al. (1999; 2001) present a model to analyze and specify requirements of clients, strongly based on QFD and practices of concurrent engineering. The model proposes to clarify the process of defining project requirements and solutions, and to make traceability activities easier. Based on case studies and surveys, authors propose a sequence of activities within three stages (definition, analysis and translation of requirements) with the respective tools for each stage. The methodology is well structured, but due to the quantity of data, there are doubts as to whether it would really be useful without the support of IT.

Finally, as already presented in the previous section, one of the main causes of failure is the lack of experience of professionals to deal with requirements processing. The design team must understand the requirements processing benefits and be prepared before performing it. Some guidelines found as possible solutions to this problem were to invest in training and designating specialists to coordinate the requirements processing activities (Barrett et al., 1999; Bluyssen et al., 2010). There are also indications that these skills should be introduced in professional education already at the undergraduate level (Barrett et al., 1999). However, it is warned that excessive emphasis on rational decision-making can limit creativity, which is important for any design process (Barrett et al., 1999).

3.4 Tools and techniques

Since there are four main stages to RE and each of them requires specific tools and techniques, the most organized way to present them was by grouping according to those stages.

As to elicitation, the best practices are still well-known interviews and questionnaires (Kamara et al., 1999; 2000), workshops and brainstorming (Rezgui et al., 2003). Software, such as ClientPro (Kamara et al., 2000) and CoBrITE (Rezgui et al., 2003), make it easier to record the data, which is essential for the next stages of RE and support the RM activities, but they were not broadly disseminated. Some other practices like, using photographs of buildings as a reference, or a non-reference, was also a simple proposal for the elicitation and analysis of requirements (Wandahl, 2004).

To develop the analysis and prioritization activities, we found some basic techniques such as the construction of decision trees (Kamara et al., 2002). Functional Performance Specification (FPS) and Function Analysis System Technique (FAST) (Shen et al., 2004; Luo & Shen, 2008) are complementary techniques for analysis (through the how-why logic) and prioritization (through a flexibility scale) of requirements. These techniques evolved to a system called Case-Based Reasoning (CBR) (Luo et al., 2010), which is a tool that makes it easier to apply FPS and FAST via IT solutions. Also, based on these techniques and tools, a method called User Pre-Occupancy Evaluation Method (UPOEM) was developed (Shen et al., 2013) and it will be presented in the next section. QFD is also used for analysis and prioritization, applied both alone (Kamara et al., 1999) and associated with the software ClientPro (Kamara & Anumba, 2001b). QFD is acknowledged as a tool that is consolidated in the manufacturing industry and, in fact, it allows organizing and prioritizing the requirements, which is very useful for traceability and decision-making. However, using it requires exhaustive work with data when applied to projects with many requirements, therefore the practice has not been very successful (Kamara et al., 2000).

As to the specification, once again QFD was used to develop activities with or without the support of software (Kamara et al., 1999; Kamara & Anumba, 2001b). CBR is also strongly dedicated to specification (Luo et al., 2010), helping to identify functionalities and respective project solutions.

Few proposals were found for validation. This stage encounters significant obstacles in the field of construction, because often there are no prototypes for testing, other than physical or electronic models. The requirements and their project solutions can be verified, for instance, by physical or electronic models (Shen et al., 2013). From this standpoint, Building Information Modeling (BIM) technology reveals as a potential tool. Software that use it, besides having various functionalities that are useful for the designers and are not within the scope of this research study, allow the permanent visualization of the model in 3D, which enables a quick verification of the design solutions whenever necessary. Drawings and sketches also can be used to check to what extent the requirements are being met (Bendixen & Koch, 2007), but they are not very dynamic, and are limited as regard changes and the verification of incompatibilities among the subprojects.

Regarding RM, in general, software are the tools that supply the greatest contributions in practice (Kamara & Anumba, 2001b; Kamara et al., 2002; Rezgui et al., 2003; Shen et al., 2013; Jallow et al., 2014). Mechanisms such as spreadsheets and matrices can also be useful and effective (Kamara & Anumba, 2001b; Rezgui et al., 2003), but registration and handling of data are more expeditious, flexible and reliable when supported by IT. The collaborative virtual environments (Sheer et al., 2007) also provide contributions, as they allow recording and sharing of information. Establishing robust mechanisms supported by reliable and dynamic technology is a very important initiative to improve the requirements processing results (Jallow et al., 2014).

During the analysis of literature, it was remarkable that most of the techniques and tools are aimed at analysis and prioritization of the requirements (Kamara et al., 2000; Kamara & Anumba, 2001a; b; Bendixen & Koch, 2007; Luo & Shen, 2008; Luo et al., 2010). On the other hand, the stage with the least support is validation. It was also found that flexible tools depend on IT, because they can make the requirements processing less exhaustive. However, most of the software found in the literature are of academic provenance, and are not widely disseminated on the market (Kamara & Anumba, 2001b; Rezgui et al., 2003; Shen et al., 2013), which is an obstacle for practitioners. Only 50% of the papers focusing on tools have presented results based on real situations, the others were based on simulations.

3.5 Methods

Only two methods were found in the literature review. The Visual Value Clarification method (Wandahl, 2004) uses photography as a tool to express and understand the clients’ needs in the initial phases of studies on the project. It is a method focused on the identification and specification of requirements, but it does not contribute much to RE/RM in a structured manner, because it is an empirical method and limited to the initial phases of the design.

Based on the FPS and FAST techniques, UPOEM was developed using the BIM technology (Shen et al., 2013). Through UPOEM modeling can be used from the beginning to the end of the project to analyze, specify and validate requirements. The method is implemented using a software that allows storing the project information, whether it is requirements, project solutions, notes, etc., which also makes it easier to trace information. Its main limitation is that it does not prescribe procedures or indicate tools to prioritize requirements.

4 The identification of gaps and recommendations

The first gap (section 4.1) is a theoretical problem noticed during the references studying. The others are based on the analysis of the relationship between the requirements processing findings for building design with RE steps and RM activities, presented in Table 2, which is a result of the researcher’s analysis. The direct relation was marked when problems, guidelines, tools and techniques, and methods found in the literature had direct impact on the RE or RM activities, compromising their execution and results. This comparison has clarified the usefulness of propositions. The relationship between the problems and solutions (guidelines, tools and methods) were also analyzed to identify gaps between them.

Table 2
Summary table of problems, guidelines, tools and techniques, and methods for the requirements processing in building design and their relationship with RE and RM.

			Requirements Processing
			RE steps				RM activities				Impact on the process
	How is the relationship between the findings below and the activities/steps beside? ●= direct ○= indirect		Elicitation	Analysis and Prioritization	Specification	Validation	Documentation and storage	Communication and collaboration	Tracking and traceability	Change management	●	○
1. Problems and Critial Factors	1.1 Lack of open and effective communication		●	●	●	○	○	●	○	●	5	3
	1.2 Lack of clarity of the objectives of the project		●	●	●	○	○	○	○	●	4	4
	1.3 Lack of precision in the definition of clients’ requirements		●	○	○	○	○	●	○	●	3	5
	1.4 Client inexperience		●	○	●	●	○	●	○	○	4	4
	1.5 Lack of established measurable targets for the design process		●	○	●	○	○	●	○	○	3	5
	1.6 Lack of formalization		●	●	●	●	●	●	●	●	8	0
	1.7 Lack of inclusion of the end-user clients in the whole design process		●	●	○	●	○	○	○	○	3	5
	1.8 Difficulties in accommodating the requirements of all involved		●	●	●	○	○	●	○	●	5	3
	1.9 Lack of clarity about why a decision was made		●	●	●	●	●	●	●	●	8	0
	1.10 Lack of evaluation of how much the solutions given fulfill the clients’ requirements		○	○	●	●	○	●	●	○	4	4
	1.11 Lack of experience of the design team to perform the requirements processing		●	●	●	●	●	●	●	●	8	0
	1.12 Lack of comprehensive frameworks, and applied methods and tools to perform requirements processing		●	●	●	●	●	●	●	●	8	0
	Impact on RE steps or RM activities	●	11	8	10	7	4	10	5	8
		○	1	4	2	5	8	2	7	4
2. Guidelines	2.1 Stimulate communication through collaborative techniques		●	●	○	○	○	●	○	○	3	5
	2.2 Store data on shared spaces		●	●	○	●	●	●	●	●	7	1
	2.3 Record the reasons why the strategic decisions of the initial phases of the project were made		●	●	●	○	●	○	●	●	6	2
	2.4 Establish the objectives and targets for the design process		●	●	●	○	○	○	○	●	4	4
	2.5 Continuously update the requirements' database		●	●	●	○	●	●	●	●	7	1
	2.6 Include the clients more in the design process		●	●	○	●	○	●	○	○	4	4
	2.7 Ensure adequate representation of clients involved in the project		●	○	○	○	○	●	○	○	2	6
	2.8 Use simultaneous engineering techniques		●	●	●	●	○	●	○	●	6	2
	2.9 Employ specialists to manage the requirements		○	○	○	○	●	●	●	●	4	4
	2.10 Invest in the design team training		●	●	●	●	●	●	●	●	8	0
	Impact on RE steps or RM activities	●	9	8	5	4	5	8	5	7
		○	1	2	5	6	5	2	5	3
3. Tools and techniques	3.1 Interviews and meetings		●	●	●	○	○	●	○	○	4	4
	3.2 Questionnaires		●	●	○	○	○	○	○	○	2	6
	3.3 Workshops and brainstorming		●	●	○	○	○	●	○	○	3	5
	3.4 Matrices and spreadsheets		○	●	●	○	●	○	●	●	5	3
	3.5 Drawings and sketches		●	○	●	●	○	○	○	○	3	5
	3.6 Photography		●	○	○	○	○	○	○	○	1	7
	3.7 Physical and electronic models		●	○	●	●	○	●	○	●	5	3
	3.8 Collaborative virtual environments		●	●	○	○	●	●	○	○	4	4
	3.9 ClientPro		○	●	●	○	●	●	●	●	6	2
	3.10 CoBrITE		○	○	○	○	●	●	●	●	4	4
	3.11 QFD		○	●	●	○	●	○	●	○	4	4
	3.12 FAST		○	●	●	○	●	○	●	○	4	4
	3.13 FPS		○	●	○	○	○	●	○	○	2	6
	3.14 CBR		○	●	●	○	●	●	●	●	6	2
	3.15 BIM technology		○	○	●	●	●	●	●	●	6	2
4. Methods	4.1 UPOEM		○	●	●	●	●	●	●	●	7	1
	4.2 VVC		●	○	●	○	○	●	○	○	3	5
	Impact on RE steps or RM activities	●	8	11	11	4	9	11	8	7
		○	9	6	6	13	8	6	9	10

4.1 Lack of consensus on requirements processing key concepts, scope and coverage

Since the keywords and related terms were established to compose the research argument, it was found that a broader set of words should be researched to include all possible contributions involving this topic. In general the lack of consensus in the definition of requirements processing key-concepts, scope and coverage is an obstacle that makes it difficult for researchers and practitioners gathering information together about problems and the best practices in order to compare them and develop new contributions. Still, this conceptual and terminological variation do not seems to be associated with an evolution over time, but with certain lines of thought.

The understanding of what was covered by the term “client”, for example, varied considerably. Most of the papers refer to a client as someone who is funding the project (Kamara et al., 1999; Bluyssen et al., 2010; Jensen, 2011; Tang & Shen, 2013; Shen et al., 2013), and they may be the end user or the sponsor. Yu et al. (2005), state that it is difficult to find the path to satisfy the diversity of interests due to the differences between “user-clients” and “paying-clients”, but that it the most important aspect is to capture everyone’s requirements, since all must be considered clients (Yu et al., 2005). Clients may also be considered all those who are interested, collaborate or expect to obtain some benefit from the project (Kamara et al., 2000; Thyssen et al., 2010), and this complete group of interested people is also called stakeholders by some authors (Wandahl, 2004; Jensen, 2011). This is an example of term to be better defined.

To solve the problem about the lack of consensus about key concepts, the main definitions were grouped in Table 3. After comparing and analyzing them, we propose a definition that better fit in the building design concept. The justification and the base-references are also presented.

Table 3
Definition of key concepts.

Key-Concept	Main definitions in literature	Proposed definition	Justification for the definition	References for the definition
Briefing	The elicitation and presentation of client requirements (and other project requirements) is done through the briefing process (Kamara et al., 2001). Brifing is the process running throughout a construction project by which the requirements of the client and other relevant stakeholders are progressively captured, interpreted, confirmed and then communicated to the design and construction team (Rezgui et al., 2003). Briefing involves informing the project team of the client’s intentions for the project and documenting the objectives, needs and requirements in a brief (Yu, 2006). Briefing is the process by which client requirements are identified, clarified, and articulated in the early design stage of construction projects (Yu et al., 2008). Process through which a client informs others of his/her needs, aspirations, and desires for a project (Luo et al., 2010). Briefing starts at the pre- project stage to create a basis for the project decision and can include a number of different processes with varying purposes before and during the design and construction activities (Jensen, 2011). Briefing is not just about specifying needs as requirements but also about evaluating how well design proposals fulfil needs and aspirations (Jensen, 2011). Process of gathering, analyzing, and synthesizing information needed in the building process in order to inform decision-making and decision implementation. (Tang & Shen, 2013) Briefing is the information gathering stage which precedes the the design stage (RIBA, 2013). Briefing is one of the earliest phases of any construction project. This includes client requirements elicitation, analysis, specification and validation. It is a process to gather and determine client needs, wishes and expectations for a building leading to statements of architectural problem and the requirements to be met (Jallow et al., 2014).	Briefing is a process at the beginning of the building design process, usually before the first drawings, through which the design objectives and stakeholders should be defined as well as their wants, needs and design constraints should be identified and clarified in order to be considered along the project.	This is the most usual position considered in the researches and practical guides of the field (building design).	(Yu, 2006; Yu et al., 2008; Luo et al., 2010; Jensen, 2011; RIBA, 2013; Tang & Shen, 2013).
Brief	A brief is a formal document setting out the client's requirements in detail (Construction Industry Board, 1997). Brief is the document which contains the requirements identified through the briefing process. It is a manner to register clients’ needs and wants (Kamara et al., 2001). The design brief is a statement of requirements that ideally should contain everything a designer needs to know about a client’s proposed project (Hansen & Vanegas, 2003). The brief is the elaboration and presentation of client requirements and a communication tool to facilitate dialogue between client and designer (Wandahl, 2004). A brief is the document that defines client requirements for a building. (Luo & Shen, 2008). The brief, which is the main product of briefing, is a document defining at any point in time the relevant needs, aims, and resources of the clients and users, the context of the project and any project requirements (Chung et al., 2009). The outcome of the briefing process is a brief, a document detailing the information about client requirements (Jallow et al., 2014).	The brief is the outcome of the briefing process, which formalizes the goals, wants, needs and constraints of the stakeholders to be considered in the project. It should be regularly consulted, updated and detailed throughout the project.	This is the most usual position considered in the references of the field (building design).	(Construction Industry Board, 1997; Hansen & Vanegas, 2003; Luo & Shen, 2008; Chung et al., 2009; Jallow et al., 2014).
Value Management	Value management is a goal-setting process that aims to satisfy the client’s project requirements (Leung et al., 2002). Value management is a structured and analytical process that seeks to achieve value for money by providing all the necessary functions at the lowest cost consistent with required levels of quality and performance (Yu et al., 2005). Many researchers have proposed using value management in construction briefing as a means of eliciting, clarifying, and specifying client's requirements (Luo et al., 2011). Value management is concerned with defining what ‘value’ means to a client within a particular project context by bring the project stakeholders together and producing a clear statement of the project's objectives (Luo et al., 2011).	Value management is concerned with defining what ‘value’ means to a client within a particular project, and leading all the necessary processes and actions to reach that value at the lowest cost, but consistent with required levels of quality and performance.	Definition based on a combination of findings in the literature.	(Leung et al., 2002; Yu et al., 2005; Luo et al., 2011).
Requirements Engineering	Requirements engineering is a cyclic process to elicit, analyse, register and verify the functions and restrictions of a system (Sommerville, 2005). Requirements Engineering is concerned with the real world problems to be addressed by a software system and is focussed on the elicitation, analysis, specification and validation of software requirements (Jallow et al., 2014). Requirements engineering isdescribed as “finding what shall actually be built,” and requirements management entails ensuring that the engineered requirements are usable and up to date throughout the pro- ject (Kim et al., 2015).	Requirements engineering focuses on solving the problems to be addressed by a product development through a cyclical process of identifying, analyzing, prioritizing, defining solutions and validating requirements	Definition based on a combination of findings in the literature.	(Sommerville, 2005; Jallow et al., 2014; Kim et al., 2015).
Requirements management	Requirements management aims to control the changes by tracking requirements (Bray, 2002). It is the process that aims to maintain the project requirements up to date after the identification step (Kiviniemi, 2005). Requirements management is a cyclical process that seeks to establish and maintain agreement between the client, the development team and everyone involved in the project (Sommerville, 2007). Management of the requirements information is important for visibility, tracking and traceability of client needs (Jallow et al., 2014). RM focuses on the activities dealing with the requirements once they have been elicited. These are: the mechanisms for requirements documentation and storage, access and retrieval, distribution, managing changes, traceability and dependency checking and communication (Jallow et al., 2014) While the requirements engineering process focuses on identifying and formalizing the requirements of a project, requirements management focuses on keeping these requirements usable and up to date throughout the project (Kim et al., 2015).	Requirements management is a continuous process during the cyclical stages of identification, analysis, prioritization, specification and validation of requirements that occur throughout the project, and aims to facilitate the registration, recovery and ongoing tracking of such requirements in order to control their changes.	Definition based on a combination of findings in the literature.	(Bray, 2002; Sommerville, 2007; Jallow et al., 2014).
Client	The term “client” refers to the person(s) or firm responsible for initiating/commissioning/promoting and paying for the de- sign and construction of a facility (Kamara et al., 1999). Building-owner(s) and end-user(s) of the building. Other project stakeholders, such as the community, are assumed to provide input to the Project through the Client(s) and Project Team (Kiviniemi, 2005). The client can be a single person or multi-headed client. Multi-headed client may be an organisation, or group of clients, made up of individuals with differing wants and desires (Yu et al., 2005). The term ‘client’ usually covers a wide range of stakeholders (Thyssen et al., 2010). Among these stakeholders is the client who states the purpose of the project and the needs and expectations to be delivered or achieved at the end of a project (Jallow et al., 2014).	Clients are people or organizations that promote a project. They may be end users, the sponsor, or even other type of stakeholders.	This is the most usual position considered in the references of the field (building design). Either explicitly or implicitly, the studies that address requirements in the design process treated as “clients” people or organizations that promote the project or enterprise - being the end users or not.	(Kamara et al., 1999; Yu et al., 2005; Thyssen et al., 2010).
Users	The person, or persons, who operate or interact directly with the product (Institute of Electrical and Electronics Engineers, 1998). “User-clients” – É o cliente que irá usar a edificação (Yu et al., 2005).	Users are people who use the built environment throughout its life cycle, either for its finality (eg live, study, work) or to operationalize it.	This is the most usual position considered in the references of the field (building design), often implicitly in the context. There are few explicit statements on this term.	(Chinyio et al., 1998; Luck et al., 2001; Othman et al., 2004; Wandahl, 2004; Yu et al., 2005; Luck & McDonnell, 2006; Soetanto et al., 2006; Jensen, 2011; Chandra & Loosemore, 2011; Jay & Bowen, 2011).
Sponsor	“Paying clients” é o cliente que irá patrocinar a edificação (Yu et al., 2005). The person or group with the financial resources in cash or in kind for the project (Project Management Institute, 2013).	The person or group with the financial resources in cash or in kind for the project (Project Management Institute, 2013).	This is the most usual position considered in the references, often implicitly in the context.	(Wandahl, 2004; Yu et al., 2005; Project Management Institute, 2013).
Stakeholder	Stakeholders are persons or organizations who are actively involved in the project, or whose interests may be positively or negatively affected by the performance or completion of the project (Project Management Institute, 2013). The term stakeholders include clients, designers, project team members and end-users in a project (Chung et al., 2009).	Stakeholders are persons or organizations who are actively involved in the project, or whose interests may be positively or negatively affected by the performance or completion of the project (Project Management Institute, 2013).	The widely accepted and widespread definition of the Project Management Institute (PMI) was adopted.	(Project Management Institute, 2013).
Needs	Need is a state of deprivation of some basic satisfaction (Kotler, 1991). Circumstances in which something is necessary, or that require some course of action (Oxford University Press, 2010). A condition or situation in which something must be supplied in order for a certain condition to be maintained or a desired state to be achieved (American Heritage, 2011).	Need is deprived state in which something must be provided to achieve or maintain a certain condition or situation.	Definition based on a combination of findings of the marketing literature and dictionaries, as it was not found a precise definition in the sytematic review references.	(Kotler, 1991; American Heritage, 2011).
Wants	Wants are desires for specific satisfiers of needs. Although people’s needs are few, their wants are many (Kotler, 1991). Wants are objects (goods or services) for satisfying cravings for mental and physical pleasures (Chinyio et al., 1998). A strong feeling of wanting to have something or wishing for something to happen (Oxford University Press, 2010).	Desire is the feeling of wanting to have something or that something happens to meet physical or mental pleasures.	Definition based on a combination of findings of the marketing literature and dictionaries, as it was not found a precise definition in the sytematic review references.	(Chinyio et al., 1998; Oxford University Press, 2010).
Restrictions	A restriction is a condition to be checked, limited, or forced to avoid some action or result. It limits the space to be designed and are formulated to allow the rejection of unacceptable alternatives (Dym & Little, 2008).	A restriction is a condition to be checked, limited, or forced to avoid some action or result. It limits the space to be designed and are formulated to allow the rejection of unacceptable alternatives (Dym & Little, 2008).	Definition based on design, as it was not found a precise definition in the sytematic review references.	(Dym & Little, 2008).
Requirements	A requirement is a statement identifying capability, physical characteristics, or quality factor that bounds a product or process need for which solution will be pursued (Institute of Electrical and Electronics Engineers, 1995). Requirements are features that a product or service must have to satisfy demands or to achieve customers’ goals, qualified by measurable conditions and bounded by constraints (Parviainen et al., 2005). A statement of quality or desired property of the building or its parts (Kiviniemi, 2005). Requirements may be regarded as measurable statements of the client’s needs which are transformed into an architectural design and subsequently into a finished facility (Jallow et al., 2014).	Requirement is a statement that prescribes features that a product or service must have to satisfy demands or to achieve project stakeholders’ goals.	Definition based on a combination of findings in the literature.	(Institute of Electrical and Electronics Engineers, 1995; Parviainen et al., 2005).
Specifications	Specifications limit the range of valid designs, but do not specify any particular design (Institute of Electrical and Electronics Engineers, 1998). Requirements should be represent in a solution-neutral format that can be understood by the different disciplines working on a project (Kamara et al., 2000). Specification is a design-neutral information which allow all team members to communicate more effectively (Luo et al., 2010). A detailed, exact statement of particulars, especially a statement prescribing materials, dimensions, and quality of work for something to be built,installed, or manufactured (American Heritage, 2011).	Specification is a prescription associated with a requirement which indicate the attributes and limitations to be met by design solutions.	Definition based on a combination of findings in the literature.	(Institute of Electrical and Electronics Engineers, 1998; Kamara et al., 2000; Luo et al., 2010; American Heritage, 2011).
Design Solution	The act or process of solving a problem (American Heritage, 2011). Design solutions are subsequently used to facilitate the construction of the facility as well as to aid material procurement process (Jallow, 2011).	Design solution is the decision or action chosen to meet the design requirements, which must be limited by the specifications.	This is the most usual position considered in the references of the field (building design), often implicitly in the context.	(Luck & McDonnell, 2006; Shen et al., 2013; Jallow, 2011).

Concerning the scope and coverage of requirements processing, we begin by stating that the phases of the design process are regularly defined in studied AEC researches. However, there is lack of clearness about how continuous requirements processing (RE steps and RM activities) is performed during those design phases. The authors studied have different attitudes regarding the scope and coverage of requirements processing. Besides overlapping objectives and expected benefits there are also variations regarding the understanding of when it begins, when it ends, and its interfaces with the design phases. Even in research using the word “briefing” to approach the requirements processing (93%) there is no consensus regarding what this process is.

Most of the authors who use the term briefing, call it a process that occurs in the initial stages of the project (Kamara et al., 1999; Yu et al., 2007; Tang et al., 2013; Yu & Shen, 2013). Some of them acknowledge that changes in the project process are inevitable and that the brief should be flexible enough to guide the changes in requirements (Yu et al., 2007; Yu & Shen, 2013). But they do not really consider that new requirements come out not only due to changes in scope or needs, but as a natural result of the project evolution and of the deployment of general requirements for the most specific ones (Othman et al., 2004).

According to this reasoning, there is another group of researchers who say that “briefing” is a continuous process and that it should accompany the project throughout its life cycle (Luck et al., 2001; Othman et al., 2004; Jensen, 2011), as Table 3 shows. They say that a brief is not an hermetic object but a decisive and interactive document in which the clients’ requirements must be recorded, in order to slowly incorporate them into the project (Ryd, 2004). Figure 3 shows a simplified illustration of these two views.

Figure 3
(a) Briefing before and at the beginning of the design process; (b) Briefing throughout the project life cycle.

The point is that even the research studies that acknowledge that the briefing should be continuous present practices turned to the initial phase of the project. Thus, it appears to be consistent to accept that the briefing is historically an initial design stage of identification of demands and if the set of requirements evolves throughout the project (become more specific, are eliminated, appear, are altered), i.e., if it changes, RE and RM are the continuous and cyclic processes during the whole project life cycle (preparation, briefing, design, construction, facility management) that should make the requirements up to date. Making a closer approach to the SE concepts might be a way to better clarify how the requirements develop throughout the design process, and how they feed the next project phases. The scheme in the Figure 4 illustrates this view.

Figure 4
Scheme of the requirements processing for building projects.

Following this logic, each cycle can be a milestone and an opportunity to evaluate the progress of the project in the light of the fulfillment of the requirements. It should be also recognized that, despite the fact that the RE stages always aim at the same objective, there may be variations as to the type of tools to be used in each design phase, since each one has different characteristics (i.e. number of people involved and the level of specificity of the requirements). In addition, accepting that the requirement processing is continuous, the information registration, storage, tracking and traceability make all sense, and the study of RE and RM tools applied to each phase of the project becomes a broad opportunity for future research.

4.2 Some disconnection between problems and solutions

The first impression of Table 2 is the balance between the number of approaches related to RE and RM. Concerning the RE, we found tools to all the steps and the first question raised is how much are they useful in each cycle of Figure 4. The studies usually cover the first design stages and do not develop to the next ones. There are also perceptions about two important moments for the value generation: requirements elicitation and validation. There are many problems and guidelines directly linked to requirements elicitation and the tools for this step are basic techniques – what is also found in SE researches. Thus, we can say that elicitation depends more on good inquiring and registering than complex tools, i.e., it depends on people’s ability and attitude. Concerning validation, this step has mainly indirect relationships, what suggests that little attention has been dedicated to this very important step.

Concerning RM, the most problematic activities according to the references are communication and change management. As to communication, there are also many guidelines and tools. However, change management needs more support of guidelines and tools, and, once it depends on documentation, storage and traceability, the study of the problems on these correlated RM activities must increase.

Therefore, it was noted by making comparisons between the groups of Table 2 that, despite the efforts on proposing alternatives for improvement of requirements processing, we have found some disconnection between the critical problems and the proposed solutions. As a recommendation, these critical aspects should be recognized and evaluated as part of the whole process, so they could indicate the way for more efficient solutions.

4.3 Lack of availability of applied methods and IT tools

Many of the problems listed from the literature review can be solved through the listed guidelines and tools of Table 2. As examples, we can mention the problems of formalization (1.6) and clearness (1.8), which are some of the broadest ones, and the problems that affect communication. It was perceived, despite that we found some models (e. g. Jallow et al., 2014) and many tools (Table 2), so far there is no methods that face the complexity and amplitude of requirements processing, connecting it to the design process and elucidating which phases, tools and activities are correlated. With adequate models and methods, the objectives and importance of the requirements processing might be better understood and it would be possible to create an environment favorable to the introduction of better practices.

We also found little IT support. BIM are recognized as relevant technologies, which associated to specific support, would facilitate work with data, professionals’ communication and requirements validation, as previously mentioned. Besides, most of the IT tools were developed and tested in academic environments, and did not reach the market, which leads to doubts about their applicability, efficacy and compatibility with the practitioners’ skills. This is an indication that IT solutions should be brought closer to real users, as these methods should include people education.

4.4 Designers’ lack of knowledge and experience

Although the clear need for applied methods and tools to effectively overcome the requirements processing problems, one of our clearest findings is that the requirements processing problems are closely related to the need for experience and training of the design team. To demonstrate this perception, we can state that in a timeless manner, the difficulties in implementing open and effective communication were named as an important problem to be overcome in RM. Some solutions were reported, such as using collaborative virtual environments, promoting workshops and meetings, among others, but they will only work if people involved understand and commit themselves to these actions. The lack of clarity in generating and formalizing information that shows the whys and wherefores of decision making and allow traceability, lack of precision in defining the client requirements, lack of an evaluation of design solutions are other problems which depend of people, not only tools.

IT solutions can greatly help, for example, in the prioritization and validation activities (RE), and tracking and traceability (RM), but, again, they depend on proper collection and information entry by the design team. Barrett et al. (1999), more than a decade ago, reported this possible failure on training professionals for this type of activity. Thus, it is concluded that, even if more reliable, dynamic and inclusive tools are developed, RE and RM will only work when people are prepared to develop them, and when such practices and tools are compatible with their skills and attitudes. The verification of the perceived valued and the motivation of practitioners on the use of new RE/RM tools, in detriment to tacit practices, is an investigation that can bring insights for future research.

5 Conclusions

This systematic review aimed at summarizing the concepts and practices for the requirements processing in the building design, discussed in the last fifteen years, and at indicating the main gaps that remained. As delimitation, even understanding that the processing of requirements follows the entire project life cycle, this study is focused on the design phase. It was found that, even its importance and main limitations have been known for decades, important gaps remained to be explored in a future work. We found (i) lack of consensus on requirements processing key concepts, scope and coverage, (ii) some disconnection between problems and solutions, (iii) lack of availability of structured and applied methods and IT tools, (iv) designers’ lack of knowledge and experience with requirements processing. In order to contribute the first problem (i), the main definitions of key concepts were grouped, analyzed and an ultimate definition was proposed by the authors in order to contribute as a basis for future research on this theme. A scheme of the main project and requirements processing stages is also illustrate in Figure 4.

The gaps found may show good theoretical and practical opportunities for research about the development of building projects, especially if the studies come together with the practical application, besides the academic simulation, which is a common characteristic of the studies that have been performed until now. The gaps led to some recommendations for future research: (i) validate the proposed definitions for the key concepts; (ii) developing the scheme of Figure 4 by studying RE and RM practices applied to each project phase; (iii) focusing more effort on the alignment of solutions to the root of the problems; (iv) developing requirements processing methods and IT tools aligned to the practitioners skills; (v) investigating the perceived valued and the motivation of practitioners on the use of new RE/RM tools in detriment to the tacit practices.

• How to cite this article: Pegoraro, C., & Paula, I. C. (2017). Requirements processing for building design: a systematic review. Production, 27, e20162121. http://dx.doi.org/10.1590/0103-6513.212116.

References

• American Heritage. (2011). American Heritage® Dictionary of the English Language (5th ed.). Boston: Houghton Mifflin Harcourt Publishing Company.
• Arayici, Y., Manchester, G., Ahmed, V., & Aouad, G. (2006). A requirements engineering framework for integrated systems development for the construction industry. ITCon, 11, 35-55.
• Barrett, P. S., Hudson, J., & Stanley, C. (1999). Good practice in briefing: the limits of rationality. Automation in Construction, 8(6), 633-642. http://dx.doi.org/10.1016/S0926-5805(98)00108-3
  » http://dx.doi.org/10.1016/S0926-5805(98)00108-3
• Barrett, P. S., & Stanley, C. (1999). Better construction briefing. Oxford: Blackwell Science.
• Bendixen, M., & Koch, C. (2007). Negotiating visualizations in briefing and design. Building Research and Information, 35(1), 42-53. http://dx.doi.org/10.1080/09613210600950401
  » http://dx.doi.org/10.1080/09613210600950401
• Biolchini, J., Mian, P. G., Candida, A., & Natali, C. (2005). Systematic Review in Software Engineering. Rio de Janeiro: UFRJ.
• Bluyssen, P. M., Oostra, M. A R., & Böhms, H. M. (2010). A top-down system engineering approach as an alternative to the traditional over-the-bench methodology for the design of a building. Intelligent Buildings International, 2(2), 98-115. http://dx.doi.org/10.3763/inbi.2010.0022
  » http://dx.doi.org/10.3763/inbi.2010.0022
• Bray, I. K. (2002). An introduction to requirements engineering. London: Pearson Education.
• Chandra, V., & Loosemore, M. (2011). Communicating about organizational culture in the briefing process: case study of a hospital project. Construction Management and Economics, 29(3), 223-231. http://dx.doi.org/10.1080/01446193.2010.521756
  » http://dx.doi.org/10.1080/01446193.2010.521756
• Chinyio, E., Olomolaiye, P. O., & Corbett, P. (1998). An evaluation of the project needs of UK building clients. International Journal of Project Management, 16(6), 385-391. http://dx.doi.org/10.1016/S0263-7863(98)00001-5
  » http://dx.doi.org/10.1016/S0263-7863(98)00001-5
• Chung, J. K. H., Kumaraswamy, M. M., & Palaneeswaran, E. (2009). Improving megaproject briefing through enhanced collaboration with ICT. Automation in Construction, 18(7), 966-974. http://dx.doi.org/10.1016/j.autcon.2009.05.001
  » http://dx.doi.org/10.1016/j.autcon.2009.05.001
• Construction Industry Board – CIB. (1997). Briefing the team. London: Thomas Telford.
• Dym, C. L., & Little, P. (2008). Engineering design: a project based introduction (3th ed.). New York: Wiley.
• Elf, M., Svedbo Engström, M., & Wijk, H. (2012). An assessment of briefs used for designing healthcare environments: a survey in Sweden. Construction Management and Economics, 30(10), 835-844. http://dx.doi.org/10.1080/01446193.2012.702917
  » http://dx.doi.org/10.1080/01446193.2012.702917
• Hansen, K. L., & Vanegas, J. (2003). Improving design quality through briefing automation. Building Research and Information, 31(5), 379-386. http://dx.doi.org/10.1080/0961321032000105395
  » http://dx.doi.org/10.1080/0961321032000105395
• Higgins, J. P., & Green, S. (2011). Cochrane Handbook for Systematic Reviews of Interventions. The Cochrane Collaboration.
• Hyams, D. (2001). Construction companion to briefing. London: RIBA Publications.
• Institute of Electrical and Electronics Engineers – IEEE. (1995). IEEE trial-use standard for application and management of the systems engineering process. New York.
• Institute of Electrical and Electronics Engineers – IEEE. (1998). IEEE Recommended Practice for Software Requirements Specifications. New York.
• Jallow, A. K. (2011). Integrated lifecycle requirements information management in construction. Loughborough University.
• Jallow, A. K., Demian, P., Baldwin, A. N., & Anumba, C. (2014). An empirical study of the complexity of requirements management in construction projects. Engineering, Construction, and Architectural Management, 21(5), 505-531. http://dx.doi.org/10.1108/ECAM-09-2013-0084
  » http://dx.doi.org/10.1108/ECAM-09-2013-0084
• Jay, I., & Bowen, P. (2011). What residents value in low-cost housing schemes: some South African concepts. Building Research and Information, 39(6), 574-588. http://dx.doi.org/10.1080/09613218.2011.617082
  » http://dx.doi.org/10.1080/09613218.2011.617082
• Jensen, P. A. (2011). Inclusive briefing and user involvement: case study of a media centre in Denmark. Architectural Engineering and Design Management, 7(1), 38-49. http://dx.doi.org/10.3763/aedm.2010.0124
  » http://dx.doi.org/10.3763/aedm.2010.0124
• Kamara, J. M., & Anumba, C. J. (2001a). A critical appraisal of the briefing process in construction. Journal of Construction Research, 2(1), 13-24.
• Kamara, J. M., & Anumba, C. J. (2001b). ClientPro: a prototype software for client requirements processing in construction. Advances in Engineering Software, 32(2), 141-158. http://dx.doi.org/10.1016/S0045-7949(00)00142-5
  » http://dx.doi.org/10.1016/S0045-7949(00)00142-5
• Kamara, J. M., Anumba, C. J., & Evbuomwan, N. F. O. (1999). Client requirements processing in contruction: a new approach using QFD. Journal of Architectural Engineering, 5(1), 8-15. http://dx.doi.org/10.1061/(ASCE)1076-0431(1999)5:1(8)
  » http://dx.doi.org/10.1061/(ASCE)1076-0431(1999)5:1(8)
• Kamara, J. M., Anumba, C. J., & Evbuomwan, N. F. O. (2000). Computer-Based Application for the Processing of Clients’ Requirements. Journal of Computing in Civil Engineering, 14(4), 264-271. http://dx.doi.org/10.1061/(ASCE)0887-3801(2000)14:4(264)
  » http://dx.doi.org/10.1061/(ASCE)0887-3801(2000)14:4(264)
• Kamara, J. M., Anumba, C. J., & Evbuomwan, N. F. O. (2001). Assessing the suitability of current briefing practices in construction within a concurrent engineering framework. International Journal of Project Management, 19(6), 337-351. http://dx.doi.org/10.1016/S0263-7863(00)00015-6
  » http://dx.doi.org/10.1016/S0263-7863(00)00015-6
• Kamara, J. M., Anumba, C. J., & Evbuomwan, N. F. O. (2002). Capturing client requirements in construction projects. London: Thomas Telford.
• Kelly, J., & Duerk, D. (2002). Construction project briefing/ architectural programming. In J. Kelly, R. Morledge & S. J. Wilkinson (Eds.), Best value in construction. Oxford: Wiley-Blackwell. 324 p.
• Kim, T. W., Kim, Y., Cha, S. H., & Fischer, M. (2015). Automated updating of space design requirements connecting user activities and space types. Automation in Construction, 50, 102-110. http://dx.doi.org/10.1016/j.autcon.2014.12.010
  » http://dx.doi.org/10.1016/j.autcon.2014.12.010
• Kiviniemi, A. (2005). Requirements management interface to building product models. Stanford: Stanford University.
• Kotler, P. (1991). Marketing management: analysis, planning, implementation and control (7th ed.). London: Prentice-Hall.
• Leung, M., Ng, S. T., & Cheung, S. (2002). Improving satisfaction through conflict stimulation and resolution in value management in construction projects. Journal of Management Engineering, 18, 68-75. http://dx.doi.org/10.1061/(ASCE)0742-597X(2002)18:2(68)
  » http://dx.doi.org/10.1061/(ASCE)0742-597X(2002)18:2(68)
• Luck, R., Haenlein, H., & Bright, K. (2001). Project briefing for accessible design. Design Studies, 22(3), 297-315. http://dx.doi.org/10.1016/S0142-694X(00)00031-4
  » http://dx.doi.org/10.1016/S0142-694X(00)00031-4
• Luck, R., & McDonnell, J. (2006). Architect and user interaction: the spoken representation of form and functional meaning in early design conversations. Design Studies, 27(2), 141-166. http://dx.doi.org/10.1016/j.destud.2005.09.001
  » http://dx.doi.org/10.1016/j.destud.2005.09.001
• Luo, X., Shen, G. Q., Fan, S., & Xue, X. (2011). A group decision support system for implementing value management methodology in construction briefing. International Journal of Project Management, 29(8), 1003-1017. http://dx.doi.org/10.1016/j.ijproman.2010.11.003
  » http://dx.doi.org/10.1016/j.ijproman.2010.11.003
• Luo, X., & Shen, Q. (2008). A computer-aided FPS-oriented approach for construction briefing. Tsinghua Science and Technology, 13, 292-297. http://dx.doi.org/10.1016/S1007-0214(08)70164-0
  » http://dx.doi.org/10.1016/S1007-0214(08)70164-0
• Luo, X., Shen, Q., & Fan, S. (2010). A case-based reasoning system for using functional performance specification in the briefing of building projects. Automation in Construction, 19(6), 725-733. http://dx.doi.org/10.1016/j.autcon.2010.02.017
  » http://dx.doi.org/10.1016/j.autcon.2010.02.017
• Othman, A. A. E., Hassan, T. M., & Pasquire, C. L. (2004). Drivers for dynamic brief development in construction. Engineering, Construction, and Architectural Management, 11(4), 248-258. http://dx.doi.org/10.1108/09699980410547603
  » http://dx.doi.org/10.1108/09699980410547603
• Oxford University Press. (2010). New Oxford American Dictionary (3th ed.). Oxford: Oxford University Press.
• Parviainen, P., Tihinen, M., & Van Solingen, R. (2005). Requirements engineering: dealing with the complexity of Sociotechnical Systems Development. In J. L. Mate & A. Silva (Eds.), Requirements engineering for sociotechnical systems. Hershey: Information Science Publishing.
• Pegoraro, C. (2016). Processamento de requisitos em projetos de ambientes construídos: caracterização e contribuições para melhorias a partir das percepções dos profissionais que desenvolvem projetos (Doctor thesis). Universidade Federal do Rio Grande do Sul, Porto Alegre.
• Project Management Institute – PMI. (2013). PMBOK guide (5th ed.). Pennsylvania.
• Rezgui, Y., Bouchlaghem, D., & Austin, S. (2003). An IT-based approach to managing the construction brief. International Journal of IT in Architecture, Engineering and Construction, 1(1), 25-37.
• RIBA. (2013). Plan of Work 2013. London.
• Ryd, N. (2004). The design brief as carrier of client information during the construction process. Design Studies, 25(3), 231-249. http://dx.doi.org/10.1016/j.destud.2003.10.003
  » http://dx.doi.org/10.1016/j.destud.2003.10.003
• Sheer, S., Mendes, R. Jr, Quevedo, J. R. S., Mikaldo Junior, J., & Fontoura, P. S. (2007). The necessary background for implementing and managing building design processes using web environments. ITCon, 12, 221-230.
• Shen, Q., & Chung, J. K. H. (2002). A group decision support system for value management studies in the construction industry. International Journal of Project Management, 20(3), 247-252. http://dx.doi.org/10.1016/S0263-7863(01)00076-X
  » http://dx.doi.org/10.1016/S0263-7863(01)00076-X
• Shen, Q., Li, H., Chung, J., & Hui, P. (2004). A framework for identification and representation of client requirements in the briefing process. Construction Management and Economics, 22(2), 213-221. http://dx.doi.org/10.1080/0144619042000201411
  » http://dx.doi.org/10.1080/0144619042000201411
• Shen, W., Zhang, X., Shen, Q., & Fernando, T. (2013). The user pre-occupancy evaluation method in designer-client communication in early design stage: a case study. Automation in Construction, 32, 112-124. http://dx.doi.org/10.1016/j.autcon.2013.01.014
  » http://dx.doi.org/10.1016/j.autcon.2013.01.014
• Soetanto, R., Dainty, A. R. J., Glass, J., & Price, A. D. F. (2006). Towards an explicit design decision process: the case of the structural frame. Construction Management and Economics, 24(6), 603-614. http://dx.doi.org/10.1080/01446190600568173
  » http://dx.doi.org/10.1080/01446190600568173
• Sommerville, I. (2005). Integrated requirements engineering: A tutorial. IEEE Software, 22(1), 16-23. http://dx.doi.org/10.1109/MS.2005.13
  » http://dx.doi.org/10.1109/MS.2005.13
• Sommerville, I. (2007). Software engineering (8th ed.). Boston: Addison-Wesley.
• Sterry, P., & Sutrisna, M. (2007). Briefing and designing performing arts buildings: assessing the role of secondary project stakeholders. Architectural Engineering and Design Management, 3(4), 209-221.
• Tang, L., Shen, G. Q., Skitmore, M., & Wang, H. (2014). Procurement-Related Critical Factors for Briefing in Public-Private Partnership Projects: case of Hong Kong. Journal of Management Engineering, 31(6), 04014096.
• Tang, L., & Shen, Q. (2013). Factors affecting effectiveness and efficiency of analyzing stakeholders’ needs at the briefing stage of public private partnership projects. International Journal of Project Management, 31(4), 513-521. http://dx.doi.org/10.1016/j.ijproman.2012.10.010
  » http://dx.doi.org/10.1016/j.ijproman.2012.10.010
• Tang, L., Shen, Q., Skitmore, M., & Cheng, E. W. L. (2013). Ranked Critical Factors in PPP Briefings. Journal of Management Engineering, 29(April), 164-171. http://dx.doi.org/10.1061/(ASCE)ME.1943-5479.0000131
  » http://dx.doi.org/10.1061/(ASCE)ME.1943-5479.0000131
• Thyssen, M. H., Emmitt, S., Bonke, S., & Kirk-Christoffersen, A. (2010). Facilitating client value creation in the conceptual design phase of construction projects: a workshop approach. Architectural Engineering and Design Management, 6(1), 18-30. http://dx.doi.org/10.3763/aedm.2008.0095
  » http://dx.doi.org/10.3763/aedm.2008.0095
• Wandahl, S. (2004). Visual value clarification: a method for an effective brief. Journal of Civil Engineering and Management, 10(4), 317-326. http://dx.doi.org/10.1080/13923730.2004.9636325
  » http://dx.doi.org/10.1080/13923730.2004.9636325
• Yu, A., Shen, Q., Kelly, J., & Hunter, K. (2005). Application of value management in project briefing. Facilities, 23(7/8), 330-342. http://dx.doi.org/10.1108/02632770510600281
  » http://dx.doi.org/10.1108/02632770510600281
• Yu, A., Shen, Q., Kelly, J., & Hunter, K. (2007). An empirical study of the variables affecting construction project briefing/architectural programming. International Journal of Project Management, 25(2), 198-212. http://dx.doi.org/10.1016/j.ijproman.2006.09.016
  » http://dx.doi.org/10.1016/j.ijproman.2006.09.016
• Yu, A. T. W. (2006). A value management framework for systematic identification and precise representationof client requirements in the briefing process. Hong Kong: The Honk Kong Polytechnic University.
• Yu, A. T. W., & Shen, G. Q. P. (2013). Critical success factors of the briefing process for construction projects. Journal of Management Engineering, 31(3).
• Yu, A. T. W., Shen, Q., Kelly, J., & Hunter, K. (2006). Investigation of critical success factors in construction project briefing by way of content analysis. Journal of Construction Engineering and Management, 132, 1178-1186. http://dx.doi.org/10.1061/(ASCE)0733-9364(2006)132:11(1178)
  » http://dx.doi.org/10.1061/(ASCE)0733-9364(2006)132:11(1178)
• Yu, A. T. W., Shen, Q., Kelly, J., & Hunter, K. (2008). Comparative study of the variables in construction project briefing / architectural programming. Journal of Construction Engineering and Management, 134, 122-138. http://dx.doi.org/10.1061/(ASCE)0733-9364(2008)134:2(122)
  » http://dx.doi.org/10.1061/(ASCE)0733-9364(2008)134:2(122)
• Zarooni, S., Abdou, A., & Lewis, J. (2011). Improving the client briefing for UAE public healthcare projects: space programming guidelines. Architectural Engineering and Design Management, 7(4), 251-265. http://dx.doi.org/10.1080/17452007.2011.618671
  » http://dx.doi.org/10.1080/17452007.2011.618671

Publication Dates

• Publication in this collection
  2017

History

• Received
  05 May 2016
• Accepted
  08 Feb 2017