REQUIREMENTS PROCESSING TOOLS AND THE BUILDING DESIGNERS MOTIVATION ON USE ♣

The successful development of projects requires, among other conditions, the ability to process requirements. In the construction literature, researchers have figured out that human difficulties was often at the root of Requirements Processing (RP) problems throughout the design phases, and that the employment of tools could be a key factor for RP implementation. To check these outcomes and to look at how current practitioners behave in relation to the RP tools, an exploratory case study was conducted with a building design team from a public university. The aim of this paper was to investigate the perception of benefits and the motivation of designers regarding the RP tools. The results indicated that 42% of the participants are highly motivated to use new tools and that they have more interest in tools that deal directly with design activities than in those focused on data. Validation tools aroused interest as the most useful tools for designers. 66,7% of the participants mentioned that the tools can make the design process clearer, and that training and adaptation are crucial to promote acceptance and commitment to RP. The main contribution is the indication of gaps for further research and for tools improvement from the designers’ perspective.


INTRODUCTION
The successful development of projects requires, among other conditions, the ability to process requirements.Professionals who design buildings have to deal with well-known problems associated with Requirements Processing (RP) (Barrett et al., 1999;Elf et al., 2012;Jensen 2011;Soetanto et al. 2006;Tang et al. 2013;Yu et al. 2006Yu et al. , 2008;;Yu & Shen 2013) and for decades theories and tools have been developed to manage requirements systematically throughout design phases.However, in spite of good prescriptive guidance (Shen et al., 2004;Ryd, 2004;Yu et al., 2007;Luo & Shen, 2008;Luo et al., 2010Luo et al., , 2011;;Tang et al., 2013), the poor dissemination of tools that are in line with designers' skills could be a ISSN 0717-9103 ISSN Online 0718-8307 Universidad del Bío-Bío reason for the limited recognition and formalization of the RP process.Some researchers had already found that human inabilities was potentially at the root of RP failures (Barrett et al., 1999;Yu et al. 2006).
Based on this assumption our research question is how practitioners behave in relation to the tools for RP in the building design process.To identify these tools, papers published in scientific journals over the past fifteen years were analyzed.From Information Technology (IT) tools to the more traditional techniques, sixteen possibilities were found and arranged according to four main RP steps identified.As a limitation, this study has not considered theoretical approaches, models, methods and other prescriptive guidelines since the focus was on practical tools.
Besides the literature review, an exploratory case study was conducted at the design office of a Brazilian public university.Twelve designers answered a 2-part questionnaire as described in section 3. The aim of this paper is to investigate the perception of benefits and the stated motivation of designers regarding the RP tools for building design found in the literature.The main contribution is the indication of gaps for further research and recommendations to improve the existing tools from the designers' perspective.
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).In construction, RP is commonly discussed under the term "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., 2006;Sterry & Sutrisna, 2007;Bendixen & Koch, 2007;Luo & Shen, 2008;Luo et al., 2010Luo et al., , 2011;;Al Zarooni et al., 2011;Elf et al., 2012;Tang et al., 2013;Tang & Shen, 2013) and it also interfaces with value management research (Leung et al., 2002;Luo et al., 2011;Luo et al., 2010;Yu et al. 2008).Clearer concepts were found in the literature of software engineering, in which this topic is thoroughly studied and from which we import some important definitions.In the Requirements Engineering subarea, we found basically four steps for the RP, which should be continuously traced thorough management mechanisms: (i) elicitation, (ii) analysis and prioritization, (iii) translation into the solution specification and (iv) validation.
The first step consists on stakeholder identification, data collection and organization, and the subsequent transformation of needs and wants into requirements ( Barrett et al., 1999;Chinyio et al., 1998;Shen et al., 2004).Although some more sophisticated tools like ClientPro (Kamara et al., 2000(Kamara et al., , 2001) ) and CoBrITE (Rezgui et al., 2003) have been reported due to their contribution to requirements elicitation, they actually still use the simplest and best known tools, such as interviews, questionnaires, workshops and brainstorming.The Visual Value Clarification (VVC) method (Wandahl, 2004) also proposes a simple and efficient manner for eliciting requirements through photos of reference -and non-reference -buildings taken by customers and designers.VVC can also be used for requirement analysis.
In the second step, analysis and prioritization, requirements should be examined and the importance of each of them should be evaluated.At this stage, it is common to identify conflicting requirements, especially in projects with many clients, which is typical in building projects (Shen et al., 2004).One of the most cited tools for analysis and prioritization was Quality Function Deployment (QFD).Its use can be identified both individually (Kamara, et al., 1999) and as part of softwares such as ClientPro (Kamara and Anumba 2001) and CoBrITE (Rezgui et al., 2003).It is well known that QFD is a consolidated tool for product development.Concerning RP for building design, QFD allows the organization and prioritization of requirements, which greatly helps analysis, decision making and requirements traceability.However, it requires extensive work with data when applied to projects with many requirements (Kamara et al., 2000).Functional Performance Specification (FPS) and Function Analysis System Technique (FAST) (Shen et al., 2004) are complementary tools for analysis (through a why-how structure) and prioritization (through a scale of flexibility) of requirements, which were evolved for the Case-Based Reasoning (CBR) System (Luo et al., 2010).CBR is a tool to organize data and facilitate the use of FAST and FPS through IT solutions.Finally, through the User Pre-Occupancy Evaluation Method (UPOEM) (Shen et al., 2013) it is possible to perform all the RP steps, however prioritization activities are not fully served.
In the third step, translation into the solution specification, requirements must be fulfilled through design solutions (Kamara et al., 1999).As for the second step, QFD is often used for requirement specification activities, with and without software support.ClientPro (Kamara and Anumba 2001) and CoBrITE (Rezgui et al., 2003) are examples of softwares that use it.CBR (Luo et al., 2010) is mainly focused on specification, it helps in the definition of functions and functional performance to facilitate the use of FAST and FPS.
In the fourth step, validation, it is time to identify and correct problems with requirements and its solutions through testing (Shen et al., 2013;Sommerville, 2007).These tests can be performed, for example, through physical or electronic models, such as the tool proposed by the User Pre-Occupancy Evaluation Method (UPOEM) (Shen et al., 2013).Here Building Information Model (BIM) tools arise as possibilities for the requirements validation.However, there are quite a few proposals focusing on solutions for requirements validation.
Every time changes are necessary in requirements or in their solution, the RP steps must be run again.That is why RP is a cyclical process throughout building design development (Othman et al., 2004) and that is why traceability tools exist.Traceability is the property of a requirement that reflects the ease of finding their origin and their relationships with design solutions and other requirements (Sommerville, 2007).Through adequate data storage and traceability tools, it is possible to identify who has requested a requirement, how a requirement has evolved during the project, how other requirements may be affected by its change, etc.
Examples of tools for this purpose are QFD (Kamara et al., 1999) and FAST diagrams (Shen et al., 2004).
A summary with a list of tools and techniques found in Table 1.Since there is no one omnipotent technique to solve all the problems of requirements process, they are arranged in Fig. 1 according to the RP steps and the references application for easier understanding.The arrangement indicates tools that contribute to the RP steps, which does not mean that those tools fully support all the step's activities.Some of them are focused on just some activities.The letter "t" indicates that the tool also helps in traceability.
In the Fig. 1 it is noticeable that most of the investigated tools are useful for the analysis and prioritization stages, and that validation is a wide field to be explored, especially if compared to its importance for the project results.
It was noted during the review of the literature, that most of the tools and techniques are aimed at analyzing and prioritizing requirements.Validation is the least supported step.It was also found that the most agile tools depend on IT because in this way the RP process becomes less exhausting.However, most of the software are limited to academic use, slightly disseminated throughout the market, which is a barrier for practitioners.Another general perception about the usefulness of these tools indicates that they somehow attempt to connect the project stakeholders.In this sense, it is important to mention that many authors in this field indicate that clear communication is an important aspect to be improved (Arayici et al., 2006;Bluyssen et al., 2010;Chung et al., 2009;Luck & McDonnell, 2006;Ryd, 2004;Sheer et al., 2007;Tang et al., 2013;Yu et al., 2006Yu et al., , 2008;;Yu & Shen, 2013) and all these tools contribute to this.

