Tag Archive for: Jama Connect Platform

People looking off into the distance toward 2025 medical device predictions

2025 Expert Predictions for Medical Device & Life Sciences: Innovations in Patient-Centered Care and the Future of Medical Device Design

As patient-centered care takes center stage, the medical industry is witnessing an unprecedented transformation in how devices are designed, developed, and regulated. From the rise of direct-to-patient products and AI-enabled diagnostics to the challenges posed by cybersecurity and evolving regulatory landscapes, 2025 promises to be a pivotal year for medical innovation.

In part five of our annual predictions series, Richard Matt – Medical Product Consultant at Aspen Medical Risk Consulting, and Vincent Balgos – Director, Solutions & Consulting at Jama Software, share their insights on the future of medical devices. Together, they explore how digital solutions are reshaping patient care, the hurdles the industry must overcome, and the exciting possibilities for advancing remote monitoring, telehealth, and AI-powered solutions.

We like to stay on top of trends in other industries as well. Read our predictions for Industrial & Consumer Electronics (ICE) HERE, Automotive HERE, Semiconductor HERE, and Aerospace & Defense HERE – Plus, stay tuned for our future topic, AECO.

With patient-centered care becoming increasingly important, how do you see software and digital solutions transforming the design and development of medical devices in the next few years?

Richard Matt: Software development needs to mature to a place of contributing equally with other specialties instead of excelling independently. Far too many companies are being held back by technical siloing, usually led by software. The tragedy is that software personnel are among the most creative and productive employees. Their collaboration needs to mature to a place of creating opportunities for other specialties to be as efficient and achieve this together.

Vincent Balgos: There is a growing trend of direct-to-patient products (hearing aids, CGM’s, smartwatch apps) that includes complex software and digital solutions. In addition, most traditional med devices are now connected to the internet or other devices. I’d expect this trend to continue in this digital age, but with that growth, there will be some unintended side effects. Specifically, cybersecurity threats will continue to become a significant factor during the design, development, and on-market phases of the product.

RELATED: Integrate Cybersecurity and Safety Risk Management in Jama Connect® to Simplify and Accelerate Medical Device Development

Regulatory compliance and data security are paramount in life sciences. What advancements in software do you think will be most effective in managing compliance and protecting sensitive patient data?

Matt: Big data will become more available and utilized systematically to provide answers to questions that have been answered inadequately for decades. Protecting patient data is a simple matter of awareness and giving cybersecurity the sliver of attention it needs to close off the dominant attack vectors.

Balgos: In recent conferences I’ve attended (and read about), AI/ML continue to dominate the discussion around software advancements. Whether providing internal value to organizations, or external facing with AI/ML enabled devices, the impact that AI/ML has (generative, predictive) will play a major factor in the security of data (whether positive or negative). The regulatory guidance of AI/ML is still evolving so it’ll be interesting to see how it unfolds in the future.

As AI and machine learning continue to evolve, what role do you see these technologies playing in medical diagnostics, treatment personalization, and device functionality by 2025?

Matt: AI and ML will continue to evolve, as they have for generations. We have made recent, significant steps forward in natural language recognition, but the integration of that forward movement with diagnostics and treatment personalization will continue to be slow and incremental.

Balgos: The expansion of AI/ML in various traditional areas of med devices is continuing to grow at an exponential rate. Looking at FDA’s dataset, the # of authorized AI/ML enabled devices continue to grow YoY as much as 40% with applications in new areas. Currently, predictive AI is supporting medical professions with their clinical assessment/decisions in a supportive role and seems to be the common use case. But there are current talks now on how generative AI could add potential value in these device areas as well.

What are the biggest hurdles the industry faces in adopting cutting-edge software solutions in device manufacturing and patient care? How can companies proactively address these challenges?

Matt: The biggest hurdle is technical siloing, which software leads very capably. Companies can proactively address this challenge by implementing a systems-approach to problem solving / product development that respects all the technical contributions needed to succeed and ensures software personnel use their exceptional abstraction abilities to work in collaboration with the rest of the company.

Balgos: Some of the biggest hurdles my customers talk to me about are the evolving regulatory landscape, continuing pressures to accelerate development, scalability and ongoing resource and budget constrictions. For changing regulatory, I do recommend folks to work with a qualified regulatory affairs profession for guidance (and is now required in EU). For acceleration, scalability and resource constraints, companies are proactively looking for ways to maximize efficiency and looking to innovative ways to help organizations (e.g., AI applications).

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Medical Device & Life Sciences

How do you foresee the growing demand for remote patient monitoring and telehealth impacting product development for medical devices? What innovations do you think are necessary to support these shifts?

Matt: COVID was an unplanned stress test on our remote work capabilities. We need to analyze the results of that stress test to identify strengths and weaknesses to build into our next generation products and services.

Balgos: Based on the new FDA CDRH Director’s speech at MedTech Conf 2024, these demands coincide with their Home as a Health Care Hub initiative where these homestead digital solutions are becoming more at the forefront of healthcare for many patients. With these increasing interests and demands, I think connectivity of these devices will continue to rise, AI/ML will play a major factor in delivering value, and also improvements in the human factors/usability aspects of these devices will be something to watch. Transitioning from a professionally trained clinical staff to the general population, there will need to be a shift in developing these at home devices to be extremely ‘easy to use’, especially with those that struggle with technology, complex processes, and tedious tactile tasks.

With these innovations, there will be some side effects such as cybersecurity, post market updates, and the interoperability of all these devices. While they seem daunting, I’m confident that industry will rise to the challenge as they have with other previous challenges

Are there any additional insights you have regarding predictions, events, or trends you anticipate happening in 2025 and beyond?

Balgos: In early 2026, the FDA’s final rule on the Quality Management System Regulation (QMSR) will be effective, thereby incorporating ISO 13485 elements into the current Quality System Regulation (QSR). QMSR will supersede QSR.

This image shows a clock wearing a graduation cap to portray that this is a quick, informative video on the topic of Live Trace Explorer.

Jama Connect Features in Five: Live Trace Explorer

Learn how you can supercharge your systems development process! In this blog series, we’re pulling back the curtains to give you a look at a few of Jama Connect’s powerful features… in under five minutes.

In this Features in Five video, Francis Trudeau, Product Manager at Jama Software, will introduce viewers to Jama Connect’s Live Trace Explorer, which auto-detects risk by bringing comprehensive and detailed insights into your complex development processes.

Please note that Live Trace Explorer is currently in beta and available for all Jama Connect Cloud customers to try.

VIDEO TRANSCRIPT

Francis Trudeau: Hello and welcome to the segment of Features in Five. My name is Francis Trudeau, and I’m a Product Manager at Jama Software. This video is an overview of Jama Connect’s Live Trace Explorer feature. Note that Live Trace Explorer is currently in beta and available for all Cloud customers to try.

The Live Trace Explorer is like a real-time map of the V-model, helping you check coverage completeness and validity across your project. It actively tracks metrics to spot gaps and risks between engineering teams so you can address issues early. This leads to a smoother development process, higher quality products, and faster time to market. This capability is a significant step in our vision to provide metrics for managing the development process through data.

To enable the Live Trace Explorer, go to the Admin tab, navigate to the Details section, find the Live Trace Explorer line, click Configure, check the box, and save. Once enabled, the feature appears in Admin Project settings and is available for Organization and Project Admins.

RELATED: Best Practices Guide to Requirements & Requirements Management

