Skip to main content

Jama Connect User Guide

Coming soon — Jama Software® Requirements Advisor (Beta)

FAQ

For Jama Connect Cloud customers, you can use the Requirements Advisor Beta to check the quality and accuracy of your requirements, leveraging the power of natural language processing.

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. Each requirement states something that is necessary, verifiable, and attainable.

Is my requirements 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 protections of Jama Connect.

What are the benefits of Requirements Advisor Beta for Jama Connect?

  • Improve the quality of your requirements statements quickly and efficiently using systems engineering optimized natural language processing.

  • Reduce risk of late-stage errors.

  • Assist development teams in standardizing your process and language used for requirements authoring to save time and enhance accuracy.

When will Requirements Advisor be available in Jama Connect?

  • Beta: 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.

How are requirements statements evaluated?

Requirements Advisor applies industry best-known methods from both INCOSE and EARS.

What is INCOSE?

The 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

  • Encourage governmental and industrial support for research and educational programs that will improve the systems engineering process and its practice.

Learn more about INCOSE

Why use INCOSE Rules?

INCOSE reflects the principles and processes of system engineering. The INCOSE Guide for Writing Requirements focuses on authoring 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 systems approach.

What is the INCOSE Guide for Writing Requirements?

International Council for Systems Engineering (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. At the time of this publication, the latest version of the guide is (V3), published in June 2019.

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 enable 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.

Learn more about EARS

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.

Learn more about these patterns

Who is using EARS?

EARS is used worldwide by large and small organizations in different domains. These include blue chip companies such as Bosch, Honeywell, Intel, Rolls-Royce, and Siemens.

The notation is taught at universities around the world including in France, Sweden, United Kingdom, and the United States.

What are EARS patterns?

Following are the six fundamental EARS patterns:

  • Ubiquitous requirements

  • State-driven requirements

  • Event-driven requirements

  • Complex requirements

  • Option feature requirements

  • Unwanted behavior requirements

Learn more about these patterns