Tag Archive for: Product Development & Management Page 8
Tag Archive for: Product Development & Management
In this blog, we recap a section of our Datasheet, “Jama Connect for Defense Systems: Integrate DoD MIL-STE-882E Risk Management with Systems Engineering” – Click HERE to read it in its entirety.
Integrate DoD MIL-STD-882E Risk Management with Systems Engineering Using Jama Connect® for Defense Systems
Align hardware and software systems safety using Jama Connect as your single, secure platform for requirements engineering, risk analysis, and test management.
Military departments and defense agencies must follow the MIL-STD-882E Standard Practice for System Safety to ensure safety throughout the entire lifecycle of military systems, including development, testing, production, use, and disposal.
A key challenge to compliance is the need to integrate risk management and collaboration into the systems engineering process systematically across system and fire protection safety and occupational and environmental health disciplines.
Relying on a manual, document-approach using Word and Excel to manage the MIL-STD-882E risk register is inefficient and error-prone. A more reliable and intelligent solution is Jama Connect for Defense Systems which provides a single, secure platform for requirements, risk, and test management throughout the development lifecycle. It enables alignment of software and hardware development teams to achieve speed and quality, auto-detection of safety and environmental hazards and risks for early identification and mitigation, and robust collaboration and reviews involving internal teams, supply chain partners and government agencies.
Align the hardware and software systems’ team safety activities. Manage risk management for hardware and software system safety in Jama Connect which provides a single source of truth that integrates with best-of-breed software tools chosen by various teams.
Identify hazards and risks for early mitigation. Teams benefit from a single system and integrated data model for architecture, hazard assessment, analysis, safety requirements, and tests.
Accelerate development by streamlining collaboration and reviews. Avoid development delays by making it easy for internal and external teams to participate in MIL-STD-882E activities with Jama Connect’s Review Center and collaboration intuitive capabilities.
Get the most out of your requirements management and traceability solution. Use the same Jama Connect solution for managing and documenting your product requirements AND your MIL-STD-882E activities to maximize your return on investment from Jama Connect.
By leveraging Jama Connect, DoD systems development teams can significantly improve their efficiency, reduce risk, enhance safety, and expedite development while maintaining the highest standards of regulatory compliance with MIL-STD- 882E, contract requirements, defense data standards, interface standards, design criteria standards, manufacturing process standards, standard practices, and test method standards.
In this blog, we recap our webinar, “Key Systems Engineering Skills: Critical Thinking and Problem Framing” – Click HERE to watch it in its entirety.
Key Systems Engineering Skills: Critical Thinking and Problem Framing
Elevate your team’s success by exploring the role of critical thinking in a system engineering competency model.
In this insightful session, Chris Unger, Retired GE Healthcare Chief Systems Engineering Officer and Principal at PracticalSE LLC, and Vincent Balgos, Director of Medical Device Solutions at Jama Software®, discuss how critical thinking and decision-making skills are integral to systems engineering.
In this insightful session, you will learn:
Explore the vital role of critical thinking and decision-making in systems engineering.
Learn practical techniques for decision framing and closure.
Gain insight on how systems engineers should manage design decisions on a project.
See a simple model of how and when to engage with stakeholders in design decisions.
Below is an abbreviated transcript of our webinar.
Chris Unger: We’re going to talk today about a follow-up to the last webinar, where I’m going to talk about some of the most important systems engineering skills, critical thinking, and problem framing. So, how do skills in general, and soft skills, fit into improving systems engineering? So, in prior talks, I’ve suggested you keep your processes very simple but make them effective, and that’s easy to say but hard to do. That means you have to understand the system of the SE processes, how they connect, and where the diminishing value of the processes, the source process heading off, happens. As an example, a topic could be a technical risk, or it could be a trade-off between different possible solutions. So, we want to understand how those to the risk management and the decision process interact.
In order to do that, the best systems engineers have to have really good judgment. In addition, we have to influence people. Being simplistic, hardware and software engineers design things, things do what they’re told. I know it’s oversimplified, but our deliverables are instructions on how the software and hardware engineers do things. So, the best systems engineers here have an area of depth that they’re experts in, so they bring some technical credibility. They have systems of breadth, they understand all the systems processes and how they interact, and they have great interpersonal skills. Today I’m going to focus on how you achieve a balanced and optimized design, how you focus on your cost versus risk, and doing that through basically decision making.
So, first I want to talk about the Helix Model. So, the Helix Project was a project funded by the government and, the US government, and their concern was for big aerospace and NASA projects you tend to produce a major, billion-dollar development every 10 years, and then you do 10 years of support. So, people often move on. They were worried about how you create the truly brilliant leader systems engineers from a team that may be a little bit sparse. They developed this model up here in the front and simplistically, you start with things you learn in school, how to do good mechanical engineering, electrical engineering, and software engineering techniques. You then go into an organization, and so you spend the first five years learning about your company. Things like, well, if you’re going to be doing a say glucose monitor, what does blood chemistry look like? What does a sensor look like? What’s a workflow? So, you become a good organization-specific mechanical engineer.
Then you learn about lifecycle. How do you go from womb to tomb, from customer needs to disposal and disposition with all the regulations across the world in terms of chemical safety? So, after five, maybe 10 years, you understand your domain, you understand the lifecycle and you understand your technology. What differentiates after that? What they found was the skills on the bottom half of this page, the Systems Mindset, so big picture thinking, and paradoxical mindset. You’ve all heard that joke about fast, good and cheap, pick two of the three. Well, that’s the world in which systems engineers live. We make trade-offs between things that are inherently conflicting. The other thing is, we’ve got to make decisions quickly, so you’ve got to have a flexible comfort zone. You’ve got to be willing to wait till you have the critical information but make a decision without all the information you want.
Unger: In terms of the middle column, Interpersonal Skills, just the obvious stuff as I mentioned. You’ve got to influence the other engineers to make a good decision. Then finally here in Technical Leadership, balanced decision-making, and risk-taking. So, I had a general manager one time say, “We’re in the business of managing risks, not avoiding risks.” The least-risk program is also a boring one, but you also don’t want to take moonshots and everything. So, you really want to balance. It’s another case of a paradoxical mindset. Balance risk-taking with hitting a schedule predictably. So, these are the kinds of skills that really differentiate as systems engineering leaders, 10 to 15 years into your career. I’m going to talk more about these, decision-making, stakeholder management, and barrier-breaking.
So, I put together a very simple Systems Engineering Competency Model. I started with the NASA handbook and the NASA lifecycle. I simplified it, into that they had scope and requirements management separated, and I actually agree with those being different. But in reality, on the size of programs that we typically implemented, the people who did one typically did the other. Same thing, the architecture and the design, those were typically the same people. So, you have the upfront design, you have implementation. So, managing the subsystems actually do the implementation of what the design asks them to do, and you integrate it, such that you find your defects early. Then you manage all the lifecycle, the serviceability, manufacturability, disposability, and all the “ilities.”
Then leadership, obviously, there the interpersonal skills. This was developed for GE Healthcare, so I just picked it from our existing leadership skillset and I simplified it. What you’ll notice here is I put down at the bottom, critical thinking, as a technical skill. For many executives, and for other functional engineers, critical thinking is important, but as I mentioned, since we deliver instructions and designs to other engineers, framing decisions, taking vague things from product management and marketing, and turning them into clearer problems or functions to solve, I consider that a core technical excellence of systems engineering. But that’s vague. How do I actually measure that? So, I came up with this fairly simple set of observable behaviors. So, first of all, framing problems takes an ambiguous problem identifies the critical stakeholders, and turns them into a clear problem a more junior engineer can solve.
So, first, let’s talk about framing the problem. Even an entry-level person has to be able to understand a problem that’s been framed for them. But as you get to more senior people, the 10 to 15-year level, you have to be able to frame a complex problem, see around corners, use foresight to sort out essentials from the detail, and identify risks and emergent behavior that need to be incorporated in the decision, that other engineers might not see. Even at the strategist level, you can take a complex and ambiguous problem clarify the ambiguity, and turn it into simply just a complex and interconnected problem.
So, if we’re talking about maybe the 10 to 15-year-old person, not the most senior executives, you’ll be able to take a complex problem, identify ahead of time problems other people don’t see, and capture that. Balance cost, schedule, technical risk, and team capabilities, and make a trade-off based on sound evidence and data. Balance your intuition, when you don’t have all the data with waiting and gathering data where you need it. Then finally, making the decision is maybe the easy part. You have to make sure the team follows your leadership. Take accountability for making the right decisions, delegate where you can, and then ensure that the entire team buys into the decisions that the team or you have made. So, that’s the theory.
Unger: Let’s talk about how we manage design decisions. First of all, why? Why is this a critical skill? By identifying the critical design decisions, it allows the team to focus on the most important thing, and separate out the core from the distractions. It helps teams identify work items. So, for example, one time when I was working with the ultrasound team in Japan, we had a bunch of really experienced engineers and they were working on a new ultrasound probe. It had moved an active component into the probe and there was a thermal issue. They were talking in Japanese for about five, 10 minutes when I was asked to frame the problem and I said, “Yeah, you’re talking too fast and too much. This is not that easy. Come back to me and tell me what you’re actually doing.”
They were figuring out how to measure the thermal properties in the lab. I said, “Well, imagine you had a probe that was safe, with maybe 39°C, but that was uncomfortable to handle. Have you worked with the application people on how much value? If you spent $50 more and took the temperature down by 1°C, would that be worth a trade-off? The team, “Oh, that’s interesting.” They were actually focused on the technical feasibility, not the real market and customer acceptance problem. So, by doing this upfront, you can make sure that you have a complete work process for the team. Then once you’ve made the decision, it minimizes rework by making sure the decisions stay closed.
Now, this decision list and prioritization should start early. It would be comfortable to wait until you know everything, but that’s too late. So, it’s a living document. Don’t wait to get started until you have enough information to make a good plan. Start with what you know, and then build out as you continue. So, one of the first things I talk about is, what is a decision? As an example, I’ve had teams come to me saying, “The operating system selection is a decision.” It’s like, “No. It’s actually not typical. It’s typically a collection of decisions.” So, I draw this little arrow here. It’s basically a decision is a point in which you select between different paths going forward and you pick one way versus another. So, deciding whether to include a stretch item in scope or not is a decision. Deciding between very specific designs and implementing a feature is a decision. Setting a critical to-quality parameter or balancing between different parameters, so cost versus reliability or cost versus performance, is a decision.
In this blog, we’ll recap a section of our recent Expert Perspectives video, “A Method to Asses Benefit-Risk More Objectively for Healthcare Applications” – Click HERE to watch it in it entirety.
Expert Perspectives: A Method to Assess Benefit-Risk More Objectively for Healthcare Applications
Welcome to our Expert Perspectives Series, where we showcase insights from leading experts in complex product, systems, and software development. Covering industries from medical devices to aerospace and defense, we feature thought leaders who are shaping the future of their fields.
In the complex world of healthcare, evaluating benefit-risk is crucial to successful product development and patient outcomes. Our expert perspectives video, “A Method to Assess Benefit-Risk More Objectively for Healthcare Applications,” offers actionable insights for healthcare innovators aiming to meet rigorous regulatory requirements while ensuring patient safety and efficacy.
In this episode of Expert Perspectives, Richard Matt breaks down a streamlined, objective method for benefit-risk analysis. He explores a structured frameworks and data-driven approach that help teams make balanced decisions, mitigate risks early, and stay compliant with regulatory standards, including FDA and ISO guidelines.
This patent-pending approach helps organizations navigate challenges, foster innovation, and ultimately bring safer, more effective healthcare solutions to market.
Below is a preview of our interview. Click HERE to watch it in its entirety.
Kenzie Jonsson: Welcome to our expert perspective series where we showcase insights from leading experts in complex product, systems, and software development. Covering industries from medical devices to aerospace and defense, we feature thought leaders who are shaping the future in their fields. I’m Kenzie, your host, and today, I’m excited to welcome Richard Matt. Formerly educated in mechanical, electrical, and software engineering and mathematics, Richard has more than thirty years of experience in product development and product remediation. Richard has worked with everyone from Honeywell to Pfizer and is now a renowned risk management consultant. Today, Richard will be speaking with us about his patent pending method to assess benefit-risk more objectively in health care. Without further ado, I’d like to welcome Richard Matt.
Richard Matt: Hello. My name is Richard Matt, and I’m delighted to be speaking with you about our general solution to the problem of assessing whether the benefit of a medical action will outweigh its risk. I’ll start my presentation by saying a few words about my background and how this background led to the benefit-risk method you’ll be seeing in the presentation.
To understand my background, it really helps to go back to the first job I got out of undergraduate school. I graduated with a degree in mechanical engineering and an emphasis in fluid flow. And my first job was in the aerospace industry at Arnold Engineering Development Center, at a wind tunnel that Baron von Braun designed. I worked there as a project manager, coordinating various departments with the needs of a client who brought models to be tested. These are pictures of the ADC’s transonic wind tunnel with its twenty-foot by forty-foot long test section that consumes over a quarter million horsepower when running flat out. Those dots in the walls are holes, and a slight suction would pull the out on the outside of the wall to suck the air’s boundary layer through the holes. So a flight vehicle appeared more closely to match its flight air characteristics in free air. It was amazing place to work.
We could talk about aerodynamic issues and thermodynamic issues like why nitrogen condenses out of the air at mach speeds above six or why every jet fighter in every country’s air force has a maximum speed of about mach three and a half. But to stay on the topic of benefit-risk, the reason or my intro to this, the reason I was brought this up was that I saw here firsthand the long looping iterations that came from different technical specialties, each approaching the same problem from the respective of their technical specialty. I found it very frustrating and the, following analogy very apt, after getting, so each of our technical specialties would look at the same problem, the elephant from their own view. And I found myself getting frustrated with my electrical and software engineering coworkers, that they didn’t understand what I was talking about, but I knew realized soon I didn’t understand what they were talking about either.
So I decided I wanted to become part of the solution to that problem by going back to graduate school and getting myself rounded out and my education so I could talk to these folks from their perspective also. So I went back to grad after mechanical and undergraduate, went back to graduate school in electrical and mathematics and picked up enough software. I started teaching, programming also in college. I developed there a solution for the robot arms in those wind tunnels to to control a robot arm for every possible one, two, or three rotational degree of freedom arm, and that was my graduate thesis. After I completed my thesis, I felt empowered to start, my work doing going wherever I wanted doing whatever I wanted to do and realized that if I wanted to do anything significant, it would take many years, and I decided to focus on teamwork. Does that sound pretty good?
Matt: My ability to work across technical boundaries enabled me to bring exceptional products to the market. For instance, I brought an Internet of Thing (IoT) device to the market during the nineteen nineties before Internet of Things was a thing. And I rapidly advanced while I was working as a VP of engineering at a boutique design firm in the Silicon Valley. These are a few of the clients that I had, through the work that I’ve done over the years.
And, the combination of the breadth of my formal training and my system perspective for solving problems has really helped me work across continue to work across boundaries, so that I’ve worked for companies to help them establish their pro product requirements, trace requirements, do V and V work. I’ve done a lot of post-market surveillance work. I established internal audit programs. I’ve been the lead auditee when my firm is audited. Done had significant success accelerating product development and has been on work on. So mixed in with all of these works, I special I started specializing into risk management as consulting focus versus something I just did normally during development.
And since the defense of a patent requires notice, I’ll mention that the material here is being pursued on the patent, and, would like to talk with anyone who finds this interesting to pursue after you’ve learned about it. So let me start my presentation on benefit risk analysis by talking about how important it is to all branches of medicine and the many problems we have implementing it. The solution I’m gonna come up with, I’ll just outline here briefly so you can follow as we’re going through the presentation. I’m gonna first establish a single and much more objective metric to measure benefit and risk than people traditionally use. I’ll be accumulating overall benefit and risk with sets of metric values from this first metric. And finally, we’ll show how to draw a conclusion from the overall benefits and risk measurements of which is bigger benefit or risk.
So in terms of importance, historically, benefit-risk has been with medicine for millennia. It’s a basic tenant to all of medicine. The first do no harm goes all the way back to the quarter of Hammurabi 2,000 BC, and it legally required physicians to think not just about how they can help patients with treatment or what harm they might cause to treatment and making sure that the balance of those two favor the patient is very much the benefit-risk balance that we look at today. The result we’re gonna talk about is gonna be used everywhere throughout medicine with devices, with drugs, with biologics, even with clinical trials.
So is that fundamental cross medicine? How it’s used currently?
If you are in one of the ways developing new products, benefit-risk determinations have to be used in clinical trials to show that they’re ethical to perform, that we’re not putting people in danger needlessly. Benefit-risk determinations are the final gate before a new product is released for use to patients. And I have a quote here from a paper put out by AstraZeneca saying the benefit-risk determination is the Apex deliverable of any r and d organization. There’s a lot of truth to that. It’s the final thing that’s being put together to justify a product’s release. And so it has a very important role here for FDA and has a very important role for pretty much the regulatory structure of every country, including the EU.
Matt: In terms of creating a quality system, every medical company is required to have one. Benefit-risk determinations are used to assess a company’s quality system. This is per the FDA notice about factors on benefit-risk analysis. When regulators are evaluating company’s quality system, they’ll use benefit-risk to determine if nothing should be done, if a product should be redesigned, if they should take legal actions against a company of a range of possibilities from replacing things in the field to stopping products from being shipped. It’s also a key in favorite target for product liability lawsuits, because of how subjective it is, and we’ll get to that in a moment. It can also be used for legal actions against officers. So benefit risk is a really foundational concept for getting products out and keeping products out and keeping companies running well. Just a bit of historical perspective of medical documentation and development. We have here, I cited four different provisions of the laws, regarding medical devices in the United States. This is a small sampling.
The point I’m trying to make here is that each of these summaries of the laws discuss continually evolving, continually growing, more rigorous standards for evidence, more detailed requests for information from the regulators to the instrumentation development companies to the product development companies. So first, medical products are heavily regulated. We have the trend of increasing analysis and rigor. Per ISO 142471, and this is an application standard that is highly respected in the medical device field. A decision as to whether risks are outweighed with benefits is essentially a matter of judgment by experienced and knowledgeable individuals.
And this is our current state of the art.
Not that everybody does it this way, but this is the most common method of performing benefit-risk analysis. And benefit-risk analysis by this method, has a lot of problems because it’s based on the judgment and it’s based on individuals, and both of those can change with different settings. That’s why it’s a favorite point of attack for product liability lawsuits.
This quote was true in 1976, when medical devices were put under FDA regulation, but significantly remains unchanged nearly fifty years laters. Benefit-risk determinations are an aberration and that unlike the rest of medicine, they have not improved over time. They’ve remained a judgment by a group of individuals. In, twenty eighteen, FDA was, approached by congress to set a goal for itself of increasing the clarity, transparency, and consistency of benefit risk assessments from the FDA.
This was in human drug review as the subject, and the issue was that various drug companies had gotten very frustrated with the FDA for disagreeing with their assessments of what benefit-risk should look like. And to repeat again, when you have a group of individuals making a judgment, that’s gonna lead to inconsistencies because both the group and their own individual judgment will vary from one situation to the next. I have another, quote here from the article from AstraZeneca. The field of formal and structured benefit-risk assessments is relatively new.
Matt: Over the last twenty years, there’s still a lack of consistent operating detail in terms of best practice by sponsors and health authorities. So this is an understatement, but a true statement. We have had a lot of increasing effort over the last few years because if people are dissatisfied with the state of benefit-risk assessments, they want to do better than this judgment approach. And so there have been a plethora of new methods developed. I’ve found one survey here that summarize fifty different methods just to give you an idea of how many attempts there are. And I went through those fifty methods.
The other thing that’s interesting to see is the FDA’s attempt to clarify benefit-risk assessments. I have here five guidance documents from the FTA, and I would put forth the proposition that anytime you need five temps five attempts to explain something, it means you didn’t understand the thing well in the first place or failing about a bit trying to get it done right. I think this is also held up by the drug companies, pressure on congress to get FDA to improve their clarity and consistency of benefit-risk assessments.
So here’s the, fifty methods that I found in one study of benefit-risk assessments. They have them grouped into, a framework, metrics, estimate techniques, and utility surveys. These are the fifty different methods, and I’ve gone through each one of them. And they all have fundamental problems. They, I’m going through them a bit slowly. Like, here’s one, from the FDA, another benefit risk assessment. Health-adjusted life years are one of the few that uses the same metric for benefit and risk. Number needed to treat is a very popular indication for a single characteristic, but you can’t integrate that across the many factors that needed to do benefit-risk assessment.
And so we’ve gone down the rest of these, methods. If I group these fifty methods by how they accumulate risk, I get a rather useful collection. Most of the methods do not consider all the risk-benefit factors for benefit-risk situation. They will pick on just one factor. And you can’t combine the factors with themselves or with others. It’s simply looking at one factor by itself. So it’s an extremely narrow view of benefit-risk for most of these. The few methods that do look at all the risk-benefit factors, most of them start with what I call the judgment method, where you’re forced to distill all the factors down to the most significant few, only four maybe four to seven methods, four to seven factors.
So either the methods consider only one type of, one factor at a time, or they force you to throw away most of the methods and consider maybe four or seven factors is the second method. The third method is they assign numbers to the factors, they’ll add the factors together, and they’ll divide the benefit sum by the risk sum. And if the division is bigger than one, they’ll say the benefit’s bigger than the risk. And if the division is less than one, they’ll say the risk is bigger than the benefit.
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.
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.
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.
In this blog, we recap our recent webinar, “Achieving ASPICE 4.0: Overcoming Key Challenges” – Click HERE to watch the entire thing.
Achieving ASPICE 4.0: Overcoming Key Challenges
The path to ASPICE 4.0 compliance can be complex. Gaining a deeper understanding of traceability requirements, process consistency, verification criteria, and special characteristics is essential to improving your development processes and achieving compliance.
How to implement robust traceability methods for ASPICE 4.0
Techniques to maintain consistency across processes
How to define and implement effective verification criteria
The significance of special characteristics in automotive software development
BELOW IS AN ABBREVIATED SECTION OF THIS TRANSCRIPT
Ronald Melster: Thank you for the warm introduction and thank you very much for inviting me to today’s webinar. I’m excited to be here with all of you to discuss the challenges and updates that we encounter in the latest version of the ASPICE standard. So let’s get started and explore what these changes mean to our industry and how we can best adapt to them. Why are we doing this webinar? The release of ASPICE 4.0 has brought new requirements and expectations and created some confusion.
In this session, we will discuss four key areas of change that are especially challenging and potentially misleading. This webinar is designed to clarify these updates and help you understand the implications. Here are the four changes I will talk about. First, we will look at the changes on how to connect elements across the V-model. Then we move on to consistency, as there is an increased emphasis on maintaining consistency across work products. I would share how this topic impacts your daily work. Then we discuss our favorite topic, the verification criteria. The base practice and the work product for the verification criteria have been removed from the standard. The question is if the need for a verification criteria is gone as well. And the last change I will talk about today are the special characteristics. This new concept was introduced with PAM for 0.0. I will explain why this is necessary and how it can be implemented.
Some of you may know me already, but for those of you who don’t yet, let me introduce myself briefly. I’m Ronald Melster or simply Ron in the automotive world. As one of Europe’s longest-serving ASPICE assessors, competent since 2005 and now principle, I’ve dedicated my career to guiding organizations through process improvements, always striving to balance structure with pragmatism. After my early work in software engineering and quality assurance at Fraunhofer, where I researched on knowledge management and 3D visualizations, I entered the automotive industry in the year 2000. Over the years, I found that meaningful assessments involve much more than simply rating. It’s about helping people to understand the why behind each process. Today, I coach companies and teams through their ASPICE improvement projects, working with companies like Bosch, Audi, and Porsche to help them reach the capability levels one, two, and even three. Together we are shaping more effective motivated teams that understand not just the how, but the purpose behind the ASPICE standard.
Melster: The first topic I will talk about is traceability. A very common misunderstanding is that a trace must be a direct link to click on, and then I end up at the target element. This was never the expectation and has been clarified with PAM 4.0 in the respective VDA guidelines. Before I run you through the possible traceability techniques, let’s discuss why traceability is essential for successful project management and product development, starting with the impact analysis of change requests. Traceability allows us to clearly track the origin and implications of each change request. By establishing traces, we can see where a change affects other components, documents, or requirements. This is particularly crucial for ensuring that safety and security requirements are met consistently. Next, we have root cause analysis of problems. With traceability, we can identify not only the immediate issue, but also trace it back to the process step where it was introduced.
This can help to prevent similar issues in future cycles by allowing us to adjust processes or documentation at the root cause level, instead of merely fixing surface-level symptoms. And traceability can help to show the completeness of work products. Traceability helps us to verify that all necessary parts of the system are complete and that each requirement has been successfully implemented. This is especially critical in safety and security cases, where missing traces could mean non-compliance or safety issues, or vulnerabilities.
Finally, traceability enables progress tracking. By using trace links, we have a clear and consistent overview of how far along each requirement is in the process. This enables project managers to track progress more accurately. In essence, traceability ties every piece of the project together, ensuring that we understand the why and how behind each element, and helping us maintain quality, safety, and security. Let’s have a look at the first traceability technique, which are naming conventions. The idea is to use the name of one artifact to identify another artifact. For example, the name of the unit, which is defined as part of the detail design, is used to identify the source code file or the function in the source code. Of course, the naming convention has to be described in a central document to make it available to everyone in the project.
Our next traceability technique are editorial references. This method uses the same ID as a text reference across documents that need to be connected. It’s a straightforward approach, often called traceability light, because it doesn’t require complex tools at the start, just the ability to update text in both documents. The question remains how to trace back. There are a few approaches that we can take. The first one is contextual searching. In the traceability strategy, we can specify how to search within the databases or text documents for these IDs, allowing to navigate across documents. Another method is to create a mapping table serving as a lookup tool that aligns IDs from one document to another. Finally, we can use tools like Rectify, that scan the text documents and provide statistics about the coverage of the traces.
Melster: Our third traceability technique is hyperlinking. This approach creates direct connections between tools, making it easier to trace items across different systems. With hyperlinking, each item has a direct link embedded in the document or tool, so rather than manually searching for information, you simply click the hyperlink and it brings you straight to the related item in another tool or document. Our fourth and last technique for establishing traceability are tool links. Many modern tools can create direct links or traces between different elements or requirements, streamlining the process of tracking dependencies and relationships across the project. Tool links often add semantic context to each trace, such as implements or is implemented by. This provides clarity on how the elements are related, making it easier to understand the purpose behind each link. One powerful feature these tools provide are suspect links. These are automated flags that notify us when a linked requirement or element is modified. This way we can quickly perform impact analysis and assess whether changes in one area affect other linked elements, helping us manage risks and ensure consistency across the project.
Another change that comes with PAM 4.0 are clusters of elements. This means that instead of establishing links from one single element to another single element, we can now create traceability links at a higher level. For example, we can trace groups of requirements that share common goals, we can trace two architectural elements within a particular subsystem, or we can trace software units associated with a specific functionality. This flexibility allows us to handle complex systems more efficiently, as we are not restricted to tracing every single element individually. However, this comes with more responsibility, as it is more important to remember that the level of traceability must still be appropriate for the product, and it is more complicated to provide the statistics for coverage, because we cannot just simply count items which are connected. And finally, the justification for consistency becomes much more important. For example, do the test cases which are linked to a cluster of requirements completely cover this cluster, or is there something missing?
Another important change I would like to highlight is that it’s now possible to trace from stakeholder requirements on SYS.1 directly to software requirements SW.1. There is no need to link via the system requirements to the system architecture to the software requirements anymore, if the stakeholder requirements are specific enough and have no impact on any other part of the system other than the software. This approach is often used in software-only projects, where the stakeholder requirements are already very specific. However, in system projects, the impact on the system must be considered in a comprehensive way. The same approach can be used for hardware requirements and mechanical requirements as well.
Another big change from PAM 3.1 to 4.0 is that there’s now a combined base practice for traceability and consistency. In ASPICE PAM versions 2.5 and earlier, we used to assess consistency and traceability together in one based practice. In PAM 3.1, they were split into two based practices for traceability and consistency, and VDA guidelines define the strong relationship between these two base practices, because these two concepts are inherently connected. To explain why, let’s consider this. Consistency depends on having effective traceability. Without solid traceability between work products, we are not able to guarantee that the elements align correctly throughout the development process. For example, if requirements are not traced to elements of the architecture or test cases, showing the evidence for consistency between these artifacts becomes nearly impossible. Therefore, checking for both consistency and traceability as a unified practice makes sense, as it ensures that all pieces are in sync and meet the intended quality standards.
Melster: Let’s have a closer look at an example for consistency, which base practice or base practices in SW.1. Software requirements analysis deal with consistency. Obviously, base practice five directly addresses consistency by requiring us to establish bi-directional traceability between software requirements and the system architecture, and software requirements and system requirements. This base practice ensures that each software requirement is directly aligned with the system architecture and linked back to the respective system requirements. The idea here is to maintain clear connections, ensuring that the requirements are accurately reflected across all levels of design. The second base practice, which deals with consistency is base practice number one, it’s a little bit hidden in node two. This node defines characteristics for requirements like verifiability, comprehensibility, freedom form implementation and surprise surprise, not contradicting other requirements, which is the synonym for consistency.
So we have two types of consistency in software requirements, external and internal. External consistency ensures alignment between software requirements, system requirements, and the elements of the system architecture. Each of these checks involves typically two different documents and it compares different artifacts, software requirements with system requirements, and software requirements with the elements of the system architecture. This is why I call this consistency, external consistency. And we have to fulfill BP-1, which can be done checking for internal consistency. For SW.1, that means software requirements are checked against other software requirements. This activity is essential for ensuring the integrity of our requirements. The primary goal of this verification is to ensure that the requirements do not contradict each other. There are many references and standards such as ISO IEEE 29148, ISO 26262-8, and the INCOSE Guide for Writing Requirements. They have one characteristic in common, that requirements shall not contradict each other.
This is one of my favorite topics. I have had discussions about this for years. Do we need an explicit verification criteria, yes or no? Now the base practice and the work product have been removed. What does this mean? This removal of the explicit verification criteria requirement in ASPICE PAM 4.0 marks a significant change, streamlining the base practices for evidence of verifiability. While previous versions of ASPICE emphasized having a separate verification criteria as a formal step, this requirement has been softened in PAM 4.0. However, demonstrating variability remains a crucial practice as we have seen. Projects must still make sure that there’s an evidence that each requirement is verifiable, though it’s no longer mandatory to document a distinct verification criteria for each requirement. This adjustment suggests that verification is evolving in focus. Instead of a string and isolated criteria, there are other ways to ensure the verifiability, performing review by the test team for example.
Melster: This ensures that requirements can be tested or writing simpler requirements if this is possible, of course, but for straightforward requirements, there’s no need to have an explicit verification criteria. However, for more complex system requirements, writing a verification criteria might still be recommended, so writing a verification criteria has become a best practice instead of a base practice. The decision and the responsibility for justifying this decision lies with the development projects now. And the last topic I would like to talk about are special characteristics. What are they and where do they come from? These special characteristics are often identified through structured risk assessments, such as FMEA, failure mode and effects analysis, which is commonly used to prioritize potential failure risks. Or HARA, hazard analysis and risk assessment, which helps identify safety critical elements. And of course TARA, threat analysis and risk assessment, which focuses on cyber security and vulnerabilities.
In terms of application standards, like IATF 16949, specify that these special characteristics should be integrated into the system architecture, as well into the hardware design. This ensures that all key attributes affecting system safety and compliance are identified from the start. An essential part of managing special characteristics is ensuring that they are verifiable. According to VDA volume one, special characteristics must be documented in a way, so that they can be reviewed and validated. This verifiability ensures that all compliance and safety requirements are traceable and systematically implemented. This concludes our little journey into the changes and challenges with PAM 4.0. If you want to learn about RSPICE, consider joining the Melster Academy or book a personal meeting with me to find out how you can elevate your ASPICE expertise. I am looking forward to support your journey. Thank you very much for your attention. I will now hand it back to Sathiya and I will be happy to answer any questions you may have at the end of the webinar.
In this blog, we recap a section of our eBook, “The Clear Choice: Why Jama Connect Surpasses Codebeamer for Requirements Management and End-to-End Traceability” – Click HERE to read it in its entirety.
The Clear Choice: Why Jama Connect® Surpasses Codebeamer for Requirements Management and End-to-End Traceability
To adapt to increasing industry challenges and complexities, innovative organizations are now requiring best-in-class software to scale development, reduce risk, save time, and ensure compliance to quality, safety, and security regulations.
As organizations strive to deliver innovative products while navigating regulatory requirements, the tools they use for requirements management and traceability can make or break their success. This eBook is designed to help you understand the critical differences between Jama Connect® and Codebeamer, two leading requirements management solutions, so you can make an informed decision.
The Requirements Sector
The landscape of requirements management has undergone significant transformation. Traditional tools (like IBM® DOORS®) which once dominated the market, are now considered outdated. These legacy systems often lack the flexibility, ease of use, and integration capabilities required by modern teams. As a result, organizations are turning to modern solutions like Jama Connect that are built to meet the needs of today’s dynamic development environments.
Why Jama Connect?
Jama Connect stands out as a leading requirements management solution because it is designed with the user in mind. Its modern, user-friendly interface, combined with powerful features like comprehensive traceability and real-time collaboration, ensures that teams can manage requirements and risks effectively throughout the product, systems, and software lifecycle. Jama Connect also emphasizes customer success, offering expert support and training to help teams maximize their investment. Ease of use, rapid deployment, pre-configured well-documented industry frameworks, and in-house subject matter experts provide the fastest time-to-value/ROI without sacrificing quality or safety.
The Clear Advantages of Jama Connect Over Codebeamer
If you’re comparing Jama Connect to Codebeamer, one thing is clear — Jama Connect is the only purpose-built requirements management platform that delivers Live TraceabilityTM which allows engineering and other 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. In addition, Jama Connect accelerates your product, systems, and software development by managing user needs and product information across the end-to-end development lifecycle.
Only Jama Connect Delivers Live Traceability™ Across Best-of-Breed Tools
Other vendors lock you into inferior platforms. Only Jama Connect seamlessly integrates with your tools of choice across engineering teams. Only Jama Connect can manage the state of development across all integrated teams and tools. Jama Connect’s unique and industry-specific Traceability Information Models define the relationships and expected behavior across teams and tools.
Our customers consistently tell us that they chose Jama Connect over Codebeamer for the following reasons:
1. Ease of Use and High Adoptability
Jama Connect’s intuitive design and user-friendly interface make it easy for teams to adopt and use. Unlike Codebeamer, which can be complex and challenging for new users, Jama Connect ensures that teams can start managing requirements effectively with minimal training. Users insist on a requirements management and traceability solution that is easy to use so that both internal and external stakeholders can efficiently access, share, and review information in a single source of truth, increasing and speeding up the adoption across teams for a better ROI.
The ease-of-use is not only imperative for users but also for administrators. Jama Connect offers an intuitive and user-friendly administration interface that enables admins to adapt the tool to their organization’s needs without having to learn overcomplicated configuration settings and concepts.
2. Modern Integration and Collaboration Capabilities
Jama Connect provides comprehensive traceability and impact analysis, enabling teams to manage change effectively and reduce the risk of errors. The platform seamlessly integrates with other best-of-breed tools (including Jira and Azure DevOps) in the development ecosystem, ensuring that teams can work efficiently without having to change their other development tools. In contrast, Codebeamer focuses on working solely with other PTC tools and its own limited application lifecycle management (ALM) capabilities.
Modern product and software development requires optimal real-time collaboration between stakeholders. Jama Connect provides an enhanced collaboration experience with its communication streams and advanced Review Center, enabling both internal and external stakeholders with the capabilities to perform formal and iterative reviews.
3. Intelligent Engineering Management
Jama Connect empowers Intelligent Engineering Management by addressing a critical challenge faced by engineering and product development organizations: the lack of real-time KPIs and metrics during development. This gap often leads to delays, budget overruns, and product defects or recalls. Jama Connect uniquely transforms traceability into a measurable instrument, enabling teams to track real-time metrics and KPIs throughout the product development process. By providing a comprehensive overview of project progress and aligning it with required processes, teams can identify gaps early, mitigate risks, and avoid missed requirements. With its Live Traceability™ and integrations with other best-in-breed engineering tools, Jama Connect ensures that both internal and external data are seamlessly managed, driving informed decision-making and on-time project delivery.
4. Strong Customer Support
We know that our customers need a support team that makes them a priority. That’s why Jama Connect offers unparalleled customer support (including 24/7 support for any production outages), with dedicated customer success teams that work closely with you to ensure you achieve your goals. In contrast, Codebeamer’s support can be limited, making it difficult for your teams to get the help they need when they need it.
5. Scalable and Flexible
Jama Connect is highly adaptable, making it suitable for a wide range of industries and project sizes. Whether your organization is in automotive, aerospace, medical devices, or another industry, Jama Connect can be tailored to meet your specific needs, often getting you up-and-running quickly with custombuilt data frameworks to satisfy your industries regulations and best practices. Additionally, the platform offers flexible deployment options, including cloud and self-hosted, giving you the freedom to choose the best setup for your organization.
6. Fastest Time to Market/ROI
Deploy Jama Connect’s easy-to-use interface in weeks, not months, with easy updates and high performance. Preconfigured frameworks are built-in to satisfy industry regulations and help teams ease the path to compliance, along with in-house industry focused subject-matter experts and exceptional customer support.
7. Lowest Total Cost of Ownership
With simple and straightforward administration and no need for custom scripting or continuous updating, Jama Connect has the lowest total cost of ownership in comparison to Codebeamer. Jama Connect scales easily without big infrastructure investment, and with unlimited no-cost access for extended internal/external stakeholders, all team members can be involved with additional costs.
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.
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.
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.
This post was originally published on January 7, 2022.
Requirements Traceability – How to Go Live
Requirements traceability is required by many industry standards to ensure product quality and safety. The industry standards are based on decades of progress made in systems and quality engineering research with requirements traceability at the core. Benefits from requirements traceability are achieved if and only if traceability is used as a tool during the product development process. These benefits include greatly reduced or eliminated delays, defects, cost overruns, and rework. Here is an overview of the best practice approach to achieve Live Traceability™.
Live Traceability vs. After-the-fact Traceability
Let’s start with some definitions to make sure we are all on the same page. Requirement traceability is defined as tracking the development progress of product requirements from definition and design through development, testing, verification, and validation. There are two forms of requirement traceability: after-the-fact traceability and Live Traceability.
After-the-fact traceability occurs after the product has been developed and is typically a highly manual effort to try and re-create artifacts to demonstrate traceability that should have occurred during the development process but did not. This effort is undertaken solely for complying with industry standards and satisfying auditor requests for demonstration of process maturity.
Live Traceability occurs in real time as the product development process progresses to improve overall productivity (by ensuring engineers across disciplines are always working off the most recent and correct versions) and to reduce the risk of negative product outcomes (delays, defects, rework, cost overruns, recalls, etc.) through early detection of issues. The benefits of early detection of issues are significant. Research by INCOSE found that issues not found until verification and validation are 40 to 110 times more costly than if found during design. For this reason, most companies want Live Traceability but are stuck with legacy tools and spreadsheets that do not support it. Since each engineering discipline is allowed to choose its own tooling, the result is a large number of tools with no relationship rules or mechanisms to create Live Traceability across them.
Live Traceability requires a model of the key process elements and their relationship rules to monitor during the development process. The systems engineering V Model is a useful framework to start with for data object and relationship definition. Jama Connect® uniquely provides a point and click, configurable, relationship rule capability to enable Live Traceability. Below you see a sample relationship rule diagram from Jama Connect. Relationship rules vary by industry and company-specific requirements. Best practice templates are provided to comply with industry standards and configured to meet client-specific needs. The definition of a traceability model forms the foundation for model-based systems engineering since it defines model elements and their relationship to each other in a consistent manner across the entire system architecture.
Step 2: Setup Continuous Sync for Siloed Tools/Spreadsheets
Once the relationship rules are defined, the next step is to set up continuous sync with best-of-breed tools and spreadsheets used by the various engineering disciplines. The traceability diagram below shows a typical example of best-of-breed tools and where they sync in the Jama Connect relationship model to deliver Live Traceability.
Most companies prioritize the areas of the traceability model that are most prone to lead to costly issues in the absence of a continuous sync. Most commonly, these areas are:
Software task management – directly linking the decomposition of requirements into user stories enables Live Traceability through the software development process through testing and defect management. The most common best-of-breed tools used are Jira and Azure Dev Ops.
Test automation – test cases are managed in Jama Connect to align to requirements and ensure traceability across all engineering disciplines with the test automation results sync’d to the traceability model at the verification step. The most common test automation tools are TestRail and qTest.
Risk analysis (DFMEA/FMEA) – is most often conducted in multiple Microsoft Excel spreadsheets and the assumption has been that Live Traceability was not possible with Excel. Jama Connect is the first requirements management solution to enable Live Traceability with Excel functions and spreadsheets. Risk teams can now work in their preferred spreadsheets AND for the first time achieve live traceability to stay in sync with changes made by any engineering team. Ansys Medini is also a supported integration.
Model-based systems engineering (MBSE) – the first step in MBSE is to define a relationship model between all product requirements. Once a relationship model is defined, then specifications can be determined through modeling. Jama Connect uniquely provides model-based requirements to sync logically with a SysML modeling tool like Cameo No Magic. Other requirements management tools do not ensure a model-based approach, which most often leads to inconsistent and conflicting fields across teams and projects and provides no coherent relationship model.
Step 3: Monitor for Exceptions
Live Traceability provides the ability, for the first time, to manage by exception the end-to-end product development process across all engineering disciplines. The traceability model defines expected process behavior that can be compared to actual activity to generate exceptions. These exceptions are the early warning indicators of issues that most often lead to delays, cost overruns, rework, defects, and recalls. Below is a view of our Live Trace Explorer that shows you the LIVE state of development for any level of the development project you choose – from the entire cross-discipline effort down to a specific sub-component. Areas of greatest risk appear in red to show where requirement or verification coverage is lacking. Traceability is now a measurement that can be managed and improved with an overall Traceability Score and coverage and verification percentages..
Benefits of Live Traceability
The main benefits of Live Traceability across best-of-breed tools are as follows:
Reduce the risk of delays, cost overruns, rework, defects, and recalls with early detection of issues through exception management and save 40 to 110 times the cost of issues identified late in the process.
Comply with industry standards with no after-the-fact manual effort.
No disruption to engineering teams that continue working in their chosen best-of-breed tools with no need to change tools, fields, values or processes.
Increase productivity and satisfaction of engineers with the confidence that they are always working on the latest version, reflective of all changes and comments.
LEARN MORE
Jama Connect Receives Buyer’s Choice for 2025 on TrustRadius!
We’re proud to announce that Jama Connect has earned the Buyer’s Choice distinction from TrustRadius for 2025, recognizing it as a top platform for requirements, risk, and test management. This award reflects excellence in key areas: best capabilities, value for price, and customer relationships, based on verified user feedback.
“Requirements management is being revolutionized by Jama Connect to enable seamless collaboration and traceability” – Verified User – Project Manager in Information Technology, Medical Device Company – TrustRadius Review
Visit the full report to see why customers love using Jama Connect. This award reflects Jama Software’s commitment to driving innovation and delivering reliable solutions that help teams achieve exceptional results.
“Jama Connect has been invaluable to our organization as a common place to host our product’s specifications (user needs, system and module requirements, system interface), testing (test cases and traceability), as well as risk management documentation. All of our recent projects make use of Jama Connect and is used by the majority of our engineers.” – Verified User, Manager in Engineering, Medical Device Company – TrustRadius Review
We sincerely thank our customers for their feedback and ongoing support. Jama Software remains dedicated to providing the best resources and expertise to help you succeed!
“Jama Connect – Excellent Tool for Regulated Products!! We use Jama Connect to manage our IEC 61508 functional safety requirements that are used to certify our products. Jama Connect had an out of the box solution which allowed us to have tools to support all our artifacts and were able to further exploit its customization to support our companies unique processes. All safety and non-safety requirements across every engineering function uses the tool in this use case.” – Eric Zaremski, Lead Program Manager, FORT Robotics – TrustRadius Review
In this blog, we’ll recap a section of our eBook, “Energy Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Energy” – Click HERE to download it in its entirety.
Buyer’s Guide: Selecting a Product Requirements Management and Traceability Solution for Energy
Use a Single Platform to Streamline Complex Energy Product Requirements Management and Traceability
Energy companies face numerous challenges in managing product requirements and traceability due to growing complexity and enhanced regulatory scrutiny to ensure quality, safety, and security. Delivering products or systems on time, reducing rework and recalls, and speeding up reviews and approvals, are critical in the intensely competitive environment.
Energy companies often attempt to manage critical processes using Word, Excel, or PDF document-based technology. While this manual approach may be adequate for small, simple projects, it fails as complexity and scale increase. Reliance on legacy document management software such as Confluence or SharePoint for tracing, storing, sharing, and retrieving requirements and traceability documents means dealing with data siloes, lack of interoperability, constant changes, security threats, and limited collaboration and analysis.
As a result, companies have difficulty:
Tracking the decomposition and implementation of their requirements
Managing the traceability between requirements, tests, designs and software
Generating documents to demonstrate adherence to standards for auditors
Managing updates and changes across concurrent or similar product development
Identifying product defects early in development
Delivering high quality products on time and budget
Collaborating effectively with all stakeholders around product requirements and standards
Creating an audit trail around sign-off and implementation of requirements
BOTTOM LINE
The increasing complexity of the energy industry and continued reliance on Word, Excel or outdated tools that lead to rework, delays, inefficient work processes, and late discovery of defects make it difficult for energy companies to efficiently manage product requirements to meet both internal and customer needs.
This Buyer’s Guide incorporates insights from Jama Software’s more than 15 years of experience partnering with forward-thinking product development teams and industry experts. We’ve designed a modern, digital platform that helps energy companies efficiently manage and deliver complex products by providing a centralized repository for all requirements, tests, and reports that are accessible by all stakeholders.
This allows energy companies to:
Reduce rework and product recalls significantly
Deliver products on time
Find defects faster and earlier
Reduce manual work associated with managing data in documents involving searching, duplicating, and formatting data, and tracking communications around requirements and reporting
Speed up review and approval cycles for requirements, feasibility, and certification documents
Increase product and data quality to ensure full test coverage, track end-to-end decomposition of products, and enable a unified data model for reporting and data extraction
Understand the source and impact of changes better and remove scope creep
Assign clear ownership over product definition
Use these insights to better understand the challenges you’re up against and thoughtfully consider potential solutions. Plus, learn how to get the buy-in you need to undertake the kind of transformation necessary to succeed with complex products.
Making the Case for Change
Jama Connect® helps energy organizations transition their product development from a document-based way of working to a powerful —but easy-to-use—digital platform that provides a single source of truth which is easily
accessible by all stakeholders at any time. When product requirements and traceability are managed in a centralized platform, users benefit from a straightforward process and the business impact and value of the platform becomes clear across the organization—making management buy-in easier.
If your company is not considering the importance of transitioning to a more modern, digital, streamlined process, time is not on your side. Failing to act quickly can leave your organization even further behind.
But to see the value of a positive impact a system can have, stakeholders in an organization must appreciate the challenges first.
This is where you come in. You can help quantify the problem within your organization and provide data to help make the case for change.
Go through the exercises in the next section using data from your organization to identify your current situation and the size of the potential opportunity.
Tools to Assess the Situation in Your Organization
Throughout the past decade of working with energy (among other industries managing complex products or systems), four common pain points continuously arise for those who have yet to transform their process.
We’ll provide context around the problems and share equations with examples to help you uncover the savings from a modern product requirements management and traceability solution. Remember to adjust the variables according to your company’s metrics to get a more precise estimate, and rethink how your team functions.
Improving any one of these four aspects of your process produces real savings. While the calculations on the following pages aren’t cumulative, they impact one another and can add up to significant value for your organization.
This is the potential of using a modern digital platform. If realized, it can radically change your business and be the competitive edge you need in today’s market.
THE FOUR COMMON PAIN POINTS
Rework
Delays in Product Delivery
Inefficient Process for Working with Internal and External Stakeholders
Failure to Find and Fix Defects Early
Rework
In our experience, approximately 30-50% of a given product development process is rework. Rework is any time spent on extra work — including mid-product development changes, incorrect testing, or fixing problems — and it costs your company big time. Requirements errors cause the majority of rework. Improving the ability to track requirements from definition through testing to catch changes and adjust scope can ensure you’re doing or building the right thing and massively reducing overall lifecycle costs. Complete the equation below to get an understanding of the number of hours your team spends in rework and the value of that in working hours alone.
If your organization is working on more than one product at a time, repeat this calculation for each and add up the savings for a holistic view.
Delays in Product Delivery
Delivering products quickly and maintaining high quality are usually seen as compounding challenges. Conventional wisdom says the quicker you complete a product, the more likely it is to have issues, and vice versa. Understanding the impact of change, capturing decisions, communicating feedback, and reusing existing intellectual property — all aspects that can help speed time-to-market — can be improved with a modern requirements management and traceability solution.
Cost savings can certainly be great and have an impact on your bottom line, but don’t forget the qualitative implications. Consider what it would mean for your company’s reputation to complete high quality, product development faster.
Inefficient Process for Working with Internal and External Stakeholders
Are your days spent in inefficient meetings with internal stakeholders, customers, and subcontractors, sifting through emails and document versions for historical information, waiting for reviews and approvals, or creating documents for auditors? You’re not alone. Many teams suffer the repercussions of archaic, siloed product development work. A modern process maximizes efficiency by tackling the root causes of momentum-killing delays and holdups. Calculate how much unproductive work time is costing your business and imagine the possibilities of getting that time back. What could you do with one extra hour each day?
We’ve seen long status meetings shrink or vanish when teams have the right solutions in place. Think about your team’s schedule and adjust the average time saved per person based on the time spent in meetings each week.
Failure to Find and Fix Defects Early
It’s common for product development to reveal defects at some point between launch and delivery. The important thing is to have a system in place that can quickly and accurately identify defects and track their impact up and downstream. This provides visibility into the problem as early as possible when it’s less detrimental to fix.
This calculation factors in personnel hours, but you should also think about the cost of delays and missed opportunities. Plus, should defects go undetected due to sub-par product requirements or testing or delivering lower-quality products could have devastating consequences.
By leveraging Jama Connect, DoD systems development teams can significantly improve their efficiency, reduce risk, enhance safety, and expedite development while maintaining the highest standards of regulatory compliance with MIL-STD- 882E, contract requirements, defense data standards, interface standards, design criteria standards, manufacturing process standards, standard practices, and test method standards.![[Webinar Recap] Key Systems Engineering Skills: Critical Thinking and Problem Framing](https://www.jamasoftware.com/media/2024/03/Key-Systems-Engineering-Skills-Critical-Thinking-and-Problem-Framing.png "[Webinar Recap] Key Systems Engineering Skills: Critical Thinking and Problem Framing")
![[Webinar Recap] Standardizing Requirements Management Across the Organization](https://www.jamasoftware.com/media/2024/11/Standardizing-Requirements-Management-Across-the-Organization.png "[Webinar Recap] Standardizing Requirements Management Across the Organization")
