2005

Kiviniemi, Arto

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 requir