Specification of Reactive Hardware/Software Systems - Electronic ...

1.1 Objectives 3
understood and still a subject for research. For this reason we did spend a lot of research
in defining a practically useful object approach.
For a complex product the knowledge of technology is, although necessary, not the key
to a complete product idea. A bottleneck today is the definition of what is to be designed.
The required functionality of a system cannot be known before one has worked on a
model of the system for a substantial amount of time. A specification in the form of
a traditional requirements list is absolutely inappropriate for complex systems. This
approach assumes that one is able to determine in advance the requirements of the
system to be developed. The traditional bottom up approach of designers does not lead
to efficient product development anymore. The same holds for the traditional top down
approach.
Emphasising technology leads to the well known pitfall of ’technology push’. An
alternative is a market-driven approach. The premise is of course that a specification
document can be understood and influenced by marketing experts. In general these
people are not technology experts. The same holds for team members from various
other expertise domains. They should be involved in the whole design path, starting
from an adequate specification. In the existing specification tradition we observed a
huge communication problem.
Concurrent Approach
There are few specification methods, for direct industrial application, that bridge the gap
between hardware/software design. A lot of research has been performed in the area
of software engineering and formal specification. A problem that we have with most
of these approaches is that they propose to finish a specification phase before starting
design. They assume that specification can be completed without performing design
activities. The idea is that an optimal implementation technology will be chosen after the
evaluation of alternatives. ’Implementation independence’ is elevated to an objective in
itself. Apart from the fact that no one knows how orthogonal criteria must be weighed
to create an economical optimum, this approach does not match with industrial practice
in general. The very necessary practice is that some implementation decisions are taken
partially beforehand or at least in an early phase. This is absolutely necessary to be
able to reuse existing knowledge and technology, and because of the enormous time
pressure that is imposed on product development nowadays. Concurrent engineering
is necessary. There is no time for a sequential approach. Therefore we set ourselves the
goal to integrate design partially with traditional implementation independent system
modelling.
System behaviour modelling is far from easy and time consuming. It is however necessary
and pays off at the end. Besides a lot of other reasons, modelling is simply necessary
to find the required behaviour of a complex system to be designed. We experienced that
a large part of the functionality of complex systems is only found when the behaviour
is actually being modelled. It is just impossible to capture the complete functionality
during a requirements phase, which is often recognised as preceding a modelling phase.
For this reason promotion of the early use of specification models is necessary.