Requirements management interface to building product models

Dissertation

Arto Kiviniemi

Research output: ThesisDissertationMonograph

Abstract

In current AEC practice client requirements are typically recorded in a building program, which, depending on the building type, covers various aspects from the overall goals, activities and spatial needs to very detailed material and condition requirements. This documentation is used as the starting point of the design process, but as the design progresses, it is usually left aside and design changes are made incrementally based on the previous design solution. As a consequence of several small changes and without any conscious decisions to change the scope, this can lead to a solution that may no longer meet the original requirements. In addition, design is by nature an iterative process and the proposed solutions often also cause evolution in the client requirements. However, the requirements documentation is usually not updated accordingly. In the worst case the changes are recorded just in the memory of the participants, and in the best case in meeting or personal notes. Finding the latest updates and evolution of the requirements from the documentation is very difficult, if not impossible. This process can lead to an end result which is significantly different from the documented client requirements. Some important client requirements may not be satisfied, and even if the design process was based on agreed-upon changes in the scope and requirements, differences in the requirements documents and in the completed building can lead to well-justified doubts about the quality of the design and construction process. My observation is that even a simple active link between the client requirements and design tools can increase the use of requirements documentation throughout the design and construction process and facilitate necessary updates of the client requirements. The key limitation is the lack of a theory to link the requirements to the design systems. A solution to the above mentioned problems can build on the following five main points of departure: (1) design as an information process, (2) existing client requirements documentation and hierarchies, (3) Lawrence Berkeley National Laboratory's Design Intent Tool for technical systems, (4) existing IFC specification and its implementation, and (5) Building Lifecycle Interoperable Software (BLIS) implementation views to the IFC specification. My research is also part of CIFE's Virtual Design and Construction (VDC) framework. Objects in the requirements model specification represent desired product form in the Product-Organization-Process (POP) ontology. I addressed the challenges by formalizing a requirements model specification which can be linked to a building-product-model-based design model of the project. My research consisted of four phases: (1) analysis of client requirements, (2) development of a requirements model specification and its links to the IFC specification, (3) extension of the BLIS view for IFC implementation, and (4) validation of the requirements model specification. Based on the requirements analysis, the number of possible requirements is high but only a few of them are used on most projects. However, the linkage of direct and indirect requirements to the design model is complicated and cannot be defined on a project by project basis only. Thus, my requirements model specification is based on an inclusive approach; all relevant requirements which were identified in my research are included in the specification, and each requirement object includes the direct and indirect links to the different levels of detail in the design model. The specification covers 300 requirements in 14 main and 35 sub-categories. It is based on a synthesis of two large, widely used requirements hierarchies, analysis of requirements in five building programs and spatial requirements in the current IFC specifications. These requirements are organized in the specification into 7 main-level and 30 sub-level requirements objects which have direct links to 5 levels of detail and 2 systems in the building product model plus indirect links to 4 levels of detail and 12 systems. The size and complexity of the specification can be managed by a good user-interface design, which is one of the proposed future research topics. The main scientific contribution of my research is this requirements model specification, based on the following main concepts: (1) division of a project's data set into four main models; requirements, design, production, and maintenance models, (2) requirements related to the different levels of details in building product models, and (3) direct and indirect requirements. Although the detailed requirements relate mainly to the architectural design, the main concepts of the specification are not domain-specific and apply to a general interface between requirements and building product models. The same link mechanism which is used between objects in the requirements and design models applies also between objects in different design and production models. My specification defines the structure of the requirements model. Its purpose is to serve as the basis for software development. For AEC professionals it is useful only if implemented into software products. Thus, the main practical implications of my work are that (1) the requirements model specification enables implementation of requirements management applications linked to building product models, and that (2) the use of such applications can improve the management of detailed client requirements in the building process. In addition, I propose some improvements in the current IFC specifications. One of the goals for my research was to create a basis and a wide framework for future research topics in this area. Thus, the documentation is inclusive rather than exclusive. In general the future research topics can be divided into two categories. (1) Research which expands the requirements model specification, such as the relation between high-level strategic owner requirements and detailed end-user requirements, requirements for other design domains, other parts of the process, and different building types. (2) Research which relates to the use of the requirements model, such as implementation of requirements management applications using model server technology, utilization of requirements history, automated verification of design, and semi-automated design software.
Original languageEnglish
QualificationDoctor Degree
Awarding Institution
  • Stanford University
