Using Building Information Modelling to Manage Client Requirements in Social Housing Projects

Abstract

This paper proposes a set of guidelines for using Building Information Modelling (BIM) to manage client requirements in the context of social housing projects. A process model representing main activities involved in requirements management has been devised, as well as nine constructs that can be used for assessing the effectiveness of using BIM for client requirements management. The process of managing and modelling clients’ requirements is important to improve value generation, considering the limited resources usually available for social housing projects, as well as the need to deal with the diversity of user profiles. The use of BIM-based tools to support this process can potentially improve the performance of those projects in terms of environmental and social sustainability. Design Science Research was the methodological approach adopted in this investigation. The main outcome of this study, the set of guidelines, emerged from an empirical study carried out in a social housing project from Brazil. This study explores the managerial perspective of client requirements modelling, proposing practical contributions, such as understanding the challenges of managing requirements in social housing projects, and theoretical contributions, such as descriptions of the activities involved in client requirements management and their interactions, and constructs for assessing BIM-based solutions for that problem.

1. Introduction

Value generation in construction projects depends strongly on the identification, processing and communication of client requirements to support decision making in the design process [1]. However, there are well-known difficulties in managing client requirements in construction projects: (i) Client requirements are often poorly identified and updated [2,3]; (ii) clients’ needs change over time, and new requirements often emerge throughout project stages [4,5,6,7]; (iii) little use is made of repositories of information on client requirements [7]; (iv) requirements are not widely available, and hence, not accessible to all product development team members [3,7,8]; and (v) there are difficulties in tracking requirements, due to the fact that much of the information involved is qualitative [7,9,10].

The aim of client requirements management is to improve value generation of construction projects through a systematic process of capturing requirements, processing this information, and making it explicit to the product development team, as well as controlling whether these requirements are properly balanced and updated [7,11,12]. Requirements modelling is part of the overall client requirements management process, and is specifically related to structuring, representing, and displaying requirements information to support decision making [13].

Client requirements management is one of the core elements of the implementation of the Lean Philosophy in Design as it involves some core principles of that philosophy related to value management: (i) Capture explicit and latent client requirements; (ii) make client requirements available to different stakeholders; (iii) consider client requirements in all deliverables and for all roles of the customer; and (iv) monitor whether the value has been generated from the perspective of the client [14].

Managing client requirements is important in social housing projects, particularly in developing countries such as Brazil, for different reasons: (i) There is a strong need to maximize value, due to the limited resources available for funding social housing projects [15,16]; (ii) there is a wide diversity of user profiles in social housing projects and their specific requirements must be considered [17,18]; (iii) due to the large scale of some social housing programs, the level of end-users’ participation in project definition tends to be low [18,19]; and (iv) there is a growing level of complexity in social housing projects, due to the fact that these combine the delivery of products (e.g., housing, infrastructure) and services (e.g., social work, job creation initiatives, healthcare improvement programs) [20,21].

Due to the large amount of qualitative information involved in modelling client requirements in construction projects, information technology can be used for introducing some degree of automation in this process, as well as for facilitating the visualization of information [8,13,22]. Building Information Modelling (BIM) seems to be a promising alternative for supporting client requirements management in construction projects, as it is capable of connecting semantic information to product models, as well as checking design conformance to legal requirements [23,24]. Koppinen et al. [25] suggest that BIM can support not only the management of technical requirements at the detail design stage, but also at early design stages by manipulating information related to space requirements.

Despite all potential benefits, previous research recognizes that the activity of managing and modelling requirements is very scarcely adopted in the construction industry [7,13,26]. Moreover, most studies on the use of information technology for client requirement modelling are focused on how to store, access or retrieve information in computer models [1,27,28,29,30] or are limited to modelling specific types of requirements, such as energy efficiency (e.g., References [7,31]). Therefore, there seems to be a gap in how BIM-based requirement modelling can support decision-making in the management of construction projects, particularly in social housing.

The aim of this research work is to propose a set of guidelines for the use of BIM to manage client requirements in the context of social housing projects. Those guidelines are based on a process model that have been devised to represent the main activities involved in client requirements management, as well as on a number of constructs that have been proposed for assessing the effectiveness of the application of BIM in client requirements management. This investigation is based on an empirical study carried out in a social housing project from Brazil, which was financed by Caixa Econômica Federal (National Savings Bank), as part of the Minha Casa Minha Vida (MHML—My House My Life) program.

The MHML program was created in 2009, with the aim of reducing the housing shortage in Brazil, which has been estimated at 7.75 million dwellings [32]. Around 90% of this shortage concerns families that earn up to three minimum wages per month (around US$ 800), which cannot afford to buy a house without subsidies from the Federal Government [33]. Two possible stakeholders have been identified as potential users of BIM-based client requirements management: (i) Companies involved in the development and construction of social housing projects; (ii) funding agencies and local authorities, which are in charge of assessing proposals for social housing projects, and carrying out inspections during the construction phase.

2. Client Requirements Management

The first studies on requirements management and modelling came from the field of information systems and software engineering [34,35,36]. Later, this topic has also become disseminated in the manufacturing and aerospace sectors [36]. Requirements can be defined as functions, attributes and other characteristics of products or services that are required by clients [24,37]. Requirements management has been described as the process of documenting, storing, communicating, tracking and managing changes in the requirements [24,35,38].

