The traceability of bug can we followed in so many ways.
*Mapping the Functional requirements scenarios (FS Doc) - test cases(ID) -- Failed test cases (Bugs) Mapping between requirements (RS Doc) - test case (ID) - Failed Test Case Maping between Test plan (TP Doc)- test case (ID) - Failed Test case mapping between business requirements (BR Doc) - test Case (ID) - Failed Test case Mapping between High Level Design (Design doc) - Test Case (ID) - Failed test case. Usually the traceability matrix is mapping between the requirements, client requirements, function specification, test plan and test cases.
Typically, in test situations, traceability matrices are used to trace requirements to test cases in order to ensure that there are test cases for all the requirements. Some easily aviailable commercial tools like Rational Suite Enterprise, will help testing engineer/ test lead to trace requirements and then to trace from the use cases and/or requirements to test cases.
Of course, usually many types of traceability matrices may be created a just simple concept of REVERSE ENGINEERING. For example, you may trace Bug--> identify that test cases-->use cases and vice versa. The default term likely applies to tracing requirements to test cases though.