Engaging the International Heritage Community to Validate End-User Requirements for Historic Building Information Modelling

Featured Application

The system requirements validated by this article can be used by individuals and organisations as a guide to implement their own HBIM systems. The system requirements also provide justification for HBIM systems developed by others, enabling their validation.

Abstract

Historic Building Information Modelling (HBIM) is the application of BIM, an information management and modelling process, to cultural heritage (CH) assets. HBIM will provide tangible benefits to the heritage community by providing an enduring record of assets, facilitating more informed decision-making, and enabling more efficient resource management. However, the HBIM application is characterised by disparate methodologies and an inconclusive understanding of what the HBIM system should be achieving. The article aimed to validate thirty-three system requirements for HBIM previously proposed by the authors and evaluate their relative criticality for both the UK and international heritage community. It presents the results of an extensive survey undertaken with the international heritage community. The thirty-three system requirements were found to be valid for both the UK and international heritage community. However, some variation in the relative criticality of the requirements according to region was identified, the most notable of which was the perceived criticality of system requirements related to visualisation. Nine requirements were updated, and an additional requirement was added to reflect feedback received from participants. One requirement was altered by the authors to encompass a greater scope. Future work will investigate opportunities for requirement realisation and produce a theoretical framework for HBIM adoption.

1. Introduction

1.1. Background

Historic Building Information Modelling (HBIM) [1] is the application of BIM, an information management and modelling process, to cultural heritage (CH) assets. HBIM will provide tangible benefits to the heritage community, defined by the Faro Convention as “people who value specific aspects of cultural heritage which they wish, […], to sustain and transmit to future generations” [2], by providing an enduring record of assets, facilitating more informed decision-making, and enabling more efficient resource management.

However, beyond the acknowledgement that HBIM typically consists of a 3D model of an asset semantically enriched with additional information, there remains minimal consensus regarding what other features and functions an HBIM system must have, and minimal involvement of the end users in HBIM development. As stated by Ewart and Zuecco [3], “we do not know what HBIM is, who it is for, or why it would be used”.

Likewise, what limited practical application of HBIM exists is characterised by disparate methodologies and an inconclusive understanding of what the HBIM system should be achieving [3,4,5]. Furthermore, most research outputs remain focused on geometric data acquisition and model creation [6,7,8,9,10] as opposed to HBIM as an information management tool.

One explanation for the limited practical application of HBIM may be that BIM development itself has been primarily limited to the design and construction stage of the asset lifecycle, and BIM use for facility management remains in an early stage of development [8,11,12,13,14]. Moreover, the existing international standard for BIM, ISO 19650 [15], not only fails to comprehensively address the use of BIM for facility management, but also does not address the inherent uniqueness of CH management, such as different classification schemas and management approaches. Consequently, for CH managers, the relevance of the existing BIM guidance may not be clear. Although it should be acknowledged that the existing standards do not explicitly exclude heritage assets [16]. Without defining the explicit information management requirements of the heritage community, it is not possible to conclusively state how, or if, HBIM applications should vary from BIM for non-heritage assets.

These occurrences are not unique to HBIM and can be considered inherent for any information system development [17]. For instance, Nicholas and Hertman [18], when discussing the design of digital information systems for the library sector, posited that “information professionals tend to be preoccupied with information systems and not the users of these systems”. Without explicitly understanding the needs of the end user, it is not possible to assess the quality and value of any existing or proposed information system [19,20,21,22]. The lack of standardisation and defined requirements can thus be considered a key barrier to HBIM adoption [23,24].

1.2. Research Context and Aim

1.2.1. Research Context and Systems Thinking

This work is part of an ongoing research project investigating the standardisation of HBIM. To address the challenges discussed in Section 1.1, the authors are applying systems thinking approaches, namely soft systems methodology (SSM) and systems engineering (SE), to define a core purpose and associated system requirements for a future HBIM system. The definition of a core purpose and associated system requirements will enable the verification and validation of future HBIM systems. This approach has yet to be applied to the development of HBIM.

Figure 1 is a simplified pictorial representation of the project’s research methodology. The research methodology has been largely influenced by the v-process diagram (depicted in Figure 2), which is a widely accepted model for system design [25], and the concept of ‘participatory design’ [26]. When applied to system design, participatory design entails involving stakeholders of the system to be actively involved in its creation, which may also be referred to as co-creation [2]. Participatory design has been shown to have a tangible impact on system effectiveness and adoption [27], and so it is an appropriate methodology for the development of HBIM.

The content of this article corresponds with Stage 4 of the research methodology (Figure 1, requirement validation) and Stage 3 of the v-process diagram (Figure 2, requirements analysis). Stages 1 and 2 of the v-process diagram were encompassed by previous work by the authors [28,29], in which the authors conducted an extensive survey of the United Kingdom (UK) heritage community involved in the management and maintenance of heritage assets. The survey was intended to identify current working practices, existing issues and desired information, and functional and modelling requirements for a future HBIM system. The work broadly corresponds with Stages 2 and 3 of the research methodology in Figure 1.

The initial output of the survey was the proposal of the root definition of HBIM. The ‘root definition’ is a term associated with the SSM [17,30,31,32,33]. The intention of a root definition is to define the core purpose of a purposeful activity taken to improve a problematic situation. In this case, the purposeful activity is the application of HBIM to the management of cultural heritage. Simply put, the root definition describes the intended goal when applying HBIM. The root definition can be used as a tool for assessing the initial validity of a proposed HBIM system, e.g., a proposed system may be considered valid if it can be described by the root definition. The following root definition of HBIM was proposed:

“A system owned and maintained by members of the Heritage Community involved in the management and maintenance of cultural heritage, which, utilising BIM and HBIM technology financially viable to the Heritage Community, contains, in a structured and connected manner, all the information required for Heritage Management. The system makes information easy to locate to ensure informed management decisions”.

The distinction between ‘HBIM’ and ‘HBIM technology’ is that ‘HBIM’ refers to the system as a whole, whereas ‘HBIM technology’ refers to the hardware and software used to implement the system.

Subsequently, the authors utilised SE processes and corresponding requirement definition guidelines, as outlined by INCOSE [25,34], culminating in the identification of thirty-three system requirements for HBIM. The system requirements were intended to reflect technical interpretation of the operational needs of the participants, as defined by BS ISO/IEC/IEEE 15288:2023 [35], and enable the realisation of a system aligned with the proposed root definition. A full description of the requirement definition process utilised is given by Lovell et al. [29]. The requirements are, beyond the advised use of BIM and HBIM technology, software agnostic. They focus purely on what the system should do, as opposed to how it should do it. This is because, at this stage of the systems engineering process, requirements should not specify solutions, such as the exact method of modelling, as there may be several different methods that equally achieve a system requirement. A useful explanation of this is provided by the Royal Academy of Engineering [5], who suggest that a solution may be specified as “four wheel drive” when the system requirement would be “off road capability”. Hence, the discussion herein will not propose solutions.

The thirty-three requirements consisted of seven requirement themes: information management, collaboration, system operability, resource management and planning, visualisation, public engagement, and environmental management.

Table 1. HBIM system requirements proposed by Lovell et al. [29].