In the construction industry, the term most traditionally used for the definition of requirements at the beginning of a project is briefing, understood as the process of identifying and structuring client requirements, which are presented in a document named brief [39,40]. The briefing is a key step in the early design stages, when decisions about the commitment of resources are made [41].

Barrett et al. [9] suggest that a broader definition for the briefing process should be adopted, assuming that client requirements are captured, developed, adapted, maintained and communicated throughout the project. Therefore, it is important to consider that the process of capturing and structuring requirements should not be limited to the initial stages of the project, as client requirements might change considerably along the project life cycle [7,42,43]. In this research study, client requirements management is understood as a systematic and disciplined process for fulfilling the main requirements during the project life cycle. Thus, it is assumed that requirements need to be updated over time [7,44,45], and communicated to the project team, so that the implementation of the necessary changes in the design or facility can be considered [7].

Several authors have proposed steps or tasks that must be performed in client requirements management.

Table 1. Client requirements management steps, description, and related authors.

Steps	Description	Studies on Software Engineering, Aerospace and Manufacturing	Studies on the Construction Industry
Identify	Understanding project context, identification of stakeholders, and systematic capture of client needs and expectations	[35,38,46,47,48,49]	[37,41,44,50]
Analyse	Interpretation of user needs, which are translated into explicit requirements	[35,38,46,48,49]	[37,41,44,50]
Structure	Definition of categories, organized in hierarchical levels, which group different types of requirements, such as space, components, and type of performance	[48,49,51,52]	[13,37,39,41]
Translate	Translation of requirements into solution-neutral specifications	[35,46,47,49]	[13,37,39,41]
Store	Storing all requirements in a repository	[35,53]	[7,13,27,54]
Prioritise	Identifying the most important requirements for different interest groups which need to be considered in product development	[46]	[26,37,41,44,50]
Communicate	Making requirements available throughout project stages, and making stakeholders aware of any changes or decisions made regarding client requirements	[24,35,48]	[7,27,29,44,55]
Assess	Checking whether product design has considered the set of requirements identified in previous stages, so that value is generated	[24,35,48]	[1,41,44,56]

summarizes the contributions from different studies developed both in the construction industry and in other sectors, such as software engineering, aerospace, and manufacturing.

As suggested in Table 1, client requirements management starts with the identification of different types of clients, which might have distinct roles in the project (e.g., users, owners, investors, etc.), and the capture of information related to user needs and expectations. Then, that information is translated into explicit requirements, which need to be structured, i.e., organized into categories, due to a large amount of information involved [13]. In the second stage of information transformation, explicit requirements may be used to develop solution-neutral specifications [57]. Explicit requirements and specifications must then be communicated and sometimes prioritized by decision makers [7]. As design solutions are developed, these must be assessed, using requirements information as a reference [27].

It must be emphasized that this sequence of steps cannot be considered as linear. Instead, the literature suggests that there is much iterations between steps, which are carried out in incremental cycles [1,18,48]. However, none of the previous studies on the management of client requirements in the construction industry has explored the sequencing of steps or relationships between them, and how these are affected by the introduction of BIM.

3. Client Requirements Modelling and BIM

Several research studies have explored the use of BIM for supporting client requirements management in recent years. Those studies have developed or used computer tools that allow the establishment of connections between requirements and product model objects by using the IFC Open Standards. Fu et al. [30] investigated the storage of requirement-related information, and its connection to space entities. Jallow et al. [7] proposed a digital information management framework for building requirements, which considers several functions, such as storage, retrieval, distribution and dependency checking. Tarandi [28] proposed a model for connecting requirement information to spaces and physical elements, so that several functions could be performed, such as visualization, assessment and tracking requirements. Shen et al. [27] devised a method for modelling user requirements by using BIM to support communication between designers and users. However, the main contributions of those studies are concerned with the development of specific solutions (e.g., tools or methods) for improving some specific steps of client requirements management. None of them has adopted a process management approach, considering all tasks that are involved in client requirements management (see Table 1).

Regarding the stage of structuring requirements, Kiviniemi (2005) have proposed a structure containing 300 requirements, classified into 13 main categories and 35 subcategories (Figure 1). This set of requirements was based on the Industry Foundation Classes (IFC) specifications, making it possible to connect them with object-based design-intent models. The proposed set of categories can be used to support automated design assessment, as it is possible to connect requirements to elements of virtual models [56,58,59].

Two types of support for managing client requirements have been provided by BIM-based tools [1]. One approach is to use a hierarchical tree structure for storing and displaying technical and functional requirements for designers by using BIM models [56]. Another approach is to translate requirement information into rules that can be used for automated checking of design solutions, especially with the aim of achieving conformance to legal and regulatory requirements [1,7,60].

Overall, there are several benefits that BIM can bring to the task of modelling client requirements, according to existing literature. Those benefits were the starting point for defining the set of guidelines for the use of BIM to manage client requirements:

• Visualization: Requirement information must be well structured and easy to be visualized in BIM models [7,13,27,29,56,61];
• Storage: BIM must allow requirement information to be stored [7,13,27,29,56,61] so that repositories of client requirements can be created and reused in different projects, if necessary [62]. This is particularly useful for creating requirement templates which allow a large set of requirements to be used for product families [13]. This could be used, for instance, to support the development of several housebuilding projects within the same housing program.
• Connection: A clear connection between requirements and objects in product models, such as spaces of components, must be established [13,25,27,29,54,56,58,59,63]. Those connections could support value generation by making it easy for decision-makers to understand the required functionalities of building spaces or components [6];
• Assessment: BIM should provide support for assessing design, based on up-to-date requirements [1,31,56,58,59];
• Communication: It is concerned with making requirements available in a format that is accessible to stakeholders [7,13,27,29,56,61,62], such as design teams, or professionals in charge of assessing project proposals, who might need different types of tools for visualization [64];
• Automation: This refers to the automation of the process of checking requirements [56], reducing the time spent in design assessment, and also increasing consistency in this task [1,31,56,58,59,63];
• Traceability: This refers to enabling stakeholders to track requirements, i.e., to identify the origin of each requirement (i.e., who have established it), and changes that have been made, and situations in which it is applicable. It is also necessary to identify requirements that are affected by changes in other requirements [28,62,63,65].

4. Research Method

4.1. Research Design

Design Science Research (DSR) was the methodological approach adopted in this investigation. The main objective of DSR is to devise innovative solution concepts, named artefacts, to solve classes of practical problems, and at the same time contribute to the development of mid-range theories, i.e., theoretical models that are applicable to a limited range of situations [66,67]. There are different types of outcomes in DSR, such as models, methods, constructs, and instantiations [68]. The artefact proposed in this research is a set of guidelines for using BIM to manage client requirements, in the context of social housing projects.

The research was divided into three stages: (i) Understanding the context; (ii) development of an empirical study in which BIM-based tools were used for modelling client requirements for a social housing project; and (iii) assessing the use of BIM for client requirement management, based on a set of proposed criteria. This set of criteria were initially devised from the literature review (see the previous section) then refined in the empirical study.

4.2. Description of the Company and of the Construction Project

The construction company involved in this investigation, named Company X, was a mid-sized firm from the State of Rio Grande do Sul, South of Brazil, which had 45 years of experience in the development and construction of housing projects. This company had five projects under construction during this investigation, four of them social housing schemes. This company was chosen because it had been involved in the delivery of several social housing projects from the MHML program, and also because of the existing interest of the technical staff in using BIM in the design process. The National Savings Bank was also a co-participant in this research project, and provided some support for this investigation, as the engineering and architecture staff from one branch was interested in exploring the use of BIM to support the assessment of proposals of housing projects.

In the MHML program, construction companies are in charge of finding a suitable piece of land for a housing project. Then, a proposal is submitted to the National Savings Bank, the financial agency in charge of funding projects for that program. The design is assessed by the technical staff (architects or civil engineers) of that bank, who typically have several years of experience in assessing design proposals, considering regulations and best practices established for social housing programs. In the MHML program, this assessment is strongly focused on checking compliance with two set of regulations. The first one is a set of standards that are established by the Ministry of the Cities of the Federal Government, with the aim of defining a minimum level of quality that each dwelling must have. The other one consists of requirements that have been created by the technical staff of the National Savings Bank, based on their expertise, which is available in an internal document of the bank.

One typical project of Company X, named Project A, was chosen for the empirical study. This was a social housing project comprised of nine apartment buildings, with a gross floor area of 7.665 m². Each building had five floors, and each floor was divided into four two-bedroom 41 m² apartments. The project also had 92 parking spaces. The main building technologies adopted in this project were structural masonry, concrete slab, and lime and cement plaster on both internal and external walls. This project was categorized in the band 1 of the MHML program, in which the target population are families with up to two minimum salaries of income (around US$ 600).

Due to limitations of resources, the modelling effort was limited to regulatory requirements established by the Federal Government and National Savings Bank for the MHML Program. Other regulatory requirements, such as from the city master plan or building codes (e.g., fire and safety codes), or requirements elicited directly from final users were not considered in this investigation.

4.3. Description of Research Stages and Sources of Evidence

The focus of Stage 1 was understanding MHML specific requirements, and how the proposals for housing projects were assessed by the National Savings Bank. The main sources of evidence used in this stage were: Analysis of official documents regarding MHML regulations and guidelines; one meeting and three open interviews with representatives of the National Savings Bank involved in design assessment (meeting A and interviews B, C and D in

Table 2. Job roles of interviewees in Stage 1.

Sources of Evidence	Job Role of Interviewees	Institution/Company
A: Meeting	Manager of the urban development department; manager of the real estate credit department; and two technical staff in charge of assessing design proposals	National Savings Bank
B: Open interview	Technical staff in charge of assessing design proposals	National Savings Bank
C: Open interview	Manager of the real estate credit department	National Savings Bank
D: Open interview	Manager of the real estate credit department	National Savings Bank
E: Meeting	Director; project manager; architect; trainee architect; electrical engineer; and plumbing engineer	Construction Company

); and a meeting with representatives of the construction company involved in the conception and design of housebuilding projects (meeting E in Table 2).

