What is requirements tracing in a project and why is it important?
My name is Egor Maryushko, I am a solutions architect at Rostelecom Information Technologies. A year ago, at the “Game of Analysis” conference, I spoke in detail about the importance and features of requirements tracing in a project. This article is based on my report and will help you quickly understand the issue of requirements tracing and its implementation in everyday work. You can listen to and watch the report itself here.
A little about myself: in IT since 2014, was a business expert, business and systems analyst, head of business and systems analysis departments, solutions architect, teach courses on business and systems analysis. I run the telegram channel “Education in BA, SA, Architecture” (BA_SA_Arch_edu).
What is requirement tracing?
Requirements Tracing – is the ability to relate any element of a project to another related element of the project, especially one that is relevant to the technical requirements of the project. This is the official definition from RUP (Rational Unified Process).
Why do you need requirements tracing in a project?
The goals of requirements tracing are:
improving the quality of analysis of the impact of changes on the product, the so-called impact analysis;
improving the quality of the product itself due to the fact that we understand the relationships and how changes affect the product;
reduction of labor costs.
What are the types of requirements tracing?
The first type of tracing is verticali.e. from the general/main to the specific/detailed. This is the principle of hierarchy, when at the top there are the main business goals of the project, below – business rules, user requirements, use cases, system requirements. So, from top to bottom we can trace the connections of the high-level requirements to the most detailed ones. And if we change a detailed requirement, we can see if our new requirement fits into the high-level ones. And vice versa, when we change a high-level requirement, through tracing we will find all the detailed requirements that it will affect. Such tracing allows us not to forget or lose anything, otherwise we can get a defect when we roll out the revision to production, and this will affect the quality of our product.
The second type of tracing is horizontalor cross-tracing, when we make connections of the same level. This is an example of a social network, when through social networks our friends are all connected to each other in one way or another. For example, if we have many use cases in the documentation, they can intersect with each other and be connected. When we change one use case, thanks to cross-tracing we can find what other use cases will change in our project, thus tracking the impact on them and taking into account the changes in them.
What can be traced?
In fact, according to statistics, it is not the requirements themselves that are traced more often, but the project artifacts in which they are mentioned. Through any task tracker, we can see the project, then from the project we look at its features, and from the features we look at the tasks. This is also tracing.
This way, we can understand what the task is, what project it belongs to, and what features the project has. If we take into account all of our features for the project, including planned ones, we form a digital backlog.
Next, for each feature, we can see the tasks associated with it. Thus, tracing project artifacts allows you to see the list of functionalities and tasks, and evaluate the progress of the project.
This may seem more like task decomposition than requirements tracing, but one does not cancel the other. Decomposition itself implies tracing from the general to the specific.
Let's look at another example that is more related to analytics and directly to requirements. Its main idea is the connection of two requirement registers, when there are artifacts of the first register and artifacts of the second register and it is necessary to make a mapping between them. Mapping through tracing will greatly facilitate our search and understanding of connections in further work.
Where can mapping (tracing) of two registries be applied?
First example – this is when we have had a cumbersome business process for a long time, we are constantly refining and improving it. To see what improvements have already been made to this business process, what are planned, and what are already in progress, we can take artifacts, conceptual solutions, technical specifications, specifications describing its improvements and link them to this business process. Thus, we will immediately see a list of business process improvements and their status. Or we look at the specification and see what business process this improvement relates to. All this seems obvious, but when you have a huge federal-scale project, a team of 300+ people and hundreds of specifications, it is quite easy to get confused.
Second example – these are requests and the requirements themselves. We have projects where business customers give quite general requests for revision. These requests rarely fit entirely into one requirement; most likely, they will fall apart into several requirements. In the same way, we map the initial requests to the final requirements for further implementation. Thus, the customer will always understand that his request is covered by certain requirements. And the development team understands from which request this requirement was born.
Third example – these are functions and components. Now we live in the age of microservices, services, component-oriented systems. It cannot be said that monoliths will leave our lives forever, but the focus is shifting from them to other architectural options. Each component has a certain set of functions, and we can map these functions to components. This is also one of the options for using the connection between two artifact registries.
The relationship between two registers is applicable to any task where you need to see how one relates to another.
Fourth example (the most hardcore approach to requirements tracing) is when we are no longer limited to two registers, but make connections between all possible requirements and try to cover our product or project with connections in as much detail as possible.
It is quite labor-intensive, but we are guaranteed to understand how our information system exists and works in terms of requirements.
Use case (use case, user scenario), as practice has shown, is one of the central units in the requirements, relative to which everything else can be linked: business objects, mockups through which this use case is implemented, printed forms that are used within the use case, atomic user stories, business rules. You can map the use case and API interfaces through which the back end is accessed. You can map business objects to the system model of the database – what tables and attributes there are. The scope for creativity is limitless. The only question is in the labor costs and whether you will be given time to do all this.
Where to start implementing requirements tracing?
I have implemented traceability, documentation structure and requirements management process in three companies. You always need to start with what causes the biggest pain. In one of the projects, the biggest pain point for us was a situation where there was a list of business processes and thousands of specifications, and we did not understand which specifications modified this business process, on what basis we implemented this business process at all. We created a business process inventory and started mapping new, current or in-progress artifacts to these business processes.
There was an experience of implementing universal tracing, when we traced everything to everything. It was quite labor-intensive, but allowed us to quickly develop the system to a large scale. It should be taken into account that the system was created from scratch. That is, when you create something from scratch, then universal tracing can be easily implemented. When you understand that in some time you will have a huge “starship”, then it is better to lay such tracing at the very beginning. If the “starship” already exists, but it is not clear how it works, then you need to start putting it in order piece by piece.
How to perform tracing in an existing “starship”: from below, from artifacts, or from above, from business processes?
You need to start from the problem. Look at all the variety of artifacts and understand what trips people up the most. It is not necessary to start with a user story or a use case. You may not have a user story or use case at all, or you do not document the API. Only the project team can understand where the project's pain point is. Retro is very helpful in identifying such points. If you have never done it before, try to do it and discuss which artifacts you would like to tidy up at least.
When to start implementing requirements tracing?
Below is a graph where the blue line shows a project without requirements tracing, and the red line shows the curve where requirements tracing is present, and the boundary is marked – approximately 100 artifacts in the project.
If you have a small project with less than 100 artifacts, then there is probably no point in wasting time on making some connections and tracing. But as soon as your project starts to grow, and there are hundreds, thousands of requirements and artifacts in it, then the labor costs to find the necessary artifact, conduct an impact analysis, understand the project will grow exponentially. Tracing requirements, of course, will not reduce these labor costs to zero, but it will provide clear tools for understanding the project, how to conduct an impact analysis, how not to lose the changes that will be made.
Let's imagine that we give a newbie a task: we need to add a certain attribute on a certain form. Where should he look for information? If there is tracing, he will see all the artifacts for the business process to which it relates, the screen form, what use cases it is connected with. According to tracing, simply by checking each of the artifacts, he will already be able to understand the business process, and the quality of his work at the output will be much higher. Tracing will make work easier not only for newbies, but also for those who have been in the project for a long time, simply because you already have a clear structured picture.
What are the tools for tracing requirements and artifacts?
The first type of toolsthe simplest one is the good old trace matrices. They can be created manually and used for this purpose in Excel, Google Doc, Confluence, even a regular whiteboard with a marker.
This will of course require some manual work, but it is important to take the first step towards tidying up and simplifying your life.
You and the project team decide what to fill the tracing matrix with. These can be use cases mapped to test cases, or business objects mapped to a use case, or a use case to a use case. In one of the projects, we used tracing through a matrix, where business objects in master systems were mapped to business objects in slave systems. This way, we could see which system was the master for a certain object, and which systems were the slave for this object. And if a business object changed in the master component, we checked that the slave object did not become inconsistent.
The second type of instruments – This Requirements Management Systems (RMS). They can all be divided into two categories:
1. Specialized software. These include Sparx Enterprise Architect, Confluence Atlassian + Requirement Yogi plugin, Jama, IBM Telelogic DOORS, IBM Rational RequisitePro, TechExpert, and others. They are designed to trace requirements. I previously gave a talk on Requirement Yogi, you can watch it here. Secondly, this is, in fact, the easiest way to set up requirements tracing on top of Confluence.
2. Any software that is used as a requirements management system. This includes Jira, because it allows you to link different artifacts, and Redmine, and Atlassian's Confluence via page tags, and Google Sheets. You can adapt a lot of things as a requirements management system, and it's quick and easy.
What is the key to successful application of requirements tracing?
Firstlyit is the ease of creating relationships, where you can quickly and easily identify your artifact or requirement, and make an anchor, unique identifier or link to it.
Secondlyis the visualization and reporting of relationships, when the requirements management system and traceability tools allow you to quickly and easily build a traceability matrix. Viewing relationships in these tables is impact analysis.
Thirdit is the obligation to create a connection. Only the inevitability of tracing makes it a good tool. Requirements tracing must necessarily be included in some kind of standard control or approval. Because as soon as it becomes optional, it stops working. A project that is not covered by tracing at all is better than a project that is half-covered by tracing.
I hope my experience will be useful to you! See you in the next article!
