Repairing Requirement Traceability Before an Audit
A braking-controls team has 220 requirements in a SysML model. Forty are labeled 'derived' from vehicle-level safety goals, but the model only contains them under a 'Braking Requirements' package; no «deriveReqt» links exist. Twelve requirements changed last month after a supplier changed the wheel-speed sensor. Test cases in the verification package link to design blocks with «satisfy» but not to requirements. An assessor found 18 requirements with no verification case and 7 that state a design solution ('use a 32-bit MCU') rather than a need. The team must prepare for a requirements audit in three weeks and cannot re-baseline the whole set. They want a minimal, defensible repair plan. The model has requirement IDs but no rationale fields, and some requirements are duplicated in two packages with different IDs. The audit will sample 30 requirements, including all changed and all derived ones.
1. Distinguish «deriveReqt», «refine», and «satisfy» for the 40 derived requirements and the 7 solution-stating requirements. What links and text changes should be made?
Read the worked answer
«deriveReqt» is a dependency from a derived requirement to its source requirement; it records why the lower-level requirement exists. The 40 derived requirements need «deriveReqt» links to the vehicle safety goals they come from, plus rationale text. «refine» is a dependency from a model element to a requirement showing that the element provides more detail or an alternative expression; it is not a substitute for derivation. «satisfy» is a dependency from a design element (block, activity, etc.) to a requirement, showing that the design meets it. For the 7 solution-stating requirements, do not just relabel them: if 'use a 32-bit MCU' is a contractual constraint, rewrite it as a design constraint with a rationale and trace it to the performance or safety need it supports; if it is only a chosen solution, replace it with the need and move the MCU choice into the design block. Link the design block with «satisfy» to the need, not to the solution. The audit should see a chain: safety goal -> derived requirement -> design satisfy -> verification.
2. Triage the 18 unverified and 12 changed requirements in three weeks. What should be done first, and what evidence should the audit see?
Read the worked answer
Triage by risk, not by count. Start with the 12 changed requirements because they have active impact: follow their «deriveReqt» and «satisfy» links to affected design and test elements, update or mark links obsolete, and record the change rationale. Then handle the 40 derived requirements that the audit will sample: create the missing «deriveReqt» links and rationale. For the 18 unverified requirements, do not invent verification. Classify each as inspection, analysis, demonstration, or test, link existing test cases with «verify» where they truly cover the requirement, and for the rest create a verification action with an owner and date. The audit sample of 30 should be traceable through a view or matrix. Evidence: unique ID, text, source, derived-from link, satisfy link, verify link (or open verification with plan), and change history. If time runs out, an honest open item with a plan is more defensible than a false link.
3. How should requirement containment and IDs be organized to eliminate duplicates and support the audit?
Read the worked answer
Containment should express ownership: each requirement should be owned once by the appropriate requirement package (for example, by subsystem or by requirement type), and that package should be under configuration control. A requirement should not appear as a separate owned element in two packages. For the duplicates with different IDs, choose a master based on the source or earliest baseline, redirect «deriveReqt», «satisfy», and «verify» links to the master, mark the other as obsolete or use «copy» only if a formal copy is required, and record the decision. IDs should be stable and never reused; add a rationale property and a source property. Use views to produce audit samples by status, changed date, or verification method, rather than moving requirements into an audit package. This preserves a single identity and makes the sample defensible.