Challenges in Requirement Traceability

Advait Moghe SMU ID#39863880 amoghe@smu.edu

1. Abstract
Traceability is one of the fundamental aspects of software modeling. Traceability refers to the completeness of the information about every step in a design process. This paper tries to shed light on the various challenges that can arise during traceability from requirement specification stage to the design stage. The main aim of this paper is to give a complete differentiation between pre-requirement specification traceability and post-requirement specification traceability and shows the various challenges faced by developers who employ these methods. Literature review is used The paper compares and contrasts various difficulties that can arise when you try to apply traceability principles while moving from the requirement specification phase to the complete design phase and shows which challenges affect the development process to the greatest extent.

Tracking and Management Documentation These problems affect the process of requirements traceability at various stages of the design process and the effects of these problems can have far reaching consequences on the overall design process.

Figure 1 : Forward and backwards traceability

2. Introduction
Requirements traceability is concerned with documenting the life of a requirement and to provide bi-directional traceability between various associated requirements. It allows users to keep track of a requirement along with any changes made to that requirement. Thus traceability allows us to keep a check on how the requirement is finally implemented into the design of the software. Requirements Traceability is concerned with documenting the relationships between requirements and other development artifacts. Though the importance and role of traceability in supporting systems development have been long recognized, there are wide variations in the quality and usefulness of the practice. Environmental, organizational, and technical factors influence the implementation of requirements traceability. Traceability is used to track the relationship between each unique product-level requirement and its source. There are two underlying terms that are the building blocks of traceability. Trace Artifact: Trace artifacts are traceable units of data. They refer to any residual data or marks of the software and systems development process that are made available to being traced. The term can apply to a single requirement, a cluster of requirements, or even to an entire requirements specification document. Trace Link: A trace link is a single association forged between two trace artifacts, one comprising the source artifact and one comprising the target artifact. The various problems and challenges faced by Requirements Traceability are: Effective bidirectional traceability Importance of requirements

3. Related Work
A lot of practical and theoretical work has been done to show the cause and effect of the various challenges of requirement traceability. The research has been carried out by many industry professionals as a means to completely understand and remedy the problems associated with traceability. These professionals took into consideration various case studies and work done by other researchers. The paper published by Orlena C Gotel & Anthony C. W. Finkelstein of the Imperial College of Science, Technology & Medicine[1] has given an excellent account of all the various problems associated with traceability and also what are the effects of these problems. Another paper written by Balasubramaniam Ramesh and Michael Edwards[2] gives a concise summary of the various challenges in the development of a requirement traceability model. Many project management tools provide facilities to model Organizational charts, role structures, work breakdown structures, work-flow, etc. The work done by many other such talented people gives us a much more in depth and clear view of the problems we face while we try to implement traceability in requirements.

4. What is Traceability?
Traceability as a general term is the "ability to chronologically interrelate the uniquely identifiable entities in a way that matters."[11] The word chronology here reflects the use of the term in the context of tracking food from farm to shop, or drugs from factory to mouth. What matters in requirements management is not a temporal evolution so much as a structural evolution: a

trace of where requirements are derived from, how they are satisfied, how they are tested, and what impact will result if they are changed. [11] Requirements Traceability is concerned with documenting the relationships between requirements and other development artifacts. Its purpose is to facilitate: The overall quality of the product under development; The understanding of product under development and its artifact The ability to manage change.[11]

Requirements traceability has been demonstrated to provide many benefits to organizations that make proper use of traceability techniques. . Important benefits from traceability can be realized in the following areas: project management, process visibility, verification and validation and maintenance

5.1. Project Management

Project estimates are made easier thanks to traceability. Traceability links allow a project manager to quickly see how many artifacts will be affected by a proposed change, thus allowing them to make a better judgment about the costs and risks associated with that change. Project managers can also utilize traceability to assist in measuring project progress. [13] Traceability also allows managers to estimate the schedule of the project during development by allowing them to know how many requirements can be traced back to artifacts by tracing requirements to code and test cases.[14]

4.1. Pre-RS and Post-RS traceability

