Requirements traceability refers to the ability to describe and follow the life of a requirement, in both forwards and backwards direction (i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases.)
[Gotel and Finkelstein 1994]
In Plain English?
Traceability is an important topic in many areas, ranging from the software industry through to the food industry. It may be easier to explain what traceability is in terms of what it helps us to do within an area that is familiar to most people – food.
Nearly every document about food regulations mentions traceability and the need to render visible part of or all of the food supply and distribution chain. First, and perhaps most importantly, traceability is required to facilitate the recall and / or withdrawal of food whenever there is an important food scare, so it is demanded for food safety. Second, there are certain properties of food that you cannot determine via inspection alone. If you are going to pay a premium for organic, you hope that someone is checking that your apple really is what it claims to be. But more critically, if you have a food allergy to nuts, where your very life depends upon avoidance, you hope that someone has checked that the food pathways of the products you eat are clear of nuts … and that some external regulatory body can assure this for you. We put a lot of trust in the food industry’s ability to demonstrate and ensure traceability. This relatively transparent process depends upon agreed policies, procedures, techniques and tools.
Exactly the same is true for the software industry, except that the problem is considered somewhat harder. This is due to the very nature of the stuff that we need to trace: the software industry deals with the tracing of abstractions (concepts and requirements) as opposed to physical materials and the properties of such – there is no obvious tangible and touchable product to pick up, package and attach tracing data to. However, traceability is mandated for safety-critical software systems (e.g., software controlling the delivery of radiation, flight control software for aircraft, etc.) where there needs to be proof that certain requirements or properties pertaining to safety have been satisfied in the software system prior to release; and it is pretty useful for many other types of software system too. Traceability is hence the mechanism we establish to follow the specification and evolution of a requirement, an unambiguous statement about what a system absolutely must do or needs to do, throughout a development project through to its eventual realization in a software product. Without this in place we are unable to validate or verify anything, and we certainly cannot manage the inevitable change. Think about the why of traceability the next time you relinquish your life to technology!
Traceability is a problem so old that it is the subject of fairy tales, legends and myths. Great myths survive because they can always be retold in a contemporary way. Consider this story of software systems development in the Near East (from [Gotel and Morris 2011]):
“Minos, chairman of CRETE, was unhappy in his marriage. As compensation, he commissioned a new software system. Immediately distracted by other matters he paid little attention to defining his requirements, changing them often and seldom reading progress reports. However, he did have sufficient experience to realize that this might result in the creation of a real monster.
Minos had engaged a brilliant engineer for the project, Daedalus, but his frustrations with his client led him to build the system in a way that only he understood and without any proper documentation. Feeling trapped, he finished the job and flew off to another firm. His son, Icarus, went with him and died on the way.
The system did eventually function, but in such a complex way that it become known as the Labyrinth. Both its users and maintainers became convinced that it did in fact contain a monster, part man-made and part machine-generated, which they named the Minotaur. The Minotaur frustrated all efforts to make the system work properly and ruined many careers.
Such was the frustration of Minos that every year he demanded a fresh team of engineers, fourteen new graduates, to ‘Get into that labyrinth, and kill that monster!’ Every year they tried to work out what the system was really supposed to do and rectify its many faults. They always became totally lost, failed completely and were fired. Eventually, one young engineer, Theseus, met Ariadne, the chairman’s daughter, who fell in love with him.
As work experience before going to university Ariadne had been an assistant to Daedalus. Occasionally, in the interest of client relations, he had explained to her exactly how he was trying to meet her father’s requirements, which ones he had abandoned, what he had added and what had become contradictory. With this knowledge, Ariadne was able to show Theseus what the Labyrinth had been intended to do and how the requirements had or had not been fulfilled. With the signs she hence laid, she could then trace its functionality forwards and backwards. It subsequently became clear that the Labyrinth had multiple entrance and exit points.
With this knowledge, and motivated by the possibility of setting up his own company with Ariadne’s support, Theseus was able to follow her trail, systematically examine the system without becoming lost in its labyrinthine constructs, discover both its specified and unspecified functions and, metaphorically speaking, slay the Minotaur and escape out of the Labyrinth. Ariadne and Theseus then went to Naxos to set up a software house. It collapsed almost immediately when Theseus absconded with its assets.”
The vision of the Center of Excellence for Software Traceability (CoEST) is to provide leadership for traceability research, education, and practice; promoting the pursuit of excellence from research idea to practice, based on a foundation of innovative, ethical, collaborative work. I have been working on a few things as an officer of the CoEST, including a Glossary of Traceability Terms, a summary of Traceability Fundamentals (see book), a View of the Traceability Future, the Traceability Grand Challenges and a Roadmap for Traceability Research. Much of this work is featured in a CoEST Technical Report.