Traceability is about connecting the dots to determine that the web of activities for a functional safety project have followed the proper paths.  Think of it like cheating at hide-n-seek; it provides a shortcut to find all those requirements and design parts that are hidden in your specification documents.  If you do it right, there is nothing that can hide because the cross-references will point you in the right direction.

Traceability is a SIL verification step that is broadly bi-directional, but items at the end of the line, like the highest level product requirements or the lowest level implementation, will be uni-directional.  IEC 61508 addresses the bi-directional nature of traceability:

• Backward traceability is checking that the implementation (what you did) is justified by a requirement (what you need); this often involves citing the parent of the activity you just completed.
• Forward traceability is checking that a requirement (what you need) is adequately addressed in later lifecycle stages (what you will do); this often involves citing the proposed child of the activity you just completed.

At the very least for SIL2, you need traceability between safety requirements and validation tests… and this should be auditable for both forward and backward traceability.  Traceability can extend beyond the requirements and validation activities.  For SIL3, you need to go further into the traceability of software safety requirements and the forward (to design and test plans) and backward (to system safety requirements) connections.

Separate traceability lists or matrices are not required, but you shouldn’t need to jump through hoops to determine the tests associated with a requirement or the requirements that a test is validating.  A table at the end of a test plan or SRS can work well, or a spreadsheet can be created with the same intent.  Many requirements management and test management tools have built-in traceability aids.  They often allow export of traceability information to a report.  The best advice I can give is to include traceability in the requirements and design review checklists so you don’t forget about it.

And don’t forget about traceability when you make modifications.  One of the benefits to creating the traceability matrices is that you can review and update them when making system, hardware, or software changes.  This will help determine the depth and breadth of the proposed change and connect the dots between what exists and what you have planned, so also be sure to include traceability in your impact analysis checklist.