REQUIREMENTS TRACEABILITY & SYSTEMS ENGINEERING

Does this design
satisfy the
requirement?

Requirements live in DOORS. Designs live in CAD. Simulations live in Ansys. Tests live in a lab system. And the answer to the most important question in engineering is someone opening three tabs and making a judgment call. Meridian eliminates the judgment call.

LIVE V-MODEL TRACEABILITY — PROGRAM AX-7200
Stakeholder needs · 24 captured
Validation · 22/24 validated
System requirements · 128 derived
System verification · 119/128 verified
Subsystem specs · 342 allocated
Integration testing · 318/342 passed
Component specs · 891 detailed
Unit testing · 847/891 complete
Traceability health: 94.7% coverage · 12 gaps detected · 3 orphans flagged
REQ-TH-004 verified via simulation (Nexus) · REQ-VIB-012 marginal at 2.3% margin · REQ-EMC-008 untested — test pending
847 PASSED9 MARGINAL2 FAILED3 ORPHANED
THE TRACEABILITY CRISIS

Requirements live in one system. Designs in another. Tests in a third. The links between them live in someone's head.

When the link between a requirement and its verification evidence is a judgment call, failures are inevitable.

3 tabs
The typical method for answering "does this design satisfy the requirement?" — an engineer opens DOORS, CAD, and the test report, and makes a judgment call
INDUSTRY PRACTICE
Gap
The missing link between MBSE and PLM — where requirement creep enters and traceability breaks during the transition from system model to physical product
MBSE/PLM SURVEY 2025
Document
Traditional systems engineering remains document-based — creating and controlling paper that represents the system instead of managing the system model itself
ARAS / CIMDATA 2025
Implicit
Dependencies between requirements, designs, and verifications remain implicit — documented in notebooks rather than enforced in the data model
INCOSE / SEBOKWIKI

Requirements live in one system. Designs live in another. Tests live in a third. And the question "does this design satisfy the requirement?" is answered by someone opening three tabs and making a judgment call. When the system has 128 requirements, 342 subsystem specs, and 891 component specifications — each linked to design artifacts, simulation results, and test procedures — the judgment call becomes a liability. Meridian replaces judgment with data.

Meridian integrates requirements management directly into the Axiom product knowledge graph. Each requirement is a node — linked to the design artifacts that implement it, the simulation results that validate it, and the test procedures that verify it. When a requirement changes, Meridian shows every design artifact, simulation, and test that must be re-evaluated. When a design changes, Meridian shows every requirement whose satisfaction may be affected. This is not a document management system with traceability columns. It is a graph-native requirements intelligence engine that makes the V-model executable, the coverage measurable, and the gaps impossible to hide.

WHY MERIDIAN

Five capabilities that transform requirements from documents into executable product intelligence.

Graph-Native Bidirectional Traceability
Every requirement traces forward to its design implementation and verification evidence, and backward to its stakeholder origin. Not links in a spreadsheet — typed relationships in a knowledge graph that enforce structural integrity.
Requirement ↔ design ↔ simulation ↔ test: every link typed, every gap flagged
Executable V-Model
The V-model is not a diagram in a presentation — it is a live data structure. Stakeholder needs link to system requirements. System requirements link to subsystem specifications. Specifications link to component designs. And every left-side element links to its right-side verification.
V-model coverage computed in real time with margin tracking at every level
MBSE Bridge to Physical Product
The gap between MBSE modeling tools (SysML, Cameo, Rhapsody) and PLM product data is where traceability breaks. Meridian bridges this gap — importing system model elements and linking them to CAD geometry, BOM components, and physical test results.
Seamless SysML ↔ PLM integration with zero traceability discontinuity
Automatic Gap & Orphan Detection
Requirements without verification evidence. Design elements without governing requirements. Tests without traceable requirement linkage. Meridian finds them all — continuously, automatically, and before the auditor does.
Zero orphaned requirements or untested design elements (automatically flagged)
Change Impact on Requirements
When a requirement changes, every downstream artifact is flagged. When a design changes, every upstream requirement is re-evaluated. Impact propagation is instant, complete, and bidirectional — connected to Cascade for automatic ECR generation.
Requirement change impact analysis across the entire product graph in seconds
REQUIREMENTS INTELLIGENCE ENGINES

Eight engines. Every requirement traced.

From stakeholder need to verified test result — Meridian governs every requirement, every allocation, every verification, and every gap.

