Arc Skills / Requirements
Review a requirement against ECSS-E-ST-10-06
Use Arc Skills to review a requirement against the applicable ECSS-E-ST-10-06 edition. Get phrase-level findings with inspected clause references, proposed wording and a separate list of project information needed to complete the review.
Use this skill
Use Arc Skills to review this requirement against ECSS-E-ST-10-06.
Inputs:
- Original requirement ID, wording and revision
- Applicable ECSS edition and project tailoring
- Relevant specification context and definitions
For each finding, return the exact phrase, engineering consequence, inspected clause and proposed correction. Separate wording issues from missing project context.
Preserve the original statement. Use placeholders for missing engineering values. If the source cannot be inspected, identify the unsupported review scope.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| One controlled requirement | Inspect actor, conditions and measurable obligation | Phrase-level findings preserving the source |
| Applicable ECSS edition and tailoring | Check the actual governing criteria | Clause-grounded review |
| Specification context and definitions | Resolve boundary and verification questions | Proposed wording and open owner decisions |
Inspect the requirement and applicable standard
Synthetic requirement REQ-004: “The unit shall provide an appropriate warning quickly.”
This reference review uses ECSS-E-ST-10-06C, 6 March 2009, printed pages 24–27, inspected on 3 October 2026. A real review must use the edition and tailoring applicable to your project.
Findings with inspected clause references
| Exact phrase | Engineering consequence | Source locator | Proposed action |
|---|---|---|---|
| “appropriate warning” | The warning’s content, recipient and indication are undefined. | 8.2.4(a), p.25: unambiguous meaning; 8.3.3(a), p.27: restricted wording includes “appropriate”. | Define the warning behaviour and remove the vague term. |
| “quickly” | No time bound or start event makes latency decidable. | 8.2.1(a), p.24: quantified terms; 8.2.9(a), p.26: approved verification methods. | Request the approved trigger, latency and verification approach. |
| “The unit” | The intended product boundary is absent from this example. | 8.2.6(a), p.25: identification relative to function, product or system. | Inspect the specification context before judging this an issue. |
The wording has issues under the cited criteria if those criteria apply. Ownership, traceability, configuration control and approved verification arrangements cannot be assessed from one statement. Do not turn absent context into a confirmed failure.
Propose wording without inventing the engineering values
Original: The unit shall provide an appropriate warning quickly.
Proposal: Upon [defined fault trigger], the [identified unit] shall
provide [defined warning indication] to [identified recipient]
within [approved maximum latency].The bracketed values are open decisions, not an acceptable finished requirement. Preserve REQ-004 beside the proposal and obtain the missing values from the engineering owner. Selecting a latency merely because it sounds plausible would change engineering intent.
Separate confirmed wording issues from missing context
- Pin the requirement revision and applicable standard edition, including tailoring.
- Compare the exact wording with inspected criteria and retain clause/page locators.
- Classify missing context separately from a confirmed defect in the statement.
- Propose wording that preserves intent and leaves unapproved limits as owner decisions.
Sources and further reading
- ECSS-E-ST-10-06C, 6 March 2009: section 8, printed pages 24–27, inspected for this example on 3 October 2026.
- AI-assisted ECSS review guide: broader context for source-grounded review.
Synthetic requirement and authored review. Clause summaries identify the source; the applicable edition and tailoring govern a project review.