Requirements engineering is a central part of software projects. It is assumed that two third of all errors in software projects are caused by forgotten requirements or mutual misunderstandings in the requirement gathering process. Due to the inherent structure of project planning and the project management process, it is very unlikely that this problem will be solved unless the process itself is changed or we develop tools that possess some intelligence to facilitate the assessment of requirements. In this paper a position for the latter approach is formulated. It is argued that it is feasible to establish a domain ontology based on meta information and explanations that are represented as scripts. It is shown that this ontology has to be constructed in a dynamic way to re ect the dynamics of the requirements engineering process. Finally, it is sketched how use cases and test cases can be derived from this ontology.
The understanding of project requirements must be reached (according to the classical project management approach) in the very early stages of the project (initiation stage), in order to formulate the project scope statement.
The project scope statement describes the project's deliverables and the work that is to be accomplished to create them. Frequently, it is quite a coarse grained level of detail in which the conditions and capabilities of the intended system are described at that time. Nevertheless, this will build the basis for further planning during the next stages.
From a business point of view, this is a quite disadvantageous setting: the gathering and analysis of the key project deliverables and the decision of how to supply them is in a project phase before there is a signed contract. Consequently, the time and work in this phase is not payed by the intended customer-to-be. It is quite common in large projects to get compensation for feasibility studies, but this does not apply to all projects.
In summary, if this stage is not performed well, it is unlikely that the project will be successful in meeting the expectations of the stakeholders. 2
To understand the project requirements it is important to understand the background, i. e. the business processes from which the need of a new product or service has arisen. This helps to understand the stakeholder's needs, wants and expectations and what has to be achieved to satisfy a contract.
Alas, the setting of such a task is often quite complex. The general
background is often quite specialized and not easy to understand, business processes
are sometimes ill de ned. The terminology used by the stakeholders may di er
from the vocabulary of the requirements engineer or, even worse some terms may
be used with a slightly di erent semantics (which usually becomes apparent later
in the project). Last but not least, some terms may turn out to be not terms at
all but business processes (cf. [
Thus, there are numerous and well known reasons (cf. [
It would be necessary to describe the system and its background in a comprehensive and almost complete way to eliminate all sources of those mistakes. There are hardly any projects where there is time and budget for such a comprehensive approach. It is important to remember that in the initiation phase of a project a contract is not signed, i. e. there is no or insu cient compensation for an in-depth approach available.
Consequently, it is quite common to concentrate on the representation of
the functional requirements with use cases. A use case describes the interaction
between a system and a request that originates from outside of that system.
Use cases represent that interaction as a sequence of single steps and events to
achieve a speci c goal. There are several representation schemes (most common:
the Uml use case diagram in various versions) to graphically express this kind
of interaction. The meaning (or semantics) of the use case is not represented
by the well de ned building blocks of the formalism [
Admittedly, those representation formalisms have a certain beauty: they represent complex interactions in a compact way that may be perceived quickly (at least in comparison to lengthy (and often tiresome to read) de nitions in natural language). Due to their seeming clarity and formality they are often over-estimated. Nevertheless, they are deceptive with respect to their precision and expressiveness. There main limitations are:
2. The expressiveness of graphical representation schemes is limited per se to a fragment of rst order logic (existential quanti ed, conjunctive connected). Trying to extend the symbology by annotations (to cover modal or second order constructs) will increase the confusion, not the expressiveness. 3. Use cases represent the interaction in the communication between user and system. Commonly, they refer to sub processes and documents that are interchanged during those process steps without explaining the content in full detail. Thus, generally, it is not possible to decide by the study of a use case whether the process ow may lead to the desired result (i. e. the system output may be achieved, given the set of input).
After this synopsis of the requirements gathering process and the di culties that exist in avoiding misunderstandings it is concluded that either this process should be upvalued considerably (in terms of time and money), or tools for facilitating this process on a more semantic level should be applied.2
In the remaining part of this paper, an approach is sketched how existing Ai
concepts could be deployed for this purpose.
1 This is no new insight, as shown by Woods [
How can Ai facilitate the requirements engineering process, and, more speci
cally, how can Ai contribute to avoid misunderstandings? From an Ai
perspective, the problem is situated in the context of formalizing domain knowledge and
to explain and to communicate this knowledge (cf. [
Explanation can be regarded as the process by which we make sense of the
world [
At a very basic level explanation equals understanding: We believe that we
understand why a person is doing what he is doing if we can point to a script
that he or she is following [
As stated above, a script models a ow of action in a speci c setting. To
understand this setting, i. e. to interact in a limited communication [
But this approach is a methodology (cf. [
The classic example of Schank's theory is the restaurant script. The script theory
is closely related to Schank's concept of conceptual dependencies [
MBUILD: Building new information of old information (i.e. decide). MTRANS: Transfer of mental information (i.e. tell).
ATRANS: Transfer of an abstract relationship (i.e. give).
MOVE: Movement of a body part by its owner.
ATTEND: Focusing of a sense organ toward a stimulus (e.g. listen). The subject of the sentences is represented by S which is a role and con be instatiated by any agent. The script consists out of four scenes: Scene 1: Entering: S PTRANS S into restaurant, S ATTEND eyes to tables, S
MBUILD where to sit, S PTRANS S to table, S MOVE S to sitting position. Scene 2: Ordering: S PTRANS menu to S (menu already on table), S MBUILD choice of food, S MTRANS signal to waiter, waiter PTRANS to table, S MTRANS 'I want food' to waiter, waiter PTRANS to cook.
Scene 3: Eating: Cook ATRANS food to waiter, waiter PTRANS food to S, S
INGEST food.
Scene 4: Exiting: waiter MOVE write check, waiter PTRANS to S, waiter ATRANS
check to S, S ATRANS money to waiter, S PTRANS out of restaurant.
It is not compulsory to adopt the concept of conceptual dependencies to utilize
scripts. Nevertheless, it is necessary to de ne entities, roles and operations (i. e.
actions) in a way, that o ers some generality and transferability. Thus, a set of
universals with prede ned semantics and support for roles seems to be helpful.7
7 Further work will include an analysis how ongoing e orts on semantic modeling
could be integrated in this approach (cf. [
As sketched above, a script transforms one state of a airs into another state. States may be modeled adequately with a fragment of rst order logic (existential quanti ed, conjunctive connected predicates). Accordingly, entities, e. g. objects or actors, that are referred to in a script may be formalized as well by a set of attributes, i. e. as predicates. Generally, rst order logic is not su cient to model the dynamic interdependencies and actions in a domain, due to the necessity of modal, temporal or second order (quanti cation about predicates) constructs. These language constructs have to be provided by modeling the actions and roles accordingly. Thus, type restrictions and quanti cations on predicates or attributes have to be considered in the process of de ning and implementing roles.
Consequently, the static aspects (situations as constellations of entities at a given point in time) are modeled with a fragment of rst order logic. Actions, as well as operations on entities, permit more advanced constructs like quanti cation on predicates and additional quali ers. This augments the expressiveness of the whole formalism considerably. A script forms a context in which the semantics for at least one - and to avoid misunderstandings: exactly one - valid assignment and interpretation is provided.
This approach is computationally feasible, since the domain of the variables of the predicates are restricted in most application scenarios to reasonably sized sets of possible instantiations. 3.5
Generally, a software system is intended to be representationally and
inferentially adequate with respect to its application area. Thus, the entities in the
software system and their real world counterparts shall be describable by the
same attributes. Inferences over attributes and entities in the system shall hold
in reality and vice versa. Thus, the conceptualization of the application domain
in the software system shall model those entities, relationships and processes
that are essential for achieving the intended level of adequacy. Such a
conceptualization may be referred to as an ontology [
The ontology has to be dynamic: the project goals may be subject to change and therefore the underlying ontology respectively. Since a project is an unique endeavor we can not take some ontology from the shelf, but it is more likely that each project (even if located roughly in the same domain) will need its own ontology.
Such an ontology will be referred to as an agreed ontology to express that it shall represent the common understanding of the domain by all stakeholders of the project. The term agreed implies a certain dynamics as well in the process of de ning and re ning the ontology. It re ects the processes as mutual understanding as the project group grows and implies that the formalism should be mighty enough to tackle well known problems with respect to knowledge bases (frame problem, non-monotone logic, etc.). 3.6
Accordingly, there have to be building mechanisms for both: scripts as
constituents of an ontolgy and the ontology itself. Given the inherent structure of a
script as outlined above it lies at hand that scripts can be de ned by a
contextfree grammar. Basically, a context-free grammar has four components (cf. [
{ A designation of one of the nonterminals as start symbol.
Applied to this context, it is evident that scenes, roles and actions form the nonterminal symbols of this grammar. The terminal symbols are either domains of the syntactic variables, such as instantiations of roles (i. e. a speci c user or a speci c entity) or outcomes of a script, i. e. a state of a airs.
This shall be illustrated with a scenario where a device fails, and calls for
a technician. This scenario is taken from a setting that has been accomplished
by the Deutsche Telekom Laboratories [
The scenario is comprised of several actions that result in speci c situations,
i.e. events. The scenario is represented with a grammar in Backus-Naur form as
given below. The terminal symbols are enclosed with quotes. Head and tails of the
rules are separated by a '::=', ',' is used as concatenation and ';' as termination
symbol.
The terminal symbols in this example are placeholders for speci c instantiations
of roles, e. g. a speci c technician, location or device, or situations. A situation
s is a con guration (cf. sec. 3.4) which holds true for all state of a airs in the
system at a given point t in time.8 Thus: t s^ t 2 :s. It surely is a challenge
to model the action and role part in a way that supports explanations and
allows quanti cations. Nevertheless, although the exact de nition and modeling
of actions and roles may be demanding in speci c cases, it is considered that this
does not present an obstacle in principle to this approach. Since there are several
approaches documented and available, where this problem has been solved (c.f.
[
Scripts form the nonterminal vocabulary of an agreed ontoloy, the terminals are representations of outcomes of scripts. The challenge to de ne the rules for the ontology is quite demanding, since they model the order and interdependencies of scripts and the dynamics of the ontology depends on them.
The dynamics is achieved by adding new scripts to the ontology, removing and modifying existing scripts or changing the order of the scripts. This shall be sketched by extending the service scenario given above with further use cases from that domain. 9 Access and Service Control: Maintenance personnel are given key (e. g. RFID tags, access cards) for accessing facilities and identi cation at devices to be maintained. Tags store employee credentials, doors to be used, work orders as well as operations carried out. The usage of doors is monitored and alerts are generated if needed.
Inventory Management: Every asset may have one or more unique identi er.
This provides knowledge of the connected devices, their functionalities, and attributes. Automatic inventory of assets using xed and handheld readers helps locating displaced and mobile assets. Absence of a reading event can be used to detect stolen equipment.
Predictive Maintenance: Continuous monitoring of operational (e.g. load) and non-operational (e.g. temperature) parameters using sensors to predict breakdowns. Estimate individual maintenance intervals for di erent equipments. Using maintenance history (data logging) to analyze tradeo s between cost to maintain old equipment and investment in new equipment. Remote Control: Remotely monitor and query about the status of individual persons (in terms of location) and devices. Devices shall be recon gured remotely.
The script for access and service control was explained in detail in sec. 3.6. The other use cases may be represented as scripts in analogous way.10 A simple example grammar that models an ontology for this facillity management setting is given below:11 1. FacilityManagementOntology::= InventoryManagement, PredictiveMaintenance,
RemoteControl, AccessAndServiceControl;
2. InventoryManagement ::= establishedAutoID;
3. PredictiveMaintenance ::= establishedPMProcesses, remoteControl;
4. AccessAndServiceControl ::= establishedAASProcesses, remoteControl;
5. RemoteControl::= "establishedRemoteControl";
9 Additionally, it might be necessary to ensure global consistency of the outcomes of
the di erent scripts. The approach of assumption based truth maintenance systems
(Atms) [
It is obvious that the scenarios are not independent from each other but imply an order. Thus, to enable predictive maintenance remote monitoring has to be established. The granularity can be increased, by splitting the scenario of access and service control in two scenarios: an access control and a service control scenario. This leads to a change in the de nition of the inventory management process: 1. AccessAndServiceControl ::= remoteControl, AccessControl; 2. AccessControl ::= "establishedACProcesses"; 3. InventoryManagement::= AccessControl, establishedAutoId; It is possible to change a sequence or to edit the starting conditions or the outcome of a script. Thus, by manipulating the grammar the ontology of the domain of interest can be managed. In addition an Atms could administer the consistency of the general state of a airs of the model of the application domain. Since each script a ects the state of a airs of the whole system and the changes that have been applied by the operations of a script are recorded, each state of a airs can be tracked down to the scripts involved. Thus, it may be easily discovered, if starting conditions of a script never appear or if scripts lead to inconsistencies.
Since scripts not only model the interaction ow but are more detailed with respect to the semantics of the process and the outcome, scripts may even act as blue print for test cases. Consequently, this approach enables to transfer the methodology of test driven development to the requirement engineering process. As production code in this setting has to pass the prede ned test cases, new requirements would have to be formulated as scripts and checked against the so far agreed ontology. Consequently, it can be decided for each requirement (that is well-formed in terms of the ontology's grammar) whether it may be derived, is subsumed, leads to contradictions or augments the set of requirements gathered so far. 4
In this paper a position was formulated that points out some general de cits in requirements engineering. It was argued that the tools to represent functional requirements of a non-trivial software system are commonly restricted in their semantic expressiveness and thus inept to establish mutual understanding concerning those processes. Misunderstandings will easily arise due to the ill de ned semantics of the representation formalism: each stakeholder will underlay his or her individual semantic reference system for understanding. To describe the system`s functional requirements in a comprehensive way in natural language is possible in theory but not feasible either. It is known from experience that large volumes are scarcely read by their target audience.
Thus, it is argued that this problem can be solved by an agreed ontology that models the understanding of the target system in a way that explanations on functional requirements can be given. This ontology should be implemented in a system that forms the semantic grounding of all assumptions about the domain of interest and the interactions within the future software system. Misunderstandings and contradictions can be managed due to its semantic-enabled constituents, i. e. scripts, and the internal management of the system. 5
Although the argumentation in this paper did not provide detailed examples, it should be comprehensible, that this approach is technically feasible and will hold true. Future work will provide comprehensive examples and esh out the approach.
Nevertheless, applying this approach to software projects will result in a major change in the administrative setting of a project and communication between the stakeholders that will hinder its acceptance. The biggest issue in that respect is that presently, the documentation of all relevant organisational stipulations is essentially paper-based. Utilizing this approach would mean to transfer an essential part of the project documentation, i. e. the written and signed requirements speci cation, to a di erent medium. The legal issues are no hindrance, since a system that implements this approach could be serialized and signed with the certi cates of the stakeholders. Nevertheless, major shifts in administrative procedures are not done lightly. Thus, future work will have to prove that the bene t of this approach to software engineering will outweigh the inconvenience of changing an administrative process.