Informatik V (Information Systems), RWTH-Aachen
52074 Aachen, Germany

Requirements Engineering has traditionally been defined by the problem it addresses -- designing the "right thing". The ESPRIT project NATURE (Novel Theories Underlying Requirements Engineering) has made an attempt to give some structure to the field, firstly by defining frameworks delineating the areas of concern in RE, secondly by encoding some basic principles of RE in formal meta models which may serve as a basis for understanding, reusing, and integrating existing and forthcoming RE models, methods, and tools. In this paper, we give an overview of these meta models, their interrelationships, and their application in the development of computer-aided requirements engineering environments


Requirements Engineering (RE) is evolving from its traditional role as a mere front-end to the systems life cycle towards a central focus of change management in system-intensive organisations. This requires a more precise understanding of the field.

Several definitions of RE have been given. In terms of the outcome, e.g. 'a requirements specification should tell a designer everything he needs to know to satisfy all the stakeholders - but nothing more' (Sommerville, 1992). Alternatively, the principal RE issue has been described by Bubenko (1993) as 'how to proceed from informal, fuzzy individual statements of requirements to a formal specification that is understood and agreed by all stakeholders'. Jarke and Pohl (1993) take a broader view by defining RE as 'establishing visions in context' and thus a central part of any change management activity.

A number of issues are involved in the process of RE. Changing requirements cause considerable problems during development (Curtis et al., 1988). Lubars et al. (1993) note that issues such as recording assumptions and decisions, understanding the effect of business changes and the use of domain models have not been solved. Desiderata of requirements specifications such as completeness, correctness, unambiguous expression, traceability, etc. have been enumerated (Davis 1993). However, Feather and Fickas (1992) draw attention to the importance of informal knowledge which is often incomplete, ambiguous and inconsistent; hence there is a need to preserve expressive freedoms in requirements, e.g. varying degrees of formality. Social factors, such as power and responsibility, influence the expression of requirements (Goguen 1993). Fact gathering has to tackle problems of tacit knowledge and public/private versions of truth which stakeholders may, or may not, wish to communicate (Harker et al. 1993).

In summary, no clear picture evolves. One of the goals of NATURE, an Esprit basic research project conducted from 1992 to 1995 (Jarke et al. 1993), has therefore been to abstract from the many different facets of RE practice by capturing them as instances of generic meta models which can then serve as a basis for integrative tool support.

This paper gives an overview of these meta models and illustrates their application to typical RE problem such as requirements traceability, process guidance in method application, elicitation, validation., and negotiation support. For full details, the reader is referred to (Jarke et al. 1997).

In section 2, we present the basic framework for understanding requirements engineering that has emerged from NATURE. Section 3 introduces the formal meta modelling approach and illustrates it with a first application, requirements traceability. Sections 4 and 5 present specific meta models NATURE has developed for reuse of domain knowledge, and process guidance in requirements engineering. In section 6, we show how user-defined meta models can serve as a basis for viewpoint resolution in cooperative requirements engineering. Section 7 is an (incomplete) comparison of our approach with related work, while section 8 presents an outlook on current activities.


Requirements belong to users, or stakeholders. They invariably begin as informal statements of goals and users' intentions expressed in natural language which have to be transformed into more formal specifications. However, requirements also reflect real world facts and constraints on design implied by the laws of physics, independently of any user's wish, hence they may occur into two sub-types:

Noticing this inevitable confrontation of wish and reality, we have defined requirements engineering as the process of establishing (user) visions in (domain) context (Jarke and Pohl 1993).

NATURE has developed two conceptions to identify a basic organisation of these two aspects. The first organises the domain context of what kinds of requirements exist according to four worlds (figure 1). The second, depicted in figure 2, organises how the user-defined requirements are established in the domain and organisation context along the three dimensions of representation (technical, notational aspects of the RE process), specification (cognitive completeness aspects), and agreement (social and political aspects). Both conceptions are related in that a specific one of the four worlds, the development world, is maintained as the place where the RE process in the three dimensions happens.

Each of the four worlds holds a family of related models with a different perspective on system development. The subject world contains knowledge of the real-world domain that the system is intended to maintain information about. It contains real-world objects which become the subject matter for conceptual modelling. This is the place where most domain-imposed requirements come from and thus a prime candidate for model reuse.

Fig. 1: The four 'worlds' of information systems modelling

The usage world describes how systems are used to achieve work, including stakeholders who are system owners, indirect and direct users, and their organisational context all the way through to enterprise modelling. This world is the major source of user-defined goals and requirements, and therefore more associated with informal statements and negotiation rather than formal reusable models. Only recently, the formalisation of individual, social, and organisational usage aspects has attracted the attention of researchers (Dardenne et al. 1993, Mylopoulos et al. 1992, Yu 1993).

The system world contains descriptions of the technical entities, events, processes, etc. representing the subject world in the required system, together with some mapping from the conceptual specifications to the design and implementation levels of application software. Clearly this representation will be closely related to system specifications in structured development methods and formal software engineering languages such as Z. Indeed, the terms system requirements and system specification are often used interchangeably.

The development world contains the processes which create applications and uses knowledge belonging to the other worlds as system specifications and designs. This involves analysis and understanding of knowledge contained in the other worlds and representation of that knowledge.

Requirements Engineering is concerned with the relationship between these worlds, within the development world. The vision for change may come from any of the worlds, e.g. user pull from the usage worlds, technology push from the development or system worlds as technological innovations suggest new applications.

The four worlds are embedded in a cyclical process of system evolution. Few applications start from completely 'green field' sites in which only manual systems exist. As the use of information technology increases, most applications start with an existing automated system. Legacy software problems also set requirements, and more often the constraints, for a new system, both in the system and the usage world (e.g. user habits).

The RE process is conceptualised as taking place in the development world. In NATURE, this process is perceived as proceeding along the three dimensions proposed by Pohl (1993); see Figure 2. The dimensions illustrate the three major facets of the RE problem, namely modelling the future application in a more complete manner, modelling with more formality, and the stakeholder dimension of agreeing on requirements.

Fig. 2: The RE process within the three dimensions

Input to the process starts with coarse-grained and ambiguous statements about the intended system. Users may have different visions of the system or partial and incomplete ideas about what they want. Input is characteristically informal in its representation, imprecise and personal as requirements are initially held by different individuals and frequently contradictory. However, the desired output from RE is very different. It should be a complete system specification using a formal language on which all people involved have agreed to the degree necessary to produce a working system.

