Abstract
The article brings together the subjects of briefing and Building Information Modelling. It considers the brief as information source for Building Information Modelling and Building Information Modelling as an environment for automating brief-related analysis and guidance. The approach is characterized by feedforward and feedback, incorporation of constraints from the brief in Building Information Modelling, connection of briefing goals to performance analysis and correlation of requirements in the brief to Building Information Modelling object properties and relations. To test the approach, 10 briefs are parsed into goals, constraints and requirements, which are then considered for integration in Building Information Modelling. As the majority of these items can become part of a model and subject to automated analyses, integration of briefing in Building Information Modelling is proposed as a viable option that can improve design and briefing performance but also signals significant changes to briefing.
Design and information
Building Information Modelling (BIM) promises integration of information and information processing for the whole of Architecture, Engineering, Construction and Operation (AECO) by combining geometric and non-geometric information in coherent and comprehensive models that accommodate all aspects and actors. By doing so, it unites all AECO processes on the basis of their interaction with the model. This ambition is combined with a willingness to cover all stages in the lifecycle of a building and support transitions between stages. However, in most publications and real-life projects, BIM appears to commence in the design stage (often in late design) and proceed to construction. These two stages are critical but hardly cover all activities and interests of AECO. The use stage, where the bulk of these occurs, has only recently emerged as an application area for BIM.1–4 This restriction in the lifecycle is not due to inherent limitations of BIM but arguably follows an established bias: that design information is primarily produced by design actions, in particular those pertaining to the form of a building (including structure). In BIM, this suggests that a geometric model emerges out of primarily tacit knowledge and step-by-step not only solves the problems of clients and users but also accommodates additional information from all actors and aspects.
Such a view underestimates and neglects information that predates the design, placing too much emphasis on the tacitness of design knowledge, while designs may be explicitly based on overt information such as precedents and types. A project does not start with sketches on the back of an envelope but with preparatory activities resulting into rather specific instructions. 5 Unfortunately, not all instructions receive credit in design. Many are relegated to the background or even considered a nuisance. For example, site information cannot be ignored, as it has direct bearing on the form of a building. The geometry of the site is often included in model setup, possibly together with some interpretation or analysis, for example, grids that align to existing spatial patterns. However, planning regulations are widely ignored, even though expressing them as spatial constraints often returns the permissible building envelope. 6 Rather than departing from the form of a design, BIM should collect all available relevant information and organize it coherently, even in the absence of geometry.
Briefing
One source of information that predates and determines the design but nevertheless often remains neglected is the brief. This is partly due to old prejudices concerning both the brief and a building’s lifecycle. Traditionally, briefing is treated as a distinct sub-stage in initiative, where accommodation needs are analysed to produce a specification for action.7,8 In many cases, however, the resulting brief is a basic, dry list of spatial requirements or a vague wish list, which may be considered limiting, incomplete or uncertain and therefore has to be re-interpreted or even discarded in design.9,10
Still, information contained in a brief has value because it may be absent from other documents and processes. Even when a design is primarily motivated by the architects’ ambitions, having an adequate picture of use patterns and client needs remains important. Moreover, briefing information not only predates design but also reappears in other lifecycle stages.11,12 In the initiative stage, the problem is examined from all relevant perspectives towards specifications of what should be designed and constructed. These specifications are a main source of criteria for the analysis and guidance of products and processes in the design stage. 8 Being concerned with use, the content of the brief naturally re-emerges in the use stage. If use patterns and building performance do not coincide with briefing specifications, this may indicate significant differences from the original client’s needs or wishes: deviation from the brief in design, changes in the buildings’ uses or unanticipated social or technological developments – issues that require attention and may lead to new initiatives and briefs.
The recurrence of briefing information in the lifecycle has not gone unnoticed. Recent approaches have come to consider briefing as a process of interaction between stakeholders towards an alignment that underlies coordinated action.11,13 According to such approaches, briefing is not limited to particular stages but occurs continually throughout the lifecycle, with new possibilities for refinement 14 and in response to frequent changes in objectives. 15 Consequently, the brief becomes a dynamic information system that contains input for and output from various actions and interactions.7,12,16
BIM and briefing
The new perspectives on briefing agree with the principles and ambitions of BIM concerning a central information repository and the function of this repository as interaction hub for all actors. 7 Both acknowledge the interconnectedness of product and process, stress the importance of integration for coherence and consistency and accept continuity by supporting lifecycle considerations and facilitating transitions between stages. We can therefore consider BIM capable of supporting new approaches to briefing:
BIM allows for storage and retrieval of briefing information in a comprehensive, shared central model (integration). The brief provides information that improves accuracy in design analyses 17 and makes such analyses meaningful to clients and users.
As a consequence of integration, BIM accommodates various interactions between actors with transparency and reliability: briefing and design take place together in BIM, in a way accessible also to non-technical stakeholders.18–20
BIM allows for dynamic, recursive development of briefing information in the lifecycle. This promotes continuity between stages and supports sustained development of both brief and design. 9
In the framework of continuity, BIM facilitates feedback: propagation of results of comparisons between brief and design, 21 so as to evaluate design conformance and performance, as well as refine and improve the brief.
Equally important is support for feedforward, so as to anticipate problems. BIM offers a responsive background where decisions already taken can be incorporated as starting point for new actions.
Briefing in various lifecycle stages.
However, there is also a dark side to BIM as a unifying methodology and technology that becomes apparent when considered from the perspective of briefing: integration may undermine brief coherence. In BIM, the source of information often seems of secondary importance. Even in work focusing on relevant issues like spatial relations or functional performance,22,23 the source and meaning of information appear less significant than its incorporation in formalisms for narrow design activities. Derivation can be sketchy under terms like ‘client specifications’ and ‘specialized requirements’ or ‘functional design constraints’. This suggests disinterest in briefing (indicative of old designer biases) and reduces brief coherence and custodianship possibilities for stakeholders like clients and users.
The problem derives from both briefing approaches, which emphasize the process and pay little attention to the information processed, and computerization approaches, which remain fixated on conventional practices. In briefing approaches, interaction and communication between stakeholders and actors is a priority, enriching briefing with new issues like inclusiveness.11,24–26 However, the information handled in interaction and communication is seldom considered in detail. In the few cases where attention is paid to the structure of briefs, conclusions and recommendations include little more than acknowledgements of the value of structure. Rather than specific structures, openness and flexibility are advocated, so as to encourage creativity.10,13,27
Computerization approaches appear to suffer from adherence to conventional practices like the distinction between technical and spatial aspects in briefing. Among the growing number of commercial briefing software that connects to BIM, there are requirement specification tools that mostly predate BIM.28–30 Through user-friendly checklists they connect to background collections of specifications, usually from manufacturers’ data, to produce conventional documents (textual reports). As these specifications refer to building elements, the checklists and connections can also link to BIM. Other programmes, often also predating BIM, focus on spatial aspects of briefing.31–33 These create room overviews and bubble diagrams or elementary layouts (in the tradition of space allocation). Connections to BIM involve importing tables and schematic representations or establishing links with model elements. Similar attempts have been developing from within BIM, using parametric software to generate schematic spaces from imported tables and let users configure them into layouts that are then translated into models. 34
The picture that emerges is one of silos defined by existing practices and specializations. Existing tools are less than generous with their connections to BIM. Most preserve their standalone character, merely allowing content to be imported or linked to BIM. Their information generally remains locked in databases hidden in proprietary software, often replicating data that exist in a model and impeding connections between different kinds of information. Despite BIM, briefing remains accommodated in parallel processes and parallel information systems.
Comprehensive attempts at briefing in BIM tend to focus on the extension of standards to accommodate relevant data and on providing appropriate user interfaces.35,36 However, adherence to the structure of standards often results into less attention for the structure and meaning of information processing. Moreover, standards often have the unfortunate effect of stressing disciplines and stages rather than integration and continuity. 37 This article proposes that one should depart from briefing information processing, with BIM as an implementation environment, towards a comprehensive solution of domain needs. The first step is a clear methodology of parsing briefs into discrete information items of specific types.
Goals, constraints and requirements
A reason why briefing can be troublesome is the compound character of the traditional brief: it is a document compiled in a loose manner by various authors, resulting into redundancy, conflict and confusion.15,38,39 Still, at closer inspection, and despite terminological variation,11,40–43 one can argue that briefs comprise just three main information types:10,16
Goals. General or abstract, these often relate to performance aspects like pedestrian circulation, sustainability or fire safety. As a result, they require extensive analyses of the whole design.
Constraints. Guiding or limiting conditions, ranging from preferred building height to budget allocations, constraints derive from contextual conditions such as the site or are determined by client preferences. They can be quantitative or qualitative (e.g. morphological guidelines).
Requirements. Normally the bulk of a brief, these refer to the content of the building: the activities to be accommodated there and what they require. In most briefs, requirements are described spatially, as characteristics of spaces that accommodate the activities, from geometric and relational ones (e.g. floor area and proximity) to behaviour and performance (e.g. light intensity).
There are strong links between these categories. Requirements may relate to goals, for example, the floor area for each activity may be modified by the desire to have a luxurious environment or reversely to economize space. Similarly, constraints on the width of a door may derive from fire safety or accessibility goals. In many briefs, goals are analysed into constraints and requirements that are linked to discrete parts of a design and evaluated locally. This is an economical manner of ensuring conformance: if the width of a door is larger enough, egress should be fast enough even under the strenuous conditions of a fire. The downside is that local evaluation may say very little about overall performance.
Considering the brief as a collection of goals, constraints and requirements solve conceptual and operational problems. In information terms, it allows accommodation of a brief in a multi-table database, where each table caters for a different information type. 16 Tables describing activities contain all requirements (spatial and technical) in distinct fields, making each record a comprehensive specification of an activity. Relations between tables make explicit the connections between goals, constraints and requirements. The database also supports analyses of the brief before designing, for example, concerning completeness and consistency in the specification of activities and requirements, or through spatial interpretations that return abstract representations like access graphs, which can be compared to design representations. 16
The brief as an information system is seldom mentioned in academic research44,45 but the implementation of briefs in databases is common practice: practically all briefing tools and techniques in the previous section28–33,35 depart from, rely on or produce databases, for example, of rooms. However, many of these remain in the background of briefing and design. With the segmentation of briefing into parallel activities, each database remains unconnected to the others. The proposed approach brings resources together and integrates them in BIM in a way that supports utility and coherence.
Briefing information in BIM
The approach presented here derives from earlier research into the computerization of design information, decision support and analysis.46–48 Following the above principles, the brief was consolidated in a relational database, which was dynamically linked to design representations in computer-aided design (CAD) in order compare designs to briefs and provide feedback. The advent of BIM meant more than transition to a new technology. 16
Requirements
The transition from a linked-data implementation (DBMS/CAD-based) to BIM transforms the brief from independent system to information integrated in a model. As the structure of BIM is oriented towards the definition of the building elements and spaces, these entities are an obvious starting point. Activities specified in a brief are directly connected to spaces (as activity containers), to the extent that in briefing activities are customarily expressed as spaces (e.g. ‘office’ instead of detailed and probably trivial descriptions of office activities). Requirements on activities can be directly incorporated in a model as custom parameters of spaces (each parameter corresponding to a field in the database implementation). These often have a one-to-one correspondence with built-in properties. For instance, the floor area required for an activity can be compared directly with the area property of the space (Figure 2). By making comparisons between required and designed permanent, one can monitor a large number of conformance issues. 49
Comparison between required and designed floor area in Revit.
Performance requirements can also be attached to spaces as custom parameters. Many can be compared to relations with bounding building elements. For example, daylighting in Dutch regulations is evaluated by the ratio of window to floor surface. A window schedule can be used to identify the existence of windows among the bounding elements of each space and calculate the required ratio. Other requirements, for example, on sound insulation, have to be propagated from spaces to bounding building elements and be checked against their sound insulation properties.
Constraints
Constraints have become popular with parameterization, a long-held ambition in CAD: not merely a clever way of connecting parts but also a method for automating design.50,51 Constraints add scope and purpose to parameterization by defining conditions that must be satisfied, for example, ranges of acceptable values. In BIM, it is through such constraints that a door behaves intelligently and sticks to its wall. Requirements can provide constraints on the behaviour of spaces concerning their form and relations to other objects: awareness by a space of its briefing requirements makes it aware of aims and limitations (e.g. its area size), adds meaning to links with its context (e.g. adjacency with a window means daylighting) and triggers feedback or automatic correction.52,53 Such constraints can be propagated along default parametric networks in a model, as with acoustic insulation: a required performance of the space becomes constraint on the properties of walls and influences choices like the acceptability of wall types on the basis of acoustic properties.
A brief usually also contains explicit constraints, such as the total number of storeys and the positioning of activities on one or other side of the building. These too can benefit from parametric networks in a model. For example, the required distance from a site boundary can be applied to elements in a mass study and propagated from these to all building elements in façades. Alternatively, such constraints can be included in the type definition of relevant objects.
Relations between activities, for example, required proximity, can also be expressed as constraints, either directly or indirectly. For example, adjacency between activities can be expressed by a maximum distance between spaces (equal to the maximal thickness of interior walls). Indirect constraints involve mediating objects or structures: direct access between two spaces means that there is at least one door adjacent to both, while belongingness to a group can be expressed as direct access of all spaces in the group to the same circulation space.
A development that increases BIM’s potential for constraints is the growing popularity of parametric extensions. 54 These provide programming facilities that enrich editors, especially concerning the development and management of constraint propagation networks. With respect to briefing, this can lead to advanced behaviours based on multi-criteria evaluation 55 that take into account different, possibly conflicting constraints and return feedback to the design or brief, or even automatic adjustments.
Goals
Goals are well served by advanced analyses using either rule-based systems or simulations of behaviour and performance – a promising area of BIM research and development.52,56–62 A complementary option has already been mentioned: goals may be expressed as constraints or requirements on spaces or building elements. Consequently, goals relate to the whole building or its major parts (e.g. storeys), where analyses address total behaviour and performance, and to critical elements, where relevant properties and relations are considered in detail. In conceptual terms, goals can be attached to a model at the highest abstraction levels, as parameters of the whole building and its major parts. Parameterization and inheritance networks between these levels and discrete objects in the model link goals to local constraints and requirements.
Feedforward and feedback
The integration of briefing information is a prerequisite to deploying briefing processes in BIM. A common misconception is that connections between brief and design start only once a design exists, that is, after there are design objects on which we can attach goals, constraints and requirements. However, it is also possible to transfer briefing information to BIM before starting to design. This amounts to feedforward: establishing mechanisms that not only describe a desired state but also guide towards it by anticipating decisions and conflicts. An example of feedforward is the definition of the permissible building envelope on the basis of planning constraints. 6 These can be augmented with brief constraints on the form and arrangement of the building (e.g. number of storeys or dimensioning with respect to existing objects). The resulting schematic representations (Figure 3) serve as a responsive background to designing; informing designers in a visual, direct manner; and guiding or analysing relevant decisions.
Feedforward: transfer of constraints to the setup of a model.
At the level of requirements, feedforward amounts to anticipating the existence of the spaces that will accommodate the activities. To achieve this, activities are used to predefine spatial objects that include all requirements as required properties.16,21 In practical terms, rather than creating spaces and then adding to them requirements from the brief, the spaces entered in the model are selected from an activities list (Figure 4) so that spaces correspond directly to the brief from scratch.
Feedforward: entering a space from a predefined activities list in Revit.
Reactions following comparisons between brief and design amount to feedback. 63 Feedback to the design generally involves re-sizing and re-positioning existing objects or adding new ones (e.g. a new door to provide direct access between two spaces). BIM offers extensive support for modifications to objects in a model, as well as for propagating the consequences of these modifications. For example, if a particular door has to be widened to allow for better access, one may decide to adapt all similar doors and modify the door type rather than the instance. The brief can be similarly modified: if the specifications of an office space (e.g. lighting requirements) are modified to match a good suggestion in the design, one may decide to apply the change to all similar activities. The definition of spatial objects on the basis of activities in feedforward makes such changes easy and consistent.
Testing
The proposed approach can be evaluated by whether all information in a brief can be included in a model. To that end, 10 briefs chosen at random were parsed into discrete information items. As a rule of thumb, the more the items that could be integrated in BIM, the stronger the case for the approach:
Activities. In most briefs, activities are specified not only in descriptions of the building and its uses but also in tables that summarize activities and requirements. The number of activities reported for each brief is the union of activities in the main text and such tables. The suitability of activities described in the brief for inclusion in a model is judged by the ability to define space types in feedforward.
Requirements. In many briefs, many requirements may be expressed independently of specific activities, for example, as general guidelines or as technical specifications on building elements. The reported numbers of requirements refer only to such items, as these have to be processed separately. Suitability for integration in BIM is judged by whether a requirement can be expressed as a custom parameter of a space type.
Constraints. These have two sources: relations between activities and explicit constraints, ranging from budgetary ceilings to specifications of form. Relations between activities may be expressed explicitly or implicitly: in descriptions of uses, through the subdivision of the brief text or the activities table. Explicit constraints can be found in many parts of the brief, including technical appendices. Concerning integration in BIM, relations generally refer to second-order data, such as those in schedules. The integration of explicit constraints is judged by the feasibility of adding them to a model so as to enrich the behaviour of an object or guide design decisions by determining choice bandwidths.
Goals. The integration of goals is judged by the feasibility of relevant automated analyses. The ability of a model to supply complete and specific information that substantiates expert interpretation and value judgement is also taken into account. No goals were translated into constraints or requirements, unless this had already taken place in the brief.
Two briefs are discussed in some detail to explain how the items were extracted and interpreted.
Brief A: town hall
The brief is for a town hall in a new municipality in the Netherlands (administrative fusion of several villages). The document is largely textual, with a couple of tables. It is compact, leaving many options open to the designer. Technical aspects are treated abstractly, as they are deemed adequately covered by applicable building codes.
A typical example of how activities are described is the administration wing, which comprises offices for the mayor and the councillors (support staff and facilities are grouped separately): The administration is housed in a separate wing, so as to facilitate internal communication. The mayor’s office should reflect the status of its occupant and be suitable for small meetings. The office should be preferably not on the ground floor, secure from prying eyes or cameras. It should also be usable as crisis management centre.
Later on, office design in general is described: The municipality has specific demands concerning office design and occupation. Office occupancy should be 100%, with hot-desking applicable, unless the activity dictates otherwise. Concerning office types, the building should combine group offices …, cellular offices …, meeting rooms … and privacy pods …
In the tables that follow, the administrative wing is defined as offices for councillors (six workstations) and for the mayor (one workstation) and a waiting area (for twenty persons). Floor areas for each activity are not specified. Instead, a gross total area for the whole building and the total number of workplaces per activity group are given.
From the above, it is inferred that the mayor and the councillors have cellular, personal offices and that the mayor’s office also includes a meeting area. In the absence of area specifications, the required size of these offices has to be derived from office layouts, which can be done as a preliminary to designing. Other requirements concerning daylighting and artificial lighting, air quality and so on are drawn from applicable building codes. Consequently, three space types can be defined in feedforward, one of the mayor’s office, one for the six councillor offices and one for the waiting area, all belonging to the administration group.
Two constraints are also present. The first is the proximity of the seven offices, which can be translated into direct access from the common waiting area. Feedback can be given through a door schedule that warns if not all offices share a connecting door with the waiting area. The second constraint is the positioning of the mayor’s office on a floor other than the ground one. Given the size of the administrative wing, this is assumed to apply to all seven activities. The constraint can be built in the definition of the three space types as a warning or even disqualification when an instance is placed on a level lower than, for example, 2 m.
Goals in the brief include accessibility and sustainability, which can be evaluated through simulations based on the model, but also three others that are abstract or symbolic: green character, expression of the village fusion and reflection of a culture of openness and cooperation. These involve value judgements that receive no particular support from BIM.
In summary, the brief contains the following:
Activities: 36;
Requirements: 15;
Constraints: 11;
Goals: 2 requiring design analysis; 3 abstract.
Brief B: town hall
This is another town hall brief for a new municipality in the Netherlands, also product of administrative fusion. The main differences are that it is for extension of an existing town hall and that it is more conventional and specific, including extensive technical requirements.
With the exception of administration and public services, all office activities form a single back office, consisting of departments like Public Works or Taxation. Each department comprises a number of teams; in Public Works, these are Infrastructure, Green and Management. In this brief too, hot-desking is the norm. Office types are specified in some detail: standard workstations (for hot-desking), privacy pods, touchdown workstations, conference rooms, informal collaboration rooms and project group rooms. Qualitative specifications attached to the offices are as follows: ‘Sustainable and green; comfortable but sober; business-like; stimulating cooperation; transparent, without physical obstacles to human contact; pleasant working conditions’. The required area for a typical workstation is calculated analytically to 9 m 2 . The number of workstations is not given but the total gross area of the back office is specified.
Circulation is considered in a separate chapter: ‘During working hours, staff should be able to enter the building through a separate staff entrance … close to the bicycle parking and staff douches’. Building performance is the subject of another chapter, where precise values for thermal comfort, air quality, relative humidity, visual and acoustic comfort, room acoustics and sound insulation are given for all activities. Yet another chapter specifies architectural quality, including flexibility (movable internal partitions with easy connections to the external walls, common grid sizes for infill subsystems, integration of services in ceilings, possibilities for various space sizes), the structure of the façade (ratio of transparent to opaque elements with respect to style and energy, sun control, etc.), the separation of load-bearing from infill elements, and required finishings of floors, walls and ceilings with respect to maintenance, visibility, health and safety.
In one appendix, activities and workstations are described again, this time with respect to internal work processes (how much time is allocated to different kinds of work), which are explained in detail (e.g. kinds of communication). The various office types are also explained (e.g. ‘Privacy pod: workstation for work that requires quiet and concentration, like reading, writing and computer work – not meetings or telephone conversations’). The types are also connected to the internal work processes (e.g. how much work time is expected to be in privacy pods). The same appendix specifies the number of required workstations for the whole back office and the expected atmosphere: Upon entering the offices, staff should encounter a space with living-room-like atmosphere. Here they can take a beverage, collect their stuff, meet colleagues and start or conclude the working day in a pleasant manner. … Clustering of workstations in groups of four, six and eight; strong preference for four and six. … Interior design not too stiff or boring. It could be playful, e.g. by using novel kinds of workstations, … yet remain business-like.
Another appendix contains the customary analytical table of activities, together with their main spatial requirements.
Integrating all this information into space types specifying activities is a substantial yet rewarding task. It resolves questions of internal consistency, both quantitative (the number of activities and the floor area required for each in relation to workstation numbers, work process percentages and gross area totals) and qualitative (architectural quality, character and office types). Despite differences in terminology between the various descriptions of activities, the quantitative aspects tally. These differences create more problems with qualitative aspects, for example, the character of offices (sober in one place, playful in another) and the office types, which vary between the main text and the appendices.
As for constraints, circulation and the clear organization into departments and teams return proximity constraints, which can be translated into indirect access to the same communal spaces. Flexibility involves constraints on the positioning of building elements in relation to each other and various grids. These can be part of feedforward but those from architectural quality, for example, the composition of transparent and opaque parts in the façade, are better served by feedback (e.g. schedules that warn if the prescribed ratios are exceeded). The brief contains another 32 constraints on the size of access elements, preservation of the existing building and the capacities of structural and service systems. These too can be included in feedforward or feedback devices. Finally, the goals include three that require analyses on the basis of the model (energy consumption, circulation and fire safety) and five that involve value judgement (e.g. pleasant environment, conducive to cooperation), one of which could benefit from the completeness of a model (flexibility).
Brief analyses summary
Table 1 summarizes the findings of the brief analyses. The totals are calculated strictly: items that could only benefit from the comprehensiveness and detail of BIM are considered to be unsupported.
Summary of information items per brief.
BIM: Building Information Modelling.
Number includes an item that cannot be directly supported by the proposed approach.
The numbers appear to favour the proposed approach, with less than 10 items unsupported in all but one briefs. Unsupported items are primarily abstract goals that involve value judgement. The numbers also illustrate that the bulk of information concerns activities, their requirements and grouping or positional constraints. Finally, the analyses show that even good briefs may suffer from structural problems like redundancy and incompleteness. Integration in BIM (or a database) enforces a higher level of coherence and consistency.
Discussion
In contrast to earlier approaches to linking briefs to designs, BIM promotes complete integration: the brief becomes part of the model, as much as the design. This presents opportunities for feedforward and feedback, which add intelligence to model elements and form a responsive background to designing. Integration of briefing in BIM also poses some key questions: Should the brief be treated by specialists who integrate contributions from various disciplines? Or should it be compiled in a manner that appears to agree more with BIM: each discipline integrates its own information in a model and retains custodianship? 21 The latter option facilitates continuous and transparent involvement of these disciplines but also entails the danger of monodisciplinary silos. 64 Protection from this could be given by brief compilers who could have a coordinating role for the representation of client and use needs or demands, 65 similar to process or information managers.
At a practical level, as the analyses of the 10 briefs suggest, most briefing information can be integrated in a model, with extensive possibilities for feedforward and feedback. While fundamental questions of, for example, aesthetics cannot be answered by design computing yet, equally significant issues like fire safety can be analysed and evaluated in BIM in ways that relieve designers from many secondary tasks.
Footnotes
Declaration of conflicting interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship and/or publication of this article.
Funding
The author(s) received no financial support for the research, authorship and/or publication of this article.