Give every requirement an identifier and link it upward to the objective it serves and downward to the design, the build item, and the test case. The practical payoff is impact analysis: when something changes late, you can say precisely what it touches. Keep the matrix light and generated where possible, because a hand maintained one goes stale within a month.
Why interviewers ask this
Traceability is easy to claim and tedious to do, so interviewers check whether you understand its purpose. The right framing is impact analysis and test coverage, not compliance paperwork. They also want realism about maintenance cost and awareness that rigor should scale with the environment, since a regulated program and a small internal build need very different levels of formality.
How to structure your answer
- Give each requirement an identifier and link it up and down.
- Justify it by impact analysis, not by compliance.
- Use it to find requirements with no test coverage.
- Generate the matrix from tooling rather than maintaining it by hand.
- Scale the rigor to the environment.
Example answer
Every requirement gets an identifier, and it links up to the business objective it serves and down to the design, the story, and the test case. The reason I bother is impact analysis rather than paperwork. When someone asks in week fourteen what happens if we drop this rule, I can answer in ten minutes instead of guessing, and that is worth the effort on its own. I also use it for coverage, so before we go into acceptance testing I can see which requirements have no test against them, and there are always a few. The important thing is keeping it cheap. If I am maintaining a spreadsheet by hand it will be out of date within a month, so wherever the tooling supports linking stories to requirements and tests I use that and let the matrix be a report. And I scale it: full traceability on a regulated program, something much lighter on a two month internal build.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How do you handle traceability when requirements are only stories in a backlog?
- What do you do about a requirement with no objective behind it?
- How do you keep the matrix current through a lot of change?
Related business analyst questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions