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 collection of tools to specify software product requirements. A good example of such a toolkit for industrial product design (which is external design) is the collection of design methods described by Jones [1] in 1970. In a similar way, toolkits for software product specification are defined by Jensen and ~lbnies [2], Birrel and Ould [3] and Wieringa [4,5]. The tools that we have in mind are conceptual. They are used to reduce uncertainty about the final product by giving heuristics for making an (external) design decision and by representing the result of this decision. It is possible to supplement them with software tools such as diagram editors that take over the clerical parts of the usage of the conceptual tools..lust as in other branches of engineering, the software tools play a supporting role with respect to the usage of the conceptual tools. The toolkit approach must be contrasted approaches in which a single method is used such as SSADM or Yourdon structured analysis. In the extreme case,Formal Analysis of the Shlaer-Mellor Method107methods like these consist of a set of manuals that prescribe a _4aarticular sequence of steps in which particular m61s must be used. The advantage of a toolkit approach is that it frees the engineer from the obligation to perform tasks that are prescribed by a method but not called for by the development situation, and opens his or her mind to tools that could help to improve the quality of the final product. To get the most out of tools, our attitude towards them should be eclectic. Note that we do not advocate the abolition of method. Rather, we favour the description of the "directions for use" of requirements engineering tools in such a way that the tools can be used in different ways of working. Requirements engineering is not yet in a state where a generally accepted set of tools has been defined. There is a variety of structured analysis methods [6-10] and an even larger variety of object-oriented methods [11-J~8] that jointly offer a confusing multitude of techniques and notations. It is hard to see which techniques and notations are variants of each other and which are compatible. Putting all of these together, we most certainly do not have a coherent toolkit. The ~addition of yet another notation to the forest of techniques would not help in clarifying the situation either. Behind the syntactic differences there is a large overlap in these methods~but there are also many real differences. In order to define a usable toolkit, we have to dig behind the surface and identify a set of tools that covers the area where these methods overlap and supplement this with additional tools that are useful but do not occur in all methods. In addition, in order to increase the utility of the tools, they should resemble as much as possible the tools that software engineers are currently familiar with. This does not mean that no new tools should be defined. We think that current research in object-oriente