Requirements Specifications: Knowing What You're Trying To Do

When it comes to bridging the gap between “what the business wants” and “what the engineers build,” the industry has developed several distinct syntaxes. These range from narrative-driven structures (Gherkin) to rigid, logical constraints (EARS).

Here is a comparison of the most prominent specification and test definition styles.

1. Gherkin (Behavior-Driven Development)

Gherkin is the language used by tools like Cucumber. It is designed to be readable by non-technical stakeholders while remaining executable as automated tests.

Structure: Uses a Given-When-Then template.

• Given: The initial context (Setup).
• When: The event or action (Trigger).
• Then: The expected outcome (Assertion).

Best For: Validating user stories and business logic.

Pros: High readability; creates “Living Documentation.”

Cons: Can become verbose; “glue code” is required to connect the text to actual test scripts.

2. EARS (Easy Approach to Requirements Syntax)

Unlike Gherkin, which focuses on testing a behavior, EARS is a set of rules for writing better requirements to reduce ambiguity in complex systems (common in aerospace or medical software).

Structure: Uses specific patterns based on the type of requirement:

• Ubiquitous: “The system shall [action].”
• Event-Driven: “When [trigger], the system shall [action].”
• State-Driven: “While [state], the system shall [action].”
• Optional Feature: “Where [feature is included], the system shall [action].”

Best For: High-stakes systems engineering and hardware/software interfaces.

Pros: Eliminates “passive voice” and vague “shall” statements; incredibly rigorous.

Cons: Feels “stiff” to creative teams; doesn’t map directly to automated testing frameworks without translation.

3. Comparative Matrix

Style	Primary Goal	Target Audience	Key Keyword(s)
Gherkin	Test Automation / Behavior	POs, QAs, Devs	Given, When, Then
EARS	Requirement Clarity	Systems Engineers	While, Where, Shall
TDD (Unit)	Code Correctness	Developers	Assert, Expect, Should
Tabular	Data-driven Logic	Analysts, Devs	Input, Output, Table

4. Other Notable Systems

TDD Style (Unit Testing)

This is the “Developer’s Syntax.” It is purely technical and usually follows the AAA (Arrange, Act, Assert) pattern.

Example: expect(user.isAdmin).to.be.true;

Difference: It lacks the “human-readable” narrative of Gherkin and focuses on the implementation rather than the requirement.

Tabular / Decision Tables

Often used in FitNesse or Robot Framework, this style uses tables to define inputs and expected outputs.

Usage: Best for complex business rules with many permutations (e.g., insurance premiums or tax calculations).

Difference: It ignores the “sentence” structure of Gherkin and EARS entirely in favor of data grids.

Specification by Example (SbE)

This is less a syntax and more a methodology often implemented via Gherkin. It focuses on using concrete examples (real numbers, real names) rather than abstract requirements to define how a system should behave.

Summary: Which one to use?

Use Gherkin if you need a shared language between the Product Owner and the Developer to ensure the right thing is being built.

Use EARS if you are writing a technical spec for a complex system where a misunderstanding of a “condition” or “state” could lead to system failure.