Use-cases and Scenarios for Developing
Knowledge-Based Systems
Michael Erdmann, Rudi Studer
Institut für Angewandte Informatik und Formale Beschreibungsverfahren (AIFB) University of Karlsruhe (TH)
D-76128 Karlsruhe (Germany)
e-mail: {erdmann, studer}@aifb.uni-karlsruhe.de
Abstract: The development of knowledge-based systems requires the availabi-lity of domain and problem-solving knowledge. This knowledge must be acquired from domain experts. For this purpose the paper proposes to adopt the concept of scenarios known from requirements engineering and object oriented modelling to enrich the set of acquisition techniques. In RE and OO scenarios are used to define a vision of a future system. In knowledge enginee-ring their scope has to be extended, but their advantages (ease of understan-ding, support of communication, focus on relevant aspects etc.) still hold for knowledge-based systems.
1 Motivation
In the knowledge acquisition (KA) community it is common sense that for developing knowledge-based systems (KBS), a modelling approach has to be pursued to guarantee reliable, traceable, and maintainable systems of high quality. A prerequisite for such systems is the availability of the needed knowledge. Most current KA methods support knowledge engineers in defining several models that document the development process but they are weak in supporting the concrete elicitation of the expert’s knowledge. For that problem the term knowledge acquisition bottle neck has been coined. Similar problems occur in other disciplines besides knowledge engineering (KE) with slight diffe-rences concerning the type of knowledge. This is due to the similarities of such disciplines as busi-ness modelling (cf. [Jacobson et al. 95]), object oriented software engineering (cf. [Rumbaugh et al. 91], [Jacobson et al. 92]), requirements engineering (cf. [Davis 93]), and knowledge engineering (cf. [Stefik 95]). All these disciplines are modelling disciplines, i.e. they aim at building a conceptional model of (some aspects of) a given or future system. That model abstracts from reality in a way that only relevant aspects are represented. In all these disciplines communication between a domain representative and a system’s developer is crucial, because only by communication the model and later the system can be built in the intended way. Ways to support the communication processes should therefore be an important topic of the above mentioned disciplines.
One way to overcome the communication problem is the tight integration of the domain expert into the development process. This can be achieved by prototyping, by easy intelligible graphical repre-sentations of system models, or by means for organising the development process (interview sessions, workshops etc.). One way of user or domain expert involvement into the development process is the utilization of scenarios or use-cases. They are used to design human computer interac-tions ([Carroll et al. 94]), in object oriented software engineering [Jacobson et al. 92], in business process modelling [Jacobson et al. 95] and in requirements engineering [Weidenhaupt et al. 98]. There does not exist a clear definition of the terms scenario, usage scenario, or use-case but rather a set of features typical for scenarios. In his introduction of [Carroll 95] Carroll gives a very illustra-tive list of these features.
Scenarios seek to be concrete; they focus on describing particular instances of use, and on a user‘s view of what happens, how it happens and why. Scenarios are grounded in the work of prospective users; the work users do drives the development of the system [...] scenarios are often open ended and fragmentary; [...] They can be informal and rough; since users as well as developers may create and use them, they should be as colloquial and as accessible as possible. They help [...] envision the outcomes of design --- an integrated description of what the system will do and how it will do it [...].
Carroll then contrasts scenarios with current views on system specifications:
Specifications seek to be abstract; they focus on describing generic types of functions, and on the data processing that underlies functions. Specifications are driven by the technology they specify; they are grounded in logic. They are intended to be complete and exhaustive. [...] They are rigorous; ideally they are formal. [...] They precisely docu-ment what is designed.
Although this description of what specifications are nearly sounds like an accusation, Carroll does not view scenarios as a new paradigm to system development; rather, current practices should be enriched using scenarios. Scenarios are a way to communicate between domain specialists (experts, users) and developers. Thus scenarios can be exploited in the first phases of a system development process to elicit system visions, system requirements, business processes, or expert knowledge. On the outcome of this phase the subsequent steps in the process (more formal modelling steps like specification, design, coding) can build upon.
In this paper we will show how scenarios can be employed in the development of knowledge-based systems (KBS). Because the main concern of a KBS is the modelled expertise, i.e. often mental processes of a human expert, the term scenario has to be redefined slightly. In the citations above Carroll talks about users because they are the appropriate peers in the development process of systems which involve a high degree of user interaction. Looking at the development of KBSs the main focus does not lie in the interaction with the future user but in the problem-solving competence of an expert, thus the following paraphrase of Carroll’s quote represents our notion of scenarios for KBS development.
Scenarios for KBS development seek to be concrete; they focus on describing particular instances of problem-solving processes, and on an expert‘s view of what happens, how it happens and why. Scenarios are grounded in the work of domain experts; the way
experts solve problems drives the development of the system; scenarios are often open
ended and fragmentary; they can be informal and rough; since experts as well as devel-opers may create and use them, they should be as colloquial and as accessible as possible. They help envision the outcomes of design --- an integrated description of what the knowledge-based system will do and how it will do it.
To summarize the given definitions one can say that the arguments for using scenarios in a system development process also hold for building KBSs. Since the accusations against specification also hold in the KA community, the implication must be to integrate a kind of scenarios into the develop-ment process of KBS.
To back this argumentation we will introduce scenarios as an appropriate addition to the set of models currently used in the MIKE approach (Model-based and Incremental Knowledge Enginee-ring [Angele et al. 96]). To illustrate the approach we will use the Sisyphus-I room assignment problem [Sisyphus-I].
The paper contains these parts: First we will introduce the use-case concept as it is currently seen in the OO world. In section 3 we will present the currently existing MIKE model set before enhancing it by the new model type of scenarios (section 5). The last section contains a final discussion of the approach and related and future work.
2 Use-Cases and Scenarios in Object Oriented Software Engineering
Use-Cases stem from the object oriented software engineering community. The use-case construct has been introduced by Ivar Jacobson and has been widely noticed through the OOSE method described in [Jacobson et al. 92]. Similar constructs also exist in several other object oriented methods like the Booch Method [Booch 94], the Object Modelling Technique (OMT) [Rumbaugh et al. 91], or Object Behaviour Analysis (OBA) [Rubin, Goldberg 92]. The Unified Modelling Language (UML) which is currently available as version 1.1 [UML 97] embraces several existing approaches towards object-oriented modelling. It has been accepted by the Object Management Group (OMG) as a world wide standard and contains use-cases as one main focus. The authors expli-citly state they develop UML to enable a "use-case driven, architecture-centric, iterative, and incre-mental process".
Following [Jacobson 95] a use-case is a description of "a way to use the system". "Taken together, a system’s use-cases represent everything users can do with it" and thus, "the collection of use-cases is the complete functionality of the system". A use-case is a class or pattern of system uses. It repre-sents a sequence of transactions between the system and actors (typically the system’s users). Thus a use-case can be characterized as a view to or a slice of the system behaviour. A use-case is written from the user’s perspective and allows system procurers, users, or domain experts to express their requirements of the future system and to communicate these to requirements analysts, software desi-gners, and test personnel. Often use-case models serve as a contract between clients and the software developers to exactly define the functionality of the system, the developers have to produce. Simi-larly, scenarios can support the acquisition and communication of expert knowledge and its negotia-tion with domain experts when developing knowledge-based systems (cf. secnegotia-tion 5).
Use-cases describe the external behaviour of the system, and allow to determine the necessary internal objects. Besides a use-case model object models have to be developed to sufficiently specify a system. These object models can be derived from use-cases. [Jacobson et al. 95] suggest to "iden-tify --for each use-case-- the objects that are needed to execute that particular use-case." In this way the object model is built bottom up by defining several views on it (one view per use-case) and later integrating these views to a single model. All the responsibilities and properties of a particular object can be obtained by integrating the roles it plays in the different use-cases in which it participates. There is a strong relationship between use-cases and objects: "For a particular use-case to be executed, a certain set of objects is required in the system [...] these objects offer the use-case." During knowledge elicitation for the development of a KBS in scenarios several different kinds of
objects are identifiable, e.g. concrete domain concepts (classes), their instances, properties and rela-tionships, tasks to be fulfilled, their subtasks, and other knowledge structures that are special to KBSs (e.g. rules or certainty factors).
Use-cases are a rather flexible method in system development. They are not only used to acquire system requirements. They can be used to represent the architecture of the system or of its environ-ment (i.e. the business processes); they are used for docuenviron-mentation purposes, for communication or even with a legal character as contracts (cf. [Weidenhaupt et al. 98] and [Rolland et al. 96] for surveys of real projects and scenario methods, respectively). Because of the broad applicability of use-cases/scenarios to a wide range of disciplines there are also several ways to represent them. Nearly all approaches encompassing use-cases allow their (informal) representation as plain text (protocols, interviews etc.). Often predefined templates are used to ensure the documentation of important facts. Additionally or alternatively other, more formal representation methods are employed. In OBA [Rubin, Goldberg 92] a tabular notation of scripts describing use-cases is presented. [Hsia et al. 94] present a formal representation language and [Glinz 95] introduces finite automatae (esp. statecharts) to represent use-cases.
As we will show in section 5 the notion of use-cases and object models is not only suitable to model business processes and businesses, or software systems --- this view can be extended towards know-ledge-based systems and describing their expertise.
3 The MIKE approach
The MIKE approach (Model-based and Incremental Knowledge Engineering) [Angele et al. 96] defines a framework for building KBSs. MIKE supports the modelling process by a set of intercon-nected models that allow the elicitation, interpretation, formalization, and implementation of know-ledge in order to build KBSs. MIKE aims at integrating the advantages of life cycle models, prototyping, and formal specification techniques into a coherent framework for the knowledge engi-neering process (cf. Fig. 1). In [Decker et al. 97] the MIKE model set that has been aimed purely to develop KBSs has been enriched by models concerning the organisational environment of the KBS. The starting point of the modelling process is the knowledge possessed by domain experts or other knowledge sources. Based on this knowledge finally an operational knowledge-based system should be developed. Between these two points lies a wide gap that has to be bridged by the knowledge engineer. MIKE supports the knowledge engineer by dividing this gap into smaller ones and thus reducing the complexity of the overall modelling task because in every step different aspects can be
considered independently from others. In parallel to the division of the overall process into substeps a set of models is introduced that enhances the ease of modelling even more (cf. Fig. 1).
The knowledge gained from the expert in the elicitation phase is normally described in protocols containing natural language statements. These knowledge protocols define the elicitation model. This knowledge represented in natural language must be interpreted and structured by the know-ledge engineer. The result of this step is described semi-formally in the so-called structure model, using a graphical notation of predefined nodes and links. The structure model consists of four contexts: the concept context defines the domain terminology, the activity context defines the task decomposition, the data flow context defines the data flow between the subtasks and the ordering context defines their control flow. All these contexts represent a partial formalisation of domain and problem-solving knowledge. During the formalisation step these semi-formal structures are trans-formed into a formal model of expertise, which ---according to the KADS approach [Schreiber et al. 93]--- is a knowledge-level description of the functionality of the system.
In MIKE the formal model of expertise is expressed in the specification language KARL [Fensel et al. 98]. Because KARL is also an operational language the specified model of expertise can be executed and thus an evaluation by prototyping becomes possible. According to the KADS proposal the model of expertise is composed of three layers separating domain specific knowledge (domain layer) from generic problem-solving knowledge (inference and task layer). The model of expertise is linked to the structure model and in turn the structure model is linked to the elicitation model. In this way traceability is assured from the formal model back to the initial natural language protocols. We
elicitation model structure model model of expertise design model operational KBS evalu ation elicitation formalisation design implemen-tation interpretation structuring
Fig. 1 Process model and documents of MIKE prototype expert
will not discuss the design and implementation phases in this paper (see [Angele et al. 98]) that finally lead to the operational KBS.
4 An Example --- The Sisyphus-I Experiment
The task of the Sisyphus-I problem [Sisyphus-I] is to assign a group of people onto a set of different rooms. This assignment has to satisfy certain constraints concerning some characteristics of the people and the rooms. The problem statement provided in [Sisyphus-I] actually contains a protocol in which the wizard Siggi D. is engaged in solving a sample room assignment problem. This protocol fits the definition of a scenario for KBS development as given in section 1 and thus serves as an illu-stration for scenario use for developing KBSs. The protocol describes a particular instance of a problem-solving session,
1. Put Thomas D. into office C5-117.
2. Monika X. and Ulrike U. into office C5-119. 3. Eva I. into C5-116.
and is extended with comments, questions and annotations. The source of this additional information is not clear. Either they are utterances by the expert to explain his decisions or they are interpreta-tions of the decisions made by the interviewer or a knowledge-engineer. If they are interpretainterpreta-tions they are probably based on questions presented to the expert during or after the interview. These additional informations are particular valuable to explain why Siggi made certain decisions, e.g.
1a. The head of group needs a central office, so that he/she is as close to all the members of the group as possible. This should be a large office.
1b. This assignment is defined first, as the location of the office of the head of group restricts the possibilities of the subsequent assignments.
2a. The secretaries’ office should be located close to the office of the head of group. Both secretaries should work together...
We view this transcript of a protocol (containing the words of the wizard Siggi D. plus the comments, questions and annotations) as the scenario provided in the Sisyphus-I experiment because ---referring to the definition of section 1--- the presented material describes a particular instance of a problem-solving process.
Besides the annotated protocol the problem description contains further information: (1) an illustra-tive background story, (2) a map of the rooms’ locations, (3) data describing the people (e.g.
"Katha-rina N. is a researcher, she works at the MLT project, she smokes and hacks") and (4) information
about the rooms (e.g. "C5-119 and C5-117 are large rooms that can host two researchers"). A large portion of this information is already contained in the given protocol and could have been extracted by the knowledge engineer. Actually, this knowledge extraction from scenarios is a main advantage of this form of knowledge elicitation, esp. if the domain expert is available and can answer questions that arise during the extraction steps. As we will show in the next section a large portion of the concept context of the MIKE structure model can be acquired just analysing the scenario description of a problem-solving process.
5 Scenarios for KBS Development
In this section we will show how to integrate scenarios into the development process proposed by MIKE. For illustration purposes we will use the Sisyphus-I room assignment problem [Sisyphus-I] (cf. section 4).
The application of scenarios in a development process for KBSs generally allows for an easy integra-tion of domain experts into the knowledge acquisiintegra-tion process due to the high comprehensibility of scenarios. As discussed in section 1 the role scenarios play during KBS development is slightly different compared to an OO system development process as presented in OOSE [Jacobson et al. 92] or compared to designing human computer interfaces. Here scenarios do not describe actual or planned sequences of use of the system as a black box but they describe on a detailed level (or even an instance level) aspects of the envisioned problem-solving behaviour of the KBS. Scenarios do so based on single cases in a given domain.
5.1 The elicitation phase
According to the definition of scenarios for KBS development they are open ended, fragmentary, informal and rough; and they are colloquial and accessible. Due to their informal and accessible nature their proper place among the MIKE models is the elicitation model. There knowledge is stored in form of natural language transcripts of instances of problem-solving processes besides regular interviews or other informal knowledge sources (cf. Fig. 2 top right). Through these different informal protocols two levels of abstraction exist already in the elicitation model. The scenarios contain concrete objects and concrete decisions with their explanations; the interviews contain more general statements of what is important in the domain or for solving the given kind of problem. Both
levels are important: scenarios allow easy access of expert knowledge and general information provides deep knowledge. The knowledge engineer, whose task it is to elicit all necessary know-ledge, must become familiar with the terms the expert uses and thus with the whole domain, i.e. the knowledge engineer has to learn. This learning process is supported by concrete scenarios, since talking about examples is often more illustrative than talking about abstract entities. This is a great benefit of scenarios for the communication between developer and expert. To reassure himself the knowledge engineer could formulate a scenario and ask the expert whether it is correct or not. Scena-rios are also easier for experts to articulate their knowledge because they often do not explicitly know how they solve a problem in general (they are unconscious of the underlying problem-solving principles), so they cannot communicate a general method for it. But they can solve concrete problems and they can articulate the problem-solving steps they perform, e.g. via think aloud proto-cols.
Another advantage of scenarios is, that they are much more focused (cf. [Weidenhaupt et al. 98]). They allow the expert to concentrate on a single case and thus on a single view of the whole problem-solving expertise. This can drastically reduce the complexity of descriptions, which makes the whole expertise more intelligible to the knowledge engineer. This complexity reduction enables him to ask questions that deepens his understanding and possibly makes even the expert more conscious of his or her problem-solving behaviour. Thus initial knowledge acquisition, negotiation and communication between knowledge engineer and domain expert becomes easier, i.e. concrete scenarios simplify the elicitation process for all partners.
expert elicitationmodel
structure model model of expertise design model operational KBS evalu ation elicitation formalisation design implemen-tation interpretation structuring
Fig. 2 Process model and documents enriched by scenario aspects instances scenarios generali-zation generali-zation prototype testing
After or during the elicitation phase scenarios and other elicited documents could be related since an interview that contains general information may represent a generalization of a set of concrete scena-rios. If the knowledge engineer’s understanding of the domain is deep enough he could formulate a generalization document making hidden, tacit knowledge explicit and have it reviewed by the expert. So the basis of the KBS, i.e. the elicitation model, becomes sounder and more reliable.
5.2 Scenarios for structuring and interpreting knowledge
Scenarios are descriptions of real cases and thus grounded in the given domain. Due to that they are natural contributors for a static domain model. In the MIKE approach the concept context of the structure model is used for describing the domain concepts and their relationships. The protocol of the Sisyphus-I experiment allows to extract a large portion of the relevant concepts, their attributes and relationships of the room assignment domain. Looking at the sample statements of the Sisyphus-I experiment from section 4, we can identify persons (Thomas D., Monika X. ...) ---speaking in an OO like terminology--- as a class. We can identify head-of-group, secretaries, and manager as subclasses of persons. The protocol delivers also attributes of those classes, that can be used to refine the concept context of the Sisyphus-I experiment. For example [Sisyphus-I] contains the following passage:
8. Werner L. and Jürgen L. into C5-123
8a. They are both implementing systems, both non-smokers. They do not work on the same project, but they work on related subjects. ...
From this paragraph the attributes for class implementor can be derived, i.e. the binary attribute smokes, and the projects and subjects implementors work on. These attributes may even be more general so that they should be defined within a superclass of implementor, e.g. researcher or person. Decisions like that are made in dialogue with the expert or can be clarified in later iterations of the development process.
Analysing the Sisyphus-I protocol a large portion of the additional information provided in [Sisy-phus-I] could be derived. As addition to the concept context the knowledge engineer has access to
concrete instances of domain classes, since the instances promoted the development of more general
classes. The identified instances are now newly introduced to enhance that model. A part of the deri-vable domain model for Sisyphus-I is given in OMT-syntax [Rumbaugh et al. 91] (cf. Fig. 3). In a similar way the other contexts of the structure model can be enhanced by instance level descrip-tions as well.
5.3 Scenarios for validation of models
The use of scenarios during the elicitation phase results in a set of protocols describing real cases. In order to be correct, the developed system has to reflect the functionality described in the scenarios. Thus, a scenario can be exploited for testing the system or its specification. The reuse of scenarios as test-cases is a well known application of scenarios in requirements engineering. In combination with an implemented prototype (often a mock-up of the user interface) in RE scenarios are a well esta-blished technique to evaluate the built models with the domain expert [Weidenhaupt et al. 98]. The final testing of the implemented system is much more difficult, because the time for the development process from initial scenario acquisition and final implementation and testing is rather long. During that time several changes of requirements or intermediate models might occur that were not reflected in the initial protocols, thus the scenarios elicited at the beginning of the development process are not up-to-date any more, i.e. traceability has been lost. Due to that scenarios often cannot serve for testing the system. Comparing the described situation with the framework proposed by MIKE, one sees the advantage of a close feedback loop through prototyping. As in RE, a prototype can be produced that can be tested or evaluated against the elicited scenarios. This evaluation may result in remodelling the structure model due to misconceptions or in additional knowledge elicitation due to missing knowledge etc. In contrast to UI prototypes the prototypes developed with MIKE are formal and operational specifications of the model of expertise in the language KARL [Fensel et al. 98]. This allows to test the functionality and thus what will be implemented in the final knowledge-based system. In that way two advantages of scenarios for testing are achieved: (i) the scenarios still reflect the current knowledge at the time the (formal) prototype is created because the time gap between elicitation and prototype is smaller than the time gap between elicitation and the implementation of the KBS; (ii) the prototype ---as the specification of the KBS--- is functionally equivalent to the implementation and thus further changes of that functionality are less probable or of minor degrees.
Person
Fig. 3 Part of the enhanced structure model for the Sisyphus-I scenario Implementor proj: Project smokes: Bool subj: Subject name: String room: Room Werner L. proj: RESPECT smokes: false subj: hacking concepts instances
Due to the framework proposed by MIKE the traceability of knowledge chunks in the different models during the knowledge acquisition process is ensured. One great drawback of scenario usage in RE is the lack of support for traceability [Weidenhaupt et al. 98]. MIKE offers naturally the ability to interconnect several models and thus an integration of scenarios into that framework is possible, i.e. due to traceability the model of expertise is connected to the structure model which is linked with the elicitation model and/or scenarios.
6 Conclusion
In this paper we showed the applicability of scenarios for the development of knowledge-based systems. The notion of scenarios has been extended on the basis of use-cases and scenarios known from object-oriented modelling and the design of human-computer interactions.
Besides the advantages described in section 5, scenarios cannot be viewed as the elicitation method for knowledge-based systems. Scenarios are less adequate for well understood domains and already acquired and structured knowledge (e.g. existing tables, explicit rules etc.). In the RE-community scenarios often describe the interactions possible between user and the envisioned system. In KA the mental processes inside an expert should be elicited, but they are not amenable, so that additional effort has to be done to achieve that knowledge (cf. [Ericsson, Simon 93]). The same problem is common to many elicitation techniques, but due to the exemplary nature of scenarios the access to the hidden and tacit knowledge becomes easier. Another major drawback of scenarios is their granu-larity. Many details could hide the real expertise and make it even more difficult to elicit the needed knowledge. But on the other hand communication and negotiation is simplified because concrete examples are at hand so that this drawback is an advantage at the same time. Scenarios inherently combine domain specific knowledge and actual problem-solving knowledge, which is in contrast to the current public view in the KA community. This might either be a disadvantage, since reuse of existing problem solving methods only makes sense if domain specific knowledge can be separated from generic problem solving knowledge, or it may be an advantage, since scenarios might provide the connecting link integrating both sides. This is an open topic of our research.
When discussing related work, CommonKADS has to be mentioned. In CommonKADS a collection of models is defined for capturing various aspects of a knowledge-based system and the organiza-tional environment it will be embedded in [Schreiber et al. 94]. CommonKADS puts emphasis on providing semi-formal languages for describing the different models, e.g. CML for defining the model of expertise or a mixture of NL descriptions and forms and tables for defining the
organiza-tional model [de Hoog et al. 96]. However, only very limited support is offered for building up these descriptions. In contrast, MIKE puts emphasis on a smooth transition between its different model types, using NL descriptions as a starting point. By including scenarios as additional model constitu-ents the model building process is also grounded on an instance level which further enhances the integration of the domain expert in the overall modelling process.
The VITAL approach includes various methods and techniques for knowledge elicitation and know-ledge modelling [Shadbolt et al. 93]. This includes tools for interactively building up Generalized
Directive Models which are used for identifying the task at hand, or tools for acquiring static domain
knowledge. Among others, VITAL offers a repertory grid tool (cf. [Gaines, Shaw 80]) for ranking domain elements, e.g. persons in the Sisyphus-I context, on property scales, e.g. preference for a central office. Similar to scenarios, repertory grids are working on an instance level, however in contrast to scenarios they do not offer any support in identifying the problem-solving behaviour. Rather, repertory grids are oriented towards identifying static aspects of domain elements.
The relation of scenarios to libraries of problem-solving methods or other components must be examined in the future, since the development of a KBS based on reusable components is a current research topic. As was mentioned above, scenarios inherently combine domain specific and problem solving knowledge, thus this might be a starting point for this investigation. As described in [Decker et al. 97] the MIKE approach can be embedded into a business modelling approach. Use-cases or scenarios represent one possible mechanism to describe business processes as well as problem-solving processes and thus to tighten the relationship between business and expertise model.
Acknowledgements: The authors want to thank the members of the working group Scenario based Requirements
Engi-neering of the German Computer Science Society (GI) for deepening our perception of the wide spectrum of scenarios. We also thank the anonymous reviewers for their inspiring comments on the draft of this paper.
7 References
[Angele et al. 96] J. Angele, D. Fensel, R. Studer: Domain and Task Modelling in MIKE. in: A.G. Sutcliffe, D. Benyon, and F. van Assche (eds.): Domain Knowledge for Interactive System Design.
Procee-dings of the TC8/WG8.2 Conference on Domain Knowledge in Interactive System Design, Geneva, Switzerland, May 1996. Chapman & Hall, London, 1996.
[Angele et al. 98] J. Angele, D. Fensel, D. Landes, R. Studer: Developing Knowledge-Based Systems with
MIKE. to appear in: Journal of Automated Software Engineering, 1998.
[Booch 94] G. Booch: Object Oriented Analysis and Design with Applications. Benjamins Cummings,
Redwood City, CA 1994.
[Carroll et al. 94] J.M.Carroll, R.L. Mack, S.P. Robertson, M.B. Rosson: Binding Objects to Scenarios of use.
in: International Journal of Human-Computer Studies. (41)3, 1994. pp.243-276.
[Carroll 95] J.M. Carroll (ed.): Scenario-Based Design: Envisioning Work and Technology in System
[Davis 93] A.M. Davis: Software Requirements: Objects, Functions and States. Prentice Hall, Englewood
Cliffs, NJ 1993.
[Decker et al. 97] S. Decker, M. Daniel, M. Erdmann, R. Studer: An Enterprise Reference Scheme for
Integra-ting Model Based Knowledge Engineering and Enterprise Modelling. in: Proceedings of the 10th European Workshop on Knowledge Acquisition, Modeling, and Management (EKAW’97). LNAI 1319. Springer, Berlin 1997.
[de Hoog et al. 96] R. de Hoog, B. Benus, M. Vogler, C. Metselaar: The CommonKADS Organizational Model:
Content, Usage, and Computer Support. in: Experts Systems with Applications 11, 1 (1996), pp. 29-40.
[Ericsson, Simon 93] K.A. Ericsson, H.A. Simon: Protocol Analysis. Verbal Reports as Data. (revised edition)
Bradford Book, MIT Press, Cambridge, Massachusetts 1993.
[Fensel et al. 98] D. Fensel, J. Angele, R. Studer: The Knowledge Acquisition and Representation Language
KARL. to appear in: IEEE Trans. on Knowledge and Data Engineering, 1998.
[Gaines, Shaw 80] B. Gaines, M. Shaw: New Directions in the Analysis and Interactive Elicitation of Personal
Construct Systems, in: Int. Journal Man-Machine Studies 13 (1980), pp. 81-116.
[Glinz 95] M. Glinz: An Integrated Formal Model of Scenarios Based on Statecharts. in: Proceedings of
the European Software Engineering Conference (ESEC’95). LNCS 989. Springer, Berlin 1995. pp. 254-271.
[Hsia et al. 94] P. Hsia, J. Samuel, J. Gao, D. Kung: Formal Approach to Scenario Analysis. in: IEEE
Soft-ware 11,2 (March 1994). pp.33-41.
[Jacobson et al. 92] I. Jacobson, M. Christersson, P. Jonsson, G. Övergaard: Object-Oriented Software
Enginee-ring - A Use-Case Driven Approach. Addison-Wesley, Reading MA, 1992.
[Jacobson 95] I. Jacobson: The Use-Case Construct in Object-Oriented Software Engineering. in: [Carroll 95]
pp. 309-336
[Jacobson et al. 95] I. Jacobson, M. Ericsson, A. Jacobson: The Object Advantage. Business Process
Reenginee-ring with Object Technology. Addison-Wesley, Workingham, 1995.
[Rolland et al. 96] C. Rolland, C. Ben Achour, C. Cauvet, J. Ralyté, A. Suttcliffe, N.A.M. Maiden, M. Jarke, P. Haumer, K. Pohl, E. Dubois, P. Heymans: A Proposal for a Scenario Classification
Frame-work. CREWS Report 96-01. http://SunSite.Informatik.RWTH-Aachen.DE/CREWS/ reports.htm. RWTH Aachen, 1996.
[Rubin, Goldberg 92] K. Rubin, A. Goldberg: Object behaviour analysis. in: Communications of ACM 35,
September 1992. pp. 48-62.
[Rumbaugh et al. 91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen: Object-Oriented Modeling
and Design. Prentice Hall, Englewood Cliffs, NJ 1991.
[Schreiber et al. 93] G. Schreiber, B. Wielinga, J. Breuker (eds.): KADS. A Principled Approach to
Knowledge-Based System Development. Knowledge Knowledge-Based Systems vol. 11. Academic Press, London 1993 [Schreiber et al. 94] G. Schreiber, B. Wielinga, R. de Hoog, H. Akkermans, W. van de Velde: CommonKADS:
A Comprehensive Methodology for KBS Development. in: IEEE Expert, December 1994. pp. 28-37.
[Shadbolt et al. 93] N. Shadbolt, E. Motta, A. Rouge: Constructing Knowledge-Based Systems, in: IEEE Software
(November 1993), pp. 34-38.
[Stefik 95] M. Stefik: Introduction to Knowledge Systems. Morgan Kaufmann Publishers, San Francisco,
CA 1995.
[Sisyphus-I] Problem Statement for Sisyphus: Models of Problem Solving. in: International Journal of Human-Computer Studies. (40)2, 1994. pp.187-192.
[UML 97] The Unified Modeling Language. version 1.1. Rational Software Corp. available at: http:// www.rational.com/uml/documentation.html, September 1997.
[Weidenhaupt et al. 98] K. Weidenhaupt, K. Pohl, M. Jarke, P. Haumer: Scenario Usage in System Development: A Report on Current Practice. in: Proceedings of the third International Conference on Require-ments Engineering (ICRE’98), Colorado Springs, Colorado, USA, April 1998.