Tag Archive for: requirements management


G2®Again Names Jama Connect® Overall Leader Requirements Management Software for Fall 2022

Thank You to Our Customers!

Jama Connect was again named far and away the overall leader in the Fall 2022 G2 Grid Report for Requirements Management Software!

In addition to the honor of being named the standout leader in requirements management software (for both Mid-Market and Enterprise), we are proud to showcase that we were awarded several additional medals for Fall 2022, including:

  • Users Love Us: For products that have collected 20 reviews with an average rating of 4.0 stars.
  • Fastest Implementation: For products that had the shortest go-live time in its category
  • Easiest Setup: The product that earned the highest Ease of Setup rating in its category
  • Easiest to Use: The product in the Usability Index earned the highest Ease of Admin rating in its category
  • Easiest Admin: For products that earn the highest Ease of Admin rating in their category.
  • Momentum Leader: Products in the Leader tier in the Momentum Grid® rank in the top 25% of their category’s products by their users.
  • Enterprise Leader: For products rated highly by G2 users and have substantial Satisfaction and Market Presence scores
Download the full report to see why customers love using Jama Connect for product, systems, and software development.

Learn More About the Fall 2022 G2 Grid for the top Requirements Management Software products HERE!

We live vicariously through the successes of our customers. The “Users Love Us” category, in particular, is a testament to our commitment to our customers.

At Jama Software®, we work hard to provide our customers with the expertise, attention, and resources needed to meet their goals, and we’re proud to be recognized in these categories and as the overall leader in requirements management software. We are so grateful to our customers who took the time to provide open and honest feedback and review their experiences using Jama Connect for requirements management.

I currently run admin on client setup. I like that our uses are finding the product easy to use and mostly intuitive from the start. After we setup rules and can now enforce them, there hasn’t been any issue or escalated queries. Client is using Jama to run their massive testing and are expanding the requirements management slowly in the mix.

-From review collected and hosted on G2.com, Project Manager, Enterprise Business

Read Jama Connect reviews on G2

We strive to provide the highest level of service possible and look forward to continuing to provide our clients with the support and expertise they need to reach and exceed their product development goals.

“Effective tool for requirements management. Easy to demonstrate compliance with processes and track requirements through approval and implementation. This gives us a single source of truth for requirements in our product workflow.”

-From review collected and hosted on G2.com, Sr. Manager, Software Engineering, Enterprise

Review Jama Connect on G2

From all of us at Jama Software to all of you, thank you!

G2 scores products and sellers based on reviews, gathered from their user community, as well as data aggregated from online sources and social networks. Together, these scores are mapped on their proprietary G2 Grid®, which can be used to compare products, streamline the buying process, and quickly identify the best products based on the experiences of your peers.

Best Practices for Change Impact Analysis

Impact analysis is a key aspect of responsible requirements management. It provides an accurate understanding of the implications of a proposed change, which helps the teams make informed business decisions about which proposals to approve.

The analysis examines the proposed change to identify components that might have to be created, modified, or discarded and to estimate the effort associated with implementing the change.

Skipping impact analysis doesn’t change the size of the task. It just turns the size into a surprise.  In product development surprises are rarely good news. Before a developer says, “Sure, no problem” in response to a change request, he or she should spend a little time on impact analysis.

RELATED: A Guide to Good Systems Engineering Best Practices: The Basics and Beyond

Impact Analysis Procedure

Impact analysis has three aspects:

  1. Understand the possible implications of making the change. Change often produces a large ripple effect. Stuffing too much functionality into a product can reduce its performance to unacceptable levels.
  2. Identify all the files, models, and documents that might have to be modified if the team incorporates the requested change.
  3. Identify the tasks required to implement the change, and estimate the effort needed to complete those tasks.

Traceability data that links the affected requirement to other downstream deliverables helps greatly with impact analysis. On complex projects with thousands of artifacts, to manually determine what and who is affected by a change is time-consuming and error-prone. Alternatively, you could adopt a product development solution like Jama Connect, which includes built-in functionality for end-to-end traceability and impact analysis, and automatically highlights the items and people that are impacted when a change occurs.

