Traceability and Interfacing Between Requirements Engineering and

UML Domains using the Standardized ReqIF Format

Arne Noyer

1,2

, Padma Iyenghar

, Elke Pulvermueller

, Florian Pramme

and Gert Bikker

Institute for Software Engineering, University of Osnabrueck, Osnabrueck, Germany

Willert Software Tools GmbH, Hannoversche Str. 21, Bueckeburg, Germany

Institute for Distributed Systems, Ostfalia University, Salzdahlumer Str. 46/48, Wolfenbuettel, Germany

Keywords:

Requirements Interchange Format (ReqIF), Model-driven Development, Uniﬁed Modeling Language (UML),

Requirements Engineering, Requirements Traceability.

Abstract:

Model Driven Development (MDD) is deemed as a key to address the increasing complexity of software sys-

tems. It is imperative that the developed software fulﬁlls the end-user’s requirements. This implies that a

collaboration between the Requirements Management (RM) tools and the modeling tools, enabling complete

traceability and interfacing among these tools, is essential. On the other hand, existing tools collaborating

between RM and modeling tools support a very limited sub-set of new features (e.g. traceability analysis)

and are compatible with only a few tools. As a result, software engineers are often required to educate them-

selves on another (often complex), intermediate (collaborating) tool, merely to realize a very limited sub-set

of supported features. This paper addresses these gaps and introduces an approach for exchanging informa-

tion between RM tools and Uniﬁed Modeling Language (UML) tools by using the standardized Requirements

Interchange Format (ReqIF). The proposed approach (a) enables software developers to create links between

requirements and UML elements in their modeling tool and (b) facilitates requirements engineers to make

traceability/other analyses down to linked model elements inside their RM tool. In contrast to many other

approaches, no additional user interface is needed for traceability.

1 INTRODUCTION

In the series of evolution in software engineering,

Model Driven Architecture (MDA) can be considered

as the next/ongoing paradigm shift. Towards this di-

rection, in the recent decade, MDD (France et al.,

2006) has already made signiﬁcant inroads for its

application in software engineering projects. Some

examples of tools used for MDD in software engi-

neering projects are Rhapsody (IBM, 2014b), En-

terprise Architect (Sparx Systems, 2014), Papyrus

(Eclipse Foundation, 2013a) and Matlab/Simulink

(Mathworks, 2014). In this paper, the focus is on

the Uniﬁed Modeling Language (UML) for MDD.

The UML (Object Management Group, 2013b) is one

among the widely used industry standards for MDD

(France et al., 2006). Besides general UML elements,

UML proﬁles enable to address application areas such

as real-time embedded systems and system engineer-

ing.

While the software requirements engineering pro-

cess by itself may vary widely on the application do-

main, it is imperative that the requirements speciﬁed

for the software are met during system modeling and

development (e.g. using a UML tool). This implies

that, while collaborating between a RM tool and a

modeling tool, there needs to be complete traceability

and interfacing between the requirements engineering

tool and the MDD tool. This aspect gains further sig-

niﬁcance during the development of safety-certiﬁed

software.

However, UML tools (e.g. Rhapsody) have to in-

terface with further interfacing tool(s) (e.g. Rational

Rhapsody Gateway (IBM, 2010)) that may providean

interface between the UML tool and RM tools. This

is required, for example, to create links between re-

quirements and model elements and to provide addi-

tional analysis capabilities to support traceability and

requirements analysis. However, many interfacing

tools only allow to do such things inside their own

user interfaces. Thereby, engineers have to learn how

to work with another tool, which can be quite com-

370

Noyer A., Iyenghar P., Pulvermueller E., Pramme F. and Bikker G..

Traceability and Interfacing Between Requirements Engineering and UML Domains using the Standardized ReqIF Format.

DOI: 10.5220/0005327303700375

In Proceedings of the 3rd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2015), pages 370-375

ISBN: 978-989-758-083-3

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

plex. This can result in a lower acceptance rate for a

traceability solution. Further, most of the interfacing

tools are proprietary for one modeling tool and only

support data exchange with certain RM tools.

Addressing the aforementioned gaps this paper

presents a framework for complete traceability and in-

terfacing between software requirements engineering

tools and modeling tools. It presents the following

novel contributions with initial prototype implemen-

tation and results.