Transformation from informal input to formal output motivates the three dimensions of the RE process. On the specification dimension, RE has to guide the discovery, refining and validation of requirements as they become more thoroughly understood and complete. Representation has to support expression of requirement statements and models in natural language, semi-formal graphical notations such as DFDs and ER diagrams and formal notations. Finally the agreement dimension has to support trade-offs between requirements and different stakeholders' views, negotiation and co-ordination of a distributed, cooperative process. As the process proceeds a thread traces the emerging requirements specification as it becomes more complete, accurate and shared as a common entity.

The process of arriving at a system specification from the user vision and domain context starting points is the essence of Requirements Engineering. In delivering accurate, valid and complete specifications, RE has to address three main issues:

We elaborate these themes in sections 4-6, after describing the basic meta modelling approach.


The approach taken in the NATURE project has been to use familiar conceptual models such as data flow (DFD), entity-relationship (ER), entity-life history (ELH) diagrams from structured development methods, but to augment the modelling activity of the subject and usage worlds by paying more attention to domain abstractions and objectives-driven user requirements elicitation. Domain abstractions (to be discussed in section 4) provide generic models as templates for requirements of certain application classes which act as a bridge between general conceptual modelling languages and specification instances. Enterprise modelling contributes further information for the interpretation of requirements before they become understood in detail.

Formal domain abstractions and informal, user-defined requirements interact with each other, and with the process models to be discussed in section 5 in numerous ways. The strategy in NATURE has therefore been to encode the basic structure of our theories in formal meta models which enable a comparison between descriptions that are both syntactically and semantically heterogeneous.

To enable the formal integration of existing and new models, NATURE has adopted the four-level framework of the ISO Information Resource Dictionary Systems standard (ISO/IEC 1992) as an organising principle.

In IRDS, application data are maintained at the lowest level. In RE, this level appears only if scenario-based approaches are considered; this is currently being studied in a follow-up ESPRIT project called CREWS (Cooperative Requirements Engineering With Scenarios).

The IRD Level defines, at runtime, a type system for these application data and reflects the schemata, programs, and workflows in the application. At system evolution time, it is the lowest level of the design environment containing the models of the developed requirements specification and the traces of the RE process.

The IRD Definition Level defines the schema of the RE product and process. Traditionally, this would be the different notations used in the process. In NATURE, it has been significantly enhanced to include traceability models, libraries of reusable domain abstractions, process guidance chunks, and even CARE tool models.

The basic frameworks used to organise the product and process models at the IRD Definition Level, are defined at the IRD Definition Schema Level. It contains meta models of traceability, domain abstractions, and process guidance interwoven through the common notion of requirements product.

Although NATURE adopted the structure of IRDS, it did not base the formal definition of the relationships among the levels on SQL, as the standard does. The reason for that is SQL's lack of expressiveness especially to represent and enforce constraints across more than one level of abstraction. For this reason, the knowledge representation language Telos (Mylopoulos et al. 1990) that has powerful meta modelling facilities was chosen as the formal knowledge representation language in NATURE.

Telos allows the association of predicative deduction rules and integrity constraints with meta-classes, thus supporting semantic definition and consistency checking of multiple interacting meta models. The language version implemented in the ConceptBase repository was used in NATURE (Jarke et al. 1995). It offers a universal notion of objects, in which entities, attributes, instantiation and specialisation relationships are all objects with the same rights and properties. Thus, a Telos object base is defined as the triple <OB, R, IC>, where OB, the extensional object base, is a set of objects, and R and IC are sets of rules and constraints. Object-oriented facilities are encoded as predefined deductive rules and constraints, called the axioms of Telos.

Requirements models are managed as an evolving knowledge base structured according to the available meta-data and process models. Meta models can be specialised to particular domains and methods. This provides the basis for integrating domain and process models into a knowledge representation framework for Requirements Engineering.

To include informal representations such as text and their linkage to formal ones, a traceability relationship recording the dynamic dependencies between different kinds of requirements products must be added to the meta modelling approach. Figure 3 shows an example of how requirements traceability is organised in the IRDS-based modelling framework (Pohl 1996). At the highest level, the three dimensions of figure 2 are used to specialise the notion of requirements product, at the level below specific modelling notations (e.g. hypertext, SA, and ER), dependency types (e.g. based-on) and tools (ER editor) are represented, while the lowest level captures the trace of tool actions and human decisions, including the resulting (intermediate or final) products of the RE process, here: hypertexts, ER and SA diagrams.

The meta modelling approach allows traces to be made on the specification history of requirements, and on ownership and modification responsibility. Searches can be made on vertical traces over time, complemented by horizontal traces linking models and different requirements documents to the agents who modified them. Informal documents such as hypertext nodes can be associated with their consequent specifications in software engineering models. Furthermore, argumentation models can be associated by such traces so that requirements rationale history, process actions and personnel can be placed together for project management purposes.

Fig. 3: Example of IRDS modelling approach: traceability links between tools, process model activities and products of RE


A major modelling concern in Requirements Engineering is the role and impact of domain knowledge (Jackson 1994). Many new applications share requirements with well-known problems, so one possibility is to create generic models of systems such as inventory management, hiring applications, accounting, etc. The NATURE domain theory attempts to add reuse to RE by providing sets of generic models for developing requirements specifications.

To support understanding of problems and hence elucidate opaque requirements along the completeness and representation dimensions, we have developed a set of more than 150 generic, reusable models for classes of problems. These can be considered as a model library for the subject world. The framework for modelling domain knowledge has been developed in NATURE to assist requirements acquisition, validation and reuse of specifications (Maiden and Sutcliffe, 1994). The framework is based upon cognitive models of memory (Gentner and Stevens, 1983; Rosch, 1983) and experimental evidence that experienced software engineers tend to recall and reuse problem abstractions (Guindon, 1990). This suggests that natural units of abstraction may be aggregates of objects linked by a purpose, similar to the 'use case' concept in object-oriented design (Jacobson 1987). Hence the framework we propose can be viewed as object-oriented reuse at the system network level rather than by individual objects.

Problem abstractions are composed of object and information system models. Object systems models define the structure and behaviour of the problem space, i.e. the application objects or entities in the subject world, while information system models hold processes which produce reports or query screens containing information about the object system. This distinction not only reflects our distinction between subject and system world in figure 2 but is also motivated by ideas on separating the entity model of a system from the functional processes which acquire information from that model (Jackson 1983). A problem domain model is an aggregation of several object and information system models, hence the framework can handle applications of different sizes and complexity.

The knowledge meta schema defines the semantic primitives of, and relationships within, the object and information system models. The semantic primitives consist of twelve knowledge types, most of which are familiar from other modelling languages. However, we add a new concept 'structure object' which models an approximation to physical structure in the real world. This concept bridges the gap between domain-specific models (Fischer, 1992) and general modelling languages. The components of the meta schema (cf. figure 4) are:

