Experience has shown that the ability to trace requirements artifacts through the stages of specification, architecture, design, implementation, and testing is a significant factor in assuring a quality software implementation. The ability to track these relationships and to analyze the impacts of changes forms a key thread throughout many modern high-assurance software processes, particularly in life-critical medical products and business- or mission-critical activities.
Historical safety data has demonstrated that missing or unaddressed requirements and/or the impacts of changes are often missed and that small changes to a system can create significant safety and reliability problems. This has caused some regulatory agencies to mandate traceability as an integral part of the development process. For example, the latest U.S. Food and Drug Administration (FDA) guidance for traceability in medical software development activities is contained in the FDA Office of Device Evaluations (ODE) Guidance Document [FDA 1998]. In addition, the Design Controls section of the medical Current Good Manufacturing Practices (CGMP) document [FDA 1996], Subpart C of the CGMP, defines the obligations of the system designers to be able to trace relationships between various work products within the lifecycle of the product's development.
If traceability has been mandated for your project due to some regulatory or internal process standards, then your team won't have any choice. If it has not been mandated , then your team will need to decide whether to apply implicit and explicit requirements traceability or not, and if so, how much traceability is required to assure the outcome you need. We'll revisit this discussion again in just a bit, but first let's look at what traceability is and how to apply it.
For a starting point, IEEE  provides the following compound definition of traceability.