RELATED: When Evaluating Product Development Software Tools, Not All Cloud is Equal

Whichever route you take, understanding the impact enables teams to quickly and accurately respond to change requests. The team can be responsive while maintaining control over the scope and customer expectations.

Lastly, impact analysis is essential on projects where quality and safety are an issue such as in healthcare, automotive, and aerospace projects. In these situations, it’s critical to understand the specific set of requirements and features that need to be retested after a change is implemented.

Steps in a typical impact analysis process look like this:

  1. Identify the sequence in which the tasks must be performed and how they can be interleaved with currently planned tasks.
  2. Determine whether the change is on the project’s critical path. If a task on the critical path slips, the project’s completion date will slip. Every change consumes resources, but if you can plan a change to avoid affecting tasks that are currently on the critical path, the change won’t cause the entire project to slip.
  3. Estimate the impact of the proposed change on the project’s schedule and cost.
  4. Evaluate the change’s priority by estimating the relative benefit, penalty, cost, and technical risk compared to other discretionary requirements.
  5. Report the impact analysis results to all stakeholders so that they can use the information to help them decide whether to approve or reject the change request.

In most cases, this procedure shouldn’t take more than a couple of hours to complete. This may seem like a lot of time to a busy developer, but it’s a small investment in making sure the project wisely invests its limited resources. If you can adequately assess the impact of a change without such a systematic evaluation, go right ahead; just make sure you aren’t stepping into quicksand.

RELATED: A Guide to Good Systems Engineering Best Practices: The Basics and Beyond

Money Down the Drain

What can happen if you don’t take the time to perform impact analysis before diving into implementing a significant change request?

Imagine two developers on your team estimate that it will take four weeks to add an enhancement to one of your product lines. The customer approves the estimate, and the developers set to work. After two months, the enhancement is only about half done and the customer loses patience: “If I’d known how long this was really going to take and how much it was going to cost, I wouldn’t have approved it. Let’s forget the whole thing.”

In the rush to gain approval and begin implementation, the developers didn’t do enough impact analysis to develop a reliable estimate that would let the customer make an appropriate business decision. Consequently, you waste several hundred hours of work that could have been avoided by spending a few hours on an up-front impact analysis.

Learn how a requirements management solution eliminates many of the budget-draining headaches of product development in Karl Wiegers’ paper, “Getting the Most from a Requirements Management Tool.”


Customer Success Programs

In this blog, we recap the “Driving Business Outcomes with Jama Software’s Success Programs” webinar.

When you buy Jama Connect, you’re not just buying the #1 requirements management solution on the market. Our Customer Success team stands behind you, delivering the expertise, guidance, and resources you need to see a quick return on your investment and achieve your business goals.

Our adoption-oriented approach balances industry best practices with the practicalities of how you plan, build, and test your products.

In this webinar, we discuss how Jama Software has created specific diagnostic tools and customer success offerings to achieve higher value with Jama Connect. We also explore how Jama Connect can enable transformational value to positively impact your business, and how our specific customer success offerings can help your team increase traceability compliance and requirement quality.

Learn more about our new customer success programs, and how they lead to better outcomes such as:

  • Higher percentage of passing tests
  • Lower product defect rates
  • Faster time to market

Below is an abbreviated transcript and a recording of our webinar.

Driving Business Outcomes with Jama Software’s Success Programs

John D’Addario: Good morning. Good afternoon. Good evening. I’m John D’Addario, senior director of customer success here at Jama Software. I’m responsible for our global customer success team here, and we are so excited to share with you some of insights around how our new success program can help you and your company drive business outcomes with Jama Connect. I’ve asked my colleague Preston to join me today. Preston, can you give a brief introduction of yourself?

Preston Mitchell: Yeah. Thanks John. Hey everybody. It’s great to be here. As John mentioned, I’m really excited to share with you some of the things we’ve been working on here to make the success programs even better. For those of you that don’t know me, I am the director of the global solutions team. I’ve been with Jama for about 10 years. My background is kind of in requirements management. I’ve been a business analyst, I’ve been an Agile program manager. So I’m really excited about all of the best practices when it comes to system development and requirements authoring. So yeah, I’ll pass it back to John and we’ll dive in.