All the meta-schema primitives have been formalised in Telos (Sutcliffe and Maiden 1994) and implemented in ConceptBase (Jarke et al. 1995).

Fig. 4: Meta-schema of knowledge types for domain modelling

Our library of Object System Models (OSMs) is structured in a class hierarchy. Models at different levels of abstraction are distinguished using different knowledge types. Structure and purpose are the most important constructs at higher levels because they discriminate effectively between different problem classes and are used by the analogical retrieval process to match interrelated knowledge structures rather than isolated facts (Gentner 1983; Holyoak and Thagard, 1989). Laboratory experiments (Maiden and Sutcliffe, 1993) showed that reuse is best achieved if the top level in the hierarchy is defined by state transitions, agents, states and semantic relations. Lower-level object system models are specialised by adding further meta knowledge types such as goal states, events, stative conditions and object properties.

The highest levels of the object system hierarchy are illustrated in Figure 5. The model population consists of nine separate trees each of which the reuse library specialises to 3-4 levels of sub-classes:

Fig. 5: Hierarchy of object system models for domain modelling

The models are used in the NATURE tool set to help requirements validation, explanation and critiquing, and provide a framework for domain knowledge representation and analysis.


RE is a complex and unpredictable activity which, we believe, is not covered by the agenda of standard workflow systems or software process models; cf. (Dowson, 1987; Pohl, 1996) for reviews. The NATURE process meta-schema addresses the problem of providing guidance and system support in poorly understood, largely human-driven creative processes that are characteristic of RE activity leading up to detailed specification.

4.1 Process Modelling for RE Contexts

As RE is composed of many complex, interleaved activities, a contextual approach is used to link possible RE activities to certain situations and intentions (Rolland et al., 1995). RE is modelled as a set of situations prescribing appropriate actions on products which contain requirements statements and models. Products include specifications under development, pre-existing specifications, informal text in natural language, sketches and diagrams, formal specifications and designs. The meta schema for RE process modelling is illustrated in Figure 6. The seven key concepts of the NATURE process meta model are:

Fig. 6: Meta schema of the NATURE process model

Contexts are sub-typed to describe different types of activity within RE:

At the detailed level a context may involve refining individual requirements. For instance, assume that the entity type 'publication' in a library system has been created within an ER schema. The requirements engineer ascertains that this entity type represents slightly different things in the real world, such as books, characterised by their authors or editors, while journals are characterised by a publisher. Advice on the different ways to deal with this observation are represented in the following choice context:
Choice context: Refine entity types
situation: an entity type with variants
intention: model variants of the entity type
	1st alternative context
	situation: entity type with slightly different variants
	intention: define discriminating attributes for the entity type arguments.
		Pros: leads to fewer number of entity types in the schema
		Cons: the real world entities are not really differentiated
2nd alternative context
	situation: entity type variants are treated differently in the system
	intention: partition the entity type into sub-types arguments.
		Pros: better representation of the real world
		Cons: greater complexity of the schema
Each of the two alternatives would itself be a plan context detailing how to revise the ER model.

Context recognition cannot be just employed at the detailed level, but also in project management to provide 'contextual assistance' to various RE activities in a flexible manner. At the highest level the process model can be used to describe activities within RE and to give a 'road map' overview of the process.

Fig. 7: A process guidance forest: excerpts from an OMT way-of-working definition

To bridge the gap between descriptions of activity at different levels of granularity, contexts can be arbitrarily nested to forests of context trees, each tree representing an independent process chunk which can be invoked when certain situations and intentions are present. As an example, figure 7 shows excerpts from a forest of process trees which formally reconstruct the description of the way-of-working of the Object Modelling technique OMT in the book by Rumbaugh et al. (1991). Several other textbook methodologies have been reconstructed in a similar manner.

The process model can describe requirements activities involving human reasoning as plan contexts with decisions, as well as detailing requirements modelling techniques. When embedded in supporting tools the process model can trigger support processes for different types of requirements analysis according to the requirements engineer's needs and the product context.

An Enterprise Modelling framework by Bubenko (1993) has been combined with the RE process modelling framework, in order to offer a categorisation of RE approaches in the form of non-deterministic plan contexts. Basically, these models provide coarse-grained advice on five main routes of requirements discovery:

  1. Requirements initiated within the organisation as policies, aims, objectives and other high level statements of intent. Goals are often discovered by decomposing high level intentions. This source includes visions, such as the famous statement by President Kennedy to 'send a man to the moon and safely return him to the earth within this decade'.

  2. Problems which initiate requirements to change an existing business or malfunctioning system.

  3. Examples when stakeholders hear about or see a demonstration of an existing application which would be useful to them. The user's immediate goal is often to acquire new technology, although the fit of technology with their working practices needs to be investigated.

  4. A variant of 3 is when experts recommend a system enhancement to users to improve their work. Technological innovation creates new goals for users but they still have to be understood in a context.

  5. Requirements imposed by the external world as standards, legislation, and other regulations. In this case new goals are imposed upon the system.


Requirements for complex, composite systems are acquired and modelled from different viewpoints. Viewpoints are held by groups of users or requirements engineers who produce the specification; they serve as a basis for quality control in RE (Nissen et al., 1996) as well as for requirements negotiation (Boehm et al., 1994).

Previous research has provided technical definitions of viewpoints in software engineering (Mullery, 1979; Kotonya and Sommerville, 1992) but these have ignored the social and cognitive aspects of RE. Therefore, the NATURE definition is in two parts. First, viewpoints are defined from the social context of their use; this definition determines the embedding in the constructs of the process meta model. Secondly, a definition of the knowledge represented in viewpoints is given; this leads to extended computational mechanisms for goal-oriented viewpoint resolution based on user-definable meta models.

A viewpoint on requirements is any artefact produced as part of the social Requirements Engineering process, through which its owners communicate and agree. This concords with the definition of product used in the process model, with the addition that viewpoints have an owner. An owner is any requirements engineer or user who either can change the viewpoint, directly or indirectly, or who is responsible for the accuracy of the viewpoint contents. Viewpoints have a state which may be agreed amongst owners, internally consistent, and signed off. The process model actions define how each viewpoint evolves with respect to these states.

A second definition focuses on the knowledge to be held in a repository. A viewpoint is a loosely-coupled, locally managed object encapsulating different types of RE products. The principal difference with previous definitions (Nuseibeh et al. 1993) is that each viewpoint can have different representation schemes and multiple owners with different relationships to the viewpoint.