Pre-RS traceability deals with the requirement elicitation phase of the design methodology, it allowes the designers to manage and keep a record of the source of the resource before its inclusion in the RS Post-RS traceability deals with the traceability of the requirement after it has been included into the RS, that the traceability of the requirement from being a simple requirement specification, to the software artifact, to the code to the final product. The figure below shows the relationship to Pre-RS traceability and Post-RS Traceability. [1]

5.2. Process Visibility

Another important feature of Traceability is that it provides better visibility to both the project designers and customers. The requirements can be traced back to their source by examining the contextual information which also allows the designers to check the importance of the requirement, how it was implemented and how it was tested. [14] By showing all this information to the customers the designers can assure them they are getting the product that they requested. Thus, traceability allows a designer to get an in-depth knowledge of what is going on in the design process and what changes need to be made if the product goes even a bit off track.

5.3. Verification and Validation

Traceability allows us to assess system functionality from the origin through the testing of each requirement. Traceability allows the designers to prove that the system complies with the desired requirements and whether they have been implemented correctly. To check whether the requirement has been designed into the system it should be able to be traced forward to a design artifact also, the implementation of the requirement can be validated if it can be traced forward to a code. It is impossible to verify whether a system has been correctly designed without Traceability.[13]

Figure 2: Pre-RS and Post-RS Traceability

Though they might seem similar, there are some very subtle differences in the Pre-RS and Post-RS traceability. Post-Rs traceability deals with e ability to trace requirements from, and back to, a baseline, through a succession of artifacts in which they are distributed. Changes to the baseline need to be repropagated through this chain. Pre-RS traceability deals with the ability to trace requirements to and from their originating source. Learning from where the resource came from can allow us to predict how addition of the resource to the system will affect the system and what the developers can do to seamlessly integrate the requirement into the product.[1]

5.4. Maintenance
Traceability helps with gauging the effects of regression on a system. That is, traceability helps to check what the effects of various changes and how they will affect the system. Changes to a system or its requirements can occur even after the project is completed. Traceability makes it easy to determine what requirements, design, code, and test cases need to be updated to fulfill a change request made during the software projects maintenance phase. Thus, traceability allows the find out the cost and time required to make the changes on a system. [13]

5. Importance of Traceability
Though traceability is not that glamorous a part of the design process, it is crucial to complex projects in particular and good for all types of projects. Traceability helps you track what is happening to the project requirements, how and where they are addressed by solution and it helps manage those requirements that are not going to be fulfilled.[13]

6. Challenges in Requirement Traceability

Like everything else, Traceability also has its share of problems. Traceability is plagued with various challenges and problems such as: Cost. Managing changes. Conflicting views of the various stake holders. Poor tool support.[13]

6.1. Cost
As in all the various product development methodologies, cost of development is the most important problem faced by requirement traceability. Cost encompasses all the various characteristics such as monetary cost and the time cost that will lead to an over budget or an extended production cycle. As a system grows in size and complexity, capturing the requirement traces quickly becomes complex and expensive. As expected the budget of traceability driven production is much more than a non-traceability driven approach. As the budget of a product development is always fixed at the beginning of the development cycle during the requirement elicitation and documentation phase, any major changes to the budget during the design process can hamper the development process significantly. For example, if the base on which the software is being programmed is suddenly rendered outdated because of the release of a newer and better version, then migrating the software to the newer base will lead to extra overhead.[3] Conversely, if the stakeholders decide that they no longer require certain components of the software then it might lead to either decrease in the cost of production if the component hasnt already been implemented, or might lead to increase in the cost if the component has already been implemented and completely integrated into the system. The increase in the cost will depend on how deeply the component has been integrated. The cost of making the changes can vary from a few hundred dollars to thousands of dollars. One of the methods of dealing with the high costs of traceability is to practice value based requirements tracing. Value-based requirement tracing prioritizes all of the requirements in the system, with the amount of time and effort expended on tracing each requirement depending on the priority of that requirement.[3] Though the extra cost incurred by using the requirement traceability approach will lead to a higher budget but it can also lead to the saving of much greater costs further along in the development lifecycle by allowing the developers to detect and deal with various problems early on in the development cycle.

