Requirements & Requirements Management

[Webinar Recap] Adopting EARS Notation to Improve Requirements Engineering

By |

In this blog, we recap a webinar discussing Adopting EARS (Easy Approach to Requirements Syntax) to Improve Requirements Engineering.

Requirements are the foundation of a smooth-running process and are the essential inputs to your mission-critical projects. Yet writing requirements is also a practice that many underestimate and fumble.

The Easy Approach to Requirements Syntax (EARS) is a notation that “gently constrains” natural language requirements to help teams to easily achieve desired outcomes. Not only does adopting the EARS notation improve the quality of requirements, but it also enables cross team collaboration and synergy, improves product requirements, and reduces project risk. This webinar will introduce the EARS notation and walk through the benefits for both individuals and teams.

In our recent webinar, attendees got an exclusive look at the coming Jama Connect Requirements Advisor, a tool in development that allows you to check the quality and accuracy of your requirements by leveraging the power of natural language processing.

Watch this webinar recording to learn more about:

  • How to write better requirements with EARS, and the benefits for both teams and individuals
  • How EARS works alongside models and can help uncover what is not yet know
  • How Jama Connect Requirements Advisor will facilitate embedding EARS notation in your requirements engineering work.

Below is an abbreviated transcript, including a portion of the Q&A session at the end of the event, and a recording of our webinar.

Adopting EARS Notation to Improve Requirements Engineering

Alistair Mavin: What is this requirements engineering thing all about anyway? Well, in theory, you could say that requirements engineering is quite easy. What is requirements engineering? Well, you ask people what they want, you write it down, you build it and then you check that it does what they ask for. Like a lot of things, if you put it to a high level, it’s perhaps quite simple, but there’s obviously a lot more to requirements than that and they are in themselves quite slippery and difficult things.

But relevant to EARS, I think is the notion that asking people what they want and then writing them down, how you choose to write it down can guide what you ask them to tell you and can help them to tell you the useful things that you can then write down more effectively. The inherent nature of EARS, which I’ll explain in a little more detail helps a lot with elicitation because it identifies the things you need to know in order to write down a well-formed EARS-compliant requirement. There are certain things you need to know to be able to populate an EARS requirement effectively. That means you interrogate people, you ask people the right questions to be able to write a good question. From very early in your requirements elicitation, you are seeking the right information to get clearer requirements.

Related: Innovation Insights Podcast Episode 1: Introduction to Requirements Advisor

Alistair Mavin: I’ve said that in theory, requirements engineering is very easy. In practice, it’s not so easy. First of all, people don’t necessarily know what they want. If they don’t know what they want, they can’t tell you or maybe they do know what they want, but they don’t know quite how to express it, or if they’re an expert in something and after all many requirements are elicited from subject matter experts in various fields, it’s a well-known characteristic of experts that they don’t actually consciously know some of what their knowledge is. It’s so obvious to them and implicit. It’s tacit. They actually would struggle to articulate it because it’s so obvious to them, they don’t think of even mentioning it. That makes it quite a tricky discipline.

People want different things. If you’ve got a whole load of stakeholders, they’re going to want different things. They may be intention or in direct conflict. Who do you even ask anyway? Who are all the stakeholders? Almost always more than you first realize. Some of those stakeholders may not be available. You may literally not be able to get hold of them because they’re too busy or contractually or geographically or in time zones or for whatever reason, it might be hard to actually speak to those people. And of course, requirements also come from other places and people from documents and so on.

Below is an excerpt from the Questions and Answers portion of the webinar:

Question: “EARS notification seems beneficial for system requirements equals higher level requirements, but what about other low level requirements? What can you recommend using EARS for which level of requirements and for which requirement levels not using it?