• Usage of the standardized ReqIF format to trans-

fer representations of requirements to UML tools

• Analysis of elements in UML tools, which are

linked to requirements

• Creation of representations for linked model ele-

ments inside the ReqIF ﬁle

• Enables traceability and impact analyses directly

in UML and RM tools

2 STATE OF THE ART AND

RELATED WORK

In requirements engineering, traceability is very im-

portant. Often, there are different reﬁnement levels

of requirements (e.g. user requirements and system

speciﬁcation) in RM tools. Requirements of these lev-

els are linked to each other in order to ensure consis-

tency. If a requirement changes, a requirements engi-

neer can check whether linked requirements have to

be changed accordingly or analyze the impact. There

are already powerfulmechanisms for such a traceabil-

ity and other analyzes in many RM tools (e.g. (IBM,

2014a) and (Polarion Software, 2014)).

In the requirements management domain, the Re-

quirementsInterchange Format (ReqIF) (Object Man-

agement Group, 2013a) has become a standard by the

Object Management Group (OMG) (Object Manage-

meng Group (OMG), 2014) for exchanging require-

ments between different RM tools. It is a norma-

tive XML-based data format to exchange and store

requirement information between different tools and

tool chains. ReqIF is an ensuing descendant of the

RIF standard deﬁned by Hersteller Initiative Software

(HIS) (Hersteller Initiative Software (HIS), 2014)

working group in the automotive domain.

ReqIF even allows that requirements of different

levels are managed in different tools. For instance,

the user requirements could be managed by a client in

his RM tool. He can export them into a ReqIF ﬁle and

then send them to a supplier. On the other hand, the

supplier can import the requirements into another RM

tool, create system speciﬁcation requirements in this

tool and create links to the user requirements. After-

wards, the system speciﬁcation requirements and their

links to user requirements can be exported in a ReqIF

ﬁle and can be send back to the client. The client can

import the ReqIF ﬁle again and has complete trace-

ability information in his RM tool. Nowadays, many

RM tools support the ReqIF format for import/export.

Unfortunately, for exchanging requirements

and/or traceability information with MDD, there is

not such a standard. Most of the solutions, which are

available on the market, are proprietary for a certain

modeling tool, as shown in Fig. 1. They are based

on (third party) interfacing tools, which are only

compatible with a selection of the RM tools and other

sources for requirements (e.g. Rational Rhapsody

Gateway (IBM, 2010)).

RM Tool 1

UML

Tool 1

UML

Tool 2

UML

Tool 3

Interfacing Tools

for transferring

requirements

or for accessing

data and linking

RM Tool 2

Text

Documents

Interfacing

Tool 1

Interfacing

Tool 2

Interfacing

Tool 3

RM Tool 3

Figure 1: Proprietary Interfacing Tools for Different UML

Tools.

There is a very detailed survey about traceability

in RM and MDD in (Winkler and von Pilgrim, 2010).

Among other topics, traceability in practice, over-

coming (current) limitations and future challenges are

discussed. As practice, it is mentioned that require-

ments traceability is usually managed in RM tools.

When a traceability to other tools is needed, success

stories are about companies, which developed their

own proprietary traceability tools for their internal us-

age.

As technical limitations, it is mentioned in (Win-

kler and von Pilgrim, 2010), that creating and main-

taining traceability links is not supported enough by

tools. Further, there is a lack of integration between

different tools and quite some effort has to be put in

keeping the links up to date.

The survey (Winkler and von Pilgrim, 2010) an-

alyzes two categories for overcoming integration is-

sues: integrative approaches and specialized trace-

ability tools. The specialized tools do all have their

own editors and user interfaces, which makes them

less intuitive, but traceability activities are supported

very well. Some even allow automatic trace record-

ing.

Integrative approaches, discussed in (Winkler and

TraceabilityandInterfacingBetweenRequirementsEngineeringandUMLDomainsusingtheStandardizedReqIFFormat

371

von Pilgrim, 2010), should be compatible with exist-

ing RM and MDD tools. Of course, the trace infor-

mation has to be stored in some way. In (Walderhaug

et al., 2008) an approach is proposed, which uses a

central repository for traceability information. Other

tools have to be integrated to this solution by using

its API. All the integrative approaches do not manage

the traceability links in the original tools, in which

