Tag Archive for: requirements management

Tag Archive for: requirements management

[Webinar Recap] Best Practices for Leveraging Systems Thinking in MBSE

This blog recaps a section of our recent webinar, to watch the entire presentation, visit Best Practices for Leveraging Systems Thinking in MBSE

Best Practices to Simplify MBSE: Unlock the Power of Systems Thinking

Model-Based Systems Engineering (MBSE) is transforming how organizations manage complexity in modern engineering projects. Yet, successful integration with existing tools and workflows can be challenging. By applying systems thinking, you can gain a holistic understanding of interconnected systems and adopt proven strategies to streamline your engineering processes.

Join a 1-hour webinar featuring INCOSE expert David Long, Director of Strategic Integration at INCOSE, and Aimi Langberg, Senior Solutions Consultant at Jama Software. They will share expert insights and actionable techniques to help you adopt MBSE with confidence.

In just one hour, you’ll learn:

  • How systems thinking enhances decision-making and problem-solving in engineering
  • Practical steps to transition from document-based processes to a unified model
  • Proven strategies for aligning MBSE with industry best practices
  • The role of AI in advancing systems engineering and MBSE adoption
  • Expert tips for integrating these approaches into your workflows

The Video Below is a Preview of This Webinar.
To Watch The Entire Presentation, Visit Best Practices to Simplify MBSE: Unlock the Power of Systems Thinking

TRANSCRIPT PREVIEW

Aimi Langberg: My name is Aimi Langberg, and I’m a Solutions Consultant for Jama Software. To start off today, I have a very special guest to chat with me about systems thinking. David Long is an internationally recognized leader in systems engineering, with over 30 years of experience advancing and advocating for best practices across government and commercial organizations. Founder of Vitech and now president of Blue Holon, he has developed industry-leading MBSE methods and tools to help teams navigate digital transformation. As an INCOSE fellow and past president, David will be able to provide the framework for us to reference as we talk about concepts and application today. I’ll be back to continue our presentation after the interview. Hi David. Thanks for taking the time to talk with me. I’m excited for this opportunity.

David Long: Pleasure, Aimi. So am I.

Langberg: Great. You’ve been advocating and teaching about these concepts for a long time. And as organizations move from traditional document-based methods, I have found it really does require a mindset, like a total shift in mindset, to be successful. So, how do you define systems thinking, and what core principles are the most essential for effective engineering?

Long: I appreciate you starting it that way, Aimi, because systems thinking is the thought process that underlies systems engineering. So if you don’t go back to the core, you’re not going to get the model based right. So for me, systems thinking is all about focusing on the whole, the big picture, whereas we’ve been taught analytical thinking, which focuses on the parts in deep detail. So when you’re doing systems thinking, you’re looking at the whole, at the interactions, at the interrelationships between ideas and concepts, and you’re thinking dynamically across time because things aren’t static. In terms of core principles that you’ve got to apply when you’re looking at the system’s thinking, it’s the wholism, it’s the big picture. As Stanley McChrystal once wrote, you can’t understand a part without at least a rudimentary understanding of the whole. You can only make good decisions about the part if you have the context of the whole. Then you’ve got the interconnectedness, which is ever-increasing because of today’s technologies. The electronics and software that empower today’s products mean that really every piece is interconnected with every other piece.

I mentioned that, thinking dynamically across time, there are feedback loops. How are things changing? Go back to thinking that we did in school with predator-prey relationships. As prey populations rise, predator populations rise. As predator populations rise, prey populations fall. What are those feedback loops that are going on in our systems? And then the positive idea of emergence and the negative idea of unintended consequence. If you disassemble an airplane, it won’t fly. It’s only the engines working with the wing to provide lift, working with the fuselage to provide structure, and with the controls that will allow you to fly. But then that’s the positive emergence. What’s the negative emergence, the unintended consequences that we haven’t thought of? So those are the core principles that I think of when I start talking about systems thinking.

Langberg: That’s really helpful. And I like these unintended consequences. The idea of mentioning that, because we always talk in engineering about the unknown unknowns, and that’s kind of what this goes back to. What are some common misconceptions you encounter about MBSE or the systems thinking approach?

