Principles for writing functional statements in objective ...

1 Principles for writing functional statements in objective -based codes Bergeron, D. NRCC-45134. A version of this paper is published in / Une version de ce document se trouve dans : Task Group on Drafting of objective -Based Codes, 2001, pp. 1-14. Canadian Commission on Building and fire Codes National Research Council Canada Committee Paper on Principles for writing functional statements in objective -Based Codes prepared for the Task Group on Drafting of objective -Based Codes by Denis Bergeron This document is a working paper prepared for consideration by task groups and committees of the Canadian Commission on Building and fire Codes. The views expressed in this paper are those of the author and do not represent those of the Canadian Commission on Building and fire Codes or of the Institute for Research in Construction.

2 This paper is not a formal publication of the National Research Council of Canada. July 2001. CCBFC/CCC Committee paper No. 09/12/01 1. Development of Principles for writing functional statements in objective Based Codes functional statements - prototype Background - Principles A main mandate of the Task Group is to recommend the most appropriate way of writing functional statements so they are clear, useful and form a coherent group of statements . In developing the NBC prototype (agenda of the first meeting of the Task Group), a few Principles have already been established regarding the nature and role of the functional statements . These Principles are listed below and should govern the further development of the functional statements : - functional statements are not stand alone requirements that can be used directly to design a building.

3 They are a link between objectives and acceptable solutions and shall always be read in the context of the objectives and acceptable solutions they are associated with. They will also serve to guide the introduction of performance criteria if a performance path is developed in the future. - functional statements are an expression of the functions and roles to be fulfilled by the building and its components. They describe the various ways the code through the acceptable solutions - controls the design and construction of buildings to achieve the objectives of the code. They are more specific than the objectives as they capture all the technical aspects addressed in the acceptable solutions. They are however more generic than the individual requirements in the acceptable solutions because they serve as umbrella statements grouping under the same statements all acceptable solutions requiring the same functions from the building and its components.

4 - functional statements shall not overlap with information already provided in the objectives they are associated with. This is why they shall not state the negative consequences of not complying with the code such as harm or injury to persons, damage to buildings, etc. since this is the role of the objectives. The functional statements shall focus on what is expected from the building and its components in order to prevent these negative consequences. - functional statements shall not be application specific since they are not attempting to capture all the application limitations and exceptions 09/12/01 2. of the acceptable solutions. Broad application limitations for functional statements are listed in Article of Division A in the prototype discussed at first meeting of the Task Group.

5 The acceptable solutions establish the more detailed application of the functional statements . In a future performance path, this role would be played by the performance criteria. TG 1st meeting discussion The NBC prototype discussed at the first meeting of the Task Group contained several functional statements in Table of Division A. These statements have been written at the early stage of development of the prototype for the sole purpose of checking the viability of the prototype. Not much thought had been given to the style, structure and language of these statements . At the first meeting, the Task Group reviewed public comments received during the consultation on objectives and the structure of objective -based codes.

6 The Task Group retained some of these comments and made a number of observations and recommendations to explore possible ways of writing these statements . - It has been suggested that the term functional requirement in the prototype be replaced with functional statement to avoid confusion with the requirements in the acceptable solutions. The use of functional requirement also seems to create a risk of misperception that one can design a building based only on the objectives and functional requirements in Division A of the prototype. The use of functional statement should help clarify this misinterpretation. - Some functional statements used in the prototype are too absolute. functional Statement R4 was given as an example: A fire shall not spread beyond its point of origin.

7 The use of qualifiers such as the words reasonable, sufficient, excessive or limit, minimize, etc. should be considered for statements that would otherwise be too absolute. - Some functional statements used in the prototype are too open-ended. functional Statement R5 was given as an example: Occupants shall be informed that a fire /emergency situation is occurring. Question asked: Informed by when? . - The affirmative should be used whenever possible ( shall do - allow - something ) as opposed to the negative ( shall not do not allow - something ). - functional statements should be written so that the subject is the building and its components. For example, above statements R4 and R5 from the prototype do not clearly reflect that the code is controlling the design and construction of buildings.

8 statements R4 and R5 rather suggest that the code is managing fire and occupants, which is not incorrect but would be a different approach to developing functional statements . 09/12/01 3. functional statements examples from NBC 1995. It was also noted that several existing requirements in the NBC 1995 use an objective - based language and do describe the expected functions of building components. It was suggested that examples of such requirements be compiled and be examined as a possible starting point in developing Principles for writing functional statements . The following table is a compilation of such examples: they are grouped under each of the 11 functional statements of the prototype for which we have found related requirements expressed in an objective -based language in the NBC 1995.

9 Action required from TG members: Task Group members are invited to comment on the adequacy or inadequacy as functional statements of both the original statements and the related examples from the NBC which are listed in the table after each of the 11 statements retained for our review. We would like to draw your attention to the absolute nature and the open- endedness of many of these examples from the NBC 1995 and also to the frequent use of the verb prevent. You are invited to identify the strengths and weaknesses of these statements and requirements and to suggest how they could be revised to become acceptable functional statements , keeping in mind the Principles listed in the Introduction at the beginning of this paper, more specifically that functional requirements: 1.

10 Are not stand alone statements : they are a link between objectives and acceptable solutions, 2. shall not overlap with information provided in the objectives they are associated with, and 3. shall not be application specific. Table of functional statements from the prototype with examples functional statements prototype + examples Combustible or explosive materials shall not be present in Combustible R1. quantities or manner that could result in an uncontrollable fire or and Explosive an explosion. Materials 4. and Storage Garages 5. 4) A garage shall be provided with natural or mechanical ventilation . to prevent excessive accumulation of carbon monoxide, exhaust fumes or flammable and toxic vapours 6. on Fill 09/12/01 4.