documenting requirements traceability information: a - soberit

HELSINKI UNIVERSITY OF TECHNOLOGY

Department of Computer Science and Engineering

Virve Leino

Documenting Requirements Traceability Information: A Case Study

Master's thesis

Supervisor:

Professor Reijo Sulonen

Instructor:

M.Sc. Marjo Kauppinen

ii

HELSINKI UNIVERSITY OF ABSTRACT OF THE TECHNOLOGY MASTER'S THESIS

Author: Virve Leino

Title: Documenting Requirements Traceability Information: A Case Study

Date: 12.4.2001 Number of pages: 54

Department: Department of Computer Science and Engineering

Professorship: Tik-76

Supervisor: Professor Reijo Sulonen

Instructor: M.Sc. Marjo Kauppinen, Helsinki University of Technology

The literature lists many benefits of requirements traceability and standards suggest that it should be practiced. However, available literature concentrates on industries developing complex and large systems with several thousands of requirements. Thus, the companies developing systems with only approximately a hundred requirements face the challenge to define what traceability information to document and how. The goals of this thesis were to introduce requirements traceability and to offer guidelines for documenting traceability information for these companies. The thesis is part of the QURE (Quality Through Requirement) project at Helsinki University of Technology.

The thesis begins with an introduction of traceability classes, relations and benefits of documenting them. It also presents techniques and tools to document traceability information. The theory part ends with discussion of the costs and problems of practicing requirements traceability.

The case study part of the thesis consists of an analysis of requirements traceability and good practices developed for documenting traceability information in a case company. In addition, improvement actions that were taken by the company are presented.

The thesis ends with a discussion of the theoretical implications of the work, the most important of which is the observation that pre-traceability is the first that the target group companies could document and benefit from whereas there can be many problems in documenting post-traceability information.

iii

TEKNILLINEN DIPLOMITYÖN KORKEAKOULU TIIVISTELMÄ

Tekijä: Virve Leino

Työn nimi: Vaatimusten jäljiettävyystiedon dokumentointi: Case-tutkimus

Päivämäärä: 12.4.2001 Sivumäärä: 54

Osasto: Tietotekniikan osasto

Professuuri: Tik-76

Työn valvoja: Professori Reijo Sulonen

Työn ohjaaja: DI Marjo Kauppinen, Teknillinen korkeakoulu

Vaatimusten jäljitettävyydellä on kirjallisuuden mukaan lukuisia etuja, ja standardit ke-hottavat dokumentoimaan jäljitettävyystietoa. Aiemmissa tutkimuksissa jäljitettävyyttä käsitellään kuitenkin pelkästään niiden alojen näkökulmasta, jotka kehittävät useiden tuhansien vaatimusten kokoisia järjestelmiä, ja siksi pienempiä kehittävät yritykset jou-tuvat itse selvittämään, mitä jäljitettävyystietoa niiden olisi hyödyllistä dokumentoida ja kuinka sen voisi tehdä. Tämän diplomityön tavoitteena oli esitellä vaatimusten jäl-jitettävyys ja tarjota ohjeita jäljitettävyystiedon dokumentointiin yrityksissä, jotka kehit-tävät noin sadan vaatimuksen kokoisia järjestelmiä. Työ on tehty Teknillisessä korkea-koulussa osana QURE (Quality Through Requirement) projektia.

Työ alkaa jäljitettävyysluokkien, -relaatioiden ja jäljitettävyyden etujen esittelyllä. Tä-män jälkeen käydään läpi tekniikat ja työkalut, joiden avulla tietoa voidaan dokumen-toida. Teoriaosuuden loppussa pohditaan vaatimusten jäljitettävyyden kuluja ja mahdol-lisesti kohdattavia ongelmia.

Case-tutkimus koostuu yhden yrityksen jäljitettävyystiedon tarpeen kartoittamisesta ja tiedon dokumentoimiseen kehitettyjen käytäntöjen esittelystä. Myös yrityksen jäljitet-tävyystiedon dokumentointiin liittyviä kehitystoimenpiteitä käsitellään.

Diplomityö päättyy pohdintaan työn teoreettisista tuloksista. Työn tärkein havainto on, että esijäljitettävyys näyttää olevan tärkein jäljitettävyystieto, josta tämän työn kohde-ryhmänä olevat yritykset hyötyvät, mutta jälkijäljitettävyyden dokumentoimiselle on monia esteitä.

iv

TABLE OF CONTENTS

ABBREVIATIONS

TERMINOLOGY

PREFACE

1. INTRODUCTION ........................................................................................................1

1.1 REQUIREMENTS ENGINEERING AND TRACEABILITY....................................................1 1.2 BENEFITS OF REQUIREMENTS TRACEABILITY .............................................................2 1.3 CHALLENGES IN DOCUMENTING TRACEABILITY INFORMATION .................................3 1.4 BACKGROUND, GOALS AND STRUCTURE OF THE THESIS ............................................4

2. TRACEABILITY INFORMATION ..........................................................................6

2.1 TRACEABILITY CLASSES.............................................................................................6 2.1.1 Pre- and Post-Traceability ................................................................................6 2.1.2 Forward and Backward Traceability ................................................................7

2.2 TRACEABILITY RELATIONS.........................................................................................8 2.2.1 Requirement-Source Traceability......................................................................9 2.2.2 Requirement-Rationale Traceability .................................................................9 2.2.3 Requirement-People Traceability....................................................................10 2.2.4 Requirement-Requirement Traceability...........................................................10 2.2.5 Requirement-Component Traceability.............................................................12 2.2.6 Requirement-Verification Traceability ............................................................13

3. TECHNIQUES AND TOOLS...................................................................................14

3.1 IDENTIFIER TECHNIQUE ............................................................................................14 3.2 ATTRIBUTE TECHNIQUE............................................................................................16 3.3 LIST TECHNIQUE.......................................................................................................18 3.4 TABLE TECHNIQUE ...................................................................................................18 3.5 GENERAL-PURPOSE TOOLS .......................................................................................19 3.6 REQUIREMENTS MANAGEMENT TOOLS ....................................................................20

4. DEVELOPING TRACEABILITY PRACTICES ...................................................23

4.1 FACTORS AFFECTING THE NEED FOR TRACEABILITY................................................23

v

4.2 COSTS.......................................................................................................................25 4.3 PROBLEMS ................................................................................................................25 4.4 TASKS TO DEVELOP AND IMPLEMENT TRACEABILITY PRACTICES ............................26

5. CASE STUDY: DOCUMENTING TRACEABILITY ...........................................29

5.1 ANALYZING COMPANY'S NEED FOR REQUIREMENTS TRACEABILITY .......................29 5.2 PROJECTS AND INTERVIEWEES FOR ASSESSMENT.....................................................30 5.3 ASSESSMENT RESULTS .............................................................................................30

5.3.1 Requirement-Source/People Traceability........................................................31 5.3.2 Requirement-Rationale Traceability ...............................................................32 5.3.3 Requirement-Requirement Traceability...........................................................34 5.3.4 Requirement-Component Traceability.............................................................35 5.3.5 Requirement-Verification Traceability ............................................................37

5.4 SUMMARY OF RESULTS.............................................................................................39 5.4.1 Need for Traceability Information...................................................................39 5.4.2 Techniques and Tools to Document Traceability Information ........................40 5.4.3 Reasons for Documenting Traceability Information........................................41

5.5 GOOD PRACTICES TO DOCUMENT TRACEABILITY INFORMATION .............................43 5.5.1 Requirement-Source/People Traceability........................................................43 5.5.2 Requirement-Rationale Traceability ...............................................................44 5.5.3 Requirement-Component Traceability.............................................................45 5.5.4 Requirement-Verification Traceability ............................................................46

5.6 IMPROVEMENT ACTIONS TAKEN...............................................................................46

6. CONCLUSIONS.........................................................................................................48

7. REFERENCES ...........................................................................................................51

APPENDIX 1: INTERVIEW OF PRACTITIONERS

vi

ABBREVIATIONS

CMM Capability Maturity Model

DoD Department of Defense

IEEE Institute of Electrical and Electronics Engineering

QURE Quality Through Requirements (the project this thesis was written in)

RE Requirement Engineering

RM Requirements Management

RS Requirements Specification

RT Requirements Traceability

SEI Software Engineering Institute

vii

TERMINOLOGY

Backward traceability

Traceability belongs to the backward traceability class if system process artifacts can be traced to the requirement or if the requirement can be traced to its origins [5, 14, 17].

Forward traceability

Traceability belongs to the forward traceability class if either the origin can be traced to the requirement or the requirement to those system process artifacts that have been affected by it [5, 14, 17].

Small systems Used in this thesis to refer to systems with approximately a hundred requirements.

General-purpose tools

General-purpose tools can be used for many purposes. Exam-ples include spreadsheet programs, word processors and hypertext editors.

Post-traceability Traceability class concerned with those aspects of a require-ment’s life that result from its inclusion in the requirements document [10].

Pre-traceability Traceability class concerned with those aspects of a require-ment’s life that are prior to its inclusion in the requirements document [10].

Requirements analysis and negotiation

Analysis and negotiation form the process of establishing an agreed set of requirements and discovering requirements conflicts and missing, ambiguous, overlapping, and unrealis-tic requirements [18].

Requirements definition

Definition is part of the RE -process. It includes requirements elicitation, analysis, negotiation, documentation and valida-tion tasks [5].

Requirements document

A requirements document is an official statement of the sys-tem requirements for customers, users, and developers [18].

viii

Requirements elicitation

Requirements elicitation is the process of discovering the requirements through consultation with stakeholders, from existing documents, domain knowledge, and market studies [18].

Requirements engineering

Requirements engineering is the process of deriving, validat-ing, and maintaining requirements, usually stored in system requirements document [4].

Requirements management (RM)

Management is part of the RE -process. It includes maintain-ing requirements with related information and managing their changes [3].

Requirements management tool (RM-tool)

Requirements management tools are sophisticated tools in-tended to help in requirements engineering activities.

Requirements specification (RS)

See requirements document.

Requirements traceability (RT)

A requirement is traceable if one can discover who suggested the requirement, why the requirement exists, which require-ments are related to it and how it relates to other information such as system designs, implementation, and documentation [5].

Requirements validation

Validation is the process of checking the requirements for omissions, conflicts and ambiguities and for ensuring that the requirements follow quality standards [18].

Stakeholder Systems stakeholders are people affected by the system with a direct or indirect influence on system requirements [18].

System process artifacts

Outputs of system engineering process. Examples include systems designs, components, verification cases and docu-ments.

PREFACE

I was hired by the QURE (Quality Through Requirements) project at Helsinki University of Technology to do my master's thesis about requirements traceability in September 1999. Since then the project has provided me with a possibility to learn about software business and requirement engineering related issues with experienced fellow workers. In addition, the project has granted me a lot of time with little interference from other work to write this thesis.

First of all, I would like to thank the instructor for the thesis, Marjo Kauppinen, who has taken her time to read my writings from the first plan to the final version of this thesis. She has provided me with much-needed feedback, new ideas, and encouragement, when needed. Her expertise has contributed a lot to the quality of the work and to my learning about requirements engineering and scientific writing.

In addition, I would like to thank all parties involved in QURE: the project team, industrial partners, TEKES for funding the project, and Professor Reijo Sulonen, my supervisor, for his valuable comments. Last, I thank my love Markku for improving the written English and my parents for their support throughout my studies.

Helsinki, April 12th, 2001

Virve Leino

1

1. INTRODUCTION

1.1 Requirements Engineering and Traceability

