Requirements Management in PLM: ReqIF, DOORS vs Jama vs Polarion and End-to-End Traceability (2026)

Most product programs do not fail because a requirement was missing. They fail because a requirement existed, was changed, and nobody could prove which part, which test and which supplier deliverable still depended on the old wording. Requirements management in PLM is the discipline of keeping that proof alive: every need expressed as a uniquely identified, versioned statement, linked to the design items that satisfy it and the verification evidence that closes it, across tools owned by different teams and companies.

It matters more in 2026 than it did a decade ago. Products are software-defined, variants multiply, suppliers deliver subsystems against exchanged requirement sets, and regulators in automotive, aerospace and medical devices expect traceable evidence rather than binders of documents. The tool you pick, and the way you connect it to the bill of materials (BOM), the change process and the test stack, decides whether an engineering change takes an afternoon or a month of impact-analysis meetings.

This article gives you a working model of the requirements hierarchy and link types, a mechanism-level view of ReqIF and OSLC, a fair comparison of IBM DOORS, Jama Connect and Siemens Polarion, a runnable trace-coverage script, and a migration playbook with the failure modes to watch.

What this covers: the requirements hierarchy and traceability model, standards (ISO/IEC/IEEE 29148, ReqIF, OSLC RM), ReqIF exchange mechanics and gotchas, a tool comparison and decision matrix, PLM and MBSE integration, a Python coverage report, and migration failure modes.

Context and Background

Requirements engineering as a formal discipline is codified in ISO/IEC/IEEE 29148, whose current edition is the 2018 revision. It describes the processes and information items for requirements across the life cycle and defines the characteristics of a well-formed requirement: necessary, appropriate, unambiguous, complete, singular, feasible, verifiable, correct and conforming. We will not reproduce the standard, which is paywalled, but those characteristics are the quality bar any tool’s review workflow should help enforce. A requirement that cannot be verified, for example, is a defect no traceability matrix can repair.

Historically, requirements lived in word processors and spreadsheets, then moved into dedicated databases. The incumbent in high-assurance engineering is IBM’s DOORS family. IBM now markets the offering as IBM Engineering Requirements Management, described on its product page as including DOORS Next, a web-based solution for collaboration and requirements change management, alongside the long-established DOORS used in high-compliance systems engineering. Jama Software’s Jama Connect and Siemens’ Polarion are the other two names that appear on most shortlists, and each approaches the problem from a different heritage: IBM from systems engineering and Rational, Jama from a requirements-and-risk focus with strong review workflows, and Polarion from application lifecycle management (ALM) with documents that behave like live databases.

The PLM side evolved separately. Product lifecycle management systems such as Teamcenter, Windchill, 3DEXPERIENCE and Aras own the parts, assemblies, BOMs and engineering change objects. For years the two worlds met through spreadsheets and email. The modern pattern is a digital thread in which requirements, design, change and test remain separate systems of record but are connected by typed, versioned links. If you have not read our overview, start with the digital thread PLM architecture guide, which frames why linking beats copying.

Two open standards make that linking feasible between vendors. ReqIF, the Requirements Interchange Format, is maintained by the Object Management Group (OMG). The OMG specification page lists version 1.2, published July 2016, preceded by 1.1 in October 2013 and 1.0.1 in April 2011, and ships machine-readable XML Schema files. It targets organizations that cannot share a single repository, such as an OEM and its supplier. OSLC, Open Services for Lifecycle Collaboration, is the complementary standard for live linking: its Requirements Management domain, version 2.1, was published as an OASIS Standard on 21 June 2021 under the namespace http://open-services.net/ns/rm#. In short, ReqIF moves content in bulk between files, and OSLC links resources in place over HTTP.

The rest of this article rests on that division of labor. Exchange is episodic and lossy by nature; integration is continuous and relational. Mature programs use both, and confuse neither.

The Reference Model: Hierarchy, Attributes, Baselines and Traceability

Direct answer: requirements management in a PLM context means maintaining a layered set of uniquely identified requirements (stakeholder, system, subsystem, verification), each with controlled attributes and change history, connected by typed links to design items, BOM lines and tests, and frozen into baselines so any release can be reconstructed and audited.

Figure 1: Requirements hierarchy with derivation links downward and verification evidence flowing back up to the stakeholder need.

Figure 1 shows the reference model. Read the solid arrows as decomposition and allocation: stakeholder needs are refined into system requirements, which are allocated to subsystems, hardware and software, and finally realized by design items such as BOM parts, software components and configuration parameters. The dashed arrows are the part teams forget: evidence flows upward. A subsystem test result only matters to the program because it rolls up to a system-level verification, which rolls up to the stakeholder need it was meant to satisfy.