Requirement Theme	ID	Requirement
Information management	I1	The HBIM system will contain a comprehensive and accurate record of asset information (regardless of form). Note—The types of asset information will likely be asset-specific.
	I2	The HBIM system will allow new information to be added over time whilst retaining previous information.
	I3	The HBIM system will have a search function for finding information.
	I4	The HBIM system will have a structured, reportable, and viewable data storage schema.
	I5	The HBIM system will allow information to be viewed at different degrees of granularity.
	I6	The HBIM system will allow all information to be accessed from a single source.
	I7	Information in the HBIM system should be associated with a digital entity with a known position in space.
	I8	The HBIM system will record and report each change made to asset information.
Collaboration	C1	The HBIM system will present current planning/legislative/listing restraints in a manner clearly understandable to users without expert knowledge.
	C2	The HBIM system can share and receive information for related assets (both internally within an organisation and externally).
	C3	The HBIM system can present the same information in differing ways for a defined audience.
	C4	The HBIM data will be shareable with specified access controls.
	C5	The HBIM system will be aligned with existing BIM practices for non-heritage assets.
	C6	The HBIM system will integrate with other systems without duplicating information.
System operability	S1	The HBIM system will be accessible from multiple locations at the same time.
	S2	The HBIM information will be accessible to users without an internet connection.
	S3	Users without an internet connection can record new information to be input into the HBIM system.
Resource management and planning	R1	The HBIM system will indicate whether an area is private or open to the public and any restraints this poses, e.g., maintenance timing or increased level of risk for the public.
	R2	The HBIM system will collate and prepare information required for funding applications.
	R3	The HBIM system will collate and prepare information required to undertake defined activities.
	R4	The HBIM system can be used to digitally simulate planned activities.
	R5	The HBIM system will calculate the expected costs of user-defined work.
	R6	The HBIM system will record and report all details of each work activity undertaken and each future work activity planned.
	R7	The HBIM system will assist with the creation of proactive maintenance schedules, utilising both mandatory testing intervals, previous maintenance records, and current asset condition.
Visualisation	V1	The HBIM system will record and visually display information associated with the location of the asset.
	V2	The HBIM system will record and visually display each historic change to an asset (both large changes and small changes).
	V3	The HBIM system will provide a 3D visualisation of an asset.
	V4	The HBIM system will contain an accurate visual record of the current asset condition.
Public engagement	P1	The HBIM system will assist with the creation and dissemination of audience-appropriate informative materials and educational resources withthe public.
Environmental management	E1	The HBIM system will record and visually display environmental hazards associated with the asset.
	E2	The HBIM system will monitor and report the near-real-time environmental conditions of the asset.
	E3	The HBIM system will monitor and report the near-real-time performance of the asset. Performance will be evaluated against organisation-specific targets.
	E4	The HBIM system will allow the comparison of current energy performance with predicted outputs of alterations and upgrades.

contains the proposed system requirements. The requirement IDs will be used to refer to specific requirements from here onwards.

The ongoing research project will only encompass stages 1 to 4 of the v-process diagram due to the need for practical HBIM implementation to vary according to the requirements of a specific asset/organisation. However, it is the belief of the authors that, whilst practical HBIM implementation may vary, the creation of associated standards, enabled by Stages 1 to 4, will enable more consistency in HBIM approach and ensure the longevity of data to support the management of cultural heritage sites.

1.2.2. Research Aim

This article details the next stage of the research project, the aim of which is to validate the thirty-three proposed system requirements for HBIM and evaluate their relative perceived criticality for both the UK and international heritage communities. This aim corresponds with Stage 4 of the overall research methodology (Figure 1) and Stage 3 of the SE v-process diagram (Figure 2) and consists of analysing the proposed requirements.

The underpinning objectives of the article are as follows:

• O1—To evaluate the validity and relative perceived criticality of the proposed requirements (Section 3.2).
• O2—To identify any region-specific variation in requirement criticality (Section 3.3).
• O3—To assess any disagreement with the proposed requirements (Section 3.4). This will then be used to inform Objective 4.
• O4—To update requirements, as needed, according to participant feedback (Section 3.6).

The perceived criticality can be considered akin to the ‘perceived usefulness’, defined by Davis [36] as “the degree to which a person believes that using a particular system would enhance his or her job performance”. The perceived usefulness of a system is a component of the Technology Acceptance Model (TAM), a system design theory that has shown that perceived usefulness correlates with future levels of system use [37].

The evaluation of criticality is also of particular importance as, due to identified concerns over the cost of implementation [28], it is likely that HBIM implementation will be a staggered process. This work extends previous work by the authors by increasing the scope from the UK to the international heritage community.

The authors will use the term ‘HBIM’ throughout this article for consistency. The use of the term ‘HBIM’ is partly to contextualise the work within the wider research community, but also because the authors believe that, due to the lack of recognised regulations around HBIM implementation and the scarcity of its use in practice, it is still possible to define/develop HBIM in a way that will meet the needs of the heritage community.

2. Method

The requirements were recirculated to the heritage community as an online multiple-choice survey. Participants in the survey were identified via snowball sampling [38], a non-probability sampling technique where an initial sample of participants is used to identify additional participants, e.g., a participant may suggest another relevant organisation or individual. Snowball sampling is appropriate when, as is the case with this study, the population to be surveyed is either unknown in its entirety or difficult to access. Snowball sampling was also intended to mitigate potential biases that could have been introduced by the experience of the investigators. It is perhaps self-evident that the participants who exist within the relevant system of study (cultural heritage management) would have a greater appreciation of who the survey was relevant to than the investigators themselves. The initial sample of participants was identified from the participants of the previous survey, via their associations with known heritage organisations and sites, and via the investigators’ own links to industry. The only criterion for participation was experience in the management or maintenance of built heritage. The reason for this is that, whilst the entire heritage community may benefit from HBIM, it is likely that those involved in the management and maintenance of heritage will provide the initial financial and resource investment to facilitate it. The inclusion criteria were intentionally broad to encompass a broad range of perspectives.

A total of sixty responses were gathered: forty-one UK and nineteen outside the UK (consisting of respondents from fourteen different countries). Further details of the participants and their countries of origin are provided in Section 3.1. The anonymised survey responses and a blank copy of the survey itself are openly available on the UBIRA E Data Repository and are accessible at the following address: https://doi.org/10.25500/edata.bham.00001279.

In order to assess the perceived criticality for each proposed requirement (Objective 1), participants were asked to state if a requirement was ‘critical’ (a system that cannot achieve this requirement would not be useable in their role), ‘useful’ (assists with/adds value to a task but work can progress without it), for a ‘wish-list’ (viewed positively but not meeting the definition of ‘useful’ or ‘critical’), ‘not needed’, or ‘not relevant to their role’. For analysis, a response of ‘not relevant to my role’ was taken as neutral. The response option was added, as it was found in the previous survey [28,29] that, if a participant felt a question was not relevant to their specific role, they tended to pick an answer they thought would best apply to others instead of their own opinions.

To evaluate the validity of proposed requirements (Objective 1), the number of critical, useful, and not needed responses was assessed, as these were deemed most representative of the participants’ agreement/disagreement with the proposed requirement. In addition, in order to assess the average criticality of each requirement, the responses were assigned a value of three points, two points, one point, and negative one point for critical, useful, wish-list, and not needed responses, respectively. Then, the average criticality of each requirement was calculated from Equation (1). An average criticality of greater than 1 suggested the requirement was viewed positively:

$$\mathrm{A}\mathrm{v}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{g}\mathrm{e} \mathrm{c}\mathrm{r}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{c}\mathrm{a}\mathrm{l}\mathrm{i}\mathrm{t}\mathrm{y}={\displaystyle \frac{\left(no.‘Critical’\times 3\right)+\left(no.‘Useful’\times 2\right)+\left(No.‘Wish-list’\times 1\right)+(No.‘Not needed’\times \left(-1\right))}{no.responses}}$$

(1)

If a requirement received significant (>50%) critical/useful responses, minimal not needed responses, and had an average criticality of greater than 1, then it was deemed valid, as it would justifiably provide some benefit for most users. Since the intention of the ongoing research project is the standardisation of the HBIM process, a degree of generalisation is inherent, and it would be ill-considered to overly limit the requirements at this stage. Overall evaluation of the proposed requirements is detailed in Section 3.2.

As previously mentioned, this article advances previous work by the authors [28,29] by extending the scope of the requirements to the international heritage community. Since the survey used to first define the system requirements was limited to individuals from the UK, it was unknown whether the requirements would be applicable elsewhere and if their assumed importance would vary between a UK and a non-UK audience. Therefore, Section 3.3 discusses differences in perceived criticality of requirements between UK and non-UK participants, hence achieving Objective 2.

The motivation behind the overall research project was, as previously stated, participatory design and the co-creation of HBIM system requirements. Hence, allowing members of the heritage community to provide feedback on the proposed requirements and putting this feedback in by altering the requirements as required was crucial to the success of the project. To facilitate this, when participants stated a requirement was ‘not needed’ they were asked to provide an additional explanation for why they thought this. This was intended to identify any omissions or flaws with the phrasing or function of the proposed requirements. An effective requirement should be unambiguous [25], so requirements should be altered if any confusion is identified. Discussion of the ‘not needed’ responses received is detailed in Section 3.4. This meets the requirements for achieving Objective 3. Furthermore, at the end of the survey, participants were given the opportunity to suggest any additional requirements they thought had not been covered and to provide any additional comments they felt were relevant. Additional comments are discussed in Section 3.5. This enabled the achievement of Objective 4. Section 3.6 summarises all alterations made to requirements in response to participant feedback.

Future work is discussed in Section 4.

3. Results and Discussion

3.1. About the Participants

This section provides a brief overview of the survey participants. Participants were asked to provide their job title and a short description of their relevant experience.

Table 2. Job titles, organisation, and country of participants. Job titles and organisations are only included where appropriate permission has been gained. […] indicates an anonymous response.

ID	Job Title	Organisation	Country
1	Infrastructure Manager	Gloucestershire Warwickshire Steam Railway	UK
2	[…]	[…]	UK
3	Site Engineer	[…]	UK
4	Head of Historic Buildings	Historic Royal Palaces	UK
5	Joint Director	Pakistan Airports Authority	Pakistan
6	HBIM Coordinator	[…]	UK
7	[…]	[…]	UK
8	Head of Visitor Services	[…]	UK
9	Mine Director, Head of Estate Management	[…]	UK
10	Head of Estate	[…]	UK
11	Senior Estates Manager	Science Museum Group	UK
12	Estate Asset Manager	[…]	UK
13	[…]	[…]	UK
14	Learning and Engagement Officer	Holburne Museum	UK
15	[…]	[…]	UK
16	Architectural Assistant	[…]	UK
17	Estates Manager	Thackray Museum of Medicine	UK
18	Student/Architect	[…]	India
19	Estate Manager	Science Museum Group	UK
20	Monuments and Memorials Officer	Southampton City Council	UK
21	Decarbonisation and Sustainability Manager	The University of Birmingham	UK
22	Co-Leader Museums—Operations	[…]	UK
23	Curator of Heritage and Collections Care	[…]	UK
24	Beadle	[…]	UK
25	[…]	[…]	UK
26	Head of Surveying	[…]	UK
27	Building Projects Manager	Portland Works Little Sheffield	UK
28	Sites Coordinator	South Yorkshire Trades Historical Trust	UK
29	Senior Curator: Historic Buildings and landscapes	St Fagans National Museum of History	UK
30	Co-CEO	Ushaw Historic House, Chapels and Gardens	UK
31	[…]	[…]	UK
32	Research and Partnerships Manager	York Minster Fund	UK
33	Estate Building Manager	Raby estates	UK
34	Director of Property	St Paul’s Cathedral	UK
35	Head of Estates	Hereford Cathedral	UK
36	[…]	[…]	UK
37	Sales and Events Officer	[…]	UK
38	Office Manager	Llandaff Cathedral	UK
39	Facilities Manager	[…]	Republic of Ireland
40	Trustee	Finchingfield Guildhall (C.I.O.) Charitable incorporated organisation	UK
41	Head of Interpretation and Learning	York Archaeology	UK
42	[…]	[…]	UK
43	Curator	Fireground	UK
44	World Heritage Coordinator	Organisation of World Heritage Cities	Germany
45	Professor	Carleton University	Canada
46	Head of Cultural Heritage	Bermuda National Trust	Bermuda
47	Architect	Barbados National Trust	Barbados
48	Geomatics Engineer	National Technical University of Athens	Greece
49	Executive President	Din l-Art Helwa National Trust for Malta	Malta
50	Architect	[…]	UK
51	[…]	[…]	Cyprus
52	Director of Museum Collections and Curator	Filoli Historic House and Garden	USA
53	Student/consultant/retired	Public Value Consulting	Australia
54	Restoration Project Responsible	[…]	Belgium
55	Enterprise Fellow	University of South Australia (from 2026: Adelaide University)	Australia
56	Conservation Project Officer Buildings PAHSMA	Port Arthur Historic Site Management Authority	Australia
57	Architectural Graduate	[…]	New Zealand
58	PhD candidate, Conservation Architect	Victoria University of Wellington	New Zealand
59	Senior Heritage Advisor	[…]	Australia
60	Principal Heritage Officer	[…]	Australia

contains the participant IDs, which will be used throughout this article, as well as where appropriate consent has been gained, their job title and organisation, and their country.

The participants of the survey had a diverse range of experiences and job roles, so they represent a good proportion of the heritage community. However, it should be noted that there is a slight bias as the majority of participants worked solely with heritage assets, as opposed to having mixed portfolios. This was due to the nature of participant identification, where participants were identified via their known association with a heritage asset. Individuals who may only occasionally work with heritage assets or who work with large mixed-age sites (e.g., university campuses) are less visible and were thus less accessible to the investigators. Future work could seek to gather a greater number of responses from those individuals.

Another sampling bias is that approximately 68% of participants were from the UK. There are several influencing factors for this bias. For instance, the initial sample of participants was identified from participants of the previous survey, which was conducted entirely within the UK. Likewise, the investigators’ existing knowledge of UK heritage organisations and more comprehensive knowledge of UK towns and cities, enabling more targeted searches for heritage organisations in a specific area, made it easier to identify potential participants. The survey and contact enquiries were also exclusively in English, which can serve as a barrier to participation for individuals who do not speak English as their first language [18] and may explain why the majority of non-UK participants were located in regions where English is one of the official languages. There are sufficient non-UK participants to conduct a preliminary evaluation of requirement validity for the international heritage community and identify any potential region-specific variation. However, there are insufficient non-UK participants to conclusively state what the region-specific variation is. In the future, stratified or region-based quota sampling could be employed to improve the representativeness and enable more detailed analysis of region-specific variation.

