EARS (Easy Approach to Requirements Syntax) bir gereksinim notasyonudur: koşulu, tetikleyiciyi ve sistem yanıtını sabit bir sırada tutan küçük bir İngilizce cümle kalıbı kümesi. Buna EARS sözdizimi de denir. Gereksinim, bir sistemin karşılaması gereken tek bir sınanabilir yükümlülüktür. Spesifikasyon odaklı geliştirme (SDD, spec-driven development), bu yükümlülüğü koddan önce bir spesifikasyona yazmak ve spesifikasyonu doğruluk kaynağı saymaktır. Ürün gereksinimleri belgesi (PRD, product requirements document), iş görevlere bölünmeden önce sorunu ve kapsamı anlatan düzyazıdır. SpecScore içinde bir gereksinim (REQ), bir özelliğin içindeki adlandırılmış kuraldır; bir kabul ölçütü (AC, acceptance criterion) ise bu kurallardan birine ya da birkaçına işaret eden isteğe bağlı soyut bir koşuldur. Sürekli entegrasyon (CI, continuous integration), önerilen her değişiklikte otomatik bir denetimdir. Denetim, komut satırı arayüzü (CLI, command-line interface) komutudur: specscore spec lint. Kiro, Amazon Web Services (AWS) kaynaklı ajanlı bir tümleşik geliştirme ortamı (IDE, integrated development environment), bu kalıplardan birini yazar. Notasyonu ilk kez Alistair Mavin ve Rolls-Royce’taki çalışma arkadaşları, 2009’da Institute of Electrical and Electronics Engineers (IEEE) gereksinim mühendisliği konferansında yayımladı.
Son güncelleme: 2 Kasım 2026
O sırada Rolls-Royce PLC’de olan Alistair Mavin, Philip Wilkinson, Adrian Harwood ve Mark Novak, 2009’da 17th IEEE International Requirements Engineering Conference’ta “Easy Approach to Requirements Syntax (EARS)”ı yayımladı. Belge tanımlayıcısı 10.1109/RE.2009.9. Kuralları, bir uçuşa elverişlilik düzenlemesi olan Certification Specification for Engines (CS-E) bölüm CS-E 50’den motor kontrol gereksinimlerini çıkarırken kurdular. Kaynak metin gereksinimleri, tasarım rehberini ve notları karıştırıyordu.
Makale, kısıtlanmamış doğal dilin sekiz sorununu adlandırır: belirsizlik, muğlaklık, karmaşıklık, eksiklik, yineleme, sözcük bolluğu, uygunsuz gerçekleştirim ve sınanamazlık. Küçük bir kural kümesi, her böyle gereksinimin beş kalıptan birini kullanmasını sağlamalıydı. Yazarlar notasyonun üst düzey paydaş gereksinimlerine uyduğunu söyler ve bir sistemin her ayrıştırma düzeyini kapsadığını ileri sürmez.
Mavin’in kendi rehberi EARS’ı metin gereksinimlerini yumuşakça kısıtlamanın bir yolu olarak anlatır. Yan tümceler tek sırada durur; buna zamansal mantık der: herhangi bir önkoşul, sonra tetikleyici, sonra sistem adı ve yanıt. Kural kümesi sıfır ya da çok önkoşul, sıfır ya da bir tetikleyici, bir sistem adı ve bir ya da çok yanıttır. 2009 makalesi bu biçimi beş kalıba özelleştirir. Aynı rehber, anahtar sözcükleri birleştiren karmaşık gereksinimleri de adlandırır.
Makalenin vaka çalışmasında ham çıkarım 36 gereksinim, yeniden yazılmış küme 47 gereksinim içeriyordu. Ortalama uzunluk 36,9 sözcükten 25,6 sözcüğe indi. Yazarlar, o çalışmada karmaşıklık, eksiklik, yineleme, uygunsuz gerçekleştirim ve sınanamazlığın yeniden yazılmış kümede bulunmadığını; belirsizlik, muğlaklık ve sözcük bolluğunun azaldığını ama kalkmadığını bildirir. Sınırları da sayarlar: küçük örneklem, yalnızca üst düzey güvenlik gereksinimleri ve muğlaklığın sınıflandırılmasındaki yargı. Bu sayılar makalenin, tek bir belge içindir.
Anahtar sözcükler 2009 makalesindekiler ve Mavin’in rehberindekilerdir. Makale, bir durum için While yerine aynı anlamda During da kullanılabilir der; okuma daha açıksa. Örnek cümleler kalıpları gösterir. Makaleden alıntı değildir. Kiro olay güdümlü kalıbı büyük harfle yazar; özgün notasyon sözcüğe büyük harfle başlar. Örnekler İngilizce kalır, çünkü EARS sözdizimi İngilizcedir.
The <system name> shall <system response>
Her zaman etkindir. Önkoşul ve tetikleyici olmadığı için EARS anahtar sözcüğü yoktur. 2009 makalesinin kendi örneği, motorun aşırı devrini önlemesi gereken bir kontrol sistemidir.
Örnek The checkout system shall keep the order total equal to the sum of its line items.
When <trigger>, the <system name> shall <system response>
Yanıt, sistem sınırında bir tetikleyici algılandığında ve ancak o zaman gerekir. Anahtar sözcük When.
Örnek 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>
Yanıt, sistem adlandırılan durumda kaldığı sürece gerekir. Anahtar sözcük While.
Örnek While the cart is empty, the checkout system shall keep the pay button disabled.
If <trigger>, then the <system name> shall <system response>
Yanıt bir arızayı, bir bozucuyu, bir sapmayı ya da başka istenmeyen davranışı ele alır. Anahtar sözcükler If ve then. Makale bu kalıba kendi sözcüklerini verdi ki bu gereksinimler görünür kalsın. Yazarlar, istenen ile istenmeyenin bazen bakış açısı olduğunu belirtir.
Örnek 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>
Yanıt yalnızca ürün adlandırılan özelliği içerdiğinde geçerlidir. Anahtar sözcük Where.
Örnek 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>
Birden çok anahtar sözcük. Mavin’in rehberi aynı yan tümce sırasını korur: önkoşul için While, sonra tetikleyici için When, sonra sistem yanıtı. 2009 makalesi bir durumdaki istenmeyen davranış için While ile If / then birleşimini de kullanır. Bu birleşimin bir gösterimi: While the shopper is signed out, if the shopper submits the checkout form, then the checkout system shall refuse the order.
Örnek While the shopper is signed in, when the shopper submits a valid checkout form, the checkout system shall place the order.
Makale bileşik cümleyi karmaşıklık sorunu sayar ve böler. SpecScore gereksinim spesifikasyonu aynı şeyi kendi terimleriyle söyler: her REQ tam olarak bir sınanabilir yükümlülük ifade etmelidir.
When beklenen bir tetikleyici içindir. If / then karşılaşmamayı yeğleyeceğiniz davranış içindir. İkisi için tek sözcük, istenmeyen durumu normal durum gibi gösterir. Makalenin işaret ettiği eksiklik sorunu budur.
“The checkout system shall store the flag in Redis” bir tasarım adlandırır. Makale buna uygunsuz gerçekleştirim der. Yanıt, sistemin neyi başarması gerektiğini söylemeli, hangi bileşenin yaptığını değil.
“When the form is submitted, shall show an error” öznesizdir. Mavin’in kural kümesi bir sistem adı ister.
“The checkout system shall show an error when the form is submitted” tetikleyiciyi sona koyar. Yayımlanan sıra önkoşul, sonra tetikleyici, sonra yanıttır.
Kiro’nun özellik spesifikasyonları sayfası tek bir kalıp yayımlar: WHEN … THE SYSTEM SHALL …. Her yerde geçerli olan, While, If / then, Where ve karmaşık birleşimler makaledeki ve Mavin’in rehberindeki notasyonun parçasıdır. O Kiro sayfasında yoktur.
Kiro’nun özellik spesifikasyonları sayfası, 4 Ağustos 2026’da güncellendiği işaretli ve 2 Kasım 2026’da okundu, requirements.md dosyasının EARS kullandığını söyler. Basılan kalıp WHEN [condition/event] ardından THE SYSTEM SHALL [expected behavior]. Sayfanın örneği: WHEN a user submits a form with invalid data, THE SYSTEM SHALL display validation errors next to the relevant fields.
Önce gereksinimler sayfası, üretilen bir requirements.md dosyasının kullanıcı hikâyelerini, kabul ölçütlerini ve sistem davranışlarını aynı WHEN … THE SYSTEM SHALL … biçiminde içerdiğini söyler. Kayıt örneği üç cümledir: geçerli kayıt verisi bir hesap oluşturur, zaten var olan e-posta “Email already registered” gösterir, geçersiz e-posta biçimi bir doğrulama hatası gösterir.
Tasarımdan önce Analyze Requirements mantıksal tutarsızlıkları, belirsizlikleri, çatışan kısıtları ve boşlukları arar. Sayfa, gereksinimler üretildikten sonra bunu sohbet seçeneklerinden ya da düzenleyicideki Continue menüsünden seçtiğinizi söyler. design.md ve tasks.md gereksinimlerin yanında durur. Quick Spec, aralarında bir onay durağı olmadan gereksinimleri, tasarımı ve görevleri çalıştırır.
Bu çözümleme Kiro’nun içindeki bir adımdır. Sayfa bunu kendi CI’nıza ekleyeceğiniz bir biçim linter’ı olarak anlatmaz. Diğer araçların bir spesifikasyonu nasıl denetlediği araç rehberinde. İki ürünün karşılaştırması SpecScore vs Kiro.
SpecScore, bir cümlenin bir EARS kalıbına uyup uymadığını denetlemez. specscore-cli deposundaki specscore spec lint yapıyı denetler. Yardım metni README dosyalarını, Open Questions bölümlerini, başlık düzeylerini, özellik göndermelerini, iç bağlantıları ve dizin girdilerini sayar. Bir EARS cümlesi bir REQ başlığının altındaki düzyazı olabilir. Linter İngilizceyi notlamaz.
Gereksinim spesifikasyonu her gereksinimi ## Behavior içindeki bir konu başlığının altına, bir düzey aşağıya koyar; tipik olarak #### REQ: slug. Slug küçük harf, rakam ve tire kullanır. Tanımlayıcı {feature-path}#req:{slug}. Spesifikasyon, bir gereksinimin RFC 2119 (Request for Comments 2119) anahtar sözcüklerini kullanması gerektiğini söyler: MUST, MUST NOT, SHOULD, SHOULD NOT ve MAY. Aşağıdaki eşlemede EARS shall sözcüğü MUST olarak yazılır.
Bir kabul ölçütü isteğe bağlıdır. Kullanıldığında ## Acceptance Criteria içinde ### AC: slug olur ve sonraki satır bu tanımlayıcılarla **Requirements:** satırıdır. Kabul ölçütleri spesifikasyonu, AC’nin soyut bir koşul bildirdiğini ve Given/When/Then adımları, somut girdiler ya da gerçekleştirim ayrıntısı içermemesi gerektiğini söyler. Somut bir akış, özelliğin _tests/ dizinindeki bir senaryodur. Özellik spesifikasyonu ayrıca bir durum, bir özet, bir sorun, davranış, kabul ölçütleri, açık sorular ve bir uyum alt bilgisi ister.
Aşağıdaki dosyalar bir ödeme özelliğidir. show-field-error olay güdümlü örnektir. reject-invalid-email istenmeyen davranış örneğidir. 2 Kasım 2026’da specscore spec lint, bu ağaç için 30 Ekim 2026’da yayımlanan son sürüm specscore 0.55.1 ile ve dogfood.yml içinde sabitlenen specscore 0.39.1 ile 0 ihlal bildirdi. Biçim deposu bu akışın yeridir.
---
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
Bu örnek geçene kadar iki hata daha çıktı; ikisi de yukarıdaki dosyalarda giderildi. **Source Ideas:** olmayan bir özellik feature-source-ideas-required ile düştü; — boş değerdir. Özellik dizini ayrıca format: https://specscore.md/features-index-specification ön bilgi alanına ihtiyaç duydu.
Linter’ın geçmesi, dosyaların bu yapı kurallarına uyduğu anlamına gelir. Cümlelerin iyi EARS olduğu ya da ödeme ürününün var olduğu anlamına gelmez. Bu davranışın Given/When/Then’i, AC içindeki başka bir paragraf değil, spec/features/checkout/_tests/ altındaki bir senaryo dosyası olur.
Easy Approach to Requirements Syntax. Gereksinimler için bir cümle kalıbı kümesidir. Rolls-Royce’tan Alistair Mavin, Philip Wilkinson, Adrian Harwood ve Mark Novak tarafından 2009’da 17th IEEE International Requirements Engineering Conference’ta yayımlandı ve Mavin’in sitesinde anlatılır.
Kiro’nun özellik spesifikasyonları sayfası bir kalıp belirtir: WHEN … THE SYSTEM SHALL …. 2009 makalesi ve Mavin’in rehberi ayrıca her yerde geçerli gereksinimleri, durum güdümlü While’ı, istenmeyen davranış için If/then’i, isteğe bağlı özellik için Where’i ve bu anahtar sözcüklerin karmaşık birleşimlerini tanımlar.
Hayır. specscore spec lint SpecScore dosya yapısını doğrular. Bir EARS cümlesi bir REQ düzyazısı olabilir. Linter İngilizceyi notlamaz.
Özelliğin _tests/ dizinindeki bir senaryoya. Kabul ölçütü soyut bir koşul olarak kalır ve kabul ölçütleri spesifikasyonunda Given/When/Then adımları içermemelidir.
2 Kasım 2026’da okundu; bir sayfa kendi güncelleme tarihini basıyorsa o tarih geçerlidir. Kiro’nun özellik spesifikasyonları sayfası 4 Ağustos 2026’da güncellendiğini söyler.
Have an idea how to improve this page?