# EARS Method to Write Clear System Requirements – Lesson 1

https://www.youtube.com/watch?v=IjENfvdh2Aw

[00:11] Writing good requirements is a challenging task.
[00:14] There are several common risks, such as lack of clarity, poorly structured sentences, ambiguous and subjective terms, and untestable statements.
[00:23] Consider the following requirement.
[00:25] The ACC must give priority to the driver's actions.
[00:29] The requirement lacks clarity because it does not specify under what conditions the driver's actions take precedence over the ACC system.
[00:37] Another example is the ACC does not consider weather conditions in the calculation of the safety distance.
[00:44] The requirement lacks exhaustiveness because it does not specify which weather conditions are not considered, such as rain, snow, or fog.
[00:54] To address these issues, we will learn about the easy approach to requirements syntax, or EARS.
[01:00] This method was developed by Alistair Mavin and his colleagues at Rolls-Royce
[01:04] in 2009 to improve the clarity, consistency, and understanding of requirements in complex projects, such as those in the aerospace industry.
[01:14] The EARS method is based on four main principles.
[01:16] Exhaustive.
[01:19] Requirements must cover all aspects of the system, including functionality, interfaces, constraints, and performance.
[01:26] Atomic.
[01:28] Requirements must be divided into independent, simple, and unambiguous elements.
[01:32] Realistic.
[01:34] Requirements must be achievable with available resources, technical constraints, and deadlines.
[01:40] Traceable.
[01:42] Requirements must be traceable throughout the system's life cycle, from design to maintenance.
[01:47] By following the EARS method, requirements are better defined, easier to understand and implement, and more likely to be met by the final system.
[01:55] This method also helps reduce the risk of misunderstandings, errors, and delays in system development.
[02:01] With the EARS method, we can differentiate five types of requirements
[02:04] patterns, along with their associated explanations.
[02:08] The first are ubiquitous requirements.
[02:10] They define the fundamental properties of the system.
[02:12] They are always applicable and ensure that certain basic functionalities are always present and operational.
[02:20] For example, the system name shall system response.
[02:25] Next, we have event-driven requirements.
[02:27] They are triggered only when a specific event occurs.
[02:30] This means that these actions happen solely in response to a particular trigger.
[02:36] For example, when trigger optional precondition the system name shall system response.
[02:44] The third are requirements for unwanted behaviors.
[02:46] They manage occurrences such as errors, failures, faults, disturbances, and other forms of undesired behaviors.
[02:54] They are designed to handle and mitigate these issues.
[02:56] For example, if unwanted condition or event then the system name shall
[03:06] For example, while system state the system name shall system response.
[03:08] Then, state-driven requirements are activated when the system reaches a certain state.
[03:14] This means that the defined action occurs as long as the system is in a specific state.
[03:27] To finish, and optional features are requirements that apply only in systems with a specific optional feature.
[03:33] They are invoked exclusively when the system has this particular option.
[03:38] For example, where feature is included the system name shall system response.
[03:45] And remember that for the most complex requirements, we can combine the various patterns mentioned before.
[03:51] At the beginning, we discussed some common issues with requirements, such as lack of clarity and exhaustiveness.
[03:57] Now, we will see how to correct these examples using the EARS patterns.
[04:02] The first example was the ACC must give priority to the driver's actions.
[04:07] could rewrite it as when the driver presses the accelerator or the brakes, then the ACC shall deactivate.
[04:15] By using the event-driven pattern, we specify that the ACC should deactivate only when a specific event, such as pressing the accelerator, occurs.
[04:24] This makes the requirement clear and specific.
[04:25] The other example was the ACC does not consider weather conditions in the calculation of the safety distance.
[04:33] To make a better requirement, we could write when the vehicle is calculating the safety distance, if weather conditions such as rain, snow, or fog are present then the ACC shall not adjust the safety distance based on these weather conditions.
[04:48] Here, by using the event-driven pattern with a when if then structure, the improved requirement specifies exactly when and under which conditions the ACC system's behavior is applicable.
[05:01] This makes the requirement more exhaustive and clear by explicitly listing the weather conditions that are not considered.
[05:06] And it eliminates
[05:08] ambiguities and ensures that everyone
[05:10] understands the limitations of the
[05:12] system.
[05:13] With this video, we hope you're now
[05:15] equipped to write clearer, more precise,
[05:17] and effective requirements that will
[05:19] lead to smoother project development and
[05:21] better system outcomes.
[05:27] [Music]