Jump to content

User:Thomasder7/sandbox

From Wikipedia, the free encyclopedia
Easy Approach to Requirements Syntax
Developer(s)Rolls-Royce
TypeRequirements management

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 [1]. 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 [2] .

Background

[edit]

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 [3] [4].

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 [2]. 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 [4] [5].

Languages and notations

[edit]

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[6].

Other languages and notations are:

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

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[1].

Pattern

[edit]

Following is the general requirement syntax used in EARS [4]:

<optional preconditions> <optional trigger> the <system name> shall <system response>

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 [4]:

  • 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

[edit]

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

Pattern name[2] Pattern[2]
Ubiquitous A ubiquitous necessity is always present and takes the shape of “The <system name> shall <system response>”.
State driven While a certain precondition is still true, a state-driven demand is active and has the form of  “WHILE <precondition> the <system name> shall <system response>”.
Event-driven When a prompting incident is discovered at the scope of the system, an event-driven requirement is activated and takes the shape of “WHEN <trigger> the <system name> shall <system response>”.
Option Systems with a specific feature are given an Option requirement, which has the form “WHERE <feature is included> the <system name> shall <system response>”.
Unwanted behaviour A requirement for Unwanted Behaviour outlines the appropriate system reaction to an unwelcome external occurrence and takes the form of “IF <trigger> THEN the <system name> shall <system response>”.
Complex Complex requirements can be created by combining the fundamental EARS patterns, for instance with the following syntax “WHILE <precondition> WHEN <trigger> the <system name> shall <system response>”.

Example

[edit]

The following list shows an example of how EARS can be used [3]:

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

[edit]

Since the development of the original EARS a couple of derivative versions.

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

Advantages

[edit]

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 [2].

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 [2].

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 [2] [5]. 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 [2].

Key Benefits

[edit]

The following list are ten key benefits of using EARS [3]:

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

[edit]

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

  • 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[1] 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[14]. In contrast, the EARS method does not have a visual representation[4].
  • 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[1] 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 [2] says it's only for functional requirements, while Alistair[1] claims limited use for non-functional. Both agree it can be used for some types of non-functional requirements.

Future development

[edit]

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[1].

  1. ^ a b c d e f Mavin Mav, Alistair; Wilkinson, Philip (2019). "Ten Years of EARS". IEEE Software. 36 (5): 10–14. doi:10.1109/MS.2019.2921164. ISSN 1937-4194 – via IEEE Software.
  2. ^ a b c d e f g h i j k Mavin, Alistair; Wilksinson, Philip; Gregory, Sarah; Uusitalo, Eero (2016). "Listens Learned (8 Lessons Learned Applying EARS)". 2016 IEEE 24th International Requirements Engineering Conference (RE). IEEE. doi:10.1109/re.2016.38.
  3. ^ a b c Mavin, Alistair (2021). "Adopting the EARS Notation to Improve Requirements Engineering" – via ResearchGate. {{cite journal}}: Cite journal requires |journal= (help)
  4. ^ a b c d e Mavin, Alistair; Wilkinson, Philip; Harwood, Adrian; Novak, Mark (2009). "Easy Approach to Requirements Syntax (EARS)". 2009 17th IEEE International Requirements Engineering Conference. IEEE. doi:10.1109/re.2009.9.
  5. ^ a b Uusitalo, Eero; Raatikainen, Mikko; Mannisto, Tomi; Tommila, Teemu (2011). "Structured natural language requirements in nuclear energy domain towards improving regulatory guidelines". 2011 Fourth International Workshop on Requirements Engineering and Law. IEEE. doi:10.1109/relaw.2011.6050274.
  6. ^ a b c Dalpiaz, Fabiano (2020). "Conceptualizing Requirements using User Stories and Use Cases: A Controlled Experiment" (PDF). International Working Conference on Requirements Engineering: Foundation for Software Quality: 221–238 – via Springer.
  7. ^ Fauzan, Reza; Siahaan, Daniel; Rochimah, Siti; Triandini, Evi (2019). "Use Case Diagram Similarity Measurement: A New Approach". 2019 12th International Conference on Information & Communication Technology and System (ICTS). IEEE. doi:10.1109/icts.2019.8850978.
  8. ^ Liaskos, Sotirios; Lapouchnian, Alexei; Yu, Yijun; Yu, Eric; Mylopoulos, John (2006). "On Goal-based Variability Acquisition and Analysis". 14th IEEE International Requirements Engineering Conference (RE'06). IEEE. doi:10.1109/re.2006.45.
  9. ^ Dalpiaz, Fabiano; Franch, Xavier; Horkoff, Jennifer (2016-06-16). "iStar 2.0 Language Guide". arXiv:1605.07767 [cs].
  10. ^ Liu, Lin; Yu, Eric (2004). "Designing information systems in social context: a goal and scenario modelling approach". Information Systems. 29 (2): 187–203. doi:10.1016/s0306-4379(03)00052-8. ISSN 0306-4379.
  11. ^ Flemström, Daniel (2021). "Industrial scale passive testing with T-EARS". IEEE Conference on Software Testing, Verification and Validation (ICST). 14: 351–361 – via IEEE.
  12. ^ Majumdar, D; Sengupta, S; Kanjilal, A; Bhattacharya, S (2011-08-30). "Automated Requirements Modelling With Adv-Ears" (PDF). International Journal of Information Technology Convergence and Services. 1 (4): 57–67. doi:10.5121/ijitcs.2011.1406.
  13. ^ Lúcio, Levi; Rahman, Salman; Cheng, Chih-Hong; Mavin, Alistair (2017), Barrett, Clark; Davies, Misty; Kahsai, Temesghen (eds.), "Just Formal Enough? Automated Analysis of EARS Requirements", NASA Formal Methods, vol. 10227, Cham: Springer International Publishing, pp. 427–434, doi:10.1007/978-3-319-57288-8_31, ISBN 978-3-319-57287-1, retrieved 2023-01-12
  14. ^ Wautelet, Yves; Heng, Samedi; Hintea, Diana; Kolp, Manuel; Poelmans, Stephan (2016), Link, Sebastian; Trujillo, Juan C. (eds.), "Bridging User Story Sets with the Use Case Model", Advances in Conceptual Modeling, vol. 9975, Cham: Springer International Publishing, pp. 127–138, doi:10.1007/978-3-319-47717-6_11, ISBN 978-3-319-47716-9, retrieved 2023-01-12
Retrieved from "https://en.wikipedia.org/w/index.php?title=User:Thomasder7/sandbox&oldid=1133458995"