Requirements that connect to something

What it is, and what it is not

Requirements as first-class objects with hierarchy, rationale, priority, a verification method and acceptance criteria — linked to the parts that satisfy them, the tests that verify them, and the evidence those tests produced.

It is not a document with numbered paragraphs. A specification in a PDF is readable and unlinkable: nothing can traverse from a requirement to the part that satisfies it, so the question an audit asks has to be answered by a person reading two documents side by side.

It is also not a full MBSE environment. System modelling, behavioural simulation and architecture description languages are a different discipline with their own tools, and Manufacturing PLM links to that work rather than attempting it.

The mechanism: four links, and the gaps between them

A requirement connects outward in four directions, and each link is a typed relationship in the same graph everything else uses.

Satisfied by a part, an assembly or a software component. Verified by a test case, with a stated method — inspection, analysis, demonstration or test. Evidenced by a result at a revision: a report, a measurement set, a signed record. Affected by any change that touched the objects on the other end of the first three.

The traceability matrix is useful because it shows the holes. A tidy grid where every requirement has a green tick is a grid somebody has filled in; the valuable output is the seven requirements with no verification method, the three verified by a test whose evidence predates the last two changes, and the one satisfied by a part that has since been superseded.

Gap detection runs automatically rather than being a report somebody remembers to generate — because the requirement most likely to be unverified is the one nobody has thought about recently.

The failure it prevents

A customer asks whether a change made eighteen months ago invalidated the qualification they signed off. Answering it means knowing what the qualification covered, which revisions were current then, what has changed since, and whether any of it touched the characteristics the qualification tested.

In most organisations that is answered by finding the two people who were there. If one has left, it becomes a week of reading, and the confidence at the end is low enough that the safe response is to re-qualify — which costs more than the original change did.

With requirements linked to tests linked to evidence at revisions, it is a traversal. The answer may still be that the qualification is invalid; what changes is that the organisation knows cheaply, rather than paying for certainty it could have looked up.

How it meets the rest of the product

Impact analysis includes requirements. A change to a part surfaces the requirements it satisfies, so a reviewer sees that a component substitution touches a thermal requirement before approving it rather than after.

Evidence lives in the vault with revisions and controlled distribution, so a test report is a controlled document rather than a file on a share. The evidence link names the revision, which is what makes the it-still-applies question answerable at all.

The Requirements Agent works this surface at whatever tier you set: flagging ambiguity, conflicts between requirements, duplication, untestable statements and missing acceptance criteria. Those are the failure modes that produce a requirement nobody can verify, and they are cheapest to catch at authoring.

The model was deliberately built general enough to carry a medical design-controls package later without re-modelling — traceability from need to requirement to test to evidence is already the shape of the data.

How it meets your ERP

Requirements do not publish to your ERP and there is no sensible reason they would. An ERP plans and transacts; it has no consumer for an acceptance criterion, and copying one across would create a second record nobody maintains.

The genuine intersection is through the parts. A requirement satisfied by a part that has just been superseded is a gap, and whether that part has stock and open purchase orders behind it is your ERP's answer — which appears in the impact set alongside the requirement gap rather than in a separate conversation.

Verification evidence sometimes concerns a specific lot or batch, and where the connector exposes lot data the evidence can reference it. That is a read: Manufacturing PLM records which lot the evidence concerns and does not attempt to manage the lot.

Where the boundary is

This is not design controls. A structured design history file covering user needs, design inputs and outputs, review, verification, validation and transfer does not exist here today. The requirements model was built to carry that package later, and later is not now — a device manufacturer should read the medical devices page before going further.

There is also no test execution. Manufacturing PLM holds the test case, the method, the acceptance criteria and the evidence; running the test and capturing measurements happens in a lab system or an MES, and the result flows in as a controlled document.