RELATED: What is MBSE? Model-Based Systems Engineering Explained

Long: So at the systems thinking level, the first thing that I’ll say, and it’s not a misconception, but we can fall into the trap, it’s the idea that systems thinking is more important than analytical thinking. The reality is that we need both. We need the big picture thinking that looks at the interactions, but also we need to do really good deep analytical thinking. And the other idea at systems thinking level is that somehow systems thinking is a skill that’s limited to the few. I’m a big believer that we’re actually born tuned towards systems thinking. If you look at a two-year-old or a three-year-old, they will frequently ask why? Why? Why? What they’re trying to do is to connect how things work. They’re looking for those interactions, those relationships. Western education actually takes us and makes us deep analytical thinkers. Now that’s good, that’s a lot of technological advance, but we have to re-prime that system’s thinking pump.

So we all have the capability if we tend to it. If we shift then and look at MBSE as we’re implementing SE today, the first myth is that somehow MBSE is different than systems engineering. It’s not this different thing. It’s a modern approach taking advantage of today’s technologies. Second myth would be that MBSE equals SysML or any other notation, any other language. The reality is MBSE is all about leveraging today’s digital capabilities. The unprecedented computing power, the unprecedented storage capability that we have to better represent and analyze the systems that we’re trying to build. We can be more explicit, more coherent, and more consistent, and we can leverage that computational power to simulate before and during the build to deliver better results. So MBSE is just SE done in today’s environment with today’s technologies.

Langberg: I like the way you described that because I agree, I’ve encountered that misconception as well about trying to equate to the system SysML. It’s not about a language, a modeling language; it’s about us all speaking the same language as far as SE goes. And that’s what I think MBSE is often trying to bring in to the technology.

Long: And one of the challenges there, Aimi, is that systems engineering is still as much of an art and a craft as it is a formal discipline. And so MBSE is forcing us to mature the principles and understand the underlying foundation. And that’s why it can sometimes feel like it’s different than SE, it’s why sometimes SysML can be confused with BEAN MBSE, but if we’ll recognize that we’re maturing the practice as we go digital, I think that helps the journey.

Langberg: And that’s one of the big topics all the time is about how do we do these digital transformations. Are organizations doing enough to foster systems thinking? As we move towards these transformations, are there simple techniques to get started or ideas you have at the grassroots level?

RELATED: A Path to Model-Based Systems Engineering (MBSE) with Jama Connect

Long: So I would argue that traditional organizations are not doing enough to really foster systems thinking. A traditional organization is built on an industrial mindset, the mindset that allowed us to do factories. And that’s a mechanistic mindset which says if each of you will do your bit part, then the whole thing will assemble and work. And if we’re working simple problems, precedented problems, if we’ve mastered the design and we’re building a million of these cogs, that works. But that’s not what we’re really doing. We’re doing things that are more complicated and more complex.

So I think organizations need to promote big picture thinking. I think they need to not only communicate what it is they want somebody to do, but what the context is for that work, and what the greater context is for what the organization is delivering. If we seek to understand not only the solution that we’re building, but the problem we’re trying to solve, that yields fresh insights from the problem space and actually allows each of us as specialists to bring our knowledge to say, oh, that’s what you’re trying to do. Well, there’s this interaction that we haven’t thought about or have we tried thinking about this.

Now, if you go back in time, we had integrated product teams. That’s a simple starting point. Empower those integrated product teams with an understanding of context and problem and get them to collaborate across bounds, and you’ll get better systems thinking. If we talk about what can I do as an individual, what if my organization is not pushing this? Well, rather than just focusing on the processes that we do, focus on why we’re doing what we’re doing. What’s this problem that we’re trying to solve? How are we trying to solve it? And then what are we doing? That understanding of larger context of relationship and dependencies are really important. What you’re building, what’s it connected to? When you’re building what you’re building, who are you dependent upon, and who’s dependent upon you?