3.2. Overview of Requirement Validity

Figure 3 depicts the responses to the survey for participants from all countries. Discussion of responses separated by UK and non-UK participants will be discussed in Section 3.3. Responses in Figure 3 are given in order of the largest to the smallest number of critical responses. It should be acknowledged that the perceived criticality of the requirements would vary slightly if they were plotted by accounting for the sum of both ‘critical’ and ‘useful’ responses as opposed to just ‘critical’ responses. The reason why the authors have not plotted the results in this way is that the cost of implementation is a key perceived barrier to HBIM adoption [28,29]. Consequently, it is unlikely that any but the most affluent organisations would be able to immediately implement a system that achieves all the proposed requirements. To democratise access to HBIM, initial systems should be the minimum required to provide a benefit and be functional for the end user (e.g., a system that cannot achieve these ‘critical’ requirements would not be usable in their role). ‘Useful’ (assists with/adds value to a task, but work can progress without it) and ‘wish-list’ requirements should be considered an optional addition where funds or resources allow. Siewczyński et al. [39] concisely summarise this thinking, stating “successful BIM implementation does not at all imply full implementation of all elements of the methodology, but only implementation of areas where implementation can deliver measurable results”.

The responses to the survey (Figure 3) indicated a considerable amount of agreement with the proposed requirements. For instance, every proposed requirement had at least thirty-two participants state it was either ‘critical’ or ‘useful’, and no requirement received fewer than five ‘critical’ responses. The calculated average criticality for all requirements was at least 1.3, with eighteen requirements achieving an average criticality of greater than 2, suggesting considerable agreement. Furthermore, for all but eight requirements, fewer than three participants stated they were ‘not needed’. For the remaining eight requirements, a maximum of seven participants (per requirement) stated that it was ‘not needed’. Explanations given for ‘not needed’ responses will be detailed in Section 3.4.

The requirements that received the most critical responses (80th percentile) were from the information management (requirements I1, I2, I3, and I4) and collaboration (C4) requirement themes. This provides evidence to support the author’s proposed root definition of HBIM, which suggests that HBIM should have a primary focus on structured information management. Furthermore, it suggests that existing HBIM development, much of which prioritises geometric model creation [6,7,8,9,10], is not addressing the key needs of the end user.

Figure 3. Criticality of proposed system requirements (all participants). Requirements plotted from most critical to least critical.

Figure 3. Criticality of proposed system requirements (all participants). Requirements plotted from most critical to least critical.

Given the diversity of CH assets and the needs of specific individuals and organisations, actual HBIM implementation will justifiably vary across use cases. For instance, Participant 11 and Participant 19 were from the same parent organisation (but different sites) and both worked as estates managers in some capacity, but their answers varied somewhat. Thus, it is important that any organisation looking to develop or procure a system using these system requirements as a basis should engage individuals from all areas to make sure all needs are encompassed. However, a degree of generalisation is inherent to standard creation. Therefore, complete agreement with a requirement was not required for it to be considered valid. Since most participants (>50%) believed every requirement would provide some benefit (inferred from a response of critical or useful) and the perception of the requirements was generally positive (inferred from an average criticality of at >1), the proposed requirements can be considered valid.

3.3. Region-Specific Variation

The requirements were originally developed only with input from the UK heritage community [28,29]. Therefore, it was initially unknown if they would be applicable internationally. As previously stated, due to the participant sample, it is not possible to provide a conclusive analysis of the region-specific variations. However, it is possible to provide some preliminary evaluation of the variations in relative perceived criticality for UK and non-UK participants. Figure 4 and Figure 5 depict the results of the survey, separated into results from UK (Figure 4) and non-UK (Figure 5) participants, and plotted in order of the number of critical responses received. The average criticality of each requirement for UK and non-UK participants has also been plotted.

It was found that both the UK and non-UK participants generally agreed with the requirements. The average criticality was greater than 1.2 and 1.3 for UK and non-UK responses, respectively, and all requirements received at least 50% critical or useful responses from UK participants. Likewise, the majority of requirements received at least 50% useful or critical responses from non-UK participants. However, only 47% of non-UK participants believed requirements E4 and E2, which both related to monitoring the energy performance of an asset, were either useful or critical. This may suggest some doubt in the validity of requirements E2 and E4. However, the calculated average criticality for requirements E2 and E4 was approximately 1.3 and 1.5, respectively, suggesting that they were at least viewed positively. Since the average criticality of requirement E2 and E4 was greater than 1, and the number of useful or critical responses was almost 50%, it is assumed that the requirements can be considered valid for non-UK participants at this time. However, additional international responses would enable a conclusive evaluation of requirements E2 and E4. The requirements are thus considered valid for both the UK and non-UK heritage community.

Whilst both UK and non-UK participants generally agreed with the requirements, and, for both groups, the four most critical (the greatest number of ‘critical’ responses) were from the information management requirement theme, and there were some notable differences in the relative perceived criticality of the requirements. The following paragraphs will discuss some of the region-specific variations and potential explanations for these variations. The potential explanations are theorised from the known characteristics of the participants (e.g., job roles and stated experience) and the knowledge of the authors. However, since participants were not asked to explain why they had given a particular answer, it is not possible, and would not be appropriate, to claim to conclusively determine causes of apparent region-specific variation.

For reference, Figure 6 depicts the percentage of responses that were critical for UK and non-UK participants. The percentage of critical responses has been chosen for the analysis because, as previously stated, the authors believe that initial HBIM system design should prioritise critical requirements due to assumed cost and resource limitations. Therefore, for the purposes of the ongoing research project, variations in the number of critical responses are the most significant variations.

Requirements I1, “the HBIM system will contain a comprehensive and accurate record of asset information (regardless of form)” and I4, “the HBIM system will have a structured, reportable, and viewable data storage schema” had a 20% and 24% variation, respectively, in the percentage of critical responses. However, the authors do not believe this variation is significant. For both requirements, more than 90% of responses were either critical or useful for UK and non-UK participants. Thus, it seems a reasonable assumption that the variation may just be due to the individual perception of individual participants, perhaps due to the perceived feasibility of the requirement.

Perhaps the most significant difference in perceived criticality, given the tendency of HBIM research to date to focus on model creation [8,23], was that non-UK participants generally considered visualisation-themed requirements (particularly V3) more critical than UK participants. There are two likely explanations for this preference. Firstly, many of the international participants were in areas that experience natural disasters that risk destroying heritage sites. In addition, many of the non-UK participants identified as architects, a profession that relies on visual depictions, whereas the UK participants were typically involved in building management.

The exception to this was requirements V1, which was perceived as more critical by UK participants. This may be caused by existing working practices and systems within the UK heritage community. For instance, historic environment records (HERs), the system where local authorities record information [40], are often linked to geographic information systems (GIS), and Historic England has recently launched Arches for HERs [41], which also encompasses GIS.

Another notable difference (29%) is in the perceived criticality of requirement I8: “the HBIM system will record and report each change made to asset information”. This difference may also be attributed to job roles of the UK and non-UK participants and the corresponding length of time the participant would be involved with a specific heritage asset. It is a reasonable expectation that building and estate managers (primarily UK participants) who are responsible for the long-term management of an asset would perceive monitoring any changes over time to information as more critical than individuals involved in comparatively short-term projects (e.g., architects).

