A Framework for Mapping Traceability Relationships
Susanne A. Sherba, Kenneth M. Anderson, and Maha Faisal
University of Colorado
Department of Computer Science
Boulder, CO 80309-0430 USA
{sherba, kena, faisal}@cs.colorado.edu
Abstract
Traceability relationships help stakeholders understand
the many associations and dependencies that exist between
software artifacts created during a software development
project. Individual relationships between specific artifacts
can be useful in understanding portions of the system. However, these explicit relationships are greatly outnumbered by
the implicit relationships that exist between artifacts. This
situation adds to the complexity of software development.
Stakeholders need a way to understand all the relationships
that exist in a software development project.
We describe TraceM, a framework for automating the
management of traceability relationships. A key contribution of TraceM is its ability to transform implicit relationships into explicit relationships by processing chains of
traceability relationships. Thus, our framework has the potential to provide software developers with insight into the
state of their software development projects.
1. Introduction
Traceability can provide important insight into system
development and evolution. Antoniol et al. maintain that
traceability assists in both top-down and bottom-up program comprehension [5]. According to Jacobson, Booch,
and Rumbaugh, “[t]raceability facilitates understanding and
change [13].” Palmer asserts that “[t]raceability gives essential assistance in understanding the relationships that exist within and across software requirements, design, and implementation [18].”
There are many different types of relationships that exist
between artifacts. For example, the allocation of requirements to components can be traced [9], relationships between requirements and architectures can be captured [11],
trace information between design models and implementation can be established [10], and relationships between
source code and natural language documentation can be discovered [5, 14].
However, in isolation, each individual type of relationship provides only limited information. For example, a
stakeholder might need to verify that all requirements have
been implemented in code. If a trace between requirements and source code has been explicitly created, this is
an easy task. However, if only requirements to design and
design to code relationships have been created, the question is more difficult to answer. In this case, to answer his
question a stakeholder needs to manually follow each relationship from the requirements specification to the design
document and then ensure that each portion of the design is
linked to a code module.
This problem suggests that a requirements traceability
tool should be able to derive implicit relationships from the
explicit relationships already represented in the system. The
user should then be allowed to make these newly discovered
relationships explicit. In this way, a synergy is formed.
This paper presents the relationship mapping service of
TraceM, our traceability management system, and explains
how it allows new relationships to be discovered based on
existing explicit relationships. The next section describes
our conceptual framework. We then present an example of
the use of the relationship mapping service to demonstrate
the benefits it provides to stakeholders.
2. Approach
TraceM uses the generic services of open hypermedia
[17] and information integration [2] to enable a new approach to requirements traceability. When customized, we
believe that these techniques will be instrumental in solving
previously intractable aspects of requirements traceability,
such as handling the significant heterogeneity that is encountered in software development projects and automating the discovery of semantic relationships between software artifacts. In this section, we provide a brief overview
of open hypermedia and information integration. We then
present our conceptual framework.
2.1. Open Hypermedia
Open hypermedia systems [17] enable the creation and
viewing of relationships in heterogeneous applications as
well as the traversal of those relationships within and between applications. Open hypermedia services allow links
(relationships) to be stored separately from an artifact. The
open hypermedia data model supports complex relationships such as relationships with multiple anchors (n-ary
relationships) and relationships between relationships [3].
Open hypermedia systems also provide services to filter relationships based on type. To take full advantage of open
hypermedia services, an application needs to be integrated
with an open hypermedia system.1
2.2. Information Integration
Information integration [2] provides services to automate the process of discovering, creating, maintaining, and
evolving relationships between heterogeneous artifacts. Information integration uses the concept of a data source to
model information outside the information integration environment. A data source might be a file, a database, or even a
human. Translators are responsible for importing information from data sources into the information integration environment as well as exporting information from the information integration environment. Different translators can be
created to import and export information in various formats.
For example, a translator might be designed to import information from a requirements specification. Another translator might export relationships in a format suitable for use
by an open hypermedia system [1]. Integrators work within
the environment to automate the discovery and creation of
relationships. Specific integrators can be developed to find
different relationships within the environment. These relationships can be between artifacts, other relationships, or
collections of artifacts and relationships. In addition, information integration uses contexts to partition its information
space in various ways, including time-based and task-based
arrangements of a project’s artifacts.
2.3. Conceptual Framework
Our conceptual framework builds on techniques from
open hypermedia and information integration. As discussed
in the previous two sections, open hypermedia and information integration provide generic services that enable the
discovery, creation, maintenance, viewing, and traversal
1 Fortunately, the open hypermedia community has developed techniques to facilitate application integration [7, 20, 21].
of relationships. However, to be useful for requirements
traceability, these generic services must be customized.
TraceM, our traceability management system, is responsible for this customization and management. In contrast
to our approach, most commercial requirements traceability tools (e.g., DOORS [8]) support only the manual creation of traceability relationships. In addition, these tools
do not support the creation of new explicit relationships
from existing ones. TraceM provides this functionality in
six services: registration, scheduling, relationship mapping,
evolution, query, and export. The framework is shown in
Figure 1.
The main elements in our framework are tool, artifact,
relationship, and metadata. A tool is something that a
stakeholder uses to perform a task. Examples of tools include word processors, UML diagramming tools, integrated
development environments (IDEs), mail programs, version
control systems, and issue tracking systems. An artifact is
produced by a tool. A relationship is a semantic association between artifacts, portions of artifacts, or relationships.
Metadata allows a method engineer (or someone familiar
with the software project) to describe the artifacts and relationships that are created and used during the project.
As can be seen in Figure 1, stakeholders are able to use
their original tools. These tools produce heterogeneous artifacts. Artifact and relationship metadata is supplied by a
method engineer or someone familiar with the project. This
metadata is used by the traceability management system to
create and customize the information space. The metadata
includes information such as which translators can be applied to specific artifact types or which integrators can be
used to find particular relationship types; in addition, the
method engineer can indicate which artifacts and relationships are of interest to different stakeholders in the project
and at what stages in the project these relationships are
needed.
With guidance from the traceability management system
and based on the metadata, artifacts are translated into the
information integration environment. Here integrators can
automatically discover and create traceability relationships.
These relationships are forwarded to the open hypermedia
system which provides services to display the relationships
in the tools that originally created the artifacts. Without the
services provided by TraceM, using open hypermedia and
information integration to support requirements traceability would be a manual and highly tedious process. With
TraceM’s services, the enabling technologies of open hypermedia and information integration can be used to their
full potential.
The registration service allows users to register new artifact and relationship types as well as new translators and
integrators. The scheduling service is used to schedule the
execution of these translators and integrators. For example,
Stakeholders
Tool A
Tool B
Tool C
Context-specific
traceability
relationships
Heterogeneous
Artifacts
Method Engineer
Method
Definition Tool
Artifact and
relationship
metadata
Traceability Management System
Registration
Relationship
Mapping
Query
Scheduling
Evolution
Export
Anchors
and links
Artifacts
Information
Integration
Environment
Relationships
Open
Hypermedia
System
Figure 1. TraceM’s Conceptual Framework.
a method engineer might indicate that a translator should
be run every time a new version of a file is created in the
source control system or that an integrator should only be
run when requested by a software developer.
In addition, TraceM provides an evolution service to analyze the changes to a set of relationships over time. We believe that this service will give users insight into how a software project has reached its current state. For example, a
number of instances relationship might provide insight into
module cohesion. If the number of allocated to relationships between a requirements document and a component
diagram explodes after an iteration in the design phase, this
may indicate that one or more components have lost cohesion.
The query service allows filtering of relationships so
that different views of the information space can be created
based on the needs of various stakeholders. For example, a
customer might only be interested in viewing allocated to
relationships to determine that all requirements have been
allocated to components. However, a software developer
might need to delve further by viewing implemented by relationships. Users will be allowed to manually create and
delete relationships to further customize their view of the
information space.
As discussed in Section 2.1, to utilize all open hyperme-
dia services, a tool will need to be integrated with the open
hypermedia system. If a tool is not integrated with the open
hypermedia system, the user will be able to use the export
service to request an HTML summary of the artifact’s relationships.
The relationship mapping service will allow users to analyze relationships currently known to the system and to
“chain” explicit relationships together to form new relationships.2 This service will be implemented by a generic integrator that takes as parameters a chain of relationship types
(rel1→rel2→. . . →relN) and the name of the type assigned
to the derived relationship. By invoking this integrator, the
user will be able to create new explicit relationships. For instance, assume that implemented by relationships between
design documents and source code and tested by relationships between source code and test cases have already been
captured. Then this integrator could produce validated by
relationships between the design documents and test cases.
In particular, if design artifact A is implemented by source
code file B which is tested by test cases C and D, then this
integrator produces two new validated by relationships that
directly link A with C and A with D.
Our current approach to chaining relationships is based
on the intersection of anchors in different relationships. (An
2 Huang
[12] calls this an indirect or transitive dependency.
anchor represents a specific location in an artifact.) Relationships and thus the anchors they contain are discovered
and created by integrators. Anchors that integrators discover and create can be arbitrarily complex. Integrators can
employ various methods such as information retrieval techniques [4] or runtime analysis [10] to discover relationships.
At this point in our work, the task (and thus the complexity)
of locating and creating anchors is delegated to integrators
that perform relationship discovery. This approach greatly
simplifies both the specification and implementation of the
relationship mapping integrator.
Our initial approach to a relationship mapping integrator uses binary relationships in which one anchor is the source anchor and the other is the destination anchor.
If R1 and R2 are relationships
and R1.destinationAnchor = R2.sourceAnchor,
we can create a new explicit relationship R3 such
that R3.sourceAnchor = R1.sourceAnchor and
R3.destinationAnchor = R2.destinationAnchor.
However, in the future we plan to develop more complex
relationship mapping integrators. For example, an integrator might be created to perform chaining with relationships
that contain more than one source or destination anchor.
Another integrator might find potential matches based on
the intersection of anchors and then actually create relationships only if certain conditions are met in the artifact and/or
relationship metadata. For instance, a developer might impose a constraint that relationships can be chained only between artifacts that belong to a particular configuration of
a software system. Once these integrators are developed,
it is a simple task to incorporate them into the information
integration environment and the TraceM framework.
The user will also be able the view the relationships currently known by the system to identify possible mappings.
For example, a user might query the system to see if it currently knows about relationships between a requirements
specification and source code. The system might determine
that those relationships exist implicitly and suggest that they
can be created by chaining together allocated to relationships and implemented by relationships. The user can then
invoke the relationship mapping integrator to create a new
explicit representation of the implicit relationships.
The advantage of chaining relationships is that the addition of a single new relationship type has the potential
of creating many new relationships because it may form
new chains with previously existing relationship types. This
forms a powerful synergy of relationships that does not exist when relationships are viewed only as isolated instances.
An example of this synergy is presented in the next section.
Requirements
Specification
Source Code
allocated_to
elaborated_by
UML Class
Diagram
Mailing List
Archive
Figure 2. Initial Explicit Relationships.
3. Example
This section describes an example of how the addition
of explicit relationships along with the chaining of relationships can lead to the discovery of new relationships. It first
describes two separate projects in which relationships between different types of artifacts were discovered. It then
illustrates how the addition of a single new explicit relationship produces a synergism that is not found when the
relationships are viewed individually.
The first project was concerned with finding relationships between source code and messages in the archive of
a development mailing list. Mailing lists, especially those
used in open source projects, can provide valuable insight
into a project’s development and evolution. These lists contain a variety of information including historical information (rationale) as well as information about current defects,
issues, and changes. However, the sheer volume of postings
on these lists makes finding relevant information difficult, if
not impossible. (One of the authors recently subscribed to
the user mailing list of an open source project that had over
500 postings in one month [16].) For our prototype, we
chose simply to use method names from the source code to
create relationships with the messages posted to the mailing
list. The mailing list itself was partitioned based on posting date. This allowed us to create a loose correspondence
between messages and specific releases based on date. A
translator was created to extract the date, author, subject,
and content for each message from the mailing list archive.
Another translator was created to extract method names and
locations (start and end line numbers) from the source code.
The Code2MailingList integrator was then able to find relationships between the source code and mailing list for a
given development period.
The second project concentrated on relationships between a requirements specification and a UML class diagram. Again, we focused on the simple case of finding relationships between a UML class diagram and the requirements specification based on class name. For example, a
“Person” class in a UML class diagram was linked to all
occurrence of the word “person” in the requirements specification. Finding these relationships can be enhanced by
the use of information retrieval techniques (see, for example, [5]). In this project, our requirements specification was
written in Microsoft Word [15]. We were able to extract
the text from the Word document using the WordReqs translator. The class diagram artifact was created in ArgoUML
[6]. ArgoUML saves its model information in XML Model
Interchange (XMI) format [22]. Thus, an XMI translator
was used to extract class names from the diagram. Once
these two artifacts had been translated, a Class2Reqs integrator was able to discover relationships between the class
diagram and the requirements specification.
Figure 2 shows the initial state of the artifacts and relationships in these two projects. As can be seen in the figure, there are two disjoint sets of artifacts. Taken individually, the relationships between the requirements specification and the UML class diagram as well as the relationships
between the source code and mailing list archive provide
useful insight into the project. However, there is no way to
connect the artifacts in one set with those in the other. If we
can find a way to relate the two disjoint sets of artifacts, we
can gain a deeper understanding of the system. Several researchers have written about finding relationships between
class diagrams and source code [4, 10]. Thus, we propose
that by finding relationships between class diagrams and
source code using one of these methods, we can join the
two disjoint sets. This is illustrated in Figure 3.
Now that our disjoint sets have been connected, we are
able to gain more insight into the system. However, it is still
not easy to answer many questions. For example, a stakeholder might want to view all messages that are related to
a specific requirement. With our current information, he
would need to first follow relationships from the requirements specification to the UML class diagram. As shown
in Figure 4, the requirement in question might be related to
several classes. From there he would need to trace relationships from each of these classes to their implementation.
Even if we have a one-to-one correspondence between design classes and implementation classes, our stakeholder is
still left having to keep track of three separate relationships.
From the source code, he must trace to the messages in the
mailing list archive to find an answer to his question. Manually tracing these relationships can easily become confusing
and cumbersome.
Our proposed relationship mapping service will simplify
this task. Using a relationship viewing tool, the user can
Requirements
Specification
Newly created
explicit relationship
allocated_to
Source Code
elaborated_by
implemented_by
UML Class
Diagram
Mailing List
Archive
Figure 3. Additional Explicit Relationship
Connecting the Two Disjoint Sets.
Requirements
Specification
Source Code
UML Class
Diagram
Mailing List
Archive
Figure 4. Manually Tracing from a Requirement to Related Messages.
Requirements
Specification
Source Code
discussed_by
allocated_to
elaborated_by
implemented_by
UML Class
Diagram
Mailing List
Archive
Figure 5. Creating an Explicit Relationship
from an Implicit Relationship.
query the system about existing explicit relationships to determine if any explicit relationship between requirements
and messages in the mailing list exist. As Figure 3 shows,
the system will inform that user that the requested relationship does not exist explicitly but can be derived by chaining together three relationships: the allocated to relationship between the requirements specification and the design,
the implemented by relationship between design and code
and the elaborated by relationship between source code and
messages.
In this example, there is only one chain of relationships
that connects the requirements specification and the mailing
list archive. However, in some cases several distinct paths
between artifacts may exist. The system will show the user
the different chaining options available. The user will then
be able to indicate that a specific chain of relationship types
should be used to form a new explicit relationship type. In
this specific example, the user might indicate that the relationships allocated to→implemented by→elaborated by
should be chained together to form a new discussed by relationship. This newly created relationship is shown in Figure 5. Once this new relationship has been created, it becomes easy for a stakeholder to view all messages that are
related to a specific requirement, since it is now possible to
traverse directly from the requirements specification to the
mailing list archive.
4. Evaluation
To evaluate the feasibility of our approach, we are currently building a proof-of-concept prototype of our conceptual framework. We will use this prototype to evaluate the
interaction of our framework with the open hypermedia and
information integration systems as well as external tools;
in addition, we will assess TraceM’s ability to manage the
activities of translators and integrators.
The prototype will also allow us to perform a preliminary evaluation of TraceM’s user interface. We will engage
2–5 computer science graduate students to perform several
tasks (e.g., invoking translators and integrators, displaying
different types of relationships, exporting information, etc.).
This preliminary evaluation will help us detect useability
problems so that they will not influence later evaluation.
In the next phase of our evaluation, we will conduct a
comparative study using artifacts from a small software development project. We will ask test subjects to answer questions using three different approaches:
1. No explicit traceability links represented—test subjects are free to use any tools with which they are familiar (e.g., grep and find)
2. Traceability links created and represented in a commercial tool
3. Traceability links generated by TraceM and represented in the tools that originally created the artifacts
We plan to normalize the data between the commercial tool
and TraceM so that the quality of the traceability information captured does not influence the test. We will ask
questions such as “Which test cases are related to this requirement?” and “Which requirements are implemented by
this code module?” We will use post-evaluation surveys to
record the test subjects’ experiences in using the different
tools and to solicit their opinions on the various approaches.
In the final phase of our evaluation, we plan to apply our
approach to the artifacts of an open source project. This will
help us determine if our approach can successfully be scaled
to a larger project. It will also allow us to evaluate our approach using “real world” data. In addition, we will attempt
to develop a characterization of the information space by
defining the types of relationships that we can capture and
manage.
5. Related Work
TraceAnalyzer [10] is a tool that establishes trace information between design model elements and implementation. Test scenarios are executed on a running software system and execution information (such as code lines executed)
is obtained by using a monitoring tool. This information
is then used to establish a footprint for the scenario. The
footprint information is combined into a footprint graph;
this process is referred to as atomizing. Once the footprint
graph has been created, relationships to model elements can
be generalized and refined.
This approach differs from ours in that a running system must exist before trace information can be obtained.
Also, some initial information about potential relationships
between model elements and scenarios must be hypothesized manually. The tool assumes that this information is
correct until a contradiction is found. Our relationship mapping service focuses on explicit relationships already known
to the system and the new relationships that can be derived
from these existing ones. TraceAnalyzer focuses on finding
relationships between artifacts in a specific portion of the
information space. Our focus is on managing relationships
throughout a software development project.
Huang describes an event-based approach to traceability
[12]. In this approach, dynamic links are maintained as publish/subscribe relationships. Dependent objects subscribe to
the requirements on which they depend. The emphasis is on
maintaining an accurate traceability scheme.
The author includes a discussion of indirect or transitive
dependencies and how they influence the accuracy of the
traceability scheme. Both optimistic and pessimistic methods for updating indirect dependencies are presented. In the
pessimistic scheme a dependent object is notified immediately; in the optimistic scheme notification is delayed until
an actual query is performed in hopes that the inconsistency
is resolved before the query occurs.
Our approach is not directly concerned with updating inconsistencies although this could be accomplished by an
integrator. Rather, in the relationship mapping service we
focus on the discovery of new relationships based on the
explicit relationships currently known to the system.
Zisman et al. [23] describe an approach that automates
the discovery of traceability relationships between requirements artifacts. Their approach focuses on three specific
types of documents: a commercial requirements specification (CRS), a functional requirements specification (FRS),
and a requirements object model (ROM). Their process is
“driven by the requirements object model.” It first finds
traceability relationships between both the CRS and ROM
and the FRS and ROM. Based on these relationships, relationships between the CRS and FRS are created.
Our relationship mapping approach is more generic. Instead of creating relationships based on specific artifacts,
our approach allows the user to indicate which relationships should be chained based on relationship type. Relationships are then chained based on common source and
destination anchors. This allows relationship chaining to be
applied to any relationship type known to the system. In our
approach, the complexity of creating relationships and anchors is contained in the information integration integrators
that discover and create relationships, not the relationship
mapping service itself.
TOOR [19] employs a three phase approach to traceability: definition, registration, and extraction. In the definition
phase, a system administrator defines the objects and relationships of interest to the project. During the registration
phase, users are able to manually register objects and relations of interest by filling in templates. Relations in TOOR
are binary and contain the notion of a source and a target
object. The extraction phase allows traceability relationships to be computed and viewed. “Indirect” or transitive
relations can be computed by the system; there is no need
to represent these implicit relations explicitly. TOOR also
allows the creation of new relationships through the writing
of axioms; the axioms specify new relation types based on
existing relation types.
TOOR is similar to our framework in that it supports
user-defined relationships and composition of those relationships. TOOR’s registration phase is similar to the
metadata used by our framework. Our approach differs in
that, through the use of information integration techniques,
we plan to automate the creation of explicit relationships.
These relationships can then be composed (chained) based
on type.
6. Conclusion
In this paper we have described an approach to automating the management of traceability relationships. We have
presented our conceptual framework as well as an example
of the use of our relationship mapping service.
Traceability relationships provide valuable insight into a
system. They allow stakeholders to answer questions such
as “Which messages are related to this requirement?” or
“Which test cases cover this code module?” However, if
these relationships are not captured explicitly, it becomes
the responsibility of each individual stakeholder to manually trace through a set of explicit relationships to find answers to these questions. Thus, these implicit relationships
contribute to the complexity of software development.
Our relationship mapping service allows stakeholders to
view the explicit relationships in a system and to chain these
relationships together to make previously implicit relationships explicit. In addition, since these implicit relationships
are being made explicit within the context of a comprehensive requirements traceability framework, they now can be
explicitly managed, tracked, and analyzed as the software
project evolves.
This research is still in its early stages. We are currently
building a prototype of our traceability management system to evaluate the feasibility and utility of our approach.
We have integrated Microsoft Word [15] and ArgoUML [6]
with the Chimera open hypermedia system [3]. Integrations with a web browser, an integrated development environment (IDE), a testing tool, and an issue tracking system
are planned. We have also written several sets of translators and integrators for the InfiniTe information integration
environment to use in evaluating our information integration techniques [2] and are currently evaluating how these
generic information integration techniques can be applied
to the problems of requirements traceability.
References
[1] K. M. Anderson and S. A. Sherba. Using Open Hypermedia
to Support Information Integration. In OHS-7/SC-3/AH-3,
pages 8–16, 2001.
[2] K. M. Anderson, S. A. Sherba, and W. V. Lepthien. Towards Large-Scale Information Integration. In Proceedings
of the 24th International Conference on Software Engineering, pages 524–535, Orlando, FL, USA, May 2002.
[3] K. M. Anderson, R. N. Taylor, and E. J. Whitehead, Jr.
Chimera: Hypermedia for Heterogeneous Software Development Environments. ACM Transactions on Information
Systems, 18(3):211–245, July 2000.
[4] G. Antoniol, G. Canfora, G. Casazza, and A. De Lucia. Maintaining Traceability Links during Object-Oriented
Software Evolution. Software—Practice and Experience,
31:331–355, 2001.
[5] G. Antoniol, G. Canfora, G. Casazza, A. De Lucia, and
E. Merlo. Recovering Traceability Links between Code and
Documentation. IEEE Transactions on Software Engineering, 28(10):970–983, October 2002.
[6] ArgoUML. http://argouml.tigris.org.
[7] H. C. Davis, S. Knight, and W. Hall. Light Hypermedia Link
Services: A Study of Third Party Application Integration.
In Proceedings of the Sixth ACM Conference on Hypertext,
pages 41–50, Edinburgh, Scotland, September 1994.
[8] DOORS. http://www.telelogic.com/products/doorsers/doors/.
[9] M. Dorfman and R. F. Flynn. Arts—An Automated Requirements Traceability System. Journal of Systems and Software, 4:63–74, 1984.
[10] A. Egyed. A Scenario-Driven Approach to Traceability. In
Proceedings of the 23rd International Conference on Software Engineering, Toronto, Ontario, Canada, 2001.
[11] J. Han. TRAM: A Tool for Requriements and Architecture Management. In Proceedings of the Australasian Computer Science Conference, Gold Coast, Queensland, Australia, 2001.
[12] J. Huang. Robust Requirements Traceability for Handling
Evolutionary and Speculative Change. PhD thesis, University of Illinois at Chicago, Chicago, Illinois, 2002.
[13] I. Jacobson, G. Booch, and J. Rumbaugh. The Unified Software Development Process. Addison-Wesley, 1999.
[14] A. Marcus and J. I. Maletic. Recovering Documentation-toSource-Code Traceability Links using Latent Semantic Indexing. In Proceedings of the 25th International Conference
on Software Engineering, Portland, Oregon, USA, 2003.
R
R http://www.microsoft.com/office.
[15] MicrosoftWord
.
[16] ObJectRelationalBridge (OJB). http://db.apache.org/ojb/.
[17] K. Østerbye and U. K. Wiil. The Flag Taxonomy of Open
Hypermedia Systems. In Proceeding of the Seventh ACM
Conference on Hypertext, pages 129–139, Washington, DC,
USA, 1996.
[18] J. D. Palmer. Traceability. In R. H. Thayer and M. Dorfman,
editors, Software Requirements Engineering, Second Edition, pages 412–422. IEEE Computer Society Press, 2000.
[19] F. A. C. Pinheiro and J. A. Goguen. An Object-Oriented
Tool for Tracing Requirements. IEEE Software, pages 52–
64, March 1996.
[20] E. J. Whitehead, Jr. An Architectural Model for Application Integration In Open Hypermedia Environments. In Proceedings of the Eighth ACM Conference on Hypertext, pages
1–12, Southhampton, UK, April 1997.
[21] U. K. Wiil and J. J. Leggett. The HyperDisco Approach to
Open Hypermedia Systems. In Proceedings of the Seventh
ACM Conference on Hypertext, pages 140–148, Washington
DC, USA, March 1996.
[22] XML
Metadata
Interchange
(XMI).
http://www.omg.org/technology/documents/formal/xmi.htm.
[23] A. Zisman, G. Spanoudakis, E. Pérez-Miñana, and
P. Krause. Tracing Software Requirements Artefacts. In
Proceedings of the 2003 International Conference on Software Engineering Research and Practice (SERP’03), Las
Vegas, Nevada, USA, 2003.