The benefits of an appropriate traceability approach are widely accepted [Go- tel et al., 2012c]. However, empirical studies show that implementing a successful and cost-effective traceability solution is still a challenge and is usually failed in many contexts [Egyed et al., 2007]. Many researchers have investigated the difficulties or problems which hinder the adoption of trace- ability in practice, considering this issue from different points of view. Some of them address difficulties associated with traceability activities, while oth- ers are interested in the shortcomings of supporting technologies. There are also studies considering the cost-benefit and return on investment (ROI) of a traceability solution in general.
Additionally, [Winkler and Pilgrim, 2010], in a comprehensive survey of traceability, classify the factors which hinder the adoption of traceability in practice into four groups.
– Natural factors; attributed to the imprecise and incomplete nature of traceability (e.g. no common understanding of a complete and well- defined traceability metamodel)
– Technical factors; related to enabling technologies for a traceability so- lution (e.g. lack of integration with other development activities/tools and automated trace recording)
– Economical factors; concerning the Return on Investment (ROI) of traceability
– Social factors; attributed to the inevitable role of human in traceability activities (e.g. in trace recording)
Considering this thorough survey on the use of traceability in practice and also other researches focusing on specific aspect of traceability, we investi- gate current difficulties and challenges from four viewpoints: definition, fun- damental characteristics, enabling techniques (traceability activities), and practicality or applicability (implementing a solution).
2.1.5.1 Definition
This viewpoint covers those difficulties which happen because of ambigu- ous and imprecise definitions in the traceability domain regardless of how traceability is implemented in a project. These difficulties are similar to the natural factors defined by [Winkler and Pilgrim, 2010]. One of the factors affecting the adoption of traceability in practice is the lack of a commonly accepted definition of traceability and inconsistency in the use of traceability terminology and concepts [Gotel et al., 2012b]. Current standards provide little guidance and the models and mechanisms vary to a large degree and are often poorly understood, so traceability in many organizations is haphaz- ard [Ramesh and Jarke, 2001]. Addressing this issue, [Gotel et al., 2012b] provide a resource for traceability fundamentals along with a glossary of traceability terms and concepts. Such work will provide a common view of traceability and help the research community and industry to structure and understand problems better.
Additionally, researchers highlight the need for a standard way of speci- fying a traceability metamodel, mainly to support interoperability between traceability solutions, and hence, propose reference models or formal spec- ification of traceability metamodels (at the metametamodel level), such as [Ramesh and Jarke, 2001; Limon and Garbajosa, 2005; Espinoza et al., 2006] (introduced in Section 2.1.3.2).
2.1.5.2 Fundamental Characteristics
We argue that there are some challenges which are inherent to traceability and which cannot be eliminated completely. To address these challenges, a traceability approach has to convince users of the benefits of having trace- ability and control or dominate the negative effects of them in some way.
Fundamentally, supporting traceability requires substantial effort to cre- ate and maintain traceability relations. Therefore, traceability is always a costly activity and it is not easy to measure the return on investment (ROI) of traceability [Palmer, 1999]. A practical solution needs to provide a less effort-intensive approach for creating and updating trace relations or in- crease the benefits of traceability to compensate its additional costs. In this context, a part of current research focuses on techniques to create, main- tain, and use traces, and try to improve them. Such studies are discussed in Section 2.1.5.3.
On the other hand, some researchers address the additional cost of trace- ability at the higher level, focusing on the overarching strategy which drives traceability activities. They provide guidelines and standard templates sup- porting the whole planning activity for traceability. The primary idea behind these approaches is to tailor and customise a traceability solution (and con- sequently traceability activities) to the needs of a particular project. This
approach has been acknowledged in various contexts.
[D¨omges and Pohl, 1998; Pinheiro, 2003] note that traceability meth- ods and tools have to be easily customised in order to lower traceability costs. [M¨ader et al., 2009a] advocate defining traceability metamodels specif- ically for a project at hand and propose practical guidelines accordingly. [Aizenbud-Reshef et al., 2005] state that an optimal traceability metamodel is the one that is customisable and extensible by the user. [Heindl and Biffl, 2005] suggest value-based requirements traceability (VBRT) to iden- tify which traces are more important and valuable than others. Similarly, [Egyed et al., 2005] propose a value-based approach to assist engineers into deciding which traces are needed, when they are needed and at what level of precision, completeness and correctness. They show that the approach reduces the cost of traceability by avoiding unnecessary trace recovery and maintenance. Cost of traceability can also be reduced by tailoring the preci- sion, completeness and correctness of trace links depending on their intended usage. In a related work, [Egyed et al., 2007] conducted three case studies to examine the trade-off between these three attributes and traceability cost. The results of these case studies show that cost and effort of traceability can be reduced by reducing the granularity of the traceable artefacts.
[Lago et al., 2009] present a scoped approach to traceability instead of automating tracing, or representing all possible traces. They scope the traces to be maintained to the activities stakeholders must carry out. They define core traceability paths, consisting of essential traceability links required to support the activities. They illustrate the approach through two examples: product derivation in software product lines, and release planning in software process management.
[Ingram and Riddle, 2012] focus on cost as the key reason to neglect or abandon traceability efforts, and identify key issues to maximise the cost- benefit of a traceability solution (optimal scenario). They introduce three strategies to minimise the cost of gathering trace data: establishing trace- ability goals, trace creation and evolution, and using automated tools. More- over, they state that traceability data should be at an ”acceptable quality” in order to reach the cost-benefit of traceability. The quality of data is defined as a function of the granularity, recall and precision, and level of coverage of trace links, which are specified regarding the given project.
On the other hand, humans inherently play an important role in captur- ing and maintaining traceability as traceability practices can never be fully automated [Egyed and Gr¨unbacher, 2005]. Even in the relatively formal context of model driven software development, fully automated establish- ing and maintaining traceability links is still an issue [Winkler and Pilgrim, 2010]. In this context, it is important to motivate users and convince them of the benefits of having traceability. Empirical studies show that direct, immediate, and short-term benefit motivate users to carry out traceabil- ity activities [Alexander, 2002; Ebner and Kaindl, 2002; Arkley and Riddle,
2005].
Additionally, [Hoffmann et al., 2004] argue that traceability acceptance will increase if supporting tools are made more usable. [Arkley and Riddle, 2005] also indicate that traceability activities should be designed in a way that can be integrated with the way users work. Otherwise, they would be imposed on them and consequently would be discarded. Moreover, [Hayes and Dekhtyar, 2005] argue that users do not trust the traces produced by automated traceability methods and many times they make the results of such methods worst, which can happen because of missing motivation or lack of understanding of traceability.
2.1.5.3 Enabling Techniques
These challenges are related to techniques and methods used to create, main- tain, and use traces in a project. The ultimate goal of the related research is to improve the efficiency, usability, or productivity of traceability activities in various ways. Some of them try to minimise manual activities (human interaction) and so to automate traceability activities as much as possible, for example through using IR- and rule-based methods for trace recovery. Other studies are interested in enhancing the recall and precision of traces. Finally, several efforts have been spent on improving tool support for trace- ability. The current and ongoing research in this context were introduced, and their strengths and weaknesses were discussed in Section 2.1.3.
2.1.5.4 Practicality and Applicability
This viewpoint focuses on problems which are related to the practicality or applicability of a traceability approach; when a traceability solution is implemented and used.
Experimental studies of existing tracing approaches in practice, observe that usually the traceability metamodel is undetermined [Von Knethen and Paech, 2002]. It has not been precisely defined what artefacts are traced and what trace links are captured. Also, selecting the right level of granularity for traceability is a challenge [Kirova et al., 2008]. It is difficult to determine what level of granularity is appropriate and useful for a given project. The granularity varies depending on the usage scenario. For example if there is a lot of in-team knowledge and experience in architecting or designing specific products within the domains, there can be less emphasis on requirements to design traceability, hence a higher level of granularity will be acceptable. So, support for selecting granularity, quality, and completeness of the traceabil- ity metamodel is essential. [M¨ader et al., 2009a] also acknowledge the lack of practical guidance on how to design, implement, and use project-specific traceability metamodels as one the main reasons why such metamodels are not used in practice, though they are considered and discussed as the core
element of any traceability solution.
Additionally, tracing approaches do not provide sufficient and clear pro- cess support [Von Knethen and Paech, 2002; Winkler and Pilgrim, 2010]. Generally, traceability is not directly supported by software development process [Ramsin and Paige, 2008]. Therefore, tracing approaches have to clearly specify when and how traceability activities are actually carried out during software development.
Insufficient tool support has been identified as a factor which hinders the adoption of traceability in practice [Von Knethen and Paech, 2002; Kirova et al., 2008; Winkler and Pilgrim, 2010]. Studies show that automated trace creation and maintenance are essential in adopting a traceability solution, as recording and using traces manually are time-consuming and error-prone tasks. The studies also highlight the lack of interoperability between tools. In industry, there is a need for a comprehensive approach to traceability which considers interoperability between requirements management tools, modelling tools, integrated development environments (IDEs), and commu- nication tools. The tooling support could implement standardized interfaces or would support a common trace data format.