the linked artifacts were created. This implies, that

the traceability links can not be viewed and analyzed

in the original tools. Further, it is pointed out in (Win-

kler and von Pilgrim, 2010) (page 548): ”Users that

are already familiar with their development tools usu-

ally do not want to switch tools just because some

other tool supports traceability”. Therefore, the goal

of the proposed approach is that users can do every-

thing in their tools.

In recent research, there is another integrative ap-

proach described in (Graf and Jastram, 2011). Com-

ponents of the prototype implementation seem to be

part of the product Yakindu Traceability (itemis AG,

2014) now. The approach provides its own traceabil-

ity meta-model and allows an integration with differ-

ent tools and formats by using so called Trace Point

Providers, which are basically like plug-ins. There is

already a Trace Point Provider for the ReqIF format,

which implies that it is compatible with a wide variety

of RM tools. Further, there is a Trace Point Provider

for UML models from Papyrus (Eclipse Foundation,

2013a). Papyrus uses the Eclipse-based implemen-

tation (Eclipse Foundation, 2013b) of the standard-

ized UML meta-model. Hence, it is possible to have

a traceability between requirements in ReqIF ﬁles and

UML model elements from Papyrus. Additionally,

Yakindu Traceability allows to deﬁne link types and

which kinds of artifacts they can have as source and

target. Furthermore, it has a powerful Eclipse-based

user interface for creating links, their visualization

and for traceability analyzes. While this approach

seems to be ﬂexible and extensible to be compatible

with different tools, the same challenges as for other

integrative approaches apply.

Open Services for Lifecycle Collaboration

(OSLC) (Open Services for Lifecycle Collaboration

(OSLC), 2014) is not only a technology for integrat-

ing RM tools with MDD tools, but a general approach

for exchanging data between different tools (Ejaz

Ul Haq, 2013). It is already used for an integration

between Rhapsody (IBM, 2014b) and Doors (IBM,

2014a) by IBM. Creating OSLC interfaces for tools

enables them to directly access each others data.

Thus, tools have to implement which data they want

to visualize and what users are able to do with them.

Further, currently only a few RM and MDD tools

support OSLC. Furthermore, the IT infrastructure

must allow such a communication between tools.

This may not be always available; for instance, in

a situation when the requirements engineer is an

employee from one company and has to send the

speciﬁed requirements to a software developer in

another company.

3 INTERFACING BETWEEN RM

AND MDD TOOLS WITH REQIF

Since the ReqIF format is a standard for exchanging

requirements and traceability is already well estab-

lished in RM, ReqIF is also especially suitable for ex-

changing requirements with a modeling tool. A pro-

posed workﬂow for this exchange is illustrated in Fig

ReqIF

Create User

Requirements

Create System

Specification

Export System

Specification

Import

Representations for

System Specification

Model Software

Artefacts

Create Dependencies between

System Specification Requirements

and Software Artefacts

Export

Representations for

linked Software

Artefacts

ReqIF

Import

Representations

for linked Software

Artefacts

Make a Traceability

Analysis

RM Tool MDD Tool

Figure 2: Proposed workﬂow for working with reqirements

in MDD.

On the left side, it is depicted what a requirements

engineer creates in his RM tool, while on the right

side, the work of a software developer in a MDD tool

is depicted. For a high acceptance rate of the ap-

proach, both have to be able to do all their work in

their established RM and MDD tool. A requirements

engineer exports the requirements, which are relevant

for the software developer, into a ReqIF ﬁle. Then,

the ReqIF ﬁle is sent to the software developer. The

software developer in turn imports representations of

the requirements into his MDD tool. Since not every

MDD tool necessarily supports requirementsnatively,

they may have to be represented by other elements,

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

372

depending on the MDD tool. Afterwards, model arti-

facts can be linked with requirements by using native

mechanisms of the MDD tool (e.g. by using UML

Dependencies). In order to transfer the traceability

information back to the RM tool, representations of

linked model artifacts are created in the ReqIF ﬁle

and are also linked to the requirements in it. Finally,

those representations of linked model artifacts can be

imported into the RM tool. In practice, the require-

ments should only be changed inside the RM tool

and the model artifacts only inside the MDD tool to

avoid redundancy issues. Thereby, loss of data can be

avoided, when changes inside representations for ele-