Resolution of viewpoints means the determination of gaps, contradictions, and other kinds of conflicts among viewpoints which address overlapping issues. Most existing techniques for viewpoint resolution attempt to solve this problem by defining a set of inconsistency detection rules with the viewpoint schema (Nuseibeh et al. 1993). In the more heterogeneous case reflected in our definition, resolution rules must be defined one level higher, at the meta-schema level.

However, while the domain and process aspects may be covered by a fixed meta-schema as described in the previous sections, the handling of many conflicts is at the very essence of what we called user-defined requirements in section 2. It should therefore be possible to associate the meta-schema with the basic vision or goal of the RE process, i.e. make it adaptable to the project at hand. The analysis and resolution of heterogeneously defined viewpoints is then not generic but driven by the analysis goal expressed in the meta schema.

Fortunately, the extensibility of the Telos language is sufficient to allow even this degree of adaptability at the meta meta level. Several meta-schemas for specific viewpoint resolution issues have been developed; an overview and a detailed industrial case study in the field of business process analysis are presented in (Nissen et al. 1996).

Even the domain and process meta-schemas presented in sections 4 and 5 can be seen as examples of this goal-oriented approach. The domain meta-schema looks at a requirements specification with the goal of identifying information about specific patterns of problems identified as often relevant in the subject world by the domain theory. The process meta-schema defines the integration of three essential kinds of activities in RE, namely product changes, decision-making and planning, under the common setting of context-driven work.


Besides providing a basis for understanding of requirements engineering problems, theory and practice by formal reconstruction, a major goal of defining the NATURE meta models was to use them as a basis for process-integrated, repository-based computer-aided requirements engineering environments which are upward compatible with present practice but provide better integration and more functionality and support. A number of such tools were developed in NATURE. As they are all driven by meta-schemas, they are all coordinated through a repository based on the management of these meta schemas, to be discussed first. After presenting then the individual tools, the other aspects of tool integration (especially control integration) are discussed as well. It should be noticed, however, that NATURE only aimed at a demonstrator of possible overall CARE integration; only certain parts of the architecture have been further developed for practical use.

7.1 Requirements Engineering Repository

At the core of the NATURE environment is the ConceptBase repository (Jarke et al. 1995) which uses the Telos language. ConceptBase provides a distributed, partitioned knowledge base which can support partitions to store inconsistent knowledge, as well as the reasoning mechanisms for detecting inconsistencies, integrity problems, dependencies, and query processing. The modular structure of ConceptBase allows independent models to be maintained in one repository to support distributed Requirements Engineering and viewpoints management, with relationships to manage traces and ownership. ConceptBase can host hypertext models used to store informal requirements as well as representing argumentation models. Editors for familiar conceptual models from structured development methods can be supported as well as more formal notations.

In essence, each viewpoint is defined and stored in two parts. First, the core viewpoint contains information about the viewpoint name, owners and intention which are used to manage the viewpoint in the Requirements Engineering process. Second, each viewpoint has a number of models, each of which maps to a ConceptBase module. Each module is typed according to its representation or language to enable retrieval of appropriate, predefined integrity constraints. The new inconsistent viewpoint 'n' imports models from two existing viewpoints 1 and 2. Repository management facilities allow viewpoints to be held as separate segments of the knowledge base which can be progressively integrated as the RE process proceeds.

7.2 Process Guidance

A process model guidance tool called MENTOR has been developed to give 'way of working' advice (Si-Said et al., 1996). The primary unit of a process is termed a 'chunk'. Chunks are grouped into procedures by the forest concept. As not all actions are atomic, the tool can search up the process model hierarchy of chunks to provide heuristic guidance by using the 'alternatives' and 'argument' components of the process model.

When integrated with the repository, the process guidance helps the requirements engineer by triggering appropriate tools for the work context in hand. This works by integrating the process chunk with the product so the tool suggests the next action to take according to the state of a product, e.g. a top level data flow diagram needs to be decomposed into lower level detail. The repository starts up the appropriate tool for the job, such as a data flow diagram editor, and loads the existing model. The repository manager in cooperation with the process guidance tool thereby provides the user with the appropriate tool for a requirements activity depending on the product state. The requirements process can be managed in a distributed, teamwork environment. One user can carry out part of the process and pass the requirements products on to the next user. The system provides appropriate tools and advice according to the history of a requirements specification.

7.3 Traceability

Gotel and Finkelstein (1994) point out that it should be possible to trace requirements forwards from an initial statement to specifications and design components, and backwards from design components to their motivating requirements. Backward tracing is necessary for system modification and maintenance, while forward traceability is used in managing development from requirements through to implementation.

The PROART environment developed in NATURE handles traceability in a novel manner by linking the product and dependency structure shown in figure 3 to the process model (Pohl, 1996). This allows requirements traces to link the product to the originating/owning agent (i.e. the individual requirements engineer or user) and to the process actions which have been carried out on the product. To support this framework technically, the traceability model elaborates the formality, completeness and agreement dimensions into a set of class definitions which characterise points and relationships as constructs in the Telos language. The process instantiates class definitions as it progresses.

The screendump in figure 8 illustrates traceability in two of the three dimensions of RE. It shows an informal hypertext (upper left) linked to a semi-formal ER representation (lower right) via a design decision in the agreement dimension (Decision Editor on the upper right). The dependencies establishing the link between these three (cf. figure 3 for the formal basis of this example) are visualised in a graphical dependency browser in the lower left.

Fig. 8: PROART showing diagram editors and traceability tools

7.4 Matching Tools

Within RE there are many needs for matching specifications or any RE product. For example, requirements can be reused by matching facts about anew application with similar requirements specifications. This can help understanding and validation of requirements. View integration can be aided by assessing the goodness of fit between two viewpoints. NATURE provides two matching mechanisms, one based on similarity, the other using analogical matching with abstract models of software engineering problems. Analogical matching uses template models and structure matching algorithms, whereas similarity is based on distance and type based metrics to establish goodness of fit between schema.

Similarity Matching. The tool detects similarities and discrepancies between RE products which share the same modelling formalism (Spanoudakis and Constantopoulos, 1994). Discrepancies are detected using a meta model of semantic knowledge about conceptual schemata, such as ER diagrams. This semantic knowledge is independent of the domain and, in part, of the modelling notation. The tool detects isomorphisms between components using a computational model of similarity.

