Backward Requirements Traceability within the

Topology-based Model Driven Software Development

Erika Asnina, Bernards Gulbis, Janis Osis, Gundars Alksnis,

Uldis Donins and Armands Slihte

Department of Applied Computer Science, Institute of Applied Computer Systems

Riga Technical University, Meza iela 1-k.3, LV-1048, Riga, Latvia

Abstract. The inconsistence between software and specifications leads to

unpredictable side effects after change implementation. Impact analysis may be

useful here, but manual control of trace links is very expensive. Model Driven

Architecture and automated transformations should make the impact analysis

easier. The issue is that the impact analysis of changes in software to real world

functional units is intuitive. Formalization of specifications of the environment

and software functionality as well as their analysis by means of Topological

Functioning Model extends possibilities of the impact analysis. This paper

demonstrates the establishment of formal trace links to real world functional

units and entities from user requirements and analysis artifacts. These links

show element interdependence explicitly, and, hence, make the impact analysis

more thorough.

1 Introduction

A software system is a subject to non-stop changes; otherwise it becomes less and less

useful for its initial purpose (as cited in Yang & Ward, 2002). Frequent change

implementations lead to breaking structure of the software system and appearance of

unpredictable side effects. Impact analysis is devoted to assess side effects and

estimate change implementation costs.

This paper discusses application of functional and topological properties of

Topological Functioning Model (TFM) for impact analysis within Object

Management Group’s (OMG) Model Driven Architecture (MDA). This research

continues research presented in [8], [12], [11], [2] and [3].

The paper is organized as follows. Section 2 briefly discusses the impact of

changes on MDA models. The related work also is discussed here. Section 3 describes

and illustrates how the suggested formalization can be applied for the impact analysis.

Section 4 demonstrates the proposed idea by the example of a library system.

Conclusion discusses results and future research directions.

Asnina E., Gulbis B., Osis J., Alksnis G., Donins U. and Slihte A..

Backward Requirements Traceability within the Topology-based Model Driven Software Development.

DOI: 10.5220/0003578500360045

In Proceedings of the 3rd International Workshop on Model-Driven Architecture and Modeling-Driven Software Development (MDA & MDSD-2011),

pages 36-45

ISBN: 978-989-8425-59-1

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

2 Traceability, Changes and Model Driven Architecture

As [5] wrote “requirements traceability is an ability to follow the life of a

requirement”. They distinguished pre-RS (backward) and post-RS (forward)

traceability. Pre-RS traceability refers to requirement’s life prior to its inclusion in the

requirements specification. Post-RS traceability refers to requirements life from the

moment of its inclusion in the requirements specification.

One of the main issues in traceability practice is the high cost of manual control of

traceability information [1]. In case of correct and entire implementation of the idea

and principles of MDA, impact analysis and traceability could be automated and

describe the state of the software system completely and clearly in always up-to-date

documentation – software system models.

MDA includes a computation independent model (CIM), a platform-independent

model (PIM) and a platform-specific model (PSM). They model systems at different

levels of abstraction. Besides them, additional models may also be used, e.g. a

transformation model, a traceability model, a platform model, a database

model/scheme, and so on. In case of automated transformations, the traceability

model with explicit trace links can be created and maintained automatically.

Let us consider the categories of changes - corrective, adaptive, perfective and

preventive [14]- in the framework of MDA (Fig. 1). Here, we have limited models

with the CIM, PIM, PSM, code and transformations. Adaptive and perfective changes

should be first verified and implemented in the CIM, and only then propagated to PIM

to PSM to code. Preventive changes affect software design already specified in the

PIM; therefore, they must be verified on compliance with the CIM and propagated

from [CIM to] PIM to PSM to code. In turn, corrective changes can affect every

MDA model.

Fig. 1. Categories of changes and their impact on MDA models.

In general, if incompliance is located in the requirements specification,

modifications start from the CIM and are propagated to code through PIMs and

PSMs. Post-RS traceability information is kept together with transformations (that are

to be automated starting from the PIM level) and helps in change requests verification

and change cost estimation. However, it does not help in identifying the origin (and

production) of requirements.

The current literature contains ample publications describing support of post-RS

traceability, rather manually defined than defined by using heuristic traceability rules

in the stage from requirements (CIM) to analysis models (PIM). However, most

approaches lack support of pre-RS traceability (within CIM). Problems confronting

