Requirement tractability matrix (RTM)
The Requirement tractability matrix (RTM) is a document that links requirement throughout the validation process.
RTM is designed to ensure that all defined requirement is validated, all test cases and scenario is covered with given specification and tested.
we are using RTM to ensure that, each requiremenet has test case to make sure requirement is covered for testing.
it also make sure all change request (by client) are or will be tested.
Advantage of RTM
- easy to identify missing functionalities.
- easy to find out which test cases need updating if there are change requests.
- Ensuring that developers are not creating features that no one has requested.
- All test cases are included in test cases
- product is developed as client required
- shows how requirement is linked to test cases
- Makes sure 100% coverage of requirements
- no automation tool is required
Types of Requirement Tractability Matrix (RTM)
Forward Tractability Matrix
its mapping of requirement to test case
this matrix is used to ensure that we are building the right product. it makes sure that each requirement is applied to the product and we did not miss any requirement.
and also it makes sure that each requirement is properly tested.
its a mapping between requirement to test cases.
testing is done in each phase to make sure, we are in the right direction.
Backward Tractability Matrix
its mapping of test case to requirement
this matrix is used to ensure that we are build the product right.
it is used to ensure that, This will help us in identify if there are test cases that do not trace to any coverage item.
If the test case does not trace to a coverage item, it is either not required and should be removed.
It is used to ensure whether the current product remains on the right track
It is also very helpful if you want to identify that a particular test case is covering how many requirements.
bi-directional
it contain both forward and backward tractability
Project: Online
Train Booking Application
This
document is provided by Client with high level business Requirements. Suppose
for Flight Booking Application it shows below 2 requirements
Business
requirement document
BR_1 Train
Booking Module:
It
should allow user to book one or more tickets, one way or round way for future
dates
BR_2 Payment
Module:
User
should able to make payment for booked tickets via Credit / Debit Card or
through Reward Points.
Functional Specification
document
This
document is prepared by Technical team which further elaborate business
requirements into functional requirements that can be implemented in a
software.
Suppose
above 2 business requirements in BRD have more detailed functional
requirements:
BR_1 Reservation
Module:
·
FR_1: One Way
Ticket booking
It
should allow user to book one-way ticket
·
FR_2 Round Way
Ticket
It
should allow user to book round way ticket
·
FR_3 Multicity
Ticket booking
It
should allow user to book one way or round way ticket for multiple cities
BR_2 Payment
Module:
·
FR_4: By Credit
Card
It
should allow user to make payment by Credit Cards
·
FR_5 By Debit Card
It
should allow user to make payment by Debit Cards
·
FR_6 By Reward
Points
It
should allow user to make payment by Reward Points
And
you have written some test cases or test scenarios for each functional
requirement.
Test Scenario for following requirement
|
Test Case ID#
|
Description
|
User
|
|
TC#1
|
Verify that, user is able to book
one-way ticket
|
|
|
TC#2
|
Verify that, user is able to book
multiple one-way ticket
|
|
|
TC#3
|
Verify that, user is able to book
round way ticket
|
|
|
TC#4
|
Verify that, user is able to book
multiple round way ticket
|
|
|
TC#5
|
Verify that, user is able to book
one-way ticket for multiple cities
|
|
|
TC#6
|
Verify that, user is able to book
round-way ticket for multiple cities
|
|
|
TC#7
|
Verify that, user is able to pay by
master card
|
|
|
TC#8
|
Verify that, user is able to pay by
visa card
|
|
|
TC#9
|
Verify that, user is able to pay by
Debit card
|
|
|
TC#10
|
Verify that, user is able to pay
fully by Reward point
|
|
|
TC#11
|
Verify that, user is able to pay
partially by Reward point
|
|
And if
prepare simple RTM for above example it would be like as below:
|
RTM (Requirement
traceability Matrix)
|
||||||
|
Project Name: Online Train Booking
Application
|
|
|||||
|
Business Requirement
document
|
Functional Specification
document
|
Priority
|
Test case Id#
|
Status
|
||
|
BR_1
|
Reservation Module
|
FR_1
|
One-way ticket Booking
|
High
|
TC#1
TC#2
|
Tested
|
|
|
|
FR_2
|
Round way ticket
|
High
|
TC#3
TC#4
|
Tested
|
|
|
|
FR_3
|
Multicity ticket booking
|
High
|
TC#5
TC#6
|
Tested
|
|
BR_2
|
Payment module
|
FR_4
|
By Credit card
|
High
|
TC#7
TC#8
|
Tested
|
|
|
|
FR_5
|
By Debit card
|
High
|
TC#9
|
Tested
|
|
|
|
FR_6
|
By Reward Point
|
High
|
TC#10
TC#11
|
Tested
|
Comments
Post a Comment