Many companies agree that requirements engineering (RE) is vital to the success of an entire project [1]. It has great economic importance because a change in a requirement during system testing can cost as much as 50 times more than during requirements analysis, according to Pohl [2]. However, RE is frequently wrongly perceived as unproductive work and thus insufficient time and resources are allocated to it [3].

Requirements Engineering (RE)

"Requirements engineering includes a structured set of activities which are followed to derive, validate and maintain requirements, usually stored in system requirements document [4]"

Definition 1. Requirements Engineering.

Requirements engineering consists of two parts: requirements definition and requirements management [5]. Requirements definition includes requirements elicitation, analysis, negotiation, documentation, and validation tasks [5]. It is frequently described as one of the first phases in process models whereas the requirements management spans the whole life cycle of a system [3]. Requirements management consists of maintaining requirements with related information and managing their changes [3].

Requirements definition

System and software design

Implementation and unit testing

Integration and system testing

Operation and maintenance

Requirements management

Figure 1. Requirements definition and management shown as a part of the waterfall model.

2

Requirements tracing is included in the requirements management component of RE. This is because requirements traceability is useful when managing requirements. For example, requirements traceability information can be used for identifying the requirements that must be updated. Requirements traceability is additionally beneficial in other activities that are discussed in the next section.

Requirements Traceability (RT)

“A requirement is traceable if you can discover who suggested the requirement, why the requirement exists, what requirements are related to it and how it relates to other information such as systems designs, implementation and documentation [5]”.

Definition 2. Requirements traceability.

1.2 Benefits of Requirements Traceability

The literature suggests many benefits that derive requirements traceability. Most frequently it is claimed to help in:

• Requirements change management by documenting the links between requirements and other system process artifacts [5, 6, 7, 8]

• Validation and reuse of requirements by documenting the source and reason for requirements existence [6, 8, 9]

• Understanding how and why the system meets the needs of the stakeholders by linking the requirement to design, implementation and verification artifacts [6, 7, 8, 9]

Moreover, Pohl, Ramesh and Gotel state that RT decreases the loss of important information when people leave projects [9, 10], and Ramesh suggests that traceability has been an important concept in improving the system engineering processes [11]. He interviewed managers of a company at the SEI CMM level three who believed that the comprehensive RT an important part of achieving this rating [11]. Dömges and Pohl argue that the increasing use of commercial tracing environments reflects the fact that traceability is seen as a critical success factor [12]. Traceability can also play an important role in interpreting customer requirements, proving that the system does exactly what is wanted and creating subcontracts using RT information as a basis of them [9]. Many standards

3

suggest that RT should be practiced. IEEE (Institute of Electrical and Electronics Engineering) Guide for developing System Requirements Specifications lists traceability as one of the four properties that requirements should have [13] and IEEE Recommended Practice for Software Requirements Specifications recommends that the requirement should be traceable to its origin and facilitate future referencing [14]. U.S. DoD (Department of Defense) standard 2167A insists that a requirement should be traceable to the product baseline [15].

1.3 Challenges in Documenting Traceability Information

Ramesh and Edwards argue that it is general not to document RT information at all [9], and, according to Palmer, its quality and benefits vary even when documented [6] because the challenges for companies to practice RT are numerous. First, the term ‘requirements traceability’ has been unknown among system engineers and there does not exist a common definition for it in the literature [6]. Second, the full capture of all conceivable traces is neither desirable nor feasible when considering project time and cost [12]. Thus the number and type of requirements traces documented must be adapted to company specific needs. Third, there is no convincing evidence of the return of investment in traceability and last, the automated techniques, to assist in practicing RT, are expensive, not tailored to project specific needs, and inefficient in terms of effort spent and are thus not useful [6].

Particularly companies developing systems with approximately only a hundred requirements (henceforth companies developing small systems) face the challenge to define which traceability relations should be documented. This is because the literature and research concentrates on such fields as aerospace, electronics, and automobile industries, which develop complex and large systems [11]. Ramesh and Jarke were the first to make the distinction between these and industries developing smaller systems in 1998. They interviewed practitioners from 26 companies and realized that 17 companies, which developed systems with approximately 10 000 requirements, had different traceability needs than those 9 companies that developed systems with approximately 1 000 requirements [16]. However, there are no studies of RT in companies developing small systems.

4

1.4 Background, Goals and Structure of the Thesis

This master's thesis is a part of a research project called QURE (Quality Through Requirements), which is a three-year project started in 1999. The project is funded by TEKES (the Finnish National Technology Agency) and six industrial partners, and its goal is to research and develop requirements engineering models, methods and practices. The project employs five researches and focuses on five requirement engineering areas, one of which is requirements traceability.

The goals of the thesis are to introduce requirements traceability and to offer guidelines for documenting RT information. Target group companies develop small systems (i.e. systems with approximately only a hundred requirements) and do not have organization wide traceability practices. The goals of the case study part are to analyze documenting traceability in a company and to develop good practices based on the results. The study is conducted in a company developing embedded systems.

More detailed goals of this thesis are:

• Introduce traceability classes and relations

• Present techniques and tools for documenting traceability relations

• Discuss issues related to developing traceability practices

• Analyze documenting traceability in one company

• Develop good traceability practices for that company

Chapter 2 introduces traceability classes and relations and presents the benefits that can be gained by documenting different RT relations. The goal is to give an insight into what RT information would be worth documenting and why.

Chapter 3 presents techniques and tools for documenting traceability relations. Four documenting techniques and two classes of tools – general-purpose and requirements management tools – are introduced.

In chapter 4, we discuss issues related to developing traceability practices. Firstly, the factors affecting the traceability needs are listed. Secondly, costs and problems that can be encountered when practicing RT are presented. Last, the tasks to develop and implement traceability practices for a company are discussed.

5

Chapter 5 consists of two parts: 1) analysis of traceability needs based on an assessment of documenting traceability relations as well as techniques and tools in the case company and 2) good traceability practices developed for that company. The assessment part studies documented traceability relations, tools, and techniques in order to find out which traceability relations would be worth documenting. The traceability practices were developed according to the assessment results and with the help of two practitioners from the case company. The last section of the chapter presents the improvement actions taken in the company to impose organization wide RT practices.

Chapter 6 states theoretical implications of the thesis, assesses the work done, and suggests future direction for traceability research.

6

2. TRACEABILITY INFORMATION

This chapter introduces four traceability classes referred to as pre-, post-, forward and backward traceability and six traceability relations known as requirement-source, requirement-rationale, requirement-people, requirement-requirement, requirement-component, and requirement-verification. The benefits gained by documenting each relation are presented to help identify those that it would be beneficial to document in different situations.

2.1 Traceability Classes

2.1.1 Pre- and Post-Traceability

Gotel and Finkelstein were the first to use the terms pre- and post-traceability in 1994. They referred to them as pre-RS and post-RS traceability (RS refer to Requirements Specification). In 1996, Pohl shortened these terms to pre-traceability and post-traceability [7].

Pre-traceability is the ability to trace a requirement to its origins or the origins to the requirement. A requirement’s origins include rationale, i.e. the reason for the existence of the requirement, the stakeholders who have participated in requirement creation, sources such as standards, and other information that has affected the creation of the requirement. Gotel and Finkelstein define pre-RS traceability as follows:

“Pre-RS traceability is concerned with those aspects of a requirement’s life that are prior to its inclusion in the Requirement Specification”[10]

Post-traceability refers to the ability of tracing a requirement to the artifacts of the system process such as system designs, components, and verification cases that have been affected by the requirement. Furthermore, the ability to trace the system process artifacts to the requirement is called post-traceability. Gotel and Finkelstein define post-RS traceability as follows:

“Post-RS traceability is concerned with those aspects of a requirement’s life that result from it inclusion in the Requirement Specification”[10]

7

Post-traceability Pre-traceability

Origins of the requirements


Requirements

Causality

Figure 2. Pre and post-traceability.

Traceability between the first box representing the requirements' origins and the second box representing requirements is pre–traceability and it is shown as an arrow in figure 2. Post-traceability is shown as an arrow between the two boxes, which contain requirements and system process artifacts. In addition, the traceability between two or more requirements is classified as post-traceability, but it is not shown in the figure.

2.1.2 Forward and Backward Traceability

The terms backward and forward traceability were first used by Davis in 1990. Traceability is forward, if either the origin can be traced to the requirement or the requirement to those system process artifacts that have been affected by it. It is backward, if system process artifacts are traceable to the requirement or if the requirement is traceable to its origins. [5, 14, 17]

Forward traceability

Backward traceability

Requirements


Origins of the requirements

Causality

Figure 3. Forward and backward traceability.

8

Pre-traceability is frequently backward traceability because the origins are generally non-tangible. Post-traceability can be forward traceability, from a requirement to the system process artifacts or backward traceability, from an artifact to the requirements.

2.2 Traceability Relations

The traceability relations that are introduced in this section are frequently mentioned in the literature as the most important and the first to be documented in projects [5, 10, 16, 18]. There is no agreement on definitions of traceability relations in the literature and thus the names used in this work are not standard but formed to be as understandable as possible.

☺ People 4

Components

1

2

3

Requirements

5

Sources: Companies, Development environments, Standards …

Rationale

6 Verification cases

Causality

Origins of the requirement Artifacts affected by the requirement

Figure 4. The six traceability relations are 1) requirement-source, 2) requirement-rationale, 3) requirement-people, 4) requirement-requirement, 5) requirement-component, and 6) requirement-verification.

Pre-traceability relations are 1) requirement-source, 2) requirement-rationale, and 3) requirement-people. The requirement-source and requirement-rationale relations in particular are commonly used in companies [10, 18]. According to a recent study,

9

companies particularly lacked the requirement-rationale information regardless of its importance [4]. Finkelstein states that the most useful pre-traceability information to document is the source and names of the people who have participated in the activities of the creation of the requirement [10]. The traceability relation that contains information about these people is referred to here as requirement-people.

In addition, certain research has used the term extended pre-traceability. Extended pre-traceability includes pieces of information such as video recordings of system use situations and interviews of system's stakeholders [19]. Additionally, contribution structures, which are models describing the dependencies between stakeholders, have been used to extend requirements pre-traceability [20, 21].

The three most frequently mentioned post-traceability relations in the literature are 4) requirement-requirement, 5) requirement-component, and 6) requirement-verification. These are the first post-traceability relations that are used in practice [16]. However, there are many further relations that have been classified as requirements post-traceability. These include traceability to technical documents, change requests, and system models, i.e. to process models, data-relation models, and data-flow models [16, 18].

2.2.1 Requirement-Source Traceability

The requirement-source traceability relation documents the source, which the requirement is based on [22]. The source can be, for example, a stakeholder, a standard, or some document [18].

The reason to document requirement-source traceability is that it is useful information in requirements validation, analysis, specification, and prioritization. It indicates if a requirement can be changed without the customers' agreement or if the requirement is valid to be reused [17]. Source information indicates the volatility of a requirement. This information is useful for designing system architectures that do not need redesign even if certain requirements change.

2.2.2 Requirement-Rationale Traceability

The requirement-rationale traceability relation documents the reasons why the requirement exists. The rationale is also known as the purpose or reason for the requirement. [8, 22]

Rationale information is useful for analyzing and checking if the set of requirements is valid and complete. The rationale allows the requirements to be prioritized, helps to

10

estimate the probability of their change, and is useful information when changing and reusing requirements. [17, 23]

2.2.3 Requirement-People Traceability

