Arc Skills / Architecture and engineering budgets
Develop operational scenarios and off-nominal scenarios
A scenario reveals handoffs and recovery behavior that a feature list can miss. Arc Skills takes a ConOps or stakeholder need and returns traceable paths for what operators and the System do.
Use this skill
Use Arc Skills to develop operational scenarios from my stakeholder need or ConOps.
Inputs:
- Source need, System boundary, actors, modes, and initial conditions
- Normal operational goal and known failure or unavailable-dependency cases
- Existing requirements and authorized recovery decisions
Return ordered normal and consequential alternate paths with triggers, observable outcomes, end states and source links. Leave unsupported recovery behavior as an owner decision rather than an assumed retry.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Stakeholder need or ConOps | Anchors why capture is requested | Scenario purpose and source link |
| Modes, actors and boundaries | Orders human and System actions | Initial state, steps and end state |
| Known failures and recovery authority | Separates specified response from open design | Alternate path and owner question |
Payload capture with full storage
Illustrative engineering example.
The fictional operator requests an image capture from a payload whose recorder can report storage-full. The example distinguishes a request rejected before recording from an interruption after recording has started.
Initial state: payload Ready; recorder Ready; operator connected
Trigger: operator requests capture
Normal end: accepted frame recorded; operator sees success
Pre-start alternate: storage-full; request rejected| Path / step | Actor or System action | Observable output | End state |
|---|---|---|---|
| Normal 1 | Operator requests capture | Command accepted by payload | Capture pending |
| Normal 2 | Payload sends frame; recorder confirms write | Stored-frame acknowledgment | Complete; success visible |
| Storage-full 1 | Recorder reports full before acceptance | Capture denied; operator informed | Ready; no new frame |
| Mid-capture unknown | Storage fills after first frame | Disposition not specified | Open: stop, partial record or retry? |
The storage-full row is a rejected request, not a successful capture and not necessarily a hardware fault. It gives the operator an observable outcome without implying a retry. The normal path requires the recorder’s write confirmation before reporting completion; command acceptance alone would overstate the result.
The mid-capture case changes data integrity and operator expectations. Its end state cannot be assigned from the supplied need. The source scenario does not say whether a partial image may remain or whether the payload can retry. That decision belongs to the operational owner and should become a separate alternate path once agreed.
Write only consequential paths
- State the initiating actor, starting mode and conditions before the trigger.
- Order actions across the chosen boundary and record each observable handoff.
- Add an alternate path where a real decision or result changes.
- Give every path a named end state and flag recovery behavior with no authority.
Questions about this task
How many scenarios are enough?
Cover distinct operational decisions and failure outcomes; avoid one scenario per sentence when the paths behave the same.
Can I draft a missing recovery path?
Yes, as a proposed option with the decision owner and evidence gap, never as an already approved operating rule.
Sources and further reading
- NASA Systems Engineering Handbook: system design processes: Stakeholder expectations, logical decomposition, functional allocation and design decisions.
- NASA Systems Engineering Handbook: product realization: Interface definition, integration sequence and verification context.