Using Requirements Coverage Matrices

It is worth mentioning that the use of Requirements Coverage Matrices and the choice of a storage format depend mainly on the nature of the project and its capacities.

The main conditions, which make usage of a Requirements Coverage Matrix on a project appropriate, are as follows:

1. The project budget allows time for creating a Requirements Coverage Matrix (or matrices).
2. Requirements to a product or to a new task are quite substantial and suggest a number of changes.
3. Requirements provided by the customer are not complete and do not take into account all the nuances of the product implementation or its specifics, thus demanding a detailed analysis and involvement of a team on both the developers’ and the customer’s side.
4. Initial requirements are not documented and formulated in a clear way, which makes it necessary to collect and document these requirements.
5. Mandatory coverage of all requirements with test cases.

So what is a Requirements Coverage Matrix and how can it be useful?

Requirements Coverage Matrix is a table that contains a list of documented requirements to a product/task and links to the corresponding test scenarios. It is used for validation of requirements coverage with test cases. There may be situations where requirements are not initially documented or where initial requirements are not final and need an additional study together with the story team and agreement with the customer. In such cases, the matrix also serves as a collection and storage place for the final approved requirements.

Most sources suggest using a two-dimensional matrix, where column headers contain requirements, and row headers contain test scenarios. The intersections mark that the requirement of the current column is covered with the test scenario of the current row. Below you can see an example of this kind of matrix:

As practice has shown, this approach is not the only possible standard. Based on the needs and specifics of the project, you can choose a different, better-suited format. For example, one of Sigma Software’s projects used the following format of the Requirements Coverage Matrix:

In this case, we see that the matrix is a table with more data necessary for the given project, namely:

• Requirement number – a unique requirement identifier, assigned initially or given by you independently. In this case, the matrix was developed for a new feature, and the identifier was the abbreviation of the feature name with a number added.
• Link to source of requirement – the link to the source where the requirement is taken from. It may be a link to an article with the initial requirement and with mentioning of the paragraph/line where the requirement is documented. Otherwise, it could be a link to a corresponding record in JIRA with a clear description of the requirement. Besides, this column may contain a reference to a document, email, skype talk or another source, where this requirement is documented and approved with both the team and the customer.
• Requirement – the statement of the requirement. It is important to note that each new requirement must be entered separately and have its unique number, which will be convenient in the future for covering the requirements with test cases.
• Link to test cases – a link to test cases, where the current requirement is covered with test cases.

It is also worth adding that in the case given above the application was a client-server application, that is why the requirements in the table are divided into server requirements, back-office requirements, and client requirements. This approach added to the convenience of further work with the requirements (implementation, preparation of test cases). As for preparation of test cases, they employed (just like in the Requirements Coverage Matrix) some cross-references to the requirements corresponding to the given test cases.

Therefore, anyone, who has a completed Requirements Coverage Matrix like this, is not left wondering where a certain requirement comes from, or whether it is approved with the team and the customer, or whether it is covered with test cases. The table provides all the necessary information.

Storage Format

When choosing a format of storage for a Requirements Coverage Matrix, it is important to take into account not only the project specifics, but also the accessibility of the matrix for other team members and, possibly, the customer as well. The Matrix may be shaped into an article on one of the project resources, or stored as a separate Word or Excel document. There is also a number of professional products created specifically for the purpose of structuring, collecting, and analyzing requirements, such as Rational RequisitePro, Rational DOORS, Rational RequisitePro, and others.

Advantages of Use

In conclusion, it is worth highlighting the main advantages of using a Requirements Coverage Matrix (or matrices) on a project:

1. All requirements are agreed and documented in a single resource.
2. All team members, as well as the customer, can have access to the matrix in case of necessity of a final review or requirements approval, or in case of questions at any stage of the product’s lifespan.
3. The matrix is easy for developers to use in the implementation process and is, in a way, a guarantee that all the requirements will be taken into account at this stage.
4. The matrix is easy for QA engineers to use at the stage of preparation of test cases and allows validating coverage of all requirements with corresponding test scenarios.
5. The matrix can be useful and convenient when new people have to get familiar with the requirements (new team members or people not involved earlier in the project), or for a history record (for example, when requirements were forgotten and there is a need to recover them fast).

We’ll continue discussing Requirements Coverage Matrices in my next article. I’ll tell you about versioning of Requirements Coverage Matrices and choice of matrix storage formats. Stay tuned!

• #Software Testing