Modeling Guide

Knowledge Guides /

How do you implement MBSE requirements traceability with evidence, rather than links alone?

Last updated: · New Horizon Digital Outsourcing Team

Traceability should connect requirement sources, design objects, and verification evidence, rather than merely generate a relationship matrix. Establish stable identifiers and relationship semantics first, then check for orphaned requirements, duplicates, and entries without verification methods. Coverage measures relationship completeness; it does not prove that a design meets its targets.

Establish a single point of reference from the original requirements

  • Retain the source section, original description, owner, and status in each requirement record. When splitting sentences with multiple criteria, preserve the decomposition links so reviewers can return to the original text. Metrics must include units, applicable operating conditions, and decision criteria. Mark unconfirmed values for clarification rather than inventing definitive requirements.

How should relationships be organized?

  • Distinguish requirement decomposition, design satisfaction, and verification relationships. For example, an endurance requirement may be allocated to the energy system, but linking a battery module does not demonstrate that endurance is met; power consumption analysis, mission conditions, and verification results are also required. Calling every relationship an association prevents impact analysis from distinguishing design responsibility from reference material.

What should be checked after a change?

  • When requirements change, trace the affected functions, interfaces, and parameters through to test or simulation cases. Freeze model versions before and after the change, and record which results must be rerun and which evidence remains valid. Deleting a requirement also requires addressing downstream relationships, so invalid verification links do not appear complete.

Delivery and spot-check methods

  • Recommended handover items include a requirements dictionary, relationship matrix, orphaned-item list, and one complete evidence-chain example. During acceptance, randomly select one item each in normal, changed, and closed states, and trace each from its original text to the model and report. Items that cannot be traced to original evidence belong on the issue list, rather than simply being marked covered in a matrix.

Have a more specific question?

Tell us your project stage and target domain. We will respond within 1 business day with collaboration options and scope recommendations.