The requirement-people relation documents the persons who have specified the requirement [10]. The relation may contain both the names of the persons and their titles. The title is useful if people leave the project because people doing the same job frequently share common knowledge of requirement related issues like application domains or customers.

The reason to document requirement-people traceability is that if the participants in requirement creation are known, one can usually locate them rapidly afterwards. This makes it possible to generate RT information when needed by asking these people. This might be the only opportunity to get RT information because projects do not usually have time to document everything. Even if this information were documented, it may be desirable to augment it with face-to-face communication. If the project only has time to document one type of pre-traceability relations, the choice would be requirement-people because it also be used to find out the other pre-traceability relations. [10, 17, 23]

2.2.4 Requirement-Requirement Traceability

Is-Constrained

Requirement No. 4

Requirement No. 1.1

Requirement No. 1 Requirement No. 3

Constrains Derives Is-Derived Requires

Requirement No. 5.1 Requirement No. 8.4

Is-Required

Figure 5. The three requirement-requirement traceability relations i.e. 1) derives/is-derived, 2) constrains/is-constrained, and 3) requires/is-required, are shown in the figure as arrows.

11

The literature suggests that the first three requirement-requirement traceability relations that companies should document are 1) derives/is-derived, 2) constrains/is-constrained, and 3) requires/is-required [7, 16, 18].

Derives/is-derived indicates that some requirement adds detail to another requirement [18]. For example, if requirement No. 1 is a general security requirement which states that data should be encrypted, requirement No. 1.1 might specify the characteristics of the encryption algorithm that should be used [18]. This makes requirement No. 1.1 derived from requirement No. 1. This is the first requirement-requirement traceability relation companies have used [16]. With the derives/is-derived traceability between requirements, one can quarantee that all the high level requirements are referred down to the lower level requirements, which are more detailed or more technical ones [7]. This information is additionally used during the system maintenance and rewriting phases to propagate the changes from higher level requirements to the lower level requirements. An employee interviewed by Ramesh explained the benefits that derive derives/is-derived traceability information:

“Often the derived requirements are the problem; you don’t know why and how they got there. Want to make sure that every low level requirement is tied to the bigger level specification”[16].

An example of constrains/is-constrained relation follows: requirement No. 3 specifies that some real value should be displayed and requirement No. 4 states that all real numbers should be implemented as twelve-digit fixed-point numbers [18]. This makes requirement No. 3 constrained by requirement No. 4. Constrains/is-constrained information helps to notice constraints and thus helps to identify the requirements that can not be changed because of other requirements.

Requires/is-required indicates that certain requirements require the result provided by other requirements [18]. For example, requirement No. 5.1 might specify that each transaction processed by the system should be date stamped and requirement No. 8.4 might specify that the system should maintain a record of the current time and date in a specific format [18]. This makes requirement No. 8.4 required by requirement No. 5.1 [18]. Requires/is-required traceability information can be documented to avoid the accidental removal or changing of still valid requirements and functionality.

12

2.2.5 Requirement-Component Traceability

Requirement-component documents relations between a requirement and the components that are designed to implement the requirement. Partitioning the requirements into components is known as requirements allocation and is an essential part of creating new architectures [6]. Requirement-component traceability can be documented as both forward – from requirement to component – and backward – from component to requirement.

Traceability to the components helps engineers keep track of all requirements so that none are lost or added [16]. This information can be used to ensure that all the requirements are implemented in the system. This is particularly important in cases where the system is complex or safety-critical. An employee interviewed by Ramesh explained the benefits of requirement-component traceability documented using an allocation table:

“When you want to know which part of the system satisfies the requirement, you can go to the allocation table to identify it. Whether the part does it or not, is another matter – for testing to worry about it” [16].

Requirement-component is important information for the management to do the work breakdown structure. It is also useful for deciding the development schedule, identifying the riskiest components, and selecting the teams to develop the components according to the skills needed. The information allows the status of the components to be followed by measuring the percentage of implemented or tested requirements. When requirements change, requirement-component information makes it possible to identify affected components, estimate the cost, and manage the change to the system [6, 8, 9, 23, 24]. An employee in one of the QURE partner companies explained why requirement-component traceability relation should be documented:

“If a requirement changes one has to talk with everybody to know to which components the change affects. If the requirement-component traceability information is documented, the affected components can be identified more easily”.

Requirement-component traceability plays an important role in making development contracts if components are developed in different companies [8]. This information helps one analyze the dependencies between components and thus estimate the quality of system architecture. It can additionally be used to share knowledge about system architectures for example to train new system engineers.

13

2.2.6 Requirement-Verification Traceability

Requirement-verification traceability documents the relation between a requirement and the artifacts that verify that the system fulfills the requirement [25]. These artifacts can be, for example, test cases. High-level customer requirements are most naturally linked to the acceptance test cases and the system requirements to the system and integration test cases. Requirement-verification traceability operate either forward or backward.

The requirement-verification relations can be used to ensure that the desired functionality is in the product and verified. In the verification phase, one can 1) check that the test cases test the requirement, 2) focus the efforts on testing the most important features, which the test engineer can identity with requirements' priorities. In addition, when the change to certain requirements takes place, requirement-verification is useful information for identifying those test cases that need to be retested. [6, 8, 9, 23, 24]

14

3. TECHNIQUES AND TOOLS

This chapter introduces four techniques referred to as identifier, attribute, list, and table to document RT information. For each technique the traceability relations that can be documented with it are mentioned as well as an example of usage given, benefits, and problems discussed. The rest of this chapter introduces two classes of tools – general-purpose and requirements management tools. For both classes the chapter lists 1) when to use it, 2) tools belonging to the class, 3) tasks the tools support, and 4) their limitations.

3.1 Identifier Technique

Traceability relations can be documented to the identifiers of system process artifacts. The term identifier refers to a unique name or a reference number, whose main function is to identify uniquely each artifact. An identifier can simply be a unique number whereas more sophisticated versions consist of substrings of letters and numbers. Identifiers are necessary for managing and making references to artifacts.

This technique is best suited for documenting one-to-one or one-to-many traceability relations. An example of one-to-one traceability is the relation between a requirement and a test case and an example of one-to-many is the relation between a requirement and several test cases. Pre-traceability information can not be documented to the identifier because it is frequently impossible to be abbreviated. Moreover, many-to-many traceability relations are troublesome to document using this technique. The following example shows how the requirement-requirement derives/is-derived traceability is documented to the requirement's identifier in an example project developing a system called Great Computing System.

Chapter 2: User Interface

GCS-UI-1 The user interface shall have grid facilities.

GCS-UI-1.1 The editor shall provide a grid facility where a matrix of horizontal and vertical lines provide a background to the editor window.

GCS-UI-1.2 The numbers of units separating grid lines shall increase when used in the ‘reduce-to-fit’ mode.

Figure 6. Derives/is-derived traceability documented using requirements' identifiers.

15

The requirements in the example are constructed by first stating the identifier and then the sentence describing the requirement. The identifier of the first and highest level requirement is GCS-UI-1 and the sentence is “The user interface shall have grid facilities”. The identifier is constructed from three dash-separated parts:

1) abbreviation of the product, GCS

The GCS is an abbreviation of Great Computing System and it is included in the identifier to help identify the product the requirement belongs to. This is useful for example if the requirements of different products are maintained in the same database or referenced from non-project documents.

2) abbreviation of the requirement class, UI

The UI is an abbreviation of User Interface and is the name of the class to which the requirements belong. Requirements are frequently classified into groups having one or more common characteristics. A common way to classify requirements is according to the functionality that they require, which is user interface functionality in the example. Because the design of architecture is frequently based on implementing the same kind of functionality in one component, the class of the requirement can also implicate the name of the component. This can of course be true only if the requirement is fulfilled by one component.

Reasons for classifying requirements are numerous: 1) Conflicting re-quirements frequently state the same kind of functionality and are thus more easily found. 2) System experts are frequently interested in one or a few classes of requirements; for example the system mathematician would be interested in calculation requirements. 3) Classification supports in designing architectures and in testing efforts. For example, it might be possible to test requirements of the same class in same testing environment.

3) number of the requirement, 1

The number 1 means that this is the first high level requirement in this class. High level requirements are identified with simple numbers and the requirements that are derived from them are numbered with the syntax like 1.1. and 1.2. The first number is the number of high-level requirement i.e. the father requirement and the second is the number of the child requirement. Thus, the identifiers imply that the requirement GCS-UI-1.1

16

and GCS-UI-1.2 were derived from the high level requirement GCS-UI-1. This is one way to document requirement-requirement derives/is-derived relations using the identifiers.

A benefit of the identifier technique is that they are frequently assigned to the artifacts anyway. Thus, RT information does not create any additional documentation and it is easily found in the identifiers.

A problem should be mentioned; if identifiers must be assigned to artifacts immediately after they are created, the traceability relations may still be unknown and impossible to document. Giving temporary identifiers to artifacts solves the problem but replacing them with real identifiers requires additional work. Understanding the documented traceability information may be problematic if practitioners have not agreed on the syntax of identifiers.

3.2 Attribute Technique

Traceability relations can be documented to the attributes of system process artifacts. The term attribute is used here to refer to those characteristics that may have several values. For instance, the characteristics named "color" can have several values: blue, red, or green. Frequently, such characteristics as priority, date of creation, and traceability relations are documented to system process artifacts using attributes.

The technique is suited for documenting any kinds of traceability relations, whether they be one-to-one, one-to-many, or many-to-many. However, many-to-many relations will be more usable if they are documented using the table technique that is presented in section 3.4. Because the attribute technique supports documenting long, verbal explanations, it is the best technique for documenting pre-traceability, particularly source and rationale information.

Attributes of requirements allow documenting RT information while attributes of components allow documenting requirement-component and attributes of verification cases requirement-verification traceability information. The attribute technique is similarly useable for documenting information for a group of artifacts if they have the same traceability information. In extreme cases it is enough to document traceability information only once. One imaginable case could be that the same group of people have specified all requirements resulting in identical requirement-people relation for each requirement.

17

The next example shows how attributes are used to document requirement-source and requirement-verification RT relations for a group of requirements. The group consists of three requirements: one high level requirement and two low-level requirements that are derived from the high level requirement.


The attributes documented with the high level requirement are also valid for the low-level requirements derived from it.

GCS-UI-1 The user interface shall have grid facilities.

Source: Jukka Laakso, customer from company B.

Test cases: T-10, T-11, T-15

GCS-UI-1.1 The editor shall provide a grid facility where a matrix of horizontal and vertical lines provide a background to the editor window.

GCS-UI-1.2 The numbers of units separating grid lines shall increase when used in the ‘reduce-to-fit’ mode.

Figure 7. Requirement-source and requirement-verification traceability documented to the attributes of a high level requirement.

In the example, the source attribute states that the source of the requirements is Jukka Laakso, who is a customer from company B. The test cases attribute states that the test cases testing these requirements are T-10, T-11, and T-15.

A significant benefit of the attribute technique is that it useful for documenting many kinds of traceability relations. Moreover, it is straightforward to use and known to engineers, for example, because attributes are also used in the databases. Additionally, attributes can be used for a group of artifacts, which makes documenting less laborious than documenting RT information for each artifact separately.

A problem is that extensive use of attributes makes the requirements document longer and thus harder to read. The groups of artifacts that have identical values of traceability relations may be hard to form, particularly if they overlap. Information documented in this way is also hard to update.

18

3.3 List Technique

Traceability information can be documented to a list located in a document, spreadsheet, or database. The list technique is best suited for documenting one-to-many traceability relations, which frequently include post-traceability relations. However, for example, many-to-many relations are easier to document with the table technique and pre-traceability information with the attribute technique.