pre-RS traceability are enumerated in detail in [5].

Pre-RS traceability includes a documented history of eliciting the final

requirements from a pre-requirements set [6], as well as a stakeholder aspect, which is

oriented on dependencies between high-level stakeholders (as well as organizations,

system missions, standards) as a starting point for driving and documenting

requirements process [13]. However, MDA either considers the CIM only as informal

(textual) requirements model without its relating to business and knowledge models

(thus, the high-level stakeholder aspect is often skipped), or uses traditional

requirements engineering models/languages.

A very ambient overview on recent publications about requirements generation

from software engineering models (and thus possibility to trace their origin) is

performed by [7]. Software models used are KAOS, i*, and temporal logic goal-

oriented models, RAD business models, eEPC business models as well as use cases

and scenarios, UML models and user interface. Models are ordered by the decreasing

number of applications. As the authors concluded, the better way is to use natural and

formal languages together. High-level business process models in BPMN notations

and their transformations also can be used [4].

Summarizing, such issues as a lack of conformity to complex human institutions

and systems and misunderstanding of the system’s purpose between developers and

users of the software system requires the pre-RS traceability. There must be up-to-

date formal models that contain knowledge about the “real world” domain at the

computation independent level in MDA. Moreover, system requirements must be

traceable, i.e., in strong conformity with these formal models. This allows at least

predicting, and at most avoiding, side effects of change implementations.

3 Changes and Requirements Traceability within Topology-based

MDA Lifecycle

The Topological Functioning Model, TFM, is a formal mathematical specification of

domain functioning. Its mathematical foundations, topological and functioning

properties, are described in detail in [10]. The TFM introduces modification in the

beginning of MDA development life-cycle [8]– in the CIM. It captures business

knowledge about the problem domain, i.e. business functional characteristics and

cause-effect relations among them, organizational units/roles and their responsibility

for providing and using those functional characteristics, and domain objects and their

participation in business functioning [10]. The TFM is a ground for checking

compliance of users’ and software functional requirements to the problem domain [9].

Fig. 2 illustrates the formalized part of MDA software development lifecycle, the

CIM, by means of the TFMs of the business system and information system.

The TFM of the business system (BS) formally specifies functionality of the

human institution or system. In turn, the TFM of the information system (IS) formally

specifies functionality of the computer system within that BS. Models of BS and IS

are continuously mapped, i.e., they are formally interrelated, and all changes must be

specified in both models. Transformation and traceability between these models is

formal and based on continuous mapping of graphs [2].

Fig. 2 points to the fact that construction of the TFM is a manual activity that

transforms informal verbal descriptions to the formal mathematical specification. The

construction of the TFM is described at large in [10]. However, first positive results

of the on-going research on automation of this activity by using a natural language

processing system are demonstrated in [12].

Fig. 2. Changes and requirements traceability at the beginning of topology-based MDA

software development lifecycle.

Initially, models of BS and IS are equal. Verification of user requirements

(desires) based on formal mappings from them to this initial TFM of IS results in

checking and correcting requirements as well as refining and modifying the TFM of

IS, while keeping its formal consistency with the TFM of BS. Then formal derivation

of software functional requirements as well as entities (classes) in domain vocabulary

becomes possible.

Another manual activity demonstrated in Fig. 2 is the transformation from CIM to

PIM, i.e., from domain vocabulary and system requirements to analysis models of the

system. The initial results of the on-going research on formalization of this activity by

means of the TFM are illustrated in [11]. Even these first results show that formal

tracing from the TFM of IS, domain vocabulary and software functional requirements

to the analysis model is possible.

Fig. 3. Pre-RS traceability framework in general.

A general Pre-RS traceability framework is illustrated in Fig. 3. Classes at the

conceptual level, actors and use cases (as software functional requirements),

functional requirements and system goals set by users (users’ desires) are traced to

TFM functional features, traceability between which at different levels of abstraction

is also provided. Hence, it is possible to determine why a class or a requirement is

included in the software solution, and how it is linked with other structural or

behavioral elements by using the formal ground – formally related topological models

of business and information system functionality.

4 Pre-RS Traceability in Case of the Perfective Change Request

For illustration of advantages of the introduced formalism, let’s take a little bit

simplified example that describes an information system of the library “Library IS”.

4.1 The CIM – Business Model

The TFM of BS (The Library)