The four layers and why they stay separate

Stakeholder requirements capture needs and constraints in the language of users, operators and regulators: “the operator can stop the line within a defined time.” System requirements restate the solution-independent “shall” behavior of the whole product. Subsystem requirements allocate that behavior to hardware, software and mechanical elements, and are where interface requirements live. Verification requirements, or more commonly the test cases and analyses that implement them, define how each requirement will be proven.

Keeping the layers separate is not bureaucracy. It is what makes change impact computable. When a regulator tightens a stakeholder constraint, the derivation links tell you exactly which system and subsystem statements to reopen. If everything is one flat list, every change is a global search and a meeting.

Attributes, baselines and change control

A requirement is more than text. Practical attribute sets include a stable unique identifier, status in a lifecycle (draft, in review, approved, implemented, verified, retired), priority, rationale, source, owner, verification method (test, analysis, inspection, demonstration) and an applicability expression for variants. The identifier must never be reused or recycled, because every external link and every supplier document points at it.

A baseline is an immutable, named snapshot of a set of requirements at specific versions, usually taken at a review gate. Baselines make three things possible: reproducing exactly what was agreed at preliminary design review, comparing two baselines to see what changed, and branching a stream for the next product generation. Change control wraps this: a proposed change to an approved requirement should arrive via a change request that records the impacted items, the approver and the resulting new version. Our article on engineering change management with ECR, ECO and ECN covers how that request object lives in the PLM side and how effectivity controls which serial numbers inherit the change.

Traceability: upstream, downstream and suspect links

Requirements traceability is the ability to follow a requirement forward to the things that realize and verify it, and backward to the need that justified it. Forward traceability prevents gold plating and uncovered requirements. Backward traceability prevents orphan requirements, statements that trace to no need and therefore no one can defend.

Two coverage metrics follow directly. Upstream coverage is the fraction of non-top-level requirements that have at least one derivation link to a parent. Verification coverage is the fraction of requirements that have at least one verification link to a test case, analysis or inspection record with a recorded result. Both are cheap to compute once links are typed, and we will compute them in code later.

The third concept is the suspect link. When an upstream requirement is edited, every link that depends on it should be flagged suspect: the downstream item has not necessarily become wrong, but a human must re-confirm it. Tools implement this differently. Some mark links suspect automatically when either end changes version; others require configuration or scripts. Suspect-link handling is the single most valuable feature in day-to-day impact analysis, and the one most often disabled because it generates noise. Treat that noise as signal about weak requirement boundaries rather than a reason to switch it off.

Where MBSE and SysML v2 fit

Model-based systems engineering (MBSE) does not replace requirements management; it gives requirements a structured home. In SysML v2 a requirement is a model element that can be related to the parts that satisfy it and the verification cases that verify it, so a “satisfy” relationship becomes a first-class edge in a model rather than a row in a matrix. In practice most organizations keep the authoritative requirement text in a requirements tool, represent the same requirement as a reference in the model, and synchronize through OSLC or an API. Our tutorial on SysML v2 MBSE and PLM integration walks through that boundary in detail. The design question is always which system is the master for the text and which for the structure, and the answer must be a single system per attribute.

Standards in Depth: ReqIF and OSLC RM

Standards are where marketing claims meet mechanics. Two matter here, and they solve different problems.

ReqIF mechanics

ReqIF is an XML-based exchange format. The OMG page confirms a normative CMOF model and the schema files reqif.xsd and driver.xsd; the file extension conventions (.reqif for the XML and .reqifz for a zip bundle that may carry attachments) are common practice among tools, and you should verify the exact packaging in your toolchain’s documentation. The conceptual structure is consistent across implementations and is what matters when you debug an exchange.

Figure 2: ReqIF exchange. Types and definitions travel with the data; identifiers and links are re-resolved on import.

At the center are four kinds of content. Spec types define the schema: what kinds of objects exist, what attributes they carry and their data types, including enumerations. Spec objects are the individual requirements, each with a globally unique identifier and attribute values. Spec relations are typed links between spec objects. Specifications are hierarchical trees that arrange spec objects into document-like structures with headings and ordering. Because the schema travels with the data, a receiving tool can in principle understand a file it has never seen.

Two properties of the format drive most real-world pain. First, ReqIF carries a snapshot, not a history. There is no built-in concept of the previous version of an object, only a last-change timestamp and an identifier. Second, ReqIF is deliberately tool-neutral, so it cannot express a tool’s native features: workflow states, review comments, suspect flags, variant expressions, or embedded diagrams may be dropped, flattened or mapped to a convention you have to agree on.