01
Requirements Ingestion & Decomposition
Multi-source import · NLP requirement extraction · Hierarchical decomposition · Attribute enrichment
Requirements arrive in many forms: customer specifications in Word documents, regulatory standards in PDFs, internal engineering memos in email, and system-level requirements in MBSE tools. Most PLM systems expect requirements to be manually entered one at a time. Meridian ingests requirements from all sources — importing from IBM DOORS, Jama Connect, Polarion, Microsoft Word, Excel, and SysML model elements. Natural language processing parses unstructured specification documents to extract individual requirements, identify "shall" statements, and classify each requirement by type (functional, performance, interface, environmental, regulatory). Hierarchical decomposition tools enable systems engineers to trace stakeholder needs to system requirements to subsystem specifications — maintaining parent-child relationships and allocation records at every level.
Multi-source import — bi-directional connectors to IBM DOORS Next, Jama Connect, Polarion, and ReqIF format. Import from Word/Excel with NLP extraction of individual requirements from unstructured text. Round-trip sync maintains consistency with external tools
NLP requirement extraction — parses specification documents to identify "shall/must/will" statements, classify by type (functional, performance, interface, constraint), and flag ambiguous or untestable requirements before they enter the baseline
Hierarchical decomposition — stakeholder needs decompose to system requirements, which allocate to subsystem specifications, which detail to component specifications. Every parent-child relationship is typed and versioned
Attribute enrichment — each requirement auto-enriched with verification method (test, analysis, inspection, demonstration), priority, maturity level, owning organization, and acceptance criteria. Attributes drive downstream workflow routing
5+
Source systems with bidirectional sync
NLP
Automatic extraction from unstructured specs
4-level
Hierarchical decomposition (need→sys→sub→comp)
Auto
Ambiguity and testability flagging
02
Bidirectional Traceability Graph
Forward & reverse trace · Typed relationships · Cross-domain linkage · Trace completeness scoring
Traceability is not a column in a spreadsheet. It is a structural property of the product data model — and it must be bidirectional, typed, and enforced. Forward traceability traces from a requirement to the design artifacts that implement it. Reverse traceability traces from a design element back to the requirement that justifies its existence. Both directions must be maintained simultaneously, automatically, and without manual intervention. Meridian implements traceability as typed relationships in the Axiom knowledge graph: "satisfies," "implements," "verifies," "validates," "derives from," "allocates to." Each relationship is version-controlled and auditable. When a link is missing, it is not a data quality issue — it is a structural gap that the system flags automatically.
Typed relationships — not generic "links" but semantically meaningful connections: "REQ-TH-004 is_verified_by SIM-THERMAL-047" or "PN-4420 implements REQ-STRUCT-012." Relationship types drive automated compliance reporting
Cross-domain linkage — requirements trace to CAD geometry (via Lattice), simulation results (via Nexus), engineering changes (via Cascade), test reports, manufacturing instructions, and field performance data (via Echo). The full lifecycle is connected
Trace completeness scoring — for every requirement, Meridian calculates a completeness score: does it have a design implementation? A verification method? Verification evidence? An approval? Incomplete traces are flagged with specific missing elements
Suspect link detection — when a linked artifact changes (design revision, simulation re-run, test update), the traceability link is marked "suspect" until re-confirmed. Prevents stale links from creating false confidence in verification status
Bi-dir
Forward and reverse trace maintained simultaneously
6+
Typed relationship semantics enforced
Auto
Suspect link flagging on artifact change
Score
Per-requirement trace completeness metric
03
V-Model Verification Framework
Four verification methods · Automated pass/fail · Margin tracking · Verification evidence assembly
The V-model defines how systems are verified — but in most organizations, the V-model exists only as a diagram on a slide, not as an executable data structure. Meridian makes the V-model live. Every left-side element (stakeholder need, system requirement, subsystem spec, component spec) is linked to its right-side verification (validation, system test, integration test, unit test). For each verification, Meridian tracks the method (test, analysis, inspection, demonstration — the "TAID" taxonomy), the evidence (test report, simulation result, inspection record, demonstration video), the result (pass, fail, marginal), and the margin (how close to the limit). The verification matrix updates in real time as evidence arrives from Nexus (simulation), laboratory systems, and field data (Echo).
TAID method assignment — each requirement is assigned one or more verification methods: Test (physical test article), Analysis (simulation or calculation), Inspection (physical examination), Demonstration (functional operation). Method drives resource planning and schedule
Automated result capture — simulation results from Nexus auto-evaluate against acceptance criteria. Test results from laboratory information management systems (LIMS) auto-populate verification records. No manual transcription of pass/fail decisions
Margin tracking across iterations — for every quantitative requirement, tracks compliance margin across design iterations. Visualizes whether margins are growing (robust convergence) or shrinking (approaching failure). Early warning on trend toward violation
Verification evidence packaging — assembles the complete verification record for each requirement: method → setup → procedure → raw data → result → evaluation → approval. Submission-ready for FDA design verification, AS9100D qualification, and IATF PPAP
TAID
Test, Analysis, Inspection, Demonstration
Real-time
Verification matrix auto-update
Trend
Margin convergence tracking across iterations
Auto
Evidence packaging for regulatory submission
04
MBSE Integration & SysML Bridge
Cameo · Rhapsody · Capella · SysML import/export · System model to physical product linkage
The gap between MBSE and PLM is where traceability goes to die. Systems engineers define the architecture in SysML. Mechanical engineers implement it in CAD. Electronic engineers implement it in ECAD. Software engineers implement it in code. And the connections between the system model and the physical implementations are maintained in someone's memory — or worse, in a PowerPoint slide that was current six months ago. Meridian bridges this gap with deep integration to MBSE platforms: importing SysML elements (blocks, requirements, interfaces, parametric constraints) and linking them directly to PLM artifacts (CAD assemblies, BOM components, simulation studies, test procedures). When the system model evolves, the PLM traceability updates. When the physical design changes, the system model is notified.
SysML element import — imports blocks, requirements, interface definitions, parametric constraints, activity diagrams, and state machines from Cameo Systems Modeler, IBM Rhapsody, and Eclipse Capella. Elements become first-class nodes in the Axiom knowledge graph
System-to-physical linkage — SysML logical blocks link to CAD assemblies. SysML requirements link to PLM-managed requirements. SysML interfaces link to interface control documents. The abstract system model and the concrete product data model are connected
Bidirectional change notification — when a systems engineer modifies the architecture in SysML, Meridian flags affected PLM artifacts for review. When a design engineer changes a CAD assembly, the connected SysML block receives a suspect notification
Multi-domain traceability — the system model connects mechanical (MCAD), electrical (ECAD), and software (ALM) domains through Meridian. Cross-domain interfaces are tracked and verified against the system model's interface definitions
3
Major MBSE platforms integrated (Cameo, Rhapsody, Capella)
Bi-dir
SysML ↔ PLM change notification
3-domain
MCAD + ECAD + software connected to system model
Zero
Traceability gap at MBSE-to-PLM transition
05
Requirement Change Impact Analysis
Downstream propagation · Upstream justification · Cost & schedule impact · Re-verification scoping
When a requirement changes, every downstream artifact that depends on it must be re-evaluated. A thermal limit reduction from 150°C to 140°C may invalidate simulations, require design modifications, trigger re-testing, and delay qualification. In traditional requirements management, this impact analysis is manual — an engineer traces through the traceability matrix and identifies affected items one by one. Meridian automates this entirely by traversing the knowledge graph from the changed requirement to every connected artifact: design implementations, simulation verifications, test procedures, manufacturing instructions, and supplier specifications. The complete scope of impact is known in seconds — including estimated cost and schedule impact for the re-verification campaign.
Downstream cascade analysis — from a changed requirement, traverses every "satisfies," "implements," and "verifies" relationship to identify all affected design artifacts, simulations, tests, and manufacturing instructions
Re-verification scoping — identifies exactly which verification activities must be repeated based on the nature of the change. A tightened tolerance may require re-simulation but not re-testing; a material change may require both
Cost and schedule estimation — calculates the estimated cost and schedule impact of re-verification: simulation compute hours, test article fabrication, laboratory time, and engineering review hours. Provides data for change board decision-making
Cascade integration — when a requirement change triggers design modifications, Meridian auto-generates a draft ECR in Axiom Cascade with the requirement change as the justification and the re-verification scope as the implementation plan
Seconds
Full impact analysis from requirement change
Auto
Re-verification scope identification
Cost
Schedule impact estimation for change board
ECR
Auto-generated via Cascade integration
06
Coverage & Gap Intelligence
Orphan detection · Coverage mapping · Verification completeness · Maturity assessment
What you don't know about your requirements will hurt you. Requirements without design implementations are unmet promises. Design elements without governing requirements are uncontrolled scope. Verification activities without traceable requirements are wasted effort. Brindwell's Coverage & Gap Intelligence engine continuously scans the traceability graph for structural deficiencies: orphaned requirements (no downstream implementation), unjustified designs (no upstream requirement), verification gaps (requirement verified by method but no evidence), and stale links (artifact changed since verification was recorded). Each gap is categorized by severity, assigned to an owner, and tracked to closure.
Orphaned requirement detection — identifies requirements with no linked design implementation. These represent stated needs that the product does not address — either intentional descoping (which must be documented) or unintentional gaps
Unjustified design detection — identifies design elements (CAD assemblies, BOM components) with no governing requirement. These represent either undocumented requirements that should be captured or unnecessary complexity that should be removed
Verification completeness matrix — for every requirement: is the verification method assigned? Is the procedure defined? Is evidence recorded? Is the result evaluated? Is the evaluation approved? Each missing element is a gap that Meridian tracks
Program maturity dashboard — aggregates coverage and gap metrics into a single program maturity score: percentage of requirements with complete forward traces, percentage with verified evidence, percentage with approved evaluations. Tracks convergence toward readiness
Zero
Orphaned requirements or unjustified designs
5-level
Completeness check (method→procedure→evidence→result→approval)
Real-time
Continuous gap scanning and alerting
Score
Program maturity convergence tracking
07
Compliance Evidence Assembly
FDA DHF · AS9100D verification · IATF PPAP · DO-178C objectives · Submission-ready packaging
Regulatory compliance is fundamentally a requirements traceability exercise. FDA wants to see that every design input traces to a design output and every design output traces to verification evidence. AS9100D wants to see that every qualification requirement has a first-article inspection result. IATF 16949 wants to see that every product characteristic has a control plan linkage. DO-178C wants to see that every software requirement traces to test coverage. In traditional systems, assembling this evidence takes weeks of manual document extraction and cross-referencing. Because Meridian maintains the traceability graph natively, compliance packages are rendered from existing data — not assembled from scattered documents.
FDA Design History File — auto-generates the DHF from the traceability graph: design inputs (requirements) → design outputs (specifications, drawings) → verification records (test reports, simulation results) → validation evidence (clinical/field data). Complete, auditable, submission-ready
AS9100D qualification package — assembles first-article inspection evidence: requirement → design characteristic → inspection method → measurement result → disposition. Traces every qualification finding back to its governing requirement
IATF 16949 PPAP — generates production part approval documentation: customer requirements → design records → process flow → control plan → measurement system analysis → initial process study. All linked through the traceability graph
DO-178C objectives matrix — for software-intensive systems, maps DO-178C objectives to software requirements, design descriptions, source code, and test cases. Coverage analysis ensures every objective is satisfied at the appropriate DAL level
4
Regulatory frameworks (FDA, AS9100, IATF, DO-178C)
Auto
Compliance package rendered from digital thread
Days
Not weeks — for submission package generation
100%
Audit trail immutability for every trace link
08
Requirements Analytics & Health Scoring
Volatility tracking · Creep detection · Quality scoring · Program readiness assessment
Requirements are not static — they evolve throughout the program lifecycle. But uncontrolled requirements evolution is the leading cause of program cost overruns and schedule delays. Brindwell's Requirements Analytics engine quantifies requirements health: how many requirements have changed since baseline? What is the rate of requirement addition (creep)? Which requirements are the most volatile? Which stakeholders generate the most changes? Which requirements have the weakest verification evidence? The analytics engine transforms requirements management from a documentation exercise into a predictive intelligence capability — surfacing program risks that hide in the traceability data long before they manifest as cost and schedule impacts.
Requirements volatility index — tracks the rate of requirement changes over time. High volatility indicates unstable requirements that should be baselined before design investment continues. Volatility benchmarked against program phase norms
Creep detection and attribution — monitors net requirement growth (additions minus deletions) and attributes new requirements to their source: customer requests, regulatory changes, design discoveries, or test failures. Enables proactive scope management
Requirement quality scoring — NLP analysis scores each requirement for clarity, testability, atomicity, and freedom from ambiguity. Low-quality requirements flagged for rewrite before they propagate confusion into design and verification
Program readiness assessment — synthesizes traceability coverage, verification completeness, margin convergence, requirements stability, and gap closure rate into a composite readiness score. Provides data-driven input to milestone reviews and gate decisions
Index
Requirements volatility tracking with phase norms
NLP
Quality scoring (clarity, testability, atomicity)
Creep
Detection with source attribution
Gate
Readiness assessment for milestone reviews
DEPLOYMENT EVIDENCE