Stage 2 involved modelling clients’ requirements of Project A. This process involved the following steps: (i) Analyzing and structuring requirements; (ii) selecting BIM-based tools; (iii) developing a 3D model and verifying its consistency; (iv) storing requirement information and connecting it to the product model; and (v) converting legal requirements into rules and performing automated code checking.

Regarding requirement structuring, the structure proposed by Kiviniemi (2005) and subcategories proposed by Bonatto et al. [69] were used as a starting point. This structure was assessed in open interviews with three technical staff from the National Savings Bank, during two different meetings (A and B in

Table 3. Job roles of interviewees in Stage 2.

Sources of Evidence	Job Role of Interviewees	Institution/Company
A: Three group open interviews	Manager of the Real Estate Credit Department; and two Technical staff in charge of assessing design proposals	National Savings Bank
B: Three group open interviews	Manager of the Real Estate Credit Department; and 2 Technical staff in charge of assessing design proposals	National Savings Bank
C: Two group open interviews	1 Architect; 1 Project manager	Construction Company

), as well as by an architect and a project manager from the construction company in two open interviews (C in Table 3).

In parallel, some commercially available BIM-based software tools for modelling requirements were analysed. Two of them, dRofus^® and Solibri^®, were chosen because of their complementarity with regards to client requirements modelling. Both allow connecting requirements and different parts of the product model by using the IFC Open Standard [23]. The dRofus^® tool can be used for structuring and storing client requirements in a hierarchical tree, which can be used to represent the decomposition of non-functional requirements (e.g., safety and indoor thermal comfort) into technical-functional requirements, such as requirements related to spaces [56]. This tool also enables requirements to be tracked, making it possible to identify the origin of each piece of information, and to control and document changes in requirements over time. However, dRofus^® does not allow the automated evaluation of the impact of a change on other requirements, as dependency relationships can only be created between spaces, but not between requirements. For example, it is possible to create a proximity relationship between two spaces, but if throughout design development, these spaces become far away from each other, the software does not identify this problem. It is still up to the designer to analyse the design and identify the non-fulfilment of this requirement, as well as to evaluate the impact of that change on other requirements. In addition, dRofus^® can create templates of requirements for different types of buildings, thereby enabling a large set of requirements to be reused.

The Solibri Model Checker^® tool also enables requirements to be connected to spaces, being able to translate them into parametric rules, which are useful for modelling some legal and regulatory requirements, such as the ones related to accessibility and space programme [56]. By using those rules, compliance checking to legal requirements can be automated to some extent [70].

The 3D model of the building was developed by the research team, using the Autodesk Revit^® software tool, based on 2D drawings from the architectural, plumbing and electrical design, provided by the Company X. This model was built to the level of development (LOD) 350.

A structured database of requirements was created in dRofus^® to categorise data, according to the requirements structure adopted by this research. Two sources of requirements were used in the modelling process: (i) The MHML minimum standards, established by the Federal Government; and (ii) interviews and meetings with professionals from the National Savings Bank. Some of these requirements were stored and connected to spaces by using dRofus^®. Some other requirements were translated into logic rules by using Solibri^®. Then, an assessment of the building design was performed by using the rule-structure interface available in Solibri^®, as well as with data stored in dRofus^®. For some requirements that could not be modelled in any of those tools, a manual check of requirements was undertaken.

In Stage 3, the use of BIM for modelling client requirements was assessed in terms of utility and applicability, pointing out the benefits and limitations of BIM for that purpose. This assessment was carried out in three seminars, one at Company X (Seminar A in

Table 4. Job roles of interviewees in Stage 3.

Sources of Evidence	Job Role of Interviewee	Institution/Company
A: Seminar	Company director; one project manager; one designer; one trainee architect; one electrical engineer; and one plumbing engineer.	Construction Company
B: Seminar	Manager of the urban development department; the manager of real estate credit; one professional in charge of assessing design proposals; and one social worker.	National Savings Bank
C: Seminar	Three managers of the urban development department; coordinator of the urban development department; one executive manager; coordinator of social work; four social workers; four architects; four engineers.	National Savings Bank
	Three master students; one PhD candidate; one researcher; two professors.	Federal University of Rio Grande do Sul

) and the other two at the National Savings Bank (Seminar B and C in Table 4). In seminars A and B, the interim results of the research project were presented and discussed with different stakeholders. In addition, seminar C was held to discuss final results of this investigation, involving 18 technical staff from the National Savings Bank, and seven researchers from the Federal University of Rio Grande do Sul (Seminar C in Table 4). Moreover, the assessment of utility and applicability was also based on the perception of the research team during the modelling process.

5. Results

5.1. Assessment of Social Housing Projects in MHML Program

As mentioned in the previous section, the focus of client requirements management in the empirical study is the assessment of proposals for new projects to the MHML Program, in which subsidies are provided to dwellers, so that the final cost of housing units is affordable. This assessment is based on two types of requirements, as mentioned above, the minimum standards established by the Ministry of the Cities and the set of requirements devised by the technical staff of the National Savings Bank.

The interviews indicated that there is a lack of standardization of criteria in the assessment of project proposals, and the scope of the analyses depend on personal judgment. In fact, 64 requirements out of 138, that were captured, had a qualitative character, often demanding some kind of subjective assessments by professionals. The interviews indicated that the professionals involved in the assessment may interpret requirements differently.