The ReqIF round trip and its gotchas

The headline use case is the OEM-to-supplier loop. The OEM exports a requirements set, the supplier imports it into their tool, adds responses such as compliance status and comments, exports back, and the OEM merges the response. Jama Software describes its Interchange for ReqIF product as supporting import, export and update of requirements and metadata between customers and suppliers, and as a means of migrating from other ReqIF-compliant tools. Siemens documents ReqIF as one of three methods, with the Polarion Import function and the Synchronizer, for exchanging data between DOORS Classic and Polarion. Note what vendor pages do not promise: lossless fidelity. The literature and our own practice agree that the round trip is where problems appear.

The recurring gotchas are these.

Identifier mapping. Each tool has its own human-readable IDs (for example a module-scoped integer) and ReqIF has a global identifier. If the importing tool generates new internal IDs and does not store the original ReqIF identifier in an attribute, the next update cannot match objects and will create duplicates. Always map the ReqIF identifier to a dedicated, read-only attribute on first import.

Datatype and enumeration drift. A priority enumeration with values High, Medium and Low in one tool may arrive as plain strings in another. Rich text is the worst case: ReqIF carries XHTML content, and tools differ in what markup they preserve, so tables and images are the first casualties.

Link semantics. ReqIF spec relations carry a type, but there is no standard vocabulary for “derives from” versus “verifies.” Two organizations can export identical-looking links with opposite directions. Agree on the link-type dictionary and direction before the first exchange, and test it on a ten-requirement sample.

Hierarchy versus identity. A requirement that appears in two specifications is one object with two placements in ReqIF, but many tools model a requirement as belonging to exactly one document. Import can silently duplicate it.

Delta handling. Because there is no history, the receiver must compute the diff between the new file and its own state. That requires stable identifiers and a rule for who wins when both sides edited the same attribute. Without a rule, the last importer wins, and nobody notices until audit.

OSLC RM and live linking

OSLC takes the opposite approach: do not copy, link. Each tool exposes its artifacts as web resources with stable URLs, described in RDF. The OSLC RM 2.1 specification defines two main resource types, Requirement and RequirementCollection, and a vocabulary whose link properties cover the relationships a traceability model needs. Per the vocabulary page, the properties in the oslc_rm namespace are affectedBy, constrainedBy, constrains, decomposedBy, decomposes, elaboratedBy, elaborates, implementedBy, satisfiedBy, satisfies, specifiedBy, specifies, trackedBy, uses and validatedBy. Notice the pairing: most links come with an inverse, so the same relationship can be stored once and navigated from both ends.

The practical power of OSLC is delegated UI and picker dialogs. From a work item in a change tool you can open a selection dialog hosted by the requirements tool, pick a requirement, and store its URL as a link, with hover previews showing live status. The requirement stays in the requirements tool; only the link and a cached label live elsewhere. That is the mechanism behind OSLC-based digital thread links in tools like Polarion, DOORS Next and several PLM platforms.

OSLC is not magic. Both ends need an OSLC provider or consumer implementation, authentication has to work across them (commonly OAuth or a shared identity provider), and links are only as stable as the URLs behind them. Version-specific linking, pointing at a requirement at a given baseline rather than its current state, depends on configuration management support in each tool, which varies. We return to this in the trade-offs section.

The Tool Landscape Compared: DOORS vs Jama vs Polarion

Direct answer: in the DOORS vs Jama vs Polarion decision, IBM’s offering fits large, long-lived systems programs that need configuration management and an existing IBM toolchain; Jama Connect fits organizations that prize review workflows, risk linkage and quick onboarding; and Polarion fits teams that want requirements, work items, tests and documents in one ALM, especially inside the Siemens ecosystem.

A fair comparison starts by saying what is verified and what is not. Product naming and packaging change, and pricing is negotiated and rarely published, so this article gives none. What follows relies on vendor pages and standards text read for this edition, with our judgment labelled as such.

IBM Engineering Requirements Management (DOORS and DOORS Next)

IBM’s product page describes IBM Engineering Requirements Management as spanning DOORS Next and DOORS, with features that include rich text and a glossary of terms, graphical sketching, a graphical explorer for visualizing relationships, structured folders and modules with filtering, views and tags, and configuration and variant management with global configurations, component reuse and multiple development streams. IBM also lists AI automations such as quality scoring against industry standards. The page does not state version numbers or lifecycle dates, so confirm the supported release and any end-of-support schedule for DOORS 9 against IBM’s support documentation before committing to a long program.