Trudeau: If permission is granted by their admins, users with a creator license can fully utilize the feature to load and configure existing diagrams. Once enabled, the Live Trace Explorer can be launched by right-clicking a project component or set to create a focused diagram for the selected node or right-clicking the project route to generate a comprehensive diagram showing all components and sets in sequence from top to bottom.

The resulting diagram visually represents the V-model with stakeholder needs, system requirements, designs, and components on the left, and their associated verifications and validations on the right. Each tile represents a component or set connected by trace paths. These paths are gray if there are no relationships between items and adjacent tiles, or they turn green and red to indicate the number of healthy or suspect relationships between them.

On the right side, the Verifications and Validation branch shows the number of Test Cases linked to items within the container on the left, no matter where they appear in the project. At the bottom of each tile, you’ll find a metric representing the ratio of these Test Cases included in a Test Plan. On the requirements side, the top part of each tile displays stats, including the number of items by type and any open conversations.

RELATED: How to Achieve Live Traceability™ with Jira® for Software Development Teams

Trudeau: In the bottom half, you’ll find coverage metrics, essentially the ratio of active relationships to expected ones as defined by the traceability information model. For example, the model indicates that each high-level requirement should have two relationships downstream. Out of my four high-level requirements, three are covered by validations, giving me 75% coverage. Two are related to mid-level requirements, resulting in a score of 50%. In the Actions menu, you can access configuration settings to customize what’s displayed and measured. You can globally turn off item types, exclude specific relationships from consideration, or you can configure each tile separately.

A common use case consists of configuring your diagram for disabling relationships you are not expected to have at an early stage of your project. Then you may want to disable lower-level requirement items and relationships pointing downstream to them. Once applied, the coverage and total score will update automatically. Make sure to save your diagram once you have configured it to your liking. Live Trace Explorer updates in real-time, so any changes to project data instantly affect the metrics. For example, I can address a gap by clicking on the incomplete coverage. This will open Trace View where I can then establish a relationship to a mid-level requirement. Back in Live Trace Explorer, the metrics and total score summarizing all coverage will be updated after a refresh. You can keep a record and share these metrics by exporting a diagram as a PDF from the Actions menu at the top.

If you’d like to learn more about how Jama Connect can optimize your product, software, and systems development processes, please visit our website at jamasoftware.com.

To view more Jama Connect Features in Five topics, visit:
Jama Connect Features in Five Video Series

This image shows a speaker who will give a presentation on ARP4754B.

In this blog, we recap our webinar, “The New ARP4754B: Tips for Engineers & Quality Teams” – Click HERE to watch it in it’s entirety.

Navigating the updates to ARP4754B can be challenging.

Understanding new safety analysis methods, validation and verification flexibility, and strategies to mitigate unintended behaviors is crucial for advancing aerospace development and ensuring compliance.

Join us as Cary Bryczek, Director of Aerospace and Defense Solutions at Jama Software, shares practical tips for engineers and quality teams to navigate the most impactful changes in ARP4754B.

Gain Insights On:

  • Changes from ARP4754A to ARP4754B
  • Model-Based Safety Analysis (MBSA) and Cascading effects Analysis (CEA)
  • Identifying and mitigating unintended system behaviors
  • Tying your safety analyses to requirements in Jama Connect
  • The updates to verification and validation methods

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

The video above is a preview of this webinar – Click HERE to watch it in its entirety!

VIDEO TRANSCRIPT

The New ARP4754B: Tips for Engineers & Quality Teams

Cary Bryczek: We’re going to have fun talking about the changes from ARP4754B revision A to revision B. We’ll spend some time a little bit more deeply on its emphasis on model-based design and safety. I’ll talk about enhanced integration of safety and requirements management and some of the changes to validation and verification. At the end, we’ll have some time for Q&A.

A quick refresher on what ARP4754B is. Its title is Guidelines for Development of Civil Aircraft. It’s an industry guideline developed by SAE International that provides recommended practices for the development of complex civil aircraft and systems. It outlines a structured systems engineering process for the integrating of hardware, software, and human factors to ensure safety, reliability, and performance across the system lifecycle. The document emphasizes traceability, verification, and validation from initial concept through to certification with a strong focus on meeting regulatory safety and design assurance standards.

ARP4754B also aligns and is used in conjunction with other key aerospace standards like DO-178C and DO-254 offering detailed guidance on how to meet safety and certification requirements in the context of modern integrated aircraft systems. ARP4754 revision B is meant to expedite consistency with ARP4761 revision A, the safety assessment process, which was it was released on the same day in December of 2023.

The guideline describes generic aircraft system development process, which establishes a framework for discussing the process. ARP4754B doesn’t imply a preferred method or process, nor does it imply a specific organizational structure. At its simplest, it emphasizes the flow down of intended aircraft function through the system requirements management process and allocation of function to systems, subsystems, and hardware and software items.

Integral processes in the context of 4754B refer to key processes that are interwoven throughout the entire development lifecycle of aerospace systems from concept to design, integration, verification, and certification. Now, these processes ensure that various engineering disciplines, your systems engineering teams, your hardware and software engineering safety are fully integrated, aligned, and contribute to the overall success of the project.

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Aerospace

Bryczek: This diagram from 4754B outlines the key stages of the aircraft system development process and provides a framework for understanding how safety is integrated into each stage. The safety are the ones that are in the lightest white or gray. The standard approach ensures that the safety risks are identified, analyzed, and mitigated early in the design process, and are continuously assessed throughout the system lifecycle.

I want to point out that lifecycle phases really are iterative and independent. 4754B emphasizes that the phases of system development aren’t strictly linear. For example, design and development may loop back to earlier phases such as the requirement’s definition. If issues are found during those later stages, sort of this iterative approach ensures that safety concerns can be identified and corrected throughout the lifecycle.

You’ll also notice that safety and hazard analysis is integrated throughout the development phases. Safety assessments are continuous activities throughout the development process. Safety considerations such as your functional hazard assessments, your fault tree analysis to your cascading effects analysis are embedded within multiple phases, particularly the design, development, and verification phases.

Let’s get to the meat of what has changed. So ARP4754B builds on the foundation laid by 4754A but offers a much more structured, detailed, and modern approach to developing complex aerospace systems. This is in response to the increasing complexity of our modern aircraft, tighter safety requirements, and evolving certification processes, particularly the need for rigorous system integration, traceability, and safety assessment practices. It provides greater clarity around the development assurance levels and how they relate to the overall system and safety requirements.

RELATED: Jama Connect Airborne Systems

Bryczek: While A provided a basic framework, B refines the application of DALs throughout the system lifecycle. B expands the understanding of development assurance levels in the context of aircraft and system development, and it places a greater emphasis on safety, traceability, and integration across the lifecycle stages. The updated standard provides a more comprehensive guidance on managing the DALs and aligning the safety assessments with the system requirements, and it ensures that development processes are rigorous enough to meet the increasing complexity of the modern aircraft systems.

With the increased use of model-based techniques, 4754B highlights the benefits of using models to perform safety assessments. It recognizes that simulation-based safety analysis can help engineers assess the safety of complex integrated systems much more efficiently by modeling different failure scenarios and responses, so the standard supports using simulation tools to model those failure scenarios and validate the robustness of safety-critical systems. And this all just improves the accuracy of safety analysis, and it helps identify the potential issues earlier in the design process.

THIS HAS BEEN A PREVIEW OF OUR WEBINAR, WATCH IT IN ITS ENTIRETY:
The New ARP4754B: Tips for Engineers & Quality Teams

In this blog, we recap the “Write Better Requirements with Jama Connect Advisor™” webinar.
Click HERE to watch it in its entirety! 

Achieve Project Success with Clear, Effective Requirements

In this webinar, the speakers provide insights on how to leverage Jama Connect Advisor™, an easy-to-use, cutting-edge requirements authoring, editing, and analysis tool. Jama Connect Advisor uses Natural Language Processing (NLP) and evaluates and scores requirements against INCOSE EARS guidelines, enabling teams to create industry-compliant requirements, reduce risk, and improve efficiency throughout development.

You will learn how to:

  • Boost requirements clarity and writing speed as well as develop team skills with guided authoring
  • Track progress and improve requirements quality over time with downloadable reports
  • Improve the quality and usability of large volumes of requirement statements effortlessly with Batch Analysis
  • Save time on authoring, reviewing, and updating requirements
  • Confidently assess project readiness through requirements maturity analysis
  • Minimize rework risk due to ambiguity and contradictions

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

The video above is a preview of this webinar – Click HERE to watch it in its entirety!

VIDEO TRANSCRIPT

Write Better Requirements with Jama Connect Advisor

Jeremy Johnson: Thank you so much to everybody that’s joining us today. This is a pretty special time for us to be able to take a new capability to market. From a product management and product development standpoint, it’s an extremely exciting time for us. So again, I appreciate everybody’s time in joining us here today.

Before we transition into the main portion of the session here, I want to provide a short introduction and an overview of our agenda. We’ll talk a little bit, for those who aren’t familiar with us, a little bit about Jama Software. We’ll talk a little bit about the trends in product development, and some of the challenges that we see in requirements authoring. We’ll also of course introduce you to Jama Connect Advisor, who it’s for, and how it works. We’ll get into a demonstration. We’ll also talk a little bit about our customer success program, specifically our customer success authoring workshop, and how we are now including and embedding the technology and the capabilities around Jama Connect Advisor into that consulting offering.

And then, as Juliette mentioned, our special guest, Sheila King will go into the requirements quality focus that she’s helping implement at Rockwell Automation, and we’re super excited and happy to have her. And then, we should have some time at the end of the session for some questions as well.

But again, starting with and moving into Jama Software’s role in the product development ecosystem, our vision and our purpose as an organization is to ensure that innovators succeed. And as you’ll see from today’s discussion and demonstration, that’s really at the core of what drove our introduction of Jama Connect Advisor.

From a broader solution standpoint, Jama Connect is the number one requirements management provider in the marketplace. We help teams with requirement management and product development through live traceability that also spans not only requirements, but the verification and validation components on the test side, risk management, and other key data that drives those processes forward.

The value that we hope these innovative organizations, our customers, derive is really focused around things like cycle time reduction, helping speed time to market, enabling through live traceability the ability to gain visibility and control over the organization’s product development processes, and really drive streamlining, really drive a tremendous amount of value, and ultimately ensure compliance and managing risk.

As far as organizations that we work with, we span medical device, automotive, industrial, machinery,and software, and this is just a sampling of the customers that we have the pleasure of partnering with. We have over 800 customers globally. These organizations span from smaller startup organizations to large global enterprises.

So with that very short intro to Jama Software, I now would like to review some of the complexity and challenges that we see today in product development, and of course to introduce you to Jama Connect Advisor.

Related: Jama Connect Advisor™ Datasheet

Katie Huckett: Thanks, Jeremy. I’m really excited to talk about Jama Connect Advisor today and some of the things that are happening in the environment that led us to develop this solution. Today’s systems have become much more complex, and the emergence of the system of systems architecture has become the dominant approach for devices in all sectors, whether it’s aerospace, automotive, medical, and even consumer products. The system of systems is actually a collection of independent subsystems that are integrated into larger systems and deliver the unique capabilities required by users. The challenge is that it is difficult to predict accurate, predictable models of all emergent behaviors. So global systems of systems performance is difficult to design. That leads to testing and verification. Verifying upgrades to existing systems of systems is difficult and expensive as well, which is hard to scale. These are some of the factors that have led us to think about how we can help.

Another question we asked ourselves is why is requirements authoring so hard? If we look at the industry approaches for requirements authoring, we looked at the International Council on Systems Engineering’s (INCOSE) Guide for Writing Requirements. There’s a need to exercise a core subset of 40 rules in the INCOSE Rules for Writing Requirements, and in addition to that, an assessment of 49 requirement attributes. So just following INCOSE alone requires a substantial amount of training and understanding and then applying it, which can take a lot of time.

We’ve also found that EARS, the Easy Approach to Requirements Syntax, is being adopted by many organizations developing complex systems of systems. That includes Airbus, Bosch, Dyson, Honeywell, Intel, NASA, Siemens, and others. What EARS does is gently constrain the textual requirements. The EARS patterns provide guidance for writing a requirement sentence and provides syntax structure with an underlying rule set. Even these industry preferred approaches are challenging to apply, so we’re looking at how we might address that.

So today, just as a brief example, product requirements quality drives fidelity and efficiency in the product development cycle. If you look at this automotive example, there are many systems. It’s a complex system of systems that are dependent on each other. Any of these systems can lead to confusing the operator or systems operating optimally. If you look at the traditional V model of approaching systems engineering, the requirements are fundamental at the very early phase. So immediately after your needs analysis, you need to have really clear, concise, accurate requirements definitions.

The negative outcomes of poorly written requirements has been well-documented. It often leads to delayed time to market, late stage errors in the product, inaccurate translation of stakeholder needs into product attributes, and the lack of development team synergy. As teams are very organic today, the requirements need to be documented clearly and in an understandable way so that the team can execute with high performance. And then, ultimately failure and verification and validation can happen without high quality requirements.

Related: How the EARS Notation Supports Effective Requirements Management and Live Traceability™ 

Huckett: A secondary challenge is the training and reinforcement of requirements authoring skills. The lack of proper requirements can lead to product issues, and it’s a significant challenge in today’s environment. 30% of engineering degree holders are nearing retirement globally, and in the US 79% of American workers agree that to retain or increase their future employability, they need to continue with their learning and development. Computer scientists, 47.5% participate in work-related training to maintain and extend their skills, and engineers almost 60% do the same. So onboarding, retaining, and training system engineers remains a significant challenge.

With those items as a background, I’d like to introduce Jama Connect Advisor. Jama Connect Advisor is an add-on for Jama Connect Cloud. It’s an intelligent natural language advisor that improves the quality of requirements. It allows you to author intricate product requirements quickly, easily, and with precision. It is powered by engineering-based natural language processing, so not a general-purpose aid. It is engineering language-based. The advice provided is based on the industry-recommended best practices for the INCOSE rules and EARS notations.

Jama Connect Advisor has a very significant side benefit, while you use it, it augments skills and reinforces organizational preferences while authoring. So not only is Jama Connect Advisor doing the pragmatic work of improving requirements quality, but your systems engineers are learning how to do that more quickly and efficiently over time with its use.

When we look at Jama Connect Advisor’s capabilities, its features include analysis and advice from industry-leading practices, INCOSE rules, and EARS notation. The application is designed to put these two together to increase the quality, accuracy, and efficiency of requirement statements. So that’s its unique value. The guidance is provided seamlessly while you are editing in Jama Connect, which we’ll demonstrate in a moment. So really, the advantages are that experts can work faster confirming the application of INCOSE and EARS as they go, sharing their expert knowledge across the organization.

CLICK HERE TO WATCH THE ENTIRE WEBINAR:
Write Better Requirements with Jama Connect Advisor™

This image shows a cta for visitors to sign up for a trial of Jama Connect Advisor.

In this image, we show a clock and graduation hat to portray how the viewer can learn about our Universal ReqIf Import features in 5 minutes.

