User:Thomasder7/sandbox

The Easy Approach to Requirements Syntax (EARS) notation is a language, a framework that gently restrains the needs of text. EARS's simplicity transfers the emphasis from writing mechanics to requirement substance, emphasizing the latter. The EARS method uses a basic template and a set of underlying principles to construct natural language requirements. To identify various clauses within a demand, EARS employs a set of keywords and the utilizing template results in a select few patterns of natural language needs.

Background
At Rolls-Royce Aero Engines, EARS was initially developed in 2009. The specifications for an aero engine control system were determined by a team of cross-discipline engineers who examined an airworthiness rule. The group examined each sentence in the regulatory text to see if it included an explicit or implied reference to the engine control system. An first set of "regulations" was applied to each sentence that contained a requirement in order to make it clearer and easier to understand. Through repeated study, the rules were improved. It became evident throughout this analysis that the resulting criteria all matched a specific select few themes and were idiomatic identical. The EARS article was published as a result of this study 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. Many lessons were acquired while working on these projects. The EARS practitioners talked about how to decrease bias and guarantee that the findings are generalizable. EARS offers a method for "gently constraining" the use of formless natural language. Numerous organizations from various industries and nations have adopted the EARS notation.

Languages and notations
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, granularity.

Other languages and notations are:


 * User story
 * Use case diagram

User stories are short tasks that derive from the agile ecosystem. They use a straightforward definition to formulate developers tasks. Use case diagrams shows the different use cases. There are different goal modeling methods. KOAS is a target method for recording software requirements is called KAOS in requirements engineering. I* is a modeling language appropriate for the initial stages of system modeling to comprehend the issue domain. GRL is an i*-based modeling language but it is more about reasoning behind requirements.
 * Goal modeling
 * KOAS
 * i*
 * GRL

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. EARS provides a framework for structuring and constraining natural language, helping to create consistent, clear requirements.

Pattern
Following is the general requirement syntax used in EARS : The requirement author is compelled by this straightforward form to separate the circumstances under which the requirement may be the occurrence that sets off the requirement (trigger), the preconditions that make it possible, and the required system behaviour (system response). Based on the type of requirement, preconditions and triggers are both optional. Given that it adheres to temporal logic, the order of the phrases in this language is also significant :


 * Any prerequisites that must be met in order 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.

Steps
The following fundamental need patterns appeared when the EARS template was applied to a number of case studies :

Example
The following list shows an example of how EARS can be used :

1. Ubiquitous requirement

The mobile phone must weigh no more than XX grams.

2. State-driven requirement

The ATM will say "insert card to begin" even if there isn't a card in it.

3. Event driven requirements

When "mute" is chosen, the laptop shall stop producing any sounds.

4. Option

A sunroof control panel must be located on the driver door of any vehicle with a sunroof.

5. Unwanted behaviour

The website will say "please re-enter payment card details" if an incorrect credit card number is supplied.

6. Complex

When backward force is ordered when the airplane is on the floor, the engine control system must permit reverse thrust

Derivative versions and tools
Since the development of the original EARS a couple of derivative versions.


 * T-Ears (Timed – Easy Approach to Requirements Syntax)sch
 * Adv-Ears ( use case models from the functional requirements. In this paper we propose a formal syntax for requirements)
 * EARS control (tool for synthesizing and validating controller software for embedded system)

Advantages
The fact that EARS promotes consistency in criteria is one of its main advantages. In light of the fact that humans are excellent at recognizing patterns, this makes each demand more similar and hence simpler to understand. However, this uniformity can make a requirements document seem fairly boring and repetitious. Documents containing requirements are rarely enjoyed reading; they are not created for amusement. The uniformity of requirement expressions should be accepted by stakeholders as a positive trait. The advantages of consistency, clarity, and rigor—supported by the human brain's innate ability to recognize patterns—far outweigh the drawbacks of repetition. EARS can help with this uniformity, but any kind of consistency would be advantageous.

EARS has the benefit of being a simple solution that doesn't require any tool support or specialized syntax. EARS may be implemented "on the side of a cigarette packet," in a basic program like Word or Excel, or with the assistance of specialized tools. The EARS operators' experience demonstrates that participants typically shy away from specialized tools, as was noted in one of the general lessons. Without a tool, EARS can be utilized efficiently with any app.

The EARS approach's simplicity makes it easy to understand, and individuals will start writing improved requirements right away. Each and every seasoned EARS practitioner 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. The EARS practitioners also advise the use of a straightforward summary sheet to supplement this succinct, effective instruction. Authors of requirements might use this as a quick reference manual.

Key Benefits
The following list are ten key benefits of using EARS :

1.      Common mistakes that are often present in textual natural language requirements are reduced or even eliminated by EARS.

2.      Even though they were written by different authors, EARS criteria are more straightforward and uniform. Due to their clarity, EARS criteria can be understood by everyone, even those who may not be familiar with the EARS notation.

3.      There is very little training required; many firms educate EARS in a half-day or even less, and immediately notice an improvement in the written requirements standard.

4.      Both inexperienced and seasoned requirement writers benefit from EARS since they both produce higher-quality requirements more quickly. The majority of requirements are written iteratively; initial requirements are expanded upon and improved upon over time. First draft requirements are frequently significantly closer to the final requirement when employing EARS.

5.      Since the components of an EARS requirement are also present in models like activity diagrams and state charts, EARS complements them nicely. EARS is a useful tool for "stealth rigor," which is the gradual introduction of rigor into the requirements and systems engineering processes.

6.      Many of EARS' advantages apply to both individuals and teams. Although some people create better requirements than others, the consistency of EARS requirements has wider advantages that extend to the project team, the entire business, and even the supply chain.

7.      A project team may experience a supernatural event once they begin employing EARS. The usage of EARS frees up cognitive capacity to evaluate the semantics of a need because it explains and streamlines the syntax of requirements.

8.      Because of the features of EARS, development teams may more rapidly identify what is unknown but must be known in order to finish the requirements. EARS reveals what needs to be found where other notations could hide incomplete or absent information in unclear requirements statements. EARS enables teams to "start before the beginning" as a result.

9.      EARS assists in aligning people, process, and technology extremely early in the system development process, even before you have fully defined your development procedures or picked tools, as was previously noted. Your team will be able to produce requirements after they have a working knowledge of EARS.

10.   EARS can be utilized successfully without any tool assistance because the requirements are essentially in (gently limited) natural language.

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 and may not be able to capture certain requirements. This may be due to a lack of understanding of EARS' syntax. Marvin suggests that "people need adequate training and follow-up support to effectively use the method."


 * Time-consuming: Marvin and Gregory suggest that people new to the EARS method should practice using it and have it reviewed by experts. 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 Marvin 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. Gregory says it's only for functional requirements, while Alistair 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 EARS, there has been much ongoing development of the method. For instance, it was recognised by the developers that work was needed on the NFRs. 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.