Research Design
This study had four main stages -literature review, case study, analysis and discussion -

Literature Review Process
The review procedures were oriented by a specific method (Biolchini et al., 2005) and a complete systematic review have already been published by the same authors.The beginning of the review was a search in three scientific databases (ScienceDirect, Taylor & Francis Online and American Society of Civil Engineers/ASCE) covering the period between 1997 and 2014.The search string ("requirements management" OR "requirements processing" OR "requirements engineering" OR briefing OR brief) AND (project OR design) AND (construction OR building OR architecture OR "built environment") NOT ("software engineering") was carried out during March 2014.Filters were used to include only results from areas related to this research (e.g.architecture, engineering, construction, management and other decision sciences).The search provided 261 papers, which, after checking the availability of full-text, were analyzed according to their titles and keywords.Articles not related to RP for building design were excluded and 54 papers remained.The abstracts of these papers were examined and only papers focusing on the proposal or application of RP tools remained.Tools to manage demands, needs, among other related terms were also accepted.Fourteen papers remained and 25 other references were included, which were found through citations during the full reading.We found sixteen tools which were analyzed and arranged in four groups: tools for elicitation, analysis and prioritization, specification, and validation (Fig. 1).

Case Study
To check how professionals behave in relation to the tools found, researchers have proposed an exploratory case study.It was conducted in a design office at a Brazilian public university which has over 45000 students on its 5 campuses.Five architects and 7 engineers (3 civil, 1 mechanic, 3 electrical) participated.They correspond to 85% of the construction professionals who design buildings at that university and their profile is in Table 2.