Supervisors/Advisors
  • Fischer, Martin, Supervisor, External person
Place of PublicationEspoo
Publisher
Print ISBNs951-38-6655-6
Electronic ISBNs951-38-6656-4
Publication statusPublished - 2005
MoE publication typeG4 Doctoral dissertation (monograph)

Fingerprint

Specifications
Architectural design
Software design
User interfaces
Ontology
Software engineering
Servers
Data storage equipment

Keywords

  • buildings
  • requirements management
  • interfaces
  • client requirements
  • design tools
  • IFC specifications
  • linkage
  • production models
  • maintenance models
  • software development

Cite this

Kiviniemi, A. (2005). Requirements management interface to building product models: Dissertation. Espoo: VTT Technical Research Centre of Finland.
Kiviniemi, Arto. / Requirements management interface to building product models : Dissertation. Espoo : VTT Technical Research Centre of Finland, 2005. 347 p.
@phdthesis{9fcd6ff5ab3d498eb4e8baeea8fd5cc0,
title = "Requirements management interface to building product models: Dissertation",
abstract = "In current AEC practice client requirements are typically recorded in a building program, which, depending on the building type, covers various aspects from the overall goals, activities and spatial needs to very detailed material and condition requirements. This documentation is used as the starting point of the design process, but as the design progresses, it is usually left aside and design changes are made incrementally based on the previous design solution. As a consequence of several small changes and without any conscious decisions to change the scope, this can lead to a solution that may no longer meet the original requirements. In addition, design is by nature an iterative process and the proposed solutions often also cause evolution in the client requirements. However, the requirements documentation is usually not updated accordingly. In the worst case the changes are recorded just in the memory of the participants, and in the best case in meeting or personal notes. Finding the latest updates and evolution of the requirements from the documentation is very difficult, if not impossible. This process can lead to an end result which is significantly different from the documented client requirements. Some important client requirements may not be satisfied, and even if the design process was based on agreed-upon changes in the scope and requirements, differences in the requirements documents and in the completed building can lead to well-justified doubts about the quality of the design and construction process. My observation is that even a simple active link between the client requirements and design tools can increase the use of requirements documentation throughout the design and construction process and facilitate necessary updates of the client requirements. The key limitation is the lack of a theory to link the requirements to the design systems. A solution to the above mentioned problems can build on the following five main points of departure: (1) design as an information process, (2) existing client requirements documentation and hierarchies, (3) Lawrence Berkeley National Laboratory's Design Intent Tool for technical systems, (4) existing IFC specification and its implementation, and (5) Building Lifecycle Interoperable Software (BLIS) implementation views to the IFC specification. My research is also part of CIFE's Virtual Design and Construction (VDC) framework. Objects in the requirements model specification represent desired product form in the Product-Organization-Process (POP) ontology. I addressed the challenges by formalizing a requirements model specification which can be linked to a building-product-model-based design model of the project. My research consisted of four phases: (1) analysis of client requirements, (2) development of a requirements model specification and its links to the IFC specification, (3) extension of the BLIS view for IFC implementation, and (4) validation of the requirements model specification. Based on the requirements analysis, the number of possible requirements is high but only a few of them are used on most projects. However, the linkage of direct and indirect requirements to the design model is complicated and cannot be defined on a project by project basis only. Thus, my requirements model specification is based on an inclusive approach; all relevant requirements which were identified in my research are included in the specification, and each requirement object includes the direct and indirect links to the different levels of detail in the design model. The specification covers 300 requirements in 14 main and 35 sub-categories. It is based on a synthesis of two large, widely used requirements hierarchies, analysis of requirements in five building programs and spatial requirements in the current IFC specifications. These requirements are organized in the specification into 7 main-level and 30 sub-level requirements objects which have direct links to 5 levels of detail and 2 systems in the building product model plus indirect links to 4 levels of detail and 12 systems. The size and complexity of the specification can be managed by a good user-interface design, which is one of the proposed future research topics. The main scientific contribution of my research is this requirements model specification, based on the following main concepts: (1) division of a project's data set into four main models; requirements, design, production, and maintenance models, (2) requirements related to the different levels of details in building product models, and (3) direct and indirect requirements. Although the detailed requirements relate mainly to the architectural design, the main concepts of the specification are not domain-specific and apply to a general interface between requirements and building product models. The same link mechanism which is used between objects in the requirements and design models applies also between objects in different design and production models. My specification defines the structure of the requirements model. Its purpose is to serve as the basis for software development. For AEC professionals it is useful only if implemented into software products. Thus, the main practical implications of my work are that (1) the requirements model specification enables implementation of requirements management applications linked to building product models, and that (2) the use of such applications can improve the management of detailed client requirements in the building process. In addition, I propose some improvements in the current IFC specifications. One of the goals for my research was to create a basis and a wide framework for future research topics in this area. Thus, the documentation is inclusive rather than exclusive. In general the future research topics can be divided into two categories. (1) Research which expands the requirements model specification, such as the relation between high-level strategic owner requirements and detailed end-user requirements, requirements for other design domains, other parts of the process, and different building types. (2) Research which relates to the use of the requirements model, such as implementation of requirements management applications using model server technology, utilization of requirements history, automated verification of design, and semi-automated design software.",
keywords = "buildings, requirements management, interfaces, client requirements, design tools, IFC specifications, linkage, production models, maintenance models, software development",
author = "Arto Kiviniemi",
note = "Project code: R2SU00818",
year = "2005",
language = "English",
isbn = "951-38-6655-6",
series = "VTT Publications",
publisher = "VTT Technical Research Centre of Finland",
number = "572",
address = "Finland",
school = "Stanford University",

}

