Tracing Software Requirements Artefacts - Semantic Scholar

This paper is a draft of a paper that has appeared in the Proceedings of the 2003 International Conference on Software Engineering Research and Practice (SERP ’03)

Tracing Software Requirements Artefacts Andrea Zisman1 George Spanoudakis1 {a.zisman|gespan}@soi.city.ac.uk

Elena Pérez-Miñana2 Paul Krause2 {elena.perez-minana|krause}@philips.com

1

2

City University, Northampton Square, London EC1V 0HB, UK Philips Digital Systems Laboratories, Redhill Surrey, RH1 5HA, UK

Abstract The support for traceability between requirement specifications has been recognised as an important task in the development life-cycle of software systems. In this paper we present an approach for automatic generation and maintenance of bi-directional traceability relations between commercial and functional requirements expressed in natural language, and requirement object models. The generation of traceability relations is based on two types of traceability rules: requirements-to-object-model rules and inter-requirements rules. Our approach support three different types of traceability relations namely overlaps, realises, and requires. The requirement artefacts and traceability rules are described in XML. A prototype tool has been developed to demonstrate our approach, and has been used in a series of experiments that we have conducted to evaluate it. The results of these experiments are also presented.

1. Introduction Requirements traceability – the ability to relate requirements specifications with other artefacts created in the development life-cycle of a software system – has been recognised as a significant factor for efficient software project management and software systems quality [14][15][19]. Typically, traceability relations denote satisfiability, dependency, evolution or rationalisation relationships between software artefacts [19]. Depending on their semantics, traceability relations can be used to: (a) assist the process of verifying that a system meets its requirements, (b) establish the impact of changes in the requirements specification to other documentation and vice versa, (c) understand the evolution of an artefact, and (d) understand the rationale underpinning certain design and implementation aspects of a system. Despite its importance, the support for traceability in contemporary software engineering environments and tools is not always satisfactory. The major shortcomings of this support is the inability to automatically identify and maintain traceability relations involving artefacts which are

(a) expressed in natural language and, as a consequence, contain parts with ambiguous meanings, and (b) independently created by non-interoperable tools and which evolve autonomously. As a consequence, traceability links need to be established and maintained manually. This can be a time consuming and complex task. Consequently, despite the advantages that can be gained, effective traceability is rarely established unless there is a regulatory reason for doing so. In this paper we describe an approach to support automatic generation and maintenance of traceability relations between different types of software requirements artefacts, including commercial and functional requirements expressed in natural language and requirements object models. Our approach has been motivated by a study of the traceability problem in the case of requirements documentation developed for a family of TV products that have been constructed following the method described in [2]. According to this method, the requirements documentation consists of: (a) commercial requirements specification (CRS) – This specification describes functional and non-functional features of the TV family. Its purpose is to position the whole TV family within the relevant market. The CRS is expressed in natural language. (b) functional requirements specification (FRS) – This specification contains a complete and detailed description of common aspects of the behaviour of the systems in the TV family, and is specified in the form of use-cases. These use-cases are expressed in natural language according to a template adapted from [6]. (c) requirements object model (ROM) – This model specifies the main parts, and their relationships, of the products in the TV family that play a role in the interactions with the users and deliver the common functionality of the family members. The ROM is expressed in UML [13]. To generate traceability relations between the above kinds of artefacts, our approach advocates a lightweight natural language processing method driven by the requirements object model. The generation of traceability relations is based on two types of traceability rules: requirement-to-object-model and inter-requirement rules.

1

This paper is a draft of a paper that has appeared in the Proceedings of the 2003 International Conference on Software Engineering Research and Practice (SERP ’03)

statement CRS72 that is concerned with the adjustment of the bass and treble levels of TV sets.

