Polarion requirements to architecture

The problem this solves

A requirements database with no architecture behind it cannot answer the question that matters: who is building this. Allocation gets done in a spreadsheet, or not at all, and the requirement nobody designed for is discovered when someone asks which subsystem owns it, usually at a review.

How it works

Give Polarion requirements an architecture to point at, one accepted link at a time. Polarion stays the requirements database. This proposes an allocation per requirement with named evidence and a confidence level, and leads with the requirements no part can satisfy.

You are linking the requirements in a Polarion project to the
architecture in the Dalus model [model name]. Polarion stays the
authoritative requirements database. Nothing is copied out of it as
editable requirements, and nothing in Polarion is edited except the
trace link itself, after approval. The team gets an architecture
their requirements point at, and their quality manager still sees
one requirements database.

CONFIRM FIRST, in one message: which Dalus model and which Polarion
project; which requirements are in scope (a document, a work item
type, a component, a release); whether links should be written back
to Polarion work items or delivered as a report only; and, if
writing, which Polarion link role to use for requirement-satisfied-
by-architecture. Ask anything else you need in the same message.
Then begin.

CHECK THE LINK ROLE BEFORE ANYTHING ELSE. Read the project's
configured link roles and report them. If no role fits a
requirement-to-architecture relationship, say so plainly and offer
two options: deliver the trace as a report the team can act on, or
record the link as a custom field or work item attribute if the
project has one. Never invent a link role, and never repurpose a
role that means something else in the team's process, because link
roles are what their traceability reports are built on.

READ POLARION, read-only: every requirement in scope with its work
item ID, title, description, type, status, and any existing links
to architecture, design or test items. Note which requirements are
inside a baselined document, because those need care later. Note
requirements that already carry a satisfied-by link, since those
are candidates for verification rather than proposal.

READ THE MODEL: parts, their functions and responsibilities;
connections and interfaces with their flows; states and modes;
existing requirements and allocations, since the model's own
requirements tell you what each part is already accountable for.

PROPOSE ONE ALLOCATION PER REQUIREMENT. For each, give:
- The requirement ID and its statement, quoted briefly.
- The proposed part, connection or interface, with its model ID.
- One sentence of reasoning that names the specific evidence: the
  function the part performs, the flow the connection carries, the
  interface the requirement constrains. "Seems related" is not
  reasoning and must not appear.
- A confidence level: high (the requirement names the thing the
  element does), medium (the element is the plausible owner but
  the requirement is worded at a different level), low (a guess
  worth a human glance).
- Where more than one element could satisfy it, say so and name
  the alternatives rather than silently picking one.

LEAD WITH WHAT YOU CANNOT MATCH. The unmatched list is the real
output of this workflow. For each unmatched requirement, classify
it and say which case it is:
- The architecture is missing an element that should exist. This
  is the valuable finding: a requirement nobody has designed for.
- The requirement is at a level the architecture does not
  describe (a process requirement, a programme constraint, a
  documentation obligation) and correctly has no allocation.
- The requirement is too vague to allocate, which is a quality
  finding about the requirement.
- It duplicates another requirement that is allocated.
Report this list first, before the confident matches, because a
list of successful links reads as progress and a list of
unallocated requirements reads as work.

ALSO REPORT: architecture elements with no requirement pointing at
them, grouped and counted rather than listed one by one. Some are
normal (structure, packaging), but a subsystem nobody has written
a requirement against is worth a look.

APPROVAL, one at a time. Present the proposals for individual
confirmation, high confidence grouped for fast acceptance if the
user wants, medium and low walked individually. Never apply
allocations in bulk. A guessed trace link is worse than none,
because someone has to disprove it later, and in an audited
process a wrong link is a finding.

WRITING BACK, gated: after approval, write the link to the
Polarion work item using the confirmed role, and record the
corresponding allocation in the model so both sides carry the
trace. Never edit a requirement's text, status, or any field other
than the link. If a requirement sits in a baselined document,
report it and ask before touching it, since some organisations
forbid modifying baselined items at all.

FINAL REPORT: counts of proposed, accepted, rejected and
unmatched; the unmatched list in full with its classification; the
unreferenced architecture elements; anything that failed to write
and why. Offer, do not execute, re-running this against new
requirements later, and the traceability gap report if the team
needs the full requirement-to-architecture-to-verification chain.

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

What you get

Common questions