Requirements Tracing, Tracking and Reporting - Requirements Engineering and Management for Software Development Projects - page 128

In some cases one requirement would span across multiple modules and
components when finally implemented. For example consider the requirement—
''the system must be secure''. It needs to be implemented in multiple components
such as the login screen; prevention of accessing any screen directly bypassing the
login screen; audit trails to investigate any intrusions; firewalls, anti-viruses and so
on. Similarly, one component could be implementing multiple requirements. For
example a sales transaction would trigger multiple actions across the system; the
stock needs to be decreased; the income needs to be increased; the salesperson
performance needs to be incremented; the customer may need to be created; the
customer account needs to be suitably updated and so on. Unless we trace all
requirements to implementation and all implementation to their requirements, we
would not know how comprehensively did we implement the requirements.
Therefore, it is important and essential to trace all requirements in both
directions, namely from requirement to implemented features and from product
features to their requirements.
9.4 Mechanisms for Tracing Requirements
The most popular mechanism used for tracing requirements through the software
development life cycle is the traceability matrix. An example of a traceability
matrix is depicted in Table 9.1 . In the traceability matrix, each requirement is
traced in a row. The first column would contain the requirement id which is
normally the one taken from the URS. The brief description column would contain
a brief description normally taken from the requirements analysis sheet for con-
sistency. References columns would be filled with the section numbers from
information artifacts and program names from code artifacts. Each column may
contain multiple references. In cases where a requirement is completely deleted,
we indicate ''Deleted'' and include its reference in the column captioned ''Deleted/
Modified'' column. If it is modified, the change request id is indicated in the
''Change Request'' column. This column too may contain multiple references. The
description in the ''Brief Description'' column would not change when the
requirement is deleted. When any requirement is modified, we need to evaluate if
the description needs change and affect it on a case-by-case basis.
We may add more columns or rows depending on our own unique require-
ments. The traceability matrix is normally implemented using Excel worksheets.
But if the number of requirements is very large, Excel sheets would be cumber-
some to manage. We may need to use a specialized requirements traceability tool.
With Excel sheets, we can trace from either requirement to its implementation
or from an implementation to a requirement. We can also use a separate worksheet
for each module to cover the entire project in the same file. Excel is an excellent
tool for implementing requirements traceability for a project. But when we come
to the organizational level, Excel sheets would not be able to consolidate the
information. It is better to use a specialized tool with RDBMS in the backend.