ments of the other domain are made. The workﬂow is

similar to what business partners already do when ex-

changing requirements of different reﬁnement levels,

but extended to the domain of MDD.

The proposed workﬂow (Fig. 2) enables require-

ments engineers to make a traceability analysis and a

coverage analysis inside the RM tool. In order to al-

low software developers to make an impact analysis

inside the MDD tool, representations of changed re-

quirements have to be marked as changed (e.g. by us-

ing a UML Stereotype) when updating requirements.

Then, the software developer can check if linked

model artifacts have to be modiﬁed. Any analysis can

be made inside the already used tools. This also re-

duces the amount of needed licenses for tools. A soft-

ware developer, for instance, does not need to have a

RM tool installed on his computer.

In the proposed approach, the representations of

model artifacts are stored in the ReqIF format; just

like requirements as SpecObject (Object Manage-

ment Group, 2013a) elements of the ReqIF format.

SpecObjects reference a certain SpecType to indicate

what kind of requirements they are. Since the Re-

qIF format allows to deﬁne attributes for a SpecType,

information about the model artifacts, such as their

name and type, are stored inside the ReqIF ﬁle. Val-

ues of these attributes can then be shown for their rep-

resentations inside the RM tool.

Requirements, on the other hand, have to be repre-

sented inside the MDD tools. For the work discussed

in this paper, the focus for MDD tools is on the us-

age of UML tools. Some of them, such as Rhap-

sody (IBM, 2014b), natively support the creation of

requirements in their models. In such tools it is ob-

vious to use them to represent requirements from RM

tools. However, the UML standard itself does not de-

ﬁne elements for requirements. Therefore, not every

UML tool has them, but the UML can be extended

by using proﬁles. The Systems Modeling Language

(SysML) (Object Managemeng Group (OMG), 2012)

is a proﬁle for the UML, which also contains support

for requirements. Thus, it is possible to apply a pro-

ﬁle, such as the SysML, to a UML model to enable it

to work with requirements.

There are different possibilities for interfacing

with a UML tool. Most of them allow the ex-

port/import model elements from a XMI format,

which contains a standardized UML model. There-

fore, it seems like a suitable way to create a ReqIF to

(standardized) UML interface. Thereby, the represen-

tations of requirements would be created inside the

standardized UML format and then transferred to dif-

ferent UML tools. Unfortunately, as stated in (Noyer

et al., 2014), there are differences in how UML tools

use the standardized UML format for export/import.

It would have to be structured differently for differ-

ent tools. Furthermore, the usage of UML proﬁles for

creating requirements would be needed, since UML

does not support requirements natively. Then, when

transferring the requirements to a concrete UML tool,

they may not be mapped to their proprietary require-

ment elements, as they exist for some tools such as

Rhapsody.

Most UML tools also allow to access their models

by using Application Programming Interfaces (API).

They can directly be used for implementing ReqIF in-

terfaces to different UML tools. The disadvantage

is that this leads to proprietary solutions for every

UML tool. On the other hand, there is the advantage

that proprietary requirements elements from different

UML tools can be considered. In order to realize this

by using the standardized UML format, the tool spe-

ciﬁc behavior has to be considered anyway.

4 INITIAL EXPERIMENTAL

EVALUATION

A prototype of the proposed mechanism for directly

interfacing between ReqIF ﬁles and the UML tools

IBM Rational Rhapsody and Enterprise Architect,

which enables the usage of the workﬂow (as shown

in Fig. 2) has been implemented. The direct integra-

tion with these tools was made to be able to use their

proprietary model elements for requirements.

The ReqIF ﬁle is parsed by using the Require-

ments Modeling Framework (RMF) (Eclipse Founda-

tion, 2014) and the elements in the UML tools are

created/analyzed by using their Java APIs. This al-

lows to make a traceability analysis inside a RM tool

and an impact analysis inside the UML tools. The

prototype has been evaluated by exporting require-

ments from a RM tool, Polarion (Polarion Software,

2014) via ReqIF and transferring representations of

them to Rhapsody and Enterprise Architect. In future

TraceabilityandInterfacingBetweenRequirementsEngineeringandUMLDomainsusingtheStandardizedReqIFFormat

373

work, an integration with the standardized UML XMI

format is planned to support a wide variety of UML

tools. Thereby, the SysML proﬁle is applied for cre-