Requirements C5 (the HBIM system will be aligned with existing BIM practices for non-heritage assets) and C6 (the HBIM system will integrate with other systems without duplicating information) also had a 30% and 23% variation, respectively, in the percentage of critical responses, with UK participants seemingly deeming both less critical than non-UK participants. C5 referred to aligning HBIM with BIM practices for non-heritage assets, so this is likely due to the experience of UK participants, primarily being responsible for heritage assets. In fact, ten of the eleven ‘not relevant to my role’ responses to requirement C5 were given by UK participants. If the survey were continued to gather a greater number of responses from individuals involved in mixed-use sites, then the perceived criticality may change. C6 referred to integrating HBIM with other systems without duplicating data. Explanation for the low perceived criticality for UK participants may be provided by the previous stage of the research project. The initial survey found that many of the participants were still only at the initial stages of adopting digital systems and documentation, and that many of the systems in place were ready-made systems like SharePoint [28]. Hence, it is unlikely that these systems would be perceived as critical enough to keep or complex enough to make integration difficult. Conversely, the non-UK participants, many of whom had experience with more advanced digital documentation of heritage assets, may have been more likely to encounter issues with duplicating information or integrating systems. Repeating the initial survey from the previous stage of the study with an international audience may provide greater clarity in these differences.

This section has discussed seven of the proposed requirements where there was an apparent variation in the perceived criticality of the requirements by UK and non-UK participants. It has been theorised by the authors that the key causes for the variation may be due to differences in existing working practices in different regions and the primary job roles of the participants. Future work may seek to investigate these differences further.

3.4. ‘Not Needed’ Comments

3.4.1. Overview of ‘Not Needed’ Comments

The following sections detail the ‘not needed’ responses received and any alterations made consequently. Discussion is grouped by requirement theme. The final alterations to requirements are detailed in Section 3.6. By asking participants to provide additional comments on why they believed a requirement was not needed, the authors hoped to understand the views and implicit assumptions that may have influenced their answers. Understanding the ‘weltanschauung’ of participants, a German term broadly translated as ‘worldview’ [42], is a key element of the SSM systems thinking approach employed by the authors [32]. This was successfully achieved by the survey, as it was found that ‘not needed’ responses generally corresponded with four different themes: a flaw in the phrasing of the requirement, opinions based on their own organisation or experience, perceptions of the capabilities of HBIM, and, lastly, outright disagreement with the requirement.

The proposed system requirements are intended to be aspirational and capable of guiding research in the future. Thus, disagreement with a requirement because it may not yet be possible or because its realisation may be complex is not sufficient to completely discount it at this stage. No requirement received sufficient ‘not needed’ responses to warrant its removal. However, nine requirements were altered to reflect participant feedback. Further discussion of the alterations is given in Section 3.6. The following sections provide the justification for all alterations made.

3.4.2. Information Management (I)

Only the requirements I5, I6, and I7 of the information management theme received a ‘not needed’ response.

Participant 38 suggested requirement I5 (the HBIM system will allow information to be viewed at different degrees of granularity) was not needed, saying “the visual is less important”. Whilst viewing and preparing model objects at different degrees of granularity is established in BIM practice [43,44,45,46], the requirement was intended to refer to any type of information. Requirement I5 has been amended accordingly.

The three ‘not needed’ responses for I6 (the HBIM system will allow all information to be accessed from a single source) suggested a flaw in the phrasing of a requirement as opposed to opposition to the requirement. Requirement I6 refers to accessing information from a single source. This was intended to mean that users looking for information can locate any information from a single platform, software, database, etc., even if the information itself is hosted elsewhere. A simplified example of this in practice would be a Revit model that includes URL links to an information database. Whilst the information may be stored in the database, it is accessible from the Revit model. However, the ‘not needed’ comments from Participants 47, 49, and 51 indicated that they were not sure what “a single source” meant or that they believed that it referred to storing all information on a single piece of software or as a single file. I6 has thus been amended to remove this ambiguity (see

Table 3. Alterations to proposed system requirements. Alterations and additions to requirements are indicated via italics.

Requirement Theme	ID	Requirement
Information Management	I5	The HBIM system will allow information (irrespective of format) to be viewed or exported at different degrees of granularity.
	I6	The HBIM system will allow all information to be accessed from a single source (i.e., a single platform/software/database/hardware/etc.). Information may be stored elsewhere.
	I9	The HBIM system will contain comprehensive and accurate metadata regarding asset information. Note—The types of metadata may be asset/organisation specific.
Collaboration	C4	The HBIM data will be shareable with interested parties with specified access controls and monitoring processes. Example monitoring processes may include version control or download tracking.
Resource management and planning	R2	The HBIM system will collate and prepare supply information required for funding applications.
	R3	The HBIM system will collate and prepare supply information required to undertake defined activities.
Visualisation	V2	The HBIM system will record and visually display each known or theorised (appropriately indicated) historic change to an asset (both large changes and small changes).
Public engagement	P1	The HBIM system will assist with the creation, and dissemination of, audience-appropriate informative materials and educational resources with for the public.
Environmental management	E2	The HBIM system will monitor and report the near-real-time right-time data regarding the environmental conditions of the asset. Environmental conditions derived from information such as temperature, light, humidity and weather etc.
	E3	The HBIM system will monitor and report the near-real-time right-time data regarding the performance of the asset. Performance will be evaluated against organisation-specific targets.
	E4	The HBIM system will allow the comparison of current energy performance with predicted outputs of alterations and upgrades.

).

Regarding requirement I7 (information in the HBIM system should be associated with a digital entity with a known position in space), Participant 56 stated “we intend to have monitoring coupled with our asset management system where possible GIS will be integral to this” seemingly implying they believed it was not needed in a new HBIM system as it was a functionality already present in their existing digital information management systems.

3.4.3. Collaboration (C)

Participant 11 believed requirement C1 (the HBIM system will present current planning/legislative/listing restraints in a manner clearly understandable to users without expert knowledge) was not needed since “users of this type of dataset are task specific and usually skilled and aware of these issues”. This implies the criticality of the requirement may be organisation-specific and depend on the size/experience of the relevant stakeholders.

Requirement C3 referred to presenting information in differing ways for a defined audience. Both Participant 6 and Participant 51 expressed thoughts about the complexity of this in reality and the risks to appropriately managing data. Participant 51 suggested “different levels of details in term of 3D is possible, but different representations, might be too complex”.

Requirement C5 (the HBIM system will be aligned with existing BIM practices for non-heritage assets), whilst only receiving one ‘not needed’ response, received the largest amount of ‘not relevant for my role’ responses. This is likely due to many participants working exclusively with heritage assets as opposed to mixed portfolios. Participant 49, who stated it was ‘not needed’, suggested “non-heritage assets may have very different concerns that heritage ones do not have and vice-versa. I think that the nature of heritage assets has to do with cultural values, history and memory whereas BIM practices for non-heritage assets are likely to be more technically oriented”. Likewise, as an additional comment, Participant 44 suggested “first a model which understand heritage as a System is urgently needed. When we work with BIM and GIS, we first need a theoretical Model what is the heritage system and what are its parts, categories etc. Otherwise only sectoral Information will dominate/structure the model”. Whilst the authors acknowledge that the principles for managing a heritage asset differ from managing a non-heritage asset, they do not believe that this difference is so substantial as to warrant entirely new processes/systems. For instance, investigating the cause of concrete deterioration is similar in principle to investigating the decay of ancient timber. The decision-making and exact sources/types of information may differ, but the general format remains the same. Furthermore, not aligning HBIM with BIM processes limits the longevity of BIM itself. In many countries, BIM use is mandated and thus more commonly adopted for new projects [47]. Since there is no way of determining what new asset will be considered heritage in the future, BIM and HBIM being completely incompatible systems will result in information inevitably being lost and work being duplicated. Since BIM is a far more mature field than HBIM, the alignment must be made by HBIM systems as opposed to BIM systems.

