# EARS gereksinim sözdizimi örneklerle açıklandı Canonical: https://specscore.md/tr/articles/ears-requirements/ Son güncelleme: 2 Kasım 2026 [EARS](https://alistairmavin.com/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](https://specscore.md/tr/spec-driven-development/) (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](https://specscore.md/) 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](https://specscore.md/tr/validators/) (CI, continuous integration), önerilen her değişiklikte otomatik bir denetimdir. Denetim, [komut satırı arayüzü](https://specscore.md/tr/cli/) (CLI, command-line interface) komutudur: `specscore spec lint`. [Kiro](https://kiro.dev/), 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ı. ## EARS nereden geldi 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](https://doi.org/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](https://alistairmavin.com/ears/) 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. ## EARS cümle kalıpları 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. ### Her yerde geçerli `The shall ` 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. ### Olay güdümlü `When , the shall ` 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. ### Durum güdümlü `While , the shall ` 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. ### İstenmeyen davranış `If , then the shall ` 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. ### İsteğe bağlı özellik `Where , the shall ` 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. ### Karmaşık `While , when , the shall ` 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. ## Sık hatalar ### Bir cümlede birkaç yükümlülük Makale bileşik cümleyi karmaşıklık sorunu sayar ve böler. [SpecScore gereksinim spesifikasyonu](https://specscore.md/requirement-specification) aynı şeyi kendi terimleriyle söyler: her `REQ` tam olarak bir sınanabilir yükümlülük ifade etmelidir. ### İstenmeyen davranışı When içine gizlemek *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. ### Gerçekleştirmeyi yazmak “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. ### Sistem adı yok “When the form is submitted, shall show an error” öznesizdir. Mavin’in kural kümesi bir sistem adı ister. ### Tetikleyici yanıttan sonra “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 tek satırını bütün EARS sanmak 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 EARS’ı nasıl kullanır [Kiro’nun özellik spesifikasyonları sayfası](https://kiro.dev/docs/specs/feature-specs/), 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ı](https://kiro.dev/docs/specs/feature-specs/requirements-first/), ü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](https://specscore.md/tr/spec-driven-development/tools/). İki ürünün karşılaştırması [SpecScore vs Kiro](https://specscore.md/tr/vs/kiro/). ## Aynı gereksinim SpecScore’da SpecScore, bir cümlenin bir EARS kalıbına uyup uymadığını denetlemez. [specscore-cli](https://github.com/specscore/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](https://specscore.md/requirement-specification) 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ü](https://specscore.md/acceptance-criteria-specification) 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](https://specscore.md/scenario-specification). [Özellik spesifikasyonu](https://specscore.md/feature-specification) 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](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) içinde sabitlenen specscore 0.39.1 ile 0 ihlal bildirdi. [Biçim deposu](https://github.com/specscore/specscore) bu akışın yeridir. ### spec/features/checkout/README.md ```markdown --- 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* ``` ### spec/features/README.md — açıklama hücresi özelliğin özet cümlesidir. Linter’ın feature-index-row-sync kuralı daha kısa bir açıklamayı reddetti. ```markdown --- 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* ``` ### spec/README.md — Open Questions bölümünü kaldırmak oq-section: Open Questions section not found üretti. ```markdown # Checkout specification ## Open Questions None at this time. ``` ### specscore.yaml — project.host, project.org ve project.repo, studio-toolbar satırının karşılaştırıldığı değerlerdir. Onlarsız linter studio-toolbar: studio toolbar requires project host/org/repo bildirdi. ```yaml # 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. ## Sorular ### EARS ne anlama gelir? 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 notasyonu bütün EARS mı? 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. ### SpecScore EARS sözdizimini doğrular mı? 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. ### Given/When/Then örnekleri nereye gider? Ö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. ## Kaynaklar 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. - [Mavin, Wilkinson, Harwood ve Novak — Easy Approach to Requirements Syntax (EARS), 17th IEEE International Requirements Engineering Conference, 2009, DOI 10.1109/RE.2009.9](https://doi.org/10.1109/RE.2009.9) - [Alistair Mavin — EARS rehberi](https://alistairmavin.com/ears/) - [Kiro belgeleri — Özellik spesifikasyonları ve EARS (sayfa 4 Ağustos 2026’da güncellendi)](https://kiro.dev/docs/specs/feature-specs/) - [Kiro belgeleri — Önce gereksinimler akışı](https://kiro.dev/docs/specs/feature-specs/requirements-first/) - [specscore/specscore — gereksinim spesifikasyonu](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md) - [specscore/specscore — kabul ölçütleri spesifikasyonu](https://github.com/specscore/specscore/blob/main/spec/features/acceptance-criteria/README.md) - [specscore/specscore — senaryo spesifikasyonu](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md) - [specscore/specscore — özellik spesifikasyonu](https://github.com/specscore/specscore/blob/main/spec/features/feature/README.md) - [specscore/specscore — dogfood CI akışı](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) - [specscore/specscore-cli](https://github.com/specscore/specscore-cli) - [specscore/specscore](https://github.com/specscore/specscore) ## İlgili - [Yapay zeka ile kodlama için Markdown’da PRD şablonu](https://specscore.md/tr/articles/feature-spec-template/) - [Spesifikasyonları CI’da bir spesifikasyon linter’ı ile lintlemek](https://specscore.md/tr/articles/lint-specs-in-ci/) - [Bir yapay zeka ajanının doğrulayabileceği kabul kriterleri nasıl yazılır](https://specscore.md/tr/articles/acceptance-criteria/) - [SpecScore vs Kiro](https://specscore.md/tr/vs/kiro/) - [Spesifikasyon odaklı geliştirme araçları](https://specscore.md/tr/spec-driven-development/tools/) - [Spesifikasyon odaklı geliştirme](https://specscore.md/tr/spec-driven-development/) - [Gereksinim spesifikasyonu](https://specscore.md/requirement-specification) - [Kabul ölçütleri spesifikasyonu](https://specscore.md/acceptance-criteria-specification) - [Özellik spesifikasyonu](https://specscore.md/feature-specification) - [Doğrulayıcılar ve CI](https://specscore.md/tr/validators/)