And the last thing that I’ll say here is there’s a very simple technique out of business analysis that’s helpful here, and it’s called SIPOC, S-I-P-O-C, and it stands for supplier; understand who’s feeding you stuff. Inputs: What are the inputs to you or the inputs to what you’re building? Processes; that’s what you’re doing, that you’ve got through analytical thinking. Outputs: What are you generating? And then customers or consumers, who is consuming that? And if you individually think about SIPOC for what you’re building and you how you’re building it, you’ll be better connected and you’ll start to foster at least a systems thinking understanding of your part of the puzzle.

TO WATCH THE ENTIRE WEBINAR, VISIT:
Best Practices for Leveraging Systems Thinking in MBSE

Suspicious Requirements: The Importance of Suspect Tracking in Requirements Management

Impact and change Analysis are two important concepts in requirements management. Understanding how a change made to one requirement, impacts the upstream and downstream relationships is essential in assessing the scope a change may make.  What happens when a change IS made to an upstream requirement, and you are a downstream stakeholder? How will you know and how can you manage this change? This is where suspect notification plays an integral role in informing users of changes to the requirements that they care about. 

RELATED POST: The Essential Guide to Requirements Management

When relationship links are established between requirements, Jama Connect users can utilize the Impact Analysis feature to inform them as to the downstream or upstream impact of changes to a particular requirement. This helps to indicate the scope a particular change may make across the system of linkages. If suspect linking is enabled, and a change is made, users are alerted of these changes through various indicators and views in Jama Connect:  

  • Displayed in the Relationship Indicator column with a red exclamation point icon (which you can hover over to see how the item violates relationship rules.)
  • Displayed in the individual requirement in the “Relationship” view as “Causing Suspect” for each linked requirement that is suspect. 
  • Displayed as a Project-wide view under “Project > Suspect Links” 

If a linked requirement is marked suspect, users can take advantage of Jama Connects’s Compare Versions feature and get a side-by-side visual comparison of the changes between versions of requirements to determine what has changed. This allows them to assess the impact of the change that caused the suspect and make appropriate changes to the linked requirements.  A good example of this is if a set of verification tests are linked downstream to a functional requirement. If a change to the details of the functional requirement is changed, then all downstream verifications will be marked suspect, and the test lead can impact the change and update the tests accordingly. When the changes are complete, the suspect link can be “cleared” (either individually or in bulk). This ability to control and react to change is especially important in meeting regulatory standards, such as DO178C, ISO26262, ISO 13485 (and many others). We cannot assume requirements are static and must have visibility to what changed, and the impact that change will have.   

Suspect linking can be configured in the Jama Connect Org Admin setting, per item type field. This allows for granular flexibility for users to set which field changes will trigger a suspect link. This level of flexibility is extremely important as it allows users to define suspect rules according to their process and what fields are essential to track for change. 

Conclusion: 

Don’t let suspicious requirements scare you! Understand that they are an important part of the requirements change process and are there to help you control and react to updates made to linked requirements.  Let’s face it, requirements change, and getting a clear understanding of when something changes and what changed is essential. 

 

Requirements Management Planning: A Guide for Product Teams

What is Requirements Management Planning

Requirements Management Planning is the process of documenting how you will gather, analyze, document and manage the requirements of a project, manage changes to requirements once they have been approved, manage the configuration of the requirements documentation, and track verification of the project’s requirements.

Requirements Management Plan

Product success depends upon the successful project management of the product’s requirements. Effective requirements management, in turn, requires thoughtful planning.

A requirements management plan describes how you will gather, analyze, document, and manage the requirements of the project. It should describe how you intend to gather the high-level project and product requirements from project stakeholders, industry standards and governmental regulations, as well as the more detailed product requirements you will collect and develop over the project lifecycle. Your requirements management plan should also specify how you will manage changes to requirements after they have been approved.

Your requirements management plan is a tool for communication. It provides all your project’s stakeholders with a common understanding of how the product’s requirements will be managed to ensure success.

In this article, we’ll describe the requirements management planning and the recommended components of a requirements management plan.

Components of a requirements management plan

A solid requirements management plan will be composed of several components. Here, we’ll describe our recommended sections. Depending upon your industry and organization, not all of these sections may apply to your situation. 

Project overview