The architectural distinction worth understanding is between the two products. DOORS is the older module-based, client-driven database that many aerospace, defense and automotive organizations have accumulated tens of thousands of requirements in, often with extensive DXL (DOORS eXtension Language) scripting. DOORS Next is the web-based successor in the same family, built on the Jazz platform, which is where IBM’s OSLC integrations, global configuration management and links across lifecycle tools are concentrated. Our reading is that this makes DOORS Next the better integration target and DOORS the harder migration source: the scripts, layouts and implicit conventions in a mature DOORS database are the real asset and the real liability.

Strengths: depth in systems engineering practice, mature baselining and configuration concepts, deep ties to IBM’s modeling and test tools, and a very large installed base, which means ReqIF import and export has been exercised against it more than against most. Limits: a heavier administrative footprint, and a learning curve that is steeper than lighter tools.

Jama Connect

Jama Software positions Jama Connect around live traceability and structured reviews. Its ReqIF datasheet describes an Interchange for ReqIF capability to import, export and update requirements and metadata and to migrate from other ReqIF-compliant tools, and the vendor’s support site documents a Data Exchange user guide. We did not find, in the pages read, a statement of exactly which ReqIF attributes survive a round trip, so test that with your own sample.

In our experience of how teams describe it, Jama’s differentiators are an approachable web interface, review and approval workflows with electronic sign-off, and trace views that make coverage visible to non-specialists. That is a qualitative judgment, not a measured finding. Its center of gravity is requirements, risk and test management rather than being a full ALM with source control and build integration, so software-heavy organizations typically pair it with Jira and a CI system and connect them by integration.

Siemens Polarion

Siemens describes Polarion as supporting classical, agile or hybrid working models, managing workflow, quality and project management processes, offering live statistics dashboards to visualize traceability, and integrating with other systems through connectors, with OSLC to Teamcenter given as an example. Siemens’ blog also documents three routes for moving data between DOORS Classic and Polarion: the ReqIF function, the Polarion Import function and the Synchronizer. On naming, Siemens’ own blog lists releases as Polarion ALM and Polarion X, the SaaS edition, using matching version numbers, with Polarion X 2606 described as the latest SaaS release built on Polarion ALM 2606 as of the blog post we read.

The conceptual hallmark of Polarion is that everything is a work item stored in one repository, and documents (LiveDocs) are views over those work items. A requirement can appear in a document and also in a query-driven report. Because the underlying store is a version-controlled repository, baselining and branching of documents follow naturally. Strengths: unified traceability across requirements, tasks and tests, flexible configuration, and an obvious fit when Teamcenter is your PLM. Limits: the flexibility cuts both ways, since a Polarion project’s data model is whatever your administrators built, so governance matters more.

Others exist: Codebeamer from PTC, Visure, ReqView, Modern Requirements and a number of open-source tools. We have not verified current product details for them this edition and so do not rate them here.

A decision matrix

The matrix below summarizes our judgments for common situations. It is opinion informed by the vendor material above, not a benchmark, and “strong” means “a good default to evaluate first,” not a guarantee.

Situation	IBM DOORS / DOORS Next	Jama Connect	Siemens Polarion
Large legacy DOORS estate, scripts and modules	Strong: stay or move within family	Possible via ReqIF, expect rework	Possible via ReqIF, Import or Synchronizer, expect rework
Supplier exchange via ReqIF	Strong, widely exercised	Dedicated Interchange for ReqIF	ReqIF supported, verify attribute fidelity
Teamcenter as PLM	Via OSLC or custom connectors	Via integration layer	Strong, OSLC to Teamcenter cited by Siemens
Software-heavy ALM with tests and tasks	Needs companion tools	Pair with Jira and CI	Strong, single repository model
Fast onboarding for mixed teams	Moderate	Strong, in our judgment	Moderate, depends on administration
Regulated evidence (electronic sign-off, audit trail)	Strong	Strong	Strong, validate configuration
Variant and product-line reuse	Strong configuration concepts	Moderate, verify	Moderate to strong, verify

Use the matrix to produce a shortlist of two, then run a structured proof of concept using your own data, which we describe in the recommendations. A matrix cannot capture the factor that actually decides most selections: which tool your PLM, change and test systems already integrate with.

Linking Requirements to PLM, Change and Test

The value of a requirements database is realized only when it connects to where the product is defined and proven. The integration question has four edges: requirements to PLM items and BOM, requirements to change objects, requirements to tests, and requirements to models.