Jama Connect® Features in Five: Jama Connect Interchange™ – Universal ReqIF Import

Learn how you can supercharge your systems development process! In this blog series, we’re pulling back the curtains to give you a look at a few of Jama Connect’s powerful features… in under five minutes.

In this Features in Five video, Mario Maldari, Director of Solution Architecture at Jama Software, will introduce viewers to the Jama Connect Interchange universal ReqIF import capabilities. We will review how requirements data from suppliers and stakeholders can easily be imported into Jama Connect, where they can be further elaborated and defined.

VIDEO TRANSCRIPT

Mario Maldari: Hello. My name is Mario Maldari and I’m the Director of Solution Architecture here at Jama Software. Today, we’ll be discussing the Jama Connect Interchange Universal ReqIF import capabilities. We will review how requirements data from suppliers and stakeholders can easily be imported into Jama Connect, where they can be further elaborated and defined. With Jama Connect Interchange’s Universal ReqIF file-based exchanges are simple and streamlined regardless of what requirements management tool is used by the supplier. The tool’s automatic and intelligent field mapping helps to facilitate a smooth import process ensuring all data comes into Jama Connect as expected. This includes field and data mapping as well as maintaining upstream and downstream traceability between various requirements. Let’s explore how this works with Jama Connect Interchange.

We have received a ReqIF export from one of our many suppliers. This particular file contains a mixture of system requirements and subsystem requirements. We have worked with our supplier to define fields and values for the requirements. The system requirements contain tolerance values and due dates that were set in the originating tool. It also has subsystem requirements that contain a Boolean value named Compliance, which is set to true or false. We’ll be using Jama Connect Interchange to create a conversation, map our attribute fields, and import into Jama Connect.

RELATED: Jama Connect Interchange™ for ReqIF

Maldari: The first thing we will do is to create a conversation that will define the context of the import. We will choose a Jama Connect project that we would like to import the ReqIF file into and provide a name for the conversation so that we can refer back to it at any time to perform additional imports or exports. Once completed and saved, we can select on the Import tab. This is where we will upload our ReqIF file and prepare for the import. We can select a location in the Jama Connect project for where we want the requirements data to be imported into. We will create a simple mapping of the requirement types found in the ReqIF file to the desired and corresponding requirement types in the Jama Connect project.

Once this is achieved, we can point and click to map our labels and attributes. First, we’ll map the labels for our system requirements. One of the great things about Jama Connect Interchange is that it automatically detects the type for you during the upload process, so that you can easily perform a corresponding mapping into Jama Connect. This helps save time during your imports. It also takes the guesswork out of manual mapping. In this case, we’ll map four values, name, description, tolerance, and due date. The field mapping can easily be toggled on or off, depending on the data you want to map and import. Next, we will map the labels for our subsystem requirements. In this case, we’ll also map three values, name, description, and compliance.

Finally, we want to ensure that whatever relationships and traceability that existed in the source system are mapped over when imported into Jama Connect. Let’s go ahead and include the relationships, and we can even select the relationship type that we would like the requirements to have when imported. Once our desired mapping is complete, we can click the Initiate Import button to begin the import process. In this case, we’ll create new items. However, if we’re performing a round-trip exchange and we had already imported, we can easily update the items with changes made by our supplier during the import process. All events are logged in Jama Connect Interchange so that it’s easy to check on status and progress. Let’s navigate over to our Jama Connect project to see the imported requirements.

RELATED: Jama Connect Interchange™ for Software and Product Development Teams: Live Traceability Realized

Maldari: As expected, we see both system requirements and subsystem requirements. We can take a look at each and verify that the name, description, and other fields such as tolerance and compliance have also come in populated with data. We can view the relationships in traceability using our trace view to ensure that the traceability from the source system has been maintained. We can easily modify any of the values in these fields and change them according to our working process in normal requirements management activities. We can continue elaborating these requirements in Jama Connect or export them using Jama Connect Interchange to share back with our supplier at any time. Many requirements’ management tools have implemented their own version of ReqIF making interoperability a challenge. Only Jama Connect provides interoperability with universal ReqIF, making imports and exports easy regardless of their originating source.

Thank you for watching this Features In Five session on the Jama Connect Interchange for ReqIF import. If you’re an existing customer and want to learn more, please reach out to your customer success manager or consultant. If you’re not yet a client, please visit our website at Jamasoftware.com to learn more about the platform and how we can help optimize your development process. Thank you.

To view more Jama Connect Features in Five topics, visit:
Jama Connect Features in Five Video Series

This image shows a car, which represents a software defined vehicle (SDV)

In this blog, we recap a section of our whitepaper, “Strategies for Mitigating Software Defined Vehicle (SDV) Development Risks and Reducing Costly Recalls” – Click HERE to read it in its entirety.

Strategies for Mitigating Software Defined Vehicle (SDV) Development Risks and Reducing Costly Recalls

Reduce the risks of product rework and recalls by using tools that enhance the efficiency and accuracy of requirements management and aid in compliance with UL 4600, the Standard for Safety for the Evaluation of Autonomous Products.

The shift to software defined vehicles (SDVs) marks a pivotal change in the automotive industry’s journey toward full autonomy. Initially, there was a rush toward developing fully autonomous vehicles, but the complexity of this task led the industry to adopt a more gradual, phased approach. This market transition has given rise to SDVs, but unlike traditional vehicles, which remained largely unchanged after purchase and are based on dated architecture topologies, vehicle OEM’s can now scale their software investments and simplify and optimize the vehicle architecture. This has benefits not only for the developer — resulting in a reduced total cost of ownership, potential acceleration of development, and improved safety and security — but also for the consumer in the form of increased choice, new business models, and post-sales updates and fixes.

Improving product and software development processes and the tools that support them can more effectively enhance safety and security standards while mitigating the risk of costly midcycle rework and after-sales recalls.

In 2023, there were over 300 recalls affecting more than 25 million vehicles, with costs potentially reaching millions of dollars per recall.

The automotive industry has advanced significantly from even a decade ago. Once-basic features, like touchscreen navigation, have evolved into sophisticated connectivity options, voice assistance, app ecosystems, and more. These changes bring several development challenges, including:

Managing increased software complexity

As vehicles become more software defined, managing multiple software components provided by many different vendors that perform entirely different functions increases complexity. For instance, an electronic control unit might operate the antilock braking system, while a cockpit domain controller is responsible for a very different task. In a software defined vehicle these distinct software systems must work seamlessly across the vehicle without issues, adding further complexity to an already challenging development cycle.

Ensuring functional safety and security compliance

With increased complexity, automotive companies face additional challenges in keeping up with safety and security standards and the associated regulatory compliance. The development community has relied on ISO 26262 for many years as the required functional safety standard. But, while it has historically served as an excellent baseline, the standard did not account for software defined vehicles, autonomous vehicles, or many of the new use cases.

Standards are evolving to keep up, and new ones, such as UL 4600, have been created that directly tie to autonomous vehicles. However, these standards continue to require companies to build requirements, test those requirements, and demonstrate that they have done everything possible to build a safe and secure product.

The process is complex with SDVs, especially when considering the hundreds of millions of lines of code involved. Companies must show that no faulty code exists and that they have not inadvertently introduced back doors that could create security issues or conditions that could violate a safety goal. As a result, there is a need to reconsider old processes and tools for requirements management to meet the current development environment and support mitigating potential risks.

Difficulty in meeting accelerated timelines