Briefly describe the purpose of the project. Explain the need the product will fill for the customer or target market and how its development will benefit your company. Mention important goals for the project and any notable constraints that may have been imposed upon it.

Roles and responsibilities

This section lists the roles of those who will be involved with managing the requirements through the rest of the project lifecycle, along with the responsibilities of each role.

Typical roles include: 

  • Project manager
  • Lead analyst / lead requirements engineer
  • Analyst / requirements engineer
  • Stakeholder

The project manager typically has overall responsibility for managing the scope of the requirements for the project.

The lead analyst / lead requirements engineer may also be a lead systems engineer or lead developer. This role is generally given overall responsibility for requirements development and integrity.

Analysts and requirements engineers assist the lead analyst / lead requirements engineer and are typically tasked with following the specified procedures for managing the subset of the project’s requirements for which they have been given responsibility.

Other project stakeholders who provide input to the requirements base are generally given responsibility for reviewing the requirements at specified milestones.

Tools

In this section of your plan, describe any automated tools that will be used to manage the requirements. Provide a brief overview of how those tools will be used during the requirements management process, and reference any documented procedures governing the use of the tools.

More detailed descriptions of how the tools shall be used in the various steps of the process should be provided in the sections of the plan that describe those steps.

Requirements gathering

Describe the process that you will use to elicit, analyze and document the requirements. Then, describe the requirements gathering techniques you will use and with what groups you will use them.

RELATED POST: 11 Requirements Gathering Techniques for Agile Product Teams

Categorization and assignment

Here, you will describe your process and procedures for dealing with various types of requirements.

Describe how requirements will be categorized within your requirements management system. Typical categories include:

  • Functional
  • Non-functional
  • Internal
  • External
  • Regulatory
  • Performance
  • Quality
  • Training
  • Support
  • Maintenance

The difference between functional and non-functional requirements—what the product must do versus any constraints on how the product must be constructed—normally impacts how the requirement will be verified. For more information on non-functional requirements and their impact on product development, click here. 

Internal requirements will generally be driven by the needs of stakeholders within your organization. External requirements will include those driven by customers, market forces, government regulations industry standards, etc.

A requirement’s category will dictate, in part, how it is assigned for development, implementation and verification. Your plan should describe your policies and procedures for assigning requirements to subsystems or components or by work breakdown structure (WBS).

Prioritization

Companies will prioritize the fulfillment of some requirements over others. Reasons for high prioritization may include market demand, regulatory compliance, contractual obligation, or internal stakeholder need.

That’s why it’s important to plan and document how you will prioritize requirements for development and release. Keep in mind that you will likely describe in detail your rules for prioritizing requirements in your Product Requirements Document. 

Traceability

Describe your overall process for tracing requirements throughout the product lifecycle: from gathering, through decomposition, development, implementation and verification. Mention the tools to be used to accomplish the traceability process. 

Requirements and their attributes need to be tracked throughout the project lifecycle to ensure fulfillment. Attributes to be tracked may include:

  • Name
  • Type
  • Project unique identifier
  • Source (stakeholder, document, parent requirement, etc.)
  • Children (lower level requirements derived from the requirement)
  • Assigned element of the WBS where it will be addressed
  • Verification method (if your project requires a variety of methods)
  • Verification reference (to the procedure that will verify the requirement)
  • Compliance reference (applicable regulations/paragraphs)

RELATED POST: What Is Requirements Traceability and Why Does It Matter for Product Teams

Change management

As a project evolves, requirements will need to be added or modified. Therefore, your requirements management plan should include a section that describes your policies and procedures for change control.

Change management (or change control) generally involves documenting each proposed requirements change in a change request. Once written, the change request is analyzed by affected stakeholders for any possible impact on project objectives or other requirements. The change request then goes before a change control board where it is either accepted (to be implemented) or rejected (and either revised or dropped). Your procedures for change control (raising, reviewing, tracking and approving change requests) should be described or referenced in this section.

Configuration management

Describe how you will monitor and control changes to your requirements documentation. Configuration management deals primarily with how documents will be revised and released during a project.