Meta-knowledge enables classification of specification components using domain-independent constructs. Components are classified as features of other specification notations or general modelling constructs. Comparisons take the form of logical equivalence relations (Gangopadhyay and Barsalou, 1991) or similarity estimations (Fankhauser et al., 1991). Classification also permits detection of structure matches between models and between components in models. The matching algorithm counts equivalent components -- e.g. classes, entities, attributes and value domains in each conceptual structure -- and calculates a distance metric according to closeness in a class hierarchy and goodness of fit metrics. Similarity analysis has been implemented for meta-model classifications for relational and hypothetical object-oriented data models. The tools operate with the Software Information Base (Constantopoulos et al., 1995), a close relative of ConceptBase specifically optimised for reuse of complex structured objects. This allows specifications and documentation to be recorded as 'application frames'. These occur as specific instantiations and as generalised application frames representing a class of applications. Similarity matching is used on both to output ranked lists of reusable components with goodness of fit metrics.

Matching with Domain Knowledge. As described in section 4, domain abstractions describe the essential static and dynamic properties of problem classes. The matcher tool works with these models to associate input facts with the appropriate problem abstraction.

Matches between new applications and existing RE products are detected by reasoning about the structural and semantic isomorphisms between two models. Overlaps, gaps, inconsistencies and conflicts between viewpoints are inferred from mappings between components in the abstraction and each viewpoint. These mappings are inferred by the domain matcher (Maiden and Sutcliffe, 1996), a computational analogical reasoning mechanism which retrieves abstractions from a library of 150 object system models and 20 information system models representing key determinants of business and real-time domains. The matcher uses pattern matching with domain semantics rather than syntactic features to retrieve object system models. The viewpoint matcher detects overlaps, gaps, contradictions and conflicts from mappings inferred by the domain matcher. Both matcher tools improve the agreement of requirements specification by pointing out mismatches. In addition, these tools help completeness by retrieving reusable specifications. The matched abstract model can be reused during Requirements Engineering to promote understanding or empower validation and critiquing of requirements.

7.5 Critiquing and Validation Tools

A variety of tools support is provided to help requirements engineers validate requirements either indirectly via argumentation models and correlation matrices, or directly by active tool assistance in intelligent critics, e.g.:

Fig. 9: CoDecide tool which supports trade-off analysis and prioritisation of requirements to design solutions and non-functional requirements.

The CoDecide tool helps progress along the agreement dimension by supporting satisficing and prioritising goals. Model browsers and the requirements critic help improve specification completeness, and links between models suggest improvements along the formality dimension.

7.6 Schema Integration

This tool assists users in integrating locally (and independently) developed database sub-schemata, using part of the domain knowledge base, into a global, integrated schema. It extends existing approaches, primarily in the sense that the integration provides more intelligent services to the user. This is achieved by combining several strategies, e.g.:

The tool works co-operatively with the user augmenting syntactically based integration algorithms with domain knowledge that helps it to better 'understand' the concepts and their relationships used in the local schemata. This understanding is a prerequisite for meaningful integration as well as for the restructuring of the schemata. The schema integration tool helps the process of completing and formalising requirements specification along two dimensions, as well as promoting agreement by schema mapping.

7.7 Summary of the NATURE tool set

An overview of our tool development is given in Figure 10. Tool interoperability is promoted by ensuring that individual tools do not need knowledge of each others' methods and data structures. Inter-tool co-ordination is delivered by a communication manager while inter-tool communication is provided by ConceptBase, and Telos which act as an interlingua between different models and their knowledge representations.

The Communication Manager (CM) insulates individual tools from control knowledge of other tools. It controls communication among currently operational tool instances, extending concepts e.g. followed in Hewlett Packard's SoftBench. That is, it knows (a) which tools are currently running, (b) how they can be accessed, and (c) their capability to provide the required service generally and in relation to their current state, but (d) also with respect to the process model (Pohl, 1996). This approach has several advantages. First, the CM hides details of message protocols from individual tools. Secondly, as all tools are invoked through messages, the CM can easily maintain a status map of the system at any point in time. Finally the CM abstracts the grouping of services to support process adaptability. Hence if a tool requires a service, it does not need to know which combination of tools offer this service because the CM acts as a service broker.

So when a tool or the user requests a service, the CM finds the appropriate tool for a service, makes it available in the correct mode (e.g. graphical or text UI display), supplies the tool with the necessary objects (e.g. input model from the repository), and restricts its use to the current process state. After the process steps associated with the service have been executed, control is returned to the calling tool. The tool environment also automatically provides a trace between the tools, the models used within the tools and the process chunk, associating both with the NATURE process model for traceability.

Fig. 10: Outline architecture of the ConceptBase repository and NATURE's CARE tools


While we know of no project which addresses Requirements Engineering on the scale of NATURE, there are several research groups who are investigating many of the issues in RE. In this section we review related work in domain modelling, process models and RE support tools. A broader review of the relationships between RE and knowledge engineering can be found in (Shaw and Gaines, 1996).

8.1 Domain Models

Several authors have proposed generic knowledge models for Requirements Engineering e.g. clichs in the Requirements Apprentice (Reubenstein and Waters, 1991) and generalised application frames in the ITHACA project (Constantopoulos et al. 1995). In software engineering, libraries of abstractions have been described at the level of design architectures (Shaw, 1991) and reusable functions, although these have had limited success in practice (Harandi and Lee, 1991; Prieto-Diaz, 1991). Similar abstract classes have also been proposed in artificial intelligence, notably generalised task theory (Chandrasekaran et al. 1992) and the abstract models proposed in the Ontolingua project (Gruber, 1992). The causal models of generalised task theory are similar to the agent and state transitions described in the domain theory. Knowledge engineering methods, notably KADS (Wielinga et al. 1993), have also espoused use of generic domain classes, although only a small number of classes have been described in detail.

The KAOS project (Dardenne et al., 1993) shows many interesting similarities with the domain theory, although the emphasis of the researchers' work is directed more towards supporting formal refinement of requirements. They emphasise constraint-based specification, compared with our approach of linking goals to functional specification for satisfying goal states. Their modelling language provides more formality, although goal modelling and requirements discovery have supplied simpler process guidance via heuristics Sutcliffe and Maiden 1993). Generic models are advocated by Dardenne et al., although they do not specify any set of such models. The provision of a set of domain knowledge models is the major difference between the two approaches. The domain theory provides a systematic guide to the construction of reusable components and, furthermore, a mechanism for matching and retrieving such components from large scale reuse libraries. This promises reuse across multiple domains and more sophisticated retrieval than that afforded by current faceted classification schemes (Prieto-Diaz, 1991).

8.2 Process Models

