Requirements reconciliation with Jira

The problem this solves

Nobody notices drift until an audit asks which system is right. Issues outlive the requirements that created them, text is edited on one side only, and a ticket gets closed while the requirement it came from is still unverified. Reconciling it by hand is a spreadsheet job everyone postpones, so the two records quietly stop describing the same programme.

How it works

Four difference lists between the model and Jira. Read-only in both systems. Matches on the Dalus ID rather than text, reports ID collisions as the traceability failure they are, and shows where the two systems disagree on text, status and priority.

You are reconciling the requirements in the Dalus model [model name]
against the requirement issues in a Jira project. You are producing
four difference lists. You change nothing in either system.

CONFIRM FIRST: which Dalus model, and which Jira project. Also
confirm the matching key: by default the Dalus requirement ID stored
on the Jira issue (in a custom field, the summary, or a label). Ask
where it lives if you cannot find it. Ask anything else you need in
the same message, once.

MATCHING:
- Match on the Dalus ID, exactly. Never match on text similarity as
  the primary key.
- Report how many Jira issues carry no Dalus ID at all, and how you
  will treat them: as unmatched, not as new requirements.
- Report ID collisions (one Dalus ID on several Jira issues, or one
  issue claiming several IDs). These are the most dangerous finding
  because they mean the traceability itself is broken.
- Say up front which Jira issue types and which JQL you used to
  decide what counts as a requirement issue, so the user can correct
  the filter.

THE FOUR LISTS:
1. In Jira only: requirement issues with no matching model
   requirement. Distinguish, where the model's history allows, between
   requirements deleted from the model and requirements that were
   never in it.
2. In Dalus only: model requirements with no Jira issue.
3. Same ID, different statement text: show both versions with the
   differences marked, and say which system was modified more
   recently if both carry timestamps. Distinguish trivial differences
   (whitespace, punctuation, case) from substantive ones, and put the
   trivial ones in a collapsed group.
4. Same text, different priority or status: show both values, and
   flag the pairs that actually matter, for example a Jira issue
   closed while the model requirement is unverified or failing.

ALSO REPORT, since they are the findings people care about once they
see them:
- Requirements whose Jira issue is closed but whose model status is
  not complete or verified.
- Jira requirement issues with no linked delivery work at all.

RECONCILE: total model requirements and total Jira requirement issues
must each account fully across matched, unmatched and collision
categories. Show the arithmetic.

INTERPRETATION, one short section at the end: which direction the
drift runs, whether one system is consistently ahead, and which
specific differences would be a problem in an audit. Keep it to a few
lines and base it only on what the lists show.

NEVER: edit a requirement, edit an issue, create an issue, or
transition anything. This run is read-only in both systems.

OUTPUT: the four lists in chat if short, otherwise a spreadsheet with
one sheet per list plus a summary sheet. End by offering, not
executing, the follow-up: syncing a chosen direction for a chosen
subset, one list at a time, with the change set shown before anything
is written.

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

Example output

What you get

Common questions