Future work by the authors will investigate the realisation of the requirements, at which stage it may be decided that requirement C5 is not feasible.

With respect to requirement C6 (the HBIM system will integrate with other systems without duplicating information), Participant 6 suggested “[integrating HBIM with other systems] is impossible without duplicating. Integration always involved in duplication”. This indicates uncertainty regarding the feasibility of the requirements as opposed to disagreement with the requirement itself. They also suggested that a “separate HBIM system is a mandate”. However, the authors are not aware of any mandates that require HBIM to be entirely separate from other systems. They may be referring to a local or organisational mandate. The following was also noted as an additional comment by Participant 12: “there seems to be a lot of cross over between BEMS [Building Energy Modelling Software], Asset Management System and BIM data/management and how would this fit in or align with a CAFM [Computer Aided Facilities Management] system?”. Digital asset management now often uses several unconnected softwares, such as the types suggested by Participant 12. However, in the previous survey [28,29], participants suggested that the siloing of information was a key existing challenge to the management of heritage data. Hence, it is evident that a future HBIM system must either entirely replace the functionalities of these existing systems or allow the integration of these tools, and so they become a connected system of software. The latter is the most feasible as, as noted by Participant 3, it will “be difficult for one software to dominate so it needs to be able to be used in conjunction with other systems”.

Whilst it is true that integrating HBIM software with other software has involved data loss and duplication in the past, such as in the work by Colucci et al. [48], the authors believe that ongoing work into improving the interoperability of systems and comprehensive data standards, as recommended by the Centre for Digital Built Britain (CDBB) [49], may mitigate this in the future. This will be covered in greater detail in future work by the authors.

3.4.4. System Operability (S)

Participant 52 responded ‘not needed’ for requirement S1 (the HBIM system will be accessible from multiple locations at the same time) but provided no additional explanation.

Discussion regarding S2 and S3, referring to accessing and recording information without an internet connection, has been grouped because each received seven ‘not needed’ responses for similar reasons. Participants 15, 25, 38, and 41 responded ‘not needed’ to both and suggested that access to the internet was an assumed resource for all potential users. Regarding requirement S2 (the HBIM information will be accessible to users without an internet connection), Participant 42 stated, “for safety and data protection, live and accurate information must be available at all times,” and Participant 6 believed “cloud integration is a key [part of an] HBIM system”. Similarly, in response to requirement S3 (users without an internet connection can record new information to be input into the HBIM system), Participant 10 suggested, “upload of this type of information is infrequent and can usually wait access to an internet connection,” and Participant 51 suggested that “Internet connection is necessary for simultaneous users,” noting that it was only not required “during the recording phase, or if a limited and controlled numbers of users”. Participant 57 stated they “cannot imagine [requirement S3] working”. Since requirements S2 and S3 only received 5 and 11 critical responses, respectively, they may be considered low priority for any system development and should only be implemented if the suggested issues can be mitigated.

3.4.5. Resource Management and Planning (R)

With the exception of requirement R6, every requirement in the resource management and planning theme received at least one ‘not needed’ response. Many of these responses can be attributed to perceptions regarding the function of HBIM. In particular, the perception is that HBIM and operational systems must be separated. This may be attributed to the lack of integration between BIM for construction and BIM for facilities management purposes [8,14,50,51]. For instance, whilst Participants 27 and 51 believed that requirement R1 (the HBIM system will indicate whether an area is private or open to the public and any restraints this poses, e.g., maintenance timing or increased level of risk for the public) was not applicable to their own sites, Participants 22, 25, and 54 suggested that an HBIM system was not the place to have/communicate information regarding whether a site is private or public.

Requirement R2 suggested HBIM should collate and prepare information required for funding applications. The three not needed responses suggested the funding applications should be separate (Participant 6) and that utilising HBIM for this purpose would complicate the process (Participants 22 and 54). However, in the previous stage of the research project [28,29], participants suggested that the time and resources required to undertake funding applications were a considerable problem and that any capability that made finding the required information easier would be beneficial. Whilst Participant 54 was from Belgium, both Participants 6 and 22 were from the UK, so this perception cannot be attributed to funding processes in different countries. Requirement R2 has been altered to “collate and supply” for clarity.

Participant 22 suggested requirement R3 (the HBIM system will collate and prepare information required to undertake defined activities) was too complex, and Participant 60 stated the government they worked with did not like using bespoke systems. They noted that there are budget concerns regarding giving other users access to the information, particularly digital imaging and geospatial surveys, and that there is a perception that expensive software is required to view such information. This is a misconception that the authors have repeatedly encountered throughout the research project. Whilst software that requires a greater financial commitment may provide more sophisticated capabilities, there are several low-cost and even free, open-source software that allow users to view and interrogate the information.

Participant 22 suggested that requirement R4 (the HBIM system can be used to digitally simulate planned activities) would overly complicate an HBIM system. However, activity planning (also known as 4D BIM [52]) is an established part of existing BIM software, and therefore, is arguably an expected capability.

Four participants (22, 25, 41, and 49) believed that using HBIM for predicting the cost of works (requirement R5) would be too complex and would be unlikely to produce accurate results since heritage activities are often bespoke or have complex supply chains. However, Participant 25 noted that it would be “amazing if possible but if it’s not accurate, it’s not needed.” Participant 60 only intended to use an HBIM system for recording conditions and, therefore, believed requirement R5 was unnecessary.

Participant 33 believed requirement R7 (the HBIM system will assist with the creation of proactive maintenance schedules utilising both mandatory testing intervals, previous maintenance records and current asset condition) was not needed since, in their experience, “planned maintenance is managed separately”. However, they did “accept HBIM could become part of the process”. Attempts to integrate HBIM with these processes should either be an improvement or an addition to existing processes.

3.4.6. Visualisation (V)

The two participants who responded not needed for Requirements V1 (the HBIM system will record and visually display information associated with the location of the asset) and V3 (the HBIM system will provide a 3D visualisation of an asset) provided no additional explanation.

Regarding requirement V2 (the HBIM system will record and visually display each historic change to an asset (both large changes and small changes)), Participant 57 suggested it was “too much work and guessing which may not be accurate”. The requirement has been altered so that only known or theorised (indicated with appropriate notation) changes are included.

In response to requirement V4 (the HBIM system will contain an accurate visual record of the current asset condition), Participant 6 stated “we have an existing EPC [energy performance Certificate] visual record system available”, suggesting they believed the functionality was already met elsewhere.

3.4.7. Public Engagement (P)

Regarding requirement P1 (the HBIM system will assist with the creation, and dissemination of, audience-appropriate informative materials and educational resources with the public), Participant 6 stated, “public could not assist with the creation unless they are trained under IHBC [Institute of Historic Building Conservation] guidelines”. The requirement was not intended to define who should be creating the materials, as this will likely be up to the discretion of the asset owners. Consequently, it has been slightly altered to reassert that the materials should be created for the benefit of the public.

