THE FOUR-PART DESIGN METHOD
This methodology brings proven techniques of hardware design and/or
building construction design to computer systems and software.
While content is always more important than form, experience has
shown that certain layouts improve the utility of documents.
Putting a cover page on each document separates finished designs
from rough ideas. Each design is normally published as a separate
document and tracked individually.
The location of information on authors. This should never go on
the front cover. Instead it goes on a Revision History page in
the 'front matter'. This explains who changed what, and when;
and more importantly who is responsible for what. A junior staff
member can make a minor revision and get appropriate credit, but
a question about basic concepts will still be directed to the
original author. This minor detail facilitates an approach whereby
the fundamental design concept and general layout are prepared
by an experienced senior designer, and the final design is left
to an assistant. This is delegation that works!
The four consecutive parts are:
- Functional Definitions (FUN)
- Interface Designs (IFD)
- Transaction Designs (TXD)
- Code/Module Designs (CMD)
The Functional Definitions explain what the system must accomplish
(simply - avoiding detail on how this should be accomplished).
Sometimes called 'one-page descriptions', they should be understandable by non-specialists.
Groups of related functions can be combined into facilities.
This is the most detail that should be incorporated in a contract.
For a validated system these include the formal 'Requirements'.
To make a comparison with building construction, these definitions
are equivalent to the 'Architect-Client Agreement' -
they establish the scope of the project prior to design.
The Interface Designs show how the system interacts with the outside world -
this may consist of an interactive user interface, calling sequences, file formats,
or hardware pinouts, as needed.
These features must be designed, and the time needed to do this
may be a major part of the development cycle.
The interface often needs to change or evolve during the project.
The traditional 'Functional Spec' that tries to treat the interface as a fixed
arbitrary a-priori decision usually fails.
In the construction analogy these would be the architectural
drawings - they describe how the building appears from the outside
or to the occupants, but not how it works.
The Transaction Designs explain how the system is supposed to work.
These are by far the most important designs
and unfortunately also the most neglected aspect of design.
This is where the designer explains why he/she thinks the system will work.
These designs cover the physical and technical answers to the problem at hand.
They describe the special cases and boundary conditions and how are they handled.
If a design can't be convincingly explained on paper,
it is unlikely to work when implemented.
These 'internal designs' were initially used for database transactions, hence their name.
In the construction analogy these would be the engineering designs/drawings
- e.g. structural, HVAC, electrical, - they describe how the building
works and why it doesn't fall down.
The Code/Module Designs show how the logic is distributed into source modules and files.
These determine whether certain code is shared or duplicated.
These designs describe specific naming conventions.
Here is where libraries and build procedures are planned.
In the construction analogy these would be the 'shop drawings'
- detailed drawings of individual pieces of steel or equipment
so they can be prepared for assembly.