Three programs. Requirements transformed.

DEFENSE · SOFTWARE-DEFINED VEHICLE
Armored vehicle program achieves 100% V-model traceability across 3 engineering domains
2,400 system requirements · MCAD + ECAD + software · MIL-STD-882 safety critical
A next-generation armored vehicle program was managing mechanical requirements in DOORS, electrical requirements in Polarion, and software requirements in Jama — with no cross-domain traceability. Systems engineers maintained a 47-page traceability matrix in Excel that was perpetually six weeks out of date. After deploying Meridian with MBSE bridge integration to their Cameo Systems Modeler environment, all three requirement domains were unified in a single traceability graph. The SysML system model linked directly to MCAD assemblies, ECAD schematics, and software repositories. V-model verification coverage went from an estimated 72% to a measured 98.4%. Fourteen orphaned requirements and twenty-three unjustified design elements were discovered and resolved within the first 90 days.
98.4%
V-model verification coverage
3→1
Requirement domains unified
37
Gaps discovered and resolved (90 days)
MEDICAL DEVICES · FDA CLASS II
Surgical robotics company passes FDA audit with zero findings on design controls
680 design input requirements · ISO 13485 · IEC 62304 software lifecycle
A surgical robotics manufacturer was managing design inputs in a custom SharePoint system with manual traceability to design outputs maintained in Word documents. FDA auditors had cited the company for inadequate design control traceability in two consecutive inspections. After deploying Meridian, every design input requirement was linked to its design output, verification method, verification evidence, and validation record in a single graph. The compliance evidence assembly engine generated the complete Design History File in 4 days — replacing a 6-week manual process. The FDA's next inspection resulted in zero findings on design controls. The lead auditor noted that the traceability system was the most comprehensive she had reviewed.
Zero
FDA findings on design controls
4 days
DHF generation (down from 6 weeks)
680
Design inputs fully traced
AEROSPACE · SATELLITE SYSTEMS
Satellite constellation program detects 89 orphaned requirements before CDR — saving an estimated $12M in rework
4,200 system requirements · V-model verification · SysML-driven architecture
A LEO satellite constellation program with 4,200 system requirements was approaching Critical Design Review with a traceability matrix that the chief systems engineer described as "a fiction maintained for management consumption." After deploying Meridian and importing the complete requirement baseline, the coverage intelligence engine immediately identified 89 orphaned requirements with no design implementation and 142 verification gaps where methods were assigned but no evidence existed. The requirements analytics engine revealed a 34% volatility index in the thermal management subsystem — indicating unstable requirements that were driving continuous design churn. Addressing these gaps before CDR prevented an estimated $12M in post-CDR rework based on historical program data.
89
Orphaned requirements detected pre-CDR
$12M
Estimated rework avoided
34%
Volatility index flagged in thermal subsystem

