1.

Explain about Requirement Traceability Matrix

Ans:- The Requirements Traceability Matrix (RTM) is a tool to help ensure that the project’s
scope, requirements, and deliverables remain “as is ” when compared to the baseline. Thus,
it “traces ” the deliverables by establishing a thread for each requirement- from the project’s
initiation to the final implementation.
RTM in Project Management Phases

● Track all requirements and whether or not they are being met by the current process and
design
● Assist in the creation of the RFP, Project Plan Tasks, Deliverable Documents, and Test
Scripts
● Help ensure that all system requirements have been met during the Verification process.

The Matrix should be created at the very beginning of a project because it forms the basis of the
project’s scope and incorporates the specific requirements and deliverables that will be
produced.

The Matrix is considered to be bi-directional. It tracks the requirement “forward ” by examining

the output of the deliverables and “backward ” by looking at the business requirement that was
specified for a particular feature of the product. The RTM is also used to verify that all
requirements are met and to identify changes to the scope when they occur.

Requirements <-> RFP <-> Design/Task <-> Deliverables <-> Verification

The use of the RTM enhances the scope management process. It also assists with process control
and quality management. An RTM can also be thought of as a process of documenting the
connection and relationships between the initial requirements of the project and the final
product or service produced.

project-management.com is free because select vendors may pay us for referrals. Our writers and
editors are editorially independent, so we consider all vendors, even those who don’t pay us.

What Elements Should an RTM Include?

Some RTMs are more in-depth than others. No matter what project you’re pursuing, though, you
must include a few basic elements.

● Requirements: An identifier or description that explains one feature your project is meant
to complete.
● Test Cases: A plan of inquiry based on a project requirement. Each test is matched with a
requirement and vice versa.
● Project Status: The viability of the project. Did it pass or fail the test?
Requirements
The team assembles project requirements when they begin development. The client will also
submit a document outlining their needs. These are two ways to generate requirements and test
cases for your project.

Examples of project requirements include:

● Creating a new input field as a result of interactions.

● Directing to a new display in response to users.
● Finding relevant internal sources in response to users.

For an even more thorough list of requirements, the team may compile potential use cases for
the project.

Test Cases
Every requirement must be paired with a test case. Without doing so, you won’t have any way of
verifying your project requirements.

Based on the three examples above, you could assemble multiple test cases. This could mean
developing a test case wherein an automated program interacts with your software as a user
would, to see if your project is performing successfully. Alternatively, you could also make a test
case that would target all three requirements simultaneously. This could mean creating a
three-pronged test that could go from requirement to requirement.

For each test case, you’ll need to outline the steps to analysis, the intended result, and the
post-test outcome.

Test cases and requirements must have identification numbers in your RTM. The best way to
ensure that every project requirement is linked with a test case is to match requirement
identification numbers to test case IDs.

Status of Project
The status of the project refers to the effectiveness of your tests. If the tests fail, you’ll need to
record the issue and search for what caused the problem. The details you include are up to you
and your team. Requirements traceability matrix documents are meant to simplify the project
management process, and so uniform usage is important.

The more complex your project, the more likely it is that you’ll encounter a considerable number
of failures. That isn’t a bad thing, but it means that you should consider giving yourself room to
describe your intended outcomes and potential errors. Project status goes hand-in-hand with
test cases and requirements by allowing teams to implement traceability.

What is Traceability?
Traceability, as related to a requirements traceability matrix, is the ability to follow a requirement
— or “trace” it — through different phases of testing. It is a simple term that refers to the
complex process of tracking the detailed development, analysis, and records of your team’s
software or hardware projects. This is tedious, and many companies find themselves lost in
information when testing new software products. Using traceability in an RTM document is the
perfect way to prevent your team from being disorganized.

Why Is Requirements Traceability Important?

Project Organization
As mentioned above, you’ll be doing a lot of tests to verify the viability of your software projects.
You’ll also have a list of requirements from multiple sources. In order to ensure that you’ve
tested every variable correctly, you need to use a RTM. These documents increase productivity
by reducing team errors and gathering all essential data in one place.

Improved Communication
Because every test your team conducts is recorded, RTM documents expedite communication.
Issues are easier to identify and teams can work faster on completing their projects. A digital
requirements traceability matrix can be used simultaneously by multiple project members, and
previous data is readily available. This allows teams to better delegate tasks and transfer
responsibilities without sacrificing quality.

Types of Traceability Matrix

Forward Traceability
As mentioned, traceability is simply the ability to follow a variable. In project management, this
often means recording the results of a software (or hardware) requirement in an RTM document.

Forward traceability follows the requirement of a project from start to finish. This means
following the basic steps of an RTM document, going from requirements to test cases and project
status. Forward traceability is typically where project management teams start. It can help you
determine successes and, more importantly, identify errors.

With software projects, forward traceability is the best way of finalizing a project’s viability
before presenting it to customers. For example, you might develop a test case that pertains to
many requirements simultaneously; with forward traceability, you can prove to your customer
that every requirement has been successfully satisfied.

Backward Traceability
Backward traceability is the opposite of forward traceability. It is very helpful when analyzing
project errors because teams can match tests with project requirements. This means that your
test cases will be applied to multiple requirements with ease. They can also be used to ‘respond’
to failed requirements. With this type of traceability, you start with your project tests/outcomes
and work backward.

Neither forward traceability nor backward traceability are enough to complete a successful
project. In order to develop a good product, you’ll need to use both types of traceability to your
advantage.
Bidirectional Traceability
Bidirectional traceability incorporates elements of both forward and backward traceability. This is
the goal for your projects; you need to be able to evaluate both forward and backward —
identify problems, and then identify why those problems occurred, and when. For example, you
begin in the research phase and work your way through your RTM, from tests to status to
failures/problems.

Creating a Requirement Traceability Matrix

Creating an RTM is relatively straightforward. Once you have your information, you simply need
to fill out your traceability matrix. It’s best to keep in mind that thorough testing leads to the best
products, so you’ll need to compile as many requirements for your project as possible.

You must also decide what information you want to include in your document. Requirements,
test cases, and project status are necessities, but many teams choose to add other data to their
RTMs. These extras often include comments, descriptions of requirements and test cases, goals,
and more.

After you’ve decided on your format, gathered your requirements, and created your tests, your
team is ready to begin analyzing the project. Then you need to fill out your RTM as you develop
your project. The most important thing to do is be consistent. Your information won’t do your
team any good if they can’t see it. Creating a habit of filling out your requirements traceability
matrix after every test case is the key to success.

Requirement
Requirement ID Test Case Status Comments
Origin

Initiate action by
Create a new input # Improve
Customer creating specific Success.
field for users. 1 interaction.
language.

— — — — — —

There is no one way to create a requirements traceability matrix, just as there is no perfect
project. But using an RTM document will help you and your team dramatically. Testing your
project and gathering requirements will be the most time-consuming and tedious part of using a
requirements traceability matrix. Fortunately, these documents will also help your project
management team complete their projects faster.

No matter how you decide to implement a requirements traceability matrix into your
organization, it will likely transform your workflow for the better. RTM documents help to focus
your team’s energies on the most pressing problems. They also stop you from inadvertently
completing the same test cases without improving your project. Indeed, projects can be costly to
develop and pursue, and your team should take advantage of any tool that promises to save time
and improve your work. And one such tool, of course, is a requirements traceability matrix.
2. Demonstrate the structure of requirement document(SRS)