Activity-oriented process models are based on a problem-solving analogy, i.e. finding and executing a plan of actions leading to the solution (Holyoak and Thagard, 1989). They are linear in nature and inadequate for methods with backtracking or Requirements Engineering which has a less deterministic task structure. Product-oriented process models, following Dowson's (1987) definition, represent the development process through the evolution of a product and emphasise the linkage between development activities and their output, i.e. a product (Finkelstein et al., 1990). More recent process models follow a decision-oriented paradigm (Potts, 1990; Rose et al., 1991). Successive transformations of the product are seen as the consequences of decisions. These models are semantically more powerful because they explain not only how a process proceeds but also why. Furthermore, decision-oriented models have the flexibility to handle less deterministic processes. However, none of these models unify the concepts of process, product and decision. This is the key advance in the NATURE process model which has progressed further by introducing the process chunks and clusters to describe processes at different levels of granularity and abstraction.

Elicitation has been researched extensively in knowledge based systems (Diaper, 1989; Shaw and Gaines, 1996), but this activity has received little attention in RE. Investigations into generic activities associated with requirements analysis have been reported by (Maiden and Sutcliffe, 1992; Maiden and Rugg, 1994) who offer advice on selecting appropriate techniques for requirements capture tasks. They draw on knowledge acquisition techniques such as card sorts, repertory grids, and laddering which are applied to certain RE activities; although much more needs to be done before comprehensive guidance can be given.

Some studies in the ethno-methodological tradition have been reported (Luff et al. 1993; Sommerville et al. 1993) which point to alternatives to interviews. These emphasise understanding the importance of the domain context and the role of artefacts in working practice for specifying requirements. However, ethno-methodological observation style studies are time consuming and the results are not always clear; furthermore, detailed guidance on the practice of such techniques is hard to find. A more promising approach, in the Inquiry Cycle (Potts et al. 1994), synthesises the walkthrough tradition with scenarios to create test data for requirements validation and discovers further requirements by checking system goals against obstacles, or problems, in the environment which the system will have to deal with.

8.3 RE Support Tools

Argumentation support has been developed in a variety of rationale based tools e.g. gIBIS (Conklin and begeman, 1988), QOC (MacLean et al., 1991). Most of these models follow a hypertext-like representation of problem statements, solution options for those problems and judgement criteria. This enables assessment of the arguments for and against different design solutions to be viewed in a structured manner. The TAME project (Basili and Rombach, 1988) goes further by linking goals to questions and metrics, thereby associating functional, and non-functional requirements to metrics for quality measurement. In NATURE we have taken the integration of rationales and the design process further by linking informal representations in hypertext and more formal representations, to argumentation models via traces of associated process histories. Typed links on traces provide a rich set of semantics beyond data modelling concepts (Storey, 1993) to handle complex hierarchical and network associations. Moreover, traceability is enhanced beyond simple history facilities provided by the Viewer tool (Nuseibeh et al., 1993) and represents a considerable advance over simple traceability for documentation handling (Ramesh and Dhar, 1992).

NATURE's requirements critic uses domain abstractions with a strong, theoretical task model to direct assistance, unlike other design critics which rely on more opportunistic strategies (Fickas and Nagarajan, 1988; Fischer, 1992). However, this assistance is tempered by control of mixed initiative dialogue driven by the context of the RE process; in contrast, existing tools such as the Requirements Apprentice (Reubenstein and Waters, 1991) and ASPIS (Puncello et al., 1988) do not explain domain knowledge and take initiative from the requirements engineer, thus impairing cooperative problem solving.

We also place considerable emphasis on explanation, as understanding is an important part of requirements analysis. The requirements explainer/critiquer provides co-operative assistance similar to that provided by the Domain Oriented Design Environments (Fischer, 1992); however, because the domain matcher uses generic models our tool can function in many different domains, unlike Fischer's domain specific tools. While the level of critiquing might not be as detailed as in a domain-specific tool, this can be traded off against the development effort of creating new tools for each specific domain. We believe the domain matcher will be more effective in supporting requirements definition in an organisation with many different types of applications, while domain-oriented support may be more effective for organisations dedicated to a narrower range of problem types.


In this paper, we have sketched some informal frameworks and formal meta-schemas of requirements engineering products and processes. The main goal of these meta-schemas has been to provide a migration path, through which the wide variety of existing and proposed RE approaches can be enhanced with formal, computerised support, and combined with each other in more comprehensive support environments than the present ones. Except for the emphasis of linking to existing RE practice in business and software engineering applications, many of these ideas are shared with, and partially inspired by, the knowledge engineering community. However, despite the many obvious and less obvious similarities, taking advantage of the synergy opportunities offered will take a substantial effort in mutual understanding and research integration, aimed at strengthening the potential for industrial uptake of results in both of the fields.

Despite its attempt to achieve broad coverage within RE, some aspects have received less attention than others. Formal modelling and proof of specifications is not addressed by our work, as many other researchers have investigated such issues in system specification over a number of years. NATURE has investigated some of the social aspects of RE although support for negotiation and cooperative aspect of RE requires much more research. It remains to be seen whether ethno-methodological techniques and modelling diffuse social concepts such as power relations can make an impact on RE, so the payoff from supporting such approaches is, as yet, uncertain. Only when we understand more about these phenomena will social models be able to express them.

Other problems remain in bridging the informal to the formal. Hypertext tools and the typology of requirements concepts in Enterprise Models help management and transforming of linguistic expressions into conceptual models. However, further research is necessary to understanding how formal requirements can be extracted from language or via reference model reuse.

The goal of the recently begun follow-up ESPRIT project CREWS (Cooperative Requirements Engineering With Scenarios) is to extend the models, methodological approaches, and tool conceptions developed in NATURE by the integration of instance-level scenarios, the extension of informal representations in the direction of multimedia, and the more explicit consideration of cooperation and negotiation processes both at the formal and at the social level.

Acknowledgements - This research was supported by the European Union in ESPRIT Basic Research Project 6353 (NATURE).


V.R. Basili and H.D. Rombach. The TAME project: Towards improvement oriented software environments. IEEE Transactions on Software Engineering, 14(6): 758-773 (1988).

T.E. Bell and T.A. Thayer. Software requirements: Are they really a problem? In Proceedings of the 2nd Intl. Conf. on Software Engineering, pp. 61-68 (1976).

B. Boehm, P. Bose, E. Horowitz and M.J. Lee. Software requirements as negotiated win conditions. In Proceedings of the 1st Intl. Conf. on Requirements Engineering, Colorado Springs, Co, pp. 74-83 (1994).

J. Bubenko. Extending the scope of information modeling. In Proceedings of the 4th Intl. Workshop on the Deductive Approach to Information Systems and Databases, Lloret, Costa Brava, Report DSV 93-034, SISU, Stockholm, Sweden, (1993).

B. Chandrasekaran, A. Keuneke, and M. Tanner. Explanation in knowledge systems: The roles of the task structures and domain functional models. In Proceedings of Workshop on Task Based Explanation, Samos, Greece (1992).