Figure 3: Link topology. The requirements tool is the provider for validatedBy, implementedBy, satisfiedBy and elaboratedBy links, and a baseline snapshots the linked versions.

Requirements to PLM items and the BOM

The most useful link is satisfiedBy from a requirement to the design item that realizes it: a part, an assembly, a software component or a configuration item. In PLM this usually means a link from a requirement to an item revision, not just an item, because a requirement verified against revision B says nothing about revision C. Where the PLM system exposes OSLC provider endpoints, the link can be created through the standard picker. Where it does not, most PLM platforms offer REST or SOAP-style APIs, and integration vendors or custom middleware store the link on either side or in a third link-store. Vendor APIs differ, and we have not verified specific endpoints here, so consult each product’s integration documentation.

A design caution: link to the structure that carries the requirement, not to every leaf. Linking a system-level requirement to hundreds of BOM lines creates link noise and makes suspect flags meaningless. Link at the subsystem or assembly level and let the BOM hierarchy express the rest.

Requirements to change and effectivity

Changes to an approved requirement should reference the change object, and the change object should reference the requirements it affects. OSLC defines affectedBy and trackedBy on the RM side precisely for this pairing with change management. The PLM-side change record, such as an engineering change request, then carries the affected items and effectivity, as described in the earlier change management article. The integration test is simple: can you start from a requirement and list every open change touching it, and start from a change and list every requirement it alters? If either direction requires a human, the link is missing.

Requirements to tests and evidence

The validatedBy and verification links connect requirements to test cases and results. The important design choice is whether the link points at the test definition or at a specific execution. Compliance evidence requires the latter: a particular run, on a particular software build and hardware revision, with a recorded outcome. Linking only to test definitions lets a requirement look verified while the last execution failed or never happened. Verification coverage should therefore be computed from links to results, not merely to test cases.

Baselines across tools

The hardest problem is a cross-tool baseline. A requirement baseline is easy inside one tool. A product baseline needs the requirement versions, the PLM item revisions, the model version and the test results to be recorded together, so that a year later you can say what was true. OSLC configuration management extensions exist for this purpose, but support is uneven. A pragmatic approach, which we have seen work, is to create a baseline object in the system of record for releases (often PLM) that stores references to the baseline identifiers in each connected tool, plus a hash of an exported manifest. It is not elegant, but it is auditable.

A Runnable Trace-Coverage Report

The script below parses a minimal ReqIF-like XML document and computes the two coverage metrics, upstream coverage and verification coverage, plus dangling links. It uses only the Python standard library. The sample is deliberately small and is not a complete ReqIF file: real files carry attribute definitions, specification hierarchies, header metadata and XHTML content. The namespace shown is the one commonly used in ReqIF 1.x files; verify it against the files your tools produce.

import xml.etree.ElementTree as ET
from collections import defaultdict

NS = {"r": "http://www.omg.org/spec/ReqIF/20110401/reqif.xsd"}