The pressure to deliver products and software faster is a significant challenge. Technology evolves rapidly, and no sooner have you developed a vehicle than consumer needs and opportunities emerge, leaving you to redesign to keep up with the market, differentiate, and stand out.

However, meeting accelerated timelines can conflict with maintaining quality and compliance, making it critical to strike the right balance. Adopting tools that allow for automation and faster processes can help keep up with these demands while aligning with safety requirements and standards. As more and more companies adopt an Agile development methodology, it’s increasingly important that the associated development tools do not stifle the benefits that Agile can offer. One great example is the concept of Traceable Agile™ that facilitates instantaneous, in-cycle insight into coverage for Agile development teams.

RELATED: A Guide to Road Vehicle Cybersecurity According to ISO 21434

Managing the dramatic increase of third-party software

Advancements in automotive development have led original equipment manufacturers (OEMs) to source software from multiple vendors. Integrating this level of diverse software while avoiding safety and security issues can be challenging. Now, you not only have to integrate hardware from various suppliers but also manage a massive software bill of materials (BOM) from different vendors, ensuring that everything works seamlessly together.

You also need to ensure that you’re not introducing bugs due to incompatibilities between systems, which can cause unexpected glitches, security vulnerabilities and safety issues. These are very expensive, can potentially delay product launches, and create negative brand impact.

Often, hundreds or even thousands of software elements come together, with tens of millions of lines of code. Ensuring that all these elements work together while remaining safe and secure, and meeting consumer expectations for a modern vehicle, is critical.

Four Major Challenges with Software Defined Vehicles

1. Managing increased software complexity. The industry is shifting quickly due to the integration of software in vehicles, which presents challenges in effectively and efficiently developing and deploying SDV’s.

2. Ensuring functional safety and security compliance. Automotive companies face challenges meeting safety and security standards and regulatory compliance, particularly with complex software systems.

3. Difficulty meeting accelerated timelines. The pressure to deliver products faster in the SDV space is a key challenge.

4. Managing the dramatic increase of third-party software. OEMs are sourcing software from multiple vendors and integrating this level of diversity while avoiding safety and security issues is difficult.

Solid engineering practices involve deciding what to build, defining a set of requirements, building it, and then testing it. This development lifecycle process ensures that you’re solving for the correct problem and is centered around requirements management.

However, many organizations use Excel sheets or Word documents to house requirements. Initially, this approach might not seem problematic, but as products become more complex and requirements grow, the spreadsheet approach becomes unmanageable. Copying and pasting requirements across documents creates opportunities for errors, a lack of a single-source-of-truth and a lack of traceability introducing the risk of expensive product or software issues.

You can address this challenge by replacing legacy processes involving spreadsheets and other solutions with a more robust, automated tool specifically designed for requirements management. This change eliminates manual processes that open the door to errors, improves efficiency, and reduces the risk of missed requirements — resulting in potentially millions of dollars of savings.

RELATED: Why Choose Jama Connect® Over Microsoft Word and Excel Documents for Requirements Management

How Ford Selected a Single Requirements Tool for SDV Architecture

In 2022, Ford selected Jama Connect as a single requirements tool. The company started to deploy the tool focused on the development of a future software defined vehicle architecture.

Before Adopting Jama Connect

  • Engineers often lacked formal training in writing requirements.
  • Unconstrained natural language often contained large specifications (non-atomic).
  • Poor requirements were the standard, and engineers had no automatic ways to receive feedback.
  • Suppliers received thousands of requirement specifications in PDF, but some didn’t apply.
  • Signing-off on products was a manual process, with engineers often having to chase down test results.

After Adopting Jama Connect

  • Requirements engineering is a discipline with training easily available and just-in-time.
  • Engineers receive immediate and automatic feedback on requirements quality.
  • Product-line engineering automatically defines what is applicable to a variant of a product.
  • Dashboards show real-time and transparent progression of product sign-off.

Read the full Ford story HERE.

CLICK HERE TO READ THIS WHITEPAPER IN ITS ENTIRETY:
Strategies for Mitigating Software Defined Vehicle (SDV) Development Risks and Reducing Costly Recalls

Traceability in Systems Engineering: A Key to Successful Construction Projects

In the world of systems engineering, “traceability” is a concept that plays a crucial role in ensuring the success of complex projects. While it’s a term more commonly associated with fields like aerospace, defense, and software development, its principles are increasingly being applied to construction projects to improve outcomes, reduce risks, and ensure seamless project delivery.

What is Traceability in Systems Engineering?

Traceability in systems engineering refers to the ability to link each requirement to its source and track its fulfillment throughout the project lifecycle. This process involves creating a chain of evidence that shows how each requirement was derived, implemented, verified, and validated.

Simply put, traceability ensures that every requirement is accounted for from the moment it is conceived until the project is completed. It enables project managers, engineers, and stakeholders to understand the origins, rationale, and status of each requirement, ensuring that nothing is missed or overlooked.

RELATED: The Complete Guide to the Systems Engineering Body of Knowledge (SEBoK)

How Does Traceability Work in Systems Engineering?

  • Requirements Traceability Matrix (RTM): A core tool in traceability, the RTM maps each requirement to its corresponding design documents, test cases, and validation outcomes. This helps ensure that every requirement is directly linked to project deliverables.
  • Bi-directional Traceability: This involves tracking requirements both forward (from requirements to design, implementation, and testing) and backward (from deliverables back to the original requirements). This helps in managing changes, assessing the impact of modifications, and maintaining alignment between project objectives and outcomes.
  • Change Control and Impact Analysis: Traceability helps in managing changes to requirements by providing a clear understanding of how any change will affect the project. This is crucial for managing scope, cost, and schedule risks.

Applying Traceability to Construction Projects

While traceability is a fundamental practice in systems engineering, its application in the construction industry is becoming increasingly valuable. Here’s how traceability can be applied to make construction projects more successful:

  • Ensuring Complete and Clear Requirements: In construction, poorly defined or misunderstood requirements are a leading cause of project delays, cost overruns, and rework. By applying traceability practices, construction teams can ensure that all requirements are clearly defined, documented, and understood by all stakeholders from the outset. This reduces the risk of ambiguity and miscommunication, ensuring that every stakeholder is aligned with the project’s objectives.
  • Managing Complexity and Change: Modern construction projects are complex, involving multiple teams, disciplines, and stakeholders. Changes are inevitable, whether due to design modifications, client requests, or regulatory updates. Traceability allows construction teams to track every change back to its source, understand its impact on the project, and ensure that all affected requirements, designs, and plans are updated accordingly. This reduces the risk of errors, omissions, and costly rework.
  • Improving Compliance and Reducing Risks: Construction projects are subject to numerous regulations, standards, and codes. Traceability provides a structured way to ensure that all project requirements meet the necessary compliance standards. By maintaining an audit trail of all requirements and their fulfillment, construction teams can quickly demonstrate compliance, reducing the risk of regulatory penalties, legal disputes, and reputational damage.
  • Enhancing Communication and Collaboration: Traceability fosters better communication and collaboration among stakeholders by providing a single source of truth for all requirements. It ensures that everyone, from architects and engineers to contractors and clients, has access to the same information and understands how their work contributes to the overall project goals. This reduces misunderstandings, promotes accountability, and enhances teamwork.
  • Facilitating Project Delivery and Quality Assurance: Traceability helps ensure that the project is delivered on time and within budget by enabling construction teams to proactively manage risks, anticipate challenges, and respond to changes efficiently. By maintaining a clear line of sight from requirements to deliverables, teams can ensure that all project goals are met, and quality standards are achieved.

RELATED: AEC Best Practices Guide to Requirements Management

