Jama Software® Requirements Advisor Beta
Check the quality and accuracy of your requirements by leveraging the power of natural language processing.
Frequently Asked Questions
Why is it important to write good requirements?
Well-written requirements are critical the for 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.
Is my requirement data secure?
Yes. Advisor uses the same security solutions as the production releases of Jama Connect.
- All user traffic to Advisor including file uploads is encrypted using SSL/HTTPS.
- Once uploaded, Jama's Virtual Private Cloud (VPC) secures all internal services and infrastructure from outside access. This keeps all user data secure and confidential between Jama Software and the User in the same manner as production releases of Jama Connect.
What are the benefits of Jama Labs Requirements Advisor Technology Beta?
- Improve the quality of your requirements statements quickly and efficiently using NLP.
- Reduce risk of late-stage errors.
- Assists development teams in standardizing requirement authoring, saving time and enhancing accuracy.
When will Requirements Advisor be Available as a Jama Software product solution?
At this time, Jama Software Labs Requirements Advisor Technology Beta is only available as a beta technology. Jama Software reserves the right to continue development and consider potential, future Jama Connect integration options. Users have the opportunity to contribute to future capabilities by using the beta and providing feedback to Jama Software. Jama Software retains the rights to Jama Software Labs Requirements Advisor Technology Beta and all derivative works.
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.
**Note that you can choose whether to evaluate individual Requirement Statements or upload a spreadsheet for multiple Requirement Statement evaluation. Detailed instructions are on the web app landing page.
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.
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.
What is INCOSE Guide?
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. The latest version of the guide, (V3) at the time of this writing, was published in June 2019.
What is EARS?
Alistair Mavin, "Mav", the originator of 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 colleagues at Rolls-Royce PLC developed EARS whilst 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.
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.
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 China, France, Sweden, UK and USA.
What are EARS patterns?
Following are five fundamental EARS patterns:
- Ubiquitous requirements
- State-driven requirements
- Event-driven requirements
- Optional feature requirements
- Unwanted behavior requirements
What INCOSE rules are being utilized?
At present Requirements Advisor Beta uses the following INCOSE rules:
- Use Active Voice
- Use Definite Articles
- Avoid Vague Terms
- Correct Grammar
- Correct Spelling
- Avoid Not
- Avoid Pronouns
- Temporal Indefinite