Requirements management interface to building product models: Dissertation

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.