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

participation is represented by the letter "c" at the arrowhead. O O A allows the definition of relationship attributes. As shown in Fig. 1, these are collected into something called an associative object class (OWNERSHIP), which is connected by an arrow to the relationship whose attributes are represented. Subclasses and superclasses are represented as shown in Fig. 2. The intention is that in each state of the system, the set of existing instances of the superclass is partitioned by the sets of existing instances of the subclasses. Each existing instance of TANK is therefore also an existing instance of exactly one of the TANK subclasses. O O A allows class migration. For example, ifMIXING_TANK would be partitioned into subclasses UNASSIGNED and ASSIGNED, we can allow amixing tank to migrate between these two subclasses.3,2. Methodological AnalysisThe information model embodies fairly standard and accepted ideas, so it is certainly a candidate for addition to our toolkit. The roots of information modelling lie in E R modelling [27] and semantic modelling [28,29]. Closely related approaches with different notational conventions can be found in other object-oriented methods, such as OMT [18] and the Coad-Yourdon method [12]. To prepare for formalisation, we analyse two important aspects of information modelling, object identification and the taxonomic hierarchy.10. TANK IT} * Tank 11399 Su~d~l (mO)RIO0~ a....IITank~D~mC~l I Heater o IR3S) 141 STORAGE TANK (S) * Tank ID [RIO0)5. MIXING TANK ~vl) * Tank ID (1:t100) 9 Mixer on/offFig 2. Representation of specialisation. [Object Lifecycles: Modeling the World in States by Schlaer & Melior @ 1991. Reprinted by permission of Prentice-Hall Inc., Upper Saddle River, NJ.]110R.J. Wieringa and G. SaakeThe importance of object identification goes beyond object-oriented requirements specification.Any administration that wants to keep track of objects in the real world must devise a way to identify these objects [30, 31]. The only way to do this is to assign a proper name to each relevant object such that there is a one-one relationship between these names and the identified objects that, once established, never changes. Thus, the set of links between proper names and identified objects grows monotonically. These proper names can then be usedas.object identifiers in the system. In order to achieve fl/is, the name must not designate any property of the object that can change. In practice, this means that the name does not carry information about the state of the object and it is indivisible, that is, it cannot be decomposed into meaningful parts. We therefore deviate from the O O A way of identifying objects and require object identifiers to be atomic. O O A rightly allows objects to migrate between classes. This has an important methodological consequence that is, however, not remarked by Shlaer and Mellor, namely that in object migration an instance may become a member of a su