Table 2. Profile of the case study participants
A 2-part questionnaire was submitted to the design team.The group which respond the survey was consisted of a very connected professionals, which were used to discuss aspects concerning the improvement of the design process.Through the research we wanted to express their level of knowledge and the practices into numbers to try a new understating of the scale of their problems/easiness, that is why we have used the questionnaire with closed questions.
The first part aimed at (i) identifying the designer's prior knowledge about RP and tacit RP practices, (ii) investigating how much of a benefit they thought that more sophisticated management tools would bring for their activities and (iii) investigating how motivated they felt about using new tools.To investigate item (i), it was asked how frequently they use basic techniques and mechanisms (e.g.interviews, spreadsheets, sketches, plans, etc.) to develop the four RP steps.To facilitate understanding and data collection, since the participants had little, or no, knowledge about RP, at this stage we have used terms such as customers' needs and wants instead of requirements.A 5-point Likert scale was used in responses to the three items, where number 1 represents a low score and number 5 represents a high score.
Afterwards, researchers made a brief PowerPoint presentation on RP concepts and tools identified in the literature review.Tools were presented in groups, according to Fig. 1.Then, the second part of the questionnaire was applied, which aimed at identifying the perception of benefits and the stated motivation of designers dealing with the RP tools presented.Again a 5-point Likert scale was used.In the second part, participants were also asked which practices gave them the greatest motivation to implement: the tacit practices of the first part, or the presented tools.A space was left for comments.

Methods for Data Analysis
The results were analyzed using the average response, Relative Standard Deviation (RSD) and Kruskal-Wallis tests.The Kruskal-Wallis Test is a nonparametric (distribution free) test used for comparing two or more independent samples of equal or different sample sizes.It was selected over the other methods because the associated probability distribution of data was not normal.Data distribution was tested by the Anderson-Darling Test and the p-value was < 0,05.