The lack of standardization of those criteria is a critical problem because MHML is a large housing program, and the assessment of proposals is decentralized, being carried out by professionals located in different parts of the country. Differences between the criteria adopted by different professionals may result in the loss of credibility of the evaluation process, causing delays and complaints by housebuilding companies.

Moreover, the assessment process is time consuming, due to a large number of items, especially if the proposal has some issues and needs to be resubmitted after a number of revisions. This assessment process is prone to errors, because it is based on a manual analysis of several documents. Some of the technical staff of the National Savings Bank also reported that they faced difficulties in visualizing and finding information, as design documents are sometimes inconsistent and poorly organized.

An additional difficulty highlighted in the interviews is the fact that social housing regulatory requirements evolve over time and these changes are not necessarily clearly communicated to the housebuilding companies involved in the development of new projects. As a consequence, some construction companies submit proposals for housing projects without considering the latest set of requirements, which is a major cause of rework and further increases the duration of the evaluation process.

From the perspective of the housebuilding companies, it is difficult to trace design decisions in relation to the requirements, making it difficult to know why some particular changes in design were made, and how these affected other design decisions.

5.2. Requirements Analysis and Structuring

The two documents that established the requirements for the MHML housing projects were analyzed, and 138 requirements were identified, 103 established by the Ministry of the Cities, and 35 by the National Savings Bank. The initial structure of requirements was based on the 13 categories proposed by Kiviniemi [13], presented in Figure 1. However, those categories needed refinements, considering the specific demands of the MHML Program, which were identified in interviews and meetings with representatives of the National Savings Bank and of the Construction Company.

Table 5. Adaptation of categories and subcategories of requirements.

	Category/Subcategory (KIVINIEMI,2005)	Category or Subcategory Considered	Category or Subcategory not Considered	Category or Subcategory Considered or Adapted to the Context of Social Housing Projects
Conformity Requirements	A.2 Location Requirements	This category was included		A.2 Location Requirements [13]
	A.2.4 Site Design Requirements	This subcategory was included		A.2.3 Site Design Requirements [13]
	A.2.6 Site Requirements for Buildings		Some requirements related to the buildings’ height and area are related to regulations established by local authorities according to the existing Master Plan.
	A.4 Space Requirements	This category was included, but with changes in the names of subcategories.		A.3 Space Requirements [13]
	A.4.1 Space Program Instance	These subcategories were merged into a single subcategory. It includes, among other things, areas, and dimensions of spaces, furniture and equipment.		A.3.1 Adequacy of usage of spaces [13,69]
	A.4.2 Space Program Type
	A.4.3 Space Program Fixtures	It includes, among other things, walls, floors, ceilings, doors, and windows		A.3.2 Requirements for construction and finishing quality [13,69]
Performance Requirements	B.3 Adaptability Requirements		No requirements related to this category and subcategories were identified. However, the adaptability requirements should be considered by public policy. A problem frequently found in projects that adopt structural masonry is the lack of flexibility in terms of changing or demolishing walls.
	B.3.1 Flexibility Of Building
	B.3.2 Flexibility Of Technical Systems
	B.3.3 Flexibility Of Space
Environmental Requirements	D.1 Sustainability Requirements		There are guidelines for producing more sustainable construction projects. The requirements are only considered if certification is required in the housing program. This was not the case for the MHML program at the time of this study.
	D.1.1 Energy Insulations
	D.1.2 Energy Requirements
	D.1.3 Environmental Pressure

illustrates how the categories proposed in previous studies were adapted for the empirical study.

The resulting requirements structure adopted in this investigation had nine categories and 13 subcategories (see

Table 6. Structure of requirements adopted in this investigation.

	Categories	Subcategories
Conformity requirements	A.1 General Requirements	A.1.1 Requirements of the project
	A.2 Location Requirements	A.2.1 Infrastructure of the Project
		A.2.2 Public Infrastructure
		A.2.3 Site Design Requirements
	A.3 Space Requirements	A.3.1 Adequacy of usage of spaces
		A.3.2 Requirements for construction and finishing quality
Performance requirements	B.1 Safety Requirements	B.1.1 Safety Of Site
	B.2 Aesthetic Requirements	B.2.1 Visual Requirements
	B.3 Accessibility Requirements	B.3.1 Accessibility of the housing unit
		B.3.2 Accessibility of the areas and equipment of common use
	B.4 Circulation Requirements	B.4.1 Circulation Systems
Systems requirements	C.1 Requirements for electrical systems	C.1.1 Electrical systems
	C.2 Plumbing systems requirements	C.2.1 Plumbing systems

). The subcategories are broken down into 49 requirements, and 138 solution-neutral specifications for apartment buildings in the band 1 and 2 of the MHML program.

Table 7. Location requirement structure of social housing projects.

