When Not to Use EARS
There are always exceptions!
The Easy Approach to Requirements Syntax (EARS) is a useful and popular method that has been adopted by many organizations in the requirements engineering field. This is due to its easy to learn and apply syntax patterns. EARS is a simple and logical method for constructing clear, concise and unambiguous Natural Language (NL) requirements.
However, not every requirement should be written in EARS. In certain cases, some requirements are simply too complicated for the EARS format. It is important to recognize when using another format is more appropriate.
As a rule of thumb, consider using other formats besides EARS:
- When the requirement extends complexity
- If you have more than 3 preconditions
- When requirements are mathematical
A requirement document can have a majority of natural language requirements written using EARS format, but a small subset of the requirements may be more clearly expressed in another format.
Requirements should be written in the notation that’s most appropriate for the user of the specification.
For high-level system requirements, the audience is usually a mixed group of users that you will need to accommodate. EARS fits perfectly in this scenario to make requirements clear, concise and testable in a form that’s logical to just about everyone.
Different forms of notations might be more fitting depending on your audience and their experience with requirements. Use the method that is most appropriate for the document’s users to understand and to capture exactly what the system must do.
Example Audience: Your document is a low-level software requirements specification and your audience is software developers. Software developers are generally comfortable with abstract thinking, pseudocode, state transition diagrams, etc. For this audience you might only use textual requirements to describe non-functional requirements that can’t be expressed visually. Just make sure that every stakeholder who will need to write, review, or read these requirements is fluent in the selected format.
Complex requirements can be more clearly expressed in other formats.
EARS easily provides enough rigor into requirement writing that is accessible to a large range of audiences. However, some requirements are simply too complicated for the EARS format.
To this point, it is more valuable to convey the meaning of the requirement than to force it into a template.
It is quite common to have some non-textual requirements within a predominantly textual requirements specification. Specifications can include graphs, diagrams, and decision tables.
There are also situations in which you would not use EARS, regardless of the audience. One such situation is where the requirement is best expressed as a mathematical formula.
More than 3 preconditions make for long and cumbersome requirements.
EARS format can and should be used for requirements with 0-3 preconditions. Based on requirement best practices and the EARS format, requirements should be a single sentence. When there are more than 3 preconditions, this can make for a very long sentence. A list, table or some other notation will make the requirement easier to understand.
Using alternative formats allows you to use the written requirements to describe and verify the system responses, while offloading the complex conditions to a form that’s easier to read and harder to misinterpret. This is helpful when the scenarios and conditions become too complicated to be expressed and understood clearly as statements only.
Example 1: A list
To ensure a multitude of preconditions are met for a specific requirement, the use of a list can be useful.
Before
Where A is True, while B is True, when C is false, when D is false, the system shall…
While this does in fact follow EARS template format from a syntax perspective. It can be difficult to follow for the audience.
After
The system shall… when the following conditions are simultaneously true:
- Where A is True
- While B is True
- When C is False
- When D is False
Example 2: Decision tables
In certain cases, preconditions can be more complex. The value of the precondition may indicate a different result/system response. It may be useful to have a decision table alongside the written requirements.
By having a decision table that covers a set of unique system responses and accounts for dozens of scenarios that would result in those system responses, you avoid writing dozens of requirements, or very complex requirements to describe these behaviors. When you introduce a decision table it becomes a reference resource that simplifies the written requirements.
The result being that you could have one simple requirement for each desired response.
Before
( A is TRUE ) AND ( B is FALSE ) AND ( (C is 5 if D is TRUE) OR ( C is 8 if D is FALSE)
After
The Decision Table in your scenario would have the columns labeled A, B, C, D, and Response.
Here’s an example of a decision table with 4 unique system responses. You would have one requirement for each of the four responses, then use the table to describe the complex interactions and scenarios that would result in that response:
While the result of Decision Table 1.1 is “Response 1”, the system shall…
While the result of Decision Table 1.1 is “Response 2”, the system shall…
While the result of Decision Table 1.1 is “Response 3”, the system shall…
While the result of Decision Table 1.1 is “Response 4”, the system shall…
Note: The decision table is not a requirement, but a resource that the requirement can reference. In this way there would be one written requirement for each system response, and the precondition would simply point to the appropriate decision table to know when that response is needed. The “precondition” for each requirement would reference a specific response number in the table, then describe what that system response included.
Conclusion: How to choose the right format for your requirement.
One great feature of the EARS method is that it is extremely versatile. The same core patterns can be used to describe a specific system response of an autonomous vehicle, the deliverables of a new IT solution, or the responsibilities of a construction subcontractor. For this reason, it’s good to use EARS as the default starting point for all of your textual requirements.
The EARS conformance check within QVscribe will let you know whether your requirement is following the EARS format, and which pattern has been employed. As you review your requirements this makes it easy to confirm that you’ve used the right template. It will also bring your attention to any requirements that are not following EARS so you can ensure these exceptions are used in the right situations.
If you realize that your requirement will have more than 3 preconditions, consider using the list format instead. If those conditions have several variables that result in complex responses, then a decision table could be the best way to manage the complexity.
Even if your requirement does not fit within the EARS format, you can still ensure they are clear, concise and unambiguous by using the QVscribe Quality Analysis. The QVscribe Quality Analysis will score your requirement whether or not it aligns with the EARS format. QVscribe is aimed to help you write clear, consistent requirements no matter the format of your requirement.
