An internationally renowned expert in the field of requirements engineering was recently asked the following at an event: “In your opinion how should one deal with user stories – client requirements in agile projects – once they have been realized?” His answer: “Once they are completed throw them out.” Everyone shifted around in their seats, then another question came from the audience: “When will traceability finally become a reality?” Counter question by the speaker: “What do you want traceability for?” Indignant heckling from the audience: “Without it we’ll never achieve a higher CMMI or SPICE level.” “Then we can forget about ISO certification.” The speaker remained calm. “How much traceability have you achieved in your projects?” he asked. Silence fell on the room like a blanket. Obviously there is a massive gap between what people theoretically want, indeed, what they consider absolutely necessary and what actually gets practiced in projects.
Why are theory and practice so far apart when it comes to traceability? Why do people have strong reservations, especially in agile projects, regarding the usefulness and costs of traceability? And how much traceability do we actually need?
Traceability – what is it exactly?
When people talk about traceability, often three terms have been mixed together. Admittedly they are quite similar, but let’s try to disentangle them.
Compliance is a term with many different facets and can be understood as the ability to look back and ascertain whether processes and standards have been kept. In regulated branches such as the automobile sector compliance is a central aspect of and prerequisite for successful automotive SPICE assessments. Audit security refers the traceability of the artefacts that have come about during the development process. They are firmly rooted in process standards such as the V model XT. Creating audit security is a topic within version and configuration management.
Traceability refers to our understanding of relationships between artefacts in the development process. According to ISO/IEC/IEEE 24765:2010 traceability is defined as: “A discernable association among two or more logical entities, such as requirements, system elements, verifications and tasks.” The guide to Business Analysis Body of Knowledge BABOK v3 concretizes this definition for special cases in requirements traceability as follows: “The ability to track relationships between sets of requirements and designs from the original stakeholder needed for the actual implemented solution.”
According to BABOK v3 it is possible to trace the relationship between requirements and their source, the stakeholders and their needs, in both directions. This kind of traceability is called pre-requirements traceability. Similarly, it should be possible to trace the relationships in both directions among the draft, code and the tests. This is known as post-requirements traceability. Both forms of requirements traceability help to answer a number of questions in the course of the development process.
Pre and post requirements traceability are not the only forms of traceability. It is possible for there to be both inter- and intra-artefact relationships. That’s why BABOK distinguishes, for example, between business, stakeholder and solution requirements that are derived from each other. Requirements in the requirements and specifications documents appear to be duty documents or IEEE according to software requirements. The traceability of the internal relationships and the relationships with their documentation is known as inner traceability.
Requirements are realized during the development process. That creates relationships between requirements and tasks in the project planning. It becomes possible to trace the development with the help of these relationships. This form of traceability is called requirements-to-task traceability.
What is traceability used for?
The different forms of requirements traceability support four analysis steps:
- The impact analysis – which requirements/artefacts will be affected by changes?
- Origin analysis – why is there a requirement/artefact?
- Comprehensiveness analysis – have all the requirements/artefacts been taken into account for a total solution?
- Performance value analysis – how will the work continue now?
You will be able to plan better and identify risks more effectively if you know the impact of intended changes. It makes it easier to estimate your maintenance costs. The transparent path between requirements and tests makes it easier to assess the progress of the project. The traceability of requirements back to their source helps in validating requirements (“are we creating the right product?”) and in creating stakeholder satisfaction. The traceability of decisions and decision making paths is a prerequisite for audits. You would make a giant leap towards verifying solutions and maintaining high quality standards if you can prove that all the requirements have been taken into account in the solution and if they have been defined for all requirements tests. In short: requirements traceability is of vital importance for projects. The question then remains: how do you set up requirements traceability at a reasonable cost?
The traceability matrix – a useful instrument?
One way to create traceability is to explicitly document the relationships between requirements internally and to other development artefacts by creating and maintaining a traceability matrix. That’s why there is a large number of excel templates online.
If you’ve ever tried to manually maintain a traceability matrix – from the stakeholders’ needs right up until the test – then you’ll probably agree with the following: “Requirements traceability probably is one of the most valuable things people almost never do.”
Maintaining a traceability matrix is time consuming and prone to errors. Even if the matrix is created by computers, a large organizational and operative effort is needed to complete it, keep it up to date and accomplish the versioning.
Why is traceability difficult to achieve within agile projects?
Many people have significant reservations with regards to the cost benefit relationship in the context of traceability. The typical critique people level is: traceability in the form of the explicit documentation of the relationships between internal requirements and other development artefacts:
- leads to more artefacts that are not necessarily part of the delivery products or up-front activities for the creation, maintenance and administration of these artefacts,
- makes changes that are needed in agile projects more difficult,
- increases the degree of “waste” involved in finding information,
- slows down the team’s productivity.
Traceability needs to be livable in order for it to be accepted in agile project requirements. How can you do that? First of all: traceability is not the same thing as a traceability matrix. Traceability is a desirable property that can also be created by other means. How can you explicitly skip the documentation involved in traceability as in the traceability matrix and manage to create a lean requirements traceability?
The Steps towards Lean Requirements Traceability
Lean requirements traceability basically can be understood as the maximum amount of traceability that can be achieved at the lowest cost. Three steps are necessary to achieve this.
Step 1: Establishing which kind of requirements traceability should be considered.
Decide if the requirements-to-activity traceability is necessary for your project.
Is any of the following information important to you: the release, the productivity or the iteration in which a requirement is planned, the human resources required, the process involved and the effort expended in the planning?
Our experience: We have decided to create and maintain the relationship between the requirements (user stories) and the productivity (releases and sprints) with the help of tools. These relationships give us the ability, using the corresponding tools, to distinguish the release costs from the requirements costs. They also make it possible to view development progress, i.e. the ratio of planned requirements vs the already met requirement according to the principles of agile earned value management.
Decide if the requirement-to-document – that is, this special form of inner traceability, is necessary.
Our experience: It may surprise you, but we have decided it is not necessary. The reason: requirements documentation that we publish always gets generated in the current development phase and is added to the version afterwards. That eliminates the necessity of keeping track of which documents are affected by the requirement, stakeholder description, use case or test case etc.
The pre/post requirements traceability remains.
In the pre/post requirements traceability it is not important whether you need them in your projects, but how much you need and what resources you require to record them. That is the content of the second step of the approach.
Step 2: Establishing which pre/post requirements traces need to be created.
The questions about recording pre/post requirements lead to another question: how much software engineering needs to happen in your projects? What does traceability have to do with software engineering? A peek into the Unified Modeling Language (UML), the current industry standard in software engineering procedures, makes the connection clear: the UML identifies dependency relationships. One of them is the trace-relationship. It states that the change in any element needs to be taken into account in a dependent element.
It is very interesting to look into the Systems Modeling Language (SysML), an extension of the UML. SysML refers to the following:
- Satisfy-relationships between elements and requirements and
- Verify-relationships between test cases and requirements
Once it has been modeled, this relationship can be used for post-requirements traceability. SysML refers to the following:
- Derive-relationships between requirements
- Contains-requirements between requirements
- Refine-requirements between elements and requirements.
All three are useful for the inner traceability of requirements. By the way, there is a high correlation between the SysML and the Business Analyze Standard BABOK v3, that identifies the derive, depends, satisfy and validate relationships as special forms of the trace relationship.
SysML contains the requirements diagram which allows you to model all the different kinds of traces. Requirements are part of the requirements diagrams, as are their relationships with stakeholders and their development artefacts. If you would like to change a requirement and would like to know which other requirements and artefacts may be affected by the change, then you can determine these elements using your model information.
We are close to arriving at an answer to the question, what does traceability have to do with software engineering? Traces are produced automatically when UML/SysML are used in modeling – they arise during the normal model based development work, so you don’t have to create and maintain additional artefacts like the traceability matrix. Repository based ALM or software engineering tools save information about the modeled relationships and allow you to evaluate and trace them.
Let’s recap: models – especially the requirements diagram- help us with inner and post requirements traceability. And what about pre-requirements?
Unfortunately there is no standardized notation used in modeling business needs and stakeholder goals as well as the requirements derived from them. We recommend a simple, easy to understand way of accomplishing needs and goals modeling: goal diagrams represented as and/or graphs. That allows you to:
- refine the stakeholder needs/goals or to create alternatives
- make stakeholder goal conflicts visible
- derive concrete requirements from goals.
In this way many traces can be created for the pre-requirements traceability that can lead to the source of a requirement. One more step is necessary to make sure that the approach remains balanced.
Step 3: Defining the degree of detail artefacts are to be traced
Our experience: we have decided to place traces requirements on the same level as the models in which the component is realized. We leave out traceability on the code level. Why? We describe the system architecture with package diagrams from the UML. A system component consists of scientific models, out of which we generate model transformations on a large scale. We develop our software with models. That is sufficient to record the relationship between requirements and components as well as between requirements and model elements like classes. These relationships are no longer modeled graphically but through the setting of references.
Lean traceability – summarized
Lean traceability can be summarized as follows: as much traceability as is necessary at the lowest possible cost. The requirement is that you establish, once off, how much traceability you need for your project, program or organization. A large document like a traceability matrix, that illustrates all the dependencies, whether they be automatically or manually generated – is only useful to a limited extent. What is helpful is the possibility of tracing situationally. This is not perceived as an added effort and using relationships between artefacts in real situations, in order to, for example, measure the impact of changes, is also certainly not generally viewed as a waste of time. That kind of activity is a daily part of every developer’s work.
 BABOK® is a copyrighted brand of the International Institute of Business Analysis. You can download the BABOK guide here: http://www.iiba.org/babok-guide.aspx