Requirements-to-object-model rules specify ways of matching syntactically related terms in textual parts of the CRS and FRS, with related elements in the ROM (e.g. classes, attributes, operations). A rule in this category succeeds when a match between a group of terms in the text and a group of elements in the object model is found. When a rule succeeds, a traceability relation of the type specified by the rule is created between the part of the specification that incorporates the matched group of terms and their counterparts in the object model. The syntactic relations required by the rules are defined in terms of patterns of terms which have specific grammatical roles in a piece of text, referred to as "part-of-speech (POS) assignments" in the literature[5]. The grammatical role of the terms is determined by a probabilistic general-purpose grammatical tagger called CLAWS [5][10]. Inter-requirements rules specify conditions for creating traceability relations between the CRS and FRS. These conditions generate traceability relations between specific parts of the CRS and FRS subject to the existence of particular types of traceability relations between these parts and the object model. A prototype system has been developed, in order to evaluate and demonstrate our approach. This system interprets the traceability rules and generates traceability relations between the requirements artefacts. These artefacts and the traceability rules are represented as documents expressed in the eXtensible Markup Language (XML)[3]. The use of XML makes it possible to use our system in settings where the involved artefacts are created and managed autonomously by heterogeneous tools, such as word processors and CASE tools, as it typically happens in industrial settings. The remainder of the paper is structured as follows. Section 2 introduces the XML documents used to represent the artefacts of our concern. Section 3 presents an overview of our approach, and discussES the types of traceability relations and rules used to identify these relations. Section 4 describes the main features of the prototype that we have developed and presents experimental results that we have carried out to evaluate our approach. Section 5 discusses related work. Finally, Section 6 summarises our approach and proposes directions for future work.

It shall be possible to increase and decrease the bass and treble levels between maximum and minimum levels . . .

Figure 1: Commercial requirements specification As shown in Figure 1, each requirement statement has a unique identifier (CRSID attribute) and is specified as a sequence of English sentences (Description element). The words of these sentences appear as contents of XML elements that indicate their grammatical role in the sentence, as identified by CLAWS [5]. The names of these XML elements are identical to the POS-tags used by CLAWS. For instance, the word "bass" in CRS72 appears as the content of element . This element denotes that "bass" is a singular common noun. Other types of elements include , a plural common noun; , a singular article; and , the infinitive form of a verb. Functional requirements specification (FRS). A FRS is a document organised into sections that include use-cases. These use-cases are specified according to a template adapted from Cockburn [6]. In Figure 2 we present an extract of use case AF3 for changing the sound balance of a TV in XML. As shown in this figure, a use case description consists of a unique identifier, title, characteristic information, flow of (normal) events, exceptional events, and related information, following the template in Figure 2. As in the case of the CRS, the words in the textual parts of the use-cases appear within XML elements that denote their grammatical roles. The characteristic information of a use-case includes its brief textual description, its level within a system, preconditions that must be satisfied before its execution, and postconditions that must be satisfied after its execution. The flow of events includes a description of the user action that triggers the use-case (element Trigger), and a specification of each of the normal events that occur within the use-case. This specification includes a number that indicates the relative position of an event within the flow, a textual description of the event, and its following subevents, if any. Exceptional events (events not normally occurring in the course of a use-case) also have a number and a textual description. Finally, related information specifies the superordinate and subordinate use-cases.

2. Requirements Artefacts In this section, we give an overview of the CRS, FRS and ROM used in our approach. To illustrate the nature of these artefacts and the format for representing them in XML, we present extracts of the documentation related to the audio functions of TV models. Our discussion assumes a familiarity of the reader with XML. Commercial requirements specification (CRS). A CRS is a set of requirements statements organised into sections and subsections. Figure 1 shows the commercial requirement

2

This paper is a draft of a paper that has appeared in the Proceedings of the 2003 International Conference on Software Engineering Research and Practice (SERP ’03)

The tagged artefacts are transformed into XML documents (CRS.xml and FRS.xml) structured according to specific DTDs [3] as discussed in Section 2. The UML requirements object models are converted into XMI [12] format (ROM.xml) by using existing commercial exporters.

Change Balance Control Level Common

The audio balance may be changed , adjusting the relative volume levels of the left and right channels Primary task The … The … TV Viewer None The TV Viewer issues a command … Balance left and … … . . .

Software Requirements Specifications CRS.txt

FRS.txt

ROM.mdl

POS Assignment/XML Conversion

XMI Generation

CRS.xml

ROM.xmi FRS.xml

Synonym.xml

Generation of traceability relations

CRS_ROM.xml

