Answer.

Requirement traceability is a systematic link between business goals, requirements, and implementation. It allows visibility into which decisions and tasks are related to specific original goals, quickly identifying deviations and making changes with minimal risks.

Key features:

Use of a Traceability Matrix: a document or tool that links requirements to tasks, test cases, and outcomes.
Integration with ALM/PM tools (e.g., Jira, Azure DevOps): maintaining the history of requirements changes, comments, and decisions.
Regular verification of requirements against implemented features and tests: constant checks for compliance.

Trick questions.

Is it sufficient to create the requirements matrix once and not update it?

Answer: No, the matrix must be updated throughout the project; otherwise, the connection between requirements is lost or becomes erroneous.

Is traceability solely the responsibility of the analyst?

Answer: No, it is a cross-functional task; collaborative work among BAs, testers, project managers, and developers is important.

Can traceability be ignored in small projects?

Answer: Even in small projects, traceability helps avoid regression, loss of requirements, and errors during changes, especially during subsequent maintenance.

Common mistakes and anti-patterns

Lack of regular updates to the requirements matrix
Ignoring minor changes and not recording them in tools
Formal approach to traceability (filling out "for the sake of formality")

Real-life example

Negative case: startup without a requirements matrix. Requirements changed verbally, some tasks remained unimplemented, bugs did not find reasons in the original goals.

Pros:

Easy communication at the start

Cons:

Lost tasks
Unclear regression points
Many redundant modifications

Positive case: introduction of a traceability matrix, regular updates in Jira, linking tasks with test cases.