One of the striking features of many briefs as documents is their lack of explicit structure. Normally they consist of a number of thematic parts, each representing a different aspect or discipline, but what happens inside each part can be arbitrary in terms of both content and structure. Briefs can even be haphazard collections of ideas, requirements and suggestions, sometimes even formulated in ways that cause confusion or invite misinterpretation. Important goals or constraints may be specified literally parenthetically in the description of a secondary subject in a way that conflicts with other parts of the brief (e.g., service types and capacities not feasible within the given budget). Even in the best briefs there are no explicit guarantees for completeness, coherence, or consistency.
Such problems are largely due to the way a brief is compiled by various contributors, each focusing on particular aspects from the viewpoint of one discipline or other party – a common occurrence in architecture and building, usually referred to as “fragmentation in the building industry.” 1
It is also inherent in the form briefs usually assume: descriptive texts incorporating various kinds of lists, tables, and diagrams. Even textbooks that give valuable advice on briefing in architecture tend to think of the brief as a textual report. However, treating the brief as a text is ill-advised, especially in the computer era. By this I do not suggest that any form of computerization might work. Even if you use of text processors for compiling briefs, the result–digital or analogue–is one-dimensional, weakly structured and hence difficult to evaluate and safeguard, as well as open to misinterpretation and abuse. Such a brief offers few possibilities for combating conflicts, inconsistencies, or redundancy.
Complex, interconnected documents such as briefs ask for sharper tools. As far as I am concerned the brief is an information system consisting primarily of lists of related items, each of which must be specified and evaluated in a precise and transparent manner. When analysing a brief by itself I want to be able to have overview of its goals and requirements, the possibility to zoom in on parts or details and then zoom out again, as well as the ability to link items and their properties. Establishing connections between information items is also important when comparing the brief to a design. I want to be able to identify all parts and aspects of the design that are relevant to particular requirements and vice versa, preferably in a systematic manner based on unambiguous spatial and performance criteria and characteristics.
To do all those things I need structure in the brief and means of implementing this structure in a flexible, adaptable manner that meets the requirements of a dynamic briefing process. The structure is essentially simple: All one has to do is distinguish between different kinds of information present in the brief (goals, constraints, requirements, etc.) and provide a full and meaningful description for each kind. As for the means for implementing this structure, they should perform the following two functions:
- •
Storage: Support registration of brief information in a way that ensures consistency and facilitates recognition of the structure and relationships between different items.
- •
Retrieval: Support various modes of accessing stored information, from highly specific queries to browsing, from different points of view corresponding to different interests and uses.