CRS_ROM_rule.xml FRS_ROM_rule.xml

FRS_ROM.xml CRS_FRS_rule.xml

Generation of Traceability relations CRS_FRS.xml

Figure 2: Functional requirement specification Figure 3: The traceability process

Requirements object model (ROM). The ROM is specified as a UML class diagram, including classes, attributes, operations, associations, association ends, and generalisation relations between classes. This model is represented in XMI format [12].

The CRS.xml and FRS.xml documents are matched with ROM.xml based on requirements-to-object-model traceability rules. These rules are also expressed in an XML mark-up language that we have introduced for this purpose. The requirements-to-object-model traceability rules (CRS/FRS_ROM_rules.xml) specify ways of matching syntactically related terms in the textual parts of the CRS.xml and FRS.xml documents with related elements in the ROM.xml document. The result of the matching process is a set of traceability relations between the CRS and ROM, and FRS and ROM (CRS/FRS_ROM.xml) represented in XML. The CRS.xml and FRS.xml documents are matched with each other based on inter-requirements traceability rules, specified in XML (CRS_FRS_rule.xml). These rules have conditions, which require the existence of particular types of traceability relations between the CRS and ROM, and between the FRS and ROM (CRS_ROM.xml and FRS_ROM.xml, respectively) in order to create a relation between the CRS and FRS.

3. The Approach Figure 3 presents an overview of the process of our approach. The main aim of this process is to generate bidirectional traceability relationships between software requirement artefacts of the forms discussed in Section 2. Initially, the CRS and FRS specifications are expressed in structured forms of natural language. These artefacts are processed by the CLAWS tagger [5], which assigns POStags to their words. CLAWS is a general-purpose tagger developed assuming the British National Corpus [10]. Tagging in CLAWS is performed in four stages. In the first stage, the text is segmented in word and sentence units. In the second stage, initial POS-tags are assigned to words based on a lexicon and tagging rules. In the third stage, the initial POS-tags may be revised to take into account the context of words based on rules. Finally, in the fourth stage, POS-tags are further disambiguated using a Markov Model [16]. Experiments have showed that CLAWS has an errorrate of approximately 1.5%, and leaves about 3% of the ambiguities in POS-tags unresolved.

3.1. Traceability relations Our approach supports three different types of traceability relations namely overlap, realises, and requires relations, as described below.

3

This paper is a draft of a paper that has appeared in the Proceedings of the 2003 International Conference on Software Engineering Research and Practice (SERP ’03)

the sequence of terms master volume level in the description of use case AF1 is matched with attribute Volume Level of class Master Volume, and an overlap relation is created between them as a result.

Overlap relation. This is a relation between two elements of different artefacts, which refer to a common feature of the underlying system. The relation expresses the potential of a dependency between the artefact elements that it associates. An overlap relation may hold between: Πa sequence of terms in a commercial requirement statement and an element in ROM, Πa sequence of terms in a use-case element (description, flow of events, triggers) and an element in ROM, or Πa sequence of terms in a commercial requirement statement and in a use-case element. Realises relation. This is a relation between an element of a use-case in a FRS and a commercial requirement statement in a CRS. The meaning of the relation is that the use-case realises the commercial requirement statement. Requires relation. This is a relation between an element of a use-case in a FRS and a commercial requirement statement in a CRS. The relation denotes that the use-case cannot be realised without the existence of the structural or functional feature required by the commercial requirement statement. Traceability relations are established subject to the satisfiability of traceability rules associated with each of the above types.

Rule 1: IF Exists SEQUENCE(,, ) in CRS.xml or FRS.xml; , in ROM.xml Such that ATTRIBUTE_OF(,) and CONTAINS(NAME(), ) and (CONTAINS(NAME(), ) or CONTAINS(NAME(), ) ) and CONTAINS(NAME(), SINGULAR_FORM) Generate Relation OVERLAPS(SEQUENCE(,,),)

