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

me than Compute desired temperature at this time If Tank.Actual Temperature < desired temperature then Generate H20: Turn on heater (heater ID) else Generate H21: Turn off heater [heater ID) Generate TIMI: Set Timer (timer ID, 10 seconds. TR13. ramp ID) else Generate TR12: Complete temperetura ramp (ramp ID} [2] Set Temperature Ramp.Status - "controlling"TRl g: Campl~ temperature ramp (ramp ID]t"13. Completet[1] [2] [3] [4]Generate B91 : Temperature ramp complete [batch tO), Generate H21: Turn off heater [heater ID) Delete timer (timer tD) Delete temperature rampFig 9. State model of a temperature ramp object class. [Object Lifecycles: Modeling the World in States by Schlaer & Meli0r.~1991.Reprinted by permission of Prentice-Hall Inc., Upper Saddle River, NJ.]Formal Analysis of the Shlaer-Mellor Method119lmwer and unrestricted memory. This ties in with our earlier analysis of objeet~transactions, which are atomic anttthus conceptually take no time. It implies that there are no direct data flows between the data transformations in an essential data flow model; if there were, then the connected transformations would always be executed simultaneously (becauseiihey take no time) and hence they would represent one object transaction; but this should be represented by a single data transformatmn. Thus, 'in an essential data flow model, data transformations interface only with data stores and external entities. Figure 11 shows part of an essential data flow model for the account object class, together with a declarative specification of the two object transactions represented by the model. Inputs from the environment of theobject to a transaction are represented by data flows from an external entity to the data transformation that represents the transaction, labelled by the transaction parameters that are supplied by the external entity. Values computed by the transaction should occur as transaction parameters and are labels of output data flows to external entities. Evaluation of the guard requires data from data stores. This may involve reading from any class data store. These data flows are labelled by the attributes read from the data store. Realising the effect of the transaction involves writing to the data store of the object class to which the transaction belongs. These data flows are labelled by the attributes written to the data store. This use of data flow diagrams is in the same spirit as the functional model of the new version of OMT [48].Current Time " p.,~.=n~~~ /Batch tD + I~ndTime + End TemperatureTimer ID ~ . , ~Timer / Timer ID§ \ Start + 1 Time EndTemE~&mr~+ 19 ~"'~"~m;TiO + ]\~ ~~~"TRI 1 : Start controlling temperature {ramp IOiTemperature RampX\)Batch CookingTankT1~erature~JTemperature Ramp Fig 10. An action data flow diagram (ADFD)for the created state of the temperatureramp. [Object Lifecycles:Modelingthe World in States by Schlaer& Melior9 1991. Reprintedby permissionof