FAQ: EARS Notation and Jama Connect™ Requirements Advisor
In our recent webinar, Adopting EARS Notation to Improve Requirements Engineering, attendees learned more about adopting EARS (Easy Approach to Requirements Syntax) to improve requirements engineering and got an exclusive look at the upcoming 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.
That webinar included an extensive question and answer session from attendees. In this blog, we’ll present an extended list of frequently asked questions about EARS and Jama Connect® Requirements Advisor
Frequently Asked Questions
1: Why is it important to write good requirements?
Well-written requirements are critical for the development of any successful system. Requirements drive the design, development, and user experience of the system. Well-written requirements can improve productivity and quality. A good requirement states something that is necessary, verifiable, and attainable.
2: Is my requirement data secure?
Yes. Requirements Advisor Beta uses the same portfolio of security solutions as the production release of Jama Connect.
- Your requirements statements stay within the Jama Connect Cloud with the same proven protection of Jama Connect.
3: What are the benefits of Requirements Advisor Beta for Jama Connect?
- Improve the quality of your requirements statements quickly and efficiently using natural language processing.
- Reduce the risk of late-stage errors.
- Assists development teams in standardizing your process for requirement authoring, saving time, and enhancing accuracy.
4: When will Requirements Advisor be available in Jama Connect?
- Beta: A limited customer beta is planned to begin calendar Q2 2022
- Release: Initial product release is planned for H2 2022
Jama Software® reserves the right to continue development and consider potential, future Jama Connect integration options. Users can contribute to future capabilities by using the beta and providing feedback to Jama Software. Jama Software retains the rights to Jama Software Requirements Advisor and all derivative works.
5: How are requirements statements evaluated?
Advisor applies industry best-known methods from both INCOSE* and EARS*. Please review the details that follow on both below.
6: What is INCOSE?
International Council for Systems Engineering (INCOSE) is a not-for-profit membership organization founded in 1990 with the following goals:
- Develop and disseminate the interdisciplinary principles and practices that enable the realization of successful systems.
- Promote international collaboration in systems engineering practice, education, and research.
- Assure the establishment of competitive, scale-able professional standards in the practice of systems engineering.
- Encourage governmental and industrial support for research and educational programs that will improve the systems engineering process and its practice.
- Learn more about INCOSE
7: Why use INCOSE rules?
INCOSE reflects the principles and processes of system engineering. The INCOSE Guide for Writing Requirements focuses on writing requirements in the context of systems engineering. It emphasizes the need to consider the context of the system of interest when writing requirements. Considering the environment in which the developed system is located is an integral part of the system approach.
8: What is the INCOSE Guide for Writing Requirements?
INCOSE created and published the first Guide for Writing Requirements in July 2009. Since then, the document has undergone several reprints, which incorporated the suggestions and comments of various practitioners. The latest version of the guide, (V3) at the time of this writing, was published in June 2019.
Related: All Systems Go: INCOSE Principals
9: What is EARS?
Alistair Mavin, “Mav,” the originator of the Easy Approach to Requirements Syntax (EARS) describes it as follows:
EARS is a mechanism to gently constrain written requirements. The EARS patterns provide structured guidance that enables authors to write high-quality requirements.
Mav and his colleagues at Rolls-Royce PLC developed EARS while analyzing the airworthiness regulations for a jet engine’s control system. The regulations contained high-level objectives, a mixture of implicit and explicit requirements at different levels, lists, guidelines, and supporting information.
In the process of extracting and simplifying the requirements, Mav noticed that the requirements all followed a similar structure. He found that requirements were easiest to read when the clauses always appeared in the same order. These patterns were refined and evolved to create EARS.
There is a set syntax (structure), with an underlying ruleset. A small number of keywords are used to denote the different clauses of an EARS requirement. The clauses are always in the same order, following chronological logic. The syntax and the keywords closely match common usage of English and are therefore intuitive.
The notation was first published in 2009 and has been adopted by many organizations across the world.
10: Why use EARS?
System requirements are usually written in unconstrained natural language (NL), which is inherently imprecise. Often, requirements authors are not trained in how to write requirements. During system development, requirements problems spread to lower levels. This creates unnecessary volatility and risk, impacting program schedule and cost.
EARS reduces or even eliminates common problems found in natural language requirements. It is especially effective for requirements authors who must write requirements in English, but whose first language is not English. EARS has proven popular with practitioners because it is lightweight, there is little training overhead, no specialist tool is necessary, and the resulting requirements are easy to read.
11: Who is using EARS?
EARS is used worldwide by large and small organizations in different domains. These include blue-chip companies such as Airbus, Bosch, Dyson, Honeywell, Intel, NASA, Rolls-Royce, and Siemens.
The notation is taught at universities around the world including in France, Sweden, UK, and USA.
12: What are EARS patterns?
Following are six fundamental EARS patterns:
- Ubiquitous requirements
- State-driven requirements
- Event-driven requirements
- Option feature requirements
- Unwanted behavior requirements
- [Webinar Recap] Moving from Modules to Models – Is it finally time to leave IBM® DOORS® behind? - May 24, 2022
- IEC 61508 Overview: The Complete Guide for Functional Safety in Industrial Manufacturing - May 19, 2022
- Property & Casualty Insurance Industry Future Hinges On People & Technology - May 17, 2022