Related: G2 Again Names Jama Connect® the Leader in Requirements Management Software

John D’Addario: Thanks Preston. So as the number one in requirements management software, our purpose is to ensure that innovators succeed with customer success at the forefront of everything we do. Through years of industry specific experience and thousands of customer engagements, we bring the best practices to bear, to maximize the success rate of the product development process. There are six core business outcomes we focus on helping you drive with Jama Connect. They are reduced cycle time, increased process efficiency, streamline and accelerate reviews, speed time to market, gain visibility and control, ensure compliance and manage risk. We do this across our five key verticals, medical device, automotives and semiconductor, space, airborne and defense systems, software development, and industrial manufacturing.

We have a really exciting agenda for you today. We’re going to go through four topics. We’re going to give an overview of our success program. Preston’s going to go on and talk about measurements and outcomes. We’re going to do a double click on the success programs and then leave some time at the end for some Q and A. So let’s get into it. We are the experts when it comes to requirements management and traceability. We have years of experience between our customer success managers, solution consultants, and technical support engineers. Through our success program, we help our customers achieve faster time to value with Jama Connect.

Preston Mitchell: Hey John, maybe for some of the folks we could give a breakdown of the different team roles here. I’m not sure if everyone has actually interacted with their entire success team at Jama Software. So maybe we could give a background of each of the roles and what their goals are at Jama.

John D’Addario: Sure, sure. So starting with our customer success manager, really think of your customer success manager as you’re trusted advisor, focusing on understanding your business outcomes. We work together to build what we call a success plan. We use that success plan to help marshal resources across the genre enterprise. We also help you with all your commercial needs, like renewals, buying more licenses, adding a success program subscription, adding services, things like that. Our technical support engineers are there to help you with any technical questions that come up during your time with Jama Connect. They are well versed in the ins and outs of all things technical. Preston, why don’t you give a little bit more detail around the solution consultants?

Related: Jama Software® and Sparx Systems Enhance Best-of-breed Tools Integration to Strengthen Live Traceability™ Across Systems Development 

Preston Mitchell: Yeah, definitely. The solution consultants are part of my team. They really bring a lot of industry experience to bear. So a lot of them have been product managers, system engineers, quality managers in their prior roles. So they bring industry experience like requirements authoring experience, quality management, specific industry experience. Then they also of course have a lot of deep practical experience using Jama Connect the product. So they combine those to really recommend best practice uses of the tool. They very much understand the pain points and the outcomes that you all are trying to drive with your products every day. So any kind of deep product questions, or asks of how to use Jama Connect in order to achieve their goals, that’s really what their purpose is.

John D’Addario: Great. Great. When I look at this team and the resources we have here at Jama, I’m a little partial to think that, not only do we have the best team and the requirements management industry, I think we have the best team of any team that I’ve worked in over the last 10, 15 years. It’s really exciting to have this level of engagement between these three teams with this one mission of driving customer success. Let’s do a little bit of a deep dive into our success program. So through this continual engagement with your teams, we really focus on measurable improvements to your process. We do that by forming focus areas, helping you drive adoption and usage of Jama Connect, helping eliminate trace debt, and increasing your Traceability Score™, improving requirements quality score, increasing verification compliance. When you think about the success program, one of the main benefits of the success program is what we call the success catalog.

John D’Addario: This success catalog brings together four great resources for our customers to use. The first one being training resources. The second one being benchmark assessments. The third one being solution consulting. And lastly, fourth, our technical services. When you think about your journey with Jama Connect, think about it in three stages, implement, measure, and optimize. The success program is at the foundation of helping you achieve those business outcomes. We do that by mixing different services in our success catalog together, and what we call a success path. In these three examples, you can see here, we have three different success path that brings this prescriptive use of these services in the catalog to help you achieve business outcomes during the different phases of your journey with Jama Connect.

