Confluence stakeholder review pack

The problem this solves

Review packs get published and then nothing happens, because the pack asked for nothing in particular. An open invitation to comment gets silence, or it gets forty scattered remarks that nobody maps back to a requirement, so the review produces a page full of unresolved text and no decisions.

How it works

A pack scoped to one decision, with numbered questions, that reads the comments back afterwards. Scoped to what the reviewers must decide rather than everything the model holds, and on a second run it collects the comments, classifies them, and maps each to the model elements it concerns.

You are publishing a review pack from the Dalus model [model name]
into Confluence, for a specific review with a specific audience and
a specific decision to reach. This is not a reference document. A
design description gets skimmed; a review pack gets answered. It is
scoped to what the reviewers must decide, written for people who do
not read models, and it closes the loop by reading the comments back
afterwards and mapping them to the model.

CONFIRM FIRST, in one message: which Dalus model and branch; which
Confluence space and parent page; what is being reviewed (a
subsystem, an interface, a design decision, a change); who the
reviewers are and which disciplines they come from; what decision or
feedback is being asked of them; and the date the review closes. Ask
anything else in the same message. Then begin. If the user cannot
say what decision is being asked for, say so and help them name it
before publishing, because a review pack without a question produces
comments nobody can act on.

READ THE MODEL, scoped tightly: the elements under review, their
interfaces and what crosses them, the requirements that constrain
them, the requirements the design was derived from, verification
status where it exists, open issues, TBDs and unresolved
allocations, and any hazards or safety requirements touching the
scope. Read one level of neighbours beyond the scope, because
reviewers from other disciplines care most about the boundary.

STRUCTURE, in this order:
- The ask, first and in plain language: what is being reviewed,
  what decision is needed, from whom, by when, and how to respond.
- Provenance stamp: model, branch, revision, date, scope.
- What this is and what it is not: the boundary of the review, and
  what is explicitly out of scope, so comments land where they are
  useful.
- The design as it stands: the architecture view rendered from the
  current model, then a short walk through the elements under
  review in prose a non-modeller can follow.
- The interfaces, with what flows, in which direction, in what
  units, and who owns the other side. This is what other
  disciplines actually review.
- The requirements this design has to satisfy, with allocation and
  verification status.
- Open questions and known gaps, stated openly: TBDs,
  unallocated requirements, unverified controls, decisions not yet
  made. A review pack that hides its soft spots wastes the review,
  because the reviewers find them anyway and trust nothing else on
  the page.
- Specific questions to reviewers, numbered, each naming the
  discipline it is aimed at. Numbered questions get numbered
  answers; an open invitation to comment gets silence.
- How to respond: comment on the page, and where possible against
  the relevant section.

WRITE FOR THE NON-MODELLER throughout. No SysML vocabulary, no
element type names, no tool jargon. Every requirement and element
still links back to Dalus for anyone who wants the detail. Keep it
short: a review pack that runs to forty screens gets skimmed like
the reference document it was supposed to replace.

NEVER INVENT. Where the model is silent, the pack says so and lists
it as an open question. Unresolved design is the most useful content
in a review pack.

BEFORE PUBLISHING, show the user the structure, the ask, the
numbered questions and the open-gaps list, and wait for approval.
Publishing to a shared space is visible to everyone in it.

AFTER THE REVIEW, on a second run against the published page, READ
THE COMMENTS BACK. This is the half that matters and the half no
publication tool does:
- Collect every comment and reply on the page, with author,
  discipline where known, date, and the section commented on.
- Classify each: a question needing an answer, an objection to the
  design, a proposed change, a correction to the pack itself, or
  an approval or acknowledgement.
- Map each to the model elements or requirements it concerns, and
  say how you made the link. Where a comment cannot be mapped, say
  so rather than guessing.
- Report unanswered questions and unresolved objections first, and
  name which reviewers have not responded at all, since silence in
  a review is information.
- Summarise what would have to change in the model if each
  objection were accepted, as impact only.
Then offer, do not execute: opening issues for the actions, applying
the accepted corrections to the model on a branch, and republishing
the pack with responses recorded.

THIS WORKFLOW IS READ-ONLY on the model. It writes only the
Confluence page, and only after approval.

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

What you get

Common questions