Categorisation of Requirements in the Ontology-Based Framework for Employer Information Requirements (OntEIR)

Abstract

Employer Information Requirements (EIR) are the keystone for developing a successful Building Information Modelling (BIM) project. However, clients’ lack of skill and experience in categorising and defining these requirements often undermines the performance of a construction project and, ultimately, the ability of the finished product to meet their needs. By definition, EIR shortcomings include incomplete and inconsistent requirements and specifications, and whilst some work has been performed to try to address these, this area is still underdeveloped. This paper reports on the development of a transformative approach to the categorisation of requirements in a meaningful way, enabling effective filtering so that stakeholders can access just the information they need for the task at hand. The Ontology-based framework for Employer Information Requirements (OntEIR) seeks to provide a step change in categorisation by identifying ‘static’ and ‘dynamic’ requirements, including related types and sub-types. OntEIR has been rigorously validated by a group of BIM experts, and the results have revealed that this approach to categorisation significantly improved the elicitation and understanding of requirements.

1. Introduction: Requirements and Requirements Categorisation

For a certain condition to be achieved or a product to be produced, certain needs should be defined. In most cases, these needs are often set by the client to request the delivery of a certain service or product. These needs, once defined and developed, become “requirements” [1]. According to the Office of Government Commerce, UK [2]: “Requirements are capabilities and objectives to which any product or service must conform and are common to all development and other engineering activities.” Requirements may also be defined as a “description of a set of testable conditions applicable to products or processes” [3].