3.4.8. Environmental Management (E)

Requirement E1 (the HBIM system will record and visually display environmental hazards associated with the asset) received only one not needed response. Participant 38 suggested they were not the kind of site to need information on nearby environmental hazards, perhaps suggesting there were none nearby.

Requirements E2 and E3 refer to utilising HBIM for the near real-time monitoring and reporting of building condition/performance, and each received seven not needed responses. The requirements are, as noted by Participant 51, akin to the concept of digital twins. There are numerous differing definitions of digital twins across multiple sectors (e.g., construction and manufacturing) [53]. However, for clarity, this article will use the definition of digital twins as given by the UK Government: “a virtual model of an object, a system, or a process […] connected to its real-world counterpart by a 2-way flow of right-time data” [54].

Participant 51 suggested, for both requirement E2 and E3, “BIM and digital twin are two separate technologies at the time being. Fusion could be anticipated but currently we are having trouble defining and having tools for BIM—let alone twins”. Likewise, Participant 12 suggested requirement E2 was “better provided by BEMS” and Participant 27 suggested it was “beyond the scope of BIM”.

The authors acknowledge that BIM and digital twin technology integration is, currently, still in its infancy [12,13,55,56,57,58]. However, they also believe that if digital twin capabilities are a requirement for the end user, then HBIM should be developed with consideration of this to avoid future issues and facilitate its implementation as technology develops. Furthermore, innovative BIM tools that integrate BIM information with digital twin technology are now in use, meaning it is likely to become an established future part of BIM. Justification for this can be provided by the University of Birmingham’s digital campus model, wherein the estates department integrated their portfolio of BIM and HBIM models with Autodesk Tandem to leverage twin technology [59] and, consequently, achieved significant financial savings. The case study may also alleviate the concerns of Participant 27, who suggested they were “not sure of the benefit [of requirement E3] against the cost of administration”.

In response to participant feedback, requirements E2 and E3 have been slightly altered. The original iteration of the requirement referred to ‘near real-time data’; however, several participants indicated that, whilst the information itself may be useful, real-time data was likely superfluous. Consequently, the requirements have been altered to ‘right-time data’. Notably, this correlates with the UK government’s definition of digital twins [54] and with the British edition of the standard for digital twins, ISO/IEC 30173:2023 [53], both of which suggest the frequency of data update is specific to the use case. This once again places the onus on the end user, who must define for themselves the appropriate frequency of data synchronisation. Similarly, Participant 12, in response to requirement E3, queried what kind of performance would be measured, suggesting “some would be useful and some wouldn’t”. The requirement is intentionally broad so it can be implemented as needed by specific organisations. To provide too much specificity would diminish its applicability.

Requirement E4 (the HBIM system will allow the comparison of current energy performance with predicted outputs of alterations and upgrades) was deemed “beyond the scope” by Participant 27, and Participant 60 thought it was not needed as “the majority of our heritage places do not have an operational use”. It is not unreasonable that a participant working primarily with ancient heritage (lacking utilities that would use energy) or heritage that is unoccupied/not regularly visited would consider monitoring the current energy performance and planning alterations superfluous to their needs. Hence, it can be assumed that the perceived criticality of requirement E4 is dependent on the type of asset.

3.5. Additional Comments

3.5.1. Overview of Additional Comments

At the end of the survey, and in order to help further meet the requirements of Objective 4, participants were asked if there were any additional requirements they felt had not been covered, and if they had any additional comments to add. Responses primarily discussed perceived barriers to implementation, perceived benefits to implementing an HBIM system according to the requirements, implementation plans at their own organisations, comments regarding methods of working, and additional comments about specific requirements and information that an HBIM system should contain. Discussion of the additional comments in this section will be grouped as follows: general perceived benefits or barriers to implementation, additional suggested requirements (information and system), and required areas of development. The latter refers to areas of development and/or research that would enable or increase the implementation of HBIM.

3.5.2. General Perceived Benefits or Barriers to Implementation

Several participants believed that implementing an HBIM system according to the requirements would be useful (Participants 2, 25, and 45). Although some indicated doubt over the feasibility of HBIM for listed assets (Participant 36) and concerns that implementing such a system may hinder the management of heritage assets (Participant 45). Participant 18 was particularly enthusiastic about the potential collaborative benefits provided by HBIM, particularly the ability to better engage with clients in their role as an architect. They summarised the perceived benefits by suggesting “integrating HBIM can greatly enhance client engagement by providing them with timely insights and the flexibility to make informed decisions regarding restoration priorities”. Participant 6 took a different stance, suggesting that there should be better collaboration opportunities for those creating and using HBIM (assumed to be referring to individuals from differing organisations or working on different projects).

A consistent theme identified throughout the research project has been a concern over the potential costs of implementing and maintaining HBIM [28,29]. This was reiterated in the current survey (Participants 2, 32, 36, and 49). For instance, whilst specifically referring to requirement I6, Participant 49 stated, “assuming that the information is only available through very sophisticated and expensive software then this will not be useful to organisations like ours. Ideally the information should be readily available to all”. Similarly, Participant 2 suggested that “any system should be open-source and using open standards” stating that it is “unlikely to be financially viable for many heritage organisations to pay for the high costs of a proprietary product”. Open-source tools and open standards could provide significant financial benefits and help realise shared networks of information, such as the ‘National Digital Twin’ proposed by the CDBB [49] or a standard network for sharing cathedral-related information as proposed by Participant 35. However, the authors do not believe it is a limiting requirement for an HBIM system. It is instead an organisational constraint, the extent of which will be determined on a case-by-case basis for those implementing HBIM. For instance, Participant 36 suggested an alternate solution to financial concerns, stating any “system should be modular to allow those not so well off to buy a standard package and then bolt-on as required extras”.

Another major concern was that any future system be ‘user friendly’ (Participants 26, 32, 36, and 49), with others referring to existing problems or perceived concerns related to the long-term storage of data (Participants 23, 26, 31, and 32). Several participants commented on the potential training required (both regarding training BIM professionals in a heritage context and training heritage professionals with BIM processes) or the perceived digital literacy of the potential end users (Participants 2, 36, 53, and 57). Whilst these concerns are valid, having been encountered previously in the study [28,29], they are constraints to the realisation of the system as opposed to system requirements. A prerequisite of any well-designed information system is that it should be easy to use and operate, easy to maintain, and easy to enhance [22]. Similarly, Participant 59 suggested any system would need to have a high level of cyber security as it would “provide a lot of information for those wanting to exploit a situation or destruction/theft of an asset”. Whilst this is a critical requirement, it is not novel to the field of HBIM and should just be taken as a prerequisite of good system design.

3.5.3. Additional Suggested Requirements (Information and System)

Participants suggested that an HBIM system should record (Participant 45)/export (Participant 55) information at different levels of detail (LoD). LoD is an existing BIM concept where objects are modelled to different degrees of geometric accuracy and with different amounts of associated information according to user need [15]. This has now been superseded by the concept of the level of information need [60], which defines need in terms of geometrical information, alphanumeric information, and documentation. To reflect the suggestions of Participant 55, requirement I5 has been altered to include the export of information. Whilst the authors agree that recording information according to the defined level of information need is undoubtedly useful, it is not so much a system requirement as it is an organisational activity, e.g., an organisation/individual should input information to the HBIM system according to their identified level of information need.

