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

11.2 SHE Context and Phases 337
a purpose description;
prescribed and predefined implementation and topology choices (design constraints).
11.2.1.1 Requirements List
In industrial practice, a requirements list contains a mix of functional requirements, environmental
conditions, constraints such as physical size or power consumption, price,
and various implementation-oriented details. Such a list is traditionally called a specification.
We consider such a ’specification’ only as a starting point to produce what we
call a specification. A requirements list is usually very incomplete. The list stops where
the imagination about the product stops. Without the use of some structured analysis
method it is not possible to analyse requirements sufficiently in depth. In practice many
companies start with an attempt to realise (parts of) a product in the form of a prototype.
They find the real system requirements by trial and error via expensive development of
successive prototypes.
11.2.1.2 Purpose Description
It is our experience that a purpose description of the system is often lacking. One is focusing
on a single solution that is already in mind, without wondering what problem the
system essentially should solve. As a premise to make an essential system specification
we require a purpose description. This enables asking questions about prejudiced
implementations and solutions in mind. The purpose of the system can only be described
when the needs of the users of the system are made explicit.
11.2.1.3 Prescribed Technologies and Topologies
Prescribed technologies and topologies constrain the freedom of the designer. Design constraints
prescribe predefined implementation choices that can or must be known in
advance. It is no use to invest time in the selection of technology or solutions when they
are prescribed. Technology is often prescribed because of past investments in know-how
and development tools. Predefined solutions can have a large influence on the structure
of a specification model.
11.2.2 Essential Specification
Milestone 1 indicates the start of the modelling with the method SHE. The goal of
the Essential Specification phase is an analysis of essential system requirements and the
creation of both an abstract behaviour model and the highest level system structure
model (architecture). Both models are developed in a strong interaction. Behaviour
and structure are formalised into a unified formal description in the language POOSL.
This description enables examination of various system properties via simulation and
verification. The result of the essential specification phase must be a correct abstract
system model. Notice that simulation requires in general also the development of a