Appendix I: Modeling Review Checklists

Model review is a team activity, not a solo exercise. You bring a model to a review gate, a group of peers asks hard questions about completeness and correctness, and the model either passes or goes back for revision. The problem is that “completeness” is vague. Without a written standard, reviewers focus on whatever they happen to notice, and different reviewers notice different things.

This appendix gives you four copy-ready checklists, one for each major review type: Architecture, Requirements, Behavior, and Verification. Each checklist is a set of yes/no questions phrased so that “yes” means the model is correct in that dimension. A “no” or “unsure” answer identifies a specific gap that needs attention before the review can pass.

How to Use These Checklists

Copy the relevant checklist into your review document, pull request description, or team wiki page before the review meeting. Work through each item independently: read the question, inspect the model, and mark it. Do not answer from memory – open the .sysml files and check.

The checklist items are sequenced so that earlier items catch structural problems that would make later items meaningless. If item 1 fails, fix it before assessing item 3.

Each item includes a chapter reference in parentheses. If a question is unclear, that chapter explains the underlying construct in full.

Not every item is a language rule. Items marked Convention: or Style: describe review heuristics – a model is perfectly legal either way. They earn their place because they catch review pain later, but a team can consciously adapt or waive them.

Note: These checklists target model completeness and structural consistency. They are not a substitute for domain correctness review. A model can pass every checklist item and still describe a system that does not work in the real world. Use domain experts alongside these checklists.

The Coffee Machine example developed throughout this book is a useful validation target. After reading this appendix, you can apply each checklist to the files in examples/coffee-machine/ and observe which items pass immediately and which require model elaboration.

Checklist 1: Architecture Review

Use this checklist during a structural architecture review, typically at the end of the definition phase, before behavioral modeling begins. It verifies that the structural model has enough completeness and internal consistency to serve as a scaffold for behaviors, requirements, and connections.

Convention: does every part def have at least one part usage that instantiates it within the model? The language does not require this – an uninstantiated definition is perfectly legal, and library or catalogue definitions legitimately have no usage in the package that declares them. The review question is whether each unused definition is intentional (a library entry, work in progress) or dead weight that nothing verifies, connects, or simulates. (Chapter 3, Chapter 5)
Convention: is every connection across a port def governed by a named interface def that specifies the connection contract? There is nothing to check on the conjugate side – every port def automatically carries a conjugated form (~PortDef); the language creates it for you. The heuristic is about the contract: when connections across a port have no interface def, reviewers and tools have no stated agreement to check the two ends against. (Chapter 5, Chapter 6)
Style: are load-bearing connect usages typed by a named connection def? Anonymous connections are fully normative – they parse, carry flows, and are queryable like any other usage. Naming the definition is a reuse and traceability convention: a named connection def can be instantiated again elsewhere and gives allocations and satisfaction links a stable target. (Chapter 6)
Does every part usage that can have more than one instance declare an explicit multiplicity? Omitting multiplicity implies exactly one instance. If a coffee machine can have between one and four heating elements, that constraint belongs in the model, not in a comment or document. (Chapter 5, Chapter 3)
Convention: are all import statements explicit rather than wildcard in production packages? Wildcard imports (import SomePkg::*;) are convenient during drafting but create invisible name dependencies. In a reviewed package, each imported name should be traceable to a specific definition. (Chapter 4)
Does every behavioral action that is assigned to a structural part have a corresponding allocation linking the action to that part? Without explicit allocation, the model declares behavior in the abstract but does not commit it to any physical or logical element. Reviewers and analysis tools need this link to check feasibility. (Chapter 6, Chapter 5)
Convention: does the package structure separate domain definitions from contextual usages, with no definitions buried inside usage packages? Definitions mixed into context packages cannot be reused elsewhere and are harder to find during review. The canonical pattern is a definitions package imported by one or more context packages. (Chapter 4, Chapter 5)

Checklist 2: Requirements Review

Use this checklist during a requirements review, typically after the requirements package has been baselined and before the architecture team begins assigning satisfaction links. It verifies that every requirement is well-formed, bounded, and connected to the rest of the model.

Does every requirement usage have a subject member declaring what the requirement constrains? A requirement without a subject is a floating assertion. The subject tells every reader – and every automated tool – exactly which element of the model must satisfy the requirement. (Chapter 10)
Convention: does every leaf requirement usage (one with no child requirements) have at least one require constraint or explicit constraint expression? A requirement with only a doc annotation is legal, but it is an English sentence rather than a formal constraint. This convention asks leaf requirements to carry a verifiable condition that a constraint solver or test can evaluate. (Chapter 9, Chapter 10)
Is every leaf requirement either satisfied by a satisfy usage, or explicitly deferred with a documented rationale? An orphan requirement – one that exists in the model without a satisfaction link and without a deferral note – is an invisible gap. Reviewers cannot tell whether it was overlooked or intentionally left open. (Chapter 10)
Does every satisfy usage name a specific requirement usage rather than a requirement definition? Satisfying a definition claims to satisfy all possible instances of it, which is almost never the intent. The satisfaction link must point to the specific requirement usage in its context. (Chapter 10)
Convention: is the requirement hierarchy no deeper than four levels? A hierarchy deeper than four levels usually indicates scope creep: requirements at the bottom level are design decisions, not stakeholder needs. Inspect any branch deeper than four levels and ask whether the lowest items belong in a design document instead. (Chapter 10, Chapter 15)
Convention: does every requirement have a doc annotation with rationale text explaining why the requirement exists? A requirement without rationale cannot be prioritized, traded off, or defended to a stakeholder. Rationale also guides verification: it tells you what evidence would actually satisfy the requirement. (Chapter 13, Chapter 10)
Does every stakeholder concern raised during elicitation appear as a named concern usage or requirement in the model? A concern that was raised during review but never captured in the model is a hidden risk. Even concerns that do not yet have a formal requirement should appear as concern usages so that the model tracks them explicitly. (Chapter 10)