Why is Traceability Critical for Construction Project Success?

  • Reducing Rework and Cost Overruns: Traceability minimizes the risk of errors, omissions, and changes that lead to rework—a significant cause of cost overruns in construction. Industry studies estimate that rework can account for 5-15% of total project costs. By ensuring that every requirement is correctly implemented from the start, traceability helps reduce these costs and keeps the project on budget.
  • Improving Stakeholder Confidence: Traceability provides transparency and accountability, which is critical for building trust with stakeholders, including clients, regulators, and project teams. When everyone can see a clear, documented path from requirements to outcomes, confidence in the project’s success increases.
  • Ensuring Compliance and Avoiding Legal Issues: With construction projects facing stringent regulations and standards, traceability helps ensure that all requirements are met, reducing the risk of non-compliance penalties, delays, and legal issues. It provides an audit trail that can be used to demonstrate compliance to regulators, clients, and other stakeholders.
  • Supporting Continuous Improvement: Traceability provides valuable data and insights that can be used to improve future projects. By analyzing the traceability data, construction firms can identify patterns, lessons learned, and areas for improvement, leading to better project planning, execution, and outcomes in the future.

Conclusion

Traceability is not just a concept reserved for systems engineering; it is a powerful tool that can transform construction projects. By applying traceability practices, construction teams can reduce costs, manage complexity, ensure compliance, and build stakeholder confidence. As construction projects become more complex and multidisciplinary, traceability will increasingly become a key driver of success, helping teams deliver high-quality projects on time and within budget.

By adopting traceability, construction firms can not only improve their current projects but also build a foundation for continuous improvement, innovation, and sustained success in the industry.

Are you ready to make traceability a cornerstone of your construction project strategy?

Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by Joe Gould, McKenzie Jonsson, and Decoteau Wilkerson.

In this image, we show a vehicle lit up by several digital points to portray automotive & semiconductor trends.

In the world of automotive and semiconductors, where the pace of technological innovation seems to accelerate daily, staying ahead of trends is critical. That’s why we sat down with Neil Stroud, Jama Software’s industry expert with decades of experience spanning major players like Intel, Arm, and Samsung. Neil has been at the forefront of the functional safety and semiconductor evolution, witnessing firsthand the challenges and transformative changes that shape these industries.

In this exclusive interview, Neil shares his unique perspective on the latest industry dynamics, the impact of global supply constraints, and how the automotive industry’s strategic relationships with semiconductor vendors are evolving. He also discusses Jama Software’s role in helping both sectors address increasingly complex requirements and integration challenges, driving efficiency and reducing risk across the supply chain. Join us in exploring how Jama Connect empowers companies to manage complexity, enhance traceability, and accelerate their time to market.

Driving Innovation: Quarterly Automotive & Semiconductor Trends with Neil Stroud

Kenzie Jonsson: Thanks for sitting down with me today, Neil! I’d love it if you could spend a little bit of time telling us about your background and career path.

Neil Stroud: Prior to joining Jama Software back in April of this year, I’d spent most of my career in the semiconductor industry, working for companies like Samsung, NEC, and PMC-Sierra. I also spent 12 years with Intel, and then moved into the IP space with Arm who are one of the key players in semiconductor IP. Directly before joining Jama Software, I spent time with CoreAVI, a niche software company in the safety-critical graphics space. Almost twenty years of my career has been spent in the functional safety domain. It wasn’t by design; it was more by accident. I didn’t set out to get into that domain at all. It all came about through my time at Intel where I was calling on a big industrial automation company and they asked me the question, “Hey, so when are you going to start supporting functional safety with Intel architecture?”

Of course, at that point, I didn’t know what it was, what it meant, what it was all about. One thing led to another, and I stumbled into the world of functional safety and was given a great opportunity at Intel to go… I was going to say, go and lead it, but it was more me volunteering and saying, I think we should be doing this. And Intel the senior leadership at Intel saying, “Oh, go on then, go do it.” That’s exactly what I did. So, it was quite nice because you’re acting as a startup within the safety of a big corporation like Intel. At that point you start to look at the fundamentals – what does safety look like? What do we need to do as a company? How do we sell it? How do we make money out of it? What are the technical issues? What problems are the industry facing? That kind of stuff. So, I pretty much became a GM of my own startup at that point, which was a great experience.

That was back in the day when complex semiconductor functional safety wasn’t really a thing. So, we were blazing the trail, not just for Intel but for the whole industry. So, little did I know back then where it would lead. It’s been so much fun. That’s also what took me to Arm – to drive the whole functional safety strategy across their ecosystem. So, all of that obviously led me into adjacent businesses especially automotive, as safety is of paramount importance where I worked with the big OEMs and throughout the supply chain. Now here I am at Jama Software bringing all of that experience of semiconductor, automotive, and software and apply that into the requirements management tools domain to drive our presence and growth in the automotive and semiconductor segments.

RELATED: Jama Connect for Automotive

Jonsson: What changes have you been part of at Jama Software recently to help us better meet the needs of our customers?

Stroud: It’s a really interesting time to join Jama Software. Obviously, we’ve been successful as a company over the preceding years. I’m amazed by the number of different market segments that are using Jama Connect. There are some obvious ones like automotive, semiconductor, medical, consumer electronics, and aerospace and defense. But there are some emerging segments as well, which is great to see, like insurance companies and state departments and beyond. Clearly, Jama Connect is a tool that transcends verticals. But of course, we need to be able to tweak and tailor that to accommodate the unique needs of each market segment. Functional safety and cybersecurity are great examples of these differences. That’s what’s exciting as part of the change with Francisco Partners acquiring us back in April for $1.2 billion. That to me is a leading indicator that they’re betting on us to continue growing and we are investing heavily to continue to delight our current customers and of course help new customers achieve new levels of innovation. Placing that bet is exciting for all of us at the company. As a result, one of the changes we made at that time was to really double down on the vertical focus. So, bringing in an organizational structure that allows us to do and in turn drive even more alignment with the needs of each market segment.

It’s good for us. But more importantly, it’s good for the customers because we can talk in their language, we can better understand their problems, and of course we can partner with them to solve their problems. And that in turn means tailoring our product to better suit their needs. So, it’s a win-win. It’s a confirmation of the importance of those verticals to Jama Software and sends a clear message to that we are listening and here to partner with them on their growth journey. So, it’s exciting for me and I see that excitement across the whole company.

Jonsson: Can you tell us what you’re seeing in the industry with the conversations that you’re having with our customers and prospects?

Stroud: Well, I cover both automotive and semiconductor industries. There’s obviously a lot of overlap between the two, and I think that’s an increasing trend we’ve seen over the last few years. The automotive guys have been building a lot more of a strategic relationship with the semiconductor vendors. Not least because when the supply constraints kicked in a couple of years ago, production lines were coming to a halt because they couldn’t get hold of the smallest, tiniest, cheapest components. And at that point, it is interesting how it created a real forcing function. The automotive segment said at that point, “Right, we aren’t going to get burnt again.”

So, they did one or two things. Some went out and tried to tie down the semiconductor vendors contractually to say, “Look, in the event that this happens again,..” and it will happen again because the semiconductor industry tends to work on about a seven-year cycle of oversupply versus constraint, “we want to guarantee our component supply.” The car OEMs and tier-one suppliers obviously didn’t want to get caught in that again. I don’t have visibility into how successful those discussions were, but I don’t think it will necessarily prevent a recurrence. The good news is that there is huge investment going into building new fabs that will provide significant capacity increases in the coming years.

