Documenting Requirements Traceability Information: A Case Study - Aalto

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, requirementcomponent, 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 System process artifacts 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 Origins of the requirements Requirements System process artifacts Backward traceability Causality Figure 3. Forward and backward traceability.

8 Pre-traceability is frequently backward traceability because the origins are generally nontangible. 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 3 5 Rationale Sources: Companies, Development environments, Standards 2 1 Requirements 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 pretraceability 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 requiremen

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