The Essential Guide to Requirements Management and Traceability
Adopting the EARS Notation to Improve Requirements Engineering
Editor’s Note: This chapter was authored by Allistair Maven (Mav), an independent requirements specialist based in the UK. He is known internationally for his requirements training, coaching, and consulting.
Requirements Engineering Foundations and Inherent Challenges
Requirements engineering (RE) is a human-centered activity and is fundamentally about communication. In some ways RE is straightforward: you need to work out who will be affected by a product, system or service, find out what they want it to do and document it. You will need to manage their expectations about what can be achieved. Once the solution is built, you need to check that it does what the people asked for. This sounds simple but is not necessarily easy.
RE is a cross-discipline activity and includes both soft skills and technical aspects. No two developments are the same; the scale, complexity, risk, novelty, and the composition of the project team all vary between projects. When developing new products, systems or services, there is much that is unknown and must be discovered. Because of these and many other factors, RE is not an exact science; it is not a completely systematic and repeatable “engineering process.” Successful RE follows a reusable approach for efficiency but is not a copy-exact process. RE processes must be adapted or customized for the nuance of each individual development program.
Inherent Challenges
There are many challenges in collecting a set of requirements for a new product, system or service. People do not always know what they want, so the requirements may not be readily available; they may have to be discovered. Even if they know what they want, people may find it difficult to express the requirements clearly. Individuals all have different experiences and make assumptions based on what they already know. Consequently, people typically do not state things that seem obvious to them. Additionally, people do not always know what is possible, so they would not think to ask it.
For any new development project, there are almost always more stakeholders than is first obvious. Requirements come from a wide range of stakeholders who will be affected in some way by the proposed new product, system or service. Even “users” are not a homogeneous group; they will have differing levels of knowledge and experience and will want to use the new system to achieve many objectives. A development team will typically include software, hardware, safety, verification, maintenance and support engineers, project managers and administrative staff. The wider project will involve a project sponsor, product managers, consultants, customers, suppliers, regulators and the public. All these diverse roles may have requirements on the product, system or service. Even the roles included here do not constitute an exhaustive list of stakeholders.
Stakeholders may have high-level aspirations, wishes, wants and needs that they hope a future system or product can address. However, these goals should not be captured as “requirements” because they are typically not things that a system can deliver. It is wise to capture and document stakeholder goals, but it is important also to manage stakeholder expectations about what the proposed system can actually achieve. Stakeholder goals will always include conflicts, so goals cannot ever be completely satisfied. The set of system requirements, however, must be complete, consistent and free of conflict; it must be possible to build a system that satisfies all the system requirements.
To undertake requirements engineering (RE) activities effectively and reduce project risk, you need people, processes, and technology to work together to capture the requirements and communicate clearly to all relevant stakeholders throughout the entire system development process.
This chapter will discuss some of the issues that arise during RE and describe how the Easy Approach to Requirements Syntax (EARS) Syntax notation helps achieve desired outcomes and overcome many common development challenges by enabling you to improve your requirements engineering practices.
Easy Approach to Requirements Syntax
The Easy Approach to Requirements Syntax (EARS) uses a few keywords and a simple underlying ruleset to gently constrain natural language (NL) requirements. EARS requirements have a few clauses that are always in the same order, following temporal logic. This means that the requirements mirror common usage of English whilst optimizing clarity and precision. EARS requirements are therefore intuitively simple to understand.
The EARS Origins
EARS was first developed in 2009 at Rolls-Royce Aero Engines. A group of cross-discipline engineers analyzed an airworthiness regulation to determine the requirements for an aero engine control system. The team looked at each clause of the regulatory document and decided whether it explicitly or implicitly inferred a requirement on the engine control system. For each clause that included a requirement, an initial set of “rules” was used to clarify and simplify the requirement. The rules were refined iteratively during the analysis. During this analysis, it became clear that the resultant requirements were all syntactically similar and followed one of a small number of patterns. This work led to the publication of the Easy Approach to Requirements Syntax paper at the IEEE “RE09” International Requirements Engineering conference.
EARS recognizes the fact that most requirements are written in natural language (NL) and that many requirement authors are not formally trained in writing system requirements. However, problems in system requirements tend to propagate through system development. This can lead to problems such as increased volatility and risk, which can impact quality, program schedule and cost. EARS has been shown to reduce or even eliminate many of the common problems in NL requirements. EARS is lightweight and requires little training overhead. EARS is therefore easy to adopt, which makes it popular with practitioners. EARS is widely used by organizations including Bosch, Daimler, Dyson, Honeywell, Intel, NASA, Rolls-Royce and Siemens and is also taught at numerous universities worldwide.
The EARS Pattern
The clauses of an EARS requirement always appear in the same order. The basic structure of an EARS requirement is: While, when, the shall
The EARS ruleset states that a requirement must have: Zero or many preconditions; Zero or one trigger; One system name; One or many system responses. Applying the EARS notation produces requirements in a small number of patterns, depending on the clauses that are used. Each of the EARS patterns are explained below.
- Ubiquitous requirements are always active and have the following structure: The shall for example The mobile phone shall have a mass of less than XX grams.
- State driven requirements are active as long as the specified state remains true, are denoted by the keyword While and have the following syntax While
- Event driven requirements specify how a system must respond when a triggering event occurs, are denoted by the keyword When and have the following syntax When , the shall for example: When “mute” is selected, the laptop shall suppress all audio output.
- Optional feature requirements apply in products or systems that include the specified feature, are denoted by the keyword Where and have the following syntax Where , the shall for example: Where the car has a sunroof, the car shall have a sunroof control panel on the driver door.
- Unwanted behavior requirements are used to specify the required system response to undesired situations, are denoted by the keywords If and Then and have the following syntax If , then the shall for example: If an invalid credit card number is entered, then the website shall display “please re-enter credit card details”.
- The simple building blocks of the EARS patterns can be combined to specify requirements for richer system behaviour. Requirements that include more than one EARS keyword are called Complex requirements and have the following syntax While
Ten Key Benefits of using EARS
Using EARS helps align people, process and technology very early in the system development process, even before you have fully defined your processes or selected tools, but applying EARS has numerous additional benefits.
- EARS reduces or even eliminates common errors typically found in textual NL requirements.
- EARS requirements are simpler and more consistent, even if written by different authors. The simplicity means that EARS requirements are universally understandable, even to those who may not have been trained in the EARS notation. This consistency also ensures each requirement is judged equally, free of any style or presentation bias. EARS has been shown to be especially effective for those whose first language is not English, but who must write in English.
- Little training is needed; many organizations train EARS in half a day or even less and see an immediate improvement is the standard of written requirements. Since EARS is close to natural language, there is no new notation to learn. EARS requirements are easier to review than those written in a more specialist notation. EARS requirements are similar in style to test cases, which in turn means that systems are easier to verify against EARS requirements.
- EARS helps both novice and experienced requirement authors, since both groups tend to write better requirements more quickly. Most requirements are written iteratively; draft requirements are elaborated and improved over several iterations. When using EARS, first draft requirements tend to be much closer to the finished requirement.
- EARS works well alongside a range of models including activity diagrams and state charts, since the elements of an EARS requirement are also found in such models. EARS is an effective means to gently introduce rigor into requirements and systems engineering processes; this has been called “stealth rigor.”
- Many of the benefits of EARS work at both individual and team level. Individuals write better requirements, but the consistency of EARS requirements has wider benefits across a project team, throughout an organization and even into the supply chain. Requirements are more widely and more easily understood. Intra-team communication is improved, and team members are more portable across projects. EARS helps to build teams, generates a shared understanding and therefore reduces silo mentality. This reduces project risk because missing information is identified earlier, and requirements are written more precisely.
- When a project team starts using EARS, something magical can happen. Since the use of EARS clarifies and simplifies the syntax of requirements, it frees up cognitive capacity to consider the semantics of a requirement. In layman’s terms, this means that people no longer need to think about structure, but instead they concentrate on meaning. Because certain elements are necessary to write an EARS requirement, it is obvious to authors when this information is missing. For example, a requirement author may know that a system must exhibit certain behavior, but they do not (yet) know how this behavior will be initiated. This will prompt the author to investigate the circumstances that should cause the system response; this could be a triggering event or a precondition.
- The characteristics of EARS mean that development teams more quickly identify what is not yet known, but that must be identified to complete the requirements. Where other notations may hide missing or incomplete information in ambiguous requirements statements, EARS exposes what must be discovered. EARS therefore empowers teams to “start before the beginning.”
- Even before you have fully defined your processes or selected tools, as mentioned, EARS helps align people, process and technology very early in the system development process, even before you have fully defined your development processes or selected tools. Once your team knows EARS, they know the elements needed to generate requirements. So even in the earliest stages of a project, they will be gathering the essential elements needed to write good requirements. If something is not known that is needed for an EARS requirement, it is obvious that something is missing and that this element needs to be discovered. EARS therefore aids the whole scope of system engineering.
- EARS can be used effectively without any tool support since the requirements are essentially in (gently constrained) natural language. However, for more complex projects, particularly with large or distributed project teams, it can be advantageous to have some tool support. One such tool, Jama Connect® for Requirements, Risk, and Test Management, can be used effectively to help establish and extend your team’s use of the EARS notation. In addition, Jama Software Requirements Advisor can optimize your usage of the EARS notation with suggested advice on EARS usage.
A senior engineer at a major engineering company once said: “If you can’t write it in EARS, then you don’t understand it.” This emphasizes a hidden strength of EARS; it prevents authors from writing incomplete requirements.
Conclusion
“In theory there is no difference between theory and practice, but in practice there is” (Yogi Berra)
In theory, Requirements Engineering is quite easy, but in practice it is quite difficult. One way to make it easier for yourself is to use EARS.
EARS is a lightweight approach that is easy to learn, provides a quick return on investment, and is popular with users because it is intuitive and mirrors normal use of English. For distributed teams, bigger teams, and more complex projects, it can be advantageous to have some sort of tool support such as Jama Connect® and Jama Software Requirements Advisor which provides assessments on the use of EARS.
EARS notation is simple and effective, with known elements needed to complete a finished requirement. The team therefore wastes no time on deciding how to write and instead, is able to use all their energy and cognitive effort on what to write. The emphasis shifts to the semantics (meaning) of the requirement – what do we want the system/product to actually do.
Coupled with a requirements management platform like Jama Connect, the EARS approach can improve product requirements and align teams, processes, and technology by enabling more effective and efficient communication within and across teams. This alignment creates better synergy allowing teams to focus on the quality of output, thereby reducing overall project risk.
In This Webinar, We Discuss Lessons for Reducing Risk in Product Development.
Ready to Find Out More?
Our team of experts is here to answer any questions and learn how we can help enable your continued success. Get started by filling out this form so we can connect!