is presented in Fig. 4a. Description of functional

features (FFs) is given in the form “identifier: feature_description, precondition,

responsible_entity (where, “Lib” denotes “librarian”, and “R” denotes “reader”)” and

they are as follows: 1: Arriving [of] a person, {}, person; 2: Creating a reader

account, {unregistered person}, Lib; 3: Creating a reader card, {}, Lib; 4: Giving out

the card to a reader, {}, Lib; 5: Indentifying a reader, {}, Lib; 6: Completing the

request for a book, {}, R; 7: Registering the request for a book, {}, Lib; 8: Taking out

the book copy from a book fund, {a book copy is available}, Lib; 9: Checking out the

book copy for a reader, {}, Lib; 10: Giving out the book copy to a reader, {}, Lib; 11:

Getting a book copy, {}, R; 12: Returning a book copy, {}, R; 13: Taking back the

book copy from a reader, {}, Lib; 14: Checking the term_of_loan of a book copy, {},

Lib; 15: Evaluating the condition of a book copy, {}, Lib; 16: Imposing a fine, {the

term_of_loan is exceeded or the condition is damaged}, Lib; 17: Returning the book

copy to a book fund, {}, Lib; 18: Paying a fine, {imposed fine}, R; 19: Closing a fine,

{paid fine}, Lib; 20: Completing a statement_of_destruction, {hardly damaged book

copy}, Lib; 21: Sending the book copy to a destructor, {}, Lib; 22: Destructing a

book copy, {}, Destructor.

User Requirements (Functional)

are dedicated to receiving an IS that supports

servicing readers. They are the following - FR1: The system shall register a new

reader; FR2: The system shall check out a book copy; FR3: The system shall handle

return of a book copy; FR4: The system shall account reader’s fines.

Tracing: The requirements map onto FFs of the TFM of BS as follows (Fig. 4b): FR1

to {2, 3, 4}, FR2 to {5, 7, 8, 9}, FR3 to {5, 13, 14, 15, 17}, and FR4 to {16, 19}.

The TFM of IS

is illustrated in Fig. 5a. After formal identification of the IS, a

subsystem of the BS, it excludes only two functional features - 21 and 22.

System Goals to is Set by Users

are needed for TFM decomposition into use cases.

The goals are stated as follows: SG1 “Register a reader”, SG2 “Check out a book”,

SG3 “Return a book”, SG4 “Pay a fine”, SG5 “Impose a fine”, and SG6 “Close a

fine”. All system goals are set by the librarian.

Fig. 4. The TFM of Business System (a) and mappings from user requirements to it (b).

Fig. 5. The TFM of Information System (a) and mappings from system goals to it (b).

Tracing: The mappings from the TFM of IS to corresponding FFs of the TFM of BS

are one-to-one. The mappings from system goals to the TFM of IS are illustrated in

Fig. 5b. Thus, SG1 “Register a reader” can be achieved by execution of functional

features 2, 3, and 4; in turn, SG2 “Check out a book” – by 5, 6, 7, 8, 9 and 10, SG3

“Return a book” by 5, 13, 14, 15, 16, and 17, SG4 “Pay a fine” by 5, 18 and 19, SG5

“Impose a fine” by 16, and SG6 “Close a fine” by 19.

SG1 corresponds to FR1, SG2 to FR2, and SG3 to FR3. In turn, SG4, SG5 and SG6

together correspond to FR4. However, functionality specified by FFs 6, 10, and 18

belongs to the IS as such, but it is excluded from the software system, i.e., it will

remain manual. Besides that, functional features 1 and 12 indicate on the input data

from the BS to the IS; and features 11 and 20 indicate on the output data that the IS

provides for other activities of the BS and its external environment.

4.2 The CIM – Business Requirements for the System

Domain Vocabulary and System Requirements

, a conceptual class diagram and a use

case model, are represented in Fig. 6a. The classes are driven from the TFM of IS.

They are ReaderAccount, ReaderCard, Reader, Request, BookCopy, BookFund, and

Fine. The detailed description of class properties is skipped here.

The diagram and descriptions of use cases are also derived from the TFM of IS by

using system goals as a decomposition criteria and mappings from functional

requirements as criteria for determination of use case flows. The use cases activated

by an actor “Librarian” are “Register reader”, “Identify reader”, “Check out book”,

