Derivation, copy and verification links in a UAV flight-control requirement set
The SkyLark UAV programme keeps its flight-control requirements in a single model. The customer requirement sits at package level: REQ-100, "The UAV shall hold commanded altitude within plus or minus 5 m in steady wind up to 15 m/s." A supplier package repeats that sentence verbatim as REQ-100-C with a «copy» dependency to REQ-100, which review accepted. The problems are downstream. The flight-control engineer created REQ-210 ("The altitude loop shall settle within 3 s of a step command") and REQ-220 ("Barometric altitude accuracy shall be plus or minus 1.0 m") as new «requirement» elements, nested them inside REQ-100, and drew «copy» dependencies from each to REQ-100. The verification lead modelled two test procedures as activities stereotyped «testCase», drew «verify» from those activities to REQ-210, and also drew «verify» from the FlightController block to REQ-210. Separately, REQ-220's plus or minus 1.0 m contradicts the plus or minus 1.5 m figure in the altimeter allocation note, and no rationale appears anywhere in the model.
1. The «copy» dependencies from REQ-210 and REQ-220 to REQ-100 were rejected. Explain what «copy» actually asserts, why these two are wrong, and what relationship and direction should replace them. Is nesting the two requirements inside REQ-100 correct?
Read the worked answer
«copy» is a Dependency stereotype making exactly one claim: the client requirement's text is identical to the supplier's. It exists for verbatim restatement across organisational boundaries, which is why REQ-100-C was fine. REQ-210 and REQ-220 are new statements containing numbers (3 s, plus or minus 1.0 m) absent from REQ-100, so the copies assert a falsehood. The damage is not cosmetic: a change to REQ-100 would be expected to propagate into both, yet their text was never meant to be identical, and any consistency check built on copy either reports a persistent false mismatch or, worse, silently overwrites deliberately tightened values.
Replace each with «deriveReqt», client = REQ-210 or REQ-220, supplier = REQ-100. Derivation says "this requirement is derived from that one and may add, tighten or decompose its intent" without claiming textual identity. It is the relationship that carries rationale, so it is also where the budget discussion belongs.
Ownership is separate from and compatible with derivation. Nesting (composite ownership) inside REQ-100 places the two in REQ-100's requirement set, which is legitimate and gives readers the hierarchy: customer requirement with its children. It does not express derivation, so keep both: containment for structure, «deriveReqt» for traceability. Note also that a verbatim copy should live in a different namespace from its original; REQ-100-C does, REQ-210 does not.
2. The verification lead has «verify» and «satisfy» attached to the wrong elements around REQ-210. State the correct client and supplier for each relationship, what kinds of element may legally be clients, and restructure the traceability so the model shows both that the design meets REQ-210 and how that was demonstrated.
Read the worked answer
The two relationships answer different questions and have different signatures.
- «satisfy»: client = the design element, normally a Block (a part or instance in some methods); supplier = the requirement. It answers "what in the design meets this?"
- «verify»: client = a test case, i.e. an element stereotyped «testCase» (commonly an activity or a classifier); supplier = the requirement. It answers "what evidence demonstrates this?"
The review found both ends wrong. «verify» from the FlightController block asserts that a design element is a test case; the stereotype's client is a test case, so the model no longer records evidence, only intent. A «verify» from a package is worse, since a namespace cannot observe or measure anything. Meanwhile the design claim was made by the test activities rather than by the block.
Restructure as follows. FlightController -«satisfy»→ REQ-210, and have the block own the altitude-loop behaviour, either as classifier behaviour or through an «allocate» from the control activity to FlightController (allocation is the mapping of function to structure; satisfy is the claim that the structure meets the requirement). Keep each of the two test procedures as an activity with «testCase», give it verification properties such as stimulus, measured settling time and verdict, and draw «verify» from each activity to REQ-210. Multiple test cases per requirement are normal and desirable. Re-run the audit query "every requirement has at least one satisfying block and at least one verifying test case" to prove the fix.
3. Resolve the plus or minus 1.0 m versus plus or minus 1.5 m conflict in a way that is auditable and that stops the number drifting again.
Read the worked answer
The root cause is that the tolerance exists only as prose, so it has no owner and no propagation path. Give it a home in the model first: add a value property to REQ-220, for example tolerance : Length, typed by the ISO 80000 length value type with unit m, and either quote it in the text or attach a constraint property to the requirement so the threshold is machine-evaluable. Bind the altimeter block's accuracy value property to that parameter in a parametric diagram, so a change to the requirement or to the sensor creates a visible diff rather than a silent inconsistency.
Then decide which figure is correct, explicitly. Usually the two numbers are answering different questions: plus or minus 1.0 m may be the barometric contribution to a total error budget that must stay inside REQ-100's plus or minus 5 m, while plus or minus 1.5 m may be a sensor specification including temperature effects. Whichever reading holds, write it down: update REQ-220's text and tolerance to the agreed value; attach a «rationale» comment to the deriveReqt dependency showing the budget arithmetic (system plus or minus 5 m = contributions from barometric error, loop error, wind-up) and naming the approver and date; and if the sensor allocation lives in an external specification, trace to it rather than duplicating its text into the model. If both figures must legitimately coexist, keep two requirements with different owners linked by «deriveReqt», and make the distinction (allocated versus measured) part of each text. A contested number living in prose recurs; a number bound to a constraint does not.