ating requirements in UML.

Figure 3: Mapping from requirements in Polarion and Re-

qIF to their representations in Rhapsody.

Figure 3 visualizes an extract of how requirements

are exported from Polarion into a ReqIF ﬁle and how

the prototype creates representations for them in the

UML tool Rhapsody. For each document with re-

quirements (in Polarion they are called Work Items),

a package is created inside Rhapsody. In these pack-

ages, there is a representation for every requirement

of the corresponding document. Since Rhapsody does

provide model elements for requirements, these are

used. The requirements are structured hierarchically,

just as they are structured in Polarion and ReqIF (Fig.

5). Requirements do further have types (e.g. func-

tional requirement) with attribute deﬁnitions, such as

author or creation time. In the UML domain, these are

mapped to Stereotypes with Tags. Therefore, every

requirement representation in Rhapsody has a stereo-

type assigned and its attribute values (e.g. creation

time) are stored inside tagged values. In Rhapsody,

these representations of requirements can be linked

with other UML model elements by using UML De-

pendencies (Fig. 4).

Figure 4: A class inside Rhapsody, which is linked to a rep-

resentation of a requirement from Polarion.

When the requirements are changed during devel-

opment and updated requirements are re-transfered

to Rhapsody, the prototype compares the already ex-

isting requirements representations with the updated

requirements. In most cases, it should be enough

to compare the attribute lastChanged, which ev-

ery SpecObject (requirement) has inside ReqIF ﬁles.

However, to ensure a correct comparison, the proto-

type also allows to compare all attributes. If the pro-

totype identiﬁes a changed requirement, it assigns a

stereotype Changed to it (Fig 5)). Further, if there is

a representation of a requirement, the corresponding

document is inside the updated ReqIF ﬁle and there

the requirement does not exist anymore, a stereotype

Deleted is assigned to the requirement representation

in Rhapsody. Since manually searching for elements

is a tedious task, Rhapsody allows to search for model

elements by deﬁning search queries. Hence, a com-

plete impact analysis can be made inside Rhapsody.

Figure 5: Changed requirements in Rhapsody.

Further, an algorithm was implemented for

searching the model elements inside Rhapsody and

Enterprise Architect, which are linked to require-

ments with UML Dependencies, and to create repre-

sentations for them inside the ReqIF ﬁle. Therefore,

at ﬁrst a Speciﬁcation (document) and a SpecObject-

Type (compare Fig. 3) are created inside the ReqIF

ﬁle. Afterwards, SpecObjects are created for each

linked UML model element inside the Speciﬁcation

and the SpecObjectType is set. Further, attributes are

created for storing information for the model from the

UML tool like its type (e.g. UML Class), description,

identiﬁer and path inside the package structure. Ad-

ditionally, a link to the requirement inside the ReqIF

ﬁle is created accordingly to the Dependency inside

the UML tool. The ReqIF ﬁle can be re-imported into

the used RM tool now.

Figure 6: UML elements in Polarion

Figure 6 shows how representations of a UML

Package and a UML Class are visualized in a docu-

ment of the RM tool Polarion. The complete trace-

ability information is inside the RM tool and can be

used for different kinds of analyses, for which modern

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

374

day RM tools already provide powerful mechanisms.

Furthermore, the information can be considered dur-

ing document generation from RM tools, as it may be

needed for certiﬁcation projects. The prototype im-

plementation is currently evaluated in a certiﬁcation

project for this purpose. Please note that additional

implementation details of this prototype are available

at (Willert Software Tools, 2014).

5 CONCLUSION AND FUTURE

WORK

The paper discusses an approach for using the stan-

dardized ReqIF format to integrate the UML domain

and the RM domain. A prototype implementation of

this approach interfaces between ReqIF and the UML

tools Rhapsody (IBM, 2014b) and Enterprise Archi-

tect (Sparx Systems, 2014) by using their Java APIs.

This allows a requirements engineer to make a trace-

ability and coverage analysis directly inside his RM

tool and a software developer to make an impact anal-

ysis inside his UML tool. In order to increase the ac-

ceptance rate of the approach, both can work in the

tools they are used to, and they do not have switch to

another tool just because of traceability.

Some future directions are: to support the stan-

dardized UML XMI format, to support the open-

