for  this first we will discuss with projectleader or 
bussiness anlyst to collect the requirment again .
if it is not possible we will discuss with clint to collect 
that missed requirement again.

This is the problem with the traceability matrix. 
Traceability has following disadvantages
1. Any requirement missed/omitted cannot be tracked easily
2. Requirement not mentioned in the functional specs can be 
tested.
For example, testing the boundary value conditions for 
minimum deposit amount, say, 1000 INR. The following 
conditions would be considered,
1.<1000
2.=1000
3.>1000
Here, FS only talks about the minimum amount to be 
maintained in a customer's account. What is not mentioned 
in the FS is also tested(<1000 and >1000). Therefore, 
traceability is ineffective.

The RTM lists all the requirements in the SRS by giving the 
requirement ids. The tester referes the SRS to write the 
test cases and againg maps the test cases to SRS by giving 
the test case ids in RTM against the requirement id. So if 
any requirement is missed by Tester then he will miss the 
test cases for that requirement. But when he will go to 
update the RTM for test cases, he will not find test case 
ids for that missing requirement. Hence the RTM helps out 
to find any missing requirement and ensures the test 
coverage by maping test case id with the requirement ID.

It is always good that traceability is mapped with 
requiremnt, the use cases,then test case.
tester can write testcase based on the use cases, use case 
must cover all the possible scenarios.
if any test case is missed out go back to use case,follow 
by SRS.

Normally in any process orieneted company there will be 
tool which tracks birectional requirement traceabilty. 
requirement traceability tool also facilates to run 
requirement GAP. All tagged requirements should have an 
associated test case(s) otherwise GAP report will mark the 
requirement with no test.

Usually GAP analysis will be done before baselining test 
plan.