23.08.2013 Views

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

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

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

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

366 SHE Framework<br />

11.4.9 Requirements Catalogue<br />

A Requirements Catalogue completes a system specification with information that lacks<br />

in the other parts <strong>of</strong> a model, and also contains redundant information for the purpose<br />

<strong>of</strong> easy retrieval. Figure 11.8 showed an approach where the Requirements Catalogue<br />

consists <strong>of</strong> four items:<br />

Listed Requirements;<br />

System Dictionary;<br />

Architecture Decisions Statement;<br />

Implementation Decisions Statement.<br />

The purpose <strong>of</strong> these items has been described in Paragraph 11.4.2.3. The further detailed<br />

definition <strong>of</strong> the prescribed structure <strong>of</strong> a Requirements Catalogue is subject for future<br />

research. The development <strong>of</strong> tools for our method will strongly influence our view on<br />

the function <strong>of</strong> a catalogue. A System Dictionary may very well be distributed. Various<br />

forms <strong>of</strong> information can be stored connected to graphical objects in various diagrams.<br />

Automated documentation facilities can retrieve and present this information.<br />

11.5 Extended <strong>Specification</strong> Modelling<br />

11.5.1 Extension <strong>of</strong> the Essential <strong>Specification</strong><br />

In the previous section we described the development <strong>of</strong> the various views that form an<br />

Essential <strong>Specification</strong>. An Extended <strong>Specification</strong> is developed by taking the Essential<br />

<strong>Specification</strong>s as a starting point. This Essential <strong>Specification</strong> must be gradually refined<br />

and extended with the purpose <strong>of</strong> bridging the gap between the Essential <strong>Specification</strong><br />

and the actual implementation <strong>of</strong> a system. Figures 11.3 and 11.4 show the place<br />

<strong>of</strong> extended modelling relative to other development activities. Figure 11.5 shows<br />

that both an Essential <strong>Specification</strong> and an Extended <strong>Specification</strong> consist <strong>of</strong> the same<br />

sorts <strong>of</strong> views. Notice that all essential representations have a corresponding extended<br />

representation. For example, Essential Message Flow Diagrams correspond to (are<br />

the basis for) Extended Message Flow Diagrams. An Architecture Structure Model <strong>of</strong><br />

the Essential <strong>Specification</strong> corresponds to an Implementation Structure Model <strong>of</strong> the<br />

Extended Model. Most <strong>of</strong> the approaches described in the previous section hold also for<br />

the creation <strong>of</strong> an Extended <strong>Specification</strong>. Therefore we will limit the description to the<br />

differences in the modelling approaches.<br />

The milestone between essential modelling and extended modelling can be placed when<br />

we pay attention to the purpose <strong>of</strong> both models. An Essential <strong>Specification</strong> is used<br />

for extensive communication with users and other experts. The focus is mainly on<br />

what the system must do. In contrast to other methods we allow to perform various<br />

design activities in this essential modelling phase. These activities concern system level<br />

design (architecture structure), design for reuse and early incorporation <strong>of</strong> definitive

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!