Rule 2: IF Exists SEQUENCE( , , , SEQUENCE(*, *, )*, ) in CRS.xml or FRS.xml; , in ROM.xml Such that OPERATION_OF(,) and MEMBER_OF(, SYNONYMS(STEREOTYPE()) and CONTAINS(NAME(),SINGULAR_FORM) and CONTAINS(NAME(), ) Generate Relation OVERLAPS (SEQUENCE(,,,SEQUENCE( *,*,)*,),)

3.2. Traceability rules Requirements-to-object-model rules. As discussed above, sequences of terms in a commercial requirement statement or a use-case may be related to an element in ROM only by overlap relations. The rules for creating overlap relations between parts of the above types of documents express heuristics indicating how terms, which have specific grammatical roles in the textual requirements specifications and appear in specific syntactic patterns, may have been modelled in the ROM. Examples of such rules are shown in Figure 4. The rules in this figure are expressed in a pseudo-language that is equivalent to the DTD that we use in our approach to specify these rules in XML. Rule 1, for example, can establish an overlap relation between an element of a use-case in the FRS (or a requirement statement in the CRS), and an attribute in the ROM. According to this rule, an overlap relation is created if there is a sequence of two qualifiers ( and ) and one singular or plural noun () in the description of the use-case or the requirement statement and a class with an attribute in the ROM such that, (a) the name of the class contains the first two qualifiers in the sequence and the name of the attribute includes the singular form of the qualified noun in the sequence, or (b) the name of the class contains the first qualifier in the sequence and the name of the attribute contains the second qualifier and the singular form of the qualified noun. An example of an overlap relation generated by Rule 1 is shown in Figure 5. In this example,

Figure 4: Requirements-to-object-model rules Rule 2 in Figure 4 can establish an overlap relation between an element of a use-case in FRS (or a commercial requirement statement in CRS), and an operation in the ROM. This rule attempts to match a verb-phrase in active voice followed by a qualified noun () that is the object of it with a class in ROM and one of its operations. The main verb of the verb-phrase has to be in the infinitive form () and is matched with the operation if it is a member of the set of synonyms associated with the stereotype of this operation1, or if the action denoted by the verb is compliant with the functional role of the operation. is qualified by another noun (). x3 and x7 may also be separated by a conjunction of one or more other qualifiers of x7. The matching succeeds if, in addition to the condition about the verb of the pattern, x3 is contained in the name of the class and the singular form of x7 is contained in the name of the operation of it. Rule 2 succeeds in the case of use-case AF2 and operation Set Bass Level of class Bass Control in Figure 5. This is because verb "adjust" belongs to the set of synonyms of the stereotype of the operation Set Bass Level 1

4

As in UML [13], here a stereotype is used to signify the main functional role of an operation. For example, operations that set or modify the state of class instances are stereotyped as "set" operations.

This paper is a draft of a paper that has appeared in the Proceedings of the 2003 International Conference on Software Engineering Research and Practice (SERP ’03)

("set"). The satisfaction of Rule 2 creates an overlap relation between the sequence of elements adjust thebassor< /CC>thetreblecont rollevel in the description of use-case AF2 and operation Set Bass Level.

A qualification of this form may be modelled in an object model through the ownership of an attribute, association end or operation by a class. The first of these three possibilities is expressed by Rule 1. The main assumptions underpinning this relatively lightweight text analysis approach are that: (a) during the development of software systems developers are expected to consult the requirements documents and use the terminology in these documents when creating ROM, and (b) the deployed ROM establishes the main entities and features of a software system and its domain, defines the terms that should be used to denote them, and declares the important semantic relations between them. ROM provides a means for identifying what is significant in a textual requirement specification and how these significant terms are semantically related to each other.

Rule 1

Adjust Master Volume Level… The master volumelevel maybe adjusted . . .

Adjust Analogue Bass or Tremble Control … The TVViewer issuesa commandto adjustthe bassorthe treblecontrol level . . .

Inter-requirements traceability rules. These rules are used to generate traceability relations between the CRS and FRS. The conditions set by these rules as a prerequisite for generating traceability relations are concerned with the existence of particular combinations of overlaps relations between CRS and FRS and related elements in ROM. Table 1 shows examples of these conditions in the case of relations between attributes and operations in the ROM on one hand, and commercial requirement statements and usecase elements on the other. As shown in this table: (a) A requires relation will be created from an element in a use-case (UCi) to a commercial requirement statement (CRSj), if there are overlap relations: (i) between an attribute X in ROM and CRSj and (ii) between UCi and an operation that sets the value of the attribute X (operation*X*)2 (2nd row of Table 1). (b) An overlap relation will be created from an element in a use-case (UCi) to a commercial requirement statement (CRSj), and vice-versa, if both these elements overlap with the same attribute in ROM (1st row of Table 1). (c) A realises relation will be created from an element in a use-case (UCi) to a commercial requirement statement (CRSj) if there are overlaps relations: (i) between operation operation*X* in ROM and CRSj, and (ii) between operation*X* and UCi (5th row of Table 1). An example of realises relation created by the traceability rule for case (c) above is a relation between the description of the trigger of use-case AF2 and the description of CRS72. This relation is created since both requirement specifications have overlap relations with operation Set Bass Level of class Bass Control (Figure 5). The inter-requirements traceability rules do not attempt any form of direct grammatical analysis and matching of textual descriptions of CRS and FRS. The conditions that they specify are concerned only with the existence of

Audio Processing Master Volume Set Balance()

Max. Volume Volume Level Mute Status GetMasterVolumeLevel()

Treble Bass

Balance

SetMasterVolumeLevel()

Bass Processing

Balance Setting Get Balance Setting()

Treble

Bass Control

Max. Treble Treble Level

Max. Bass Bass Level

Get Treble Level() Set Treble Level()

Get Bass Level() Set Bass Level()

Rule 2

Figure 5: Examples of traceability relations The rules that we are using to trace requirement documents to the object model do not attempt any form of complete or deep semantic analysis of the text involved. They do not even attempt a complete syntactic analysis (parsing) of the text. The objective of the rules is to identify local parts of textual requirement specification that incorporate terms which: (i) follow specific grammatical patterns and (ii) appear in the ROM as sub-strings of names of elements that are related by particular types of relations which reflect these patterns. In the case of Rule 1, for instance, the grammatical pattern expected by the rule indicates a form of qualification: the former two nouns qualify the third noun.

2

5

The expression operation *X* denotes an operation whose stereotype is stereotype and whose name includes the string X.

This paper is a draft of a paper that has appeared in the Proceedings of the 2003 International Conference on Software Engineering Research and Practice (SERP ’03)

traceability relations between requirement specifications and ROM. As a consequence, the generation of traceability relations between the textual specifications is driven by the object model, and relates items in the textual descriptions only if they are related to the same counterpart in the object model. This makes our approach different from various methods for information retrieval in which, the significance of different terms in a set of documents is determined by the frequency of their appearance in the set [7]. The justification for our approach lies with the assumptions that we make about the role of the ROM in the context of software systems development. CRS-ROM overlaps attribute X attribute X attribute X operation *X* operation *X* operation *X* operation *X operation *X operation *X

FRS-ROM overlaps attribute X operation *X* operation *X* attribute X operation *X* operation *X* attribute X operation *X* operation *X*

traceability relations between not previously considered documents. Case-1 Case-2 Case-3 Case-4

User-1 User-2 User-2 User-3 User-1 User-1 User-3

Recall 0.81 0.81 0.95 0.79 0.51 0.64 0.46

Precision 0.68 0.74 0.94 0.67 0.86 0.92 0.52

Table 2: Measured recall and precision rates More specifically, we used the same set of 26 rules to detect traceability relations between: (i) part of FRS that specified the use-cases related to the audio-functions of TV products and ROM (Case-2) (ii) part of CRS that specified requirements about the video functions of TV products and ROM (Case-3) (iii) part of FRS that specified the use-cases related to the video functions of TV products and ROM (Case-4) The traceability relations generated by the rules in each of these cases were compared against sets of traceability relations that were manually identified by three different users with substantial experience in object modelling. The recall and precision measures calculated for each of the 4 cases and different users are shown in Table 2. These results are clearly preliminary. However, it is possible to obtain recall and precision measures comparable to those achieved by systems that perform text classification by deploying lightweight natural language processing techniques in other domains (see [20]). The relatively lower recall measure obtained in Case-3 reflected the use of grammatical patterns in the writing style of CRS that had not been captured by the small set of rules being used. Further analysis of these patterns indicated that with 2 more rules we could raise the recall to 0.62 without affecting precision. In Case-4, we obtained low results given the relations indicated by User-3 but substantially better results given the relations by User-1. This manifests the possibility of different interpretation of the contents of artefacts by distinct users.

FRS-CRS relation overlap requires requires overlap realises overlap overlap overlap realises

Table 1: Conditions for FRS-CRS traceability relations

3. Implementation and Evaluation Aspects In order to evaluate and demonstrate our approach we have implemented a traceability tool to support: (a) automatic transformation of documents tagged by CLAWS into XML, (b) definition of traceability rules, (c) construction of synonyms lexicons for operation stereotypes, and (d) automatic generation of bi-directional traceability relations. The tool incorporates a traceability rule engine, which interprets the traceability rules and generates traceability relationships between the artefacts. We have conducted some experiments using our tool to evaluate the precision and recall that can be achieved by our system. We used the following standard definitions of precision and recall measures: Precisioni = | ST ∩ UTi | / | ST | Recalli = | ST ∩ UTi | / | UTi | where: ST is the set of traceability relations identified by the tool, UTi is the set of traceability relations identified by user i, and | X | is the cardinality of set X. In the experiments, we used requirement documentation developed for a family of TV products created by Philips, including CRS, FRS and ROM documents. We deployed 26 traceability rules. These rules were specified by investigating the grammatical patterns, which appeared in the part of the CRS that specified requirements regarding the audio functions of the TV set (Case-1). The objective of our experiment was to measure the recall and precision that could be achieved using the same set of rules to detect

6.

Related Work

The work presented in this paper is related to the use of natural language processing (NLP) techniques in requirements engineering and requirements traceability. Researchers have used NLP techniques to generate structured or formal models from requirements documents expressed in natural language (CICO [1], OICSI[21] and COLOR-X[4]), or identify terms denoting entities that deserve further consideration within such documents (Moreno [11]). Model generation has been based on semantic or grammatical analysis of natural language. CICO[1] transforms tagged requirements statements into various forms of structured models based on rules.

6

This paper is a draft of a paper that has appeared in the Proceedings of the 2003 International Conference on Software Engineering Research and Practice (SERP ’03)

OICSI[21] generates a semantic network from requirement statements expressed in natural language, by using rules to identify the grammatical nature of words in a sentence and the general meaning of verbs. COLOR-X[4] supports nonautomatic construction of formal event models from lists of events described in natural language. Moreno has also developed a method that transforms natural language requirement statements into an object model [11]. Her method is based on a grammatical (as opposed to semantic) analysis of requirements statements, and initially transforms them into a restricted form of natural language. Subsequently, the restricted statements are transformed into object structures based on patterns that translate linguistic structures into conceptual structures. Rayson et al. [17] have used probabilistic grammatical and semantic tagging techniques to extract terms denoting stakeholder roles. Their experiments have indicated that general purpose semantic tagging is weak and needs tailoring to technical corpus in order to be used in requirements engineering. Research into requirements traceability has been concerned with the study and definition of different types of traceability relations [8][14][19], and the provision of support for generating and maintaining these relations in requirements engineering tools [9][15][19][22]. The majority of contemporary requirements engineering and traceability tools offer only limited support for traceability and require the users to create traceability relations manually. Some of these tools allow users to declare their own types of traceability relations but provide no support for defining their semantics in a declarative and enforceable axiomatic form (RETH[9], DOORS[22]). Other tools offer built-in types of traceability relations with pre-defined semantics (Remap[18]). An exception to the norm is TOOR[15], which allows users assert traceability relations of different types and define their semantics.

Acknowledgement The authors gratefully acknowledge the comments and critical feedback of Tim Trew (Philips Research Laboratories, Redhill), Klaus Pohl (University of Essen), and Patricio Letelier (University of Valencia). The research presented in this paper has been partially funded by Philips Research Laboratories, Redhill.

References [1]

[2]

[3]

[4]

[5] [6] [7]

[8]

[9] [10]

[11]

[12]

[13] [14]

7. Conclusion and Future Work

[15]

In this paper we have presented an approach to support automatic generation and maintenance of bi-directional traceability relations linking commercial and functional requirements specifications expressed in natural language and requirements object models. These relations are generated based on requirements-to-object-model and interrequirements rules. Currently, we are extending our tool to optimise the generation and maintenance of traceability relations as requirement artefacts evolve. We are also investigating: (i) the merit of our approach in supporting generation of additional types of traceability relations between features of requirements specifications that pertain to product families such as the specification of diversities between products, and (ii) the development of support to developers for amending the rule base of the system when the rules fail to produce traceability relations or produce incorrect relations.

[16]

[17]

[18]

[19]

[20]

[21] [22]

7

Ambriolla V., Gervazi V., "Processing Natural Language Requirements", Proceedings of International Conference in Automated Software Engineering (ASE ’97), 36-45, 1997 America P., Wijgerden J., "Requirements Modelling for Families of Complex Systems", In Proc. of IW-SAPF, Springer LNCS 1951, 2000. Bray T., Paoli J., Sperberg-McQueen C.M., Maler E., “Extensible Markup Language (XML) 1.0”, second edition, http://www.w3.org/TR/2000/WD-xml-2e-20000814, W3C. Burg J., van de Riet R., "COLOR-X: Linguistically-based Event Modelling: A General Approach to Dynamic Modelling", In Proc. of the 7th Int. Conference on Advanced Information System Engineering (CaiSE ' 95), 26-39, 1995. CLAWS. http://www.comp.lancs.ac.uk/ucrel/claws. Cockburn A., "Structuring Use-Cases With Goals", JOOP, Sep-Oct 1997. Faloutsos C., Oard D. "A Survey of Information Retrieval and Filtering Methods", Tech. Report CS-TR3514, Dept. of Computer Science, Univ. of Maryland, 1995. Gotel O., Finkelstein A., "Contribution Structures, Proceedings of 2nd International Symposium on Requirements Engineering, (RE ' 95), 100-107, 1995. Kaindl H., "The Missing Link in Requirements Engineering", Software Engineering Notes, June 1992, pp. 498-510 Leech G., Garside R., and Bryant M., "CLAWS4: The tagging of the Bristish National Corpus", In Proc. of 15th International Conference on Computational Linguistics, Kyoto, Japan, 622-628, 1994. Moreno A., "Object-Oriented Analysis from Textual Specifications", In Proc. of 9th International Conference on Software Engineering and Knowledge Engineering (SEKE 97), 1997. OMG (1998). XML Metadata Interchange (XMI) - Proposal to the OMG OA&DTF RFP 3: Stream-based Model Interchange Format (SMIF). Technical Report AD Document AD/98-10-05. OMG (1999). OMG Unified Modelling Language Specification Version 1.3. ftp://ftp/omg.org/pub/docs.ad/99-06-08.pdf. Pohl K. Process-Centered Requirements Engineering. John Wiley Research Science Press, 1996. Pinheiro F., Goguen J., "An Object-Oriented Tool for Tracing Requirements", IEEE Software, 52-64, March 1996. Poritz, A.B., "Hidden Markov models: a guide tour”. In International Conference on Acoustics, Speech and Signal Processing, Vol I, 1998, 7-13, New York, IEEE. Rayson et al., "The REVERE project; experiments with the application of probabilistic NLP to systems engineering". 5th International Conference on Applications of Natural Language to Information Systems (NLDB ' 2000), Revised papers, SpringerVerlag, LNCS 1959, 288-300, 2000 Ramesh B., Dhar V., "Supporting Systems Development Using Knowledge Captured During Requirements Engineering", IEEE Transactions in Software Engineering, June 1992, 498-510, 1992. Ramesh B., Jarke M., "Towards Reference Models for Requirements Traceability", IEEE Transactions in Software Engineering, 27(1), 5893, 2001. Riloff E., Lehnert W., Information Extraction as a Basis for HighPrecision Text Classification, ACM Transactions on Information Systems, 12(3), 296-333, 1994. Rolland C., Proix C., "A Natural Language Approach for Requirements Engineering", In Proc. of CaiSE ' 92, LNCS , 1992. Teleologic, Teleologic DOORS,www.teleologic.com/products/doors