Software Technologies - Home
Traceability
Christof Ebert, Managing Director, Vector Consulting Services
MAR 11, 2014 14:14 PM
A+ A A-

Ever corrected a problem and introduced two new defects? Introduced a last-minute change and accidentally removed an important feature? Growing governance concerns demand traceability between needs and solutions to preserve work product integrity. Traceability facilitates maintainability and dramatically reduces cost of rework. However without the right methodology and technology, traceability can be highly inefficient and thus rather decrease value.

Traceability is the tangible relationship between two or more logical entities, such as work products, by means of recorded identification. The goal of traceability is to assure clean change control and provide better quality of work products, such as better consistency. A typical example is the traceability from customer requirements to test cases. It helps to ensure that key market and customer requirements are delivered with the product, even after regressions and corrections. Successful traceability means a delicate balance to have minimum governance and effectiveness – without overheads and inefficiency. Traceability is pointless and not working without optimal technology, such as automatic consistency checks, graphic trace introduction, and semantic checks across work products in the life-cycle.

We distinguish horizontal and vertical traceability. Horizontal traceability describes the relationship between work products of the same type, e.g., among requirements, across interfaces, among product components, from function to function.  "Horizontal" indicates that the traceable work products are on the same abstraction/description level, such as market requirements. Vertical traceability describes the relationship between work products which build upon each other or are derived from each other, e.g., from customer requirements to acceptance test cases, among levels of requirements, between requirements and project plans, from plans to work products, between work products and product components, etc.. "Vertical" indicates that the traceable work products are on the different abstraction and description levels, such as market requirements and software requirements.

Bidirectional traceability is traceability implemented from both ends of a relationship, e.g., from requirements to end products and from end product back to requirements. It allows to directly and efficiently following relationships between work products in both directions.

Traceability is often legally necessary to prove consistency from user and operational requirements to their implementation, validation and qualification - especially in the domain where you operate, namely systems and embedded software. For instance, standards such as IEC 61508 demand traceability, and in many liability cases it had been found the primary source to show that professional state of the practice engineering discipline had been consistently applied throughout the product life-cycle.

If used wisely it provides substantial business gains, while if done formally and stubbornly it will create overheads and demotivate engineers. I have in fact seen companies that introduced an expensive requirements tool to improve consistency and change management, and later found that their engineers actually used two tools, i.e., their previous spread-sheets and the new requirements tool, just because it was overly complex and never aligned with real engineering business needs.

In evaluating your own traceability business case and to determine how much traceability is good enough, you should look to the typical industry benefits and then map them to your specific needs and risks. Here is a brief checklist of benefits:

  • Making sure that critical customer and market requirements have been adequately designed and tested
  • Providing consistency when there are late changes either from requirements or from implementation perspective
  • Aligning effort and prioritization with value; this is the key business aspect in product management, because often valuation is too coarse and it remains unclear whether a specific feature actually provides ROI
  • Mitigating risks from a commercial perspective, because it is visible what was changed and on which basis
  • Ensuring consistency across multiple documents, from specification to technical and market documentation
  • Facilitating reuse across markets or customers
  • Providing visibility in systems engineering and complex supply chains (in fact here the support of expensive RE tools is obvious for exchange of specs and collaboration on contents / engineering change management)
  • Aligning component configurations across systems or products, such as PDM/BOM with software versions
  • Improving efficiency and reducing engineering cost because changes, corrections and updates can be much better managed across variants and versions.

This all being said, traceability comes at a cost and thus must be carefully introduced and safe-guarded. Often it is carefully specified during design and completely lost in test and maintenance of a product. We typically set up concrete rules on which types of traceability are necessary (e.g., horizontal, vertical) based on business needs, such as commercial risks, change management or external standards. Then we provide practical guidance to developers and management how they manage traceability and how they keep it up-to-date throughout the product's life. Finally we suggest simple check-points so that at milestone reviews and change control boards, these minimum rules are considered. This all being done, there is a clear ROI of traceability and concrete risk management. In good times it saves money, and in bad times it saves your life – professionally speaking.

More:

Our book "Global Software and IT" from IEEE / Wiley provides case studies on practically introducing and maintaining traceability along the life-cycle.

Read our free white papers on requirements engineering technologies and their introduction.

Author:

Dr. Christof Ebert is managing director at Vector Consulting Services.  He supports clients around the world to improve product strategy and product development and to manage organizational changes. Prior to that, he held global management positions for ten years at Alcatel-Lucent. A trusted advisor for companies around the world, member of industry boards, and adjunct professor at the University of Stuttgart and Paris, he authored several books including his most recent book “Global Software and IT” published by Wiley. He received the IEEE distinguished visitor award and is member of the Alcatel Technical Academy.

Contact him at christof.ebert@vector.com

FIRST
PREV
NEXT
LAST
Page(s):
[%= name %]
[%= createDate %]
[%= comment %]
Share this:
Please login to enter a comment:
 
RESET