Participant 55 made a number of useful extra comments, suggesting an HBIM system should “have authoritative status linked [and] conform to Semantic Web principles” and that it would be beneficial if “parts can [be] export[ed] and be annotated [and] downloads can be tracked”. Responses to each comment in turn are as follows:

• Knowing the source and authority of data (authoritative status) is critical for information management and heritage management and should be reflected by an HBIM system. Thus, a new system requirement (see requirement I9 in Section 3.6) was proposed: “the HBIM system will contain comprehensive and accurate metadata regarding asset information. Note—The types of metadata may be asset/organisation specific”. The metadata proposed should encompass the authoritative status suggested. The requirement has been framed as ‘metadata’ as opposed to ‘authoritative status’ as the inclusion of metadata for specific information requirements had already been suggested by participants in the previous stages of the research project [28,29]. This fact, combined with the comments made by Participant 55, suggested that there should be a clear distinction between ‘asset information’ and ‘metadata regarding asset information’. Hence, a new requirement was needed.
• Incorporating semantic web principles is a topic that has previously been investigated in the field of HBIM [61,62] and has demonstrated tangible benefits. However, the authors believe that it is better attributed as an opportunity for realising the requirements under the ‘information management’ theme as opposed to a requirement itself.
• Exporting information is arguably already encompassed by requirement C4. However, allowing exports (presumably offline) for annotation may result in individuals using outdated information. Similar issues were raised by participants when discussing requirements S3 and S4 (see Section 3.4.4). Therefore, requirement C4 was altered to include the addition of monitoring processes for sharing data. This should also encompass the suggestion that downloads should be tracked.

Participant 31 suggested an HBIM should include the “location of known hazardous materials (e.g., asbestos) [and a record] of condition including photos”. Both requirements were proposed as information requirements for HBIM in the previous stage of the research [29]. Likewise, Participant 12 suggested the HBIM system could detail “life cycle and, cyclical replacement and differing stratifies such as run to fail, within the HBIM to enable differing cost options” and Participant 45 suggested HBIM “could make suggestions for maintenance works on certain elements of the monument/site”. The cost of work and details of maintenance requirements were also identified as an HBIM information requirement. Thus, the comments made by Participants 12, 31, and 45 provide additional evidence to support their proposal.

Whilst some responses from the survey seemed to suggest an HBIM system should be making management suggestions, and another recurrent comment was regarding the need to retain the human element of asset management, with Participants 3 and 53 suggesting technology alone was insufficient to adequately manage heritage assets. Participant 17 proposed that an HBIM system could have a “facility to have progress reports”. However, it is unclear whether they were referring to the system creating the reports or simply storing them. Participant 33 suggested “most historic/listed buildings which are managed well have a process in place to ensure continued maintenance and upkeep is paramount. HBIM is another layer of management which stands slightly apart from the maintenance aspect, although accept the two may combine. I don’t see HBIM becoming one single driver of asset management”. The authors agree that, particularly with the need to make balanced decisions in a heritage context, any HBIM system should, at this time, purely be for managing and supplying information as opposed to actual decision-making.

Participant 60 was interested in whether the proposed system would be applicable to the monitoring of cultural landscapes. While a few requirements (primarily those under the ‘environmental management’ theme) may not be as applicable, the authors see no insurmountable reason why a system developed according to the proposed system requirements could not be applied to the monitoring of cultural landscapes. In fact, the initial questionnaire used to define the system requirements received significant input from individuals involved with cultural landscapes [28]. It is likely that the only key changes that would be required would be the actual technology used to realise the requirement. The most significant potential barrier to this would be the current lack of interoperability between technology for documenting buildings (primarily BIM tools) and technology for documenting landscapes (primarily GIS) [63,64,65,66], meaning there may potentially be challenges for those seeking to utilise one system for both purposes. However, there is ongoing work being undertaken by others that seeks to mitigate this [67,68]. Participant 2 also believed that HBIM should be integrated with GIS tools.

3.5.4. Required Areas of Development

Participant 59 stated, “HBIM and BIM needs to be mandated by legislative instruments. I have been trying to get HBIM implemented in Australia for over 20 years. BIM has been pushed in consultancy for over 35 years but has gained very little traction”. BIM adoption has been shown to increase with BIM mandates [47]. However, even though, at least for the UK, historical assets are not excluded from existing mandates [16], HBIM adoption remains low. The solution to this may be more comprehensive mandates and actionable enforcement for HBIM adoption. It should be noted that a specific HBIM mandate would not be possible without associated standards, which this work hopes to inform.

Another element of standardisation that will enable the greater adoption of digital systems [49] will be the creation or identification of relevant data classification schemas. This is an existing barrier to HBIM adoption as identified by Participant 50, who asked, “how is information from project delivery integrated into asset management system as currently they use separate classifications?” and later added, “what classification will be used for asset management of historic assets?”. This is an acknowledged barrier to HBIM adoption [69,70,71], and there have been frequent attempts to address this within the research community [72,73]. At this stage, the authors cannot provide an answer to this. However, potential solutions will be investigated in the next stage of the research project.

3.6. Alterations to Requirements

In meeting the requirements of Objective 4, all changes to requirements are indicated by italics in Table 3. Only altered requirements are included. The remaining requirements can be considered valid without alteration. As a result of participant feedback (both the ‘not needed’ explanations and additional comments), nine of the proposed requirements were altered and one requirement was added (requirement I9). An eleventh requirement (requirement E4) was altered, as the authors felt the initial iteration was unnecessarily exclusionary. The discussion in Section 3.4 and Section 3.5 provides the justification for the proposed changes.

4. Future Work and Conclusions

This article details the latest contributions in an ongoing research project utilising systems thinking, particularly system engineering, to enable the standardisation of HBIM. It addresses key occlusions in HBIM research to date, namely the lack of defined information management that end users need for the heritage community, without which it is not possible to assess the validity of any current or future HBIM system.

The article uses participatory design principles and the concept of ‘perceived criticality’ to validate the thirty-three system requirements for HBIM previously proposed by the authors and evaluate their relative criticality for both the UK and international heritage community. The thirty-three system requirements were found to be valid for both the UK and international heritage communities, with every requirement receiving at least thirty-two (greater than 50% of participants) critical or useful responses and every requirement achieving an average criticality of greater than 1 (achieving Objective 1). However, some variation in the relative criticality of the requirements according to region was identified (achieving Objective 2). The most notable of which was the perceived criticality of system requirements related to visualisation. The authors theorised that the key causes for all identified variations may be due to differences in existing working practices in different regions and the primary job roles of the participants. Future work may seek to investigate these differences further.

As part of the research’s participatory design approach, nine requirements were updated, and an additional requirement was added, to reflect feedback received from participants (achieving Objectives 3 and 4). One requirement (requirement E4) was altered by the authors to encompass a greater scope. Consequently, this article completes the third stage of the v-process diagram (Figure 2) for system design, ‘requirements analysis’, and enables the design of a future HBIM system according to the HBIM system requirements. The system requirements contained herein can also be used by others to validate and verify their own implementation of HBIM, an action that is not possible without a comprehensive understanding of the end-user needs [19,25].

Future work by the authors will compare the validated requirements to available BIM and HBIM technology to identify opportunities for their realisation and to propose required areas of development. A theoretical framework for the initial stages of HBIM implementation will be proposed. This will encompass Stage 4 of the SE v-process diagram (Figure 2).