To watch the full webinar, visit: Driving Business Outcomes with Jama Software’s Success Programs


What is DOORS

What does DOORS® stand for?

DOORS is an acronym that stands for Rational Dynamic Object Oriented Requirements System.

What is DOORS?

IBM DOORS, formerly known as Telelogic DOORS, is a legacy requirements management tool originally created in 1991 and is part of the IBM Engineering Requirements Management DOORS Family.

Why was IBM ® DOORS ® originally built?

Requirements management tools started to evolve more than 30 years ago when it became clear that document-based tools such as Microsoft Office did not offer the capabilities able to manage and analyze requirements traceability.

There was initially a limited choice of requirements tools including QSS DOORS® (now IBM), Rational Requisite Pro (end of life), Borland Calibre RM (now Microfocus), as well as a few others.

Legacy requirements solutions may have been sufficient to handle managing requirements in the past but are failing to keep pace over time due to increasing engineering complexity and the need for modern software to be far easier to use.

Why did teams originally invest in IBM DOORS?

Requirements management has long been accepted by the engineering industry as an essential discipline, no matter which process is used, or which type of system is being produced. IBM DOORS was typically selected as choices were limited. Organizations originally invested in a requirements tool to establish a standard requirements management practice and process that allowed teams to align on a single source of truth for requirements.

They invested in DOORS software with the goal of:

  • Encouraging and motivating teams to follow common requirements practices. 
  • Establishing a single source of truth for requirements to ensure teams were working off the same information. 
  • Creating minimal disruption to the business with an off-the-shelf solution that allowed teams to focus on their core business. 
  • Integrating requirements into core workflows and business without impacting how people work. 
  • Tracking the life of a requirement through development, test, and release.

Related: Is There Life After DOORS®?

Why does IBM DOORS fall short for requirements management?

The past few decades have ushered in a new way of working — now teams are expected to work more efficiently and collaboratively across the organization and supply chain. Companies building highly regulated and complex products often rely on legacy tools such as IBM DOORS, yet as product development methodologies evolve, legacy requirements management tools have not kept pace.

Misalignment between what teams need vs. what legacy solutions provide can introduce increased risk in the product development process, leading to inefficiencies and lack of visibility that often result in missed deadlines, defects, compliance gaps, and rework. Companies that have migrated to a modern solution from IBM DOORS have achieved faster development times, greater efficiencies, and reduced expenses. As you plan your next move, we’ll cover everything you need to consider moving forward, including market challenges, how engineering teams are adapting, and why waiting to make a change will continue to expose you to greater unnecessary risks.

The Drawbacks of DOORS Software

You may currently be using a solution that was implemented with the intention of producing positive business outcomes. But over time, the market has changed and, as a result, your organization’s needs have changed.

If you feel like you’ve outgrown your requirements management software, you aren’t alone. Complex systems such as IBM DOORS have inherent drawbacks and have also had trouble keeping up with the innovation occurring in highly regulated industries. Continuing to use a solution that your organization has outgrown comes with a variety of challenges, including:

A cumbersome user experience. DOORS has a complex and challenging architecture and an outdated user interface. Existing users are losing the motivation to continue to use DOORS while new users are reluctant or refuse to learn. Users oftentimes refuse to use DOORS and wind up working in Word/Excel and collaboration is done in meetings and emails leaving decisions and details lost outside of DOORS.

A system lacking robust collaboration abilities and a single source of truth for requirements. With stakeholders reluctant to work within DOORS, “librarians” must enter information into the system to keep everything up to date, while the real collaboration happens outside of DOORS in emails or conversations. As a result, organizations lack the ability to perform robust reviews or examine the audit trail for requirements evolution. Additionally, teams using DOORS often must retain dedicated staff, a cost that is unnecessary in today’s competitive market where teams are being tasked with doing more with less.

Risk is introduced due to aging technologies. DOORS 9.6 is already outside of its original support window, which raises questions about how long DOORS will continue. Inevitably, IBM will at some point discontinue support for the DOORS legacy platform, and that leaves customers in a high-risk situation trying to protect their intellectual property. Additionally, a cloud option is not available, which creates challenges with remote working.