Requirements Components implementing the requirement

UI-1 – UI-9 User interface component, existing window manager

SAF-1 – SAF-5 Network component, error handler component, existing network hardware

SAF-6, SAF-7 Security component

Table 1. Requirement-component traceability documented to the list.

The first row containing artifacts, can be read as “The user interface component and the existing window manager implement the system’s user interface requirements from first to ninth”.

An advantage of the list technique is that with it one can document many kinds of traceability relations to one place , such as the appendix of a requirements document. Moreover, it takes less space and is less error prone than the table technique discussed next [18].

A problem with the list technique is that traceability relations are easily readable only in one direction. In particular if the list is long, the relations are hard to read in the other direction. Relations documented using the table technique are readable in both directions, which makes the table technique better for documenting many-to-many relations.

3.4 Table Technique

RT relations can be documented to a table located in a document, spreadsheet, or database. A table is best suited for documenting many-to-many and one-to-many relations i.e. post-traceability information. This is because once created, it has a unique cell for each pair of artifacts.

19

In the following example, a table is used to document the requirement-requirement requires/is-required and constrains/is-constrained information. The first is marked with the symbol “R” and the latter with “C”.

UI-1.1 UI-1.2 UI-2 UI-3.1 UI-3.2

UI-1.1 R R

UI-1.2

UI-2 C

UI-3.1

Table 2. Requires/is-required and constrains/is-constrained documented to the table.

The first row means that the requirement UI-1.1 requires the requirements UI-2 and UI-3.1 and the fourth row that the requirement UI-2 constraints the requirement UI-2. Because the relations are non-associative, they are only readable in one direction.

One benefit of the table technique is that it is the most visual technique particularly for documenting many-to-many relations because relations can be read in both directions [18]. Another benefit is that different symbols can be used to document different types of relations, which can thus be documented to the same table. For example, a table of requirement-requirement relations is usable for documenting overlapping requirements in addition to traceability relations. Also numeric values can be documented to the relations, for example to the requirement-component relations when a high level requirement states the total weight of the system.

Problems include the risk that the direction in which the relations should be read may be mistaken. Such mistakes can happen if a table is used to document non-associative relations between same kinds of artifacts, i.e. between requirements. Another problem is that a table easily becomes large, which makes it unmanageable and error prone. [18]

3.5 General-purpose Tools

If tracing is manual, it can result in most cases either not being done at all or being performed poorly [3]. Therefore, for most projects one needs specific tools to assist in practicing RT, be it a general-purpose or a more advanced requirements management tool [12]. Although traceability is not a concern of such general-purpose tools as word processors, they can be configured to support traceability activities [10, 26]. This makes

20

them suitable for small-scale and short-term projects [10, 26]. However, general-purpose tools are not sufficient for extensive requirements tracing purposes.

General-purpose tools include spreadsheet programs such as Lotus 1-2-3 ™ (Lotus Development Corporation), MS Excel ™ (Microsoft Corporation), and Quattro Pro ™ (Corel Corporation), word processors and hypertext editors such as MS Word ™ (Microsoft Corporation), WordPerfect ™ (Corel Corporation), and Frame Maker ™ (Adobe Systems Inc.) [27]. Word processors provide ways to document traceability with such techniques as lists and tables, hypertext editors can be used to create links between artifacts, and spreadsheet programs help keep track of different level requirements and their attributes. Macros facilitate the automation documenting and maintaining tasks as well as to scan the documents, for example to search requirements or to create summaries. The tools can also be also used with databases in which the requirements are maintained [28].

There are three main limitations in using general-purpose tools to document RT information: 1) configuring tools is time consuming, 2) tools do not usually integrate with the lifecycle wide tools nor support many simultaneous users, and 3) tools do not provide a common and consistent framework for traceability but promote immediate and ad hoc solutions. Thus, the quality of documentation varies. [10, 26]

3.6 Requirements Management Tools

Projects producing large and complex system need more dedicated tools than general-purpose tools to help in practicing traceability because the volume of the data makes traceability tasks more error-prone and time consuming [8, 12, 29]. Another important reason for using requirements management tools (RM-tools) is that they additionally support other requirements management tasks than documenting RT. RM-tools are best suited for large projects and/or organization wide usage [26].

Examples of requirements management tools include RequisitePro ™ (Rational Software Corporation), Caliber-RM ™ (Technology Builders, Inc.), DOORS ™ (Telelogic AB), Slate ™ (SDRC), RTM Workshop ™ (Integrated Chipware, Inc), and CRADLE ™ (Structured Software Systems Limited) [28, 30]. Basic functionality and characteristics are the following [10, 28, 31, 32, 33, 34, 35, 36]:

21

Basic functionality:

• Documenting information to attributes of requirements.

• Filtering and sorting to view requirements

• Importing and exporting requirements to and from the tool

• Documenting and using RT information

• Supporting configuration and change management tasks

Other characteristics:

• Graphical user interface

• Compatibility with other tools

• Support for simultaneous users

RM-tools should have attributes for requirements, such as creation date, version number, rationale, and priority and support defining more attributes for requirements. Moreover, sorting and filtering of requirements, based for example on values of the attributes, should be supported. Importing requirements may be needed, for example to add requirements from previously written requirements documents to the database of the tool whereas exporting is needed to create requirements specifications, reports, and summaries. Tools should support documenting bi-directional traceability relations, i.e. relations that are both forward and backward. This means that one requirement-component relation should be shown in a tool as both relation from requirement to component and from component to requirement. The use of information could include such functions as analyzing the impact of changes and generating reports of requirements' statuses. Configuration support should consist of such functions as storing and recovering sets of requirements that belong to a particular release whereas change management functionality could automatically document requirements' change history. To be usable and support visualization of data, RM-tools should have a graphical user interface and, in order to utilize further the documented information in other tools, they should integrate with them. In addition, currently used practices can set limits or require some functionality from RM-tools. For example, support for multiple simultaneous users may be necessary.

The research has reported several problems with RM-tools. Finkelstein argues that RM-tools: 1) support managerial activities rather than the activities of requirement specification producers, 2) are difficult to adapt to working practices, 3) do not provide means to

22

coordinate concurrent work, and 4) integrate poorly with other tools [10]. In addition, they can also impose arbitrary limits for the data stored in them, for example by insisting that a requirement must belong to a project. This makes it impossible to have pre-project or post-project requirements. Another problem is the price of an RM-tool. It consists of costs of licenses, consultation, training end-users, system maintenance, and integrating the tool to the current environment.

23

4. DEVELOPING TRACEABILITY PRACTICES

This chapter discusses issues related to developing traceability practices. Firstly, it lists factors affecting the traceability needs and secondly, it presents costs and problems that can be encountered when practicing RT. Last, it discusses the tasks to develop and implement traceability practices for a company.

4.1 Factors Affecting the Need for Traceability

Companies should take into account many factors when they analyze the need for practicing RT. According to Kotonya and Sommerville, the most important of these are [5]:

1. Type of the system

2. Estimated system lifetime

3. Number of requirements

4. Size of the project team

5. Level of organizational maturity

6. Specific customer requirements

1. Critical systems, such as hard real-time control or safety-critical systems, need comprehensive RT practices. They are often additionally required to be traceable by standards. Traceability is used to ensure that these systems fulfill the requirements. On the other hand, less critical systems, such as prototypes, do not need as comprehensive traceability documentation, if any.

2. Systems that have a long life usually must be fixed, updated, and maintained. In these tasks, one benefits from traceability information. On the other hand, if the life of the system is short (as in case of mockups and prototypes), RT information is not worth documenting. Normally, it holds that the longer the system life is, the more comprehensive traceability practices are needed.

3. Systems having many requirements need more formal traceability practices than smaller systems. Documenting RT information for large systems can be impossible without RM-tools. Kotonya and Sommerville even state that documenting such comprehensive RT

24

information as requirement-component is impractical for a large system as there is too much information to maintain [5]. On the other hand, if the system has few requirements, traceability information is easier to remember.

4. If the project team is large or scattered geographically, it is more useful to document RT information than if the project team is small because a small team can more easily get together and assess the impact of proposed changes. Small projects are able to discuss requirements and ensure that they are implemented without documented RT.

5. In companies having high process maturity level, detailed traceability practices are most likely to be cost effective. This is because in basic maturity level companies, all the analyzing and quality assurance tasks in which the traceability information could be useful are not accomplished.

6. A customer can require that RT information be documented. This is common in projects of the U.S. Government and in such industries as aerospace, electronics, and telecommunications as well as in others industries that develop safety-critical or hard real-time control systems. A customer who has standards to follow may also require traceability from his/her subcontractors.

Traceability is also worth documenting if:

• Requirements are expected to change frequently

• It is important to see interrelations between documents

• Requirements or parts of the system are going to be reused

• Documentation is used to communicate between different parties

• The system is going to be maintained by a different company

• Project people frequently change

In the last case, documenting RT information is necessary for maintaining the understanding of the system structure in the project.

Not all projects benefit from RT practices. These include projects in which requirements are not used or there is no time to document RT. An example could be a situation in which it is critical to get the product to the market before competitors.

25

4.2 Costs

Costs of traceability practices include the cost of developing and introducing them and the cost of gathering, documenting, and maintaining RT information [5].

The costs of developing and introducing traceability practices are comparable with the costs of developing and introducing any other significant quality management procedure [18]. Several months of calendar time may be needed for consultation, and effort is required to ensure that high-quality practices are developed and reviewed [18]. Documents such as process models, standard templates of documents, and instructions must be updated. Once that has been accomplished, the practices must be introduced for example in training sessions. After the practices are brought into operation, there still remain the costs of updating them, according to feedback from practitioners. The amount of time needed for updating depends strongly on the quality of the practices first introduced.

The costs of gathering, documenting, and maintaining pre- and post-traceability differ. Pre-traceability relations such as requirement-source, requirement-rationale, and requirement-people should be well known if requirements are systematically collected. Thus, the main costs are related to documenting and maintaining RT information when it is changed. If there are many requirements and pre-traceability is documented for all of these, the costs of pre-traceability can be considerable. In any event they are usually smaller than those of post-traceability, which are mainly due to analyzing traceability relations between artifacts and maintaining RT information. The costs of analyzing post-traceability relations depend strongly on the quality of the artifacts to which they are documented whereas the costs of documenting depend on techniques and tools used. Moreover, maintaining post-traceability is more laborious than maintaining pre-traceability because a change in one requirement can create a need to update several post-traceability relations.

4.3 Problems

Problems can be encountered first when traceability practices are developed and introduced and later when information is gathered, documented, and maintained. If there are difficulties in using traceability information, benefits will consequently be fewer than estimated.

The problem in developing practices is that there may be both unrealistic beliefs of and doubts as to the value of RT practices. The first can lead to the creation of too complex practices, which will not be followed, whereas the latter will slow down their development

26

and introduction. In addition, introduction can be difficult if projects are already required to create a lot of documentation in a tight schedule.

Main problem in gathering pre-traceability information is that information is hard to remember if it is not documented immediately. Analyzing post-traceability relations is difficult if artifacts like requirements, components, and test cases are documented unclearly or in different levels of detail. Time and expertise, which are frequently lacking in the projects, are necessary for documenting post-traceability relations in particular.