Categories	Subcategories	Requirement Names	Solution-Neutral Specifications
A. 2 Location Requirements	A. 2.1 Infrastructure of the Project	A.2.1.1 Site Drainage	Solution for urban drainage
		A.2.1.2 Gas Supply Infrastructure	Individual measurement of gas (not required for metropolitan area)
		A.2.1.3 Water Supply Infrastructure	Potable water reservoir on top of building
			Security fencing for the pumps at the reservoir
			Individual measurement of water
		A.2.1.4 Sewage Supply Infrastructure	Solution for site sewage
	A.2.2 Public Infrastructure Requirements	A.2.2.1 Electricity Network and Lighting	Public electricity and lighting
		A.2.2.2 Sewage Supply Infrastructure	Public sewage
		A.2.2.3 Water Supply Infrastructure	Water supply system
		A.2.2.4 Road Infrastructure	Paving on sidewalks
	A.2.3 Site Design Requirements	A.2.3.1 Min. Bike Parking Spaces	Bike parking spaces
		A.2.3.2 Min. Motorcycle Parking Spaces	Motorcycle parking spaces
		A.2.3.3 Min. Car Parking Spaces	Car parking spaces as defined in legislation
		A.2.3.4 Min. Green Site area	Grass in non-paved places

presents, as an example, the breakdown of the Location Requirements in four types of information: (a) Categories of requirements; (b) subcategories of requirements; (c) requirement names; and (d) solution-neutral specifications.

5.3. Modelling Requirements in BIM-Based Software Tools

Table 8. Requirements assessment by using Building Information Modelling (BIM)-based tools.

Categories	Subcategories	Requirement Names	Solution-Neutral Specifications	Assessment
A.3 Space Requirements	A.3.1 Adequacy of usage of spaces	A.3.1.3 Minimum dimensions	Master bedroom: Minimum circulation of 0.50 m between furniture and walls	Automated (dRofus)
B.3 Accessibility Requirements	B.3.1 Accessibility of housing unit	B.3.1.3 Access to spaces of housing unit	It should be possible in all rooms to include wheelchair maneuver area without displacement to a rotation of 180º defined by NBR 9050 (1.20 m × 1.50 m), free of obstacles	Automated (dRofus)
	B.3.2 Accessibility of communal areas and equipment	B.3.2.1 Accessibility to disabled people to spaces of common use	Reception room with toilets for disabled access	Automated (Solibri Model Checker)
C.1 Requirements for electrical systems	C.1.1 Electrical systems	C.1.1.1 Electrical points, sockets, and communication system	Room: Two electrical outlets; one telephone outlet with wiring; one doorbell; one antenna outlet; one interphone outlet	Subjective
C.2 Plumbing systems requirements	C.2.1 Plumbing systems	C.2.1.1 Water services of housing unit	Outlets for future installation of washing-machine (water and sewage)	Subjective

presents some examples of requirements and how these can be assessed. An important limitation of this investigation was that all requirements had a technical-functional character, i.e., they were related to product attributes. None of them consisted of highly abstract requirements, related to consequences in use or client’s perceived values, as modelled by Hentschke et al. [17].

Table 9. Summary of modelled requirements and methods.

Origin of Requirements	Total Number of Requirements	Number of. Requirements Modelled in BIM-Based Tools	Methods for Assessing Requirements	Number of Requirements Assessed
103 requirements from the Ministry of Cities + 35 from the National Saving Bank	138 technical-functional requirements	81 technical-functional requirements modelled in dRofus	Subjective assessment with the support of dRofus and Revit	64 qualitative requirements
			Automated assessment by dRofus	17 quantitative requirements
		57 technical-functional requirements modelled in Solibri	Automated assessment by Solibri	57 requirements translated into 72 rules

presents a summary of the number of requirements that were modelled in BIM, for each category, and the methods used for assessing them. From the 138 requirements, 74 could be checked by using some degree of automation in BIM tools, 17 in dRofus^®, and 57 in SMC. This indicates that it is possible to standardize the assessment of design proposals for 54% of the requirements. The remaining requirements had a qualitative nature and could only be checked by expert judgement as some degree of subjectivity is usually required.

As dRofus^® works as a repository of requirement-related information connected to the building model, any of the 138 requirements for spaces, equipment, furniture and building services could be represented and connected to the elements of the building model. On selecting one of the spaces, dRofus^® opens a window called Room Data Sheet (RDS) (Figure 2), into which space requirements are informed. The 9 categories and 13 subcategories, shown in Table 6, were used to structure the information in the RDS. Those categories and subcategories can be visualized for all building spaces, as dRofus^® allows the requirements to be stored in a structured way, by using different information configurations, such as text-edit boxes and multiple-choice fields.

Figure 3 shows some requirements related to mechanical, electrical and plumbing services and equipment of the laundry room, which can be used to assess the architectural design, modelled in Autodesk Revit^®. Some degree of automation is provided by dRofus^® for checking some quantitative requirements, such as geometric requirements related to areas and height of the ceiling, as well as identifying whether a component or equipment is missing in the model. Figure 3 illustrates a situation in which one of the requirements modelled in dRofus^® is marked in red, because one of the components were missing.

In SMC, several requirements can be checked by using logical rules, which allow automated checking for more complex quantitative requirements, such as the minimum dimensions of circulation. This software tool provides sets of predefined rules, which were edited and adapted to the MHML requirements. However, in order to make automatic assessment feasible for certain requirements, details had to be provided for specific elements of the model and standards for the names of those elements had to be created, which requires an object classification process. For some requirements, sets of rules had to be created. For example, two rules were necessary to do the necessary checks for the requirement "Single bedroom: Minimum circulation between beds of 0.80m and for other circulations a minimum of 0.50m". Consequently, for the 57 requirements that were checked using SMC, 72 rules were required.