A high cost of ownership and reliance on customization. Organizations need to focus on their core business and using a bespoken RM tool interferes with that goal. Companies often struggle to achieve the benefits promised by DOORS without complex customization, and those customizations don’t transfer to IBM DOORS Next.

Stagnant infrastructure doesn’t support change. At rest, DOORS is working and has a low IT man-power cost of ownership. Changes are constantly happening and ignoring them creates additional risk. As the IT industry faces more demanding regulations, supporting the DOORS architecture is growing increasingly difficult.

Lack of vertical frameworks to support compliance. As industries establish increased regulatory and compliance rules, new and updated industry engineering frameworks have been created (e.g., DO178 A, B & C). Legacy requirements tools made early attempts at providing engineering frameworks, but these have not kept up with industry changes and are now mostly left to users to create for themselves.

Related: Migrating from IBM DOORS: Why and How Rockwell Automation Made the Switch

Risks and Costs Associated with Staying with DOORS Software

Tools that are difficult or frustrating to use — and require experts to operate — will not only slow down development but will also breed resistance and hinder adoption. As is the case with DOORS software. This creates fragmented processes that introduce unnecessary risks for organizations that must stay current with compliance regulations while developing integrated, complex products that sustain business and maintain market relevance.

The unintended consequences of a fragmented development process are critical functions such as requirements traceability, verification, validation, risk mitigation, product integration, and compliance can be fraught with information gaps, defects, delays, rework, recalls, missed requirements, and significant manual effort.

In the complex product, systems, and software delivery lifecycle, organizations can experience negative outcomes when using DOORS software, such as: 

  • Performance: Product fails to perform specified functions. 
  • Quality: Product defects are discovered by customers post-launch. 
  • Delays: Product release deadlines are missed, or costs are overrun. 
  • Fit to requirements: Product fails to meet the needs of customers. 
  • Compliance gaps: Gaps identified late and require extreme cost to rework and fix. 
  • Regulatory action: Product is not approved for launch or recalled post-launch.

Interested in making a change in your requirements management tool? There are a lot of solutions on the market, check out our requirements management buyer’s guide to cut through the clutter, Selecting the Right Requirements Management Tool 

What is DOORS

requirements management software

G2 Again Names Jama Connect® the Leader in Requirements Management Software

Thank You to Our Customers!

Jama Connect® was once again named the leader in the Summer 2022 G2 Grid® Report for Requirements Management Software!

In addition to the honor of being named the only leader in requirements management software, we are proud to showcase that we were awarded several additional medals for Summer 2022, including:

    • Easiest Admin: For products that earn the highest Ease of Admin rating in their category
    • Fastest Implementation: For products that had the shortest go-live time in their category.
    • Leader: For products that are rated highly by G2 users and have substantial satisfaction and market presence scores.
    • Users Love Us: For products that have collected 20 reviews with an average rating of 4.0 stars.
    • Momentum Leader: Based on employee growth, review growth, social growth, web growth, and year-over-year change

Learn More About the Summer 2022 G2® Grid for the top Requirements Management Software products HERE!

We live vicariously through the successes of our customers. The “Users Love Us” category, in particular, is a testament to our commitment to our customers.

At Jama Software®, we strive to provide the highest level of service possible and look forward to continuing to provide our clients with the support and expertise they need to reach and exceed their product development goals.

“Option to configure all items and opportunity to adjust it to your need. Traceability. The functionality of the review center – approval, review, and see statistics of participants.”

-From review collected and hosted on G2.com, User in Information Technology and Services, Small Business

Read Jama Connect reviews on G2

We work hard to provide our customers with the expertise, attention, and resources needed to meet their goals, and we’re proud to be recognized in these categories and as the overall leader in requirements management software. We are so grateful to our customers who took the time to provide open and honest feedback and review their experiences using Jama Connect for requirements management.

“Jama is very user-friendly and has a great support team.Requirements and Test Management and Traceability are issues that Jama can help with.”

-From review collected and hosted on G2.com, Administrator in Automotive, Mid-Market