source UML tool Papyrus (Eclipse Foundation,

2013a), to roundtrip UML diagrams to RM tools,

to support Dependencies in UML tools with custom

Stereotypes, to enable automatically invoking the in-

terfacing between ReqIF and UML tools (e.g. on

a build server), the realization of a OSLC interface,

and to investigate how the approach can be adapted

to other non-UML MDD tools (e.g. Matlab/Simulink

(Mathworks, 2014)).

REFERENCES

Eclipse Foundation (2013a). Papyrus UML Product web-

site. http://www.eclipse.org/papyrus/.

Eclipse Foundation (2013b). UML2 Project website. http://

www.eclipse.org/modeling/mdt/?project=uml2.

Eclipse Foundation (2014). Requirements Management for

Eclipse - Requirements Modeling Framework (RMF).

http://www.eclipse.org/rmf/.

Ejaz Ul Haq (2013). Tool integration using OSLC. Master

Thesis, Mlardalen University, Vsteras, Sweden, http://

www.idt.mdh.se/utbildning/exjobb/ﬁles/ TR1420.pdf.

France, R. B., Ghosh, S., Dinh-Trong, T., and Solberg, A.

(2006). Model-driven development using UML 2.0:

promises and pitfalls. Computer, 39:59 – 66.

Graf, A. and Jastram, M. (2011). Requirements, Traceabil-

ity and DSLs in Eclipse with the Requirements In-

terchange Format (RIF/ReqIF). http://deploy-eprints.

ecs.soton.ac.uk/307/1/mbees2011.pdf.

Hersteller Initiative Software (HIS) (2014). HIS Website.

http://www.automotive-his.de.

IBM (2010). Rational Rhapsody Gateway Add On User

Manual. http://pic.dhe.ibm.com/infocenter/rhaphlp/

v7r5/topic/com.ibm.rhapsody.oem.pdf.doc/pdf/

manual.pdf.

IBM (2014a). Rational DOORS Website. http://

www-03.ibm.com/software/products/en/ratidoor.

IBM (2014b). Rational Rhapsody Family Website. http://

www-03.ibm.com/software/products/en/ratirhapfami.

itemis AG (2014). Yakindu Traceability - Trace Man-

agement and Reporting (Product Website). http://

www.yakindu.com/traceability/.

Mathworks (2014). Matlab/Simulink Website. http://

www.mathworks.co.uk/products/simulink/index.html.

Noyer, A., Iyenghar, P., Pulvermueller, E., Pramme, F.,

Engelhardt, J., Samson, B., and Bikker, G. (2014).

Tool Independent Code Generation for the UML -

Closing the Gap between Proprietary Models and the

Standardized UML Model. In Evalutation to Novel

Approaches of Software Engineering (ENASE 2014),

Lisbon, Portugal.

Object Managemeng Group (OMG) (2012). SysML Speci-

ﬁcation 1.3. http:// www.omgsysml.org/.

Object Managemeng Group (OMG) (2014). OMG Website.

http://www.omg.org.

Object Management Group (2013a). Require-

ments Interchange Format Speciﬁcation 1.1.

http://www.omg.org/spec/ReqIF.

Object Management Group (2013b). Uniﬁed Modeling

Language Speciﬁcation. http://www.uml.org/.

Open Services for Lifecycle Collaboration (OSLC) (2014).

OSLC Website. http://open-services.net/.

Polarion Software (2014). Polarion alm. https://

www.polarion.com/products/alm/index.php.

Sparx Systems (2014). Enterprise Architect. http://

www.sparxsystems.de/.

Walderhaug, S., Stav, E., Johansenand, U., and Olsen, G. K.

(2008). Traceability in model-driven software devel-

opment. In: Tiako, P.F. (ed.) Designing Software-

Intesnvie Systems: Methods and Principles, pages

133–159.

Willert Software Tools (2014). ReqXChanger DataSheet.

http://www.willert.de/assets/Datenblaetter/DatBl-

ReqXChanger-V-2.0en-2014.pdf.

Winkler, S. and von Pilgrim, J. (2010). A survey of

traceability in requirements engineering and model-

driven development. Software & Systems Modeling,

9(4):529–565.

TraceabilityandInterfacingBetweenRequirementsEngineeringandUMLDomainsusingtheStandardizedReqIFFormat

375