The requirement presented in the first line of Table 8 refers to the minimum distance of required in the bedroom between two pieces of furniture or between one piece and a wall, which is 500 mm. However, in the design, there was a piece of furniture that was 457mm away from the bed, indicating that this requirement is not met (Figure 4). This difference, however, is within the limits of tolerance for approval by the National Savings Bank’s professionals. This example shows the need to implement explicit tolerance levels in MHML requirements so as to make automatic checking consistent.

Furthermore, SMC was used to check whether all spaces in the housing unit allowed the necessary wheelchair maneuver area. This requirement, defined by NBR9050 [71], is presented in Table 8. Figure 5 illustrates how SMC identified the non-fulfilment of this requirement for the circulation space between bedrooms. In the third example of Table 8, MHML requires that buildings must include an accessible toilet in the Reception Room. The assessment of this requirement is carried out subjectively as the parameters and specifications for this type of toilet are not clearly defined. The last two examples of Table 8 can be checked in dRofus^®, and the requirement was “to foresee a solution for a washing-machine (one hydraulic component and one wastewater outlet)”, as previously shown in Figure 3.

5.4. Guidelines for Managing Requirements in Social Housing Projects with the Support of BIM

Figure 6 presents the process model that has been proposed for the management of requirements in social housing projects with the support of BIM. This model is an adaptation of the requirements management activities suggested in the literature (Table 1) to the specific context of social housing. In this model, client requirements management starts with the identification of stakeholders, and data collection about their requirements, which need to be analyzed and structured. Then, the resulting information needs to be translated and connected to building objects by using BIM-based tools, where all the requirement information is stored. In the case of conflicting requirements, some kind of priority might be established among them. Client requirements information can be accessed by different stakeholders along different stages of the design process.

This process should start at the conceptual design stage. However, requirements information should be represented in the BIM model in order to support design decision making along different project stages. As design develops, more detail client requirements information should be added, creating a cycle encompassing requirements modelling, design, and design assessment. This cycle might even happen after design completion, as it is often necessary to make design changes during construction or occupation phases. In the case of social housing projects, an external and comprehensive design assessment is made when the project is proposed for funding. This assessment can be supported by BIM tools, which are able to do some automated checks or display the requirement information to professionals involved in the evaluation. Therefore, client requirements modelling can be regarded as precursors to BIM-based design assessment.

The proposed guidelines are based on the process model, considering a set of constructs that express some of the expected benefits of client requirements management. Seven of those benefits have been presented in the literature review (visualization, storage, connection, assessment, communication, automation, and traceability), while two of them, comprehensiveness and standardization, have emerged in this investigation. Those benefits can be related to different tasks involved in requirements management, as presented below:

• Before starting modelling requirements, the scope of client requirements management must be identified (step 1), which depends on (i) the purpose of the modelling effort; (ii) the stakeholders that will be considered in requirements capture; and (iii) the level of abstraction of the modelling process. Therefore, some boundaries need to be established in terms of the comprehensiveness of client requirements. For instance, in the empirical study carried out in this investigation, the purpose of requirements management was limited to supporting the assessment of housebuilding project proposals, based on requirements established by the Federal Government and the National Savings Bank. The focus was a set of requirements considered to be necessary to provide minimum quality for final users, without considering the requirements of other clients directly (e.g., neighbours, facilities management staff, etc.). Moreover, other sources of information have not been used, such as direct elicitation from final users. Finally, the level of abstraction was bounded by the definition of requirements adopted in this investigation, mostly focused on attributes of the product, rather than on high abstract values related to users’ needs and expectations, as modelled by Hentschke et al. [17].
• In the analysis of requirements (step 2), different sources of information can be used for capturing requirements, including existing regulations (e.g., building codes, standards, etc.), results from post-occupancy evaluations of similar projects, as suggested by Formoso et al. [18], and perceptions of stakeholders. In social housing projects, there are regulatory documents, such as the ones used in the empirical study, in which minimum standards are defined. It is possible also to interview representatives of different organizations involved (e.g., funding agencies, housebuilding companies, facilities management companies, and designers), especially when there is not enough time or resources available to do a survey with final users. Some of these stakeholders have their own requirements that also need to be considered. At this stage, some inconsistencies between regulations and other sources of information can be found, as well as conflicts between the requirements of different stakeholders. Therefore, this analysis also requires an effort of finding a balance between requirements from different stakeholders.
• The structure of requirements (step 3) can be built from an existing taxonomy (e.g., Kiviniemi [13]), but some adaptation is usually necessary, due to the specific type of project being considered (e.g., social housing) or the comprehensiveness of the modelling process. The following step is the translation of requirements (step 4) into a language that can be understood or stored in an BIM-based computer software. This has a strong iteration with the task of structuring requirements. The structuring of requirements needs to establish a connection of the set of requirements for building components and spaces from the product model (step 5).
• An effective structure of requirements must make it easier to check the completeness of the modelling effort, and enable requirements to be traced in the computer software (e.g., in dRofus^®). Traceability means providing a historical record of changes in requirements, making it possible to track the origin of the information. The interviews pointed out that it is often difficult to identify who has made changes in requirements, and when that happened.
• Requirement information must be stored (step 6) in BIM-based tools, which can provide support to collaborative work and make requirements available to the main stakeholders. Storage allows requirement information to be reused. For instance, templates of requirements can be created and stored for similar products (e.g., projects from the same housing programs). Such a template could also be used by professionals involved in the assessment of project proposals for the same housing programs. Based on an explicit model of client requirements, some priorities can be established, in case trade-offs are necessary.
• In the context of social housing, there are several potential users (e.g., construction companies and designers involved in the development of new projects, professionals in charge of assessing proposals). BIM can potentially support the standardization of a large number of criteria for assessing design proposals. It can also be used to communicate in real time changes in requirements defined by regulations that need to be updated or refined frequently. In meetings and interviews carried out in this investigation, it was suggested that the National Savings Bank could play the role of administrator of an updated repository of requirements, to be used in the development of design and assessment of project proposals.
• A well-established structure of requirements, and the connection between requirements and product model objects, as in the dRofus^® software, can potentially improve the visualization of project information. Some of the professionals involved in this investigation agreed that BIM-based requirement models could help them to achieve a better understanding of the social housing project, as well as a faster and more consistent design assessment.
• In the assessment (step 8), some degree of automation in client requirements management can be introduced by using BIM-tools. Of course, the introduction of BIM will demand new skills for the professionals in charge of checking conformance of design proposals to standards and regulations. Some requirements could be translated into rules and checked by using SMC, while others could be checked by using templates which exist in dRofus^®. Other requirements had to be stored by using text-like representation in dRofus^®. In the empirical study, 54% of the requirements could be translated into logical rules or templates. The share of requirements that had a qualitative character and required human judgement (46%) could be reduced to some extent if regulations (i.e., human-readable documents) were written from machine-readable codes, as suggested by Beach et al. [72], instead of being an input to rule creation. Current automated code checking approaches still rely on translating information from regulatory to explicit requirements, and later to codified requirements by using logic rules, which depends fundamentally on human involvement [73]. By increasing the percentage of requirements that could be checked in an automated way, experts would have more time to assess the fulfilment of those requirements that demand their knowledge and some degree of subjectivity.