SAMPLE = """<?xml version="1.0" encoding="UTF-8"?>
<REQ-IF xmlns="http://www.omg.org/spec/ReqIF/20110401/reqif.xsd">
 <CORE-CONTENT><REQ-IF-CONTENT>
  <SPEC-TYPES>
   <SPEC-OBJECT-TYPE IDENTIFIER="T-SYS" LONG-NAME="SystemReq"/>
   <SPEC-OBJECT-TYPE IDENTIFIER="T-TST" LONG-NAME="TestCase"/>
   <SPEC-OBJECT-TYPE IDENTIFIER="T-SUB" LONG-NAME="SubsystemReq"/>
   <SPEC-RELATION-TYPE IDENTIFIER="REL-DERIVE" LONG-NAME="derivedFrom"/>
   <SPEC-RELATION-TYPE IDENTIFIER="REL-VERIFY" LONG-NAME="verifiedBy"/>
  </SPEC-TYPES>
  <SPEC-OBJECTS>
   <SPEC-OBJECT IDENTIFIER="SYS-1" LONG-NAME="Brake response"><TYPE><SPEC-OBJECT-TYPE-REF>T-SYS</SPEC-OBJECT-TYPE-REF></TYPE></SPEC-OBJECT>
   <SPEC-OBJECT IDENTIFIER="SYS-2" LONG-NAME="Pressure range"><TYPE><SPEC-OBJECT-TYPE-REF>T-SYS</SPEC-OBJECT-TYPE-REF></TYPE></SPEC-OBJECT>
   <SPEC-OBJECT IDENTIFIER="SUB-1" LONG-NAME="Valve timing"><TYPE><SPEC-OBJECT-TYPE-REF>T-SUB</SPEC-OBJECT-TYPE-REF></TYPE></SPEC-OBJECT>
   <SPEC-OBJECT IDENTIFIER="SUB-2" LONG-NAME="Sensor accuracy"><TYPE><SPEC-OBJECT-TYPE-REF>T-SUB</SPEC-OBJECT-TYPE-REF></TYPE></SPEC-OBJECT>
   <SPEC-OBJECT IDENTIFIER="TC-1" LONG-NAME="Bench timing test"><TYPE><SPEC-OBJECT-TYPE-REF>T-TST</SPEC-OBJECT-TYPE-REF></TYPE></SPEC-OBJECT>
  </SPEC-OBJECTS>
  <SPEC-RELATIONS>
   <SPEC-RELATION IDENTIFIER="R1"><TYPE><SPEC-RELATION-TYPE-REF>REL-DERIVE</SPEC-RELATION-TYPE-REF></TYPE><SOURCE><SPEC-OBJECT-REF>SUB-1</SPEC-OBJECT-REF></SOURCE><TARGET><SPEC-OBJECT-REF>SYS-1</SPEC-OBJECT-REF></TARGET></SPEC-RELATION>
   <SPEC-RELATION IDENTIFIER="R2"><TYPE><SPEC-RELATION-TYPE-REF>REL-VERIFY</SPEC-RELATION-TYPE-REF></TYPE><SOURCE><SPEC-OBJECT-REF>SUB-1</SPEC-OBJECT-REF></SOURCE><TARGET><SPEC-OBJECT-REF>TC-1</SPEC-OBJECT-REF></TARGET></SPEC-RELATION>
   <SPEC-RELATION IDENTIFIER="R3"><TYPE><SPEC-RELATION-TYPE-REF>REL-DERIVE</SPEC-RELATION-TYPE-REF></TYPE><SOURCE><SPEC-OBJECT-REF>SUB-2</SPEC-OBJECT-REF></SOURCE><TARGET><SPEC-OBJECT-REF>GHOST-9</SPEC-OBJECT-REF></TARGET></SPEC-RELATION>
  </SPEC-RELATIONS>
 </REQ-IF-CONTENT></CORE-CONTENT>
</REQ-IF>"""

def q(tag):
    return "{%s}%s" % (NS["r"], tag)

def parse(xml_text):
    root = ET.fromstring(xml_text)
    types = {e.get("IDENTIFIER"): e.get("LONG-NAME")
             for e in root.iter()
             if e.tag in (q("SPEC-OBJECT-TYPE"), q("SPEC-RELATION-TYPE"))}
    objs = {}
    for o in root.iter(q("SPEC-OBJECT")):
        ref = o.find("r:TYPE/r:SPEC-OBJECT-TYPE-REF", NS).text
        objs[o.get("IDENTIFIER")] = (o.get("LONG-NAME"), types[ref])
    rels = []
    for r in root.iter(q("SPEC-RELATION")):
        rt = types[r.find("r:TYPE/r:SPEC-RELATION-TYPE-REF", NS).text]
        s = r.find("r:SOURCE/r:SPEC-OBJECT-REF", NS).text
        t = r.find("r:TARGET/r:SPEC-OBJECT-REF", NS).text
        rels.append((rt, s, t))
    return objs, rels

def report(objs, rels):
    up, down, broken = defaultdict(set), defaultdict(set), []
    for rt, s, t in rels:
        if s not in objs or t not in objs:
            broken.append((rt, s, t))
            continue
        if rt == "derivedFrom":
            up[s].add(t)
        elif rt == "verifiedBy":
            down[s].add(t)
    reqs = [i for i, (_, ty) in objs.items() if ty.endswith("Req")]
    non_top = [i for i in reqs if objs[i][1] != "SystemReq"]
    orphan = [i for i in non_top if not up[i]]
    unverified = [i for i in reqs if not down[i]]
    print(f"requirements={len(reqs)} relations={len(rels)}")
    print(f"upstream coverage   {1 - len(orphan)/len(non_top):.0%}  orphans={orphan}")
    print(f"verification cover  {1 - len(unverified)/len(reqs):.0%}  unverified={unverified}")
    print(f"dangling links      {broken}")

if __name__ == "__main__":
    report(*parse(SAMPLE))

Running it prints four requirements and three relations, upstream coverage of 50 percent with SUB-2 flagged as an orphan (its only derivation link points at a non-existent object), verification coverage of 25 percent with three unverified requirements, and one dangling link to GHOST-9. Those numbers are illustrative output from a toy file, but the logic is exactly what a real CI gate would run.