In addition to challenges in using techniques and tools, lack of motivation can hinder documenting RT information. Motivation may be low because practitioners who should document traceability relations seldom benefit from documenting. Besides, they may want to improve their technical skills more by developing the system than by documenting it. The management can use RT to generate reports of project progress, which may represent too much control in the employees' point of view. In maintaining RT information and informing about its changes, a possible difficulty is that the project personnel's responsibilities are unclear. Practitioners do not necessarily know how to use the information. This includes the failure to identify the situations in which it could be used or where to find it. Even when they find it, they may not know how up to date or reliable RT information is.

4.4 Tasks to Develop and Implement Traceability Practices

While the tasks involved in implementing RT practices vary as much as there are implementers, the tasks considered good in our project are as follows:

• Analyze the company's need for RT

• Define RT relations which should be documented

• Select techniques and tools to be used

• Choose when, by whom and to where information should be documented

• Ensure that the RT practices are taken into use in needed extent

The need for traceability should be analyzed before practices are developed because all companies do not necessarily benefit from RT. The main benefit of traceability is improved quality of the system, which may not be the first business need of an innovative start up company in rapidly expanding markets. On the other hand, for companies in more

27

mature market domains, the quality of products can be one of their best assets. Frequently, the company itself has already realized the value of RT practices at the time when consultants are hired to implement them.

The RT relations worth documenting may be selected by weighting the usefulness of information versus work amount. This is not a straightforward task. Ways to accomplish this are:

• Interviewing practitioners

• Trying to find the practices that are already used in some projects

• Brainstorming and piloting RT practices in projects

A drawback of interviews is that the practitioners do not necessarily know which information should be documented. Furthermore, RT information documented in certain projects can turn out to benefit only these projects and may be useless in others. Piloting can take a great deal calendar time because it is not enough to measure the usefulness of information during the projects. This is because many of the benefits can not be seen until the maintaining phase or the writing of the next version of the system.

It may not be clear immediately which techniques and tools should be used. It is less risky to pilot traceability techniques with general-purpose tools or even on paper than to buy an RM-tool. In certain cases, the latter may be the only possibility if RT information is used extensively in a tight schedule throughout the company. The cost of experimenting different techniques is negligible whereas the decision to buy an RM-tool is frequently more expensive and conclusive.

Other important decisions include the time that information is documented. If information is documented right away, it is usually more exact than if it is documented later in the process. However, the sooner the RT relations are documented, the more likely they will have to be updated. The next thing to decide is the responsibilities, i.e. who should gather, document, and update RT information. Last, the place where traceability information is kept should be decided. Frequently, traceability relations are documented to a requirements specification or component and test case documents. If there is a large amount of RT information to be documented, a separate document, called traceability manual, can be used [18]. If RM-tools are used, information is frequently maintained in a database.

The last task is to ensure that RT practices are brought into operation to the appropriate degree. This requires that all affected documents be updated (for example process models,

28

instructions, and standard document templates), project people trained, and the extent to which the traceability practices are taken into use decided. First, when there is no real evidence of traceability practices' usefulness, the decision to use them could be made at the project level. Later, if the practices are seen to benefit the projects, they can be taken into organization wide use. If all projects are forced to document RT, there should additionally be policies to handle exceptions to this practice. After all, there always exist projects in which RT information is either not worth documenting or can not be documented, for example because of the short time available to get the product to the market.

29

5. CASE STUDY: DOCUMENTING TRACEABILITY

This chapter presents a case study conducted in one of QURE's industrial partner companies that develops embedded systems. The first section analyzes the factors affecting the company's traceability needs and the second introduces the projects and interviewees used in the assessment of documenting traceability relations. Then the results, i.e. used traceability relations, tools, and techniques are presented. The chapter concluded with a summary of the assessment results, good traceability practices developed, and discussion of improvement actions taken in the company.

5.1 Analyzing Company's Need for Requirements Traceability

First, we analyzed the need for traceability in the company. The factors affecting the need are: 1) estimated system lifetime, 2) number of requirements, 3) size of the project team, 5) level of organizational maturity, and 6) specific customer requirements [5].

The company in which the case study was conducted develops measuring equipment for ensuring stability and reliability of operations in meteorology, traffic, industry, and research. The lifetime of the systems is expected to be decades. The oldest product is almost 30 years old, but there are also many new products.

The number of requirements per projects, which is from ten to 150, has not increased in the course of time while the functionality of systems has. Systems have become more product like and the project team size has increased to comprise 5 to 20 part or full time workers. Thus the current projects need more detailed practices than previous projects, which had been possible to control even without detailed practices. Even if the business of the company is global, system development is still centered in one place.

The company has not appraised itself with CMM, but the level seems to be the first because allocating requirements to the components, which is required in the level 2 is not done. In the past, certain customers required traceability between documented requirements and the system design document to be able to check that there existed a design for given requirements. Today, these customers prefer generic to tailored systems and thus the traceability to the design is no longer necessary.

In, summary, the value of RT practices is suggested by the criticality and longevity of the systems. Further, the increase in system and project size suggests that the need for

30

documenting RT information is becoming even more evident. On the other hand, the customers do not require RT, and the maturity of the company's processes is high according to the CMM scale.

5.2 Projects and Interviewees For Assessment

Project Years Number of requirements

Practitioners interviewed

A 1997 - 1999 90-140 - B 1998 - 1999 30 - C 1999 115 - D 1999 - 44 Project manager E 2000 - 66 Product manager

Table 3. Projects and practitioners interviewed used in assessment.

The five largest projects, in terms of man-months, were selected for assessment. The company was going through an increase in project size. The projects had up to 20 workers and most projects were developing new versions of old systems. The number of requirements varied from forty to 150.

Practitioners to be interviewed were selected from the two projects that were still in progress. From project D, we interviewed the project manager who had been working over 10 years in system development and the last one and half years in the case company. The practitioner from project E was the product manager. He had been working for 20 years in system development in the company. Moreover, he had ten years of experience in project managing and several years’ experience of product development. Both practitioners had been involved in process improvement activities.

5.3 Assessment Results

Assessment was conducted by interviewing the practitioners and analyzing documents. It was performed to find out how the interviewees would understand traceability terms, to what extent RT information was already used, which techniques were used to document it, what were the experiences, and how important documenting RT was seen in future projects. Detailed questions are presented in Appendix 1.

31

Interviewees were also asked when, by whom, and to where RT information should be documented. Answers to these questions were largely consistent: Pre-traceability and requirement-requirement traceability should be documented to the requirements document, requirement-component information either to the architecture document or to the components design documents, and requirement-verification information to the document containing test cases. Information should be documented by the author of the document as soon as possible.

5.3.1 Requirement-Source/People Traceability

In the documents, the most frequently used pieces of requirement-source information were names of the contracts, customers, and people that had participated in the requirement creation activities. There were also sources such as the wishes of a customer and generic need, but interviewees did not consider these in sufficient detail. Other accepted sources by interviewees included people working for the customer, tenders, standards, conferences, name of market areas, and reference to the project's previous phases.

A B C D E

0 %

30 – 70 %

30 – 1 %

> 70 %

Figure 8. Percentages of requirements to which requirement-source information had been documented.

Project A had not documented the source or people involved information at all, whereas project B had documented the people involved information for almost every requirement. Despite the fact that project C had not documented source or people information for each requirement, certain sources of requirements could be found in the first pages of the requirements document. Both projects D and E had the source information with almost all the requirements. These contained both the non-people sources such as contracts and standards as well as the names of the people.

The technique for documenting the source and people information was the attribute technique in all the projects, but the names of the attributes varied. Most of the projects had been using an attribute named source, whereas others used also attributes named

32

rationale and comment. The interviewees were convinced that an attribute named source was the best technique to document both the source and people information.

Figure 9. Requirement-source information was documented using the attribute technique.

The interviewees said that source information, including the names of people involved, should be documented in every project for all requirements. According to the practitioner from project D, sources, such as a specific customer, help understand the requirement if one knows how that customer works and what he wants from the system. He also thought that it helps validate the correctness of the requirements. The practitioner from project E said that documented source information helps ensure that requirement is important to be implemented to the system by stating for example the name of the customer who would pay for the feature. He also saw that the source is the most important piece of information when requirements related issues are traced afterwards. Both interviewees agreed that the requirement-people relation should be documented to the source attribute, too. This was because names of people had to be known in case someone wanted to discuss requirement-related issues afterwards. The people-requirement relation was also seen as useful for ensuring that there have been enough professionals to specify the requirement.


In the documents, rationales explained reasons for requirement existence and included references to contracts, competitive advantage, standards, and names of other systems requiring the stated functionality. Interviewees also accepted names of market areas, customers’ current and future needs as well as the company’s own requirements for the system as possible rationale information. Not accepted were those that included more detailed explanations of a requirement itself and descriptions of how it could be fulfilled by the system. Interviewees explained that the term rationale refers to the reasons that the requirement exists.

33

> 70 %

30 – 1 %

30 – 70 %

0 % A B C D E

Figure 10. Percentages of requirements to which rationale had been documented

In project A's requirements document, there were exclusively rationales that explained many requirements at once. These had to be searched in the document, because it was in prose. Other projects had documented rationales more systematically and used them to explain only one requirement at a time. Projects B, D, and E had documented the rationale for almost all requirements and project C for approximately half of its requirements. Project E had additionally used an e-mail as rationale information. The e-mail contained discussion with a customer about the requirement, and thus explained its need.

Figure 11. Requirement-rationale information was documented using the attribute technique. Extended pre-traceability information, in this case a mail from a customer, was included to one requirement and it is shown as an icon in the figure.

The rationale information was documented to requirement attributes. Interviewees were convinced that it was the best technique to document these relations and only had positive

34

experiences of it. In project E, e-mail was included to the attribute field as a linked object. Adding linked objects to the document was seen as a valid technique if there was information concerning and extending requirements pre-traceability.

The interviewees were certain that the rationale relations are worth documenting in every project and planned to document them in their future projects, too. The one interviewee thought that the rationale should be documented for every requirement, and the other that it should be documented for all but the most obvious requirements. They said that the rationale is essential information for understanding the requirement and the reason for its existence. They also agreed that information such as e-mails could be used to extend or even replace the requirement-rationale and requirement-source information.

5.3.3 Requirement-Requirement Traceability

The only requirement-requirement relations were two derives/is-derived relations found in the same requirements document. Both of them were documented between one high-level customer requirement and one lower level, more detailed requirement. The interviewees agreed that this is derives/is-derived requirement-requirement traceability. Other kinds of requirement-requirement traceability were not found in documents, nor did the interviewees have experience of these.

A B C D E

0 %

30 – 70 %

30 – 1 %

> 70 %

Figure 12. Percentages of requirements to which requirement-requirement derives/is-derived information had been documented.

The only documented requirement-requirement derives/is-derived traceability relations were found in project E’s requirements document. They were documented using the identifier technique, which was not considered straightforward enough to be used in future projects. The interviewees belived there to be no simple technique to document dependencies between requirements but that an RM-tool is needed to support documenting.

35

Interviewees said that documenting relations was not the only challenge. It was not known how to analyze requirements relations. However, requirement-requirement relations were not seen as the first ones to be documented. Interviewees said that at the time it would be more important to try to take the more easily documented RT information than requirement-requirement into wider use in projects.

Figure 13. Requirement-requirement information was documented with identifier technique.

The requires/is-required and constraints/is-constrained relations were more needed than derives/is-derived. One practitioner had tried to document derives/is-derived traceability but noticed that, in addition to customer requirements, one would also need detailed requirements, which had to be created from customer requirements. Although the task had been very laborious, the interviewees thought that there might be benefits in deriving detailed requirements if somebody had time to write them. Both interviewees were interested in trying to document requires/is-required and constraints/is-constrained traceability in their future projects. Even if spesific benefits that accrue from information were not known, the interviewees were convinced that requirement-requirement dependencies should be documented so that they could be known by all project members.