Review Jama Connect on G2

From all of us at Jama Software to all of you, thank you!

G2 scores products and sellers based on reviews, gathered from their user community, as well as data aggregated from online sources and social networks. Together, these scores are mapped on their proprietary G2 Grid®, which can be used to compare products, streamline the buying process, and quickly identify the best products based on the experiences of your peers.

In this blog, we recap the “Managing Mission Critical Requirements in an Agile Environment” webinar.

Over the last two decades, Agile has been demonstrated to be a powerful approach to software and systems development. It has taken on a number of representations but there are features that most representations share – namely “flexibility” when dealing with requirements.

The common theme is for the user community (or the representative of the user community) to state in very broad terms what user functionality would be beneficial and then leave the details (and often the priorities) to the software “whiz”.

This is seen by many as antithetical to mission or safety-critical systems. Systems where the operational characteristics must be well understood to prevent loss of life or mission failure when the product performs differently than expected. In a similar manner, the system must be reliable since it is essential for mission success or human safety.

In this webinar, attendees will learn more about how:

  • Agile can deliver cost and schedule benefits when developing mission or safety-critical software
  • Exploiting Agile requires adapting approaches often assumed for Agile – especially when it comes to requirements management
  • When appropriately applied, Agile can give you a product that is more reliable/dependable than classical methods

Below is an abbreviated transcript and a recording of our webinar.

Managing Mission Critical Requirements in an Agile Environment

Cary Bryczek: Welcome to our virtual user group’s keynote. Today, I’m joined by Mr. Kenneth Hebert, he’s the Chief Technical Director at AFuzion, Inc. Mr. Kenneth Hebert is a 40-year veteran of safety-critical software engineering, including over 35 years as a system safety software project and process leader manager with a Ph.D., MS, BS in Computer Science, extensive experience in the safety systems and architectural design of real-time safety-critical defense and other military and private sector applications, also a registered Agile Scrum master and CMMI software process expert. He has extensive experience in systems software development methodologies ranging from Waterfall to Agile and experience with developing and deploying processes that integrate concepts embodied in DOD, NASA, ISO, AS, and FAA standards, as well as development frameworks, such as CMMI and Lean Six Sigma. He is Lean Six Sigma certified, a certified Scrum Master, and SCAMPI lead appraiser trained. I am delighted for Mr. Hebert to come and deliver our keynote. Welcome and thank you, Kenneth. Please take it away.

Related: Jama Connect® Solution for IBM® DOORS®

Kenneth Hebert: Good morning. It’s certainly a pleasure to be here. What we’re going to talk about this morning is a little bit about Agile and requirements, and hopefully, we have a few thoughts that you can take with you and use as you go forward as a part of this conference. So this is the agenda I’d like to cover. We’d like to talk a little bit about what Agile is for those of you that might not have been familiar with that term or that approach to development a little bit about whether or not it’s different and in what ways is different. And then bringing that back into the fold of requirements and requirements management and how things fit together in that realm.

So again, hopefully, these thoughts will give you a few things to chew on and you can go forward and use them as a part of this conference and everything. So in any event, what is Agile? Well, Agile means a lot of things to a lot of different people. Actually, Agile was coined back in the early 2000s. It began with something called the Agile Manifesto and basically it was a document put together by a series of thought leaders in the software community. And at a time when, if you think about what was going on in the early 2000, and late ’90s, we had a number of standards coming out that were driving to what they perceived to be a heavyweight process.

Related: Better Product Development: Five Tips to Achieve Live Traceability™ 

Kenneth Hebert: Standards that called for delineation of what had to be done, exactly how it was going to be done. The CMMI was being introduced. Mill standard 498 had been installed and was being used 12207 was being worked on. NASA was putting together its standards for how it expected software to be done in development with respect to space systems. So all of them had seen several common themes, and those were those involved in essentially heavily evaluating and systematically approaching the software development process and as a part of that requirement, requirements management.