6. Conclusions

This research work highlights the importance of managing client requirements in social housing as this type of project usually faces issues related to the subjectivity and lack of structure involved in the assessment of project proposals, which is strongly based on personal judgment. There are also difficulties in tracing requirements changes, which makes ineffective the communication of updated information to stakeholders. Moreover, the design assessment of social housing projects is time-consuming, and there is a lack of standard criteria for assessing design proposals.

In order to deal with these issues, a set of guidelines for managing client requirements in social housing projects, with the support of BIM-based tools, was proposed. These guidelines were related to a process model that defines a sequence of interrelated activities involved in client requirements management, and also on a set of nine constructs that define the benefits of using BIM for managing client requirement.

The main contributions regarding the process model are the introduction of some tasks, such as defining the scope of the requirements model, structuring requirements, and storing requirements models for future use in housing programs, and the understanding of the interdependences between them. Moreover, the proposed set of constructs related to the benefits of client requirements management could be used to assess BIM-based solutions. Those constructs were mostly identified in the literature, and their roles in the context of social housing were discussed, such as the contribution of BIM for standardizing criteria in the design assessment of housing projects, and the need for clearly defining the boundaries of requirements modelling.

From a practical perspective, BIM-based client requirements management can potentially be used by government agencies and local authorities to increase the speed and consistency of the design review process. Regarding construction companies, this type of innovation can eliminate waste and reduce lead time in the delivery of new projects, which are typical goals in the implementation of Lean design. By using a BIM-based approach for client requirements management and design checking, there are also opportunities for making social housing projects more sustainable from a social and environmental perspective. Improving value generation, i.e., providing benefits for the users of those projects is an essential step towards social sustainability. Moreover, the effective management of client requirements can contribute to reducing waste related to refurbishment and demolition, as well as to meet standards for building energy consumption.

Some limitations must be pointed out in this research study:

• The artefact proposed in this research work is at the level of solution incubation, being based on a single empirical study, devised in a specific housing program from Brazil, so that the requirements structure, rules, templates and other elements of the requirements model cannot be generalized to other projects;
• The process model and the guidelines have not had their utility and applicability tested in the product development process of housing projects;
• Due to the emphasis on the use of BIM, the scope of client requirements modelling was limited to technical and functional requirements, which are related to product attributes, rather than on high abstract values that define the needs and expectations of social housing users;
• The development of BIM-based solutions for client requirements management does not eliminate all problems regarding delays in the assessment of project proposals, but only those problems related to de difficulty of modelling and communicating requirement information.

Due to the scarcity of studies on client requirements management, further research must be encouraged with the aim of contributing to improving value generation of social housing. The main outcomes, i.e., guidelines, process model and assessment criteria, need to be tested in empirical studies, if possible by implementing them in real projects. Future studies are also necessary on the evaluation of BIM-based requirements modelling tools in relation to some of the criteria proposed, such as the traceability of requirements, and the storage of requirements templates for families of house building projects. In addition, more studies should be carried out on strategies for extending the use of information technology to other levels of requirements modelling, so that the relationship between technical-functional requirements, non-functional requirements, and expected values could be properly modelled.