Checklist 3: Behavior Review

Use this checklist during a behavior review, typically after action flows and state machines have been drafted. It verifies that behavioral elements are internally consistent, properly connected, and grounded in the structural model.

Does every state def have at least one entry transition and at least one exit condition? A state with no entry transition is unreachable. A state with no exit condition is a dead end. Either situation represents a logical error in the behavioral model. Check every state node, including nested parallel states. (Chapter 8, Chapter 7)
Does every transition usage have an explicit guard, trigger, or both – with the only exception being the initial pseudo-transition? An unguarded, untriggered transition (other than the initial transition from the initial state) fires unconditionally on entry to its source state, which almost always indicates a modeling error. Verify the intent before approving. (Chapter 8)
Are all action usages within a sequence model connected by succession links, with no disconnected action nodes? An action node with no incoming succession and no outgoing succession is an island: it never executes in the sequence and will not appear in simulation or analysis. Every non-initial action needs at least one incoming succession link. (Chapter 7)
Do all control-flow fork nodes have a corresponding join node that synchronizes the same branches? A fork without a join creates parallel branches that never converge. This may be intentional in some models, but it should be explicit: if there is no join, add a comment explaining why the branches are designed to diverge permanently. (Chapter 7)
Does every accept action and send action reference a port or flow definition that is declared in the structural model? Behavioral elements that send or receive across ports must reference the same port type used in the structural layer. A mismatch – for example, an action that sends a WaterFlow on a port typed for ElectricalPower – is a semantic error that the structural review should have caught but the behavior review must confirm. (Chapter 6, Chapter 7)
Style: does every exhibit usage in an action definition reference a named state def rather than an anonymous inline state? Inline anonymous states are legal, but they cannot be referenced from other actions, tested in isolation, or carry documentation. Prefer a named state definition for any state that has more than trivial logic. (Chapter 8, Chapter 3)
Do action parameter types match the item types declared on the ports or flows they read from or write to? A perform action that reads a CoffeeGrounds item but whose input parameter is typed as Water will pass a parser but fail during simulation or analysis. Parameter types must match the flow types at every boundary. (Chapter 7, Chapter 6)

Checklist 4: Verification Review

Use this checklist during a verification review, typically after the verification cases package has been drafted and before formal test planning begins. It verifies that every requirement has a path to objective evidence and that no verification case exists without a purpose.

Does every leaf requirement usage have at least one verify usage inside a verification case that references it? A requirement with no verification case cannot be closed. Requirements without objective evidence are assumptions. This item should be checked against the same list of leaf requirements identified in Checklist 2 item 3. (Chapter 10)
Convention: is every verification case usage annotated with a verification method metadata tag – one of: analysis, test, inspection, or demonstration? Without a method tag, the verification case is unscheduled: you do not know who performs it, what evidence it produces, or when it runs. Method classification is also required for V&V plan traceability. (Chapter 13, Chapter 10)
Does every verification case usage contain at least one verify usage that references a named requirement? A verification case that contains no verify usages is a placeholder with no executable content. It may pass a parser but it contributes nothing to requirement closure. These orphan cases must either be populated or removed. (Chapter 10)
Style: does every assert constraint usage inside a verification case reference a named constraint def rather than an inline anonymous constraint? An anonymous inline constraint inside a verification case cannot be reused, named, or referenced from a test script or analysis tool. Named constraint definitions allow the same constraint to appear in both the requirement and the verification case, making the link explicit. (Chapter 9, Chapter 10)
Convention: is every verification case annotated with a responsible stakeholder or team via a metadata usage? An unassigned verification case will not be executed. Ownership metadata can be as simple as a #Responsible { team = "Systems Test"; } annotation; the convention asks that it be present so that test planning tools and project managers can schedule the work. (Chapter 13)
Does the coverage matrix show every requirement at the leaf level mapped to at least one verification case? Individual checklist items verify individual connections. This item asks you to look at the whole picture: generate or inspect the requirement-to-verification-case coverage matrix and confirm no leaf requirement appears as uncovered. The Systems Modeling API supports this as a graph query. (Chapter 10, Appendix C)
Are verdict expressions in verification cases written using named calculation def results rather than literal boolean constants? A verification case whose verdict is assert true; is always passing and provides no information. Verdicts must evaluate observable conditions: parameter values, measured outputs, or constraint evaluations drawn from a named calculation. (Chapter 9, Chapter 10)
Has a view def <Milestone>ReviewView (carrying the filter <viewCondition>;) plus a view usage (carrying expose <package>::*;) been authored to scope the milestone review? A milestone review pulls a particular slice of the model — the requirements affected by this gate, the parts touched by this design phase, the verification cases due this iteration. Authoring that slice as a named view (rather than relying on each reviewer to remember which packages to inspect) makes the scope explicit, reviewable, and re-runnable for the next milestone. The filter clause lives in the view definition and narrows the slice to the relevant element kinds; the expose ... ::* lives in the view usage (a view def body does not admit expose) and keeps the view fresh as the underlying packages grow. (Chapter 13: Metadata and Views)