Review-board triage of conformance and quality findings in a delivery-drone model
A review board is examining a delivery-drone model of 412 elements and 9 requirement diagrams before a safety case is submitted. Five findings are on the table. (a) The telemetry requirement "shall transmit at 1 Hz" has no value property anywhere; the rate exists only in the requirement text and in a note attached to an internal-block-diagram connector, while the TelemetryUnit block satisfies the requirement. (b) After a package merge, three «copy» dependencies form a cycle A to B to C back to A. (c) A test-case activity verifies REQ-31, but the dependency was drawn from the Drone block, and a second «verify» was drawn from a package. (d) The DeliverPackage activity is allocated to both FlightController and MissionPlanner, two parts of the drone with no other relationship. (e) A 30 s timeout appears as 30 s, 45 s and 60 s in three requirement texts linked only by «trace».
1. Sort the five findings into violations of SysML semantics, methodology or quality defects that are still legal SysML, and presentation issues. Justify each placement.
Read the worked answer
The three categories warrant different responses, so separating them is the first act of the review.
Semantics violations: (c) only. «verify» has a test case as its client, so a Block is the wrong element kind and a Package cannot be a test case at all. Those two dependencies record no evidence; the model claims verification it does not contain, which is precisely the kind of finding that must block a safety case.
Legal but methodologically defective: (b), (d), (e). Dependency cycles are permitted by UML and SysML, so a tool stores A to B to C back to A without complaint, but a copy cycle makes text equality circular and change propagation undefined; it is a meaning defect, not a syntax defect. Two allocations of one activity to two unrelated blocks are individually legal and jointly contradictory, since each asserts that one block performs the whole activity. Three different timeouts in texts joined by «trace» are legal too, because trace carries no semantics beyond relatedness, and that is the defect: no single source of truth, nothing to verify.
Presentation or completeness: (a) is legal SysML, since a requirement may sit next to a design with no quantifying property, but the note on the connector and the rate living only in prose mean the requirement cannot be checked. Comments are not model values and will not appear in a change diff.
Pressing (c) immediately and scheduling (b), (d) and (e) with owners and dates is the defensible split; treating all five as equally urgent makes the board's signal meaningless.
2. For findings (a) and (e), describe the modelling changes that make the requirements checkable and keep one source of truth.
Read the worked answer
For (a), give the rate a home in the model. Add a value property to the element that governs transmission, for example telemetryRate : Frequency on the telemetry interface block or on TelemetryUnit's link block, typed by an ISO 80000 frequency value type so unit and dimension are captured. Express the threshold as a constraint property, telemetryRate at least 1 Hz, bound in a parametric diagram so the requirement is machine-evaluable. TelemetryUnit can then «satisfy» the requirement with the value that demonstrates it, a «testCase» activity can «verify» it by measuring or reading that value, and the note on the connector is deleted. If the rate is configurable, make it a value property with a default and reference it from the constraint so a variant changes it in one place.
For (e), the three texts with different numbers are not copies of one another; they are either derived requirements with genuinely different limits or unsynchronised drift. Choose the owner, the requirement whose number the approving authority signed, and give its timeout a value property. For each of the other two: if the text must be identical, replace the local wording with a «copy» from the owner and delete the divergent edit; if it must differ, use «deriveReqt» with a «rationale» comment naming the different context, and bind each timeout to its own parameter. Replace the untyped «trace» links with the specific relationship so the audit query "what does a change to this requirement affect?" has a defined answer instead of a list of vague associations.
3. Which single finding would you press as release-blocking, and what evidence would close it?
Read the worked answer
Finding (c). Every other item degrades the model's usefulness, but (c) degrades the safety argument's validity. A «verify» drawn from the Drone block asserts that a design element is a test case; a «verify» drawn from a package asserts that a namespace observed something. Neither is evidence, so REQ-31 is currently recorded as verified with no test case behind it, and any report or dashboard that counts verify links will pass the requirement. In a safety submission that is the worst failure mode available: invisible false assurance, and it is precisely the item a reviewer cannot detect by reading the requirement text.
Closing evidence: model each test procedure as an activity or classifier stereotyped «testCase», with verification properties covering stimulus, setup, measured quantity and pass criterion; draw «verify» from each such element to REQ-31; allocate the test activities to the bench or rig block that executes them so the evidence has an owner; then re-run a traceability query that requires every safety-relevant requirement to have at least one «verify» whose client is stereotyped «testCase». Publish the query result, not a diagram, as the closure artefact, and add the query to the gate checklist so the defect cannot silently return. Of the remaining items, (d) is the next most urgent, because duplicated allocation will corrupt the integration plan, but it does not invalidate a verification claim the way (c) does.