Kiviniemi, A 2005, 'Requirements management interface to building product models: Dissertation', Doctor Degree, Stanford University, Espoo.

Requirements management interface to building product models : Dissertation. / Kiviniemi, Arto.

Espoo : VTT Technical Research Centre of Finland, 2005. 347 p.

Research output: ThesisDissertationMonograph

TY - THES

T1 - Requirements management interface to building product models

T2 - Dissertation

AU - Kiviniemi, Arto

N1 - Project code: R2SU00818

PY - 2005

Y1 - 2005

N2 - In current AEC practice client requirements are typically recorded in a building program, which, depending on the building type, covers various aspects from the overall goals, activities and spatial needs to very detailed material and condition requirements. This documentation is used as the starting point of the design process, but as the design progresses, it is usually left aside and design changes are made incrementally based on the previous design solution. As a consequence of several small changes and without any conscious decisions to change the scope, this can lead to a solution that may no longer meet the original requirements. In addition, design is by nature an iterative process and the proposed solutions often also cause evolution in the client requirements. However, the requirements documentation is usually not updated accordingly. In the worst case the changes are recorded just in the memory of the participants, and in the best case in meeting or personal notes. Finding the latest updates and evolution of the requirements from the documentation is very difficult, if not impossible. This process can lead to an end result which is significantly different from the documented client requirements. Some important client requirements may not be satisfied, and even if the design process was based on agreed-upon changes in the scope and requirements, differences in the requirements documents and in the completed building can lead to well-justified doubts about the quality of the design and construction process. My observation is that even a simple active link between the client requirements and design tools can increase the use of requirements documentation throughout the design and construction process and facilitate necessary updates of the client requirements. The key limitation is the lack of a theory to link the requirements to the design systems. A solution to the above mentioned problems can build on the following five main points of departure: (1) design as an information process, (2) existing client requirements documentation and hierarchies, (3) Lawrence Berkeley National Laboratory's Design Intent Tool for technical systems, (4) existing IFC specification and its implementation, and (5) Building Lifecycle Interoperable Software (BLIS) implementation views to the IFC specification. My research is also part of CIFE's Virtual Design and Construction (VDC) framework. Objects in the requirements model specification represent desired product form in the Product-Organization-Process (POP) ontology. I addressed the challenges by formalizing a requirements model specification which can be linked to a building-product-model-based design model of the project. My research consisted of four phases: (1) analysis of client requirements, (2) development of a requirements model specification and its links to the IFC specification, (3) extension of the BLIS view for IFC implementation, and (4) validation of the requirements model specification. Based on the requirements analysis, the number of possible requirements is high but only a few of them are used on most projects. However, the linkage of direct and indirect requirements to the design model is complicated and cannot be defined on a project by project basis only. Thus, my requirements model specification is based on an inclusive approach; all relevant requirements which were identified in my research are included in the specification, and each requirement object includes the direct and indirect links to the different levels of detail in the design model. The specification covers 300 requirements in 14 main and 35 sub-categories. It is based on a synthesis of two large, widely used requirements hierarchies, analysis of requirements in five building programs and spatial requirements in the current IFC specifications. These requirements are organized in the specification into 7 main-level and 30 sub-level requirements objects which have direct links to 5 levels of detail and 2 systems in the building product model plus indirect links to 4 levels of detail and 12 systems. The size and complexity of the specification can be managed by a good user-interface design, which is one of the proposed future research topics. The main scientific contribution of my research is this requirements model specification, based on the following main concepts: (1) division of a project's data set into four main models; requirements, design, production, and maintenance models, (2) requirements related to the different levels of details in building product models, and (3) direct and indirect requirements. Although the detailed requirements relate mainly to the architectural design, the main concepts of the specification are not domain-specific and apply to a general interface between requirements and building product models. The same link mechanism which is used between objects in the requirements and design models applies also between objects in different design and production models. My specification defines the structure of the requirements model. Its purpose is to serve as the basis for software development. For AEC professionals it is useful only if implemented into software products. Thus, the main practical implications of my work are that (1) the requirements model specification enables implementation of requirements management applications linked to building product models, and that (2) the use of such applications can improve the management of detailed client requirements in the building process. In addition, I propose some improvements in the current IFC specifications. One of the goals for my research was to create a basis and a wide framework for future research topics in this area. Thus, the documentation is inclusive rather than exclusive. In general the future research topics can be divided into two categories. (1) Research which expands the requirements model specification, such as the relation between high-level strategic owner requirements and detailed end-user requirements, requirements for other design domains, other parts of the process, and different building types. (2) Research which relates to the use of the requirements model, such as implementation of requirements management applications using model server technology, utilization of requirements history, automated verification of design, and semi-automated design software.

