Versioning of Requirements Coverage Matrices

STOCKHOLM - Jan. 4, 2018 - PRLog -- In my previous article, we looked at Requirements Coverage Matrices and examples of their usage on a project. Today I would like to speak in more detail about the choice of matrix storage formats, in particular when there is a need to track the history of how requirements changed on a project/task.

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 (https://sigma.software/about/media/about/media/using-requirements-coverage-matrices), 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 which 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(link is external) (https://support.office.com/en-us/article/Track-changes-in...).

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.