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

a timer. A timer is an object that functions as an alarm clock. A n y number of timers may be created in the system. Relationships may have two state models, one that describes the life cycles of its instances and one, called the assigner, that monitors the creation of relationship instances. There is at most one assigner for each relationship. We ignore assigners in what follows, because they can be represented in the same way as state models that describe the life of instances.4.2. Methodological AnalysisWe will use the account state model of Fig. 5 as a vehicle to argue that an equivalent Mealy representation of the state model is considerably simpler and can be defined in such a way that it contains less implementation bias. To argue this, we start by noticing that there are two kinds of states in the account state model, stable and transitory. In a stable state of an object, the object is ready to respond to events initiated by its environment, and in a transitory state the object is busy responding to an event that it has received. When the object is busy responding to an event, it will queue incoming events so that it can respond to them later. The concept of transitory state is well known from the Ward-Mellor method of structured analysis [10]. For example, opening an account brings one into state 1, in which the M o o r e automaton creates and initialises an account and generates a deposit action. The deposit action is received by the very same object and causes transition into state 2, where the deposit is added to the balance. If the balance is non-negative, the action account OK is generated, which causes the account to move to state 3 and if the balance is negative, the action overdrawn is generated, which causes the account to move to state 4. The account then settles in state 3 or 4, that is, these are stable states in which the object can respond to events that it receives from the environment. The states that the account meets on the way are transitory. In fact, states 3 and 4 are the only stable states in the diagram. Transitory states can be used to factor out common computations among different transitions. For example, state 2 factors out the action of depositing money, which occurs in the initialisation transition of an account, in the deposit transition from the overdrawn state and in the deposit transition from the in good standing state. Transitory states m:e also useful to test a guard to determine which transition can be taken. For example, state 6 tests whether handling a check would cause the account to be overdrawn and so tests whether to go to state 7 or state 3. Let us define an object" transaction as an atomic interaction between the object and its environment,114R.J. Wieringaand G. Saakeobject, the object is in a state where either the transaction has occurred or it has not occurred. This is die classical transaction concept known from databasewhere an interaction is defined to be atomic ~{f _its inte