“Return book” and “Close fine”. “Identify reader” is an inclusion use case.



Fig. 6. The conceptual class diagram and use case diagram (a), and their mappings to functional

features of the TFM of IS (b).

Tracing: Mappings from the classes and use cases to the TFM of IS are illustrated in

Fig. 6b. As we can infer, “Register reader” operates with classes ReaderAccount,

ReaderCard, and Reader. “Indentify reader” operates with Reader. “Check out

book” operates with RequestForBook, BookCopy, and BookFund. “Return book”

operates with BookCopy, BookFund, and Fine. Both “Impose fine” and “Close fine”

operate with Fine. Thus, possible changes of classes Reader, BookCopy, BookFund

and Fine may have impact on several interrelated functional units. Main and

alternative flows of use cases should also be defined in strong compliance with the

functional features. We omit system sequence diagrams here due to page limitation.

4.3 Illustration of Traceability Links in Case the Change Request Occurred

Let us consider the case of a perfective change request, i.e., changes in user

requirements. Let us assume that requirement “FR2: The system shall check out a

book copy” is extended to “FR2: The system shall allow a reader to complete and

by the registered request by both reader and librarian. The system shall inform a

reader about the status of the registered request via e-mail.”

The trace links among elements before a modification are the following: FR2 is

linked with FFs 5, 7, 8, and 9 (Fig. 4b), which are linked with the system goal SG2

(Fig. 5b). Considering these FFs within the TFM of IS (Fig. 5a) shows that

functionality touched by the modification (see Fig. 7a) depends on FFs 2 and 3 (new

reader registration), 6 (completing the request for a book) and 17 (taking the

requested book copy from the book fund). Besides that, it affects FFs 10 (giving out

the book copy to a reader), 13 (taking back the book copy from a reader) and 18

(paying the fine). This means that the requested change may generate side effects in

these functional parts which origin from different user requirements and belong to

different system goals (Fig. 7b) and use cases – “Identify reader” and “Check out

book” (Fig. 6b). Hence, cause-effect relations between these functional features and

modified/new functionality must be carefully verified.

Fig. 7. Trace links between elements after change verification.

The TFM shows that completing of a book request is manual. First, the librarian

identifies a reader. Then the reader is allowed to complete the request manually, and

only after that the librarian registers the request. Thus, one part of the new FR2 is

already specified by feature 6. However, the new execution order adds a new path: the

reader provides his login data; if the reader is identified by the system, he is able to

complete an electronic request form and register it in the system. Hence, features 5

and 7 must be modified; the new cause-effect relation from feature 5 to 6 must be

established (Fig. 7c). The next point is that identification of a reader via Internet will

modify also the class Reader (Fig. 6b), e.g., by adding new class properties – login

name and password, and e-mail, as well as functionality of the use case “Register

reader” specified by features 2 and 3.

Another point is that a reader who has registered his/her request via Internet

should be notified about the request status. Hence, new FFs - “23: Updating the status

of the request of a reader, {the request is registered OR the book copy is taken from

the book fund}, System“, “24: Creating an e-mail, {}, System”, and “25: Sending the

e-mail to a reader, {}, System” - and cause-effect relations from features 7 and 8 to

23, from 23 to 24, and from 24 to 25 are established (Fig. 7c). Additionally, the new

class E-mail also is created (Fig. 7e).

Besides that, giving out a book copy should also be modified, since a reader can

came to the library to receive the book already taken from the fund. Checking out the

book copy (feature 9) should also be related to the mentioned Internet functionality.

Hence, a new feature is created – “26: Checking the status of the request of a reader,

{}, Librarian” that generates feature 9 only if the book copy has been taken from the

fund. A new alternative path in the TFM of IS is “5-26-9” (Fig. 7c).

Modifications of the TFM of IS must be propagated to the lower artifacts. Using

use cases requires verification of the system goals. The reader states a new goal SG7

“Complete the request via Internet” that includes features 5, 6 and 7. SG2 is extended

and includes also features 23, 24, 25 and 26 (Fig. 7d). This modifies conceptual class

and use case diagrams as shown in Fig. 7e. A new use case “Complete request” is

specified. It extends “Check out book” and includes “Identify reader”.

Summarizing, the change in FR2 requires modifications in FR1 and FR3 that will

cause creation of class E-mail and use case “Complete request”, modification of

classes ReaderAccount, ReaderCard, Reader, Request and use cases “Register

