- Email: [email protected]
A case-based reasoning system for using functional performance specification in the briefing of building projects
Automation in Construction 19 (2010) 725–733
Contents lists available at ScienceDirect
Automation in Construction j o u r n a l h o m e p a g e : w w w. e l s ev i e r. c o m / l o c a t e / a u t c o n
A case-based reasoning system for using functional performance specification in the briefing of building projects Xiaochun Luo, Geoffrey Qiping Shen ⁎, Shichao Fan Department of Building and Real Estate, The Hong Kong Polytechnic University, Hong Kong
a r t i c l e
i n f o
Article history: Accepted 26 February 2010 Keywords: Case-based reasoning Functional performance specification Value management Briefing Building projects
a b s t r a c t Functional Performance Specification (FPS) is a structured requirement analysis process, in which client requirements are firstly defined with functions and relevant evaluation criteria — functional performance. This paper describes a Case-Based Reasoning (CBR) system recommending functions and functional performance to facilitate the use of FPS in the briefing of building projects. It begins with an introduction to the briefing practice and the problems of using FPS in briefing, followed by proposing a structural job plan of FPS. Next, the CBR system design is described and how it supports the use of FPS is illustrated. Finally, the competence of the system is evaluated with two experiments, which demonstrate that the CBR system is a highly promising tool for facilitating the use of FPS. The future research work concerning addressing the shortcomings of the CBR system identified in the experiments is also noted. Crown Copyright © 2010 Published by Elsevier B.V. All rights reserved.
1. Introduction
2. Functional Performance Specification (FPS) for briefing
Case-Based Reasoning (CBR) utilizes the specific knowledge of previously experienced, concrete problem situations (cases), thus a new problem is solved by finding a similar past case, and reusing it in a new problem situation [1]. CBR has been widely applied to a variety of tasks. Concerning applications in the A/E/C industry, we can cite construction negotiation [2], wall selection [3], bid decision making [4], construction safety planning [5], procurement selection [6], construction planning [7,8], bid mark-up estimation [9], subcontractor registration decisions [10], value engineering [11], and construction hazard identification [12]. Due to the success of CBR in suggesting solutions based on similar situations, the study described in this paper aims to introduce CBR to support the use of Functional Performance Specification (FPS) in the briefing process of building projects. The strategy we take is to design a CBR system that retrieves similar cases (textural functions representing client requirements in the form of ‘verb + noun’ enable semantic search) responding to the new event (keywords related to requirements that the user concerns), and then recommends solutions (relevant functions and their functional performance) to the selected returned cases. The paper begins with an introduction to the briefing, followed by the discussion of the problems encountered in using FPS in it. After that, a structural job plan of FPS is proposed. Next, the design of the CBR system is detailed, including how it supports the use of FPS in the briefing. Finally, we evaluate the competence of the system within two experiments.
Briefing (also known as ‘architectural programming’ in the US) is a process through which a client informs others of his/her needs, aspirations, and desires for a project [13]. A brief is the document that defines client requirements for a building. Defining the requirements and communicating them to other stakeholders are crucial to the successful delivery of a project [14,15]. With consideration of the critical influence of briefing on the whole building delivery process, Value Management (VM) exercises are expected to be conducted at the earlier stages [16–21]. In Hong Kong, the Environment, Transport and Works Bureau requires major projects (those with an estimated project cost exceeding HK$ 200 million) in the subordinate departments to conduct VM studies [22]. The Construction Industry Review Committee also recommended that VM should be used more widely in local construction, because it can help the clients and the project team to focus on the objectives of the project and the needs of all stakeholders, both long and short term [23].
⁎ Corresponding author. E-mail address: [email protected] (G.Q. Shen).
2.1. Value management VM is concerned with defining what ‘value’ means to a client within a particular context by bring the project stakeholders together and producing a clear statement of the project's objectives [16]. An essential feature of the VM approach is expressing client requirements as functions. In terms of VM, a function is referred to as the specific purpose or intended use of a project that makes the project sell, produce revenue or meet requirements. Function analysis is one of the key components of VM methodology, which distinguishes VM from other cost reduction activities [23]. Charles Bytheway developed a concept and named it FAST (Function Analysis
0926-5805/$ – see front matter. Crown Copyright © 2010 Published by Elsevier B.V. All rights reserved. doi:10.1016/j.autcon.2010.02.017
726
X. Luo et al. / Automation in Construction 19 (2010) 725–733
Fig. 1. Structure of FPS (adapted from [34]).
System Technique), which utilizes ‘why-how’ logic to address the difficulty of getting agreement on the basic function of an assembly or component [24]. Bytheway succinctly summarizes the ‘why-how’ logic and features of the FAST in the following statement: ‘the result of writing down the functions as they relate to each other generated a visual diagram which showed how each function is performed by merely observing the functions posted immediately to the right of any given function. By the same token, if one desired to know why a given function is required, the function posted at its immediate left provided the answer [25]’. Job plan is another key component of VM methodology [23]. It is a structured process which has a definite beginning and a definite end. A good job plan lays down the procedure of a VM workshop explicitly. A successful attempt in the functional representation of client requirements is the Charette job plan, which rationalizes client briefs primarily through the function analysis of space requirements. Shen et al. [20] contended that it should be broadened to include other issues of client requirements and to communicate them clearly to the designers. 2.2. Functional Performance Specification (FPS) As one of VM techniques, FPS was originally developed in French manufacturing, and was used in Europe as a system for the explicit
statement of optimum product definition for a given market within a tool for conception and design management [26]. Currently, the application of FPS is primarily in the two realms of software engineering [27–30] and manufacturing industry [26,31,32]. FPS represents requirements in terms of functions in the form of ‘verb + noun’, functional performance criteria, and flexibilities of these criteria indicating which of them are imperative (with a certain tolerance) and which are desired but open to negotiation. The structure of briefs achieved by conducting FPS is shown in Fig. 1. Shen et al. introduce FPS to the construction industry and developed a structured framework for identifying and representing client requirements in briefing [19]. In the context of a briefing team of multidisciplinary stakeholders, where the focus, perspective, orientation, knowledge, and expertise of the stakeholders are often quite diverse, there is a strong need to have a common language to present client requirements. As a performance-based approach thinking and working in terms of ends rather than means [33], FPS constructs a design-neutral way allowing all team members to communicate more effectively. To further prompt and validate the framework by Shen et al., a computer-aided tool FPS Genius was developed by Luo and Shen [34]. However, during the course of applying the computer-aided tool in practice, it has become apparent that to efficiently and accurately define functions and their performance in the function analysis phase with a fixed and short duration is a big challenge.
3. CBR for FPS CBR is useful in interpreting open-ended and ill-defined concepts; in other words, CBR allows a reasoner to propose solutions in domains that are not completely understood by the reasoner [35]. With respect to the uniqueness and complexity of building projects, it is feasible and practical to introduce CBR to address the problems encountered in using FPS in briefing. Unique cases defined in the briefs of previous analogous building projects could and should be reused. With the recommendations by CBR, those normal inexperienced clients are expected to understand their projects and clarify their requirements more easily. To combine CBR with the FPS practice, we adapt the job plan in [19] and propose a new one with five phases (see Fig. 2): 1) preparation phase to organize the briefing team and define the briefing workshop, 2) information phase to establish a shared understanding of the project among all participants,
Fig. 2. Job plan for using FPS in briefing.
X. Luo et al. / Automation in Construction 19 (2010) 725–733
727
3) function analysis phase to identify client requirements in functional terms and develop these functions into a task functional diagram using the why-how logic, 4) performance specification phase to identify functional performance and assign flexibility to each performance item, and 5) evaluation phase to generate and assess the brief and to agree ways to evaluate whether the requirements in the brief are met at the end of the project. The CBR system is designed to work through recommending functions and related functional performance. Thus, it will be used in function analysis phase and performance specification phase of the proposed job plan.
4. System design Fig. 3. View of a typical case.
Core problems addressed by CBR research and development can be grouped into four areas: representing cases, indexing cases, retrieving cases, adapting cases [1]. Considering the simple nature of solutions (i.e. textural expressions of functions and functional performance),
Fig. 4. Part of the ontology for case indexing.
728
X. Luo et al. / Automation in Construction 19 (2010) 725–733
we use a null adaptation [36] strategy in our system that means no adaptation.
Table 1 Development and use environments of the CBR system. Item
Development environment
4.1. Representing cases Hardware
A case is a contextualized piece of knowledge representing an experience [1]. Typically, a case is composed of two elements [35]: the problem that describes the state of the world when the case occurred and the solution that states the derived solution to that problem. In our system design, the problem is defined with two entities: (1) a function that representing a piece of client requirements and (2) the building type, for which the function is defined. The solution is the recommendations pertinent to the function and the building type; it consists of two categories: (1) recommended functions answering question ‘why’, ‘how’ and functions similar with the function of the case, and (2) recommended functional performance. Fig.3. shows the view of a typical case. 4.2. Indexing cases Case indexing involves assigning indices to cases to facilitate their retrieval [1]. The indexing problem has several parts. First is the problem of assigning labels to cases at the time that they are entered into the case base to ensure that they can be retrieved at the appropriate time. Second is the problem of organizing cases so that searches through the case base can be done efficiently and accurately [35]. We adopt the similarity and explanation-based generalisation method that produces an appropriate set of indices for abstract cases created from cases that share some common set of features, whilst the unshared features are used as indices to the original cases [1]. We construct an ontology, which is a ‘formal, explicit specification of a shared conceptualisation’ [37], to implement the similarity and explanation-based generalization. As one of the most influential and comprehensive information matrices, the information index matrix by Pena and Parshall is adapted and adopted to build the ontology. The solution proposed utilizes the ‘goals’ and ‘concepts’ columns in [38] to construct the briefing domain ontology, in which ‘goals’ means what the client want to achieve, and why; whilst ‘concepts’ means how the client achieve the ‘goals’. In each column, four considerations, i.e. function, form, economy and time, are taken. Thus, the final
Intel Pentium 4 CPU 2.80 GHz, 1.50 GB of RAM Software Microsoft Windows XP Version support 2002 Service Pack 2, Microsoft . NET Framework 2.0, Microsoft Office 2003 Access IDE Microsoft Visual Studio 2005 EN Programming C# language
Use environment (minimum requirements) CPU 1.0 GHz, 512 MB of RAM Microsoft Windows XP Version 2002 Service Pack 2, Microsoft . NET Framework 2.0, Microsoft Office 2003 Access
ontology enables us to categorize cases into eight general groups: goal-function, goal-form, goal-economy, goal-time, concept-function, concept-form, concept-economy, and concept-time. Considering the practical target of the CBR system, the ontology is organized into a tree view (see Fig. 4), which is similar with the hierarchical structure of FPS. As shown in the figure, two relationships among entities are created: abstract-concrete and motivation-action. These entities are ‘abstract cases created from cases that share some common set of features’. The two relationships essentially follow the ‘why-how’ logic; the abstract/motivation entities answer the question ‘why’ and the concrete/action entities answer the question ‘how’. In the example shown in Fig. 4: 1) the abstract entity ‘physical comfort’ is implemented by concrete entities ‘aural comfort’, ‘visual comfort’, and ‘thermal comfort’; 2) the abstract entity ‘environment controls’ is carried out through concrete entities ‘noise control’, ‘ventilation’, and ‘adequate lighting’; and 3) the action entity ‘environmental controls’ serves motivation entity ‘physical comfort’.
4.3. Retrieving cases Retrieving a case starts with a problem description, and ends when a best matching previous case has been found. Its subtasks are referred to as identifying features, initially matching, searching, and
Fig. 5. Four types of approaches to retrieving cases.
X. Luo et al. / Automation in Construction 19 (2010) 725–733
729
selecting, executed in that order [39]. We implement the process as follows:
5) computing similarity of the sentences: computing the similarity of the sentences based on the similarity of the pairs of words.
1) the user identifies features, i.e. keywords related to his/her requirements; 2) the CBR system semantically searches functions in the case base with keywords; 3) the user selects the functions he/she is interested in; finally 4) the CBR system retrieves the solutions to the problem pertinent to the selected function in step 3.
The case retrieval step 4 is implemented through the abstractconcrete and motivation-action relations. The abstract-concrete relation allows us to find out the similar functions of the selected function in step 3; it tries to identify the ‘siblings’ of the function as its similar functions. The motivation-action relation is employed to retrieve functions answering ‘why’ and/or ‘how’ from the causal perspective. As a result, four types of case retrieval approaches can be built as follows (see Fig. 5): functions answering ‘why’, similar functions, functions answering ‘how’, and functional performance.
The following contents are engaged to describe the implementations of steps 2 and 4. We borrow the semantic search engine reported in [40] to fulfil case retrieval 2. The engine enables us to measure semantic similarity between functions stored in the case base and keywords input by the user. Although, the project only concerns work with ‘noun-noun’, and ‘verb–verb’ parts of speech, it is believed adequate for the current CBR system since functions are primarily defined in the form of ‘verb + noun’. There are five steps in the algorithm to calculate semantic similarity between two sentences: 1) tokenization: partitioning each sentence into a list of tokens; 2) tagging part of speech: identifying the correct part of speech of each word in the sentence; 3) stemming words: removing the common morphological and inflexional endings of words; 4) word sense disambiguation: finding the most appropriate sense for every word in a sentence;
5. Using the CBR system in briefing The CBR system is implemented on Microsoft Windows XP with Microsoft .NET Framework 2.0. The case base is accommodated in Microsoft Office 2003 Access considering the flexibility and the cost of the system deployment and configuration. The integrated development environment (IDE) is Microsoft Visual Studio 2005 EN. Table 1 describes the development and use environments of the CBR system. 5.1. Authoring cases A case base administrator is implemented to author cases for the CBR system. The user of the case base administrator is expected to be a knowledge engineer who is responsible for retaining new cases, updating existing cases, and deleting inadequate cases. A snapshot of
Fig. 6. Interface of the case base administrator.
730
X. Luo et al. / Automation in Construction 19 (2010) 725–733
the main interface of the case base administrator is shown in Fig. 6, in which six feature areas are designed including indexing tree, address of cases, existing functions, existing function performance, new functions, and new functional performance. After adding a new entity into the indexing tree or simply selecting an existing node (entity) in the indexing tree, the address of cases can be located. The hierarchy of the indexing tree is established based on the ‘abstract-concrete’ relation. When an existing node is selected, the existing functions and functional performance attached to it, if any, are shown promptly in relevant feature areas. After defining the new cases, the next step is to establish the ‘motivation-action’ relation between the newly added entities. The interface for establishing case relations is shown in Fig. 7, in which four feature areas are designed: client path, service path, existing relations, and new relations. Client paths represent addresses of motivation entities and service paths reflect addresses of action entities. When a path is identified, client or service, the existing relations with it will be shown in the existing relations area. The case base administrator can also use it to manage the existing entity relations. 5.2. Recommending solutions The case-based reasoner is the key component in the CBR system to generate recommendations according to inputs by the user. A snapshot of the interface of the case-based reasoner is shown in Fig. 8. There are six feature areas in the interface: searching area, results found, functions answering ‘why’, similar functions, functions answering ‘how’, and functional performance. The searching area consists of keywords of function, building type, and semantic similarity. The case-based reasoner semantically searches the case base with building type and semantic similarity as filtering
conditions. Here, semantic similarity is a threshold controlling the minimum semantic similarity between the keywords input and the functions stored in the case-base. Only those functions with bigger semantic similarity than the threshold will be returned. Selecting any retrieved function will trigger case retrieval process. That is, the related functions and functional performance to the selected function will be shown in the relevant areas. As an example, Table 2 shows the solution generated by the CBR system to function ‘ensure aural comfort’. 6. System performance evaluation In the following section, we evaluate the system competence with respect to three performance criteria: case base coverage, percentage of problem solving successes, and performance of recommendations. The first criterion is used to measure the competence of the case base and the last two are employed to evaluate the utility of the CBR system. 6.1. Case base coverage We borrow the matrixes of case base coverage proposed by Smyth and McKenna [41] as one of the criteria to measuring the competence of our system. Since there are some subtle yet different interpretations of the elements consisting of the measuring model considering the characteristics of our CBR system, we give our adapted definitions as follows: Case density: the density of cases is defined and used to evaluate the individual competence contribution of a single case in a case group. A case within a dense collection is believed to have lower competence contribution than one within a sparse group; dense groups contain greater redundancy than sparse groups [41]. The local density of a case c within a case group G is formulated as Eq. (1), where Sim(c, c′) is the semantic similarity between the entities, to which the case c and the case c′
Fig. 7. Interface of establishing motivation-action relations.
X. Luo et al. / Automation in Construction 19 (2010) 725–733
731
Fig. 8. Interface of the case based reasoner.
attached, and |G| is the number of cases in group G. If there is only one case in a case group, the local density of the case is set as 1. ∑
CaseDensityðc; GÞ =
c0 ∈G−fcg
Sim c; c′ ð1Þ
jGj−1
Table 3 Case sources.
Table 2 An example: the proposed solution to ‘ensure aural comfort’. Suggestions Functions answering ‘why’ Alternative/Similar functions Functions answering ‘how’ Functional performance
Competence groups and group coverage: a collection of related cases that share coverage constitute a competence group [41]. In this research, we identified 74 competence groups resided in the case base; they are the entities consist of the information matrix. In this sense, group density is defined as the average case density of the group (see Eq. (2)) and group coverage is formulated as Eq. (3)
Year Relations
Create physical comfort
Abstraction
1. Ensure thermal comfort 2. Ensure visual comfort 1. Reduce noise 2. Minimize noise 1. Room acoustics with limited background noise and suitable reverberation time should be designed for speech intelligibility 2. Distance between teachers and students should be minimized as much as practical 3. Sound absorption surfaces to reduce reverberation are best to be located at edges and the end wall of the classroom to achieve a balance between sound reflection and absorption and to avoid reflecting echo 4. Sound-absorbing materials are used to minimize noise
Abstraction Abstraction Causal Causal Abstraction
Abstraction
Abstraction
Causal
Title
2008 DQI briefing tool user guide, version 1.0 2004 21st century libraries: changing forms, changing futures. 2005 Picturing school design: a visual guide to secondary school buildings and their surroundings using the design quality indicator for schools 2006 Better places to work 2007 Guidance on tall buildings 2008 Building for life: delivering great places to live 2008 Building for life: evaluating housing proposals step by step 2009 Good design: the fundamentals 2005 Standard classification for serviceability of an office facility for support for office work 2005 Standard classification for serviceability of an office facility for meetings and group effectiveness 2005 Standard classification for serviceability of an office facility for layout and building factors 2005 Standard classification for serviceability of an office facility for location, access and wayfinding
Author CIC CABE CABE
CABE CABE CABE CABE CABE ASTM ASTM ASTM ASTM
CIC: the Construction Industry Council, http://www.dqi.org.uk/. CABE: Commission for Architecture and the Built Environment, http://www.cabe.org.uk/. ASTM: ASTM International, http://www.astm.org/.
732
X. Luo et al. / Automation in Construction 19 (2010) 725–733
Table 4 Case base coverage. General group
Count of competence groups (a)
Count of cases (b)
Group coverage (c)
Average group coverage (c/a)
Average case coverage (c/b)
1. Goal-function 2. Goal-form 3. Goal-economy 4. Goal-time 5. Concept-function 6. Concept-form 7. Concept-economy 8. Concept-time Total
13 12 8 6 11 11 7 6 74
73 74 23 9 42 98 16 10 345
40.99 41.62 10.62 4.89 25.57 43.95 9.28 6.16 183.08
3.153 3.468 1.328 0.815 2.325 3.995 1.326 1.027 2.474
0.562 0.562 0.462 0.543 0.609 0.448 0.580 0.616 0.531
Standard deviation of average group coverage: 1.229. Standard deviation of average case coverage: 0.063.
considering its direct proportion to group size and inverse proportion to group density.
GroupDensityðGÞ =
∑CaseDensity ðc; GÞ
c∈G
jGj
GroupCoverageðGÞ = 1 + ½ jG j × ð1−GroupDensityðGÞÞ
ð2Þ ð3Þ
Case base coverage: to this end, case base coverage is relatively straightforward and defined as the total coverage of the competence groups C = {G1, G2, …, Gn} by Eq. (4). CoverageðC Þ = ∑ GroupCoverageðGi Þ Gi ∈C
ð4Þ
The case base is constructed through distilling cases from the principal literature listed in Table 3. Consequently we have 345 cases in the case base and these cases are classified into 74 competence groups that are categorized into the eight general groups described in the section of indexing case. The coverage scores of the case base are shown in Table 4 and the coverage distribution of the competence groups is shown in Fig. 9. The biggest three general groups (i.e. goal-function, goal-form, and concept-form) account for 69% coverage. The competence group coverage scores fluctuate greatly; the mean of the average group coverage scores is 2.474, but the standard deviation of them is 1.229. Compared with the spread-out average group coverage scores, the average case coverage scores are relatively uniform; the mean and standard deviation of them are 0.531 and 0.063 respectively.
The fluctuated average group coverage scores indicate that the central issues of the CBR system are focused on goal-function, goalform, and concept-function. The inadequate case accumulation in economy and time categories identifies the direction of the future work on case authoring; the future case authoring should pay more attention on these two inadequate categories. 6.2. Percentage of problem solving successes and performance of recommendations Before turning to the evaluation equations of percentage of problem solving successes and performance of recommendations, it is necessary to clarify two basic elements of the general CBR process: event and session. According to [42], an event is a call to the system provoked by an action performed by the user. In our study, the action consists of two steps: first is inputting keywords and second is selecting an interesting function returned by the CBR system. A session s(u) is a set of closed events provoked by a user u. We classify recommendation items into three categories: 1) P1: the items with preference P1 are those that can be directly used according to the judgment of the user. A recommendation is successful when it is of preference P1. 2) P2: the items with preference P2 are those that can work as inspiration to elicit adequate requirement definitions, or be used after some revisions. 3) P3: the items with preference P3 are those remaining. Therefore, in a session s, the percentage of problem solving successes is formulated as Eq. (5) and performance of recommendations as Eq. (6). In these two equations, n represents the number of successful recommendations, |R| the number of recommendations, and |E| the number of events. SuccessPercentageðsÞ = PerformanceðsÞ =
n ð%Þ j Rj
ð5Þ
n jE j
ð6Þ
Five experts with construction industry experience were invited to the experiment. All of them were familiar VM; they attended VM class
Table 5 Success percentage and performance of function recommendations.
Fig. 9. Coverage distribution of competence groups.
Count of events Count of P1 functions Count of P2 functions Count of P3 functions Success percentage Performance
User 1
User 2
User 3
User 4
User 5
Total
12 33 16 1 66% 2.75
11 43 21 9 59% 3.91
10 25 20 6 49% 2.50
10 49 7 0 88% 4.90
10 42 23 2 63% 4.20
53 192 87 18 65% 3.62
X. Luo et al. / Automation in Construction 19 (2010) 725–733 Table 6 Success percentage and performance of functional performance recommendations.
Count of events Count of C1 function performance items Count of C2 function performance items Count of C3 function performance items Success percentage Performance
User 1
User 2
User 3
User 4
User 5
Total
12 19
11 17
10 20
10 13
10 29
53 98
5
13
8
0
17
43
0
1
1
0
0
2
79% 1.58
55% 1.55
69% 2.00
100% 1.30
63% 2.90
69% 1.85
BRE533 Value Management in Construction and Property in The Hong Kong Polytechnic University. The combination of the most relevant two domains, i.e. construction and VM, was expected to ensure the experimental validity of the system performance evaluation. Each expert was asked to evaluate around 10 events and then evaluated the competence of the recommendations. The results of the experiment are shown in Tables 5 and 6. It shows that the usefulness of the CBR system is acceptable, referring to 65% and 69% problem solving successes on functions and functional performance recommendation respectively. However, compared with the performance of recommendation on functions (score 3.62), the score of functional performance of 1.85 demonstrates that more functional performance items should be identified and retained to the case base. 7. Conclusions This paper presents a CBR system attempting to facilitate the use of FPS at the briefing stage of building projects. A job plan composed of five phases (preparation, information, function analysis, performance specification and evaluation) has been proposed. To serve the job plan, the system has been designed to recommend functions in the function analysis phase and functional performance in the performance specification phase. The recommendations may be adopted directly or used to elicit more accurate representation of requirements. The system design considers three elementary CBR system design issues: representing cases, indexing cases, and retrieving cases. According to the performance evaluation of the CBR system, it holds high promise to effectively facilitate the use of FPS in the briefing of building projects. However, it should be remembered that the case base should be constructed well enough; the cases residing in the case base are primarily concerned with three general groups: goal-function, goal-form, and goal-concept. In addition, more effort should be made to refine the recommendations on functional performance. Nevertheless, the system described throws new light on improving the efficiency and accuracy of defining functions and their performance, and therefore facilitating the use of FPS in briefing. It also offers an effective approach to accumulating and reusing the valuable knowledge in previous construction briefing practice. Acknowledgements The authors wish to express their sincere gratitude to the Research Grants Council of the Hong Kong Special Administrative Region, China (PolyU 5252/05E) for the funding support to the projects on which this paper is based. We would also like to extend our appreciation to Dr. Derek Drew for his general advice on the writing of the paper and Dr. Paul Fox for his help in editing the paper. References [1] I. Watson, Applying Case-based Reasoning: Techniques for Enterprise Systems, Morgan Kaufmann Publishers, Inc., San Francisco, California, 1997. [2] H. Li, Case-based reasoning for intelligent support of construction negotiation, Information & Management 30 (5) (1996) 231–238. [3] N.J. Yau, J.B. Yang, Applying case-based reasoning technique to retaining wall selection, Automation in Construction 7 (4) (1998) 271–283.
733
[4] D.K.H. Chua, D.Z. Li, W.T. Chan, Case-based reasoning approach in bid decision making, Journal of Construction Engineering and Management 127 (1) (2001) 35–45. [5] D.K.H. Chua, Y.M. Goh, Application of case based reasoning in construction safety planning, Computing in Civil Engineering, Proceedings of International Workshop on Information Technology in Civil Engineering, 2002, pp. 298–307. [6] D.T. Luu, S. Thomas Ngb, S.E. Chena, A case-based procurement advisory system for construction, Advances in Engineering Software 34 (7) (2003) 429–438. [7] R.J. Dzeng, H.Y. Lee, Critiquing contractors' scheduling by integrating rule-based and case-based reasoning, Automation in Construction 13 (5) (2004) 665–678. [8] H.G. Ryu, H.S. Lee, M. Park, Construction planning method using case-based reasoning, Journal of Computing in Civil Engineering 21 (6) (2007) 410–422. [9] I. Dikmen, M. Talat Birgonul, A. Kemal Gur, A case-based decision support tool for bid mark-up estimation of international construction projects, Automation in Construction 17 (1) (2007) 30–44. [10] S.T. Thomas Ng, D.T. Luu, Modeling subcontractor registration decisions through casebased reasoning approach, Automation in Construction 17 (7) (2008) 873–881. [11] Y.M. Goh, D.K.H. Chua, Case-based reasoning for construction hazard identification: case representation and retrieval, Journal of Construction Engineering and Management 135 (11) (2009) 1181–1189. [12] S. Lee, C. Hyun, T. Hong, RETRIEVE: REmembering Tool for Reusing the Ideas Evolved in Value Engineering, Automation in Construction 18 (8) (2009) 1123–1134. [13] J.J.N. O'Reilly, Better briefing means better buildings, Building Research Establishment (BRE), Garston, Watford, 1987. [14] D. McGeorge, A. Palmer, Construction Management—New Directions, Blackwell Science, London, 1997. [15] S.D. Green, A SMART methodology for value management, occasional paper, The Chartered Institute of Building, 1992. [16] J. Kelly, S. Male, Value Management in Design and Construction, E&F N. Spon, London, 1993. [17] R.T. Barton, Soft value management methodology for use in project initiation—a learning journey, Journal of Construction Research 1 (2) (2000) 109–122. [18] J. Kelly, S. Male, D. Graham, Value Management of Construction Projects, Blackwell Science, 2004. [19] Q.P. Shen, H. Li, J. Chung, P.Y. Hui, A framework for identification and representation of client requirements in the briefing process, Construction and Management Economics 22 (2) (2004) 213–221. [20] T.W. Yu, A Value Management Framework for Systematic Identification and Precise Representation of Client Requirements in the Briefing Process, Ph.D. Thesis, Department of Building and Real Estate, The Hong Kong Polytechnic University, Hong Kong, 2006. [21] Environment, Transport, and Works Bureau (ETWB), Implementation of Value Management, Technical Circular No. 35/2002, Hong Kong SAR Government, 2002. [22] Construction Industry Review Committee (CIRC), Construct for Excellence—Report of the Construction Industry Review Committee, Hong Kong SAR Government, 2001. [23] B. Norton, W. McElligott, Value Management in Construction: A Practical Guide, MacMillan Press Ltd., London, 1995. [24] T.J. Snodgrass, K.K. Muthiah, Function Analysis: the Stepping Stones to Good Value, University of Wisconsin, Madison WI, 1986. [25] C.W. Bytheway, FAST Creativity & Innovation: rapidly improving processes, product development, and solving complex problems, J. Ross Publishing, Inc., Florida, 2007. [26] L.F. Janin, Functional Specifications, Proceedings of International Conference—Society of American Value Engineers, Indianapolis, Indiana, June 1989, 1989, pp. 112–117. [27] B.C. Meyers, N.H. Weiderman, Functional Performance Specification for an Inertial Navigation System, A Technical Report, Software Engineering Institute Carnegie Mellon University, Pittsburgh, Pennsylvania, 1988. [28] J. Masson, The Use of Functional Performance Specification to Define Information Systems Requirements, Create RFQ to Suppliers and Evaluate the Supplier's Response, SAVE International 41st Conference Proceedings, Fort Lauderdale, 2001. [29] A. Beal, S. Holmes, Functional Performance Specifications: Knowing What You Need, Road Talk, Ministry of Transportation of Canada, 2006. [30] T.W. Fletcher, L. Parrot, Using VM/FPS (Functional Performance Specification) to prepare a framework for the development of a comprehensive traffic volume information system, SAVE International 46th Annual Conference Proceedings, Savannah, Georgia, 2006. [31] Y. St-Laurent, H. Nguyen, Integrated product development using functional specification: an application at Frigidaire Canada, CSVA International Conference, 1998. [32] Deparment of Defence (DoD) of Australian, DEF (AUST) 8324: Perishable Food Load Units Functional Performance Specification, Australian Government, 2006. [33] E.J. Gibson, Working with the Performance Approach in Building, CIB State of the Art Report, No. 64, CIB Working Commission W060, Rotterdam, 1982. [34] X.C. Luo, Q.P. Shen, A computer-aided FPS-oriented approach for construction briefing, Tsinghua Science and Technology 13 (S1) (2008) 292–297. [35] J.L. Kolodner, Case-Based Reasoning, Morgan Kaufmann, 1993. [36] C. Riesbeck, R. Schank, Inside Case-based Reasoning, Lawrence Erlbaum Association, Hillsdale, Hove and London, 1989. [37] T. Gruber, Toward principles for the design of ontologies used for knowledge sharing, International Journal Human-Computer Studies 43 (1993) 907–928. [38] W. Pena, S. Parshall, Problem seeking: an architectural programming primer, 4th edJohn Wiley and Sons Inc, 2001. [39] I. Watson, F. Marir, Case-based reasoning: a review, The Knowledge Engineering Review 9 (4) (1994) 355–381. [40] T. Simpson, T. Dao, WordNet-based semantic similarity measurement, http://www. codeproject.com/KB/string/semanticsimilaritywordnet.aspx2005. [41] B. Smyth, E. McKenna, Modelling the Competence of Case-Bases, in: B. Smyth, P. Cunningham (Eds.), EWCBR' 98, LNAI, 1488, 1998, pp. 208–220. [42] F.H. Olmo, E. Gaudioso, Evaluation of recommender system: a new approach, Expert Systems with Applications 35 (2007) 790–804.
Contents lists available at ScienceDirect
Automation in Construction j o u r n a l h o m e p a g e : w w w. e l s ev i e r. c o m / l o c a t e / a u t c o n
A case-based reasoning system for using functional performance specification in the briefing of building projects Xiaochun Luo, Geoffrey Qiping Shen ⁎, Shichao Fan Department of Building and Real Estate, The Hong Kong Polytechnic University, Hong Kong
a r t i c l e
i n f o
Article history: Accepted 26 February 2010 Keywords: Case-based reasoning Functional performance specification Value management Briefing Building projects
a b s t r a c t Functional Performance Specification (FPS) is a structured requirement analysis process, in which client requirements are firstly defined with functions and relevant evaluation criteria — functional performance. This paper describes a Case-Based Reasoning (CBR) system recommending functions and functional performance to facilitate the use of FPS in the briefing of building projects. It begins with an introduction to the briefing practice and the problems of using FPS in briefing, followed by proposing a structural job plan of FPS. Next, the CBR system design is described and how it supports the use of FPS is illustrated. Finally, the competence of the system is evaluated with two experiments, which demonstrate that the CBR system is a highly promising tool for facilitating the use of FPS. The future research work concerning addressing the shortcomings of the CBR system identified in the experiments is also noted. Crown Copyright © 2010 Published by Elsevier B.V. All rights reserved.
1. Introduction
2. Functional Performance Specification (FPS) for briefing
Case-Based Reasoning (CBR) utilizes the specific knowledge of previously experienced, concrete problem situations (cases), thus a new problem is solved by finding a similar past case, and reusing it in a new problem situation [1]. CBR has been widely applied to a variety of tasks. Concerning applications in the A/E/C industry, we can cite construction negotiation [2], wall selection [3], bid decision making [4], construction safety planning [5], procurement selection [6], construction planning [7,8], bid mark-up estimation [9], subcontractor registration decisions [10], value engineering [11], and construction hazard identification [12]. Due to the success of CBR in suggesting solutions based on similar situations, the study described in this paper aims to introduce CBR to support the use of Functional Performance Specification (FPS) in the briefing process of building projects. The strategy we take is to design a CBR system that retrieves similar cases (textural functions representing client requirements in the form of ‘verb + noun’ enable semantic search) responding to the new event (keywords related to requirements that the user concerns), and then recommends solutions (relevant functions and their functional performance) to the selected returned cases. The paper begins with an introduction to the briefing, followed by the discussion of the problems encountered in using FPS in it. After that, a structural job plan of FPS is proposed. Next, the design of the CBR system is detailed, including how it supports the use of FPS in the briefing. Finally, we evaluate the competence of the system within two experiments.
Briefing (also known as ‘architectural programming’ in the US) is a process through which a client informs others of his/her needs, aspirations, and desires for a project [13]. A brief is the document that defines client requirements for a building. Defining the requirements and communicating them to other stakeholders are crucial to the successful delivery of a project [14,15]. With consideration of the critical influence of briefing on the whole building delivery process, Value Management (VM) exercises are expected to be conducted at the earlier stages [16–21]. In Hong Kong, the Environment, Transport and Works Bureau requires major projects (those with an estimated project cost exceeding HK$ 200 million) in the subordinate departments to conduct VM studies [22]. The Construction Industry Review Committee also recommended that VM should be used more widely in local construction, because it can help the clients and the project team to focus on the objectives of the project and the needs of all stakeholders, both long and short term [23].
⁎ Corresponding author. E-mail address: [email protected] (G.Q. Shen).
2.1. Value management VM is concerned with defining what ‘value’ means to a client within a particular context by bring the project stakeholders together and producing a clear statement of the project's objectives [16]. An essential feature of the VM approach is expressing client requirements as functions. In terms of VM, a function is referred to as the specific purpose or intended use of a project that makes the project sell, produce revenue or meet requirements. Function analysis is one of the key components of VM methodology, which distinguishes VM from other cost reduction activities [23]. Charles Bytheway developed a concept and named it FAST (Function Analysis
0926-5805/$ – see front matter. Crown Copyright © 2010 Published by Elsevier B.V. All rights reserved. doi:10.1016/j.autcon.2010.02.017
726
X. Luo et al. / Automation in Construction 19 (2010) 725–733
Fig. 1. Structure of FPS (adapted from [34]).
System Technique), which utilizes ‘why-how’ logic to address the difficulty of getting agreement on the basic function of an assembly or component [24]. Bytheway succinctly summarizes the ‘why-how’ logic and features of the FAST in the following statement: ‘the result of writing down the functions as they relate to each other generated a visual diagram which showed how each function is performed by merely observing the functions posted immediately to the right of any given function. By the same token, if one desired to know why a given function is required, the function posted at its immediate left provided the answer [25]’. Job plan is another key component of VM methodology [23]. It is a structured process which has a definite beginning and a definite end. A good job plan lays down the procedure of a VM workshop explicitly. A successful attempt in the functional representation of client requirements is the Charette job plan, which rationalizes client briefs primarily through the function analysis of space requirements. Shen et al. [20] contended that it should be broadened to include other issues of client requirements and to communicate them clearly to the designers. 2.2. Functional Performance Specification (FPS) As one of VM techniques, FPS was originally developed in French manufacturing, and was used in Europe as a system for the explicit
statement of optimum product definition for a given market within a tool for conception and design management [26]. Currently, the application of FPS is primarily in the two realms of software engineering [27–30] and manufacturing industry [26,31,32]. FPS represents requirements in terms of functions in the form of ‘verb + noun’, functional performance criteria, and flexibilities of these criteria indicating which of them are imperative (with a certain tolerance) and which are desired but open to negotiation. The structure of briefs achieved by conducting FPS is shown in Fig. 1. Shen et al. introduce FPS to the construction industry and developed a structured framework for identifying and representing client requirements in briefing [19]. In the context of a briefing team of multidisciplinary stakeholders, where the focus, perspective, orientation, knowledge, and expertise of the stakeholders are often quite diverse, there is a strong need to have a common language to present client requirements. As a performance-based approach thinking and working in terms of ends rather than means [33], FPS constructs a design-neutral way allowing all team members to communicate more effectively. To further prompt and validate the framework by Shen et al., a computer-aided tool FPS Genius was developed by Luo and Shen [34]. However, during the course of applying the computer-aided tool in practice, it has become apparent that to efficiently and accurately define functions and their performance in the function analysis phase with a fixed and short duration is a big challenge.
3. CBR for FPS CBR is useful in interpreting open-ended and ill-defined concepts; in other words, CBR allows a reasoner to propose solutions in domains that are not completely understood by the reasoner [35]. With respect to the uniqueness and complexity of building projects, it is feasible and practical to introduce CBR to address the problems encountered in using FPS in briefing. Unique cases defined in the briefs of previous analogous building projects could and should be reused. With the recommendations by CBR, those normal inexperienced clients are expected to understand their projects and clarify their requirements more easily. To combine CBR with the FPS practice, we adapt the job plan in [19] and propose a new one with five phases (see Fig. 2): 1) preparation phase to organize the briefing team and define the briefing workshop, 2) information phase to establish a shared understanding of the project among all participants,
Fig. 2. Job plan for using FPS in briefing.
X. Luo et al. / Automation in Construction 19 (2010) 725–733
727
3) function analysis phase to identify client requirements in functional terms and develop these functions into a task functional diagram using the why-how logic, 4) performance specification phase to identify functional performance and assign flexibility to each performance item, and 5) evaluation phase to generate and assess the brief and to agree ways to evaluate whether the requirements in the brief are met at the end of the project. The CBR system is designed to work through recommending functions and related functional performance. Thus, it will be used in function analysis phase and performance specification phase of the proposed job plan.
4. System design Fig. 3. View of a typical case.
Core problems addressed by CBR research and development can be grouped into four areas: representing cases, indexing cases, retrieving cases, adapting cases [1]. Considering the simple nature of solutions (i.e. textural expressions of functions and functional performance),
Fig. 4. Part of the ontology for case indexing.
728
X. Luo et al. / Automation in Construction 19 (2010) 725–733
we use a null adaptation [36] strategy in our system that means no adaptation.
Table 1 Development and use environments of the CBR system. Item
Development environment
4.1. Representing cases Hardware
A case is a contextualized piece of knowledge representing an experience [1]. Typically, a case is composed of two elements [35]: the problem that describes the state of the world when the case occurred and the solution that states the derived solution to that problem. In our system design, the problem is defined with two entities: (1) a function that representing a piece of client requirements and (2) the building type, for which the function is defined. The solution is the recommendations pertinent to the function and the building type; it consists of two categories: (1) recommended functions answering question ‘why’, ‘how’ and functions similar with the function of the case, and (2) recommended functional performance. Fig.3. shows the view of a typical case. 4.2. Indexing cases Case indexing involves assigning indices to cases to facilitate their retrieval [1]. The indexing problem has several parts. First is the problem of assigning labels to cases at the time that they are entered into the case base to ensure that they can be retrieved at the appropriate time. Second is the problem of organizing cases so that searches through the case base can be done efficiently and accurately [35]. We adopt the similarity and explanation-based generalisation method that produces an appropriate set of indices for abstract cases created from cases that share some common set of features, whilst the unshared features are used as indices to the original cases [1]. We construct an ontology, which is a ‘formal, explicit specification of a shared conceptualisation’ [37], to implement the similarity and explanation-based generalization. As one of the most influential and comprehensive information matrices, the information index matrix by Pena and Parshall is adapted and adopted to build the ontology. The solution proposed utilizes the ‘goals’ and ‘concepts’ columns in [38] to construct the briefing domain ontology, in which ‘goals’ means what the client want to achieve, and why; whilst ‘concepts’ means how the client achieve the ‘goals’. In each column, four considerations, i.e. function, form, economy and time, are taken. Thus, the final
Intel Pentium 4 CPU 2.80 GHz, 1.50 GB of RAM Software Microsoft Windows XP Version support 2002 Service Pack 2, Microsoft . NET Framework 2.0, Microsoft Office 2003 Access IDE Microsoft Visual Studio 2005 EN Programming C# language
Use environment (minimum requirements) CPU 1.0 GHz, 512 MB of RAM Microsoft Windows XP Version 2002 Service Pack 2, Microsoft . NET Framework 2.0, Microsoft Office 2003 Access
ontology enables us to categorize cases into eight general groups: goal-function, goal-form, goal-economy, goal-time, concept-function, concept-form, concept-economy, and concept-time. Considering the practical target of the CBR system, the ontology is organized into a tree view (see Fig. 4), which is similar with the hierarchical structure of FPS. As shown in the figure, two relationships among entities are created: abstract-concrete and motivation-action. These entities are ‘abstract cases created from cases that share some common set of features’. The two relationships essentially follow the ‘why-how’ logic; the abstract/motivation entities answer the question ‘why’ and the concrete/action entities answer the question ‘how’. In the example shown in Fig. 4: 1) the abstract entity ‘physical comfort’ is implemented by concrete entities ‘aural comfort’, ‘visual comfort’, and ‘thermal comfort’; 2) the abstract entity ‘environment controls’ is carried out through concrete entities ‘noise control’, ‘ventilation’, and ‘adequate lighting’; and 3) the action entity ‘environmental controls’ serves motivation entity ‘physical comfort’.
4.3. Retrieving cases Retrieving a case starts with a problem description, and ends when a best matching previous case has been found. Its subtasks are referred to as identifying features, initially matching, searching, and
Fig. 5. Four types of approaches to retrieving cases.
X. Luo et al. / Automation in Construction 19 (2010) 725–733
729
selecting, executed in that order [39]. We implement the process as follows:
5) computing similarity of the sentences: computing the similarity of the sentences based on the similarity of the pairs of words.
1) the user identifies features, i.e. keywords related to his/her requirements; 2) the CBR system semantically searches functions in the case base with keywords; 3) the user selects the functions he/she is interested in; finally 4) the CBR system retrieves the solutions to the problem pertinent to the selected function in step 3.
The case retrieval step 4 is implemented through the abstractconcrete and motivation-action relations. The abstract-concrete relation allows us to find out the similar functions of the selected function in step 3; it tries to identify the ‘siblings’ of the function as its similar functions. The motivation-action relation is employed to retrieve functions answering ‘why’ and/or ‘how’ from the causal perspective. As a result, four types of case retrieval approaches can be built as follows (see Fig. 5): functions answering ‘why’, similar functions, functions answering ‘how’, and functional performance.
The following contents are engaged to describe the implementations of steps 2 and 4. We borrow the semantic search engine reported in [40] to fulfil case retrieval 2. The engine enables us to measure semantic similarity between functions stored in the case base and keywords input by the user. Although, the project only concerns work with ‘noun-noun’, and ‘verb–verb’ parts of speech, it is believed adequate for the current CBR system since functions are primarily defined in the form of ‘verb + noun’. There are five steps in the algorithm to calculate semantic similarity between two sentences: 1) tokenization: partitioning each sentence into a list of tokens; 2) tagging part of speech: identifying the correct part of speech of each word in the sentence; 3) stemming words: removing the common morphological and inflexional endings of words; 4) word sense disambiguation: finding the most appropriate sense for every word in a sentence;
5. Using the CBR system in briefing The CBR system is implemented on Microsoft Windows XP with Microsoft .NET Framework 2.0. The case base is accommodated in Microsoft Office 2003 Access considering the flexibility and the cost of the system deployment and configuration. The integrated development environment (IDE) is Microsoft Visual Studio 2005 EN. Table 1 describes the development and use environments of the CBR system. 5.1. Authoring cases A case base administrator is implemented to author cases for the CBR system. The user of the case base administrator is expected to be a knowledge engineer who is responsible for retaining new cases, updating existing cases, and deleting inadequate cases. A snapshot of
Fig. 6. Interface of the case base administrator.
730
X. Luo et al. / Automation in Construction 19 (2010) 725–733
the main interface of the case base administrator is shown in Fig. 6, in which six feature areas are designed including indexing tree, address of cases, existing functions, existing function performance, new functions, and new functional performance. After adding a new entity into the indexing tree or simply selecting an existing node (entity) in the indexing tree, the address of cases can be located. The hierarchy of the indexing tree is established based on the ‘abstract-concrete’ relation. When an existing node is selected, the existing functions and functional performance attached to it, if any, are shown promptly in relevant feature areas. After defining the new cases, the next step is to establish the ‘motivation-action’ relation between the newly added entities. The interface for establishing case relations is shown in Fig. 7, in which four feature areas are designed: client path, service path, existing relations, and new relations. Client paths represent addresses of motivation entities and service paths reflect addresses of action entities. When a path is identified, client or service, the existing relations with it will be shown in the existing relations area. The case base administrator can also use it to manage the existing entity relations. 5.2. Recommending solutions The case-based reasoner is the key component in the CBR system to generate recommendations according to inputs by the user. A snapshot of the interface of the case-based reasoner is shown in Fig. 8. There are six feature areas in the interface: searching area, results found, functions answering ‘why’, similar functions, functions answering ‘how’, and functional performance. The searching area consists of keywords of function, building type, and semantic similarity. The case-based reasoner semantically searches the case base with building type and semantic similarity as filtering
conditions. Here, semantic similarity is a threshold controlling the minimum semantic similarity between the keywords input and the functions stored in the case-base. Only those functions with bigger semantic similarity than the threshold will be returned. Selecting any retrieved function will trigger case retrieval process. That is, the related functions and functional performance to the selected function will be shown in the relevant areas. As an example, Table 2 shows the solution generated by the CBR system to function ‘ensure aural comfort’. 6. System performance evaluation In the following section, we evaluate the system competence with respect to three performance criteria: case base coverage, percentage of problem solving successes, and performance of recommendations. The first criterion is used to measure the competence of the case base and the last two are employed to evaluate the utility of the CBR system. 6.1. Case base coverage We borrow the matrixes of case base coverage proposed by Smyth and McKenna [41] as one of the criteria to measuring the competence of our system. Since there are some subtle yet different interpretations of the elements consisting of the measuring model considering the characteristics of our CBR system, we give our adapted definitions as follows: Case density: the density of cases is defined and used to evaluate the individual competence contribution of a single case in a case group. A case within a dense collection is believed to have lower competence contribution than one within a sparse group; dense groups contain greater redundancy than sparse groups [41]. The local density of a case c within a case group G is formulated as Eq. (1), where Sim(c, c′) is the semantic similarity between the entities, to which the case c and the case c′
Fig. 7. Interface of establishing motivation-action relations.
X. Luo et al. / Automation in Construction 19 (2010) 725–733
731
Fig. 8. Interface of the case based reasoner.
attached, and |G| is the number of cases in group G. If there is only one case in a case group, the local density of the case is set as 1. ∑
CaseDensityðc; GÞ =
c0 ∈G−fcg
Sim c; c′ ð1Þ
jGj−1
Table 3 Case sources.
Table 2 An example: the proposed solution to ‘ensure aural comfort’. Suggestions Functions answering ‘why’ Alternative/Similar functions Functions answering ‘how’ Functional performance
Competence groups and group coverage: a collection of related cases that share coverage constitute a competence group [41]. In this research, we identified 74 competence groups resided in the case base; they are the entities consist of the information matrix. In this sense, group density is defined as the average case density of the group (see Eq. (2)) and group coverage is formulated as Eq. (3)
Year Relations
Create physical comfort
Abstraction
1. Ensure thermal comfort 2. Ensure visual comfort 1. Reduce noise 2. Minimize noise 1. Room acoustics with limited background noise and suitable reverberation time should be designed for speech intelligibility 2. Distance between teachers and students should be minimized as much as practical 3. Sound absorption surfaces to reduce reverberation are best to be located at edges and the end wall of the classroom to achieve a balance between sound reflection and absorption and to avoid reflecting echo 4. Sound-absorbing materials are used to minimize noise
Abstraction Abstraction Causal Causal Abstraction
Abstraction
Abstraction
Causal
Title
2008 DQI briefing tool user guide, version 1.0 2004 21st century libraries: changing forms, changing futures. 2005 Picturing school design: a visual guide to secondary school buildings and their surroundings using the design quality indicator for schools 2006 Better places to work 2007 Guidance on tall buildings 2008 Building for life: delivering great places to live 2008 Building for life: evaluating housing proposals step by step 2009 Good design: the fundamentals 2005 Standard classification for serviceability of an office facility for support for office work 2005 Standard classification for serviceability of an office facility for meetings and group effectiveness 2005 Standard classification for serviceability of an office facility for layout and building factors 2005 Standard classification for serviceability of an office facility for location, access and wayfinding
Author CIC CABE CABE
CABE CABE CABE CABE CABE ASTM ASTM ASTM ASTM
CIC: the Construction Industry Council, http://www.dqi.org.uk/. CABE: Commission for Architecture and the Built Environment, http://www.cabe.org.uk/. ASTM: ASTM International, http://www.astm.org/.
732
X. Luo et al. / Automation in Construction 19 (2010) 725–733
Table 4 Case base coverage. General group
Count of competence groups (a)
Count of cases (b)
Group coverage (c)
Average group coverage (c/a)
Average case coverage (c/b)
1. Goal-function 2. Goal-form 3. Goal-economy 4. Goal-time 5. Concept-function 6. Concept-form 7. Concept-economy 8. Concept-time Total
13 12 8 6 11 11 7 6 74
73 74 23 9 42 98 16 10 345
40.99 41.62 10.62 4.89 25.57 43.95 9.28 6.16 183.08
3.153 3.468 1.328 0.815 2.325 3.995 1.326 1.027 2.474
0.562 0.562 0.462 0.543 0.609 0.448 0.580 0.616 0.531
Standard deviation of average group coverage: 1.229. Standard deviation of average case coverage: 0.063.
considering its direct proportion to group size and inverse proportion to group density.
GroupDensityðGÞ =
∑CaseDensity ðc; GÞ
c∈G
jGj
GroupCoverageðGÞ = 1 + ½ jG j × ð1−GroupDensityðGÞÞ
ð2Þ ð3Þ
Case base coverage: to this end, case base coverage is relatively straightforward and defined as the total coverage of the competence groups C = {G1, G2, …, Gn} by Eq. (4). CoverageðC Þ = ∑ GroupCoverageðGi Þ Gi ∈C
ð4Þ
The case base is constructed through distilling cases from the principal literature listed in Table 3. Consequently we have 345 cases in the case base and these cases are classified into 74 competence groups that are categorized into the eight general groups described in the section of indexing case. The coverage scores of the case base are shown in Table 4 and the coverage distribution of the competence groups is shown in Fig. 9. The biggest three general groups (i.e. goal-function, goal-form, and concept-form) account for 69% coverage. The competence group coverage scores fluctuate greatly; the mean of the average group coverage scores is 2.474, but the standard deviation of them is 1.229. Compared with the spread-out average group coverage scores, the average case coverage scores are relatively uniform; the mean and standard deviation of them are 0.531 and 0.063 respectively.
The fluctuated average group coverage scores indicate that the central issues of the CBR system are focused on goal-function, goalform, and concept-function. The inadequate case accumulation in economy and time categories identifies the direction of the future work on case authoring; the future case authoring should pay more attention on these two inadequate categories. 6.2. Percentage of problem solving successes and performance of recommendations Before turning to the evaluation equations of percentage of problem solving successes and performance of recommendations, it is necessary to clarify two basic elements of the general CBR process: event and session. According to [42], an event is a call to the system provoked by an action performed by the user. In our study, the action consists of two steps: first is inputting keywords and second is selecting an interesting function returned by the CBR system. A session s(u) is a set of closed events provoked by a user u. We classify recommendation items into three categories: 1) P1: the items with preference P1 are those that can be directly used according to the judgment of the user. A recommendation is successful when it is of preference P1. 2) P2: the items with preference P2 are those that can work as inspiration to elicit adequate requirement definitions, or be used after some revisions. 3) P3: the items with preference P3 are those remaining. Therefore, in a session s, the percentage of problem solving successes is formulated as Eq. (5) and performance of recommendations as Eq. (6). In these two equations, n represents the number of successful recommendations, |R| the number of recommendations, and |E| the number of events. SuccessPercentageðsÞ = PerformanceðsÞ =
n ð%Þ j Rj
ð5Þ
n jE j
ð6Þ
Five experts with construction industry experience were invited to the experiment. All of them were familiar VM; they attended VM class
Table 5 Success percentage and performance of function recommendations.
Fig. 9. Coverage distribution of competence groups.
Count of events Count of P1 functions Count of P2 functions Count of P3 functions Success percentage Performance
User 1
User 2
User 3
User 4
User 5
Total
12 33 16 1 66% 2.75
11 43 21 9 59% 3.91
10 25 20 6 49% 2.50
10 49 7 0 88% 4.90
10 42 23 2 63% 4.20
53 192 87 18 65% 3.62
X. Luo et al. / Automation in Construction 19 (2010) 725–733 Table 6 Success percentage and performance of functional performance recommendations.
Count of events Count of C1 function performance items Count of C2 function performance items Count of C3 function performance items Success percentage Performance
User 1
User 2
User 3
User 4
User 5
Total
12 19
11 17
10 20
10 13
10 29
53 98
5
13
8
0
17
43
0
1
1
0
0
2
79% 1.58
55% 1.55
69% 2.00
100% 1.30
63% 2.90
69% 1.85
BRE533 Value Management in Construction and Property in The Hong Kong Polytechnic University. The combination of the most relevant two domains, i.e. construction and VM, was expected to ensure the experimental validity of the system performance evaluation. Each expert was asked to evaluate around 10 events and then evaluated the competence of the recommendations. The results of the experiment are shown in Tables 5 and 6. It shows that the usefulness of the CBR system is acceptable, referring to 65% and 69% problem solving successes on functions and functional performance recommendation respectively. However, compared with the performance of recommendation on functions (score 3.62), the score of functional performance of 1.85 demonstrates that more functional performance items should be identified and retained to the case base. 7. Conclusions This paper presents a CBR system attempting to facilitate the use of FPS at the briefing stage of building projects. A job plan composed of five phases (preparation, information, function analysis, performance specification and evaluation) has been proposed. To serve the job plan, the system has been designed to recommend functions in the function analysis phase and functional performance in the performance specification phase. The recommendations may be adopted directly or used to elicit more accurate representation of requirements. The system design considers three elementary CBR system design issues: representing cases, indexing cases, and retrieving cases. According to the performance evaluation of the CBR system, it holds high promise to effectively facilitate the use of FPS in the briefing of building projects. However, it should be remembered that the case base should be constructed well enough; the cases residing in the case base are primarily concerned with three general groups: goal-function, goal-form, and goal-concept. In addition, more effort should be made to refine the recommendations on functional performance. Nevertheless, the system described throws new light on improving the efficiency and accuracy of defining functions and their performance, and therefore facilitating the use of FPS in briefing. It also offers an effective approach to accumulating and reusing the valuable knowledge in previous construction briefing practice. Acknowledgements The authors wish to express their sincere gratitude to the Research Grants Council of the Hong Kong Special Administrative Region, China (PolyU 5252/05E) for the funding support to the projects on which this paper is based. We would also like to extend our appreciation to Dr. Derek Drew for his general advice on the writing of the paper and Dr. Paul Fox for his help in editing the paper. References [1] I. Watson, Applying Case-based Reasoning: Techniques for Enterprise Systems, Morgan Kaufmann Publishers, Inc., San Francisco, California, 1997. [2] H. Li, Case-based reasoning for intelligent support of construction negotiation, Information & Management 30 (5) (1996) 231–238. [3] N.J. Yau, J.B. Yang, Applying case-based reasoning technique to retaining wall selection, Automation in Construction 7 (4) (1998) 271–283.
733
[4] D.K.H. Chua, D.Z. Li, W.T. Chan, Case-based reasoning approach in bid decision making, Journal of Construction Engineering and Management 127 (1) (2001) 35–45. [5] D.K.H. Chua, Y.M. Goh, Application of case based reasoning in construction safety planning, Computing in Civil Engineering, Proceedings of International Workshop on Information Technology in Civil Engineering, 2002, pp. 298–307. [6] D.T. Luu, S. Thomas Ngb, S.E. Chena, A case-based procurement advisory system for construction, Advances in Engineering Software 34 (7) (2003) 429–438. [7] R.J. Dzeng, H.Y. Lee, Critiquing contractors' scheduling by integrating rule-based and case-based reasoning, Automation in Construction 13 (5) (2004) 665–678. [8] H.G. Ryu, H.S. Lee, M. Park, Construction planning method using case-based reasoning, Journal of Computing in Civil Engineering 21 (6) (2007) 410–422. [9] I. Dikmen, M. Talat Birgonul, A. Kemal Gur, A case-based decision support tool for bid mark-up estimation of international construction projects, Automation in Construction 17 (1) (2007) 30–44. [10] S.T. Thomas Ng, D.T. Luu, Modeling subcontractor registration decisions through casebased reasoning approach, Automation in Construction 17 (7) (2008) 873–881. [11] Y.M. Goh, D.K.H. Chua, Case-based reasoning for construction hazard identification: case representation and retrieval, Journal of Construction Engineering and Management 135 (11) (2009) 1181–1189. [12] S. Lee, C. Hyun, T. Hong, RETRIEVE: REmembering Tool for Reusing the Ideas Evolved in Value Engineering, Automation in Construction 18 (8) (2009) 1123–1134. [13] J.J.N. O'Reilly, Better briefing means better buildings, Building Research Establishment (BRE), Garston, Watford, 1987. [14] D. McGeorge, A. Palmer, Construction Management—New Directions, Blackwell Science, London, 1997. [15] S.D. Green, A SMART methodology for value management, occasional paper, The Chartered Institute of Building, 1992. [16] J. Kelly, S. Male, Value Management in Design and Construction, E&F N. Spon, London, 1993. [17] R.T. Barton, Soft value management methodology for use in project initiation—a learning journey, Journal of Construction Research 1 (2) (2000) 109–122. [18] J. Kelly, S. Male, D. Graham, Value Management of Construction Projects, Blackwell Science, 2004. [19] Q.P. Shen, H. Li, J. Chung, P.Y. Hui, A framework for identification and representation of client requirements in the briefing process, Construction and Management Economics 22 (2) (2004) 213–221. [20] T.W. Yu, A Value Management Framework for Systematic Identification and Precise Representation of Client Requirements in the Briefing Process, Ph.D. Thesis, Department of Building and Real Estate, The Hong Kong Polytechnic University, Hong Kong, 2006. [21] Environment, Transport, and Works Bureau (ETWB), Implementation of Value Management, Technical Circular No. 35/2002, Hong Kong SAR Government, 2002. [22] Construction Industry Review Committee (CIRC), Construct for Excellence—Report of the Construction Industry Review Committee, Hong Kong SAR Government, 2001. [23] B. Norton, W. McElligott, Value Management in Construction: A Practical Guide, MacMillan Press Ltd., London, 1995. [24] T.J. Snodgrass, K.K. Muthiah, Function Analysis: the Stepping Stones to Good Value, University of Wisconsin, Madison WI, 1986. [25] C.W. Bytheway, FAST Creativity & Innovation: rapidly improving processes, product development, and solving complex problems, J. Ross Publishing, Inc., Florida, 2007. [26] L.F. Janin, Functional Specifications, Proceedings of International Conference—Society of American Value Engineers, Indianapolis, Indiana, June 1989, 1989, pp. 112–117. [27] B.C. Meyers, N.H. Weiderman, Functional Performance Specification for an Inertial Navigation System, A Technical Report, Software Engineering Institute Carnegie Mellon University, Pittsburgh, Pennsylvania, 1988. [28] J. Masson, The Use of Functional Performance Specification to Define Information Systems Requirements, Create RFQ to Suppliers and Evaluate the Supplier's Response, SAVE International 41st Conference Proceedings, Fort Lauderdale, 2001. [29] A. Beal, S. Holmes, Functional Performance Specifications: Knowing What You Need, Road Talk, Ministry of Transportation of Canada, 2006. [30] T.W. Fletcher, L. Parrot, Using VM/FPS (Functional Performance Specification) to prepare a framework for the development of a comprehensive traffic volume information system, SAVE International 46th Annual Conference Proceedings, Savannah, Georgia, 2006. [31] Y. St-Laurent, H. Nguyen, Integrated product development using functional specification: an application at Frigidaire Canada, CSVA International Conference, 1998. [32] Deparment of Defence (DoD) of Australian, DEF (AUST) 8324: Perishable Food Load Units Functional Performance Specification, Australian Government, 2006. [33] E.J. Gibson, Working with the Performance Approach in Building, CIB State of the Art Report, No. 64, CIB Working Commission W060, Rotterdam, 1982. [34] X.C. Luo, Q.P. Shen, A computer-aided FPS-oriented approach for construction briefing, Tsinghua Science and Technology 13 (S1) (2008) 292–297. [35] J.L. Kolodner, Case-Based Reasoning, Morgan Kaufmann, 1993. [36] C. Riesbeck, R. Schank, Inside Case-based Reasoning, Lawrence Erlbaum Association, Hillsdale, Hove and London, 1989. [37] T. Gruber, Toward principles for the design of ontologies used for knowledge sharing, International Journal Human-Computer Studies 43 (1993) 907–928. [38] W. Pena, S. Parshall, Problem seeking: an architectural programming primer, 4th edJohn Wiley and Sons Inc, 2001. [39] I. Watson, F. Marir, Case-based reasoning: a review, The Knowledge Engineering Review 9 (4) (1994) 355–381. [40] T. Simpson, T. Dao, WordNet-based semantic similarity measurement, http://www. codeproject.com/KB/string/semanticsimilaritywordnet.aspx2005. [41] B. Smyth, E. McKenna, Modelling the Competence of Case-Bases, in: B. Smyth, P. Cunningham (Eds.), EWCBR' 98, LNAI, 1488, 1998, pp. 208–220. [42] F.H. Olmo, E. Gaudioso, Evaluation of recommender system: a new approach, Expert Systems with Applications 35 (2007) 790–804.