P. Coad and E. Yourdon. Object-Oriented Analysis. Prentice-Hall (1991).

J. Conklin and M.L. Begeman. gIBIS: A hypertext tool for exploratory policy discussion. ACM Transactions on Office Information Systems, 6(4):303-331 (1988).

P. Constantopoulos, M. Jarke, J. Mylopoulos, and Y. Vassiliou. Software Information Base: a server for reuse. VLDB Journal, 4(1):1-43 (1995).

B. Curtis, H. Krasner, and N. Iscoe. A field study of the software design process for large systems. Communications of the ACM 31(11):1268-1287 (1988).

A. Dardenne, A. v. Laamsweerde, and S.Fickas. Goal directed requirements acquisition. Science of Computer Programming, 20: 3-50 (1993).

A.M. Davis. Software Requirements: Object Functions and States. Prentice Hall, Englewood Cliffs, NJ (1993).

D. Diaper. Knowledge Elicitation: Principle, Techniques and Applications. Ellis Horwood, Chichester, UK (1989).

M. Dowson. Iteration in the software process. Proceedings of the 9th Intl. Conf. on Software Engineering, San Francisco, Ca, pp. 36-39 (1987).

E. Dubois, J. Hagelstein, and A. Rifaut. Formal requirements engineering with ERAE. Philips Journal of Research 43(4) (1989).

R. Fankhauser, M. Kracker and E. Neuhold. Semantic vs. structural resemblance of classes. SIGMOD Record 20(4) (1991).

M.S. Feather and S. Fickas. Coping with requirements freedoms. In Proceedings of the Intl. Workshop on Development of Intelligent Information Systems, Niagara, Ontario (1992).

S. Fickas and P. Nagarajan. Critiquing software specifications. IEEE Software, 8:37-47 (1988).

A.C.W. Finkelstein, J.Kramer, and M. Goedicke. Viewpoint-oriented software development. LeGnie Logiciel et ses Applications, Toulouse, 337-351 (1990).

G. Fischer. Domain-oriented design environments. In Proceedings of the 7th Knowledge-Based Software Engineering Conference, IEEE Computer Society Press, 204-213 (1992).

D. Gangopadhyay and T. Barsalou. On the semantic equivalence of heterogeneous populations in multi-model multi database systems. ACM SIGMOD Record 20(4) (1991).

O.C.Z. Gotel and A.C.W. Finkelstein. An analysis of the requirements traceability problem. In Proceedings of the 1st Intl. Conf. on Requirements Engineering, Colorado Springs, Co, pp. 94-101 (1994).

D. Gentner. Structure mapping: a theoretical framework for analogy. Cognitive Science 7:155-170 (1983).

D. Gentner and A.L. Stevens. Mental Models. Lawrence Erlbaum Associates (1983).

T. Gruber. Ontolingua: A mechanism to support portable ontologies. Technical Report, Knowledge Systems Laboratory, Stanford University, Ca (1992).

J.A. Goguen J.A. Social issues in requirements engineering, In Proceedings of the 1st Intl. Symposium on Requirements Engineering, San Diego, Ca, pp. 194-198 (1993).

R. Guindon. Designing the design process: exploiting opportunistic thoughts. Human-Computer Interaction 5:305-344 (1990).

M.T. Harandi and M.Y. Lee. Acquiring software design schema: a machine learning perspective. Proceedings of the 6th Knowledge Based Software Engineering Conference, IEEE Computer Society Press, 188-197 (1991).

S.D.P. Harker, K.D. Eason, and J.E. Dobson. The change and evolution of requirements as a challenge to the practice of software engineering. In Proceedings of the 1st Intl. Symposium on Requirements Engineering, San Diego, CA, 266-272 (1993).

K.J. Holyoak and P. Thagard. Analogical mapping by constraint satisfaction. Cognitive Science, 13:295-355 (1989).

ISO/IEC. Information Technology - Information Resource Dictionary Systems (IRDS) - Framework. ISO/IEC International Standard, 1990.

M. Jackson. Problems, methods and specialisation. Special Issue of SE Journal on Software Engineering in the Year 2001 (1994).

M. Jackson. Systems Development. Prentice-Hall International (1983).

M. Jackson and P. Zave. Domain descriptions. In Proceedings of the 1st Intl. Symposium on Requirements Engineering, San Diego, Ca, pp. 56-64 (1993).

I. Jacobsen. Object oriented development in an industrial environment. Proceedings of the OOPSLA-87, pp. 183-191 (1987).

M. Jarke, Y. Bubenko, C. Rolland, A.G.Sutcliffe, and Y. Vassiliou. Theories underlying requirements engineering: an overview of NATURE at genesis. In Proceedings of the 1st Intl. Symposium on Requirements Engineering, San Diego, Ca, pp. 19-31 (1993).

M. Jarke, R. Gallersdörfer, M.A. Jeusfeld, M. Staudt, and S. Eherer. ConceptBase: A deductive object manager for meta data bases. Journal of Intelligent Information Systems 4(2):167-192 (1995).

M. Jarke, M. Gebhardt, S. Jacobs, and H.W. Nissen. Conflict analysis across heterogeneous viewpoints: formalization and visualization. Proceedings of the 29th Hawaii Intl. Conf. System Sciences, Vol. III, pp. 199-208, Wailea, Hi (1996).

M. Jarke and K. Pohl. Establishing visions in context: towards a model of requirements processes. Proceedings of the 14th International Conference on Information Systems, Orlando, Fl, pp. 23-34 (1993).

M. Jarke, C. Rolland, and A.G. Sutcliffe (eds.). The NATURE of Requirements Engineering. Springer-Verlag (1997).

G. Kotonya and I. Sommerville. Viewpoints for requirements definition. Software Engineering Journal 7:375-387 (1992).

M. Lubars, C. Potts, and C. Richter. A review of the state of the practice in requirements modelling. In Proceedings of the 1st Intl. Symposium on Requirements Engineering, San Diego, Ca, pp. 2-14 (1993).

M.M. Lehman. Software engineering, the software process and their support. Software Engineering Journal 6(5):243-258 (1991).

P. Luff, M. Jirotka, C. Heath, and D.Greatbatch. Tasks and social interaction: the relevance of naturalistic analyses of conduct for requirements engineering. In Proceedings of the 1st Intl. Symposium on Requirements Engineering, San Diego, Ca, pp. 187-190 (1993).

A. Maclean, R.M. Young, V. Bellotti, and T.Moran. Questions, options, and criteria: elements of design space analysis. Human-Computer Interaction 6(3&4):201-250 (1991).

