Versioning of Requirements Coverage Matrices

Let’s suppose, a new task comes to the project, with requirements processed by the team and approved by the customer. The final requirements were documented in the Requirements Coverage Matrix, the task was implemented, tested, and released. After a while, the customer requests for a task update, which involves an update of requirements. So how do we update the Requirements Coverage Matrix, if we need to save the history of the current changes?

I suggest considering several possible options:

1) Creating the Requirements Coverage Matrix in a document that supports changes tracking

One way could be an Excel document. Frankly speaking, I have never used this option in practice myself, but the internet provides descriptions of the necessary settings and examples of how changes can be chronologically tracked in Excel spreadsheets. Here is one of such sources.

A significant disadvantage of this approach is a number of limitations for Excel documents with shared access. This must be studied in detail, taking into account the specifics of your project.

2 Storing the Requirements Coverage Matrix in a Version Control System

One example of this could be a rather popular free version control system – Subversion (SVN). For us, the main advantage of working with a system of SVN type is history tracking of the file and catalog changes even after they were renamed or moved, as well as high efficiency.

Graph 1 – History of changes of a file stored on SVN

This is a rather convenient and popular method of storing any project documentation and other artifacts. Version control systems offer the user a whole range of options to work with files and catalogs.  If you choose this way, you can use both project source control (as a rule, a project uses source control, which can be accessed to store necessary documentation) and control provided by the company (if necessary, you can create a request to the company to provide a repository for the project needs). If you choose a version control system different from SVN, it is necessary to get familiar with the system tools and options for tracking file changes first, as each system has its own specifics.

NOTE: The ways of storing the Requirements Coverage Matrices described above make sense when there is no need to access the current requirements for each product version on a daily basis. In case of such need, it is best to use the ways given below.

3) Using separate sheets for storing the Requirements Coverage Matrices for each version of the product

We take Excel spreadsheets as an example. In this case, you can use a separate sheet for the Requirements Coverage Matrix for each version of the product. Let’s suppose, we have Task 1, the requirements to which are different in product versions 1.0 and 2.0. We create an Excel document for a Requirements Coverage Matrix for the current task. We name sheet 1 “Version 1.0” and create a Requirements Coverage Matrix with the final requirements for version 1.0. So, sheet 2 will be named “Version 2.0” and will contain the updated matrix with requirements for version 2.0.  As a result, you will have an updated Requirements Coverage Matrix for each version – you only have to switch to the corresponding sheet.

Graph 2 – Excel document with Requirements Coverage Matrices for each product version in separate sheets

4) Indicating supported product versions for changing requirements

To avoid duplicating constant unchanging product requirements you can, for instance, use an additional column to indicate the product version, where the changing requirement is supported. You can also indicate the latest supported version, or the version, in which the given requirement was introduced and from which it is supported. You can also set a range or list of versions, where the changed requirement is supported. This way you will have a matrix with all the requirements for all versions of the product.

Graph 3 – Indicating supported product versions for changing requirements

Possible disadvantages of this approach are that the volume of information may grow substantially, and that the requirements will be mixed up.

5) Storing information in separate folders or branches

If we are talking about a file system, a separate folder can be created for each new product version or for each requirements package. It will contain all corresponding documentation. In the same way, when using, for example, Confluence for storing Requirements Coverage Matrices and other project documentation, a separate branch can be created.  Let’s consider both examples to illustrate this point:

Graph 4 – File system. Storing project documentation for different product versions in separate folders

Graph 5 – Confluence. Storing project documentation for different product versions in separate branches

In my opinion, this is a really convenient and practical way. You can store a Requirements Coverage Matrix for each new product version with a set of new requirements only, without duplicating the requirements described in earlier versions. Or, you can store a set of unchanged requirements described earlier plus a list of new ones.

6) Using professional software

There is a range of professional solutions aimed specifically at structuring, collecting, and analyzing requirements, and documenting history of changes as well as providing an audit of requirements evolution of the project/task. For example, IBM Rational, HP Quality center, and others.

These are only a few examples of how you can work with versioning of the Requirements Coverage Matrices. I am sure each of you can significantly add to this list, building on your own or other people’s experience.

The methods described above can also be applied to versioning of other types of project documentation.

In conclusion, I would like to highlight the main points, which should be considered when choosing any of the formats of storing Requirements Coverage Matrices:

1) It is necessary to determine the overall approach to working with Requirements Coverage Matrices on your project. One way is as follows: new changes requested by the customer are interpreted as a new task and documented in a separate matrix, without changing matrices created earlier. Otherwise, you can choose another approach, where a separate Requirements Coverage Matrix is not created, but an earlier one is updated instead (if there is one).

2) It is necessary to take into account access settings, depending on the project specifics.

3) It is necessary to consider whether there is a need to access the Requirements Coverage Matrix for each product version on a daily basis.

• #Software Product Development
• #Software Testing