This article was originally published in a journal published by Elsevier, and the attached copy is provided by Elsevier for the author’s benefit and for the benefit of the author’s institution, for non-commercial research and educational use including without limitation use in instruction at your institution, sending it to specific colleagues that you know, and providing a copy to your institution’s administrator. All other uses, reproduction and distribution, including without limitation commercial reprints, selling or licensing copies or access, or posting on open internet sites, your personal or institution’s website or repository, are prohibited. For exceptions, permission may be sought for such use through Elsevier’s permissions site at: http://www.elsevier.com/locate/permissionusematerial Knowledge-Based Systems 18 (2005) 353–365 www.elsevier.com/locate/knosys co p y Integration of behavioural requirements specification within compositional knowledge engineering Daniela E. Herlea Damiana, Catholijn M. Jonkerb, Jan Treurb,*, Niek J.E. Wijngaardsa,b b a University of Calgary, Software Engineering Research Network, 2500 University Drive NW, Calgary, Alta, Canada T2N 1N4 Vrije Universiteit Amsterdam, Department of Artificial Intelligence, De Boelelaan 1081a, 1081 HV, Amsterdam, The Netherlands al Received 21 February 2002; accepted 31 May 2005 Available online 11 July 2005 Abstract rs on In this paper it is shown how specification of behavioural requirements from informal to formal can be integrated within knowledge engineering. The integration of requirements specification has addressed, in particular: the integration of requirements acquisition and specification with ontology acquisition and specification, the relations between requirements specifications and specifications of task models and problem solving methods, and the relation of requirements specification to verification. q 2005 Elsevier B.V. All rights reserved. 1. Introduction Au th or ’s pe Requirements Engineering (RE) addresses the development and validation of methods for eliciting, representing, analysing, and confirming system requirements and with methods for transforming requirements into more formal specifications for design and implementation. Requirements Engineering is one of the early but important phases in the software development life cycle. Numerous studies have revealed the misidentification of requirements as one of the most significant sources of customer dissatisfaction with delivered systems [1,2,3]. However, it is a difficult process, as it involves the elicitation, analysis and documentation of knowledge from multiple stakeholders of the system. There is an increased need to involve the users at this stage of the development life-cycle [4,5]. It is recognised that the users are the experts in their work and a thorough understanding of the requirements is achieved only by promoting effective communication with them during the requirements engineering process [6]. It is also argued that an effective requirements definition requires involvement and mutual * Corresponding author. Tel.: C20 598 7763; fax: C20 598 7653. E-mail addresses: danah@cpsc.ucalgary.ca (D.E. Herlea Damian), jonker@nici.ru.nl (C.M. Jonker), treur@few.vu.nl (J. Treur). URLs: http://www.nici.ru.nl/~catholj (C.M. Jonker), http://www.few. vu.nl/~treur (J. Treur). 0950-7051/$ - see front matter q 2005 Elsevier B.V. All rights reserved. doi:10.1016/j.knosys.2005.05.002 control of the process by all players, and that a good partnership between users and designers enables a high quality of the resulting system [7]. Requirements express intended properties of the system, and scenarios specify use-cases of the intended system (i.e. examples of intended user interaction traces), usually employed to clarify requirements. The process of requirements engineering within software development is an iterative process, in which a sharp borderline between defining requirements and constructing the system design is not always easy to draw. When an effective stakeholderdeveloper communication link is in place, on the basis of a (partially) constructed design description of the system, additional information may be elicited from the stakeholders (i.e. domain experts, users, system customers, managers). Furthermore, detailed requirements and scenarios can be developed which refer to this design description. Requirements can be expressed in various degrees of formality, ranging from unstructured informal representations (usually during initial requirements acquisition) to more structured semi-formal representations and formal representations. The interleaving of the process of requirements engineering and the process of design is emphasised in current research in the area of AI and Design, e.g. [8,9]. It is put forward that realistic design processes include both the manipulation of requirement specifications and the manipulation of design object specifications, resulting in a detailed description of a design object and a good 354 D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365 Section 4 briefly summarizes the relations between requirements and scenarios. Section 5 concludes the paper with a discussion. 2. Representation of requirements and scenarios on al co p y In the approach presented in this paper, the processes of requirements engineering and system development are integrated by a careful specification of the co-operation between the two. The manipulation process of a set of requirements and scenarios, and the manipulation process of a design object description (i.e. a description of the system) are intertwined in the following way. First the set of requirements and scenarios is made as precise as possible. This requires multiple interaction with and among the stakeholders. Based on that set a possible (partial) description is made of the system. The description of the system is used not only to validate the understanding of the current set of requirements and scenarios, but also to elicit additional information from the stakeholders. This leads to more requirements and scenarios and to more detailed requirements and scenarios. The process continues, alternating between manipulating a set of requirements and scenarios, and manipulating a description of a system. Adequate representations of requirements and scenarios are required for each part of the overall process, and, therefore, the relations between the different representation forms of the same requirement or scenario need to be carefully documented. One of the underlying assumptions on the approach presented in this paper is that a compositional design method will lead to designs that are transparent, maintainable, and can be (partially) reused within other designs. The construction of a compositional design description of the system that properly respects the requirements and scenarios entails making choices between possible solutions and possible system configurations. Such choices can be made during the manipulation of the set of requirements and scenarios, but also during the manipulation of the design object description. Each choice corresponds to an abstraction level. For each component of the system design further requirements and scenarios are necessary to ensure that the combined system satisfies the overall system requirements and scenarios. The different abstraction levels in requirements are reflected as levels of process abstraction in the design description during the manipulation of the compositional design description. Different representations of requirements and scenarios are discussed in Sections 2.1–2.3. The use of process abstraction levels is explained further in Section 3. An overview of the relations between representations of requirements and scenarios, and different levels of process abstraction is presented in Section 4. In Requirements Engineering the role of scenarios, in addition to requirements, has gained more importance, both pe rs understanding of the requirements. This perspective on design, applied in particular to the design of knowledgeintensive software, is employed throughout the paper. This is in contrast with the tradition in software engineering to separate the activity of manipulating software requirements from the ‘design of software’, the actual construction of the system design [10]; Sommerville 1985; [11–13,42]. Principled model-based methodologies for knowledge engineering, are, for example, Desire [14–16] and CommonKads [17] or Mike [18]. Here the emphasis is on specification of the (conceptual) model of the system being developed and not on specification of required behaviour properties of a system to be developed. A transparent distinction between specification of the structure of a system (or task or problem solving method) and its (behavioural) properties is not made. For example, in the AI and Design community a specification of the structure of a design object is often distinguished from a specification of function or behaviour; e.g. [8,9]. In recent research in knowledge engineering, identification and formalisation of properties of knowledge-intensive systems is addressed, usually in the context of verification or competence assessment [19–23]. Such properties can be used as a basis for requirement specifications. In this paper it is shown how specification of behavioural requirements from informal to formal can be integrated within knowledge engineering. From the basic ingredients in knowledge engineering methodologies the following are especially relevant to the integration of requirements specification: † knowledge level approaches to problem solving methods, e.g. [21], † ontologies, e.g. [24] and † verification, e.g. [19,20]. or ’s It has to be defined how requirements specification relates to these basic ingredients. Therefore, integration of requirements specification within a principled knowledge engineering methodology has to address, in particular: Au th † behavioural requirements and ontologies. Integration of requirements acquisition and specification with ontology acquisition and specification † behavioural requirements and compositionality. Relations between requirements specifications and specifications of task models with tasks and problem solving methods at different levels of (process) composition † behavioural requirements and verification. Relation of requirements specification to verification These aspects are addressed in this paper. The different forms of representation of requirements and scenarios are presented in Section 2, for reasons of presentation illustrated by a simple example. In Section 3 refinement of requirements related to different proces abstraction levels (e.g. as in task or task/method hierarchies) is addressed. 355 D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365 co p y other hand, an advantage of using formal descriptions is that they can be manipulated automatically in a mathematical way, for example in the context of verification and the detection of inconsistencies. Furthermore, the process of formalising the representations contributes to disambiguation of requirements and scenarios (in contact with stakeholders). At the same time however, a formal representation is less appropriate as a communication means with the stakeholders. Therefore, in our approach in the overall development process, different representations and relations between them are used: † informal or structured semi-formal representations (obtained during the process of formalisation) in contact with stakeholders and designers of the system, and † related formal representations to be used by the designers during the construction of the design. on al Independent of the measure of formality, each requirement and each scenario can be represented in a number of different ways, and/or using different representation languages. Examples are given below. When manipulating requirements and scenarios, different activities can be distinguished (see Fig. 1). Requirements and scenarios are † elicited from the stakeholders, † checked for ambiguities and inconsistencies; † they are reformulated in a more precise or more structured form, and † represented in different forms (informal, semi-formal, and formal) to suit different purposes like communication with stakeholders or the construction of a design description, and † they are refined across process abstraction levels (which is addressed in Section 3). 2.1. Informal representations Different informal representations can be used to express the same requirement or scenario. Representations can be made, for example, in a graphical representation language, Au th or ’s pe rs in academia and industry practice [25,26]. Scenarios or use cases are examples of interaction sessions between the users and the system [26,27]; they are often used during the requirement engineering, being regarded as effective ways of communicating with the stakeholders (i.e. domain experts, users, system customers, managers, and developers). The initial scenarios can serve to verify (i.e. check the validity in a formal manner) the requirements specification and (later) the system prototypes. Evaluating the prototypes helps detecting misunderstandings between the domain experts and system designers if, for example, the system designers made the wrong abstractions based on the initial scenarios. In our approach requirements and scenarios both are explicitly represented, and play a role of equal importance. Having them both in a requirements engineering process, provides the possibility of mutual comparison. The requirements can be verified against the scenarios, and the scenarios can be verified against the requirements. By this mutual verification process, ambiguities and inconsistencies within and between the existing requirements or scenarios may be identified, but also the lack of requirements or scenarios. In particular, scenarios may be identified for which no requirements were formulated yet, and requirements may be identified for which no scenarios were formulated yet. As stated above, requirements and scenarios are seen as effective ways of communicating with the stakeholders. This can only be true if requirements and scenarios are represented in a well-structured and easy to understand manner and are precise enough and detailed enough to support the development process of the system. Unfortunately, no standard language exists for the representation of requirements and scenarios. Formats of varying degrees of formality are used in different approaches [13]. Informally represented requirements and scenarios are often best understood by the stakeholders (although also approaches exist using formal representations of requirements in early stages as well [28]). Therefore, continual participation of stakeholders in the process is possible. A drawback is that the informal descriptions are less appropriate when they are used as input to actually construct a system design. On the Fig. 1. Representations from informal to formal. 356 D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365 A reformulation can lead to structured requirements in a semi-formal form that provide more detail, for example R1 can be reformulated to R1.1, but also to two parts: or a natural language, or in combinations of these languages. Scenarios, for instance, can be represented using a format that supports branching points in the process, or in a language that only takes linear structures into account. A simple example of a requirement R1 on a system to control a chemical process is the following: A requirement is a general statement about the (required) behaviour of the system to be designed. This statement is required to hold for every instance of behaviour of the system. In contrast to this, a scenario is a description of a behaviour instance (e.g. to be read as an instance of a system trace the system has to show, given the user behaviour in the scenario). An example of an informal representation of a scenario is: Requirement R1b.1: at any point in time if the system provided as output an indication that the situation is explosive and after this the user gave an input that it has to be resolved, then the system shall generate output that the heater is turned off al co p y Requirement R1 For situations that the temperature and pressure are high the system shall give a red alert and turn the heater off. Requirement R1a.1: at any point in time if the system received input that the temperature is high and the pressure is high then the system shall generate as output a red alert and an indication that the situation is explosive 2.2. Structured semi-formal representations pressure is high pe Both requirements and scenarios can be reformulated to more structured and precise forms. th or ’s 2.2.1. Requirements To check requirements for ambiguities and inconsistencies, an analysis that seeks to identify the parts of a given requirement formulation that refer to the input and output of the system is useful. Such an analysis often provokes a reformulation of the requirement into a more structured form, in which the input and output references are made explicitly visible in the structure of the formulation. Moreover during such an analysis process the concepts that relate to input can be identified and distinguished from the concepts that relate to the output of the system. Possibly the requirement splits in a natural manner into two or more simpler requirements. This often leads to a number of new (representations of) requirements and/or scenarios. For example, the following requirement may be found as a result of such an analysis: Au temperature is high rs Note that this scenario describes one of the behaviour instances for which requirement R1 holds. Requirement R1a.1 can also be represented graphically, for example, by (here each of the pairs of arrows means that both arrows of the pair occur at the same time): on Scenario S1 The temperature and pressure are high. A red alert is generated and the heater is turned off. Requirement R1.1: at any point in time if the system received input that the temperature is high and the pressure is high then the system shall generate as output a red alert and an indication that the situation is explosive, and after the user gives an input that it has to be resolved, the system gives output that the heater is turned off red alert system situation is explosive As a specific case, also requirements referring only to input or only to output can be encountered. For requirements formulated in such a structured manner the following classification can be made: † requirements on input only, independent of output (input requirements), † requirements on output only, independent of input (output requirements), and † requirements relating output to input The latter type of requirements can be categorised as: † function or behaviour requirement (output is dependent on input: input-output-dependency) † environmental requirement or assumption (input is dependent on output: output-input-dependency) The environment is not within the scope of the software development; it cannot be ‘tuned’ to exhibit particular properties. Therefore, when stating properties of the environment (which includes users) of the system (output– input–dependency), the term ‘requirement’ is avoided and the term ‘assumption’ is used. As such, only assumptions can be made on its behaviour and properties. The term ‘requirements’ is used for those parts of the system that are within the scope of designable parts of the system. In addition, requirements can be categorised according to the kind of properties they refer to: 357 D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365 † static requirements, or † dynamic requirements. † represent the temporal structure described implicitly in the sequence of events. For nontrivial dynamic requirements a temporal structure has to be reflected in the representation. This entails that terms such as ‘at any point in time’, ‘at an earlier point in time’, ‘after’, ‘before’, ‘since’, ‘until’, ‘next’ are used to clarify the temporal relationships between different fragments in the requirement. The input and output terms used in the structured reformulations form the basis of an ontology of input and output concepts. Construction of this ontology takes place during the reformulation of requirements. Acquisition of a (domain or task or method) ontology is then integrated within requirements engineering (requirements engineering contributes at least to part of the ontology acquisition). For the requirements engineering process it is very useful to construct ontology of input and output concepts. For example, in R1b.1 the concepts indicated below in bold can be acquired. The scenario S1 shown earlier is reformulated into a structured semi-formal representation S1.1: y co p on al This scenarion covers both requirements given above Notice that from this scenario it is not clear whether or not always an input to be resolved leads to the heater being turned off, independent of what preceded this input, or whether this should only happen when the history actually was as described in the first two lines of the scenario. If the second part of the scenario is meant to be history independent, this second part is better specified as a separate scenario. However, we assume that in this example at least the previous output of the system situation is explosive on which the user reacts is a condition for the second part of the scenario (as also expressed in the requirements above). These considerations lead to the splitting of scenario S1.1 into the following two (temporally) independent scenarios S1a.1 and S1b.1: Scenario S1a.1 –input: temperature is high, pressure is high –output: red alert, situation is explosive Scenario S1b.1 –output: situation is explosive –input: to be resolved –output heater is turned off rs pe Requirement R1b.1: at any point in time if the system provided as output an indication that the situation is explosive, and after this the user gave an input that it has to be resolved, then the system shall generate output that the heater is turned off Scenario S1.1 –input: temperature is high, pressure is high –output: red alert, situation is explosive –input: to be resolved –output: heater is turned off or ’s This ontology later facilitates the formalisation of requirements and scenarios, as the input and output concepts are already defined. In summary, to obtain a structured semi-formal representation of a requirement, the following is to be performed: Au th † explicitly distinguish input and output concepts in the requirement formulation † define (domain and task/method) ontologies for input and output information † classify the requirement according to the categories above † make the temporal structure of the statement explicit using words like, ‘at any point in time’, ‘at an earlier point in time’, ‘after’, ‘before’, ‘since’, ‘until’, ‘next’. 2.2.2. Scenarios For scenarios, a structured semi-formal representation is obtained by performing the following: † explicitly distinguish input and output concepts in the scenario description † define (domain) ontologies for the input and output information 2.3. Formal representations A formalisation of a scenario can be made by using formal ontologies for the input and output, and by formalising the sequence of events as a temporal trace. Thus a formal temporal model is obtained, for example as defined in [16,19,20]. To obtain formal representations of requirements, the input and output ontologies have to be chosen as formal ontologies. In the example this can be done, for example by formalising a conceptual relation of the form A is B, with as meaning that the object A has property B, in a predicate form B(A). For example ‘the situation is explosive’ is formalised by explosive(situation), where situation is an object and explosive a predicate. This format can be used within an appropriate subset or extension of predicate logic. For example, requirement R1a.1 can also be represented formally in combined symbolic and graphical form by the following: 358 D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365 temperature(high) To summarise, formalisation of a requirement or scenario on the basis of a structured semi-formal representation is achieved by: red alert system explosive(situation) y al co p This results in a temporal formula F for a requirement and in a temporal model M for a scenario. Checking a temporal formula, which formally represents a requirement, against a temporal model, formally representing a scenario, means that formal verification of requirements against scenarios can be done by model checking. A formal representation M of a scenario S and a formal representation F of a requirement are compatible if the temporal formula is true in the model. For example, the temporal formula R1b.2 is indeed true for the model S1. 2, i.e. the explosive situation occurred at time point 2 in the scenario, at time point 3 (which is later than 2) the system received input to_be_resolved, and at time point 4 (again later than 3), the system has as output turn_off(heater). However, requirement R1b.2 would also be true in the following two scenarios. Scenario S2 is an example of a situation in which the system turns off the heater when this is not appropriate, scenario S3 is an example of a situation in which the system waits too long before it turns off the heater (which might lead to an explosion). or ’s pe rs In addition, the temporal structure, if present in a semiformal representation, has to be expressed in a formal manner. Using the formal ontologies, and a formalisation of the temporal structure, a mathematical language is obtained to formulate formal requirement representations. The semantics are based on compositional information states, which evolve over time. An information state M of a component D is an assignment of truth values {true, false, unknown} to the set of ground atoms that play a role within D. The compositional structure of D is reflected in the structure of the information state. The set of all possible information states of D is denoted by IS(D). A trace M of a component D is a sequence of information states (Mt)t2N in IS(D). The Temporal Trace Language TTL is a language in the family of languages to which also situation calculus [29], event calculus [30], and fluent calculus [31] belong. It is defined as follows. Given a trace M of component D, the information state of the input interface of component C at time point t of the component D is denoted by stateD(M, t, input(C)), where C is either D or a sub-component of D. Analogously, stateD(M, t, output(C)), denotes the information state of the output interface of component C at time point t of the component D. These formalised information states can be related to statements via the formally defined satisfaction relation ~, comparable to the Holdspredicate in situation calculus. Behavioural properties can be formulated in a formal manner, using quantifiers over time and the usual logical connectives such as not, &, 0. An alternative formal representation of temporal properties (using modal and temporal operators) within Temporal Multi-Epistemic Logic can be found in [47]. For example, in TTL the requirement R1b.1 can be represented formally by: † choosing formal ontologies for the input and output information † formalisation of the temporal structure on pressure(high) Au th In this formalisation of R1b.1 the word ‘after’ is represented by indicating that the time point t at which to_be_resolved appeared on the input is greater than some time point t 0 at which the system reported that the situation is explosive on its output. Scenario S1.1 can be represented formally by the temporal model that is defined as follows: Scenario S2 The temperature and the pressure are high The system generates a red alert and turns off the heater, The temperature and the pressure are medium The temperature is low and the pressure is medium The system turns off the heater Scenario S3 The temperature and the pressure are high The system generates a red alert and turns off the heater, The system increases the heater The system increases the heater An explosion occurs The system turns off the heater Furthermore, the requirement would also be true in a scenario in which the system waited with turning off the heater, maybe even first increasing the heater for some time (Scenario S4). Scenario S4 The temperature and the pressure are high The system indicates an explosive situation and a red alert The user indicates that the situation is to be resolved The system increases the heater The system again increases the heater 359 D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365 An explosion occurs The system turns off the heater. Based on these reformulations (that also affect the ontologies), the requirement engineers made the following representation of R1b.2 in TTL: This last scenario has semi-formal scenario S4.1 and is formalised as scenario S4.2: Scenario S4.1 –input: temperature high pressure high –output: explosive situation red alert –input: to be resolved –output: increase heater – output:increase heater –input: explosion occurred – output:turn off heater. co p y Requirement R1b.4 is true in scenario S1.2 (let prev be the function: n/nK1 and succ: n/nC1), but is not true in the sketched unwanted scenarios like S3.1. 3. Requirements refinement and process composition levels on al The requirements engineering process considers the system as a whole, in interaction with its stakeholders. However, during a design process, often a form of structuring of the system is used. Sub-processes are distinguished, for example in relation to development or selection of a task or task/method hierarchy. For the processes at the next lower process abstraction level, also requirements can be expressed. Thus a distinction is made between † stakeholder requirements and stakeholder scenarios (for the top level of the system, elicited from stakeholders, such as users, customers) and † designer requirements and designer scenarios (for the lower process abstraction levels, constructed by requirement engineers and designers). rs or ’s pe In other words, requirement R1b.2 leaves too many possibilities for the system’s behaviour, and, being a formalisation of R1b.1, so do the requirements that form the reason for formulating R1b.1, i.e. R1a.1, and R1.1. During the requirement engineering process this has to be resolved in contact with the stakeholders. In this case, the semi-formal R1.1 and R1a.1, and the formal R1b.2 have to be reformulated. After a discussion with the stakeholders, R1.1 is reformulated into: Au th Requirement R1.2: at any point in time if the system received input that the temperature is high and the pressure is high then at the next point in time the system shall generate as output a red alert and an indication that the situation is explosive, and at the next point in time after the user gives an input that it has to be resolved, the system gives output that the heater is turned off And requirement R1b.1 is reformulated into: Requirement R1b.3: at any point in time if the system provided as output an indication that the situation is explosive, and at the next time point after the user gave an input that the situation has to be resolved, then the system shall generate output that the heater is turned off Designer requirements and scenarios are dependent on a description of the system. Requirements on properties of a sub-component of a system reside at a next lower level of process abstraction compared to the level of requirements on properties of the system itself. Often sets of requirements at a lower level are chosen in such a way that they realise a next higher-level requirement. This defines a process abstraction level refinement relation between requirements. These process abstraction refinement relationships can also be used to verify requirements. For example, if the refinements of a requirement to the next lower process abstraction level all hold for a given system description, then the refined requirement can be proven to hold for that system description. Similarly, scenarios can be refined to lower process abstraction levels by adding the interactions between the sub-processes. At each level of abstraction, requirements and scenarios employ the terminology defined in the ontology for that level. In the example used above, for the structured semi-formal requirements two processes can be distinguished: interpret process info input information of type: temperature is high, pressure is high output information of type: situation is explosive 360 D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365 generate actions input information of type: situation is explosive output information of type: red alert, heater is turned off y At the next lower abstraction level of these two processes the following requirements can be formulated, as a refinement of the requirements given earlier: interpret process info (IPI) Requirement R1int.1: at any point in time if the component received input that the temperature is high and the pressure is high then the component shall generate as output an indication that the situation is explosive co p Furthermore, scenarios S1a.1 and S1b.1 given earlier can be refined to The semi-formal scenarios S1inta.1 and S1intb.1 are reformulated into formal scenarios S1inta.2 and S1intb.2, respectively. These formal scenarios are shown below: pe rs Requirement R1actb.1: at any point in time if the component received input that the situation is explosive, and after this it received an input that it has to be resolved, then the component shall generate output that the heater is turned off on Requirement R1acta.1: at any point in time if the component received input that the situation is explosive, then the component shall generate as output a red alert al generate actions (GA) Au th or ’s The semi-formal requirements R1int.1, R1acta.1, and R1actb.1 are reformulated in the formal requirements R1int. 2, R1acta.2, and R1actb.2, respectively. These formal requirements are given below: Fig. 2. Process abstraction level refinements 361 D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365 † between scenarios at different process abstraction levels (Fig. 2), † between requirements and scenarios at the same process abstraction level (Figs. 1–3) † among requirements at the same level of formality (Fig. 3) † between requirements and scenarios at the same level of formality (Fig. 3). 4. Traceability relations for requirements and scenarios y As requirements and scenarios form the basis for communication among stakeholders (including the system developers), it is important to maintain a document in which the requirements and scenarios are organised and structured in a comprehensive way. This document is also important for maintenance of the system once it has been taken into operation. Due to the increase in system complexity nowadays, more complex requirements and scenarios result in documents that are more and more difficult to manage. The different activities in requirements engineering lead to an often large number of inter-related representations of requirements and scenarios. In this section an overview is given of the traceability relations, after which the traceability relations in the example are shown, and finally the use of traceability relations for verification is described. co p These relationships are often adequately specified using hyperlinks. This offers traceability; i.e. relating relevant requirements and scenarios as well as the possibility to ‘jump’ to definitions of relevant requirements and scenarios. Thus requirements and scenarios resulting from an extensive case-study have been placed in a hyperlinked structure [32]; see Fig. 3, which combines Figs. 1 and 2. al 4.2. Traceability relations for the example rs The explicit representation of these traceability relations is useful in keeping track of the connections; traceability relationships can be made explicit: The diagram shown in Fig. 3 can be used to depict the current relationships of the requirements and scenarios. In Fig. 4 the relationships are depicted which are explained in Section 2, right up to the point when R1b.2 is determined to be incorrect. In this figure alternative reformulations are shown for both R1 and S1. For example R1 can be reformulated into R1.1, but also in two requirements R1a.1 and R1b.1. The following relationships between requirements and scenarios hold (not depicted in Fig. 4): on 4.1. Overview of traceability relations requirement R1 is true in scenario S1 requirement R1.1 is true in scenario S1.1 Au th or ’s pe † among requirements at the same process abstraction level (Fig. 1), † between requirements at different process abstraction levels (Fig. 2), † among scenarios at the same process abstraction level (Fig. 1), Fig. 3. Traceability relations. 362 D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365 process abstraction level 1 form sem l rma info l rma i-fo { al R1b.2 R1b.1 R1a.1 } R1.1 R1 S1b.1 S1.1 S1 S2 S3 S4.2 S1.2 { S1a.1 } S4.1 S4 form sem l rma info l rma i-fo { al R1b.4 R1b.3 R1a.1 } R1.2 R1 S1 S2 S3 S4.2 S1.2 S1b.1 S1.1 co p process abstraction level 1 y Fig. 4. Traceability relationships depicting the situation when R1b.2 is determined to be incorrect. { S1a.1 } S4.1 S4 al Fig. 5. Traceability relationships depicting the correct requirements and scenarios. Fig. 6 depicts the relations between requirements and scenarios at different levels of process abstraction. As shown, requirement R1.2 at process abstraction level 1 is refined into requirements R1int.1, R1acta.1, and R1actb.1 at process abstraction level 2. The same holds for the set of requirements consisting of R1a.1 and R1b.3. These are refined by the same set of requirements as R1.2. The scenarios S1a.1 and S1b.1 at process abstraction level 1 are refined by the scenarios Sinta.1 and S1intb.1 at process abstraction level 2, respectively. At process abstraction level the semi-formal scenarios S1inta.1 and S1intb.1 are reformulated into the formal scenarios S1inta.2 and S1intb. 2, respectively. on requirement R1a.1 is true in scenario S1a.1 (not shown) requirement R1b.1 is true in scenario S1b.1 (not shown) requirement R1b.2 is true in scenario S1.2 requirement R1b.2 is true in scenario S4.2 (unwanted scenario) pe rs After the discovery of the incorrect requirement R1b.2 a number of requirements is reformulated, resulting in the situation depicted in Fig. 5. The requirements R1.2, R1b.3 and R1b.4 replace requirements R1.1, R1b.1 and R1b.2 of Fig. 4, respectively. The following relationships between requirements and scenarios hold in Fig. 5: or ’s requirement R1 is true in scenario S1 requirement R1.2 is true in scenario S1.1 requirement R1a.1 is true in scenario S1a.1 (not shown) requirement R1b.3 is true in scenario S1b.1 (not shown) requirement R1b.4 is true in scenario S1.2 requirement R1b.4 is not true in scenario S4.2 (unwanted scenario). th process abstraction level 1 sem Au l rma info sem l rma i-fo R1b.4 S1.1 S1 form Verification of requirements and scenarios is facilitated by keeping track of traceability relations. Traceability relations over process abstraction levels (vertical direction in Fig. 3) al l R1b.3 rma i-fo {R1a.1 } R1.2 R1 process abstraction level 2 rma info form 4.3. Traceability relations and verification S2 S3 al R1acta.1 R1int.1 R1actb.1 S4.2 S1.2 S1b.1 {S1a.1 } S4.1 S4 S1inta.2 S1inta.1 S1intb.2 S1intb.1 l Fig. 6. Traceability relationships for two levels of process abstraction. 363 D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365 5. Discussion or ’s co p on pe rs Examples of ‘horizontal’ verification. When the formal scenario S1.2 is fulfilled, then it can be concluded that the semi-formal scenario S1b.1 is also fulfilled. The scenario S2 is an ‘isolated’ scenario: it is not related to any requirement. The informal scenario S2 is an ‘unreformulated’ scenario: it is not related to a semi-formal scenario. Verification of requirement R1b.2 against the (unwanted) scenarios (e.g. S4.2) caused the reformulation of that requirement, resulting in requirement R1b.3. al Example of ‘vertical’ verification. When requirements R1int.1, R1acta.1 and R1actb.1 are all fulfilled, then it can be concluded that requirement R1.2 is also fulfilled. Traceability relations among requirements and scenarios at one process abstraction level (horizontal direction in Fig. 3) enable verification of requirements and scenarios in terms of each other. Scenarios can be employed to verify requirements, requirements can be employed to verify scenarios, isolated requirements and scenarios can be detected, et cetera. Requirements Engineering is today a well-studied field of research within Software Engineering; e.g. [1,2]. In recent years requirements engineering for distributed and agent systems has been studied, e.g. [33,34]. The requirements specification language ALBERT II [28,34], based on real-time temporal logic, has been developed for the area of real-time distributed systems, but has been tuned to the agent perspective as well. Reusable requirements patterns play an important role. In [33,35, 36] the KAOS approach to Requirements Engineering of composite systems is described. In this approach a requirement for the overall system is called a goal. What is called a requisite is a requirement on part of the dynamics controllable by a single agent or (given) environment component. Goal refinement is used to decompose goals into requisites via AND/OR graphs. This can be compared to our notion of requirements refinement over process abstraction levels. The term assumption is used to indicate requisites on (given) environmental components. The process of making requirements more precise is supported by using both semi-formal and formal representations for requirements. Part of this process is to relate concepts used in requirements to input and output of the system. Since requirement specifications need system-related concepts, it has been shown how the acquisition and specification of requirements goes hand in hand with the acquisition and specification of ontologies. Examples of known properties (based on ontologies) that can be related to requirements are properties of problem solving methods for diagnosis [19,20,37], and properties of propose-and-revise problem solving methods [23]. The formalisation of behaviour requirements has to address the semantics of the evolution of the system (input and output) states over time. In this paper the semantics of properties of compositional systems is based on the temporal semantics approach, which can be found in the development of a compositional verification method for knowledgeintensive systems. For diagnostic process models, see [19, 20]; for co-operative information gathering agents, see [14]; for negotiating agents, see [46]. By adopting the semantical approach underlying the compositional verification method, a direct integration of requirements engineering with the specification of properties of problem solving methods and their verification could easily be established. The temporal trace language TTL used in our approach is much more expressive than standard or extended modal temporal logics as described, for example, in [39–41,45], in a number of respects. In the first place, it has order-sorted predicate logic expressivity, whereas the standard temporal logics are propositional. Secondly, the explicit reference to time points and time durations offers the possibility of modelling the dynamics of real-time phenomena, which may be useful for the development of knowledge-based systems for real-time applications, just as the languages ALBERT II and KAOS discussed above are. y enable a compositional approach to verification. Requirements and scenarios at a specific process abstraction level are verified in terms of requirements and scenarios at the next (lower) process abstraction level [19,20]. Requirements and scenarios which are not further decomposed in requirements and scenarios at a lower process abstraction level are considered to be ‘primitive’, and need to be verified in the specification of the system. Ideally these requirements and scenarios are easier to verify than the more complex, broadly stated requirements and scenarios higher up in the process abstraction levels. Au th Requirements describe the required properties of a system (this includes the functions of the system, structure of the system, static properties, and dynamic properties). In applications to agent-based systems, the dynamics or behaviour of the system plays an important role in description of the successful operation of the system. Requirements specification has both to be † informal or semi-formal (to be able to discuss them with stakeholders), and † formal (to disambiguate and analyse them and establish whether or not a constructed model for a system satisfies them). Typical software requirements engineering practices are geared toward the development of a formal requirements specification. 364 D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365 References on al co p y [1] A.M. Davis, Software requirements: Objects, Functions, and States, Prentice Hall, New Jersey, 1993. [2] I. Sommerville, P. Sawyer, Requirements Engineering: a Good Practice Guide, Wiley, Chicester, England, 1997. [3] G. Kontonya, I. Sommerville, Requirements Engineering: Processes and Techniques, Wiley, New York, 1998. [4] C. Clavadetscher, User involvement: key to success, IEEE Software, Requirements Engineering Issue (1998) 30–33. [5] The Standish Group, (1995): The High Cost of Chaos: http://www. standishgroup.com. [6] H.R. Beyer, K. Holtzblatt, Apprenticing with the customer, Communications of the ACM 38 (5) (1995) 45–52. [7] K. Holzblatt, K.R. Beyer, Requirements gathering: the human factor, Communications of the ACM 38 (5) (1995) 31. [8] J.S. Gero (Ed.), Artificial Intelligence in Design’96, Kluwer Academic Publishers, Dordrecht, 2002. [9] J.S. Gero, F. Sudweeks (Eds.), Artificial Intelligence in Design’98, Kluwer Academic Publishers, Dordrecht, 1998. [10] M.A. Jackson, Principles of Program Design, Academic Press, New York, 1975. [11] G. Booch, Object Oriented Design with Applications, Benjamins Cummins Publishing Company, Redwood City, 1991. [12] J.C. van Vliet, Software Engineering: Principles and Practice, Wiley, Chicester, 1993. [13] R.S. Pressman, Software Engineering: A practitioner’s approach McGraw-Hill Series in Computer Science, Fourth ed., McGraw-Hill Companies Inc., New York, 1997. [14] C.M. Jonker, J. Treur, Compositional Verification of multi-agent systems: a formal analysis of pro-activeness and reactiveness in: W.P. de Roever, H. Langmaack, A. Pnueli (Eds.), Proceedings of the International Workshop on Compositionality, COMPOS’97 Lecture Notes in Computer Science vol. 1536, Springer Verlag, Berlin, 1998, pp. 350–380. [Extended version in Int. J. Cooperat. Inform. Syst., vol. 11, 2002, pp. 51–92]. [15] F.M.T. Brazier, C.M. Jonker, J. Treur, Principles of component-based design of intelligent agents, Data and Knowledge Engineering, Vol. 41, pp1–28, (2002). [16] F.M.T. Brazier, J. Treur, N.J.E. Wijngaards, M. Willems, Temporal semantics of compositional task models and problem solving methods, Data and Knowledge Engineering 29 (1) (1999) 17–42; Preliminary version in: B.R. Gaines, M.A. Musen (eds.), Proceedings of the 10th Banff Knowledge Acquisition for Knowledge-based Systems workshop, KAW’96, Calgary: SRDG Publications, Department of Computer Science, University of Calgary, 1996, pp. 15/1–15/17 [17] A.Th. Schreiber, B.J. Wielinga, J.M. Akkermans, W.van.de Velde, R. de Hoog, CommonKads: a comprehensive methodology for KBS development, IEEE Expert 9 (6) (1994). [18] J. Angele, D. Fensel, D. Landes, R. Studer, Developing knowledgebased systems with MIKE, Journal of Automated Software (1998). [19] F. Cornelissen, C.M. Jonker, J. Treur, Compositional verification of knowledge-based systems: a case study in diagnostic reasoning in: E. Plaza, R. Benjamins (Eds.), Knowledge Acquisition, Modelling and Management, Proceedings of the 10th European Knowledge Acquisition Workshop, EKAW’97 Lecture Notes in AI vol. 1319, Springer, Berlin, 1997, pp. 65–80. [20] F. Cornelissen, C.M. Jonker, J. Treur, Compositional Verification of Knowledge-Based Task Models and Problem Solving Methods. Knowledge and Information Systems Journal, Vol. %, 2003, pp. 337– 367. [21] D. Fensel, Assumptions and limitations of a problem solving method: a case study in: B.R. Gaines, M.A. Musen (Eds.), Proceedings of the 9th Banff Knowledge Acquisition for Knowledge-based Systems Workshop, KAW’95, SRDG Publications, Department of Computer Science, University of Calgary, Calgary, 1995. pe rs Third, the possibility to quantify over traces allows for specification of more complex dynamics. As within most temporal logics, reactiveness and pro-activeness properties can be specified. In addition, in our language also properties expressing different types of adaptive behaviour can be expressed. For example an adaptive property such as ‘exercise improves skill’, or ‘the better the experiences, the higher the trust’ (trust monotonicity) which both are a relative property in the sense that it involves the comparison of two alternatives for the history. This type of adaptive property can be expressed in our language, whereas in standard forms of temporal logic different alternative histories cannot be compared. The same difference applies to situation calculus [29], event calculus [30], and fluent calculus [31]. Therefore, TTL is more suitable for requirements specification within the development of adaptive knowledge-based systems, than standard temporal logics, or KAOS, ALBERT II or these other calculi mentioned. Fourth, in TTL it is possible to define local languages for parts of a system. Especially in a compositional approach to Knowledge Engineering as in DESIRE, the distinctions between components, and between input and output and internal languages are crucial. They are supported by treating them as first class citizens in the language, which also entails the possibility to quantify over system parts and changing system parts over time. For example, this allows for specification of system configuration modification over time; cf. [43]. For some example systems requirements and scenarios have been elicited, analysed, manipulated, and formalised. The lessons learned from these case studies are: Au th or ’s † The process of achieving an understanding of a requirement involves a large number of different formulations and representations, gradually evolving from informal to semi-formal and formal. † Scenarios and their formalisation are, compared to requirements, of equal importance. † Categorisation of requirements on input, output and function or behaviour requirements, and distinguishing these from assumptions on the environment clarifies the overall picture. † Grouping requirements and scenarios in clusters gives a more global insight. † Keeping track on the various relations between different representations of requirements, between requirements and clusters, between requirements and scenarios, and many others, is supported by hyperlink specifications within a requirements document. In current and future research, further integration of requirements engineering in the compositional design method for multi-agent systems, Desire and, in particular, in its software environment is addressed. 365 D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365 on al co p y [36] A. van Lamsweerde, R. Darimont, E. Letier (1998), Managing Conflicts in Goal-Driven Requirements Engineering. IEEE Transactions on Software Engineering, Special Issue on Managing Inconsistency in Software Engineering. [37] V.R. Benjamins, Problem Solving Methods for Diagnosis. PhD Thesis, University of Amsterdam, Amsterdam, The Netherlands, 1993. [38] F.M.T. Brazier, C.M. Jonker, J. Treur, Principles of Compositional Multi-agent System Development in: J. Cuena (Ed.),, Conference on Information Technology and Knowledge Systems, IT&KNOWS’98 Proceedings of the 15th IFIP World Computer Congress, WCC’98 (1998), pp. 347–360. [39] M. Fisher, A survey of concurrent metateM—the language and its applications in: D.M. Gabbay, H.J. Ohlbach (Eds.), Temporal Logic— Proceedings of the First International Conference Lecture Notes in AI vol. 827 (1994), pp. 480–505. [40] E.M. Clarke, O. Grumberg, D.A. Peled, Model Checking, MIT Press, Cambridge, MA, 2000. [41] Z. Manna, A. Pnueli, Temporal Verification of Reactive Systems: Safety, Springer Verlag, Berlin, 1995. [42] A.P. Sage, J.D. Palmer, Software Systems Engineering, Wiley, New York, 1990. [43] M. Dastani, C.M. Jonker, J. Treur, A requirement specification language for configuration dynamics of multi-agent systems in: M. Wooldridge, G. Weiss, P. Ciancarini (Eds.), Proceedings of the Second International Workshop on Agent-Oriented Software Engineering, AOSE’01 Lecture Notes in Computer Science vol. 2222, Springer Verlag, Berlin, 2002, pp. 169–187. Extended version in: Int.J. of Intelligent System, vol. 19 (2004), pp. 277–300. [44] D. Herlea, C.M. Jonker, J. Treur, N.J.E. Wijngaards, Integration of behavioural requirements specification within knowledge engineering in: D. Fensel, R. Studer (Eds.), Proceedings of the 11th European Workshop on Knowledge Acquisition, Modelling and Management, EKAW’99 Lecture Notes in AI vol. 1621, Springer Verlag, Berlin, 1999, pp. 173–190. [45] C. Stirling, Modal and Temporal Properties of Processes, Springer Verlag, Berlin, 2001. [46] F.M.T. Brazier, F. Cornelissen, R. Gustavsson, C.M. Jonker, O. Lindeberg, B. Polak, J. Treur, Compositional Design and Verification of a Multi-Agent System for One-to-Many Negotiation, Proceedings of the Third International Conference on Multi-Agent Systems, ICMAS’98, IEEE Computer Society Press, California, 1998. pp. 49– 56 [Extended version in: Journal of Applied Intelligence, vol. 20 (2004), pp. 95–117. [47] J. Engelfriet, C.M. Jonker, J. Treur, Compositional Verification of Multi-Agent Systems in Temporal Multi-Epistemic Logic. In: J.P. Mueller, M.P. Singh, A.S. Rao (eds.), Intelligent Agents V. Lecture Notes in AI, Springer Verlag. Extended version in Journal of Logic, Language and Information, vol. 11, 2002, pp. 195–225. Extented version in: Journal of Logic, Language and Information, vol. 11 (2002), pp.195–225 Au th or ’s pe rs [22] D. Fensel, R. Benjamins, Assumptions in model-based diagnosis in: B.R. Gaines, M.A. Musen (Eds.), Proceedings of the 10th Banff Knowledge Acquisition for Knowledge-based Systems workshop KAW’96, SRDG Publications, Department of Computer Science, University of Calgary, Calgary, 1996, pp. 5/1–5/18. [23] D. Fensel, A. Schonegge, R. Groenboom, B. Wielinga, Specification and verification of knowledge-based systems in: B.R. Gaines, M.A. Musen (Eds.), Proceedings of the 10th Banff Knowledge Acquisition for Knowledge-based Systems workshop KAW’96, SRDG Publications, Department of Computer Science, University of Calgary, Calgary, 1996, pp. 4/1–4/20. [24] M. Musen, Ontology Oriented Design and Programming: a New Kind of OO in: J. Cuena (Ed.), Proceedings of the 15th IFIP World Computer Congress, WCC’98 Conference on Information Technology and Knowledge Systems, IT&KNOWS’98 (1998), pp. 17–20. [25] M. Erdmann, R. Studer, Use-cases and scenarios for developing knowledge-based systems in: J. Cuena (Ed.), Proceedings of the IFIP World Computer Congress, WCC’98 Conference on Information Technologies and Knowledge Systems, IT&KNOWS (1998), pp. 259–272. [26] K. Weidenhaupt, M. Pohl, M. Jarke, P. Haumer, Scenarios in system development: current practice IEEE Software,March/April 1998 pp. 34–45. [27] Potts, C., Takahashi, K. and ANton, A. Inquiry based requirements analysis, IEEE Software, 11(2), 1994. [28] E. Dubois, E. Yu, M. Petit, in: E. Dubois, E. Yu, M. Petit (Eds.), From Early to Late Formal Requirements Proceedings of the IWSSD’98, IEEE Computer Society Press, California, 1998. [29] J. McCarthy, P. Hayes, Some philosophical problems from the standpoint of artificial intelligence, Machine Intelligence 4 (1969) 463–502. [30] R. Kowalski, M. Sergot, A logic-based calculus of events, New Generation Computing 4 (67–95) (1986) 1986. [31] S. Hölldobler, M. Thielscher, A new deductive approach to planning, New Generation Computing 8 (225-244) (1990) 1990. [32] Herlea, D., Jonker, C.M., Treur, J., Wijngaards, N.J.E. A Case Study in Requirements Engineering: a Personal Internet Agent. Technical Report, Vrije Universiteit Amsterdam, Department of Artificial Intelligence. 1998. [33] A. Dardenne, A. van Lamsweerde, S. Fickas, Goal-directed requirements acquisition, Science in Computer Programming 20 (1993) 3–50. [34] E. Dubois, P. Du Bois, J.M. Zeippen, A Formal Requirements Engineering Method for Real-Time, Concvurrent, and Distributed Systems Proceedings of the Real-Time Systems Conference, RTS’95, 1995. [35] R. Darimont, A. van Lamsweerde, Formal refinement patterns for goaldriven requirements elaboration, Proc. Fourth ACM Symp. Foundation Software Eng. (FSE4) (1996) 179–190.