N.A.M. Maiden and G. Rugg. Knowledge acquisition techniques for requirements engineering. In Proceedings of the Workshop on Requirements Elicitation for System Specification, Keele UK (1994).

N.A.M. Maiden and A.G. Sutcliffe. Requirements critiquing using domain abstractions. In Proceedings of the 1st Intl. Conference on Requirements Engineering, Colorado Springs, Co, pp. 184-193 (1994).

N.A.M. Maiden and A.G. Sutcliffe. Requirements engineering by example: an empirical study. In Proceedings of the 1st Intl. Symposium on Requirements Engineering, San Diego, Ca, pp. 104-112 (1993).

N.A.M. Maiden and A.G. Sutcliffe. Exploiting reusable specifications through analogy. Communications of the ACM. 34(5): 55-64 (1992).

N.A.M. Maiden and A.G. Sutcliffe. The domain matcher for requirements reuse, In press, Software Engineering Journal.

G.P. Mullery. CORE - A method for controlling requirement specification. In Proceedings of the 4th International Conference on Software Engineering, IEEE Computer Society Press, pp. 126-135, (1979).

Mylopoulos, A. Borgida, M. Jarke, and M. Koubarakis. Telos: a language for representing knowledge about information systems. ACM Transactions on Office Information Systems, 8(4):325-362 (1990).

J. Mylopoulos, L. Chung, B. Nixon. Representing and using non-functional requirements: a process-oriented approach. IEEE Transactions on Software Engineering 18(6), 1992.

H.W. Nissen, M.A. Jeusfeld, M. Jarke, G. Zemanek, and H. Huber. Managing multiple requirements perspectives with meta models. IEEE Software, pp. 37-48 (March 1996).

B. Nuseibeh, J. Kramer, and A.C.W. Finkelstein. Expressing the relationship between multiple views in requirements specification. In Proceedings of the 15th Intl. Conf. on Software Engineering, Baltimore, Md, pp. 187-196 (1993).

K. Pohl. The three dimensions of requirements engineering. Proceedings of the 5th Intl. Conf. Advanced Information Systems Engineering, pp. 275-292, Paris, France (1993).

K. Pohl. Process-Centred Requirements Engineering. John Wiley & Sons, Chichester, UK (1996).

C. Potts. A generic model for representing design methods. In Proceedings of the 11th Intl. Conf. on Software Engineering (1989).

C. Potts, K. Takahashi, and A. Anton. Inquiry based requirements analysis, IEEE Software, pp. 21-32 (March 1994)

R. Prieto-Diaz. Implementing faceted classification for software reuse. Communications of the ACM 34(5):88-97 (1991).

P.P. Puncello, P. Torrigiani, F. Pietri, R.Burion, B. Cardile, and M. Conti. ASPIS: A knowledge-based CASE environment. IEEE Software, pp. 58-65 (1988).

B. Ramesh and V. Dhar. Supporting systems development by capturing deliberations during requirements engineering. IEEE Transactions on Software Engineering 18(6):498-510 (1992).

H.B. Reubenstein and R.C. Waters. The Requirements Apprentice: automated assistance for requirements acquisition. IEEE Transactions on Software Engineering 17(3):226-240 (1991).

C. Rolland, C. Souveyet, and M. Moreno. An approach for defining ways-of-working. Information Systems, 20(4):337-359 (1995).

E. Rosch. Prototype classification and logical classification: the two systems. New Trends in Conceptual Representation: Challenges to Piaget's Theory, Lawrence Erlbaum Associates (1983).

T. Rose, M. Jarke, M. Gocek, C. Maltzahn, and H. Nissen. A decision-based configuration process environment. Software Engineering Journal 6(5):332-346 (1991).

J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object Oriented Modeling and Design. Prentice Hall, Englewood Cliffs, NJ, 1991.

M. Shaw. Heterogeneous design idioms for software architecture. Proceedings of the 6th Intl. Workshop on Software Specification and Design, IEEE Computer Society Press, pp. 158-165 (1991).

Shaw, B. Gaines. Requirements acquisition. IEE Software Engineering Journal 11(3):149-165, 1996.

S. Si-Said, C. Rolland, G. Grosz. MENTOR: a computer-aided requirements engineering environment. Proc. 8th Intl. Conf. Advanced Information Systems Engineering, Heraklion, Greece, 22-43, 1996.

I. Sommerville. Software Engineering, Addison Wesley (1989).

I. Sommerville, T. Rodden, P. Sawyer, R.Bentley, and M.Twidale. Integrating ethnography into the requirements engineering process. In Proceedings of the 1st Intl. Symposium on Requirements Engineering, pp. 165-173, San Diego, Ca (1993).

G. Spanoudakis and P. Constantopoulos. Measuring similarity between software artefacts. In Proceedings of the 6th Intl. Conf. on Software Engineering and Knowledge Engineering (SEKE94), Skokie, Latvia (1994).

V. Storey. Understanding semantic relations. VLDB Journal 2(4):455-488 (1993).

A.G. Sutcliffe and N.A.M. Maiden. A theory of domain knowledge in requirements engineering. Technical Report CU-94-00A, Centre for Human Computer Interface Design, City University (1994).

A.G. Sutcliffe and N.A.M. Maiden. Bridging the requirements gap: policies, goals and domains. In Proceedings 7th International Workshop on System Specification and Design, IEEE Computer Society Press, pp. 52-55 (1993).

W. Swartout and R. Balzer. On the inevitable intertwining of specification and implementation, Communications of the ACM 25(7): 438-440 (1982).

B. Wielinga, W. Van de Velde, G. Schreiber, and H. Akkermans. Expertise model definition document. KADS project document KADS-II/M2/UvA, University of Amsterdam, (1993).

E.S.K. Yu. Modelling organisations for information systems requirements engineering. In Proceedings of the 1st Intl. Symposium on Requirements Engineering, San Diego, CA, pp. 34-41 (1993).

[1] The NATURE team comprised the following people: R.Dömges, S.Jacobs, M.Jarke, H.W.Nissen, K.Pohl (RWTH Aachen, Germany, coordinating partner); N.Maiden, A.Sutcliffe, C.Taylor, D.Till (City University, London, UK); P.Constantopoulos, G.Spanoudakis, Y.Vassiliou (FORTH Heraklion, Greece); G.Grosz, V.Plihon, C.Rolland, J.R.Schmitt, S.Schwer, S.Si-Said, C.Souveyet (Universite Paris-Sorbonne, France), J.Bubenko, R.Gustas, P.Holm, P.Johannesson, J.Ljungberg, B.Wangler (SISU Stockholm, Sweden).