EARS (Easy Approach to Requirements Syntax) è una notazione dei requisiti: un piccolo insieme di modelli di frase in inglese, detto anche sintassi EARS, che tiene una condizione, un innesco e una risposta del sistema in un ordine fisso. Un requisito è un obbligo verificabile che un sistema deve soddisfare. Lo sviluppo guidato dalle specifiche (SDD, spec-driven development) è la pratica di scrivere quell’obbligo in una specifica prima del codice e di trattare la specifica come fonte di verità. Un documento dei requisiti di prodotto (PRD, product requirements document) è la prosa che enuncia il problema e l’ambito prima di spezzare il lavoro in attività. In SpecScore, un requisito (REQ) è una regola con nome dentro una funzionalità, e un criterio di accettazione (AC, acceptance criterion) è una condizione astratta facoltativa che punta a una o più di quelle regole. L’integrazione continua (CI, continuous integration) è un controllo automatico su ogni modifica proposta. Il controllo è un comando dell’interfaccia a riga di comando (CLI, command-line interface): specscore spec lint. Kiro, un ambiente di sviluppo integrato (IDE, integrated development environment) agentico di Amazon Web Services (AWS), scrive uno di questi modelli. La notazione fu pubblicata per la prima volta da Alistair Mavin e colleghi alla Rolls-Royce in una conferenza di ingegneria dei requisiti dell’Institute of Electrical and Electronics Engineers (IEEE) nel 2009.
Ultimo aggiornamento: 2 novembre 2026
Alistair Mavin, Philip Wilkinson, Adrian Harwood e Mark Novak, allora alla Rolls-Royce PLC, pubblicarono “Easy Approach to Requirements Syntax (EARS)” alla 17th IEEE International Requirements Engineering Conference nel 2009. L’identificatore del documento è 10.1109/RE.2009.9. Costruirono le regole estraendo requisiti di controllo motore dalla Certification Specification for Engines (CS-E), sezione CS-E 50, un regolamento di aeronavigabilità. Quel testo mescolava requisiti, guida di progetto e note.
L’articolo nomina otto problemi del linguaggio naturale non vincolato: ambiguità, vaghezza, complessità, omissione, duplicazione, verbosità, implementazione inappropriata e non testabilità. Un piccolo insieme di regole doveva far usare a ogni requisito uno di cinque modelli. Gli autori dicono che la notazione è adatta ai requisiti di alto livello degli stakeholder e non affermano che copra ogni livello di scomposizione di un sistema.
La guida dello stesso Mavin descrive EARS come un modo per vincolare con dolcezza i requisiti testuali. Le clausole restano in un ordine, che lui chiama logica temporale: ogni precondizione, poi l’innesco, poi il nome del sistema e la risposta. Il suo insieme di regole è zero o molte precondizioni, zero o un innesco, un nome di sistema e una o molte risposte. L’articolo del 2009 specializza quella forma in cinque modelli. La stessa guida nomina anche i requisiti complessi, che combinano le parole chiave.
Nello studio di caso dell’articolo, l’estratto grezzo aveva 36 requisiti e l’insieme riscritto 47. La lunghezza media scese da 36,9 a 25,6 parole. Gli autori riferiscono che, in quello studio, complessità, omissione, duplicazione, implementazione inappropriata e non testabilità erano assenti dall’insieme riscritto, mentre ambiguità, vaghezza e verbosità diminuirono senza sparire. Elencano anche i limiti: un campione piccolo, solo requisiti di sicurezza di alto livello e un giudizio nel classificare la vaghezza. Quei numeri sono dell’articolo, per quel solo documento.
Le parole chiave sono quelle dell’articolo del 2009 e della guida di Mavin. L’articolo consente anche During al posto di While per uno stato, con lo stesso significato, quando si legge meglio. Le frasi di esempio illustrano i modelli. Non sono citazioni dell’articolo. Kiro scrive il modello guidato da evento in maiuscolo; la notazione originale usa l’iniziale maiuscola. Gli esempi restano in inglese perché la sintassi EARS è inglese.
The <system name> shall <system response>
Sempre attivo. Non c’è una parola chiave EARS, perché non ci sono precondizione né innesco. L’illustrazione dell’articolo del 2009 è un sistema di controllo che deve impedire il fuorigiri del motore.
Esempio The checkout system shall keep the order total equal to the sum of its line items.
When <trigger>, the <system name> shall <system response>
La risposta è richiesta quando un innesco è rilevato al confine del sistema, e solo allora. La parola chiave è When.
Esempio When a shopper submits the checkout form with invalid data, the checkout system shall show a validation error next to the invalid field.
While <precondition>, the <system name> shall <system response>
La risposta è richiesta finché il sistema resta nello stato nominato. La parola chiave è While.
Esempio While the cart is empty, the checkout system shall keep the pay button disabled.
If <trigger>, then the <system name> shall <system response>
La risposta tratta un guasto, un disturbo, una deviazione o un altro comportamento indesiderato. Le parole chiave sono If e then. L’articolo diede a questo modello parole chiave proprie perché quei requisiti restino visibili. Gli autori notano che desiderato e indesiderato è a volte una questione di punto di vista.
Esempio If the submitted email is not a valid address, then the checkout system shall reject the form.
Where <feature is included>, the <system name> shall <system response>
La risposta vale solo se il prodotto include la funzione nominata. La parola chiave è Where.
Esempio Where the shop includes gift wrapping, the checkout system shall offer gift wrapping on the order review step.
While <precondition>, when <trigger>, the <system name> shall <system response>
Più di una parola chiave. La guida di Mavin mantiene lo stesso ordine delle clausole: While per la precondizione, poi When per l’innesco, poi la risposta del sistema. L’articolo del 2009 combina anche While con If / then per un comportamento indesiderato in uno stato. Un’illustrazione di quella combinazione: While the shopper is signed out, if the shopper submits the checkout form, then the checkout system shall refuse the order.
Esempio While the shopper is signed in, when the shopper submits a valid checkout form, the checkout system shall place the order.
L’articolo tratta una frase composta come il problema della complessità e la divide. La specifica dei requisiti SpecScore dice la stessa cosa nei suoi termini: ogni REQ deve esprimere esattamente un obbligo verificabile.
When è per un innesco atteso. If / then è per il comportamento che si preferirebbe non incontrare. Una sola parola chiave per entrambi fa sembrare il caso indesiderato quello normale: è il problema di omissione che l’articolo segnala.
“The checkout system shall store the flag in Redis” nomina un progetto. L’articolo lo chiama implementazione inappropriata. La risposta deve dire che cosa il sistema deve ottenere, non quale componente lo fa.
“When the form is submitted, shall show an error” non ha soggetto. L’insieme di regole di Mavin richiede un nome di sistema.
“The checkout system shall show an error when the form is submitted” mette l’innesco in fondo. L’ordine pubblicato è precondizione, poi innesco, poi risposta.
La pagina delle specifiche di funzionalità di Kiro pubblica un solo modello, WHEN … THE SYSTEM SHALL …. L’ubiquo, While, If / then, Where e le combinazioni complesse fanno parte della notazione nell’articolo e nella guida di Mavin. Non sono su quella pagina di Kiro.
La pagina delle specifiche di funzionalità di Kiro, segnata come aggiornata il 4 agosto 2026 e letta il 2 novembre 2026, dice che il file requirements.md usa EARS. Il modello stampato è WHEN [condition/event] seguito da THE SYSTEM SHALL [expected behavior]. L’esempio della pagina: WHEN a user submits a form with invalid data, THE SYSTEM SHALL display validation errors next to the relevant fields.
La pagina requisiti per primi dice che un requirements.md generato include user story con criteri di accettazione e comportamenti di sistema in quella stessa forma WHEN … THE SYSTEM SHALL …. L’esempio di registrazione è tre frasi: dati di registrazione validi creano un account, un’email già esistente mostra “Email already registered” e un formato email non valido mostra un errore di validazione.
Prima del progetto, Analyze Requirements cerca incoerenze logiche, ambiguità, vincoli in conflitto e lacune. La pagina dice che lo si sceglie dalle opzioni della chat o dal menu Continue nell’editor dopo aver generato i requisiti. design.md e tasks.md stanno accanto ai requisiti. Quick Spec esegue requisiti, progetto e attività senza una sosta di approvazione fra loro.
Quell’analisi è un passo dentro Kiro. La pagina non la descrive come un linter di formato da aggiungere alla propria CI. Come gli altri strumenti controllano una specifica è nella guida degli strumenti. Il confronto dei due prodotti è SpecScore vs Kiro.
SpecScore non controlla che una frase corrisponda a un modello EARS. specscore spec lint, dal repository specscore-cli, controlla la struttura. Il testo di aiuto nomina file README, sezioni Open Questions, livelli di titolo, riferimenti a funzionalità, link interni e voci di indice. Una frase EARS può essere la prosa sotto un titolo REQ. Il linter non valuta l’inglese.
La specifica dei requisiti mette ogni requisito sotto un titolo di argomento dentro ## Behavior, un livello più in basso, di solito #### REQ: slug. Lo slug usa lettere minuscole, numeri e trattini. L’identificatore è {feature-path}#req:{slug}. La specifica dice che un requisito dovrebbe usare le parole chiave di RFC 2119 (Request for Comments 2119): MUST, MUST NOT, SHOULD, SHOULD NOT e MAY. Nella corrispondenza sotto, lo shall di EARS è scritto MUST.
Un criterio di accettazione è facoltativo. Quando se ne usa uno, è ### AC: slug dentro ## Acceptance Criteria, e la riga successiva è **Requirements:** con quegli identificatori. La specifica dei criteri di accettazione dice che l’AC enuncia una condizione astratta e non deve contenere passi Given/When/Then, input concreti o dettagli di implementazione. Un flusso concreto è uno scenario nella directory _tests/ della funzionalità. La specifica di funzionalità richiede anche uno stato, un riepilogo, un problema, il comportamento, criteri di accettazione, domande aperte e un piè di aderenza.
I file sotto sono una funzionalità di checkout. show-field-error è l’esempio guidato da evento. reject-invalid-email è l’esempio di comportamento indesiderato. Il 2 novembre 2026, specscore spec lint ha riportato 0 violazioni per questo albero con specscore 0.55.1, l’ultima versione pubblicata il 30 ottobre 2026, e con specscore 0.39.1, la versione fissata in dogfood.yml. Il repository del formato è dove vive quel flusso.
---
format: https://specscore.md/feature-specification
status: Draft
---
# Feature: Checkout validation
> [SpecScore.**Studio**](https://specscore.studio): | [Explore](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=explore) | [Edit](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=edit) | [Ask question](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=ask) | [Request change](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=request-change) |
**Status:** Draft
**Source Ideas:** —
## Summary
The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address.
## Problem
A vague sentence such as "the form should handle bad input" does not say which event causes which response. Checkout needs those obligations written so a reviewer and a linter can point at them.
## Behavior
### Field validation
The checkout system checks the form when the shopper submits it.
#### REQ: show-field-error
When a shopper submits the checkout form with invalid data, the checkout system MUST show a validation error next to the invalid field.
#### REQ: reject-invalid-email
If the submitted email is not a valid address, then the checkout system MUST reject the form.
## Acceptance Criteria
### AC: invalid-submission
**Requirements:** checkout#req:show-field-error, checkout#req:reject-invalid-email
Submitting the checkout form with invalid data shows a validation error next to the invalid field, and an email that is not a valid address is rejected.
## Open Questions
None at this time.
---
*This document follows the https://specscore.md/feature-specification*
---
format: https://specscore.md/features-index-specification
---
# Features
| Feature | Status | Description |
|---|---|---|
| [Checkout validation](checkout/README.md) | Draft | The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address. |
## Open Questions
None at this time.
---
*This document follows the https://specscore.md/features-index-specification*
# Checkout specification
## Open Questions
None at this time.
# SpecScore Repo Config Schema: https://specscore.md/repo-config
project:
title: Checkout sample
host: github.com
org: example
repo: checkout
Sono comparsi altri due errori mentre si faceva passare questo esempio, ed entrambi sono corretti nei file sopra. Una funzionalità senza **Source Ideas:** è fallita su feature-source-ideas-required; — è il valore vuoto. L’indice delle funzionalità aveva anche bisogno del campo di frontmatter format: https://specscore.md/features-index-specification.
Il passaggio del linter significa che i file rispettano quelle regole di struttura. Non significa che le frasi siano buon EARS, né che il prodotto di checkout esista. Il Given/When/Then di questo comportamento sarebbe un file di scenario sotto spec/features/checkout/_tests/, non un altro paragrafo dentro l’AC.
Easy Approach to Requirements Syntax. È un insieme di modelli di frase per i requisiti, pubblicato da Alistair Mavin, Philip Wilkinson, Adrian Harwood e Mark Novak della Rolls-Royce alla 17th IEEE International Requirements Engineering Conference nel 2009, e descritto sul sito di Mavin.
La pagina delle specifiche di funzionalità di Kiro fissa un modello: WHEN … THE SYSTEM SHALL …. L’articolo del 2009 e la guida di Mavin definiscono anche requisiti ubiqui, While guidato da stato, If/then per il comportamento indesiderato, Where per una funzione opzionale e combinazioni complesse di quelle parole chiave.
No. specscore spec lint valida la struttura dei file SpecScore. Una frase EARS può essere la prosa di un REQ. Il linter non valuta l’inglese.
In uno scenario sotto la directory _tests/ della funzionalità. Un criterio di accettazione resta una condizione astratta e, nella specifica dei criteri di accettazione, non deve contenere passi Given/When/Then.
Letto il 2 novembre 2026, tranne dove una pagina stampa la propria data di aggiornamento. La pagina delle specifiche di funzionalità di Kiro dice di essere stata aggiornata il 4 agosto 2026.
Have an idea how to improve this page?