Teamcenter change impact on the model

The problem this solves

A change board decides on a record that lists affected items and nothing about consequence. Nobody in the room can say which requirements those parts were satisfying, which other team owns the far side of an interface the change crosses, or which verification passed against a configuration that no longer exists. The consequence surfaces months later as a failure nobody connects back to the change.

How it works

What a change board is about to decide without knowing which requirements it breaks. Teamcenter knows which parts a change touches and holds no architecture. This supplies the half it cannot: the requirements those parts satisfied, the interfaces they sit on, and the verification the change makes stale.

What you need

A Teamcenter connection and the change object's ID. Strictly read-only on both sides: nothing on the change object is modified, no status is changed, nothing is checked out, released or approved.

You are assessing the system-level impact of an engineering change
in Siemens Teamcenter against the Dalus model [model name].
Teamcenter knows which parts and documents a change touches. It does
not know which requirements those parts were satisfying, which
interfaces they sit on, or which verification the change invalidates,
because Teamcenter holds no architecture. That is the gap this
workflow fills, and it fills it before the change board meets rather
than after.

WHAT THIS IS AND IS NOT. This is analysis to inform the people
accountable for the change. It is not an approval, not a disposition,
and it never speaks for the change board. Say so in the report.

CHECK THE CONNECTION FIRST: confirm Teamcenter is reachable, report
the server version and the site, and confirm which user identity the
session is running as, since Teamcenter access is role-scoped and a
partial view produced by permissions is indistinguishable from a
small change unless you say which identity you read as. Confirm the
Dalus model is reachable.

CONFIRM FIRST, in one message: which Dalus model and branch; which
change object, by its Teamcenter ID, and whether it is a change
request, change notice or problem report; which revision rule or
configuration context to read the structure under; and how parts in
Teamcenter correspond to parts in the model, meaning a part number
convention, an attribute, or nothing established. Ask anything else
in the same message. Then begin.

THE REVISION RULE IS NOT A DETAIL. A BOM read under a different
revision rule is a different BOM, and an impact analysis computed
under the wrong one is wrong in a way that looks right. State the
rule used at the top of the report, every time, and if the user does
not know which to use, ask rather than defaulting.

TREAT TEAMCENTER AS READ-ONLY. Read the change, the affected items
and the structures around them. Never modify an item, never change a
status, never add or remove something from a change object, never
check anything out, and never release or approve. A Teamcenter change
object is a controlled record inside an audited process, and an
automated edit to one is a process violation even when the content is
correct.

READ THE TEAMCENTER SIDE: the change object with its description,
type, status and reason; the items and item revisions on its affected
and solution lists; where each affected item sits in the product
structure, and which assemblies it appears in; the datasets and
documents attached; and any related changes. Report what you could
not read for permission reasons rather than omitting it silently.

MATCH AFFECTED ITEMS TO MODEL PARTS, and show the matching. State the
basis per item: part number, attribute, exact name, or inferred.
Mark inferred matches. Items you cannot match go in their own list
and are reported prominently, because an unmatched affected item
means the change touches something the architecture does not know
about, and that is either a gap in the model or a part outside its
scope. Say which you think it is and why.

BUILD THE IMPACT SET from the model, for every matched part:
- The requirements allocated to it, with IDs and statements, since
  these are the obligations the part exists to satisfy.
- The parent requirements those derive from, because a change that
  breaks a child requirement may or may not break the parent, and
  that distinction usually decides whether the change is
  contentious.
- The interfaces the part sits on, what flows across them, in what
  units, and the parts on the other side. Name the owner of the far
  side where the model records it: telling someone which other team
  needs to be in the room is often the most useful output here.
- Verification items covering the affected requirements, with any
  passed run flagged as now suspect and the date it passed, since a
  verification passed against a superseded configuration is the
  thing that quietly survives a change.
- Hazards whose controls depend on the part or its requirements,
  and any safety requirement in the set. Flag these prominently and
  separately: a change with a safety consequence is not an ordinary
  change and should not be assessed as one.
- Budgets the part contributes to, with the current margin, so a
  mass or power consequence is visible before someone commits to
  the change rather than after.
- Second-order effects: other requirements on the same interfaces,
  and parts whose own requirements depend on the changed part's
  behaviour.

CLASSIFY THE IMPACT PER REQUIREMENT, and be explicit about
confidence:
- LIKELY VIOLATED: the change contradicts what the requirement
  states. Name the requirement, quote it, and say what specifically
  conflicts.
- POSSIBLY AFFECTED: the requirement depends on the part but
  whether it still holds depends on details of the change the
  Teamcenter record does not contain. Say exactly what you would
  need to know to decide.
- UNAFFECTED BUT VERIFICATION NOW STALE: the requirement probably
  still holds, but the evidence for it predates the change.
- NOT AFFECTED.
Never present POSSIBLY AFFECTED as VIOLATED to make the report look
decisive. Most engineering changes in Teamcenter carry a description
that is too terse to judge from, and saying so is more useful than
guessing.

WHAT THE CHANGE RECORD DOES NOT TELL YOU. State plainly what you had
to work from. A change notice reading "update bracket per DCN-4471"
supports a structural impact set and no more, and the report should
say that rather than implying a technical assessment was possible.
Where the attached datasets would resolve it, name them so a human
can look.

RECONCILIATION: affected items = matched + unmatched; matched parts =
those with allocated requirements + those with none. A part carrying
no requirements at all is worth reporting, because either the model
is incomplete or the part is not doing anything the system asked for.

DELIVER a report ordered by consequence: safety findings first, then
likely-violated requirements, then interfaces crossing an ownership
boundary with the owners named, then stale verification, then budget
effects, then the possibly-affected list with the questions each one
needs answered. Stamp it with the Teamcenter change ID and its
status, the revision rule used, the identity read as, the Dalus
branch and revision, and the date. This report will be read in a
change board meeting and quoted afterwards, so it has to be citable.

OFFER, DO NOT EXECUTE: writing the impact summary back to Teamcenter
as a note or attachment on the change object, gated and only if the
user's process permits an external analysis to be attached; raising
change requests in Dalus for the requirements that must move;
re-running the affected verification; and posting the interface
findings to the owners of the far side.

THIS WORKFLOW IS READ-ONLY on Teamcenter and on the Dalus model.

Replace the [bracketed] placeholders with your model and project names.

What you get

Common questions