Arc Skills / Requirements

Extract requirements from a customer document

Arc Skills reads a scoped customer document and produces a traceable candidate register. It keeps exact source wording beside normalized proposals and excludes informative context from binding-duty counts.

Use this skill

Use Arc Skills to extract candidate requirements from the supplied customer document.

Inputs:
- Document revision, section scope, and extraction rule for binding duties or broader needs
- Exact source text with page, clause, or paragraph locators
- Definitions, annexes, and referenced attachments needed to interpret the clauses

Return a candidate register with quotation, locator, modality, normalized proposal, classification, and reconciled counts.
Flag uncertain OCR, missing definitions, and informative passages. Do not assign final system IDs

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
Customer document	Supplies exact clauses and revision	Quoted candidate register
Extraction rule	Distinguishes binding duties from broader needs	Accepted, open, and excluded counts
Definitions and annexes	Resolves terms before normalization	Questions and source traces

One duty, one open clause, one informative sentence

Illustrative engineering example.

The illustrative excerpt is typed source text from CS-1 revision C, so the quotation is treated as exact. The authorized requester is not defined.

§4.2: The supplier shall provide a fault log within 24 h of a request.
§4.3: The log should identify the affected unit.
§4.4: A fault log would be useful for operations.

One duty, one open clause, one informative sentence — illustrative output
Locator and source	Class / candidate	Reason and open trace
CS-1 C §4.2: The supplier shall provide a fault log within 24 h of a request.	Open binding candidate: supplier provides log ≤24 h after request.	Requesting authority undefined; preserve exact clause as source.
CS-1 C §4.3: The log should identify the affected unit.	Open preference or candidate need; modality is should.	Ask customer whether mandatory before elevating to shall.
CS-1 C §4.4: A fault log would be useful for operations.	Excluded informative context	No obligated actor or required response.

The three source sentences reconcile to one binding candidate with an open term, one non-mandatory preference needing customer decision, and one excluded informative passage. Normalized text does not replace the controlled quote.

If the document later defines who may request a log, that definition should be traced to §4.2. Importing these candidates into a model is a separate reviewed mapping step.

Keep source and interpretation together

Fix the document revision, section range, and binding-duty extraction rule.
Read bounded clauses and retain exact text, locator, and modality.
Classify duty, preference, need, or context before proposing normalized wording.
Reconcile all examined passages and list missing definitions or unread annexes.

Questions about this task

Does should become shall in the model?

Only after the customer or controlling authority confirms that intent. Preserve the original modality meanwhile.

Can an informative sentence still matter?

Yes. It may explain operational context, but it should not be counted as a binding duty without another source.

Sources and further reading

NASA Systems Engineering Handbook: Lifecycle and requirements guidance; the example decisions are illustrative.