The other interesting dynamic that happened was some of the auto guys said, “Well, screw that. We’re going to do our own silicon.” It sounds easy when you say it quickly, but there’s an awful lot to it when you commit to that solution. Questions like, “Okay, so how are you going to do that?”, “Are we going to go and engage with a design house or we’re going to hire a team of semiconductor design engineers,” “Which fab supplier will we use?” “Will they guarantee supply?”

It’s not a trivial undertaking and to make it work from an ROI perspective it’s probably a ten-year journey. And in the meantime, you’ve still got to work with what you’ve got. The other issue is once you get down that path, you are committed and it’s an expensive commitment to make. The downside is you don’t get the benefit of volume that the big guys like Qualcomm, Samsung, MediaTek, or NVIDIA can offer you. They build millions and millions of chips and can amortize the cost across many customers and markets. If you’re building your own, you don’t get that advantage, but you mostly own your own destiny. So, pros and cons.

So that’s one dynamic. I think the other dynamic we’ve seen in automotive generally over the last five years is a repositioning of what’s important. If we go back, even just five years, we all thought we would be driving autonomous vehicles right now. There’d be mass deployment. You and I would both have one on the drive. Of course, that hasn’t happened because we all realized how difficult it is. I think we were in denial for a while, but that forced us to pivot to solving the software defined vehicle challenge. If we can get that taken care of, then that kind of leads us to the autonomous world anyway. And we can solve it in bite-sized chunks. So thankfully the automotive industry and the semiconductor industry, and probably lots of other industries now are focused on a software-defined vehicle as an intermediate step.

Solving this challenge doesn’t just apply to road vehicles. I think when you look at industrial automation, that’s the same. Do they want to get full autonomy? Of course they do. Is it a challenge? Yeah, it is. So, software-defined has a role to play there. Same in A&D, same in a lot of the other verticals. So, there are a lot of synergies between the verticals as well. That created, I think, clarity, but it also created a seismic shift for the car OEMs in that the OEMs themselves, and I’m talking more about the incumbent suppliers, the big guys like VW, Mercedes, Ford, GM and others. History shows they’re so used to being completely in charge of their own destiny – when you need something, you just put a team together and you go build it. Those days are gone. You look at complexity in a modern vehicle, whether it’s the hardware or the software, you just can’t do that these days. It’s not scalable.

So, you have to rely on the supply chain to drive the innovation and deliver those pieces, those elements, and then you as the OEM have to integrate them. But that’s not a world they’re used to. And it obviously introduces a whole world of complexity.

RELATED: Compliance Made Easy with Jama Connect for Automotive and Semiconductor Development

Stroud: That’s another area where using Jama Software really pays dividends to ensure the whole supply chain is seamlessly connected from a requirements perspective resulting in faster design and delivery across multiple vendors and a better-quality product overall. A modern vehicle can have upwards of 100 million lines of code going into a modern high-end vehicle and this is increasing exponentially. Those software elements are coming from a hundred different vendors. Some of those are safety-related, and some of those are security-related. All of a sudden as an OEM, I’m responsible for integrating all of that, checking it works together, checking it’s still safe, checking it’s still secure, and then rolling it out through the door for consumers to go and purchase a new vehicle.

At the same time, vehicle suppliers can use this new SDV approach to drive new business models that allow post-sales upgrades and updates. If a car doesn’t have a feature on the day of sale, in a year’s time the owner could say, “Hmm, it’d be nice to have that new feature.” You log into your account, put your credit card details in, and as if by magic, the new feature arrives over the air to your vehicle the next day. That’s a whole new world and we are only scratching the surface today.

So, I guess the punchline is from our perspective, and doing what we do, it’s all about efficient requirements management and traceability. This applies not just to the OEMs, but throughout the supply chain as well, to ensure the elements from those hundreds of different vendors all come together. Those requirements have got to be exquisitely accurate and all the independent interdependencies mapped out correctly to be sure that you’re not violating a safety goal or creating a bug in the system.

This way you get into traceability… How well is my project going? How healthy is it? How many of those requirements are covered right now and tested and using that capability to reduce the number of recalls, drive efficiency in the design team, reduce the risk, all those good things. Of course, this level of detail isn’t just important to the engineering teams. It can also be rolled out to senior management who are likely more interested in risk, cost, time-to-market and so on.

So, the market’s really coming to us. Jama Software is now the largest supplier of requirement management solutions overall, which we’re immensely proud of. But we have to learn from the market and our customers how Jama Connect changes grows and morphs as a solution to enable that ubiquitous risk reduction and efficiency improvement. So, there are some big factors at play.

So that’s automotive. The semiconductor segment is interesting as well. It’s a very different world, with different care abouts.

We’ve done very well in the semiconductor space overall, but it still frightens me to see how many spreadsheets are used to manage the business in the big semiconductor companies. And that’s speaking from experience because I lived in that world for a long time. There are way too many spreadsheets out there for doing requirements tracking. When you’re working that way, there’s no single source of truth and that will get you into trouble, guaranteed. It will cost you big with bugs in the silicon. So, it’s imperative to partner with the semiconductor industry and really drive change, accelerate innovation and solve tomorrow’s supply constraints. That’s on the chip design side, but also more recently, we’ve got the CHIPS Act, which is kick-starting a massive investment in the semiconductor industry to drive fab capacity to meet the huge growth in demand for chips.

So, we see the big players such as Intel, Samsung, and TSMC, all investing billions and billions of dollars to put fabs into place to meet this growth in demand and technology, which is exciting. The challenges are different to the auto market but guess what, these chip manufacturers need robust requirements management to run their business. And again, a lot of it’s been running on spreadsheets for a long time.

Now, we’re seeing, of course, headwinds in both industries. We still see that with EV vendors on the automotive side. We see even today challenges in the semiconductor industry with some consolidation of cost and trying to get costs under control. Jama Software has a critical role to play in that transformation. We can help drive efficiency and shorten cycles and time-to-revenue. All those things play into huge cost reductions for all. We are using our expertise in both product and deployment to educate and drive incremental success for our customers.

Kenzie Jonsson: Thank you for your time today, Neil! I really enjoyed this conversation, and I look forward to catching up with you next quarter!

This image portrays a webinar speaker who will lead the topic of Standardizing Requirements Management Across the Organization.

In this blog, we recap our webinar, “Standardizing Requirements Management Across the Organization” – Click HERE to watch it in its entirety.

Standardizing Requirements Management Across the Organization

Is your organization struggling with costly production failures?

A survey by Engineering.com revealed that a staggering 83% of companies faced production outcome failures — such as significant delays, cost overruns, product defects, compliance gaps, recalls, omitted requirements, and extensive rework — often stemming from inadequate requirements management.

In contrast, implementing standardized requirements management can lead to enhanced consistency, repeatability, predictability, and a distinct competitive advantage.

In this webinar, Matt Mickle – Director, Solutions & Consulting at Jama Software, explores the advantages of establishing, implementing, and enforcing requirements management standards within your organization.

In this session, you will learn:

  • The key benefits of standardizing requirements management across your organization
  • Common challenges encountered during the standardization process
  • How to leverage Jama Connect® to implement best practices and streamline your requirements management standards

BELOW IS AN ABBREVIATED SECTION OF THIS TRANSCRIPT

Matt Mickle: Hello and thank you all for joining today. Perhaps requirements management is a new task for you, or perhaps you have been doing it for many years. Hopefully, I can provide some value for any of those people listening regarding standardizing requirements management within their organization. Personally over the last 10 years working at Jama Software as a consultant and over hundreds of implementations that I’ve worked on with our customers on developing their process and modernizing their requirements elicitation, I have developed a strong bias towards the need for standardization is definitely a crucial area which if correctly developed within an organization, will actually improve the speed of product development rather than slowing it down.