Turning the script into a gate

Three extensions make it production-worthy. First, read real files by walking attribute values (the ATTRIBUTE-VALUE elements, which the sample omits) so you can filter on status and ignore retired requirements. Second, treat the thresholds as policy: for example, block a release candidate baseline if verification coverage of safety-relevant requirements is below 100 percent, while allowing a lower bar for draft-stage baselines. Third, emit the report as an artifact attached to the baseline so the evidence is frozen with the data it describes. Running this in continuous integration against a nightly export converts traceability from a pre-audit scramble into a daily metric, and the most common first discovery is dangling links created by an earlier migration.

Figure 4: Migration playbook. The round-trip diff gate loops back to schema mapping until the pilot comes through clean.

Migration Playbook and Failure Modes

Tool migration is where requirements programs most often lose years of accumulated traceability. Figure 4 shows a sequence that has worked in practice, and the reasoning behind each step matters more than the diagram.

Inventory first. List every module or document, its approximate object count, the link types actually in use, the scripts or layouts that encode conventions, and the external consumers (suppliers, auditors, other tools) that reference identifiers. In a mature database the scripts often encode rules that nobody wrote down, such as an attribute that is computed rather than stored.

Map the schema deliberately. Decide for each source attribute whether it maps to a target attribute, becomes a tag, is dropped, or is archived as text. Resolve enumerations explicitly. The mapping document is a deliverable that you will need again when something looks wrong in six months.

Pilot with one module and demand a clean round trip. Export a module, import it into the target, export it again, and diff the two files. The diff tells you what the target silently changes. Do this before touching the bulk, because the failure modes you find are the ones that would have corrupted thousands of objects. Preserve the original ReqIF identifier in an attribute so later delta imports can match.

Migrate by baseline, not by current state. If auditors may ask about the state at a past release, migrate the baselines in order, oldest first, or at minimum keep the legacy system read-only and reachable. Migrating only the latest state discards the history that justifies the present text.

Rebuild and verify links last, with the coverage script. Links are the most valuable and most fragile part. After import, run the coverage report on both source and target exports and compare the numbers. A drop in coverage is a migration defect until proven otherwise.

Freeze, do not delete, the legacy system. Keep it read-only for the period your regulator or contract requires.

The failure modes to expect

Orphan requirements arise when derivation links are not maintained during change. They look harmless and accumulate until a verification review cannot say why a requirement exists. Link rot is the web-scale cousin: with OSLC, links are URLs, and renaming a project, moving a server or retiring a tool breaks them silently. Mitigate with stable URL policies, redirects, and periodic link-checking jobs.

Baseline explosion occurs when teams snapshot at every minor change and end up with hundreds of baselines no one can interpret. Baseline at review gates and releases, name them by gate, and use change history, not baselines, for fine-grained tracking. Suspect-link fatigue, described earlier, is the human version: the signal drowns in noise until the flag is disabled. Finally, tool-driven requirement style: requirements written as whatever fits a template field, or split into dozens of fragments to get a green coverage number. Coverage metrics measure link presence, not requirement quality, and optimizing the metric is a classic way to defeat its purpose.

Trade-offs, Gotchas, and What Goes Wrong

Every architecture choice here trades one cost for another, and the honest version of the story includes the costs.

Exchange versus integration is the first trade-off. ReqIF files are portable, auditable as artifacts and work across organizational boundaries, but they are snapshots that go stale the moment they are written. OSLC links are live and relational, but they require compatible providers, shared identity and network reachability between companies that may not trust each other. A supplier will rarely open a firewall to your requirements tool, so the realistic cross-company pattern is ReqIF at the boundary and OSLC inside each organization.

Single master versus synchronized copies is the second. Keeping requirement text in exactly one system and referencing it elsewhere is clean, but it makes every consumer dependent on that system’s availability and API. Copying text into the model or the PLM item avoids that dependency and creates a synchronization problem with all the failure modes of any replicated data. Our default is a single master per attribute and cached read-only labels elsewhere.

Granularity is the third. Fine-grained requirements make verification precise and coverage numbers meaningful; they also multiply links and maintenance. Coarse requirements are cheap to maintain and hide unverified detail. A useful rule is to write each requirement at the level where one verification activity can pass or fail it.

Regulated domains add obligations without changing the mechanics. Standards such as ISO 26262 for road vehicles, DO-178C for airborne software and IEC 62304 for medical device software all expect bidirectional traceability between requirements, design and verification evidence, along with controlled change. We mention them only generally: the specific work-product and clause requirements depend on the standard edition, the assurance level and your regulator, and you should read the current text rather than rely on a summary. Note too that tool vendors may offer qualification kits or evidence packages, but qualifying a tool for use in a certified process remains your responsibility to scope and justify.