needs to be updated whenever changes are made to the product. [3] In traceability driven approach the impact of changes and updates can be figured out by taking a look at the traceability data. But, if the data hasnt been updated after the previous change then it might lead to grossly incorrect predictions regarding the current change. Dealing with change and its impact on traceability is a difficult prospect. Some tools offer assistance with identifying the impact of change on existing traceability data; however, a lot of manual time and effort is still required to update the traceability data.[3] The only way to avoid the adverse effects of change management on requirement traceability is for the organization to maintain strict logs of the traceability changes. Only by enforcing stringent change maintenance and updating laws can a company be able to effectively utilize the practice of requirement traceability. [3]

6.3. Conflicting views of the various stakeholders

Software has a huge number of stakeholders; from the people who commissioned the product to the designer to the consumer all are in one way or the other a stakeholder in the software. Because of this each stakeholder will have his/her own additions to make the system more to the required specifications. As such, there might be some stakeholders who might disagree with the various changes the others might want to bring to the product. These different viewpoints exist primarily because current software engineering standards typically require traceability to be implemented but provide little guidance as to why and how it should be performed.[3] Those who hold a non-technical stake in the design process do not really understand the importance of the requirement traceability process and hence tend to overlook its importance in the overall system design while on the other hand project engineers familiar with the importance of traceability who will want to ensure that the traceability performed is complete and correct.[3]

6.4. Poor tool support

Various tools have been developed for the effective implementation of requirement traceability. The aim of those tools is to support establishing and maintaining traceability links between software artifacts, by proposing candidate links based on textual similarity between documents.[3] The various requirement management tools are: Accept Requirements, Acclaro DFSS version 5, Aligned elements version 1.5, Blueprint Requirements Center 2010, CORE Version 7.0, etc.[5] Multiple studies have found the level of commercial traceability tool adoption to be around 50 percent throughout industry. The majority of the remaining companies utilize manual methods and a small percentage develop their own in-house traceability tools.[5] There are various problems with both the manual and the automatic traceability tools. Traceability information can be consolidated manually using a tool called Traceability Matrix.[10] The traceability matrix is a tabular representation of the links between functional requirements and system artifacts. Though it is a great tool for requirement traceability for small and less complex software, as the scale and

6.2. Managing Changes

Traceability provides a methodical approach for managing changes by linking high-level requirements to their more specific descendants. Traceability relationships make it easy to track changes to a requirement throughout the development cycle. Though traceability helps to maintain changes in the development process, it can also lead to various problems. As changes can occur in any part of the development process, they can also take place after the product has been launched and on sale. When using traceability, the traceability data

complexity of the software increases it becomes tedious and extremely time consuming to keep track of all the requirements. Manual traceability methods are also prone to errors that are not easy to catch. Errors can arise from simple typographic mistakes, from inadvertently overlooking a portion of the traceability data. It has been observed that many of the current tools listed above are not adequate for the needs of the software engineering industry; studies have shown that existing commercial traceability tools provide only simplistic support for traceability. Also it has been observed that tools need to be implemented from the very start of the if it to be of any help in keeping track of the requirement. If a tool is suddenly implemented in between it will not be able to effectively track the requirement in either the forward or the backward direction.[3]
Table 1: A Traceability Matrix

whole, not only that, the traceability matrix which was derived before the change was made might have become obsolete now and hence needs to be scrapped and a completely new matrix needs to be created. This leads to increased cost in terms of the time required to create the new matrix. In another case if the software has neared completion and the stakeholders decide to add a new feature to the almost completed software, if the software is extremely large and complex then it the engineers will have to see what effects the implementation of the software will have on the traceability front. As we know, the more complex a software becomes the harder it becomes to effectively practice traceability, in such an environment any change to the system will exponentially increase the cost of integrating the new change in the requirement traceability document. This might affect both the time required to complete the project along with the traceability and will also increase the overall budget. Managing changes to traceability data is a very important task which needs to be done very carefully, even a small mistake can snowball into a great catastrophe if the traceability data is misaligned.

7.2. Effect of conflicting views on cost

As the number of stakeholders increases the external input into the product development also increases. Each stakeholder might want the development to run according to them. Hence, each stakeholder will have his/her own additions to the product. These excessive additions might lead to a deadlock between two or more stakeholders which might want to have their requirement added onto the system at the cost of both time and money. The longer the project implementation is drawn out the more cost of the project will increase. In terms of traceability it means that it will take longer to create the tracing document and hence add to the cost of production. Also those stakeholders who do not hold much regard for traceability will find it unnecessary to keep an account of requirement traceability which will lead to increased overhead when in the future the developers need to make certain changes to the system. Since they will not have any way to trace the requirements to the code and vice versa, this will lead to increased overhead as new methods of incorporating the changes will have to be implemented. In this way, conflicting views can indirectly increase cost of traceability.

