Graphisoft®

Basic Library Version: 16

Specifiation of Libraries

Index

  1. Introduction
  2. Defining Requirements
  3. Specification
  4. Prototypes

1. Introduction

This document is addressed to procurers of GDL libraries. Its intentions should be considered both in contracted and in in-house situations.

2. Defining Requirements

The complexity of the library part should be carefully considered: a very sophisticated object is also very difficult to use. An element can be a composite of smaller parts, which will reduce the number of parameters and/or the size of the library part. A large library part's modeling process can be very slow. The number of parameters is limited to 512.

The abstraction level of the same library part can vary depending on its different representation forms. A sophisticated 2D symbol can sometimes be used as a simple 3D model. These types of decisions must be made before the other phases of specification.

3. Specification

First of all, the purpose and the function of the library part must be clear. Therefore, all parameters must be designed together with their hierarchy, to give a perfect overview of the library part's function: the level of abstraction, features, 2D/3D representation, and the section and elevation shape. The most basic question is: what is this library part used for?

The parametrizing logic must be reflected in the arrangement of the parameters: groups of parameters should be created and the connection between them must be defined clearly (later implemented in the Parameter Script). To accomplish this, links between different parameters must be carefully analyzed.

Detailed specification drawings must be prepared before the creation of a new library is started.
Specification drawings must contain every version of each unique library part:

The specification drawing must contain everything that is important for the client. The programmer will not complete what is not shown on specification drawings. Therefore, good communication is needed between client and programmer to avoid having to make serious modifications in an advanced phase of the library development.

4. Prototypes

Usually, it is impossible to define the clear specification for a never seen functionality in advance. Prototypes are a good solution for both the customer and the developer to communicate the requirements and the specification. To represent the requests and the possible solutions in an advanced form, a prototype should be created for one or more basic elements of the library.

Prototypes must be checked very carefully by the customer. They should contain all parameters, options and features of the final library part. Very often, this is not possible in an early stage of the development, so library parts must be prepared to easily handle modifications. For this reason, a library part should never be considered as an ultimate solution for the client's requests.