Forward Engineering

Forward engineering is the set of engineering activities that consume the products and artifacts derived from legacy software and new requirements to produce a new target system

In current forward engineering practice informal requirements are somehow converted into a semi-formal
specification using domain notations without underlying precise semantics like e.g. data-flow diagrams, entity-relationship diagrams, natural language descriptions, or other problem specific informal or semiformal
notations. The program then is constructed manually (i.e. in an error prone way) from the specification by a
creative agent, the programmer.
Hidden in this creative construction of the program from the specification are a set of obvious as well as
non-obvious design decisions about how to encode certain parts of the specification in an efficient way using available implementation mechanisms to achieve performance criteria (the why of the design decisions).
As an example, a specification fragment requiring associative retrieval using numeric keys may be implemented using hash tables, achieving good system reaction time. These decisions are usually not documented.
Over time the program code is modified to remove errors and to adapt the system to changed requirements.
The requirements may change to allow usage of alphanumeric keys and to be able to handle large amounts
of data, and the implementation revised to use disk-based B-trees. Unfortunately, often these changes take
place without being reflected correctly in the specification. The gap between the original specification and
the program becomes larger and larger. The result is a program code without a proper specification and with
untrustworthy design information (such as comments describing the hash tables!). The code becomes difficult to understand and, thus, difficult to maintain.
To overcome this deficiency, it is important to change the specification first and then reflect the changes in
the program code. A necessary precondition for this is to have reliable information about the relationship
between the specification and the program code. The design and its rationale describe the how and why of
this relationship; however, they are not documented in current practice.