Design a requirements traceability service that survives a re-baseline
Carry 4,000 requirements through a mid-program re-baseline without losing the thread to test and hardware.
- Re-baseline
- CUI marking
- Disconnected ops
IllustrativeA composite built from public information. It does not describe a specific OCEANS engagement, customer system or solicitation, and every figure on this page is an assumption for the exercise.
Practice mode
45:00
Starts a 45-minute clock on the prompt. Built for rehearsing an orals technical challenge.
01 · The prompt
“A program carries 4,000 requirements across three baselines, linked to systems, test cases and fielded hardware. Mid-program the sponsor re-baselines and 600 requirements change. Design a traceability service that shows exactly what the change touches, keeps the history auditable, and still exports to the tools the program office already uses.”
02 · Ask these first
Each of these changes the design. Ask them before drawing a single box.
- Q1 Is the system of record the traceability tool, or the signed baseline documents?
- Q2 Who approves a change, and does that approval have to live inside the system?
- Q3 Which exports are non-negotiable: DOORS, Excel, ReqIF?
- Q4 Does "traced" mean linked, or linked and verified by a test?
- Q5 Does it have to run on a disconnected network?
Practice prompt
Your turn. Requirements, sizing, architecture, trade-offs.
Work it on a whiteboard. Our write-up for this one is still being drafted, so compare your structure against problem 01.
Time. Pens down.
Write-up in progress
The prompt and the opening questions are live. Our full write-up is still being drafted.
You can practice it now. For the finished format, read problem 01.