For many projects, depending upon your organization, this section may be combined with the Change Management section just described. For very large projects, you may want a separate Configuration Management section. If you have a separate Configuration Management Plan you’ll probably want to reference it and keep this section brief.

Verification

Finally, describe the methods and metrics you will use to verify requirements. Specify how their achievement will be measured, tested, etc.

If you use a variety of verification methods to verify different types of requirements, you will likely want to give a brief explanation of the procedures for each and how each type of verification is documented.

Benefits of requirements management planning

As mentioned earlier, your requirements management plan is a tool for communication. It helps your analysts, systems engineers and developers get up to speed and stay on the same page when it comes to managing your project’s requirements. Plus, it gives higher-level stakeholders a warm, fuzzy feeling that your product’s requirements will be properly managed to ensure your product’s success.

For more in-depth information…

Requirements management and requirements management planning can be greatly simplified through the use of a state-of-the-art requirements management tool like Jama Connect. For a deeper dive, visit our Essential Guide to Requirements Management! 

requirements-management-hub

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

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!

DOWNLOAD

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.


This image shows a bullseye target, graph, and money to show that change impact analysis is beneficial and that best practices help make goals.

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.

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

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

A colorful link of chains showing the elements that make up the roles of traceability in change impact analysis; identifies effects, reduced rework, strengthens compliance, and enhances collaboration.

Editor’s Note: This section was added to this blog post on 4/08/2025. It was written with assistance from AI and reviewed and updated by McKenzie Jonsson.

The Importance of Traceability in Change Impact Analysis

Effective change impact analysis is not just about identifying affected requirements, tests, and risks—it’s about doing so with confidence, speed, and accuracy. This is where traceability becomes critical.

Traceability is the ability to track and document the lineage and history of requirements throughout the development process. It ensures that every requirement, test case, design element, and risk assessment is connected in a structured way, providing full visibility into all dependencies in the full process. When a change in one element is introduced, whether in response to evolving customer needs, regulatory updates, or system modifications, traceability enables teams to easily assess the impact of that change on all related artifacts.

How Traceability Enhances Change Impact Analysis

The truth is, the two go hand in in, really. Traceability supports change impact analysis in many ways, including:

  1. Identifies Downstream and Upstream Effects
    Changes in one part of a system can have cascading effects on related requirements, tests, and risk assessments. With end-to-end traceability, teams can immediately see what is impacted and take proactive steps to mitigate risks.
  2. Reduces Rework and Late-Stage Surprises
    Without traceability, overlooked dependencies often result in late-stage failures, expensive rework, or compliance gaps. A traceability-enabled approach to change impact analysis allows teams to plan changes with greater precision, minimizing unexpected disruptions.
  3. Strengthens Compliance and Audit Readiness
    Many industries, from medical devices to automotive and aerospace, require stringent documentation of changes and their impact. Traceability ensures that organizations can quickly generate reports that demonstrate compliance with regulatory requirements.
  4. Enhances Collaboration Across Teams
    By maintaining a single source of truth, traceability tools ensure that stakeholders across engineering, quality, and compliance teams stay aligned. This reduces miscommunication and streamlines decision-making.

RELATED: Traceable Agile™ – Speed AND Quality Are Possible for Software Factories in Safety-critical Industries

Leveraging Traceability Tools for Smarter Change Management

Manual impact analysis is time consuming and error prone. Modern requirements management platforms like Jama Connect® provide real-time traceability (Live Traceability™), allowing teams to visualize relationships between artifacts and perform change impact analysis efficiently. These tools help teams:

  • Instantly generate trace reports to understand how a change affects the system.
  • Perform gap analysis to ensure all impacted areas are accounted for.
  • Automate notifications to relevant stakeholders when changes occur.

By integrating robust traceability into change impact analysis, organizations can reduce risk, accelerate development cycles, and maintain compliance with confidence —ensuring that every change is made with clarity and precision.

[Webinar Recap] Driving Business Outcomes with Jama Software’s 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

RELATED


G2 Again Names Jama Connect® the Leader in 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!

DOWNLOAD

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

RELATED


FAQ: Adopting EARS Notation to Improve Requirements Engineering

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

RELATED


Introducing The Essential Guide to 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