Managing Your Requirements 101 – A Refresher. Part 4: What is Traceability?
AndyGurd 270001QKDH Comments (5) Visits (8185)
Note: This is the fourth post in our series of Managing Your Requirements 101. Read the first three posts here:
What is traceability? Or more specifically what is requirements traceability? Well rather than repeat what is already a good collection of definitions, I’ll refer you to http
Traceability in this context is about relationships between requirements at the same or different levels of detail, and between requirements and other lifecycle artifacts as listed above. It also extends to relationships beyond those directly involving requirements – i.e. the relationship of a defect report to a test case – this is referred to as ‘lifecycle traceability’. Traceability relationships can be of multiple types, for example:
Basic traceability establishes a relationship or link between one or more elements. Typed traceability adds the relationship type with its associated semantics (examples above). Rich traceability (ref: Requirements Engineering, Hull, Jackson & Dick, Springer, 2004) adds additional information on the traceability relationship such as the rationale explaining why a group of systems requirements satisfies a particular user requirements; or as is often the case, you can’t be 100% certain on specification or design decisions, you might document any assumptions you made in deriving a set of systems requirements from a user requirement. The rich traceability approach is particularly valuable in heavily regulated industries and safety-critical systems where audit trails of decisions made are vitally important to provide assurance and reduce risks.
Once traceability has been established there are multiple ways in which it can be viewed and reported on. Perhaps the oldest and most commonly recognized method is the traceability matrix where you can see the intersection between two sets of requirements and a check or cross shows where a link exists. This method doesn’t scale particularly well since the matrix could become very large. It’s also sometimes used for creating the links, but it’s not ideal for that either since you can typically only see a small amount of information on the requirements.
Another way to see traceability is to pick a starting point, e.g. the user requirements and display the related systems requirements alongside the user requirement they are linked to, in a traceability column. You can typically choose how much detail of the linked requirement is displayed, and you can even make it recursive, going down as many levels of requirements as you need/is practical to manage in a single view.
Graphical displays are great for getting a bigger picture view of traceability rather than immediately focusing in on the details of particular relationship. You can explore the traceability tree, zooming in/out or coll
But what about in agile development, I hear you cry? Well that could be another topic in its own right – watch this space - but relationships still exist between typical artifacts created in agile approaches (such as between product features and user stories), and I argue that as long as traceability is created ‘as you go’ and automated by tools as much as is practical, that it’s even more essential to stay informed when changes are happening rapidly and ensure you are looking at the correct versions of related artifacts.
In a follow-on post in this Requirements 101 series, I’ll take a look at what traceability can be used for – highlighting where its application can bring significant value to your projects. But for now I’ll leave you with a few resources below that I’d recommend you take a look at, and ask you to let me know if you think this post was useful (or not!) and provide any feedback or additional information using the comment function.
This is the fourth part of our six part blog posts series on basics of requirements management. Read the remaining parts here -