One project had documented component-requirement traceability relations. It had documented them between requirements and those components for which there existed design documents. The interviewees defined the term requirement-component traceability to mean that a requirement affects the design of a component and agreed that requirement-component RT information includes both forward and backward traceability.

36

A B C D E

0 %

30 – 70 %

30 – 1 %

> 70 %

Figure 14. Percentages of components for which requirement-component information had been documented is shaded dark gray. The light gray is used to show the plans to document these RT relations in the still ongoing project E.

Documents of projects A and B did not contain identified components and thus no requirement-component RT information. Documents of projects C, D, and E all contained some pictures and explanations of components whereas project D alone had documented requirement-component traceability. In project E there were plans to document these RT relations.

Figure 15. Requirement-component information was documented to the chapter of the component design document entitled "Related Requirements".

In project D, the requirement-component information was included in the beginning of all the components design documents in a chapter entitled "Related requirements". This chapter was used to list the requirements that the component was to implement. The technique can be considered as a special case of the attribute technique, where the "Related

37

requirements" is the name of the attribute and requirements listed to the chapter are values of the attribute. The practitioner, in whose project this had been tested, said that referencing to requirements from design documents helps keep in mind why the component is designed and to ensure that requirements are met. Both interviewees also suggested that the table technique could be used to document these RT relations. The attribute technique was considered/thought easy to use, but the table technique had in comparison certain benefits. A table could be used to help in writing architecture description and other technical documents. It was also seen to support requirements change management, because all requirement-component RT information could be found in it more easily than in the design documents.

The requirement-component RT relations were considered worth documenting in every project for every requirement and component. The interviewee who had already used the requirement-component information was going to use it in his future projects, too. Another interviewee had not yet documented these relations


The requirement-verification traceability had been used only in one project. It had been documented between the requirements and the test cases. Nevertheless, the interviewees agreed that if there were other verification cases, traceability could similarly be documented for these. Both forward and backward traceability were seen as important parts of requirement-verification traceability.

A B C D E

0 %

30 – 70 %

30 – 1 %

> 70 %

Figure 16. Percentages of requirements to which requirement-verification information had been documented is shaded dark gray. The light gray is used to show the plans to document this RT information in the still ongoing project E.

Projects A, B, and C had not documented any test cases whereas project D had and project E had plans to do so. Project D had documented verification traceability for all but two

38

requirements which could not be tested because they stated the cost of components and would have needed other kind of verification than test cases.

Figure 17. Requirement-verification was documented using the identifier technique.

The technique used in project D was the identifier technique, i.e. the identifiers of test cases were created from the identifier of the requirement that they tested. Because several test cases tested each requirement, the identifiers of test cases were also assigned a number to be able to identify separate requirements testing the same requirement uniquely. The identifier technique was seen as a potential technique to be used to document these traceability relations. The practitioner who had used this technique was sure that he would also use it in the future. He preferred the identifier to the table technique because he saw that a table could easily become too large to handle. The other interviewee was going to use the table technique because with it one could similarly document other requirement and verification related information than traceability.

Interviewees considered the requirement-verification relation useful and planned to document it in the future. They were convinced that requirement-verification information should be documented in all projects. The reasons were that requirement-verification

39

traceability helps the tester to check what the system is expected to do and to ensure that all requirements have a related test case.

5.4 Summary of Results

5.4.1 Need for Traceability Information

The following figure shows the need for documenting each type of traceability relation according to the two interviewees.

Pre-Traceability Post-Traceability

Oth

er

Not needed

Req

uire

men

t-Ve

rific

atio

nR

equi

rem

ent-

Ver

ifica

tion

Req

uire

men

t-C

ompo

nent

Req

uire

men

t-C

ompo

nent

Req

uire

men

t-R

equi

rem

ent

Trac

eabi

lity

Oth

er

Req

uire

men

t-R

equi

rem

ent

Tra

ceab

ility

Req

uire

men

t-R

equi

rem

ent

Der

ives

/Is-

Der

ived

Req

uire

men

t-R

equi

rem

ent

Der

ives

/Is-

Der

ived

Exte

nded

Pre

-Tr

acea

bilit

yE

xten

ded

Pre-

Tra

ceab

ility

Req

uire

men

t-R

atio

nale

Req

uire

men

t-R

atio

nale

Req

uire

men

t-So

urce

/Peo

ple

Req

uire

men

t-So

urce

/Peo

ple

May be needed

I am not sure

Needed

Certainly needed Req.-Req. Traceability

Person D Person E

Figure 18. Need for documenting each type of traceability relatio stated by interviewees

The requirement-source/people and requirement-rationale pre-traceability relations were considered most important, because the benefits of these could be noticed by many project people working in different roles. The most important benefits were that pre-traceability information helps one understand requirements and the need behind them as well as locate people and customers, who would know more about the requirements. Documenting extended pre-traceability information was seen as possible or even necessary, depending on the importance of available information.

Post-traceability was seen as less important than pre-traceability. For example, interviewees thought that project people should know the requirement-requirement

40

relations but considered that, for the time being, it is more important to bring the other traceability relations into wider practice in projects. Derives/is-derived information was regarded as the least important kind of RT information because only one level of requirements, i.e. the customer requirements was used. Specific benefits of requirement-requirement relations were not known because they were not experimented with to an sufficent degree in any project. Interviewees thought requirement-component and requirement-verification information useful for managers and designers of both components and verification cases. The main benefits of documented requirement-component and requirement-verification relations were that they helped one keep in mind the requirements when designing components or verification cases and ensure that all requirements are designed, implemented, and verified.

5.4.2 Techniques and Tools to Document Traceability Information

The next table summarizes 1) techniques that were used to document RT information, 2) interviewees' experiences of these, and 3) techniques that were identified as potentially useful in future projects. One face represents the opinions of one interviewee. More than two faces may appear on one row because one interviewee could have both experiences of and opinions about what would be a good technique to document each traceability relation.

Iden

tifie

r

Attr

ibut

e

Link

ing

to a

ttrib

ute

List

Tabl

e

RM

-tool

Requirement-Source/People ☺ ☺

Requirement-Rationale ☺ ☺

Extended Pre-Traceability ☺ ☻ Requirement-Requirement Derives/Is-Derived

☻ ☻

Requirement-Requiremen Others ☻ ☻

Requirement-Component ☺ ☻ ☻

Requirement-Verification ☺ ☻

☺ I used and liked

I used but will not use in the future

This could be a good technique

☻

Table 4. Techniques that have been used or planned to be used.

41

Interviewees said that such pre-traceability information as requirement-source/people and requirement-rationale could be documented with the attribute technique without problems. Both had written the attributes to the requirements document using the Microsoft Word word processor. In addition, the customer's e-mail was linked to the rationale attribute because it chiefly explained rationales. Linking was used only once by one of the interviewees and thus there was not much experience of it. Still, the other interviewee agreed that linking could be a usable technique to document extended pre-traceability information for requirements.

The best techniques to document post-traceability relations were not as apparent as the best techniques to document pre-traceability relations. Interviewees thought that requirement-requirement traceability was too complicated to document without an RM-tool. One of the interviewees had documented requirement-component information using the attribute technique to a chapter in a component design document and requirement-verification using the identifier technique. He had no problems with these. Both agreed that the table technique could be used, too. They saw that there are many techniques to document requirement-component and requirement-verification traceability relations. However, they had experience only of the identifier and attribute techniques

5.4.3 Reasons for Documenting Traceability Information

Post-TraceabilityPre-Traceability

5 R

equi

rem

ent-

Verif

icat

ion

Req

uire

men

t-V

erifi

catio

n

Exte

nded

Pre

-Tr

acea

bilit

yE

xten

ded

Pre-

Tra

ceab

ility

Req

uire

men

t-R

equi

rem

ent

Der

ives

/Is-

Der

ived

Req

uire

men

t-R

equi

rem

ent

Der

ives

/Is-

Der

ived

O

tR

equi

rem

ent-

Req

uire

men

tTr

acea

bilit

y

Oth

er

Req

uire

men

t-R

equi

rem

ent

Tra

ceab

ility

her

Req

uire

men

t-C

ompo

nent

Req

uire

men

t-C

ompo

nent

Req.-Req. Traceability

Req

uire

men

t-R

atio

nale

Req

uire

men

t-R

atio

nale

Req

uire

men

t-So

urce

/Peo

ple

Req

uire

men

t-So

urce

/Peo

ple

4 3 2

1

0

Figure 19. The number of projects that had documented RT information.

42

For each traceability relation type, figure 19 summarizes the number of projects that documented it. Five projects were studied and thus the weight of each project is 1 unit. If traceability relations were documented systematically in project documentation, 1 unit was added to the bar of the traceability relation at hand. If, on the other hand, documenting had been so unsystematic that traceability information had to be sought in documents, only half a unit was added. For example, rationale information had to be sought in the requirements document of project A, which was written in prose. The figure does not illustrate the extent to which each traceability relation was documented in projects. It merely summarizes the number of projects that documented each relation. An extreme example is the project E, which documented extended pre-traceability information only for one requirement. This adds one unit to the extended pre-traceability bar.

In addition to the need for pre-traceability information, there existed suitable documenting techniques, e.g. the attribute technique for documenting pre-traceability information. Other reasons for high usage levels were: 1) almost non-existent prerequisites for documenting and 2) easy information gathering and maintaining compared to post-traceability information. The only prerequisite for documenting these relations was documented requirements. Not even their high quality was required because pre-traceability helps one understand requirements written unclearly. Relations were easier to gather than post-traceability relations because they do not need as much analyzing by experts. Furthermore, updating was less laborious than for post-traceability, which may contain many-to-many relations. All these factors contribute to the fact that pre-traceability relations were the first and most practiced traceability.

Extended pre-traceability was documented only once because it was regarded as additional information that could – but did not have to be documented – when there existed pieces of information that could be used. Even when only one of the interviewees had documented extended information, the other similarly considered that documenting extended pre-traceability was easy, because there often exists much informal requirements related information such as e-mails, review meetings, notes, results of feasibility studies, and market surveys [37]. These can be linked to the requirements document with the help of almost any general-purpose tool. However, there was not much experience in documenting extended pre-traceability information and there can still be some problems in documenting it more extensively. For example, problems could relate to access and change management of linked files. Moreover, the linked files are frequently unstructured, which creates problems when searching for certain information in them.

43

Low usage of requirement-requirement information can be explained by the fact that the benefits were not clearly seen and the task of analyzing relations was considered very laborious. Relations were documented for only four requirements in one project, which is not enough to see all the benefits. In addition, the interviewees were in roles of product and project manager, while the benefits would be seen in system development work. However, the interviewees saw that these traceability relations are worth documenting but not the most beneficial for the time being. There exist many reasons for this:

• Requirements were frequently stated unclearly and in different levels of detail, which makes them difficult to analyze

• Only high level customer requirements existed

• There was no experience of analyzing requirements

• Analyzing would have taken time and required the expertise of many professionals

• An RM-tool would be necessary for supporting documenting and visualizing RT information, according to the interviewees

Both requirement-component and requirement-verification were documented in one project and were similarly planned to be used in the other. The percentage of projects using these relations was low even though they were seen worth documenting and there were many suitable documenting techniques available according to the interviewees. There are two main reasons for the situation. First, analyzing requirement-component and requirement-verification relations takes time and requires expertise. Secondly, to be able to analyze the traceability relations, one needs clearly stated requirements, components, and test cases. For the time being, test cases were becoming more common but identified and clearly documented architecture components were still missing in many project.

