Classification and Coding systems
In the BC industry, Classification systems saw increased adoption in the fifties. Most prominent example is the Swedish SfB Classification andCoding system, which, in one form or another, has been in use ever since. It has received CIB endorsement and is used in many countries. Recently, the formalisms behind the SfB family of Classifications were standardised in the ISO 12006-2 standard
A more rigorous variant of the original SfB, CBC, was created in Denmark by Bjørn Bindslev , mainly with computer-based support in mind. It used very strict boundaries between classes for that aim. This fits in well with the Merriam-Webster dictionary definition `a systematic arrangement in groups or categories according to established criteria'.
Classification is a grouping of entities according to some external criteria. The grouping will be quite natural, as it is mostly made from a specific viewpoint. Classification is basically a set of boxes (with labels) to sort things into and can be used as a user-friendly view on other kinds of information storages.
Goal of a Classification is to allow information, documents and drawings to be ordered . The level of granularity is quite low, an example is the use of Classifications in naming layers of CAD drawings. Doors and windows can be described in layer 30 for instance; a more granular subdivision is not normally feasible in drawing practice.
Specifications
A building Specification (Dutch: bestekstekst) is usually understood as a central document in a building process. It, traditionally, functions between the design phase and the actual construction phase. It is a contract document, part of the Tender Documents, detailing the agreements made between the Client and the Contractor.
Content of specifications
Essential properties of the Specification text are the formal description, (references to) conditions and regulations, a Classification structure and references to Specification drawings.
- Formal description
- The formal description is build-up from a list of Specification items. Historically, one Specification item often deals with something that has to be budgeted. For such an item for instance the required end-result, required quality and source material is described.
- Conditions
- Conditions (or regulations) give extra information on top of plain technical data (like fire resistance = 30 min). Conditions can be technical or administrative and standard or additional, explained below.
Use of Classification in Specification
One common way of subdividing the textual Specification is subdivision into parts called chapters. Traditionally chapters often correspond with branches of the industry or types of work. All paint work is in one chapter, groundwork in another and doors & windows in a third. This makes it easier to provide a cost estimation by allowing different experts to estimate their part. This kind of subdivision is common in the housing and utility construction sector, traditionally subdivided in specific crafts.
On the down side, much information gets scattered all over the place when there are Specification items that impact more than one kind of work. For instance, an inner wall with masonry, a door and wall finishing might end up in three different chapters .
A second common way of subdivision is by following normal execution patterns. Reason for this is that detailed cost estimations (in the ground/water/road sector) are normally made that way. A good match between cost estimation and Specification text is desired.
The Classification structure used by the Specification is sometimes also used to structure other information. Links, made that way, are however on chapter/section/subsection level, not really on the level of actual Specification units.
Types of Specification
There are--roughly--two kinds of Specifications: result Specifications and functional Specifications. Result Specifications specify in detail what the desired end-result is. Functional Specifications specify functional requirements on certain parts. A functional Specification allows theContractor more decisions.
A mix between result Specifications and functional Specifications is possible. In the Dutch building Specification system it is, for example, normal to see functional requirements for the installation side of a building (heating, ventilation), with the rest of the Specification being a very detailed result description.
Challenges for specifications
Traditional Specifications are static. Changes do occur, but usually meet resistance, which hinders a dynamic connection between the Client's wishes and the eventual finalised project. Contractors are often selected on lowest price and often look for inevitable errors or omissions in the acsingularTender Documents (and more specifically the Specification) for sources of additional work. This contract document--in reaction--is nailed down as much as possible. The concept becomes everybody's boss instead of being an effective agent for collaboration.
Conclusions on specifications
Specifications have a quite central place in the building process, with many information links to other documents which are owned by many different parties (figure 3.1). This makes it an ideal target for research on improved instrumentation, as Specifications naturally include a lot of interaction between various sources of information. Links exist to: Classification systems, (Specification) drawings, laws, regulations, costing applications, etcetera.
 |
In a traditional construction process, where a Specification is a one-off textual document, reasonable simple textual Specifications are adequate. In a dynamic process, though, the Specification is, initially at least, much more a work-in-progress. This dramatically raises the cost of having to extract the Specification's information manually, should the Specification still be purely text-based
STABU: specification system
As an example of a Specification system, the STABU system is discussed. This originally paper-based system was given a renewed basis in 1991 with a fully database-based implementation. It successfully penetrated the Dutch Building industry and remains in use till this date.
The fact that an almost 15 year old computer-based system still has a 100% market share testifies to the quality of the original design. Implemented as a relational database, it consists on the one hand of a chapter structure, ordered by kind of work (masonry, painting). On the other hand it consists of Specification items, which are a combination of materials, activities and result descriptions. Specification items have properties (attributes) attached to them. See figure 3.3.
 |