In Part 1 of this article, we discussed the general considerations that influence the setup of room data sheets. In this second part, we take a closer look at the specific types of information that can be included.

We will cover ten categories:

1. Functional descriptions
2. Reference images and diagrams
3. Classifications and IDs
4. Spatial requirements
5. Functional requirements
6. Indoor climate requirements
7. Adjacency requirements
8. Elements
9. Equipment

For each category, we will discuss its relevance and recommended use.

(1) Functional description

The starting point for a room data sheet is often a short description of the space’s functional purpose. Such a description should not define requirements, as these are better captured individually and assigned their own requirement IDs. Instead, it should explain the intended use of the space.

An elaborate description is not necessary for every room. If the room’s name is self-explanatory, such as Meeting room (12 persons), an extensive text is unlikely to add value unless you want something special (e.g. a highly formal boardroom or an informal collaboration space). The situation is different, however, for specialist or non-standard spaces.

Laboratory projects, in particular, are often characterised by highly specialised room types that may be unfamiliar to the average architect (e.g. H₂ lab, XRPD lab, PSD lab). In such cases, a functional description can be highly valuable in helping the design team understand the intended use of the space.

Recommendations

• Add descriptions primarily for non-standard or specialist spaces;
• Keep descriptions short;
• Focus on explaining usability rather than design solutions;
• Avoid embedding actual requirements in descriptive text.

(2) Reference images/diagrams

In addition to functional description, it can be useful to include reference images or diagrams in a room data sheet. The purpose of such images should not be to prescribe a design solution, but rather to communicate intended usability, atmosphere or layout principles.

Recommendations

• Be clear about what the image is intended to communicate;
• Use diagrammatic or conceptual images rather than fully designed solutions;
• Avoid including dimensions in images as those can better be captured as spatial requirements (see further down).

(3) Classifications and IDs

In larger projects, room data sheets will typically include identification and classification information.

Identification means assigning a unique name or code to a space so it can be distinguished from other spaces.

Classification means assigning a standardized category, allowing spaces to be grouped and filtered according to their function or properties.

In some projects also geographic room numbers are added, indicating floor levels or building parts. However, because such information is often design-dependent, it is usually more effective to manage such geographic information in the BIM model.

Recommendations

• Keep numbering and classification systems as simple as possible;
• Ensure that the design team uses the same identification data in the BIM model;
• Avoid using manually managed room numbers for data exchanges with other applications. Instead, use software-generated IDs for this purpose.

(4) Spatial requirements

Spatial requirements define the minimum size and capacity of a space and form the basis for the building’s spatial design. Typical spatial requirements include:

• Usable floor area;
• Occupancy or capacity;
• Minimum clear height;
• Minimum clear width;
• Spatial proportions (length : width).

Please note that not every requirement is relevant for every space type. For corridors, for example, minimum width may be relevant in relation to accessibility, but it will be less relevant for other spaces such as classrooms where you are more likely to ask for a particular spatial proportion (e.g. a 1:1 length-to-width ratio).

Where possible, spatial requirements should be quantitative and machine-readable. This makes them easier to verify and reuse in BIM workflows and design automation processes.

Recommendations

• Make geometric requirements quantitative where possible;
• Prefer minimum or maximum values over exact dimensions;
• Use standardized units of measure and terminology, preferably in line with those used in the BIM model.

(5) Functional requirements

Functional requirements relate directly to the usability of a space, but cannot yet be linked to a specific design solution. Typical examples include:

• Zoning requirements (e.g. public / semi-public / restricted access);
• Flexibility requirements (e.g. defining the multifunctionality of rooms);
• Layout requirements (e.g. possibility to create different layouts in one space);
• Visual privacy (e.g. degree to which visual control should be possible)
• Accessibility (i.e. usability of the space for wheelchair users);
• Lockability (i.e. should a space be lockable, from which side);

What functional requirements are relevant will depend heavily on the type of project and the operational processes involved. Layout requirements will, for example, be relevant to classrooms as they should support different kinds of teaching. Accessibility will be critical for patient rooms as it should be possible to get easily in and out with big hospital beds.

Recommendations

• Focus on functional intent rather than technical solutions;
• Where possible, use picklists for requirement values (e.g. yes/no, public/semi-public) to improve consistency. See example below;
• Structure requirements in a way that supports filtering, querying and verification.

(6) Indoor climate

The term indoor climate refers to the invisible, yet critical environmental conditions in a room. Requirements are generally categorized in four groups:

• Thermal comfort (i.e. temperature levels);
• Visual comfort (i.e. lighting levels, daylight levels);
• Acoustic comfort (i.e. noise levels, reverb times);
• Indoor air quality (i.e. ventilation rates).

Some projects may additionally include requirements concerning odor and vibration as a part of indoor climate.

There are roughly two ways of defining indoor climate requirements in room data sheets.

One approach is to refer to predefined standards or classes. For thermal comfort, there is e.g. an ISO standard that differentiates between a comfort class A, B and C. Using such classifications keeps your room data sheets relatively compact.

The alternative is to define all individual performance requirements explicitly, such as temperature ranges, air velocity, reverberation times, daylight factors or CO₂ concentrations. While this approach requires more effort, and results in lots of requirements, it also creates more explicit requirements that allow for systematic compliance checking and BIM integrations.

Recommendations

• Align terminology, classifications and units with recognised standards;
• Structure requirements so that design proposals can easily be checked for compliance.

(7) Adjacencies

Adjacency requirements describe how spaces should relate spatially to one another. A tea kitchen may need to be located close to an office area. A storage room may need direct access to a loading area.

Most room data sheets distinguish between:

• Proximity requirements;
• Direct spatial connections;
• Visual connections / sight lines;
• Separation requirements.

In some cases, adjacency requirements may specify maximum distances.

Recommendations

• Focus on operational logic and workflows;
• Also visualize adjacencies in diagrams;
• Avoid unnecessary complexity in adjacency matrices.

 

(8) Elements

Spaces are formed by many different building elements, each potentially carrying their own requirements.

A typical categorization of the elements is:

• Exterior construction (e.g. windows, exterior doors, shading)
• Interior construction (e.g. partitions, interior doors)
• Finishes (e.g. floor finishes, wall finishes, and ceiling finishes)
• Electrical services (e.g. data and power outlets, security cameras)
• Mechanical services (e.g. water outlets, gas outlets, drainage)
• Fixed inventory (e.g. toilets, sinks, counters)
• Furniture (e.g. tables, chairs, cabinets)

All these elements may themselves also carry performance requirements. A floor finish, for example, may come with requirements concerning slip resistance, water resistance, chemical resistance and a particular anti-static performance (see example below).

To prevent room data sheets from becoming overloaded, it is advisable to define sch requirements not in the room data sheet itself, but in separate data sheets per element type. These can then be linked to the rooms, stating for example that a room should get floor finish type A or B.

Recommendations

• Group elements into logical categories, preferably following a standard (e.g. Uniclass, Masterformat, CCI);
• Create dedicated data sheets for different element types;
• Link element types to spaces instead of duplicating data on the room data sheets.

(9) Equipment

Specifying the equipment that users will use in a room can be relevant if that equipment comes with specific requirements. Again especially in labs and hospitals, it can be that equipment comes with specialist demands concerning dimensions, power supply, ventilation, cooling and vibrations.

Just like with the elements, it can be useful to create a dedicated list of equipment types and to give these their own data sheets, specifying properties such as height, weight, power needs and heat production.

Recommendations

• Focus on equipment with building-related implications;
• Create dedicated data sheets per equipment type;
• Capture relevant technical properties such as power needs, heat output or weight.

Conclusion

This article’s title is: Room data sheets: what to include, what not?

The somewhat predictable answer is: it depends. As discussed in the first part of the article, the answer depends on the type of project, the project phase and the procurement model being used. Most importantly, it depends on who the room data sheets are intended for and what those people should use them for.

In the second part of the article, we discussed the many different kinds of requirements that can be captured on a room data sheet—ranging from room sizes to reverb times and ventilation rates.

As becomes clear, there can be quite a lot of information on a room data sheet. The challenge is therefore not necessarily to minimize information, but to structure it in such a way that it remains clear, actionable and manageable.

Several general guidelines can help:

• Categorize requirements so that different stakeholders can easily find the information relevant to them;
• Avoid long and ambiguous texts. Keep requirements clear, specific and quantitative where possible;
• Focus on functional performance requirements rather than predefined design solutions;
• Structure information in a recognizable way, preferably using standards like Uniclass, MasterFormat and the like;
• Use digital requirements management tools, such as BriefBuilder, to manage large quantities of room data;
• Where possible, parameterise requirements so they can be integrated with BIM models and other digital workflows.

When following these principles, room data sheets become far more than static documents. They become actionable project information that can support briefing, BIM integration, and systematic verification throughout the entire project, thereby helping project teams create buildings that support their intended use.

Good to know: BriefBuilder provides ready-to-use, fully customizable templates for room data sheets. Click here for a free trial.