Good Practices to Document Traceability Information
5.55.5
Requirement-Source/People Traceability
5.5.15.5.1
The source documents the origins of the requirement and indicates from where and from whom the requirement has been acquired. It can include names of customers, contracts, tenders, standards, conferences, and market areas. If there are many sources, all can be listed. In addition, e-mails, market studies, and other information which documents sources

44

can be included in the requirement’s source information. In addition it is important to mention the practitioners of the system development company, who participated in requirement creation.

The source is important because, if it is known, the correctness and importance of a requirement are more easily validated and its priority decided. This information is also useful when requirements must be changed, because it can be used to locate the customers who demanded these requirements. In addition, marketing people can benefit from RT information because it allows them to know which market segments' requirements are fulfilled by the different versions of the product. People who have participated in requirement creation are important because, if their names are known, one can get in touch with them afterwards to discuss requirement related issues. It may be a good practiceA good practice to document the titles of these people, so that it would be easy to ensure that there have been enough professionals to decide about the requirement.


GCS_UI.1 The user interface should have grid facilities.

Source: Marketing manager J. Kulmala heard this requirement from graphic designers of companies A and B when he visited them in summer 1997.

Figure 20. Source of the requirements documented in the requirements document. In this case, it contains two customers who have asked for requirement and the name and title of the company's employee.


The rationale is an explanation of why the requirement exits. It explains the reasons behind the requirement, i.e. why the requirement is needed. It can include explanations for customers’ existing and future needs, competitive advantages, internal requirements of the company, and specific market needs, for example. If there are many rationales, all can be listed. In addition, mails, market studies or other information that explains the reasons for the requirement's existence, can be included in the requirement’s rationale information.

The rationale is essential information for understanding the requirements and why they are needed. The rationale is useful for change management, analyzing, prioritizing, implementation, validation, and verification of the requirement. In addition, it helps the

45

marketing people understand the meaning of the system functionality so that they can more efficiently advertise the system to the right customers.


GCS_UI.1 The user interface should have grid facilities.

Rationale: Companies A and B do not have a specific tool to accomplish the graphic design. Thus, the system has to support placing the elements.

Source: Marketing manager J. Kulmala heard this requirement from graphic designers of companies A and B when he visited them in summer 1997.

Figure 21. Rationale of the requirement, i.e. explanation of its existence documented in the requirements document.


Traceability from components to the requirements allows the requirements that a particular/given component fulfills to be identified. This traceability relation helps the designer keep in mind the reasons that the component is designed. In addition, it helps the inspector ensure that the requirements are met by the component.

Traceability from components to the requirements can be documented in the component design document’s chapter entitled “Related Requirements” as shown in the following example.

1.3. Related Requirements

The component fulfills the following requirements:

GCS_IF.1 The system shall be able to create a statistic file that can be fed to program B as input.

GCS_IF.2 The system shall be able to accept control files created by program C

Figure 22. Requirements that the component fulfills are documented in the component design document.

46


Traceability between requirements and test cases means that 1) for a given requirement, the test cases that test it can be identified and 2) for a given test case, the requirement that it tests, can be identified. This RT information helps the tester check what the system is expected to do and ensure that all the requirements have related test cases.

Traceability between a requirement and test cases can be documented with identifiers, which are unique strings that identify system process artifacts. At its simplest, traceability can be documented by giving the test case the same identifier as the requirement it is testing. If there are many test cases that test the same requirement, the numbers can be added to test case identifiers to distinguish them from each other. An example of this follows:

Chapter 2: Test Cases for User Interface

GCS_UI.1/7 Move the graphical objects with the help of the grid facilities.

Figure 23. A test case identifier is formed from requirements identifier to document traceability between the artifacts.

The previous example can be read as saying that the test case GCS_UI.1/7 is the seventh test case that tests the requirement GCS_UI.1. The substrings of the identifiers have a logical meaning: GCS is an abbreviation of the name of the system, i.e. Great Computing System, the UI is an abbreviation of the class of the requirement, i.e. User Interface requirements, and 1 states that this is the first user interface requirement for the system.

5.6 Improvement Actions Taken

Pre-traceability information was adopted throughout the organization as a result of this work. The requirements engineering process owner, i.e. the person who was responsible for the RE -process, was assured that pre-traceability information would be worth documenting in each project. He added the pre-traceability types requirement-rationale and requirement-source/people to the requirements document standard template. In addition, he created a separate document to assist in the usage of the template, which contained instructions to document pre-traceability.

47

Post-traceability information was not taken into organization wide use. There were three main reasons for this. Firstly, in order to document post-traceability information, one must have clearly stated requirements, components, and test cases as well as time and expertise, all of which there was a lack of. Secondly, the process improvement project that was going on in the company concentrated only on the RE -phase whereas requirement-component and requirement-verification information can not be documented until the system and software design phase. The third reason was that the company had plans to invest in an RM-tool called Caliber RM (Technology Builders, Inc.), which would support documenting post-traceability information and thus also dictate how it should be documented. The company planned to invest in the tool in the first half of the year 2001, which makes the future of documenting post-traceability types uncertain.

48

6. CONCLUSIONS

Our case study suggests that pre-traceability relations are the first that companies developing systems of approximately a hundred requirements (small systems) could document and benefit from. The finding is supported by four facts. First, the practitioners of the case company saw that pre-traceability is more useful than post-traceability because many project members can benefit from it. Second, there were also good experiences of documenting pre-traceability relations using the attribute technique and even the prerequisites were practically none: not even clearly stated requirements were necessary because pre-traceability helped understand ones stated unclearly . Third, pre-traceability information was easier to gather and maintain than post-traceability information, and fourth, the pre-traceability relations were the first and most widely documented ones. Our finding supports two independent surveys by Ramesh & Edwards and Gotel & Finkelstein that suggest that requirements pre-traceability is more important than requirements post-traceability [8, 10].

We found out that extended pre-traceability can be documented in companies that do not have comprehensive requirements traceability. Extended pre-traceability can be documented selectively for a few requirements to which there exist important pieces of related information. These include e-mails, review meetings, notes, results of feasibility studies, and market surveys. Linking these to requirements is supported by many general-purpose tools. Experience in our case company suggest that there are no difficulties or prerequisites to document extended pre-traceability information. Much research has been done on/into extended pre-traceability in companies having comprehensive requirements traceability [10, 20, 38] whereas the practices developed are too cumbersome to be used in other companies [20]. No research has suggested that extended pre-traceability could similarly/additionally be documented in companies that do not have comprehensive requirements traceability practices.

Our study suggest that there can be many problems in documenting requirement-requirement relations for companies developing small systems without long term experience of requirements traceability. The problems found were that 1) requirements were frequently stated unclearly and on different levels of detail, which makes them difficult to analyze, 2) only one level of requirements was used, which makes documenting derives/is-derived futile, 3) there was no experience in analyzing requirements in the case company, 4) the analyzing task would require the time and expertise of professionals, and

49

5) an RM-tool was seen as necessary to document and visualize requirement-requirement relations. However, these problems are not mentioned in the literature. Indeed, Sommerville and Sawyer state that requirement-requirement relations should always be documented [18] and Sommerville and Kotonya consider requirement-requirement traceability the most important requirements traceability (RT) relation [5].

Our study suggests there can be many problems in documenting requirement-component and requirement-verification relations in companies developing small systems and taking the first steps towards organization wide requirements traceability. This is particularly true if a company does not have a high process maturity level. The first obstacle in documenting these post-traceability relations is the absence of clearly stated requirements, architecture components, and verification cases. Furthermore, the analysis of requirement-component and requirement-verification relations, of which there is frequently no experience, takes time and requires expertise. However, the practitioners from our case company saw that there exist important benefits that derive this traceability information as well as many techniques to document it. In their study of companies developing systems with approximately 1000 requirements, Ramesh and Jarke suggest that it is important to document requirement-component and requirement-verification relations [16] but obstacles are not discussed in the literature.

This thesis is has been the first to concentrate on requirements traceability in companies that develop systems with approximately a hundred requirements and do not have organization wide traceability practices. Thus, the goals of this thesis were set to introduce requirements traceability and to offer guidelines for documenting traceability information for such companies.

The theory part of the thesis presented RT information classes and relations in addition to techniques and tools to document traceability. It also addressed factors affecting the need for traceability, tasks to develop organization wide traceability practices, cost, and problems in practicing RT. The subject of the part based on the literature and opinions of six practitioners from the QURE project industrial partners was discussed with them.

The case study part consists of an assessment of traceability needs and good traceability practices that were developed for the case company. The assessment was conducted to discover which traceability relations would be worth documenting. It was done by interviewing two practitioners and analyzing projects' documents. Based on the results, we developed good traceability practices in co-operation with practitioners from the case company.

50

As a result of this thesis, the case company adopted pre-traceability into organization wide use. In addition, knowledge of requirements traceability has increased among QURE partner companies.

In general, companies face the challenge of defining what RT information to document to benefit their business. To support the practical work in companies, an important subject for research would be how the benefits and costs of practicing RT relates to the characteristics of the company, project, and system.

51

7. REFERENCES

[1] Hsia, P.; Davis, A.; Kung, D. 1993. Status Report: Requirements Engineering. IEEE Software. Volume 10, Issue 6, Pages. 75–79. ISSN 0740-7459.

[2] Pohl, K. 1997. Contextual Approach for Process-Integrated Tools. Proceedings of the 6th European Software Engineering Conference / 5th ACM SIGSOFT Symposium on the Foundations of Software Engineering, Zurich, 22-25 September. Springer. Pages 176-192. ISBN 3-540-63531-9.

[3] Sawyer, P. 1999. Software Requirements Engineering – An Introduction and Overview. Lancaster. Course material. Lancaster University. Online. URL: <http://www.comp.lancs.ac.uk/computing/users/sawyer/csc320/overview.htm>

[4] Sommerville, I. 1996. Software Engineering. 5th ed. Wokingham. Addison-Wesley Publishing Company. 742 Pages. ISBN: 0-201-42765-6

[5] Kotonya, G.; Sommerville, I. 1998. Requirements Engineering – Processes and Techniques. New York. John Wiley & Sons. 400 Pages. ISBN 0-4719-7208-8.

[6] Palmer, J. D. 1997. Traceability. Thayer, R. H.; Dofman, M (eds). Software Requirements Engineering. Los Alamitos. IEEE Society Press. Pages 412-422. ISBN 0-8186-7738-4.

[7] Pohl, K. 1996. PRO-ART: Enabling Requirements Pre-Traceability. Proceedings of the IEEE International Conference of Requirement Engineering, Colorado Springs, 15-18 April. IEEE. Pages 76 – 84. ISBN 0-8186-7252-8.

[8] Ramesh, B.; Edwards, M. 1993. Issues in the Development of a Requirements Traceability Model. Proceedings of the 1st International. Symposium on Requirements Engineering, San Diego, 4–6 January. IEEE Computer Society Press. Pages 256–259. ISBN 0-8186-3120-1.

[9] Ramesh, B.; Powers, T.; Stubbs, C.; Edvards, M. 1995. Implementing Requirements Traceability: A Case Study. Proceedings of the 2nd International. Symposium on Requirements Engineering, York, 27-29 March. IEEE. Pages 89–95. ISBN 0-8186-7017-7.

52