RESULTS AND DISCUSSION
The first result of this research was the arrangement and analysis of RP tools presented in section 2 of this paper.The arrangement indicated that there are few tools for requirements validation, as the majority is focused on analysis and prioritization activities.It was found that the most agile tools depend on IT, because it is the way to make the RP process less exhausting, as analysis indicates that main limitations involve information overload.However, IT solutions has still too complex interfaces and some unavailability.Most of the softwares cited in the literature are academic not widely disseminated, and this is a barrier for practical testing and improvement.
Regarding the case study, the results of the first part of the questionnaire have indicated that although participants have little formal knowledge and experience with RP (only 33% had already heard about RP concepts) in practice they tacitly use some unsophisticated techniques.Interviews, meetings and content analysis were the most common techniques to identify requirements (Fig. 2a), as we found in the literature review.The Kruskal-Wallis Test showed a significant difference (p<0,05) between the use of interviews and meetings, and applying a questionnaire.Regarding the form of registration of the collected demands, we found that notes and sketches are the most common techniques and individual storage was more frequent than the use of shared spaces.In this sense, compared to the literature review (Chung et al., 2009;Hansen & Vanegas, 2003;Sheer et al., 2007), some good practices of sharing and storage of information could be used even without advanced tools, such as the widespread use of the office server and of collaborative environments on the Web.
The question about prioritization activities had the lowest scores of the first part of the questionnaire, the response averages about the use of quantitative techniques were lower than 3. Three participants mentioned they performed prioritization based only on their experience and three others are used to prioritizing demands based on conversation, which is not an unusual attitude in this field (Kamara et al., 2000).The Kruskal-Wallis Test also indicated that there were significant differences (p<0,05) among answers about the verification of the design solutions.The most basic techniques (e.g.use of plans, sections, sketches, images) are significantly more used than the more advanced ones such as animations (Fig. 2b).
Finally, when asked how much of a benefit they supposed that more sophisticated tools would bring to the aforementioned RP tacit activities, 67% answered that they perceived many benefits and 75% stated that felt very motivated to use them.Besides, 58% of the participants stated that they had little or very little contact with this area throughout their undergraduate course.This is a relevant result compared to the studies that indicate that designers need preparation and training to develop their managerial skills (Barrett et al., 1999;Bluyssen et al., 2010;Othman et al., 2004;Yu et al., 2006).
After the presentation on RP concepts and tools identified in the literature review, three questions were submitted to the participants.The resulting responses are shown in Fig. 3 and 4. In general, the tools presented had high scores in both questions which meant that designers are interested in using more sophisticated tools.The Kruskal-Wallis test has indicated only one significant difference (p<0,05) between validation and analysis/ prioritization tools in the question about motivation.Concerning validation tools, besides being at the top of both rankings, the RSD of the responses was 6% and 0% respectively for Fig. 3 (a) and (b).This result suggests a particular interest compared to the results of the first part of the questionnaire, when it was evidenced that mainly basic techniques were used.A feasible explanation is that it is very difficult to test whether requirements are fulfilled in construction because usually there is no testing or real size prototypes.The interest in the use of virtual tools for validation, such as softwares that allow three-dimensional design (e.g.BIM softwares), was especially highlighted by the participants at the end of the presentation.
In addition, we recall that quite a few tools for requirements validation are proposed in the literature, which is a gap to be widely explored.Analysis and prioritization was the step which had the most tools available in the literature, however it scored low in the second part of the questionnaire (Fig. 3) -as in the first partwhich indicates that there is little interest in them.Concerning requirement analysis, this step requires data management, and it must be emphasized that with poor data storage, there is no reliable management and traceability.Here arises a problem to be solved, because, on the other hand, traceability tools were outstanding in the rankings of Fig. 3.During the presentation, participants have demonstrated great interest in verifying the impact of changes through traceability tools.But the results of the case study also indicate that, in general, there is more interest in tools that deal directly with images and design activities (e.g.UPOEM, BIM) than with those focused on data (e.g.QFD).This might be another gap to be explored, as data solutions must be developed to get benefits by exploring the abilities of the designers.
Concerning prioritization activities, skipping their formal execution is not unusual for designers, as also found in the in literature (Luck et al., 2001), but this step must be valued because it is very important for value generation.
Finally, it was asked which group of practices motivates the participants most in formal implementation: the tacit practices or the tools of the presentation.The results shown in Fig. 4  RSD indicate that engineers have more homogeneous responses than architects.We might suppose that engineers have a greater tendency to accept tools aligned with data than architects because of their skills or education, but further research is needed on this subject.Despite the small sample, the research provided important information about how designers deal with RP practices, and how they would behave in relation to new tools.The gains can be significant for practitioners, since some good practices identified in the literature are not far from the reality of designers, such as the elicitation techniques (Bendixen & Koch, 2007;Rezgui et al., 2003;Shen & Chung, 2002;Wandahl, 2004), modeling softwares and collaborative environments (Rezgui et al., 2003).From the results, it would be possible, for example, to develop action plans to improve the RP process, either by using the tools which are available but underutilized, or by implementing new tools.With regard to the new tools, BIM softwares provoked much interest in participants, because they perceived not only a tool for RP, but also for improving design activities in general.Unavailability is a significant barrier for the implementation of some advanced tools, since they are only academic versions.In the final comments 66,7% of participants mentioned that the RP tools presented can make the design process clearer.For these professionals training and adaptation time are crucial to promote understanding, acceptance and team commitment with RP.It is also important to consider that the experiment was conducted in a public institution, with its specific features.

CONCLUSIONS
The aim of this exploratory paper was to investigate the perception of benefit and the stated motivation of designers regarding the RP literature tools for building design.Results have indicated that although participants have little knowledge and formal experience with RP, they felt motivated to use the available tools and also to implement the more sophisticated ones and IT tools.In general, there was high interest in the four groups of tools presented, but tools that deal directly with design activities and images were outstanding, such as BIM tools.In this sense, validation tools were the most motivating group, however we found that quite a few of these tools are proposed in the literature.
ISSN 0717-9103 ISSN Online 0718-8307 Universidad del Bío-Bío Besides the implementation of the questionnaire survey with a bigger sample for broader results, we identified three gaps to be explored in future research: the efficiency of the usual techniques, the barriers involving the implementation of new techniques and tools (like the little motivation on the execution of database activities) and the proposal of tools and techniques specially for requirements validation.The research extracted important information about how a design team behaves in relation to the RP practices and both the participants and the literature indicated that, in addition to investment in tools' improvements -such as in IT, training and adaptation time are crucial to promote understanding, acceptance and team commitment to RP.

Figure 1 .
Figure 1.Arrangement of RP tools and techniques for building design, according to the steps and references application

Figure 2 .
Figure 2. (a) response averages about demands identification; (b) response averages about clients' demands fulfillment

Table 1 .
Summary of RP tools and techniques for building design indicate that 42% have more motivation to use the tools of the presentation and 42% have the same interest in both.It means that the team tends to be open to new approaches.Based on this sample and using a correlation analysis, there is no evidence that time of experience is correlated with the responses (r=0,15).However, results indicate a relation between the engineers and the high interest in the tools of the presentation.Moreover, averages and