Finally, beware of tool-led process. Buying a tool does not create a requirements practice. The most common root cause we see behind traceability failures is not a tool defect but unowned links: no one is responsible for keeping them current, so they decay. Assign ownership of the link set the way you assign ownership of the requirement set.

Practical Recommendations

Start with the graph, not the product. Write down the artifact types you must connect (stakeholder need, system requirement, subsystem requirement, design item, change object, test case, test result) and the link types between them, with direction. Fewer than ten link types is a good target. This dictionary is the contract for ReqIF exchange, OSLC configuration and coverage reports alike.

Pick the master system for each attribute before you pick a tool. If your PLM is Teamcenter, evaluate how Polarion’s OSLC connection fits. If you hold a large DOORS estate, price the migration, not just the licenses. If suppliers use several tools, make ReqIF round-trip fidelity a pass-fail criterion in your proof of concept, using your own files.

Run a proof of concept on real data for two to four weeks, with exit criteria written in advance: a clean round trip on a representative module, coverage numbers matching between source and target, suspect-link behavior demonstrated, a baseline created and compared, and an OSLC link created from a change item and followed from the requirement side.

Automate the metrics. A nightly coverage report like the script above costs little and changes behavior, because teams respond to numbers they see daily. Gate release baselines on verification coverage for safety-relevant requirements and keep exceptions explicit and signed.

Checklist:

Link-type dictionary with directions agreed and documented
Unique, never-reused requirement IDs, with the ReqIF identifier stored as an attribute
One master system named per attribute
Baselines only at review gates and releases, named by gate
Suspect-link handling enabled and triaged, not disabled
Verification links point at executed results, not only test definitions
Nightly coverage report with dangling-link detection
Cross-tool release baseline recorded in the system of record
Legacy system retained read-only for the required retention period
Named owner for the link set

Frequently Asked Questions

What is requirements management in PLM?

It is the practice of managing requirements as controlled, versioned, linked information inside the product lifecycle rather than as standalone documents. Each requirement has a unique identifier, attributes, a status and history, and typed links to the design items, BOM lines, change records and tests that realize and verify it. Baselines freeze the set at review gates. The result is that a change to a requirement can be traced to its affected parts and evidence, and a release can be reconstructed during audit.

What is ReqIF and what is it used for?

ReqIF, the Requirements Interchange Format, is an OMG standard for exchanging requirements between tools and organizations that cannot share one repository. The current formal version listed by OMG is 1.2, from July 2016. A file carries a schema of types, the requirement objects, typed relations and document hierarchies. It is commonly used for OEM-to-supplier exchange and for migration between tools, but it transports snapshots and cannot carry every tool-specific feature.

How do DOORS, Jama Connect and Polarion differ?

IBM’s offering, spanning DOORS and DOORS Next, has deep systems-engineering heritage, configuration management and a large installed base. Jama Connect emphasizes live traceability, review workflows and approachable use, with a dedicated ReqIF interchange product. Polarion is an ALM in which requirements are work items in one repository and documents are live views, with OSLC links to Teamcenter cited by Siemens. The right choice depends mostly on your PLM, existing estate and supplier tooling, so test with your own data.

Do I need OSLC if I already use ReqIF?

They solve different problems. ReqIF moves requirement content in bulk across organizational boundaries and is episodic. OSLC creates live links between artifacts in different tools, so a test, change request or PLM item can reference a requirement without copying it. Inside one company with several lifecycle tools, OSLC or equivalent vendor APIs give continuous traceability; at a supplier boundary, ReqIF is usually the practical choice. Many mature programs use both.

How do I measure requirements traceability?

Compute two basic coverage metrics from typed links: upstream coverage, the share of non-top-level requirements with at least one parent, and verification coverage, the share of requirements linked to a test, analysis or inspection with a recorded result. Add counts of suspect and dangling links. Measure per baseline and trend over time. Remember that coverage measures link presence, not requirement quality, so pair it with reviews against the characteristics in ISO/IEC/IEEE 29148.

How should requirements relate to SysML v2 models?

Treat the requirements tool and the model as complementary. The tool usually holds the authoritative text, attributes and approval history; the model holds structure and relationships such as which part satisfies which requirement. Represent each requirement in the model by reference and synchronize through OSLC or an API, with a single master per attribute. Avoid editing text in both places, which creates conflicting versions and defeats baselining.