REQUIREMENTS PROCESSING: A FIRST STEP TOWARDS
CLIENT SATISFACTION
Requirements processing for client satisfaction
J. M. KAMARA and C. J. ANUMBA
Department of Civil and Building Engineering, Loughborough University, Loughborough, UK
N. F. O. EVBUOMWAN
Franosev Associates, Grand Prairie, Texas, USA
Abstract
As the initiators and financiers of projects, clients are central to the construction process. The satisfaction of their requirements should therefore be the ultimate goal of all parties in a project. There
are many factors, such as project organisation, design, construction and quality of materials, which
contribute to client satisfaction. However, the construction process should begin with a clear understanding of the wishes of the client. This can be achieved through requirements processing, which
involves the definition, analysis, and translation of explicit and implicit client requirements into a
format that designers can act upon. Client requirements processing (CRP) provides a framework
for: understanding the business needs of clients; rationalising and prioritising the various perspectives within the client body; and translating the wishes of clients into a format that designers can act
upon. This paper discusses the meaning and need for requirements processing and describes a methodology for CRP which is represented by a client requirements processing model (CRPM). CRP
within the CRPM has many advantages over existing practices, and can therefore serve as a first step
towards client satisfaction.
Keywords: Client satisfaction, construction, requirements processing.
1 Introduction
In construction, a client can be defined as the person or firm responsible for commissioning and paying for the design and construction of a facility (building, road, bridge, etc.) [1]. The client can also
be the user of a proposed facility, or they (i.e client and user) may be separate entities. However, as
the purchaser of services for the design and construction of a facility, the client should represent (or
consider) the interests of users and other identified persons, groups or organisations (stakeholders)
who influence, and are affected by, the acquisition, use, operation and demolition of the facility being
commissioned. Thus the ‘client’ becomes a ‘body’ which incorporates the interests of the buyer of
construction services, prospective users and other stakeholders.
Clients are at the core of the construction process as they initiate and pay for construction activities
[2]. The satisfaction of their requirements should therefore be the ultimate goal of the industry.
CIB W55 & W65 Joint Triennial Symposium
Customer Satisfaction : A focus for research & practice
Cape Town : 5-10 September 1999
Editors: Bowen, P. & Hindle, R.
Within the context of a project, the ultimate satisfaction of the client depends on a number of factors
which derive from his or her wishes. These include, but are not limited to, the following:
• Project organisation (i.e. procurement and contractual arrangements);
• Design quality. This provides the blueprint for the facility desired by the client. It depends on the
reliability of the brief (i.e. how well the design team understands the wishes of the client); the level
of expertise of the design team, the reliability of the sources of information used as the basis for
design, etc.;
• Construction quality. This depends on the skill of the work-force in translating the design into a
facility;
• Quality and suitability of construction materials that are used in the project (strength, durability,
functionality, etc.)
This paper discusses one aspect in the overall framework for client satisfaction: the determination of
their requirements by the project team. The focus of the paper is that effective requirements processing which results in precise and unambiguous requirements, is a first step towards the satisfaction
of clients. It is recognised that clear objectives in themselves do not necessarily lead to complete client satisfaction. However, it will be very difficult (if not impossible) to completely satisfy the client
without a clear understanding of precisely what he or she requires [2]. A methodology for effectively processing client requirements is therefore discussed.
2 Client requirements processing
Client requirements processing (CRP) involves the definition, analysis, and translation of explicit and
implicit client requirements into solution-neutral specifications for design purposes [3]. The outputs
of the CRP activity include the following:
• properly defined requirements which incorporate the different perspectives within the client (complexities within the client organisation), and which are unambiguous (precise and open to only one
interpretation) [4, 5];
• adequately decomposed or structured requirements (in a hierarchy from strategic or general
wishes, to more specific statements that are implementable) that facilitate traceability to original
requirements (structuring and rationalisation) [6];
• prioritised requirements that reflect the importance the client (including other perspectives within
the client body) places on each requirement (analysis);
• requirements that are adequately translated (or mapped) from the business terminology of the client to that of design professionals in the industry;
• requirements which are stated in a way that do not prescribe any pre-conceived solution (no restriction to designer creativity) and which facilitate the development of innovative solutions to the
client’s problem [7].
The need for client requirements processing arises from the nature of client requirements, and the
interactions between multi-disciplinary teams involved in a project.
2.1 Client requirements within the project context
A client represents different perspectives. These include the perspectives within the organisation of
the paying client (e.g. different departments), those of the various user groups represented and other
stakeholders (e.g. neighbourhood association). If the paying client is a consortium comprising dif-
CIB W55 & W65 Joint Triennial Symposium
Customer Satisfaction : A focus for research & practice
Cape Town : 5-10 September 1999
Editors: Bowen, P. & Hindle, R.
ferent organisations, the perspectives of these organisation would also have to be taken into consideration.
The interrelationships between these perspectives in the client requirements set can be very complex [8]. There are further interrelationships between client requirements and other project requirements (site, environmental, regulatory, design, construction and life-cycle requirements). Client requirements combine with site, environmental and regulatory requirements to produce design requirements, which in turn generate construction requirements. Other project requirements are generated (or derive) from the business need of the client that is to be satisfied by the proposed facility.
For example, a client’s desire to have an office block in a strategic location (because of the nature of
his or her business activities) will have an effect on the site, environmental and regulatory (relevant
planning regulations) requirements.
A thorough understanding of client requirements can therefore be achieved through effective requirements processing (definition, analysis and translation). Requirements definition ensures that all
the major perspectives within the client body are identified. Analysis ensures that various perspectives are rationalised, organised (into a hierarchy based on level of detail) and prioritised with respect
to the importance of each requirement. The consideration of client requirements separately from
other project requirements also ensures that focus is maintained on the client. This, in turn, can enhance adequate understanding of the problem which design and construction, in the context of the
immediate environment and the regulatory framework, are to solve.
2.2 Interactions between different members of a project team
The requirements of the client, together with other project requirements (site, regulatory, etc.) provide the input for project development teams (involving architects, engineers, etc.). The focus, perspective and orientation of each discipline (and member of the team) is usually different. Therefore,
to enable these disciplines to work collaboratively in the project development process, the following
are required:
• Clearly defined requirements, which are unambiguous, and which are understood from the perspective of the client (not those of the different professional disciplines). This will enable the
members of a project team to work from a common set of requirements.
• Requirements which are stated in design terms. This entails translating the ‘voice of the client’
into the ‘voice of the designer’ within the context of other relevant project requirements.
• A mechanism for managing the inevitable changes to requirements, and for tracing and correlating
the history of design decisions to the original and evolving requirements of the client.
• A process that ensures that focus on the client is maintained throughout.
The above conditions can be satisfied by the effective processing of client requirements. The process
of defining, structuring and rationalising the requirements will remove or minimise ambiguity, provide better understanding of the requirements, and facilitate traceability and correlation of requirements for life-cycle management.
3 A methodology for processing client requirements
A methodology for processing client requirements is now described. It is represented by a client requirements processing model (CRPM), which was developed using an iterative process involving
peer review with researchers and staff in the Construction Research Unit of the School of Science
and Technology (University of Teesside). Detailed analysis and discussions with industry practitio-
CIB W55 & W65 Joint Triennial Symposium
Customer Satisfaction : A focus for research & practice
Cape Town : 5-10 September 1999
Editors: Bowen, P. & Hindle, R.
ners were also carried out to generate ideas and validate a prototype software developed to demonstrate the working of the model.
The approach adopted in the development of the model focuses on the description of the proposed facility (which satisfies the business need of the client) in terms of its functions, attributes, effects on people, and the process of acquiring and operating it. Through a process of structuring, a
hierarchy of primary, secondary and tertiary requirements are established. This forms the basis for
translating the client requirements into solution-neutral design specifications which can be acted
upon by a designers.
The CRPM is based on Quality Function Deployment (QFD), a matrix-based methodology which is
used in manufacturing for translating customers’ required quality characteristics (i.e. wants, needs
and desires) into appropriate product or service features [9]. In QFD, multi-functional teams are
used to identify, incorporate and deploy the ‘voice of the customer’ during the product development
process [9]. Other tools are also used in the CRPM to facilitate the identification, structuring, analysis, rationalisation and translation of explicit and implicit client requirements into solution-neutral
specifications for design purposes [10]. They include:
•
•
•
•
Elicitation tools to facilitate the elicitation of requirements from the client(s).
Decomposition tools to facilitate the structuring, analysis and traceability of requirements (e.g.
value tree analysis, [11]).
Decision-making tools to facilitate the prioritisation of requirements (e.g. criteria weighting[11]).
The QFD ‘house of quality’ matrix is used for translating the ‘voice of the client’ into the ‘voice
of the designer’. It is also used for the traceability of requirements.
3.1 Description of the CRPM
The CRPM is described using the ICAM (Integrated Computed Aided Manufacturing Definition
Method for functional/activity modelling - IDEF-0) [12, 13] The basic notation of the IDEF-0
methodology consists of boxes and arrows. A box represents the activity/function and the arrows
represent inputs (left side of box), outputs (right side of box), controls (top of box) and mechanisms
(bottom of box) (IOCM). Inputs are converted into outputs through the activity represented by the
box. The controls serve as constraints for the activity and the mechanisms are the means (tools) for
carrying out the activity. Fig. 1 provides a representation of the main stages of the CRPM which are
described below.
CIB W55 & W65 Joint Triennial Symposium
Customer Satisfaction : A focus for research & practice
Cape Town : 5-10 September 1999
Editors: Bowen, P. & Hindle, R.
'Voice of The Client'
C1
C3
C2
Project Characteristics
Client Organisational Factors
International Standards
(e.g. ISO 6242:1-3) Ref: [13]
Project & Client Details,
Acquisition & Operation Info.
Project Characteristics
Facility Use
Information
User Information
I1
DEFINE CLIENT
REQUIREMENTS
Client's vision
of facility
1
Functions
& Attributes
Tertiary Client
Requirements
(TCRs)
ANALYSE CLIENT
REQUIREMENTS
Interest Groups
Information
2
Relative
Weights
of TCRs
RPT
TRANSLATE CLIENT
REQUIREMENTS
Solution-neutral
specifications
3
RPT
Elicitation Techniques
and Templates
Requirements
Processing Team (RPT)
M1
Node: CRPM/A0
M2
TITLE : PROCESS CLIENT REQUIREMENTS
Fig. 1. The Main Stages of the Client Requirements Processing Model
CIB W55 & W65 Joint Triennial Symposium
Customer Satisfaction : A focus for research & practice
Cape Town : 5-10 September 1999
Editors: Bowen, P. & Hindle, R.
Decomposition & Decision
Making Techniques
M3
QFD
Matrix
M4
O1
3.1.1 Define client requirements stage
At the “define client requirements” stage (activity box number 1 in Fig. 1), the project context and
interest groups represented by the client are identified, and client requirements are elicited.
The input for this activity is the ‘client’s vision of the facility’ (i.e. statements from the client
about what is required of the proposed facility), which is converted into the following outputs: ‘user
information’, ‘facility use information’, ‘interest groups information’ and the ‘voice of the client’
(consisting of: ‘functions and attributes’ for the facility, ‘project and client details,’ and ‘acquisition
and operation information’). The controls, ‘client organisational factors’ (i.e. overall framework of
the client organisation) and ‘project characteristics’ (i.e. type of facility, and the nature of the project) provide the context for defining client requirements. ‘Elicitation techniques’ (questionnaires,
group consultations, etc.) and the ‘requirements processing team’ are the mechanisms for the ‘define
client requirements’ activity, which is further decomposed into three sub-functions: “define project
context”, “identify client interest groups”, and “elicit client requirements”.
The input, controls, outputs and mechanisms on the “define client requirements” indicate that,
within the context of the client organisation, and the type of project and facility, a client’s vision is
converted (or re-structured) into the various outputs listed, by the requirements processing team,
using various techniques and/or templates for eliciting information.
3.1.2 Analyse client requirements stage
The “analyse client requirements” activity (box number 2 in Fig. 1) deals with the structuring (into
primary, secondary and tertiary requirements) and prioritisation of (tertiary) client requirements
based on the relative importance interest groups place on those requirements.
The inputs for this activity are: ‘functions and attributes’ of the facility, and ‘interest groups information.’ These are converted by the “analyse client requirements” activity into the following outputs: ‘tertiary client requirements (TCRs)’, and ‘relative weights of TCRs’. The controls are: ‘project and client details’, ‘acquisition and operation information’ and ‘project characteristics.’ The
mechanisms for this activity are: the ‘requirements processing team’ and ‘decomposition and decision-making techniques’ of the facility are transformed into primary, secondary and tertiary requirements. The “analyse client requirements” activity is decomposed into three sub-activities: “structure
client requirements”, “prioritise interest groups” and “prioritise tertiary requirements.”
3.1.3 Translate client requirements stage
The “translate client requirements” activity (box number 3 in Fig. 1) deals with the translation of client requirements into design attributes (e.g. ‘gross floor area’, ‘air flow velocity’, etc.). It involves
the generation of design attributes, determination of target values (for design attributes), translation
of client requirements into design attributes, and the prioritisation of design attributes.
The translation process involves associating tertiary client requirements with generated design attributes using the QFD ‘house of quality’ matrix. For example, a client requirement for ‘pleasant
internal environment’ can be associated with any, or a combination, of the following design attributes: ‘air flow velocity’, ‘mean radiant temperature’ and ‘sound pressure levels’. The target values
(e.g. gross floor area of 2500m2) are intended to define a solution space for the design attributes, are
their determination depend on the controls for that activity. For example, the target (minimum or
maximum) value for ‘air flow velocity’ that will contribute to a ‘pleasant indoor environment’ for the
client, will depend on factors which include: the number and categories of users (‘user information’)
and use categories and patterns (‘facility use information).
CIB W55 & W65 Joint Triennial Symposium
Customer Satisfaction : A focus for research & practice
Cape Town : 5-10 September 1999
Editors: Bowen, P. & Hindle, R.
The strength of the relationship between a requirement and a design attribute can be represented
by 9, 3, 1, 0 for strong, medium, weak, and no relationship respectively. This is used, together with
the relative weights of tertiary client requirements, to determine the absolute and relative weights of
each design attribute. The output of the translate requirements activity is solution-neutral specifications. These comprise of the following: design attributes (translations of tertiary client requirements),
relative weights of design attributes (indicating the level of importance) and the target values for design attributes (solution space). The sub-activities which form part of the “translate client requirements” activity are: “generate design attributes,” “determine target values for design attributes”,
“evaluate relationships between tertiary client requirements and design attributes” and “prioritise design attributes.”
3.3 Implementation of the CRPM
Fig. 2 shows the context of the client requirements processing model within the construction process. The CRPM serves as the interface between the client’s business needs and design requirements.
It is performed before design (i.e. concept, scheme and detailed design). The outputs from the client
requirements processing activity can facilitate a multi-disciplinary design team to work collaboratively, and can serve as the basis for adopting a particular procurement/contract strategy.
Client Requirements Processing
Client (demand for facility)
Conceive
Project
Construction industry (supply of facility)
Design & Construction
of Facility
Use & Operate
Facility
Collaborative
Design and
Construction
Statement
of need
Decision
to Build
Design
Requirements
Feedback
Fig. 2: Context for implementing the client requirements processing model
Space restrictions do not permit the inclusion of an example of how the model could be implemented in practice. However, the model has been tested using the requirements for a building project, the results of which are published in reference [14]. Construction industry professionals (including an architect, a civil engineer, a project manager, and a planning and quality control manager)
were also involved in evaluating a prototype software (ClientPro) developed for the model. This
evaluation followed a demonstration of a run of ClientPro using the requirements in the paper-based
application [14]. The general impression of evaluators was that, the prototype is “an excellent tool to
crystallise client requirements into a clearly defined and prioritised document.”
CIB W55 & W65 Joint Triennial Symposium
Customer Satisfaction : A focus for research & practice
Cape Town : 5-10 September 1999
Editors: Bowen, P. & Hindle, R.
4 CRP and current briefing practices
The approach for CRP adopted in the CRPM is different from current practice in the construction
industry where the briefing process is used to document and communicate the objectives of the client
(Table 1) [15-17]. The briefing process is generally considered to provide less than the optimum in
defining and understanding the client’s needs. The problems associated with current briefing practice
include the following:
•
•
•
•
•
•
•
inadequate involvement of all the relevant parties to a project;
insufficient time allocated for briefing;
inadequate consideration of the perspectives of the client body;
inadequate communication between those involved in briefing;
inadequate management of changes in requirements;
lack of a structured methodology;
lack of a framework for proactive association with specific design decisions.
The CRPM however, provides a structured framework which:
•
•
•
•
•
•
•
•
considers the complexities of the client organisation;
helps clients to clarify their vision of the facility to be constructed and ensures that their requirements are clearly defined at an early stage;
facilitates effective management of the dynamic process of describing a proposed facility. A
structured approach, ensures that every aspect is taken into consideration, and minimises bias in
decision-making.
considers, through the requirements processing team, the entire life-cycle of the facility at the
requirements processing stage.
facilitates innovation in formulating design solutions which directly address the client’s needs
(since the requirements are translated into a solution-neutral format);
enhances communication and team working between various members of a project team since the
requirements are clear to all parties involved in the project;
provides a solid foundation for the design, construction and operation of a facility that fully satisfies the client;
provides a mechanism for maintaining the traceability of design and construction decisions to explicit and implicit requirements throughout the project life-cycle.
CIB W55 & W65 Joint Triennial Symposium
Customer Satisfaction : A focus for research & practice
Cape Town : 5-10 September 1999
Editors: Bowen, P. & Hindle, R.
Table 1. Comparison between the CRPM and current briefing practice
CRP with the CRPM
Current briefing practice
CRP is done before conceptual design
Briefing is combined with design
Problem-focused approach whereby requirements are sufficiently defined before
conceptual design starts
Solution-focused approach is usually adopted. The
‘solution’ in the form of sketches/drawings is used to
define the problem
CRP is done by a team (the RPT) which
comprises representatives of the client and
appointed construction professionals
Briefing is usually the responsibility of the architect
and the client representative(s). No deliberate effort to
include other ‘downstream’ professionals (e.g. engineers, contractors, suppliers, etc.) at the briefing stage
Structured approach to the prioritisation of
client requirements using formal decisionmaking techniques
Prioritisation is done through discussions; no formal
approach to prioritisation
5 Conclusion
In this paper, the meaning and need for requirements processing in construction has been discussed.
A methodology for client requirements processing as represented by the client requirements processing model (CRPM) has also been described.
It should be noted that the consideration of all the perspectives represented by the client body is
only possible through the co-operation of the paying client who commissions the design and construction of a facility. It is however in the interest of the client for all these perspectives to be considered early in design, otherwise the operation and use of the facility will be adversely affected. The
use of a requirements processing team (RPT) (separate from a design team) can also allow adequate
time to be spent on defining client requirements. Unlike current practice, where briefing is combined
with design, there will be little pressure on the RPT to meet design deadlines, which is usually the
reason why insufficient time being allowed for briefing. In fact, a number of consulting firms already
offer briefing services to clients which do not involve design, and can therefore utilise the CRPM in
defining the requirements of their clients.
It is evident that, in spite of the concerns raised above, client requirements processing within the
framework of the CRPM facilitates adequate understanding of the requirements of the client, and
therefore provides a solid foundation for client satisfaction.
6 References
1.
2.
3.
BPF (1983) The British Property Federation (BPF) System for the Design of Buildings, British
Property Federation, UK.
Latham, M. (1994) Constructing the Team, Final Report on Joint Review of Procurement and
Contractual Arrangements in the UK Construction Industry, UK.
Kamara, J. M., Anumba, C. J and Evbuomwan, N. F. O. (1997) The Importance of Clients’ Requirements Processing in Concurrent Engineering. Proceedings of the FAIM97 Conference,
June 25-27, University of Teesside, UK, pp. 228-238.
CIB W55 & W65 Joint Triennial Symposium
Customer Satisfaction : A focus for research & practice
Cape Town : 5-10 September 1999
Editors: Bowen, P. & Hindle, R.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
Gause, D. C. and Weinberg, G. M. (1989) Exploring Requirements: Quality Before Design,
Dorset House Publishing, New York.
Kott, A. and Peasant, J. L. (1995) Representation and Management of Requirements: The
RAPID-WS Project. Concurrent Engineering: Research and Applications, Vol. 3, No. 2. pp.
93-106.
Buede, D. M. (1997) Developing Originating Requirements: Defining the Design Decisions.
IEEE Transactions on Aerospace and Electronic Systems, Vol. 33, No. 2. pp. 596-609.
Hill, R. R. (1991) Improving the Requirements Process in Acquisition. Proceedings of the 1991
Acquisition Research Symposium, pp. 389-398.
Cherns, A. B. and Bryant, D. T. (1984) Studying the client’s role in construction management.
Construction Management and Economics, Vol. 2, pp. 177-184.
Mallon, J C and Mulligan, D. E. (1993) Quality Function Deployment- A System for Meeting
Customers’ Needs, Journal of Construction Engineering and Management, Vol. 119, No. 3.
pp. 516-531.
Kamara, J. M., Anumba, C. J. and Evbuomwan, N. F. O. (1998) Tools for Client Requirements
Processing in CLDC, in 2nd International Symposium on Tools and Methods for Concurrent
Engineering, (eds. I. Horvath and A. Taleb-Bendiab), Manchester, UK, 21-23 April, pp. 73-83.
ICE (1996) Creating Value in Engineering, ICE Design and Practice Guides, Thomas Telford,
London.
IDEF (1993), “Integration Definition for Function Modelling (IDEF-0)”, FIPS Publication 183,
National Institute of Standards & Technology, USA.
ISO 6242, Parts 1-3 (1992) Building Construction - Expression of Users’ Requirements, International Standards Organisation, Switzerland.
Kamara, J. M., Anumba, C. J. and Evbuomwan, N. F. O. (1999), “Client Requirements Processing in Construction: A New Approach Using QFD”, Journal of Architectural Engineering,
Vol. 5, No. 1, pp. 8-15.
Newman, R., Jenks, M., Dawson, S. and Bacon, V. (1981) Brief Formulation and the Design of
Buildings: A report of a Pilot Study. Buildings Research Team, Department of Architecture,
Oxford Brookes University.
CIT (1996) Benchmarking Best Practice Report: Briefing and Design, Construct IT Centre of
Excellence, UK.
Kamara, J, M., Anumba, C. J and Evbuomwan, N. F. O. (1996) A Review of Existing Mechanisms for Processing Clients Requirements in the Construction Industry. Technical Report No.
96/1, School of Science & Technology, University of Teesside, Middlesbrough, UK (ISBN: 0
907550 75 4).
CIB W55 & W65 Joint Triennial Symposium
Customer Satisfaction : A focus for research & practice
Cape Town : 5-10 September 1999
Editors: Bowen, P. & Hindle, R.