So this was in some ways a revolt or at least looking at where the pendulum was, and a claim by these leaders that let’s not lose sight of what we’re doing. Let’s realize that our objective here is to solve a problem and let’s get back to what’s really important. So what you’ve seen over the last two decades, is that Agile has become a significant influence in the development community, the software, and systems development communities. What you’ve seen is it’s been applied in a number of different contexts. It actually can be, because it really isn’t a development methodology as much as it is a set of guiding principles. And so we want to talk a little bit about what those were so that we can kind of have a common discussion as we look at what those areas, those principles, what you’ll see are some common themes in all these areas.

And that is it’s built around the notion that you have that a team is used to build a product. That team has a shared purpose. It’s typically a multidisciplinary team. It has all the skills and knowledge needed to get the job done successfully. It’s a cooperating group. They work together in order to achieve the objective and they blend their skills. They don’t operate as a group of individuals. They operate as a team. Much like if you think of a football team where everyone is operating together in order to achieve a touchdown and to advance the ball down the field. No individual may be the perfect running back or the perfect lineman or the perfect quarterback, but as a group, they overcome each other’s deficiencies in order to achieve a common goal. And that’s really what you want to see in an Agile environment.

To watch the full webinar, visit: Managing Mission Critical Requirements in an Agile Environment


EARS Notation

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.

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

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.

Learn more about EARS

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.

Learn more about these patterns

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
  • Complex
  • Option feature requirements
  • Unwanted behavior requirements

Learn more about these patterns


Requirements Management and Traceability

This is a recap of our press release announcing The Essential Guide to Requirements Management and Traceability.

Jama Software®, the leading requirements management and requirements traceability solution provider has released The Essential Guide to Requirements Management and Traceability – a comprehensive microsite that helps engineers gain access to information on best practices related to requirements management and requirements traceability.

Requirements management is the process of gathering, analyzing, verifying, and validating the needs and requirements for the given product or system being developed. Successful requirements management ensures that completed deliverables meet the expectations of the stakeholders. Requirements can be managed using documents, however, complex systems or products in highly regulated industries mitigate risk by using trusted requirements management tools.

“Jama Software is committed to enabling system engineering excellence,” said Tom Tseki, Jama Software’s Chief Revenue Officer. “Practitioners can use this comprehensive nine-chapter guide to learn and follow best practices across all aspects of the systems development process.”

Visit The Essential Guide to Requirements Management and Traceability to take a deep dive into the following topics and more:

  • Best practices for writing requirements
  • Requirements traceability – and why it matters
  • Requirements gathering and management processes
  • Evaluating requirements management tools and software
  • The requirements validation and verification process
  • Meeting regulatory compliance and industry standards
  • Key product development terms and definitions

The Essential Guide to Requirements Management and Traceability is live and can be found HERE

Read the entire press release here

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



axendia report medical device development

In this blog, we present a research report conducted by Axendia, a leading Life-Sciences Analyst firm, and presented by Jama Software, we walk through groundbreaking new research about the costly impact of ineffective requirements management in the medical device industry.

Axendia Report: The Costly Impact of Ineffective Requirements Management

Medical device organizations are continuing to sharpen their focus on developing high-quality medical devices aimed at improving patient outcomes. However, many struggle with effectively managing requirements and traceability across the product development lifecycle. This can be costly, risky, and lead to delays in new product introductions when considering the increased complexity in medical products, competition, and the regulatory landscape.

In this research report conducted by Axendia, a leading Life-Sciences Analyst firm, and presented by Jama Software, we walk through groundbreaking new research about the costly impact of ineffective requirements management in the medical device industry, including:

  • The impact of having an ineffective closed-loop requirements management process.
  • The critical importance of requirements management to achieve improved patient outcomes, product quality, and time to market.
  • The negative impact on budgets, traceability, verification, and validation activities when relying on manual processes

Download Axendia’s full research report: HERE

Axendia is a leading analyst and strategic advisory firm focused exclusively on the Life-Sciences markets. They provide strategic advice Business, Regulatory and Technology issues and trends enabling our clients to prepare for, adapt to, and overcome disruption.
To learn more visit, Axendia Provides Strategic Advice for the Life-Sciences Markets