Models and IT support for Requirements Processing

The client requirements processing model (CRPM) was developed to help in the definition of client requirements and the incorporation of the different perspectives represented by the client body, and assist in the systematic mapping or translation of the requirements from the business terminology (“voice of the client”) that clients are likely to use into design terms (“voice of the designer”). Its aim is also to ensure requirements are presented in a solution-neutral format (Kamara et al., 2002). Kamara and Anumba (2000)

59 argue that “it is necessary that ‘processing’ be done before conceptual design.”

CRPM has three main stages for the processing of requirements:

defining client requirements, analysing client requirements and translating client requirements.

Defining client requirements deals with the elicitation and capturing of the requirements and the identification of interested stakeholders. Analysing these requirements makes sure that requirements are structured and prioritised according to their relative importance. The last stage, translation of the requirements deals with the transformation of clients requirements into design attributes. During all these stages, managing the elicited requirements is of great importance. However it is apparent that the CRPM only feeds into the design phase of a construction project but doesn’t apply throughout the lifecycle phases of a project. The diagram in Figure 3.1 shows the graphical design of the different stages of CRPM with all of the information necessary for processing the requirements.

Figure 3.1: Client Requirements Processing Model (CRPM) Source: (Kamara et al., 2002)

60 The CRPM helps capture client requirements and facilitates design development. It serves as a link between project conception and design. In other words, “CRPM serves as the interface between the client’s business needs and design requirements” (Kamara et al., 2002). Design solutions are subsequently used to facilitate the construction of the facility as well as to aid material procurement process. The original requirements documents become redundant in the later phases of a construction project having been substituted by the schematic and detailed design. However, this research argues that requirements management process should be continued throughout the phases of a construction project and building life, and not just to aid design. Figure 3.2 shows the CRPM link between conceiving a project and the design highlighting where the model is applied.

Figure 3.2: Context for the implementation of the CRPM Source: (Kamara et al., 2002)

Managing requirements along all phases of a construction project does not only help different teams perform their work efficiently but can contribute to elimination of waste in design and construction. This is achieved because design re-works and construction defects are reduced immensely with lifecycle requirements information management. Similar observation was made by Baldwin et al., (2007), that waste can be eliminated in both design

61 and construction process by ensuring the timely delivery of design information and process and information modelling can facilitate that process.

Kamara et al. (2000) identify that different media such as drawings, sketches, text and other forms have been used to manage and communicate requirements. This has been emphasised by Fiksel and Dunkle (1992), who point out that “there are a variety of forms in which requirements can be represented, including documents and drawings.” Computational tools have emerged that help to manage the different media. Most of these applications are general computer applications such as word processors, spreadsheets and databases in some cases. There are many disadvantages associated with such applications, and there is a recognised need for more advanced tools. Ozkaya and Akin (2007) state that “computational requirements management and engineering strategies need to evolve, along with algorithms to manipulate requirements for architectural design as well.” To address this problem, the Computational Hybrid Assistance for Requirements Management (CHARM) framework was developed. CHARM establishes a process whereby a designer/architect needs to be aware of the requirements information of a given solution, or track emerging data by interacting with the computational system. Figure 3.3 shows a graphical representation of CHARM.

Figure 3.3:Computational Hybrid Assistance for Requirement Management process components

Source: (Ozkaya and Akin, 2007)

Kiviniemi et al. (2004) and Kiviniemi (2005) working on requirements management present a framework focusing on the requirements model and its interconnection to the architectural design model by creating a link between requirements Objects in the Requirements Model and objects in Design,

62 Production, and Maintenance Models. This is another improvement in requirements management in the construction industry and the concept would be useful to industry.

These links are relevant for traceability purposes, however, this research argues that the links should be categorised to help define the degree of the dependency or relationship of one requirement to another. Consequently, this research adopts the philosophy of these links as a point of departure to facilitate defining categories of the links and how they can be applied across the lifecycle phases. This research also extends the capabilities and utilisation of the links to enhance the checking for dependencies between requirements during changes which is crucial for impact analysis.

Meziane and Rezgui (2004) present a document management methodology for the management and sharing of documents in the construction domain. It aims to facilitate the identification of documents and management of the updating process of those documents, and to deal with heterogeneous and large database of documents.

All these different models and frameworks discussed have the potential to facilitate the requirement management processes within the construction industry. However, the extent to which this is done is limited compared to the need for a lifecycle requirements management support for construction projects.

Many commercial software tools exist that claim to be able to provide requirements management. According to Oduguwa (2006), the three industry leaders are recognised as DOORS from Telelogic, Slate (part of Teamcenter) now owned by Siemens (Siemens, 2011) and Calibre-RM from Borland which provide common support for requirements management but they are not able to provide detailed impact analysis when a design requirement is changed.

Halbleib (2004) and Kamara et al. (2002) also identify similar commercial requirements management tools. An evaluation of some commercial requirements management tools was also made in Tvete (1999) to enable

63 selection of one to be used for their purpose. These software tools are generic and have been developed for use across different industry sectors. However, none have become adopted as standard for the construction industry.

Other systems were developed as research outputs notably, EGRET, developed by Sinha et al. (2006), is a collaborative requirements management tool aimed at supporting the requirements communication and management across distributed software development teams. This was specific to the software industry and no focus in construction. However, the concept addresses similar problems to those of the AEC/FM industry. It is crucial that in order to support and enable multidisciplinary teams to work collaboratively, requirements must be processed and presented in a format that will facilitate that process (Kamara et al., 2002).