The importance of proper identification of requirements arises from the role they play in defining the end product in terms of the clients’ and stakeholders’ needs, leading to clients’ satisfaction and improved project performance; the requirements are the basis of every project [4]. The lack of skill in defining and classifying their requirements at the beginning of the project often leads to incompatibility of client requirements, cost, and time for completion, which will eventually lead to an overrun in cost and time [5] (The same notion is applied to the construction industry. In fact, in a report/survey published by the Chartered Institute of Building [6], 87% of respondents believed that good procurement and requirements specification are synonymous with a successful project and for that project to be developed on time, on budget, and to a high quality. This starts with the proper identification of the Employer Information Requirements (EIR). It is necessary at this point to make it clear that despite the distinction between the terms client and employer, this paper refers to both the client and the employer as the same entity, which according to CIOB ‘Code of Practice for Project Management’, the client is defined as the “Entity, individual or organisation commissioning and funding the project, directly or indirectly.” [7]. The client is also sometimes referred to as the: Employer, Promoter, Owner, Purchaser, or Principal.

One of the key pillars of BIM, as stated in the Publicly Available Standards [8]. Published by the British Standard Institution, proposed setting out the EIR as part of the Employer’s Requirements document, which is incorporated into tender documents. Such documents provide information that is mandatory for suppliers to be able to produce the BIM Execution Plan (BEP), in which the proposed approach, capability, and capacity can be evaluated. This information includes requirements required by the client in addition to key decision points and project stages.

EIRs are created to organise and manage the information produced from the different processes. EIR is an important document in construction projects for the information and instructions it holds for the creation, storage, and transfer of digital information when a building is delivered via BIM [8]. Studies have shown that having a relevant and complete EIR defined from the beginning of the project will lead to having a successful BIM project [9]. In fact, issues that are associated with poor requirements specifications include inappropriate and disappointing results, overrun in time and money, and project delays which often lead to conflicts and lawsuits [10].

Being the cornerstone for the BIM Execution Plan (BEP), a proper EIR ensures that the BIM process delivers the right information for optimising the asset construction cost and usability over the long term [9]. Designing a successful EIR is an important solution for managing the collaboration and integration process that is the main feature of the BIM process. Integration and collaboration are important for reducing project overrun and cost, removing non-value-added activities, encouraging collaboration, and increasing client satisfaction [9,11]. EIR is considered an important strategy platform that needs to be strengthened to nurture social collaboration between the different roles in the BIM project [12].

Categorisation of requirements has been practised in different disciplines to make it easier to manage the control of requirements [13]. It is also used to support requirements elicitation that aims at completeness [14], and it helps in defining some kinds of priorities that assist designers in defining suitable solutions in less time [15].

The concept of requirements categorisation has been applied to ensure that stakeholders obtain what they need from the requirements. Categorisation of requirements is based on the attributes that further define these requirements. Categorising requirements allows stakeholders to access the information they need from the vast amount of available information that affects the requirements and enables them to communicate the different levels of requirements to the appropriate audience, each at their own level [16].

Categorisation of requirements has been practised extensively in systems engineering [17] and in Software Engineering [18,19]. This categorisation is mainly to describe “what a product must do” and the “product attributes” [1].

In the construction industry, other types of requirements categorisation were introduced. Kamara et al., [20] presented the “primary, secondary, and tertiary” requirements. Primary requirements are those that represent the more ‘general’ requirements of the client. Secondary requirements are a decomposition of the primary requirements into a more detailed set of requirements. Another decomposition of the secondary requirements generates the tertiary requirements [20]. Moreover, Kiviniemi et al. [21] identified two types of requirements: direct and indirect requirements. Direct requirements are requirements related to the spaces and recorded in the building program. On the other hand, indirect requirements are those related to the bounding elements and technical systems. These types of requirements are difficult to notice because the detailed design process related to them often takes place later and often by people who were not involved in the early stages of the briefing [21]

Saxon [22] had a different perspective on requirements categorisation. He discussed that there are two types of requirements that need to be identified for BIM projects. Those requirements are the ‘product’ requirements and the ‘process’ requirements. Product requirements are those that cover the physical side and performance of the asset. Process requirements are the ones related to the asset information, content, and flow. Although this categorisation covered both the physical side and the information side of the project, still, the project stages, and the way the requirements change and develop throughout those stages, are not.

Despite having some studies that considered the categorisation of requirements in the construction industry, it can be noticed that very few of them actually respond to the nature of the BIM project and the information involved. Employer Information Requirements (EIR) are requirements regarding the information involved in the BIM project. They are not requirements regarding a ‘product’ or an ‘end result’, but they are the requirements of the information required and produced during the BIM process, which includes the actual lifecycle of the project. As agreed by Kovacs and Miscik [23], the requirements for the BIM process and workflow are important parts of the BIM requirements specification, alongside the requirements that apply to the building as a ‘product’.

The Ontology framework for defining EIR (OntEIR) is a framework and tool able to cover the issues of changing and development of requirements during the BIM process and develop a full and complete EIR [24]. OntEIR defines and describes the information requirements needed throughout the project lifecycle for a full and complete information model to be delivered at the end of the BIM project. Two major components make up this framework: high-level needs and project stages [24,25]

The OntEIR framework was reached by identifying the weaknesses of the current practices in EIR and through meetings and interviews with experienced stakeholders in the UK construction industry [25]. The OntEIR framework expands the current practices in the EIR definition to include the project lifecycle and tracking of the information development during its different stages. It enables the client to easily trace their requirements and involve the relative stakeholder during the definition of the requirements [25].

To do so, a new categorisation system with its taxonomies were introduced to define a complete and stable set of requirements that is understandable for all stakeholders. This paper reports on the development of the OntEIR framework as the basis on which a standardised EIR document can be produced both effectively (at the right level of quality in terms of correctness, completeness, and consistency) and efficiently (in reduced time and at reduced cost). OntEIR adopts an approach to categorising the EIRs to ensure that all requirements are covered and fully understood by the client(s) and all stakeholders. This framework is a novel contribution to the construction industry that will enable clients to produce a full and comprehensive set of EIR. It seeks to benefit all types of clients, public and private, experienced and non-experienced, as well as both owners and developers.

The success of OntEIR emerges from the fact that it is intuitive and systematically helps to consider all issues that are essential for the delivery of a full and comprehensive set of EIRs, which will lead to the definition of better-quality requirements. In an evaluation of the OntEIR framework with major UK industry experts, 80% of the respondents thought that the OntEIR framework was comprehensive and able to consider the requirements and aspects needed to provide complete EIR, as it managed to identify three times more requirements than current practices [25]. Furthermore, 85% agreed that OntEIR presented an understandable framework for clients to produce successful EIR [25].

The purpose of this paper is to present the new categorisation concept of requirements into ‘static’ and ‘dynamic’ introduced in the OntEIR framework. It starts by examining the concept of requirements categorisation and its applications across different disciplines, including the construction industry. It also reviews the categorisation concept in OntEIR. Moreover, it continues to expand on the new categorisation concept and the relations that the different categories share with each other. The last section explains the validation process for the categorisation system and the feedback received from the participating, relevant, and experienced stakeholders in the industry.

2. Categorising Employer Information Requirements in OntEIR

The proposed categorisation of requirements in OntEIR assists in understanding and uncovering more of these requirements. In the construction industry, EIR should cover all the requirements needed to successfully complete a complex construction project. To help understand these requirements better, PAS 1192-2 [8] set out a list of needs that should be covered in the EIR. According to Dwairi et al. [24], those needs should be broken down for the requirements to be generated. This is the method used to specify the EIR requirements in the OntEIR framework [24]. OntEIR is an ontology-based framework/tool that managed to define more than 150 EIRs using the decomposition of goals, following a goal-driven Requirements Engineering approach such as proposed by van Lamsweerde and Letier [26], Mylopoulos et al. [27], and Van Lamsweerde [28]. Similar approaches have been used in construction, such as the Goal Cognitive Task Analysis (GDTA) [29], which was utilised by Irizarry and Gheisari [30] in establishing a hierarchy of goals, decisions, and related information requirements to develop the Situation Awareness (SA) framework to improve decision-making and information requirements specification for construction projects.

For so many complicated requirements, a type of categorisation should be applied to ease the understandability and comprehensiveness of these requirements. Categorising the EIR will also facilitate the definition of these requirements by the different stakeholders and suppliers involved in the project through the grouping of the different requirements that share similar attributes. Thus, the concept of ‘static’ and ‘dynamic’ requirements was introduced as a high-level categorisation of the EIR in OntEIR.

Figure 1 shows how the BIM Information Delivery Lifecycle (IDL) starts with the definition of the EIR, which is the base of the procurement process, and upon which the supplier will present the BIM Execution Plan (BEP) and the Master Information Delivery Plan (MIDP). Those documents are the main documents that manage and plan the whole construction process from initiation to handover and even until the end of life for the asset. The BEPs and MIDPs job is to specify the: who, what, and how of the information involved in the project by specifying roles, responsibilities, and information ownership [31].

The EIR should hold all the necessary information that will enable the development of the BEP and the MIDP, as well as all the necessary information for the storage and exchange of information. As discussed by Koutamanis [32], client needs that are expressed in the brief (and EIR) are critical and important information for the success of a BIM project.

In order to reach the final full Asset Information Model (AIM), and according to the PAS BIM IDL shown in Figure 1, five main layers should be fully covered in the EIR, as demonstrated in Figure 2.

These layers are:

• The Common Data Environment (CDE) and the roles and responsibilities of all the team members of the project, including the client.
• The project stages in terms of project requirement for each stage, the Asset Information Requirements (AIR) for each stage, and the maturity level of each stage defined by the Level of Definition (LOD) and Level of Information (LOI) of the deliverables.
• Data Drops: these are the deliverables that should be presented to the client at the end of each stage, which include the requirements defined by the client in the EIR; at the end of each data drop, the Project Information Model (PIM) develops until reaching fully mature AIM model; in the final stage, ‘Hand over’.
• The client decision points, which are connected to the data drops, in which the client decides to progress to the next stage or not.
• As well as the information exchange requirements which are an important part of the delivery cycle because it guides the information exchanged between the different team players and the information exchanged with the client as well.

When examining the BIM IDL Layers, as shown in Figure 2, it can be noticed that there are two main components of the IDL: (1) the base on which other information relies on, such as standards, guidance, strategy, definitions, CDE, roles and responsibilities, and information exchange strategies. Moreover, (2) the information that ‘flows’ between the different stages and between the stages and the CDE; it is the information that is responsible for the development and maturity of the PIM and the development of the AIM at the end.

The online visualising tool “graph commons” was chosen to represent those requirements due to the flexibility and options the tool offers for visualising the requirements and the relationship between them, as shown in Figure 3. It can be seen that some kind of clustering occurs to the needs that have to cover the two types of information. These clusters represent the categories of the OntEIR.

The nodes in Figure 3 represent the components of the OntEIR framework. Purple nodes represent Cluster 1 (Static Needs), red nodes represent Cluster 2 (Dynamic Needs), blue nodes represent the stages, and black nodes represent the requirements. Another important aspect of the framework is the lines that link these nodes together. Although the length of the lines has no significance, the use of different colours of the lines connecting the nodes expresses whether the relationship is: ‘has need’, ‘has requirement’, ‘is related to’ or ‘includes’. However, the size of the nodes graphically represents the number of connections a node is attached to other nodes or stages. Therefore, a larger node has more connections than a smaller one.

Looking at the arrangement of the nodes in Figure 3, it is seen that they cluster themselves into two groups. The terms ‘static’ and ‘dynamic’ needs were chosen to refer to those two types of clusters according to the characteristics and behaviour they demonstrate:

Needs in Cluster 1-Static Needs: have only links and relations amongst themselves, they are not connected to the stages, and they only appear once throughout the whole project, which is at the beginning. On the other hand, Cluster 2-Dynamic Needs: represents needs that have different characteristics: they are linked to one another in addition to being linked to the project stages, and they tend to move through the stages while developing and maturing during the stages. All nodes and requirements shown in Figure 3 are detailed separately in the immediately following paragraphs.

2.1. Static Needs (Cluster 1)

Static needs in OntEIR could also be called generic needs. They are the needs that should be defined for all projects despite their type or size. They are defined at the beginning of the project and are not affected by the project’s development stage. They are only linked with the other static needs in their group, as shown in Figure 4.

Static EIR needs include:

-

Tasks (responsibilities): BIM roles and responsibilities which inform the RACI table for the project (Responsible for, Authorising, Consulted by, and Informed by)

-

Roles: defines the different roles that are involved in the project, the names of the individuals, and the contact details

-

Standards: defines the standards that will be used in the project

-

Ownership of the model: defines the ownership and the licensing of the model in the different stages of the project

-

Data security measures: the measures that should be undertaken by the team to ensure data security in terms of cyber security

-

Software platforms: the different software platforms and versions that will be used during the project

-

Coordinates: clarify the relationship between the origin and orientation and the ordinance survey grid and local project grid

-

Communication: Coordination and clash detection

-

AIM delivery strategy: BIM information exchange formats and classification systems

2.2. Dynamic Needs (Cluster 2)

On the other hand, and as discussed before, the dynamic needs obtain its name from being changing and continually developing with the development and maturing of the stage, as shown in Figure 5. Mainly, dynamic needs are the basis on which the MIDP is developed.

Dynamic requirements that change and develop according to the maturity of the stage they are linked to include:

-

Data drops: data submitted to the client at each stage

-

Project team: the roles that will be involved in each stage

-

Project requirements: information that is added to the model at each stage

-

LOD and LOI: Level of Detail and Level of Information for the different components at each stage

-

AIR: the Asset Information Requirements required by the client, which informs the AIM

-

CDM data drops: health and safety data that is submitted at each stage and that adheres to the Construction and Design Management Regulations (CDM)

-

Data security level: a label added to the information to determine the level of security and confidentiality.

-

COBie: Construction Operations Building Information Exchange is the information to be added to the BIM model that contains the operation and maintenance information for the different assets.

3. Evaluation of the Static and Dynamic Categorisation of Requirements

The categorisation of requirements was appraised as part of the overall evaluation of the OntEIR framework. This section discusses the purpose of the evaluation and the criteria, the methods applied in reaching the results, how the selection of the participants was made, in addition to the findings of the evaluation process.

3.1. Purpose of Evaluation

The purpose of this process was to evaluate the categorisation of the requirements in the OntEIR framework into static and dynamic requirements, which was part of the overall evaluation of the OntEIR framework. The categorisation of requirements was evaluated according to the following criteria:

• The justification of the use of static and dynamic requirements in the categorisation of the EIR;
• How successful was the categorisation system in OntEIR in enhancing the clarity and comprehensiveness of the EIR;
• The completeness of the EIR in terms of both the static and dynamic needs in covering all the related requirements.

3.2. Methods Applied

The evaluation was conducted using semi-structured interviews, surveys, and focus groups.

3.2.1. Interviews and Survey

This mixed research method of the study aims at exploring the categorisation of the requirements in the OntEIR framework for developing and producing complete and successful EIR. Semi-structured interviews and a survey were conducted. The interview process started with a presentation of the OntEIR framework in terms of concepts and components, which included the categorisation of the requirements in the framework, which is the most important feature, followed by a detailed look at the framework itself. The presentation was followed by a discussion with the interviewees about the framework and the categorisation used, and notes were taken as guidelines for the development of the framework.

A survey was then distributed to the participants that discussed the framework. The survey included 26 questions in total that were designed to cover the evaluation of the categorisation criteria. The surveys recorded the feedback of the participants. The feedback sheet contained 26 Likert-scale and open-ended questions, including:

-

9 Likert-scale questions, in which the categories of ratings include: 1 (Highly Disagree), 2 (Disagree), 3 (Neutral), 4 (Agree), and 5 (Highly agree); and 17 open-ended questions, in which the participant would have more freedom in answering the questions.

3.2.2. Selection of Participants

The selection of subjects for the study is considered by many researchers the most important step in the entire process because it directly affects the quality of the results reached [33]. For this study, and as in other qualitative interviews, participants were chosen according to their depth of knowledge and experience about the phenomenon under investigation [34,35].

Participants were selected on the basis of having a good understanding of EIR and BIM. Construction professionals in facility and BIM management roles, in addition to academics that had an extensive experience in BIM and EIRs in the construction industry, are most likely to provide useful input and feedback in interviews and questionnaires, which were the main criteria in selecting the participants for this evaluation. The selection of experts was based on specific criteria. Each participant should be able to fulfil at least one of the selection criteria below:

• Having extensive working or academic experience with BIM Clients, BIM EIR specifications, Procurement or Building Information Modelling, with a five-year or more experience working in BIM;
• Recent and direct involvement in the specifications of the Employer Information Requirements for BIM Projects, and client requirements, the participant should have been involved in specifying or translating at least 10 EIRs/BEP in the last five years;
• Having a sound knowledge and understanding of client requirements, information requirements, and Procurement or Building information modelling within the U.K, which is translated into having over five years of experience in BIM requirements, specification of client requirements, and/or the procurement process.

Twenty participants from fifteen organisations finished the survey. Details of the involved participants, including their titles and business areas, are shown in

Table 1. Participants in the Validation Process.

Participant ID	Title	Area of Business
R1-1	Project-Manager	Facility Management // Buildings and Construction
R1-2	AutoCAD Assistant	Space Management and Master Planning
R1-3	BIM Manager	Client-Higher Education
R1-4	Lecturer in BIM	BIM and Project Management
R1-5	Project Manager	BIM and Project Management
R1-6	BIM Manager	Main Contractor
R1-7	Building Services Advisor	Central Government
R1-8	Revit Technician	Engineering
R1-9	Architectural Technologist	Construction
R1-10	BIM Leader	BIM Smart Cities
R1-11	BIM Manager	Architecture
R1-12	Senior Lecturer	Architecture and Construction
R1-13	BIM Leader	Smart Cities
R1-14	Architectural Technologist	Construction
R1-15	Revit Technician	Engineering
R1-16	Requirements Manager	Requirements Management, Validation and Verification Management
R1-17	Facility and Real Estate Manager	Office and Manufacturing Buildings and Related Services.
R1-18	Construction Project Manager	Industrial Facilities and Services
R1-19	Project Manager	Manufacturing Engineering
R1-20	Project Manager	Construction

.

Figure 6 illustrates the professions of the number of participants involved in survey:

3.2.3. Focus Groups

The focus group is a different group than the one that completed the survey. The aim of focus groups is to gather a group of people for the purpose of being interviewed on a specific issue in the research inquiry [34,36,37].

One focus group was put together with experts in the industry from one organisation to discuss the OntEIR framework, including the concept of the requirements categorisation used.

The focus group conducted took place at AIRBUS in Filton, Bristol. Nine experts attended this focus group, details for whom are shown in

Table 2. Participants in the Airbus Focus Group-Ids and Roles.

Participant ID	Role
FG1	Facilities Manager
FG2	Facilities Manager
FG3	Facilities Manager and Construction Project Manager
FG4	Facilities Processes and BIM Expert
FG5	Facilities Processes and BIM Expert
FG6	Construction Project Manager (Facilities)
FG7	Client (Manufacturing facilities)
FG8	Construction Project Manager (Manufacturing facilities)
FG9	Client (Manufacturing facilities)

below; for confidentiality reasons, the names of the attendants were replaced with ID numbers:

The roles chosen for this focus group were according to the involvement of this role with the information requirements provided by the AIM. Therefore, since the framework is aimed at specifying the Information Requirements for the client, it was considered fitting these roles to provide an evaluation to determine how the framework can affect the identification of the EIR in which they are involved. The process designed for the evaluation of the framework in this focus group is illustrated in Figure 7.

In the beginning, a Microsoft PowerPoint presentation was delivered by the researcher to outline the research and challenges facing the current practices in EIR. It also outlined the concepts of categorisation and the elicitation process used in the OntEIR framework. The OntEIR framework was then presented, and all components were discussed in detail. Then the architecture of the OntEIR prototype was presented with all its components and relations.

A quantitative approach was used to present the data, which was then analysed and discussed. The questions/questionnaire was designed to capture both qualitative and quantitative data. Two types of evaluations were also conducted: formative and summative. Formative evaluation is applied to provide feedback for those who are trying to develop something [38], and the summative evaluation is applied to provide feedback on how effective a system is in achieving its aim. Therefore, the triangulation method was used for the collection of the evaluation, presentation, and analysis.

3.2.4. Descriptive Statistics

For the analysis of the validation process, the descriptive statistics were used as an analysis technique. According to Denscombe [35], descriptive statistics are often used to uncover the patterns, distributions, and peculiarities within a data sample. Therefore, for data of a univariate type, frequency distributions were considered appropriate [39]. Measures of central tendency were used to identify mean response points with respect to the Likert scales [35].

3.2.5. Relative Importance Index

After identifying the mean response for each question, the Relative Importance Index (RII) formula is applied to support the mean value analysis and rank the criteria that have been validated from strongest to weakest. The RII is applied to the ranks that represent very high on the Likert scale (4 and 5), which will allow the identification of the strongest criteria (the one with the highest RII). This will assist the researcher in identifying the weaknesses of the framework and ranking its features from strongest to weakest, which will allow for more concentrated development attention on the weakest features for the update and improvement of the framework in the next stage.

The RII value ranges from 0 to 1: a higher the RII value indicates a more successful the framework in addressing the criterion. This will allow ranking the criteria from highest to lowest in the framework’s ability to address them and work on finding a solution for the lowest scoring in developing the framework.

The formula for the RII is:

$$RII={\displaystyle \sum }_1^5 \left(\frac{Ni\times Ki}{Rh\times n}\right)$$

Ni: Number of respondents choosing rating points 4 and 5 on the Likert scale (Highly agree)

Ki: Rating points used (in this case, it will be (4 + 5)/2 = 4.5)

n: total number of respondents

Rh: the highest number in the ranking order

3.2.6. Responses to Questions

For the three evaluation criteria discussed earlier, at least one question was asked in the evaluation process, either in the interviews or in the survey. Questions and answers for each criterion are discussed next:

1-Criterion 1: The justification of the use of static and dynamic requirements in the categorisation of the EIR:

a-Question: Do you agree that the categorisation between static and dynamic requirements is right for EIR?

This question was to check whether having two types of requirements (static and dynamic) is justified. (Static requirements are the requirements that are defined at the beginning of a project and do not change according to the stage. Dynamic requirements are the requirements that change and develop according to the stage the project is in).

Answers to this question are shown in

Table 3. Responses to Question 1-a.

Mean	S.D	Degree of Agreement
		Highly Disagree	Disagree	Agree	Highly Agree
4.20	0.93

Mean ratings: 1 ≤ mean ≤ 1.5 = Highly Disagree, 1.5 < mean < 2.5 = Disagree/ 2.5 < mean < 3.5 = Agree/ 3.5 ≤ mean = Highly Agree.

.

Results showed that 85% of the participants agreed (high or very high on the Likert scale) with the categorisation of requirements into ‘static’ and ‘dynamic’, and that it is more understandable and made more sense for them, which would make EIR clearer for inexperienced users as well, as seen in Figure 8.

In addition to facilitating the understanding of the requirements for the users, the categorisation of the requirements was proposed to also enable the filtering of requirements in a way that would allow stakeholders to access just the information they need for the task at hand.

RII for this question was: 0.765

2-Criterion 2: How successful was the categorisation system in OntEIR in enhancing the clarity and comprehensiveness of the EIR:

Question: How successful was the OntEIR Framework in covering all aspects when defining requirements for EIR?

This question is to measure the comprehensiveness of the overall framework in covering the appropriate level of requirements needed to create a full EIR. Answers to this question are shown in

Table 4. Responses to Question 2-a.

Mean	S.D	Degree of Agreement
		Highly Disagree	Disagree	Agree	Highly Agree
3.90	0.70

Mean ratings: 1 ≤ mean ≤ 1.5 = Highly Disagree, 1.5 < mean < 2.5 = Disagree/ 2.5 < mean < 3.5 = Agree/ 3.5 ≤ mean = Highly Agree.

.

For this question, respondents rated the comprehensiveness of the framework to be high in terms of obtaining the level of requirements to create a complete set of EIR, as seen in Figure 9. RII for this question scored 0.72.

3-Criterion 3: The completeness of the EIR in terms of the completeness of both the static and dynamic needs in covering all the related requirements:

Question: Do static requirements contain the right level of needs?

This question was to check the completeness of the static needs. Answers to this question are shown in

Table 5. Responses to Question 3-a.

Mean	S.D	Degree of Agreement
		Highly Disagree	Disagree	Agree	Highly Agree
3.60	0.66

Mean ratings: 1 ≤ mean ≤ 1.5 = Highly Disagree, 1.5 < mean < 2.5 = Disagree/ 2.5 < mean < 3.5 = Agree/ 3.5 ≤ mean = Highly Agree.

.

As shown in Figure 10, in terms of needs covered by the static category, 60% of the participants agreed that it is able to cover the needs required for a complete EIR. Comments for further improvements included the ability to add client-specific requirements. RII = 0.54.

b-Question: Does the dynamic section contain the right level of needs?

This question is to check the completeness of the Dynamic needs. Answers to this question are shown in

Table 6. Responses to Question 3-b.

Mean	S.D	Degree of Agreement
		Highly Disagree	Disagree	Agree	Highly Agree
3.95	0.74

Mean ratings: 1 ≤ mean ≤ 1.5 = Highly Disagree, 1.5 < mean < 2.5 = Disagree/ 2.5 < mean < 3.5 = Agree/ 3.5 ≤ mean = Highly Agree.

.

The completeness of the dynamic section, in terms of containing the right level of needs, scored high in the responses, where 80% of the participants responded that it covers the needs, as shown in Figure 11. RII for this question scored 0.72.

Table 7. Descriptive analysis of OntEIR success criteria.

OntEIR Evaluation Criteria	Question	Mean	RII	RII Value	Degree of Agreement
					Highly Disagree	Disagree	Agree	Highly Agree
Categorisation	Do you agree that the categorisation between static and dynamic requirements is right for EIR?	4.20	0.765	Very High
	Categorisation (Mean: 4.20 = Highly Agree, RII: 0.765 = Very High)
Comprehensiveness	How comprehensive is the OntEIR framework in defining the requirements for EIR?	3.90	0.72
	Comprehensiveness (Mean 3.9 = Highly Agree, RII: 0.72 = High)
Completeness	Do static requirements contain the right level of needs?	3.6	0.54	Low
	Does the dynamic section contain the right level of needs?	3.95	0.78	Very High
	Completeness (Mean = 3.775 = Agree, RII: 0.66 = low)

Mean ratings: 1 ≤ mean ≤ 1.5 = Highly Disagree, 1.5 < mean < 2.5 = Disagree/ 2.5 < mean < 3.5 = Agree/ 3.5 ≤ mean = Highly Agree.

shows the three criteria discussed in the evaluation of the OntEIR categorisation as part of the OntEIR Framework evaluation and the questions associated with each criterion.

For each question the mean average and RII were calculated. Results show that the concept of the categorisation used in OntEIR had the highest score, with a mean of 4.2 and an RII of 0.765. Both comprehensiveness and completeness came in second and third place with scores of 3.9 and 3.775 in mean average, respectively, and 0.72 and 0.66 in RII. The next section will discuss these scores and suggestions for improvements based on focus groups, interviews, and the open-ended questions in the survey.

3.2.7. Suggestions for Improvements and Other Comments

Interviews, surveys, and the focus group form a good source for the evaluation of the OntEIR framework and the categorisation of requirements used.

Table 8. Areas of Improvement and Update of the OntEIR Framework.

Question	Remarks	Sample Quotes
In the static section, what requirements should be added?	CDE Clash detection frequency AIM delivery strategy
In the static section, what requirements should be removed?	All participants answered with “None”
In the dynamic section, what requirements should be added?	More detail in the Asset Information Requirements Classification system to be used should be specified (UniClass, NRM…)
In the dynamic section, what requirements should be removed?	All participants answered with “None”
Additional comments on the overall OntEIR framework?	RIBA stages would be more comprehensive to use with the industry stakeholders instead of the PAS stages used.	Looks like a very good approach and very useful Seems like a very good and helpful framework in general A very useful and well-configured framework
What do you think is the strongest feature of the OntEIR framework?		The comprehensive overview of BIM aspects It focuses on the users and guides them through the different aspects he/she needs to think of when developing the EIR. That it incorporates the fact that during the stages, we need the same things but at an increasing level of detail and maturity That one can decide which level of detail is needed in which stage and, in general, the distinction between static and dynamic requirements. It allows for increasing or specific levels of detail depending on the various stages, which is more realistic.

discusses the open-ended questions in the survey and the discussions in both the interviews and the focus groups when discussing areas of improvement and updates for the framework, and

Table 9. Weakest to Strongest Criterion and Ways to Improve.

Criterion	Highly Agree	Agree	RII	Discussion
Categorisation of the requirements into static and dynamic	45%	40%	0.765 (high)	No action needed
Does the static section contain the right level of needs?	5%	55%	0.34 (low)	As seen in the interviews and open-ended questions discussed in the previous section, participants believe that there are still some static needs and requirements to be covered in the framework and tool. Those requirements include: CDE requirements, AIM requirements, communication requirements
Does the static section contain the right level of requirements?	0%	40%	0.36 (low)
Differentiation between needs and requirements in the static section	0%	40%	0.36 (low)	There should be a way for the user of the framework and tool to be able to understand the difference between the high-level need and requirement when defining the EIR. High-level needs could work as a checklist when going through the needs that should be covered in the EIR, while the requirements are the more detailed way of achieving the need. This should be clear to the user when designing the tool
Differentiation between needs and requirements in the dynamic section	0%	70%	0.63 (low)

shows the weakest to strongest Criteria of the Framework and Ways to Improve.

“OntEIR focuses on users and guides them through the different aspects they need to think of when developing an EIR” (Participant quote).

Based on the validation of the framework and according to the criteria, it was found that participants found that the OntEIR framework has performed well regarding all criteria. The overwhelming majority (85%) perceived the framework to be understandable and clear. However, based on the comments given by the participants during both the surveys and interviews, update and improvements on the framework are needed in terms of stages used, AIM delivery strategy, and classification system to be used. Some of the participants prefer the use of UniClass or NRM. Additionally, there were other comments regarding giving the user more involvement in defining the requirements.

According to the results and findings, the update of the findings will maintain the categorisation system used (Static and Dynamic) due to the overall agreement of the participants with it. However, some modifications to other aspects of the framework had to go under work to make it more comprehensive, complete, and understandable for all types of users using the OntEIR framework.

Update of the Static Needs and Requirements:

After the analysis of the validation of the initial OntEIR framework, results and findings have shown that there is a need for further coverage of needs and requirements in the static section. Participants agreed on adding the ‘needs’:

-

Communication: Coordination and Clash Detection

-

Asset Information Model (AIM) Delivery Strategy

Communication: Coordination and Clash Detection

Dubas and Paslawski [40] argue that communication in BIM is crucial for the correct execution of the project due to the need for information exchange between the stakeholders to achieve an obtained goal.

Park et al. [41] discuss the problems that might negatively impact the construction quality and could be overcome by using proper communication strategies:

• Data loss: This is due to the way information is stored and exchanged.
• Workload; and
• Revealing defects after they appear.

Communication in OntEIR is performed at two levels: (1) communication between the parties involved in the delivery of the project, which includes the data exchange, coordination of responsibilities, and clash detection; and (2) communication between the stakeholders and the client, in terms of exchange of information and the client decision points. It is important to mention that the communication of data is conducted through the CDE, which is the common single space agreed upon by all stakeholders involved in the project and is where all the data is stored and exchanged. Figure 12 illustrates the level of communication covered by OntEIR.

Thus, the requirements included in the ‘communication’ needs to include the following:

-

CDE: in which the Common Data Environment is defined.

-

Frequency of information exchange.

-

Clash detection process.

-

Clash resolution process.

-

Clash detection responsibility.

-

Other communication fields that the client feels should be defined.

Asset Information Model Delivery Strategy

In this need, the client defines the requirements of the AIM, which is the model expected to be delivered at the completion of the delivery phase. It includes the requirements needed for the model format and how the information is transferred into an existing or proposed facility management system, in addition to the classification system to be used in the Asset Information Requirements (AIR) that would eventually make up the full model.

Consequently, the requirements included in this need are:

-

Information exchange format.

-

Standard classification system; and

-

Computer Aided Facility Management (CAFM) software.

Update of the Dynamic Needs and Requirements:

Results and findings have shown that the there is a need for further covering of needs and requirements in the dynamic section. Participants agreed to update and develop the following ‘needs’:

-

Project stages.

-

Asset Information Requirements (AIR) and the COBie deliverables.

-

Definition of LOD and LOI.

4. Discussion

The use of OntEIR to define EIRs for BIM projects offers the benefits of enabling clients to define their requirements in a clear and understandable way and produce a complete, clear, and consistent EIR. A unique feature of the OntEIR framework is its underlying categorisation system, which focuses on classifying the requirements into two groups based on their features and how they relate to other attributes and requirements of the framework, in addition to the movement of the requirement through the different stages of the project. These two groups were the ‘Static requirements’ and the ‘Dynamic requirements’. Static requirements form the base on which other requirements are defined and do not change during the project lifecycle, whereas dynamic requirements have been shown to be essential for change in the project during the different stages.

This study reports on the categorisation system used in the OntEIR framework in defining EIR. Results show that the categorisation of the requirements has assisted in improving the understandability and clarity of the EIR. This corresponds to previous studies that discuss the importance of requirements categorisation, facilitating the management and control of requirements in defining a more complete set of requirements [13,15,42].

In agreement with Saxon [22] in the particularity of BIM requirements in combining two types of requirements: physical requirements and information requirements (process), the OntEIR categorisation also defines the requirements into two groups that capture both the physical and the information part of a BIM project. The categorisation of requirements in OntEIR goes further by including project stages and the movement of requirements through the stages. Contrary to other studies that look at the construction project as a product [20,21], OntEIR considers the construction project a dynamic process in which the flow of information should be considered a vital part of the categorisation. The categorisation of requirements in the OntEIR framework has enabled OntEIR to achieve its goals as a tool for defining EIRs by:

• Enhancing the understandability and clarity of the requirements needed for a complete EIR.
• Enhancing collaboration through the categorisation of requirements which allows stakeholders to access the information they need [16].
• Moreover, incorporating stages and defining their own dynamic requirements makes it easier in the early consideration of lifecycle issues and requirements [43]
• The consideration of requirements in early stages of the project that would affect the lifecycle of the project and facility [43]

Thus, the categorisation of the requirements utilised in OntEIR can potentially be useful in facilitating a better understanding of the EIR and more effective collaborative work. Figure 13 illustrates the final categorisation used in the OntEIR framework with the needs associated with each category, according to the results of the evaluation and discussion.

5. Conclusions

Due to the increase of BIM adoption in the construction industry, there is an apparent need to find a system or tool that enables stakeholders to define more complete and consistent requirements that will help to plan and guide the whole lifecycle, which will result in a reduction of waste, costs and lead times.

Categorisation of requirements is a concept that has been practiced in many disciplines for the clear benefits it offers in terms of increasing the understandability, communication, discussion, and validation of requirements.

The OntEIR framework has been introduced in the construction industry as a means to increase requirements quality, in particular, the completeness of sets of Employer Information Requirements (EIR) for BIM projects. This research provided a novel approach to the categorisation of the requirements in the EIR into two main high-level types of ‘static’ and ‘dynamic’ requirements. The categorisation of the requirements in OntEIR was based on the relations and links they have with other related requirements and the standardised project stages.

Based on the rigorous evaluation carried out on the OntEIR framework, which included the discussion and evaluation of the categorisation system used (through focus groups, semi-structured interviews, and questionnaire-based surveys), it was found that the overwhelming majority of participants perceived that the categorisation of requirements into static and dynamic was helpful when defining the EIR.

The categorisation of the OntEIR requirements made it easier to track requirements and improve their correctness, completeness, and consistency. The categorisation of the requirements also made it easier for stakeholders who are in one way or another involved in the project to find and isolate a particular requirement for a particular reason by accessing this particular requirement from a large number of surrounding requirements.

This research managed to contribute to the body of knowledge and practice through the identification of an elicitation system that allows the definition of more requirements than existing studies and standards. By presenting new ideas of distinction between the high-level needs of EIR and the requirements, and the decomposition of goals to extract requirements from those high-level needs, OntEIR was able to identify three times more requirements than current practices, which contributes to a more detailed and relevant EIR. As well as being a more user-friendly and understandable approach, especially for unexperienced clients

However, in order to further increase the completeness and comprehensiveness of the framework with the aim to specify a full and complete set of EIR, suggestions were made to further extend the two categories of the framework, as discussed in the previous section. Based on the analysis of the feedback received, the final OntEIR framework and its supporting tool were updated. As part of future research, the OntEIR framework and tool will be applied in detail to upcoming BIM projects in the UK.