"Our traceability matrix was a fiction. Everyone knew it. The chief engineer knew it. The program manager knew it. The customer knew it. It was a 47-page Excel spreadsheet that was perpetually six weeks out of date. Meridian replaced the fiction with truth. We have 2,400 requirements across mechanical, electrical, and software — and every single one is traced forward to its implementation and backward to its justification. When the CDR board asked for verification status, we showed them a live dashboard instead of a stale PDF. That changed the entire dynamic."

Chief Systems Engineer
ARMORED VEHICLE PROGRAM · MIL-STD-882 · 2,400 REQUIREMENTS

"The FDA auditor asked me to show her the traceability from design input number 247 to its verification evidence. In our old system, that would have taken 40 minutes of searching through SharePoint folders. In Meridian, I clicked on the requirement and the complete trace appeared: design input → design output → verification method → test procedure → test result → evaluation → approval. The auditor paused, looked at me, and said 'this is how it should work everywhere.' Zero findings."

VP of Regulatory & Quality Affairs
SURGICAL ROBOTICS · FDA CLASS II · IEC 62304

Stop guessing whether
your design satisfies
the requirement.

Import your requirements baseline. Watch Meridian build the traceability graph, detect gaps, score coverage, and render your V-model verification status — in minutes.

Or contact the Meridian requirements team at meridian@brindwell.com