Arc Skills / Requirements

Rewrite a requirement using EARS

Arc Skills selects the simplest EARS sentence form that preserves the original engineering intent. It returns original and proposed wording side by side with any trigger or definition that still needs approval.

Use this skill

Use Arc Skills to rewrite the supplied requirements using appropriate EARS patterns.

Inputs:
- Original IDs, exact wording, revisions, and source
- Controlled event, state, abnormal-condition, and feature definitions
- Approved limits, units, modality, and exceptions to preserve

Return a pattern choice and original-versus-proposed wording for each requirement.
Keep trigger, actor, response, and quantities intact. Do not add timing or design behavior without source authority

Set up the toolkit · Read the skill instructions

What you provide and what you get

Inputs and outputs
What you have	How it is used	What you get
Original requirement	Preserves the source obligation	Proposed EARS wording
Event and state definitions	Chooses event versus state syntax	Open definition question
Source constraints	Prevents invented limits or behavior	Intent-preservation note

Image capture on a command event

Illustrative engineering example.

The original sentence places the trigger at the end. The event-driven EARS form makes it easier to scan without changing what the camera must do.

R-30: The camera shall capture an image when it receives a valid capture command.
R-31: The camera shall identify its serial number on the housing.
Definition of “valid capture command”: [not supplied].

Image capture on a command event — illustrative output
Original ID and wording	EARS pattern / proposal	Preserved intent and open point
R-30: The camera shall capture an image when it receives a valid capture command.	Event-driven: When the camera receives a valid capture command, the camera shall capture an image.	Same actor, event, and response; valid remains undefined.
R-31: The camera shall identify its serial number on the housing.	Ubiquitous: retain the original statement.	No event is needed; inspect legibility criterion separately.
R-30 timing	No timing phrase added.	The source contains no response latency; ask for an approved source before adding one.

R-30 is a syntax rewrite, not derivation. It moves the event to the front but does not turn a received command into a persistent “while commanded” state.

R-31 shows that EARS does not require cosmetic change to every sentence. The missing definition of valid is a separate quality issue and remains open after rewriting.

Choose the pattern that matches the condition

Identify whether the obligation is always active, event-triggered, state-bound, abnormal, or feature-dependent.
Move only the actual trigger or state into the matching EARS position.
Compare actor, response, modality, quantities, and exceptions with the original.
List unresolved terms and avoid adding design or performance detail.

Questions about this task

Does EARS fix an undefined valid command?

No. The syntax exposes the event but the project must still define validity.

Should a simple statement always be rewritten?

No. Keep clear ubiquitous wording when an added pattern would add no meaning.

Sources and further reading

Alistair Mavin, EARS: Author overview of the event, state, and other EARS sentence patterns.
NASA Systems Engineering Handbook: Lifecycle and requirements guidance; the example decisions are illustrative.