User:Thomasder7/EARS

The Easy Approach to Requirements Syntax (EARS) is a requirements engineering related notation that restrains the demands of text in a predefined structure. The simplicity provided by the EARS structure allows the author to focus on the substance of requirements, instead of the mechanics of the writing. The notation uses a basic pattern and a set of underlying principles to construct natural language requirements. To identify different clauses within a question, EARS uses a set of keywords and a pattern that results in a select number of natural language patterns.

Background
The EARS notation was initially developed in 2009 at Rolls-Royce Aero Engines. This relatively new notation was designed to translate the complex elements of an aircraft system into manageable and understandable requirements. Back then, inexperienced people documented the requirements for aircraft systems in non-structured natural language. Different non-textual notations were available to resolve this issue, like UML and SysML. However, learning these tools was difficult and prone to errors. That's when EARS was developed, aimed to keep the current market position and satisfy the customers.

The first set of guidelines forced the natural language into a pattern, and this would make the requirements easier to understand. In the implementation, it became clear that the notation criteria force the requirements to be linguistically identical. To share knowledge and improve the notation even more, the author officially published an EARS article at the IEEE "RE09" International Requirements Engineering conference.

In 2016, several researchers applied the EARS notation, and the article gave an overview of the many project types where EARS was utilized, and the paper discussed the deployment strategies. The EARS practitioners talked about how to decrease bias and guarantee that the findings are generalizable.

Pattern
The EARS notation exists through a pattern, the structure of the EARS requirements uses the following format : Depending on the circumstances, preconditions and triggers are both optional. Besides that, the order of the phrases in this language is also significant. Any EARS requirement must use the following criteria:

Steps
 * Any prerequisites must be met for the requirement to ever be activated.
 * The requirement can only be "triggered" if the trigger is valid and the prerequisites have been met.
 * When and only if the trigger and minimum standards are met, the system must execute the specified response of the system.

The following basic need patterns emerged when the EARS model was applied to a number of case studies :

Example
The following table provides an example of applying EARS for an ATM :

Advantages
In the literature, there are three main advantages of EARS.

The first advantage according, to Mavin (2016) is consistency. The power of consistency is that it is supported by the human brain's innate ability to recognize patterns. In particular, humans are excellent at recognizing patterns; this makes each demand more similar and hence simpler to understand. EARS can help with this uniformity, but any kind of consistency would be advantageous.

The second advantage is that EARS has the benefit of being a simple solution that doesn't require any tool support or specialized syntax. EARS may be implemented in a basic program like Word or Excel, or with the assistance of specialized tools. The EARS authors' experience demonstrates that participants typically shy away from specialized tools.

The third advantage is that the EARS approach's simplicity makes it easy to understand, and individuals will write requirements immediately. Each and every EARS practitioners suggests quick training sessions. Typically, a half-day requirements engineering course includes EARS training. Smaller groups or even lone users can learn how to utilize EARS in about an hour if they have prior writing expertise and are given the necessary assistance. EARS practitioner also recommend the use of a simple summary to complement this short and effective instruction. .

Criticism
Although EARS has gained a widespread adoption and is used by numerous organizations worldwide, it has some limitations and problems.


 * Complexity: The EARS method can be complicated if a practitioner is not familiar with the use of a syntax or notation. Mavin (2019) suggests that "people need adequate training and follow-up support to effectively use the method.".


 * Time-consuming: Marvin et al. (2016) suggest that people who are new to the EARS method should practice using it and have it reviewed by experts, this may be time-consuming. They recommend that authors should also strive to improve their requirements and be willing to revise their drafts.


 * No visual representation: User stories and use cases are often represented visually, such as with a use case diagram or user story map . In contrast, the EARS method does not have a visual representation.


 * Granularity: The EARS method involves breaking down requirements into smaller pieces in order to better understand and manage them. However, it may not be as effective for dealing with low-level scenarios where the complexity of requirements can increase. As Mavin (2019) pointed out, "A requirement that appears to meet the rules at a surface level may still be ambiguous." . Therefore, it is important to consider the level of detail or granularity when using the EARS method.
 * Non-functional requirements (NFR): EARS has been debated as useful for functional vs. non-functional requirements. Marvin et al. (2016) says it's only for functional requirements, while Mavin et al. (2019) claims limited use for non-functional. Both agree it can be used for some types of non-functional requirements.

Future development
Since the emergence of the EARS notation in the field of requirements engineering, there has been much ongoing development within this new method. For instance, it was recognized by the original authors that work was needed on the pattern for non-functional requirements. Although the author has done so, there is still a need to make these adjustments more apparent. Besides the limitations mentioned, there is little literature available on future adaptations of the EARS. The author's latest published paper does mention that many professionals now work with draft requirements. .

EARS variants
In the field of requirements specification and modelling, there are several different languages and methods that can be used to shape requirements, including EARS, use cases, and user stories. The most appropriate choice for a given situation depends on the system, context, and granularity.

User story
User stories are short tasks that derive from the agile ecosystem [1]. They use a straightforward definition to formulate developers' tasks [1].

While use cases and user stories are often too short, the EARS notation provides more comprehensive system requirements and design definitions. The use of natural language in requirements specification can lead to issues such as: "untestability, implementation problems, wordiness, duplication, omissions, complexity, vagueness, and ambiguity" [2]. EARS provides a framework for structuring and constraining natural language, helping to create consistent, clear requirements.

Use case diagram
A Use case diagram visually represents the relation between use cases and actors. Unless the compatibility with UML, use case diagrams may contain unclear or vague terminology. Therefore it could be difficult to extract them precisely. The EARS notation does contain a set of patterns, which force the text into a structure.

Versions of EARS
Since the development of the original EARS, a couple of derivative versions and tools were developed.

T-Ears
Timed – Easy Approach to Requirements Syntax (T-Ears) has five main pillars: "Boilerplates, Data Types, Expressions, Timing, and Structural Elements." The SAGA tool was the precursor of the T-EARS toolset. It is used for passive testing in the field of requirements engineering.

Adv-Ears
The variety in expressing any form of need is provided by Adv-EARS, which greatly expands on the four fundamental components. In the Adv-EARS model, the English grammar structure has been mapped. Then, grammar is suggested to analyze Adv-EARS requirements papers to identify the components of use case diagrams, from which the latter would be constructed automatically.

EARS-CTRL (tool)
With the EARS-CTRL tool, a step can be taken toward building controllers with natural language as the primary specification. After defining the terminology to be used in the specification, a requirements engineer creates the specification using the EARS notation.