Alistair Mavin: Good question. The first EARS paper, all we claimed was we’ve run it past some high level system requirements for a jet engine control system and it appears to work. That’s all we claimed. Subsequently, it was used by the team I was with within Rolls Royce and other people within Rolls Royce, and then once the paper was published, other people in other organizations for different sets of data in different domains and for systems at different levels. The short answer is it can be used pretty much at any level.

I mean, if you think about a system of… The thing about requirements engineering for me is you define your system to be built and you consider that as a block box. What are the inputs to it? What are things that it can detect that it’s going to react to? And what outputs does it produce in response to receiving those inputs? A system is a transfer function of inputs into outputs. Your system is whatever you define as a system. In that sense, you can do it pretty much at any level. The simple answer is it works at any level.

Interestingly, since we’ve talked about lower levels, one of the other questions, well, it’s not a question, but it’s a point put in the Q and A, Frederick Wolf, if I pronounce the correctly. Renault Software Factory is using EARS. There you go. Software people use EARS.

Question: “EARS notification seems to me to only be applicable to capture functional requirements. What about nonfunctional requirements, namely quality requirements and constraints?”

Alistair Mavin: Short answer, yes. EARS can handle nonfunctionals of all types. The way I recommend treating nonfunctionals within EARS is… It’s difficult to answer. This is a very short answer in the time we’ve got, but there are three distinct ways that you can handle nonfunctionals. Constraints can be handled with any EARS pattern. The system shall have a certain weight, maximum weight, shall comply with a standard, shall interface with some other system. Those sort of things can be specified just using any EARS pattern.

If you have a nonfunctional aspect that applies the one function, the system shall display a message within one second, that within one second is a quality of service. It’s called an EARS, is a little suffix you put on the end of an EARS requirement, which somehow gives a quality measure to how quickly, how accurately type of thing on the end of a functional requirement. Then the quality and performance requirements, which in a way are the purely nonfunctional requirements, if you like, quality and performance requirements, I recommend having three measures. A must, a plan, and a stretch, which is rather like Gilb’s Planguage, which handily, question four…

Question: “How does EARS compare to Gilb’s Planguage?”

Alistair Mavin: Well, in terms of how it handles nonfunctionals, it basically follows Gilb’s suggested notation for how to follow nonfunctionals. You would write a required following the general principles to make an EARS compliant requirement, but you would explicitly and specifically put in an imprecise word such as quickly, which in a normal requirement, you would not want a word like quickly. I would recommend tagging them as this is a QPR, this is a quality and performance requirement, so you know it has knowingly got an imprecise word such as quickly, and then you’d have metadata. Another attribute that says must, what’s the worst quickly will be? Within three seconds. The plan is within two seconds and the stretch is within one second. That maps exactly to Gilb’s Planguage… is taken from Gilb’s Planguage.

Related: How to Write an Effective Product Requirements Document

Question: “Is Jama Software the only provider of an EARS tool?”

Joseph Pitarresi: No, there are other suppliers in the market. Our approach, however, is to really provide this tool as a benefit to all Jama Connect users, many of the other solutions, and there are excellent solutions in the marketplace and we have partners that offer solutions as well, are created from a custom development process to where there’s either a special development tool and hands-on consulting required to develop a detailed approach to artificial intelligence. Again, we’re trying to provide the 80%, 90% of the value at a very high level across the INCOSE and the EARS patterns.

And so, we think that’s a huge value opportunity that we’re addressing, but we highly are happy to refer you to our partners who can build custom solutions for EARS analysis if you want to go into that kind of depth and you can contact me and I’m happy to refer you to our partners who want to go even deeper more than the Advisor, but just to be clear, Advisor will be integrated in our Connect platform. You’ll round trip your requirement statements that are in Jama Connect to the Advisor and back once you’ve decided if you want to make some changes. And so, it’ll be very quick and efficient right within our tool. You don’t have to be popping in and out of different tools.

Watch the full webinar to learn more about Adopting the EARS Notation to Improve Requirements Engineering

 

RELATED


Jama Software
Latest posts by Jama Software (see all)