AB - In current AEC practice client requirements are typically recorded in a building program, which, depending on the building type, covers various aspects from the overall goals, activities and spatial needs to very detailed material and condition requirements. This documentation is used as the starting point of the design process, but as the design progresses, it is usually left aside and design changes are made incrementally based on the previous design solution. As a consequence of several small changes and without any conscious decisions to change the scope, this can lead to a solution that may no longer meet the original requirements. In addition, design is by nature an iterative process and the proposed solutions often also cause evolution in the client requirements. However, the requirements documentation is usually not updated accordingly. In the worst case the changes are recorded just in the memory of the participants, and in the best case in meeting or personal notes. Finding the latest updates and evolution of the requirements from the documentation is very difficult, if not impossible. This process can lead to an end result which is significantly different from the documented client requirements. Some important client requirements may not be satisfied, and even if the design process was based on agreed-upon changes in the scope and requirements, differences in the requirements documents and in the completed building can lead to well-justified doubts about the quality of the design and construction process. My observation is that even a simple active link between the client requirements and design tools can increase the use of requirements documentation throughout the design and construction process and facilitate necessary updates of the client requirements. The key limitation is the lack of a theory to link the requirements to the design systems. A solution to the above mentioned problems can build on the following five main points of departure: (1) design as an information process, (2) existing client requirements documentation and hierarchies, (3) Lawrence Berkeley National Laboratory's Design Intent Tool for technical systems, (4) existing IFC specification and its implementation, and (5) Building Lifecycle Interoperable Software (BLIS) implementation views to the IFC specification. My research is also part of CIFE's Virtual Design and Construction (VDC) framework. Objects in the requirements model specification represent desired product form in the Product-Organization-Process (POP) ontology. I addressed the challenges by formalizing a requirements model specification which can be linked to a building-product-model-based design model of the project. My research consisted of four phases: (1) analysis of client requirements, (2) development of a requirements model specification and its links to the IFC specification, (3) extension of the BLIS view for IFC implementation, and (4) validation of the requirements model specification. Based on the requirements analysis, the number of possible requirements is high but only a few of them are used on most projects. However, the linkage of direct and indirect requirements to the design model is complicated and cannot be defined on a project by project basis only. Thus, my requirements model specification is based on an inclusive approach; all relevant requirements which were identified in my research are included in the specification, and each requirement object includes the direct and indirect links to the different levels of detail in the design model. The specification covers 300 requirements in 14 main and 35 sub-categories. It is based on a synthesis of two large, widely used requirements hierarchies, analysis of requirements in five building programs and spatial requirements in the current IFC specifications. These requirements are organized in the specification into 7 main-level and 30 sub-level requirements objects which have direct links to 5 levels of detail and 2 systems in the building product model plus indirect links to 4 levels of detail and 12 systems. The size and complexity of the specification can be managed by a good user-interface design, which is one of the proposed future research topics. The main scientific contribution of my research is this requirements model specification, based on the following main concepts: (1) division of a project's data set into four main models; requirements, design, production, and maintenance models, (2) requirements related to the different levels of details in building product models, and (3) direct and indirect requirements. Although the detailed requirements relate mainly to the architectural design, the main concepts of the specification are not domain-specific and apply to a general interface between requirements and building product models. The same link mechanism which is used between objects in the requirements and design models applies also between objects in different design and production models. My specification defines the structure of the requirements model. Its purpose is to serve as the basis for software development. For AEC professionals it is useful only if implemented into software products. Thus, the main practical implications of my work are that (1) the requirements model specification enables implementation of requirements management applications linked to building product models, and that (2) the use of such applications can improve the management of detailed client requirements in the building process. In addition, I propose some improvements in the current IFC specifications. One of the goals for my research was to create a basis and a wide framework for future research topics in this area. Thus, the documentation is inclusive rather than exclusive. In general the future research topics can be divided into two categories. (1) Research which expands the requirements model specification, such as the relation between high-level strategic owner requirements and detailed end-user requirements, requirements for other design domains, other parts of the process, and different building types. (2) Research which relates to the use of the requirements model, such as implementation of requirements management applications using model server technology, utilization of requirements history, automated verification of design, and semi-automated design software.

KW - buildings

KW - requirements management

KW - interfaces

KW - client requirements

KW - design tools

KW - IFC specifications

KW - linkage

KW - production models

KW - maintenance models

KW - software development

M3 - Dissertation

SN - 951-38-6655-6

T3 - VTT Publications

PB - VTT Technical Research Centre of Finland

CY - Espoo

ER -

Kiviniemi A. Requirements management interface to building product models: Dissertation. Espoo: VTT Technical Research Centre of Finland, 2005. 347 p.