As shown above, there are many problems which affect the process of requirement traceability. But this paper will further prove that the most important and major factor which most adversely affects the process of requirement traceability is that of the cost of requirement traceability. This is proved in the following sections.

7. Effects on Cost
Cost in this case the cost in terms of both time and money. Requirement traceability is a very sensitive and time consuming process. Each and every step in this process is calculated and given a lot of thought before implementation. Hence any change in the process can either have a major or a minor change in the cost, i.e. the cost might increase drastically or marginally. In very few cases the cost of traceability decreases during the design process.

7.1. Effect of changes on cost

As discussed earlier, changes can take place at any time in the development process. That means that changes can occur either in the start, middle or end of the development lifecycle. There are also changes that might take place after the product has been released. These changes can adversely affect the end product. As the definition of traceability states, traceability is the practice of keeping track of how the various requirements get converted into software artifacts and how these artifacts are later converted to code. Now, consider a situation where a certain feature has been implemented and its traceability matrix been derived and tested, now either the developer or the manager finds a flaw that had been overlooked during the design process which now needs to be corrected. Though the change my be miniscule it might have far reaching effects on the entire system as a

7.3. Effect of poor tool support on cost

After cost the second most important problem faced by traceability is that of poor tool support. Currently there exists no tool that can completely guarantee effect generation of tracing data for the software. Also in some cases the use of tools to generate traceability data might end up increasing the cost of production. Manual tools such as the Traceability Matrix discussed earlier are a major contributor to the increased cost. These matrices take a lot of time to make and implement in practice, also even the slightest mistake in the matrix can lead to a major flaw in the system, and rectifying the flaw may require more money, time and effort. Such manual methods are also vulnerable to changes in a system. If changes occur to any

elements captured in the traceability data, the affected portions of the traceability data must be updated manually, thus leading to increasing the time spent in making the desired changes. As for automated tools for requirement tracking, it is important to start using the tools right from the inception of the development process. If not implemented correctly the tools might hamper rather than facilitate traceability. Also the rights to use these automated tools also cost a few thousands of dollars with the addition of the yearly maintenance fee. These tools tend to do more harm than good if not used with utmost precision and hence add to the overall budget of the software. The figure below shows how cost varied based on various tools.

Traceability Strategy: Various tools, planning models and investment simulators can be used to illustrate the business impact of spend decisions on traceability solution options.[13] Traceability Creation and Maintenance: This is the practice to only create traceability when it is needed and each trace will be created in the cheapest way possible to serve its intended purpose. Just enough traceability will always be maintained, and each trace will be maintained to continue to serve its intended purpose. Once the traces have outlived their usefulness they will be discarded so as to avoid any extra maintenance costs. [13] Traceability Use: The main aim of traceability is to support the end user in his/her tasks, to this effect the cost of establishing traceability will only be incurred at the point of end use and it will based on the benefits obtained. [13] When a perfect middle ground between maintainability and creation of traceability early and maintainability on demand is attained, so that the time, effort and money that are spent on establishing traceability come in balance with the resource specification and required quality in the end result. The entire research methodology for requirement traceability is kept until the end of the project lifecycle so that any mistakes made during the process are cataloged for future reference so that the cost and effectiveness of various traceability techniques, methods and tools are known and improved upon.[10] Those companies that practice traceability consult the Traceability Body of Knowledge (TBOK) to understand the cost-effectiveness of existing and new techniques, methods and tools when making traceability strategy decisions. Tracking the returns on the investments on traceability allows the producers to know where costs can be saved and which areas need more support of traceability.

Figure 3: Effect of tools on cost

