In this paper, we define a number of tools that we think belong to the core of any toolkit for requirements engineers. The tools are conceptual and hence, they need precise definitions that lay down as exactly as possible what their meaning and possible us

Model 5.1. StructureIn the process model, each action is specified by an action data flow diagram (ADFD) that represents the processing performed during the action. To illustrate this, we give an ADFD for the Created state of the temperature ramp state model in Fig. 9. The temperature ramp is part of a model Qf a controller of a juice plant that mixes juice in a cooking tank and puts it into cans. The entire model specifies the controller for the cooking tank and the canning operation and is specified more fully in Shlaer and Mellor [43]. The temperature ramp state model of Fig. 9 contains the following actions: 9 Created. Upon creation of a temperature ramp, a timer is created for this ramp, the current time and the current cooking tank temperature are stored in5.2. Methodological AnalysisThere are some problems with the use of data flow diagrams in combination with object-oriented modelling techniques. First of all, data flow diagrams represent what we call the Von Neumann partitioning principle in which data is separated from processing. This partitioning goes against the object-oriented partitioning principle that data and processing should be118R.J. Wieringaand G, Saakegrouped together [43,45]. Second, all the data in a data store is globally accessible to any process that accesses it [46]. This again contrasts with the object-orientedencapsulation of data with the processes that access it. Third, data flow diagrams specify the operations that take place during an action, and this tends to have a bias towards implementation [43,47]. To be completely free from any implementation bias, a declarative specification of the meaning of actions is to be preferred. These problems with DFDs do not imply that they should be abolished altogether. Using ideas from McMenamin and Palmer [41], we can define an essentialdata flow model of objectotransactions as a data~ flow model with the following contents (Fig. 11): 9 The state of the object is represented by a data store. 9 Each object transaction is represented~by exactly one data transformation. 9 Each data transformation represents~ exactly one object transaction.Thus, essential data transformationstt'ave no memory. We add to this McMenamin and Palmer's idea of perfect technology, which says that an essential data ftow model describes a machine with infinite processiirgTRgO: Do temperature ramp (bat:ch ID, end time, end temperature)1. Created [1] Create Temperature Ramp with an arbitrary Ramp ID and Batch ID, End Time, End Temperature from event data [2] Temperature Ramp.Timer ID := Create Timer [3] Set Temperature Ramp.Start Time = current time [4] Set Temperature Ramp.Stert Temperature = Cobking Tank.Actual Temperature [5] Generate TR11 ! S~.artcontrolling temperature (ramp id] [6] Temperature Ramp,Status - "created"TR11: ~ r ~ c, r~lling temperatura (ramp ID]..j . . . . . ..@77~13:F~mp ~imer eR~r~dIoj9. 2, Controlling..[1 ] If current time < Temperature Ramp,End Ti