reader”, “Check out book” and “Identify reader”. Use cases “Return book” and

“Close fine” may require re-testing.

5 Conclusions

MDA gives new breath to post-RS traceability support. However, automated support

of pre-RS traceability requires formalization of requirements, business, knowledge

models and relations among them. The TFM as a formal CIM-Business Model gives

an opportunity to establish and use trace links between elements of development

artifacts for pre-RS traceability needs. This results in feasibility to trace system

requirements to and verify them with business functionality and original user

requirements, check necessity of modification of logically related parts, and propagate

established modifications in business models to system requirements and classes.

Direction of our on-going and further research is formalization of transformations

between CIM models and from CIM to PIM by means of topological functioning

modeling and “lightweight” mathematics.

References

1. Aizenbud-Reshef, N., Nolan, B. T., Rubin, J., & Shaham-Gafni, Y. (2006). Model

traceability. IBM SYSTEMS JOURNAL , 45 (3), pp. 515-526.

2. Asnina, E., & Osis, J. (2010). Computation independent models: bridging problem and

solution domains. Proceedings of the 2nd InternationalWorkshop on Model-Driven

Architecture and Modeling Theory-Driven Development MDA & MTDD 2010, In

conjunction with ENASE 2010, Athens, Greece, July 2010 (pp. 23-32). Portugal:

SciTePress.

3. Asnina, E., & Osis, J. (2011). Topological Functioning Model as a CIM-Business Model. In

J. Osis, & E. Asnina, Model-Driven Domain Analysis and Software Development:

Architectures and Functions (pp. 40-64). Hershey, New York, USA: IGI Global.

4. De Castro, V., Marcos, E., & Vara, J. M. (2011). Applying CIM-to-PIM model trnsforma-

tions for the service-oriented development of information systems. Information and

Software Technology , 53, 87-105.

5. Gotel, O. C., & Finkelstein, A. C. (1994). An Analysis of the Requirements Traceability

Problem. Proceedings of the First International Conference on Requirements Engineering,

1994 (pp. 94 - 101). Colorado Springs, CO , USA: IEEE.

6. Grammel, B., & Kastenholz, S. (2010). A Generic Traceability Framework for Facet-based

Traceability Data Extraction in Model-driven Software Development. Proceedings of the

6th ECMFA Traceability Workshop (ECMFA-TW), June 15th 2010, Paris, France (pp. 7-

14). ACM Press.

7. Nicolás, J., & Toval, A. (2009). On the generation of requirements specifications from

software engineering models: A systematic literature review. Information and Software

Technology , 51, 1291–1307.

8. Osis, J. (2006). Formal Computation Independent Model within the MDA Life Cycle. (P.

Loucopoulos, & K. Lyytinen, Eds.) International transactions on system science and

applications , 1 (2), pp. 159-166.

9. Osis, J., & Asnina, E. (2008). A Business Model to Make Software Development Less

Intuitive. Proceedings of 2008 International Conference on Innovation in Sofware

Engineering (ISE 2008). December 10-12, 2008, Vienna, Austria (pp. 1240-1245). IEEE

Computer Society Publishing.

10. Osis, J., & Asnina, E. (2011). Topological Modeling for Model-Driven Domain Analysis

and Software Development. In J. Osis, & E. Asnina, Model-Driven Domain Analysis and

Software Development: Architectures and Functions (pp. 15-39). Hershey, New York,

USA: IGI Global.

11. Osis, J., & Donins, U. (2010). Formalization of the UML Class Diagrams. In Evaluation of

Novel Approaches to Software Engineering (pp. 180-192). Berlin: Springer-Verlag.

12. Osis, J., & Slihte, A. (2010). Transforming Textual Use Cases to a Computation

Independent Model. Proceedings of the 2nd InternationalWorkshop on Model-Driven

Architecture and Modeling Theory-Driven Development MDA & MTDD 2010, In

conjunction with ENASE 2010, Athens, Greece, July 2010 (pp. 33-42). Portugal:

SciTePress.

13. Sahraoui, A.-E.-K. (2005). Requirements traceability issues: generic model, methodology

and formal basis. International Journal of Information Technology & Decision Making , 4

(1), 59-80.

14. Yang, H., & Ward, M. (2002). Successful Evolution of Software Systems. Boston, London:

Artech House, Incorporated.