[10] Finkelstein, A.; Gotel, O. 1994. An analysis of the Requirements Traceability Problem. Proceedings of the 1st International Conference on Requirements Engineering, Colorado Springs, 18-22 April. IEEE Computer Society Press. Pages 94 – 102. ISBN 0-8186-5480-5.

[11] Ramesh, B. 1998. Factors Influencing Requirements Traceability Practice. Communication of the ACM. Volume 41, Issue 12, Pages 37-44. ISSN 0002-0782.

[12] Dömges, R.; Pohl, K. 1998. Adapting Traceability Environments to Project-specified Needs. Communication of the ACM. Volume 41, Issue 12, Pages 54-62. ISSN 0002-0782.

[13] IEEE Std. 830. 1994. IEEE Recommended Practice for Software Requirements Specifications. Software Engineering Standards Committee of the IEEE Computer Society. 22 Pages.

[14] IEEE Std. 1233. 1998. IEEE Guide for Developing System Requirements Specifications. Engineering Standards Committee of the IEEE Computer Society. 30 Pages.

[15] DoD Std. 2167A. 1988. Military standard: Defense systems software development. U.S. Department of Defense. 47 Pages.

[16] Ramesh, B.; Matthias, J. 1999. Towards Reference Models For Requirements Traceability. Aachen. ESPRIT, project 21.902 CREWS, CREWS-99-13. 53 Pages. Online. URL: <ftp://sunsite.informatik.rwth-aachen.de/pub/CREWS/CREWS-99-13.pdf>

[17] Boldyreff. C.; Burd, E. L.; Hather, R. M.; Munro, M.; Younger, E. J. 1996. Greater Understanding Through Maintainer Driven Traceability. Proceedings of 4th Workshop on Program Comprehension, Berlin, 29-31 March. IEEE. ISBN 0-8186-7283-8.

[18] Sommerville, I.; Sawyer, P. 1997. Requirements Engineering – A Good Practice Guide. 1st ed. New York. John Wiley & Sons. 404 Pages. ISBN 0-471-97444-7.

[19] Haumer, P.; Pohl, K.; Weidenhaupt, K.; Jarke, M. 1999. Improving Reviews by Extended Traceability. Proceedings of 32nd Annual Hawaii International Conference on Systems Sciences, Maui, 5-8 January. IEEE. Pages 1-10. ISBN 0-7695-0001-3.

53

[20] Gotel, O.; Finkelstein, A. 1997. Extended traceability: Results of an Industrial Case Study. Proceedings of the 3rd IEEE Symposium on Requirements Engineering, Maryland, 6-10 January. IEEE. Pages 169-178. ISBN 0-8186-7740-6.

[21] Gotel, O.; Finkelstein, A. 1995 Contribution Structures. Proceedings of the 2nd IEEE International Symposium on Requirements Engineering, York, 27-29 March. Pages 100-107. IEEE Computer Society Press. ISBN 0-8186-5480-5.

[22] Ramesh, B. 1995. Towards Requirements Traceability Models. Proceedings of the 5th International Symposium and Workshop on Systems Engineering of Computer Based Systems, Tuscon, 6-9 March. IEEE. Pages 229-232. ISBN 0-7803-2531-1.

[23] Watkins, R.; Neal, M. 1994. Why and How of Requirements Tracing. IEEE Software. Volume 11, Issue 4, Pages 104–106. ISSN 0740-7459.

[24] Corriveau, J-P. 1996. Traceability Process for Large OO Projects. Computer. Volume 29, Issue 9, Pages 63-68. ISSN 0018-9162.

[25] Curtis, S. 1994. How to Do and Use Requirements Traceability Effectively. Proceedings of the 4th INCOSE International Symposium, San Jose, 10-12 August. INCOSE. Pages 57-64.

[26] Kean, L. 1997-2000. Requirements Tracing -- An Overview. Software Technology Review. Software Engineering Institute. Online. URL: <http://www.sei.cmu.edu/str/descriptions/reqtracing_body.html>

[27] Jones, A. D.; Nallon, F. J.; York, M. D.; Simpson, J. 1995. Factors Influencing Requirement Management Toolset Selection. Proceedings of the 5th Annual International Symposium of the INCOSE, St. Louis, 22-26 July. INCOSE. Online. URL: <http://www.incose.org/lib/rmtools.html>

[28] Jones, A. D.; Kar, C. P.; van Gaasbeek, R. J; Hollenbach, F.; Bell, M.; Ellinger, S. R. 1997. Interfacing Requirements Management Tools In The Requirements Management Process - A First Look. Proceedings of the 7th Annual International Symposium of the INCOSE, Los Angeles, 3-7 August. INCOSE. Online. URL: <http://www.incose.org/rwg/97_paper_inter/inter_rmt.html>

[29] Pohl, K. 1996. Process Centered Requirements Engineering. Number 5 in Advanced Software Development Series. Willey & Sons. ISBN 0-86380-193-5.

[30] McMullen, L. W. 1998-2001 Tools Survey: Requirements Management (RM) tools. Report of INCOSE Tools Database Working Group. INCOSE. Online. URL: <http://www.incose.org/tools/tooltax.html>

http://www.incose.org/tools/tooltax.html

54

[31] McMullen, L. W. 1996-1997. Requirements Management Technology Overview. Report of INCOSE Tools Database Working Group. INCOSE. Online. URL: <http://www.incose.org/tools/reqsmgmt.html>

[32] Gabb, P. A.; Maheswaran, N.; Allwright, M. A. 1997. Requirements Management Tools Evaluation User Needs and Evaluation Criteria. Salisbury. Electronics and Surveillance Research Laboratory. AR-010-201, DSTO-GD-0139. 45 Pages. Online. URL: <http://www1.tpgi.com.au/users/agabb/Files/neecri.zip>

[33] Hermodsson, Klaus. 1998. Core functionality of requirements engineering tools. Master's Thesis. Lund University. Online. URL: <http://www.q-labs.com/pdf/RE_thesis.pdf>

[34] LaBudde, E. V. 1997. Reducing Development Time with Requirements Management. Medical Device & Diagnostic Industry. Issue 7, Page 32. Online. URL: <http://www.devicelink.com/mddi/archive/97/07/008.html>

[35] Cooke, J.; Stone, R. 1991. A Formal Development Framework and Its Use to Manage Software Production. IEE Colloquium on 'Tools and Techniques for Maintaining Traceability During Design', London, 2 December. Computing and Control Division, Professional Group C1 (Software Engineering). Digest Number: 1991/180. Pages 10/1.

[36] Antoniol, C. G.; De Lucia, A. 1998. Maintaining Traceability During Object-Oriented Software Evolution: A Case Study. Proceedings of the IEEE International Conference on Software Maintenance, Bethesda, 16-20 November. IEEE. Online. URL: <http://www.computer.org/proceedings/icsm/0016/00160211abs.htm>

[37] Lubars, M.; Potts, C.; Richter, C. 1993. A Review of the State of the Practice in Requirements Modeling. Proceedings of IEEE International Symposium on Requirements Engineering, San Diego, 4-6 January. IEEE. Pages 2-12. ISBN 0-8186-3120-1.

[38] Tryggeseth, E.; Nytro, O. 1997. Dynamic Traceability Links Supported by a System Architecture Description. Proceedings of the International Conference on Software Maintenance, Bari, 1–3 October. IEEE. ISBN 0-8186-8013-X.

http://www.q-labs.com/pdf/RE_thesis.pdf

http://www.devicelink.com/mddi/archive/97/07/008.html

http://www.computer.org/proceedings/icsm/0016/00160211abs.htm

Appendix 1. 1

INTERVIEW OF PRACTITIONERS

This appendix describes the course of the interviews the practitioners, including the questions asked, which are divided into three sections: 1) traceability classes, relations and techniques, 2) background of projects and interviewees, and 3) documenting RT information in projects.

1. Traceability Classes, Relations and Techniques

Actions:

First, I explained what the term requirements traceability means, according to the literature, after which I showed figures 2 and 3 of pre- and post-traceability and forward and backward traceability classes.

Questions:

• Would you regard pre-, post-, forward-, and backward traceability as traceability classes?

• Are you familiar with these terms and how would you explain them?

Actions:

I showed figure 4 of traceability relations.

Questions:

• Would you regard requirement-source, requirement-rationale, requirement-people, requirement-requirement, requirement-component, and requirement-verification as traceability relations?

• Are you familiar with these terms and how would you explain them?

Actions:

I showed a list of rationales and sources taken from the five projects used in the case study.

Appendix 1. 2

Questions:

• Which of these (list below) you would call requirement-source, requirement-rationale, and requirement-people information?

Customer name

Names of people working for the customer

Customer(s)

Contract

Contract name

Request of a customer

Names of several customers

Competitive advantage

Competitive advantage explained

Name of a conference

Design

Explanation of reasons behind the requirement

Future standard

Name of a future standard

Future needs

Future needs explained

Generic need

General requirement for software

Internal requirement

Name of a laboratory

More detailed requirement

Need of several customers

Some other system

Projects

Project group

Names of project people

Requirement of previous phase

Specific market needs (Brazil etc.)

Some kind of an example what the requirement means

Name of a standard

Tenders

Appendix 1. 3

Names of tenders

Technical support

People from technical support

• How would you explain the meaning of these traceability relations (requirement-source, requirement-rationale, and requirement-people)?

• How would you explain the meaning of other traceability relations (requirement-requirement, requirement-component, and requirement-verification)?

Actions:

I showed the figure 4 (traceability relations) again.

Questions:

• Are there some traceability relations missing in your company's point of view?

• Are there some traceability relations that are not relevant?

2. Background of Projects and Interviewees

Actions:

I showed a list of the five projects used in the case study.

Questions:

• How many man-months did the projects take?

• In which year did the projects start and end?

Actions:

I showed a table of documents I had studied from each project:

Appendix 1. 4

Projects Documents Name Version Date

Customer Requirements Specification Not known June 1997 System Architecture Specification Draft February 1998

A

Test Plan 1.01 March 1999 Technical Specification & Requirement Specification

1.2 February 1999 B

System Description 1.1 September 1998

C Customer Requirements 1.2 August 1999 Requirements Specification 1.0 December 1999 Component Design Document 1.0 April 2000

D

System Test Specification 0.1 January 2000 E Customer Requirements 1.1 June 2000

Questions:

• Are all relevant documents for analyzing requirements traceability present in the table?

• Are there some characteristics of the projects, which would make them not comparable with other projects as far as requirements traceability is concerned?

• Is the need for RT the same throughout the company?

• Has the need for RT remained stable in the past and do you think that it will change in the future? Will the need remain at the same level or are there issues that can decrease or increase it?

Actions:

I started asking the interviewees about their own background in system engineering.

Questions:

• What have your duties been in the company in the past and what are they now?

• How long have you been working in this company?

• How many years have you been working with system projects?

Appendix 1. 5

• In which projects (A, B, C, D, E) have you been working?

• What roles have you had in the projects?

3. Documenting Traceability Information in Projects

Actions:

I listed the traceability relations I had found in the projects documentation.

Questions:

• Have you documented other relations of requirements traceability?

• Why did you document these pieces of RT information?

• What are the benefits of documenting this information?

• Why did you not document other relations of requirements traceability?

• Did you have any problems with documenting?

• How useful are the different RT relations?

• Should RT information be documented for each requirement?

• If not, for which kinds of requirements it should be documented?

• When should RT information be documented and by whom?

• Which traceability relations are you going to document in your future projects? Why? Why not use the other relations?

• Name the techniques best suited for each traceability relation and justify your answer.