9. Conclusion
As shown above it can be inferred that though cost exponentially increases without tools that does not mean that even with the use of tools the cost decreases, only the perfect tracing tool can guarantee perfect tracing data that keeps the cost in check. But, currently such a tool does not exist and hence we have to compromise on either the cost or the quality of requirement tracing data. As we can see from the data presented above that all the various challenges that mar the deployment of traceability, viz Cost, Change management, stakeholder views and poor tool support, either directly or indirectly affect the cost of the traceability process thus making cost the biggest deciding factor in the implementation of requirement traceability. These challenges lead many organizations to implement only as much traceability as is required by their customers. As we have seen the overall budget of a company which employs traceability tends to be significantly more than the ones that do not, but this saves additional costs that will be spent once problems are found in the system and changes need to be incorporated. Hence, though cost of production is increased the end result is much more refined and the returns are very good. Since traceability has such a far reaching effect on the final outcome of the product that it is very important to find cost effective ways to manage and implement requirement traceability Currently various new novel and cost effective ways are being developed to implement traceability, The use of manual and automatic tools to record traceability data have helped to reduce costs incurred, but it is not completely possible to know which tools will deliver the most in-depth analysis and which will completely overturn the process. Ignorance is another reason why the implementation of traceability is still facing problems in practice, and hence untrained engineers

8. Overcoming the Challenges

Complete traceability is often impractical, expensive to establish and not always necessary. Too much time can be invested in establishing traceability that may never be used or useful on a project. As it is difficult to know in how much depth should traceability be implemented for each project situation because these situations themselves are often inaccurately expressed. There can also be delays in implementing traceability because one does the largest costs are incurred during the inception of traceability which also makes traceability a unfavorable practice on small projects as it leads to increase in costs which the management might find unnecessary. [3] Also, the developers are not able to completely estimate the cost of traceability during the entire development lifecycle. Because of this it is not possible to completely find out what the return on the investment will be.[9] There are many ways to address these problems, some of them are described below:

who do not know how to correctly use traceability and traceability tools drive up the cost of the design process when using traceability. The solution simply involves creating cost-effective traceability tools and methodologies that improve upon the design and feature set of currently available tools. This would serve to greatly improve the practice of traceability in the software engineering industry.[13] Requirements Traceability problems will persist when accurate responsibility cannot be located and these individuals cannot be accessed for the informal communication often necessary to deal with them. The remedy is to provide a continuously up to date picture which promotes and instigates these activities. [1] Though there still exists the problem that there is no perfect tool that can be used to assist in traceability, various third party companies are still trying to create tools that are making the concept of a perfect tracing tool into a reality. The time may not be far off that all companies will start employing tractability techniques in all their design methodologies in all the products no matter the size or complexity of the product.

12. http://en.wikipedia.org/wiki/Requirements_traceabilit y 13. The Grand Challenge of Traceability, Orlena C. Gotel. 14. Traceability Fundamentals, Orlena Gotel, Jane Cleland-Huang, Jane Huffman Hayes, Andrea Zisman, Alexander Egyed, Paul Grnbacher, Alex Dekhtyar, Giuliano Antoniol, Jonathan Maletic and Patrick Mder 15. Assessing traceability of software engineering artifact, Senthil Karthikeyan Sundaram, Jane Huffman Hayes, Alex Dekhtyar, E. Ashlee Holbrook

10. References
1. An Analysis of the Requirements Traceability Problem, Orlena C. Gotel & Anthony C. W. Finkelstein. Issues in the Development of a Requirements Traceability Model. Balasubramaniam Ramesh & Michael Edwards. Why Software Requirements traceability remains a challenge, Andrew Kennenburg, Dr. Hossein Saiedian Requirement decomposition and traceability. David P. Kirkman INCOSE(International Engineering), ORMS. Council on Systems

2.

3.

4.

5.

6.

A heterogeneous solution for improving the return on investment of requirements traceability. ClelandHuang, J.; Zemont, G.; Lukasik, W. Analyzing and Systematizing Current Traceability Schemas. Angelina Espinoza; Pedro P. Alarcon; Juan Garbajosa Overcoming the Traceability Benefit Problem. Paul Arkley, Steve Riddle Software and Systems Traceability. Jane ClelandHuang, Orlena Gotel and Andrea Zisman Hull, Elizabeth; Jackson,

7.

8. 9.

10. Advanced Traceability. Kenneth; Dick, Jeremy

11. Requirements engineering. Hull, Elizabeth; Jackson, Ken; Dick, Jeremy