So on the agenda today, we will talk about how standardizing requirements management processes can benefit your organization and also the challenges that organizations commonly face when developing a standardized process. Then we’ll dive into how Jama Connect can make the successful and sustainable implementation of standardized requirements management processes within your organization a reality. Before we get started, let’s make sure that we are aligned on what we mean when we say requirements management.

Requirements management, sometimes called requirements engineering or requirements definition is the process of documenting, analyzing, tracing, prioritizing, and agreeing on requirements, and then of course controlling change in communication to relevant stakeholders. It is a continuous process throughout product development and the process that companies use to take their raw ideas and turn them into detailed requirements. The pillars of requirements management include requirement definition, requirement verification and validation, and requirements change management. The most fundamental aspect of any requirements management activity is the need for communicating effectively.

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution

Mickle: While requirements are originally elicited within the first step of the product development lifecycle, it is important that we keep in mind that they are part of a bigger picture and that ownership of that bigger picture may vary. For example, the governance of requirements management processes may fall under your organization’s project or portfolio management office and can be controlled centrally or sometimes companies may choose to control that in a project-specific way. Just as there are multiple approaches to the ownership of requirements processes, there is no one-size-fits-all requirements management standard framework, and there are many standards that are proven to work. Examples include those defined in the system engineering body of knowledge or the business analyst body of knowledge or others listed here. I’d like to point out a great quote from Aristotle. “It is the mark of an educated mind to be able to entertain a thought without accepting it.”

I think this really represents the value for considering and taking in from multiple approaches within your organizations in order to drive for successful adaptation of standards. So now that we have level set on our definition of requirements management and have established that ownership and approach can vary from company to company and even from project to project, let’s move on to our main topic. Standardizing requirements management across the organization, a concept that can be entirely agnostic and universally beneficial no matter your product development structure or methodology.

Now there is no argument that requirements management has increased in prominence in the recent years and regardless of industry, it is largely no longer considered a nice to have for development, but rather an absolute necessity. Yet for most implementation details often remain ambiguous and therefore difficult to apply. We can be entirely committed to getting the requirements right with a little consensus on what getting the requirements right actually means. It can be hard to escape the manifestations of the Mobius strip and requirements management such as the statement requirements management is planned in the requirements management plan. This is where standardization arrives to save the day.

The standard becomes our requirements management plan versus being a separate effort for each product or project that detracts from effort that could be focused instead on development. There is a massive evidence demonstrating the benefits of defining, deploying, and enforcing requirements management standards for your organization. Those benefits include providing a framework for efficiency, predictability, repeatability, and a benchmark for improvement, better traceability, mitigation of risk, easier training and onboarding, and the elimination of unnecessary rework. Additionally, standardization allows organizations to leverage a diverse array of resources while maintaining consistent results, and it also provides transparency both in process and in work performed.

Just as the concept of reusing our requirements and leveraging the work that is done already, which is highly appealing, standardization of requirements management processes could be viewed as reusing our processes for managing requirements for repeatability of success. A strong case for standardization is illustrated in the quote, “Quality is free but only to those who are willing to pay heavily for it.” What you put in is what you get out. Valuable products are a result of high-quality inputs as well as high-quality processes. Even perfect requirements can’t withstand the damaging effects of a poor process. The pressure to reduce development time is only ever-increasing and standardization liberates development teams from worrying about the mechanics of development process and allows them to instead give their full focus to solution development.

Consider the quote from Lee Iacocca, the former CEO of Chrysler. “You can have brilliant ideas, but if you can’t get them across, your ideas won’t get you anywhere.” Now imagine a new tech company that is developing a revolutionary product, but everyone is trusted with their own process. This causes teams to work in silos. They develop strong processes but with little alignment. Eventually, their misinterpretation with one another can lead to bugs or the wrong things being developed, causing delays and extensive meetings to try and realign. What they can do is define a standard process for communicating and aligning on the requirements. And with a communication plan and regular alignment meetings, this will them to coordinate more effectively and have the same vision about what they’re building.

Earlier I stated that the most fundamental aspect of requirements management is the need to communicate effectively. If establishing requirements management standards seems like a heavy-handed approach, then just try polling a cross-section of your development team to define the difference between validation and verification, and maybe you’ll reconsider. It is critical that the foundations of your requirements management process are uniformly understood and applied across your organization in order to ensure quality with your final product. Now you might be wondering if the case for standardization is so strong, then why isn’t everyone doing it? This is a fair question and the rationale is likely due to previous challenges they have faced or perceived challenges. So let’s take a few minutes to explore what challenges teams may face in their efforts for standardization.

RELATED: Jama Connect Advisor™ Datasheet

Mickle: One common challenge is that we need to correct the misconception that standardization stifles creativity and response time. Standardization of requirements management is about removing the things that get in the way of your work rather than adding more work to your work. Other common misconceptions that face a standardization effort are that it’s too time-consuming or it’s too costly to implement or that it will disrupt development and progress. Given the overwhelming statistical correlation between poor requirements and project failure, it’s pretty hard to bear these arguments too much weight. The basic thought is that if you can make time to fix your problems, then you can definitely make time to plan so that those problems don’t occur.

Okay, so now we have discussed some of the benefits and the perceived challenges to a standardization of a requirements management approach. Let’s take a minute to reconsider how to move forward. The first step is the definition of a process framework. That process framework may include policies and standards, processes, procedures, training and tools, and please note that there’s a surprising amount of debate over the definitions for the hierarchy between the terms listed on this slide.

My intent is to illustrate the importance of establishing the framework not to prescribe the individual elements or their order. Over the past several years, Jama Software has developed comprehensive solution offerings in many industries. Those include a process, framework, definition, or the different verticals. We are constantly working on improving those frameworks as the industry changes, as new standards and maturity models are introduced, and as we learn from our customers and industry experts that we work very closely with.

Here is an example just to give you an idea of what a concept of a process framework would look like. Basically taking the foundations and breaking them into standards or policies and then into processes and supporting procedures. Here are some additional supporting elements that are extremely critical and must be taken into consideration. People, put the necessary resources in place to properly apply requirements management and recognize and develop the skills needed for the functions needed. Processes, it’s important to standardize and formalize processes at the project and product levels in order to ensure good requirements management practices are consistently applied.

WATCH THIS WEBINAR IN ITS ENTIRETY:
Standardizing Requirements Management Across the Organization

This image shows a set of stairs leading to an open door, which is meant to portray the question, "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.

Person standing in from of several DOORS in an attempt to find the right requirements management solution.

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: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution

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.

RELATED: Move to Jama Connect — A Modern Requirements Management Alternative to IBM DOORS

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 manpower 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: How to Overcome Organizational Barriers to Live Requirements Traceability

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.

This image shows the V Model of Live Traceability for product management.

Achieving Live Traceability™ with Jama Connect

Jama Software’s Live Traceability allows engineering teams to quickly and easily access the latest and most complete information for any requirement, no matter the stage of development or tools used. This real-time capability boosts productivity by ensuring teams work with the latest data and reduces risks like delays and defects by finding issues early. Research shows that issues found late can be much more expensive to fix, which is why Live Traceability is so important. Jama Connect helps overcome the limitations of older tools, leading to better results in many industries such as automotive, medical devices, aerospace & defense, and more. To learn more, visit Buyer’s Guide: Selecting a Requirements Management and Traceability Solution
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