Tag Archive for: Requirements & Requirements Management Page 9
Tag Archive for: Requirements & Requirements Management
Understanding ISO 26580: The Standard for Agile Product Line Engineering
Modern organizations face the challenge of balancing speed, compliance, and innovation, particularly when managing complex systems across multiple product lines. ISO 26580 provides a structured approach to addressing these challenges by standardizing Agile Product Line Engineering (APLE). But what exactly is ISO 26580, and why is it important? Let’s break it down.
ISO 26580 is an international standard that defines best practices for Agile Product Line Engineering (APLE). It bridges the gap between Agile methodologies and Product Line Engineering (PLE), enabling organizations to efficiently develop and manage product variations while maintaining agility in development processes.
The standard provides guidance on:
Integrating Agile principles with PLE frameworks
Managing shared assets across multiple product variations
Streamlining development cycles without sacrificing quality
Ensuring regulatory compliance within Agile environments
As industries shift towards mass customization and digital transformation, companies need robust strategies to manage evolving product lines efficiently. ISO 26580 helps businesses achieve this by:
Enhancing Efficiency: Organizations can reuse core components across product variations, reducing duplication and accelerating time-to-market.
Improving Collaboration: By integrating Agile methodologies, teams across different domains can collaborate more effectively, reducing silos.
Ensuring Compliance: Many industries, such as automotive and aerospace, require rigorous compliance. ISO 26580 helps align Agile processes with industry regulations.
Reducing Costs: With a structured approach to managing product variations, organizations can significantly cut development costs and resource expenditures.
Increasing Adaptability: Agile PLE enables companies to quickly adapt to market changes and customer demands without overhauling entire systems.
Who Benefits from ISO 26580?
Industries that manage complex systems with multiple variations, such as:
Automotive (e.g., different models of electric vehicles with shared software platforms)
ISO 26580 is a game-changer for organizations balancing innovation, compliance, and efficiency in Agile product development. By standardizing Agile Product Line Engineering, it empowers businesses to streamline processes, improve collaboration, and accelerate market responsiveness. For companies navigating complex product variations, adopting ISO 26580 isn’t just an advantage — it’s a necessity.
Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by Matt Mickle, McKenzie Jonsson, Mario Maldari, and Decoteau Wilkerson.
Implementing systems engineering (SE) practices in MedTech presents unique challenges. From aligning with regulatory standards like ISO 13485 to managing time-to-market pressures and technical complexity, MedTech professionals must navigate a highly regulated and rapidly evolving environment.
In this webinar, industry experts Mike Johnson, Trainer & Co-Founder of SE-Training GmbH and Vincent Balgos, Director of Medical Device Solutions at Jama Software share actionable strategies to overcome these obstacles and explore how MedTech can lead the way in adopting SE methodologies.
Key Takeaways:
Overview of Systems Engineering practices in the Medical Device industry
Common early-career challenges and practical tips to overcome them in MedTech
Aligning SE practices with regulatory standards like ISO 13485 and addressing gaps in conceptualization, system analysis, and risk management
Don’t miss this opportunity to learn from industry leaders and gain strategies for addressing MedTech’s common SE challenges.
The video above is a preview of this webinar – Click HERE to watch it in its entirety!
VIDEO TRANSCRIPT
Mike Johnson: Thank you very much to all the people of Jama Software for supporting this webinar this evening. The topic is Systems Engineering MedTech Challenges. I’m Mike Johnson and I’m working for a company called SE-Training GmbH. To give you a little introduction on tonight’s topics, so firstly, I have a short introduction about SE-Training, the company I co-founded. Then I want to dive into practical perspectives, aligning systems engineering, challenges, systems engineering opportunities, tips and tricks for overcoming common obstacles, and we have some time then at the end for a wrap-up summary and questions.
Short introduction about the company SE-Training. We are a group of systems engineering experts working on the development and support of technically complex systems. So, the technical complexity is the thing that unites us all and is very much what unites the systems engineering approach. The problems caused by complexity are often very multifaceted, often have a lot of non-linearities, many dependencies, et cetera, and it’s not easy to overcome them. We are an endorsed training provider by the INCOSE UK group. So INCOSE stands for the International Council on Systems Engineering. We are accredited here in Switzerland by the EduQua training accreditation and many people come to us because they would like to achieve one of the accreditations in INCOSE.
That’s the ASEP, the CSEP, or the ESEP. ASEP is the Associated Systems Engineering Professional. CSEP is the Chartered Systems Engineering Professional. ESEP is very experienced. And of course, with both the ASEP and the CSEP, you need to take an exam and it’s not an easy exam. You have to revise quite a lot for it, and so we have a dedicated training course to prepare you for it. Also, for anyone in Switzerland, which may be quite a few people in this webinar, anyone working in Switzerland, if you’re working as a temporary worker, then you can find us on tempservice.ch.
So the challenges for this webinar that we’re trying to overcome, firstly I want to talk about the practical perspectives on the context and constraints. I want to talk about aligning systems engineering implementation initiatives with the applicable standards, ongoing challenges in the MedTech industry, opportunities, and tips and tricks for overcoming the common obstacles in highly regulated industries. Short introduction about myself, I’m British, which means sometimes I make silly jokes. That is of course what the British do. And growing up I attended the University of Exeter firstly to study physics. Following my undergraduate in physics, I went to the University of St. Andrews to gain my master’s in optics and optoelectronics there. My first job was at Thales Optronics in the UK and already from a young age, I was a systems engineer. I was always a systems engineer in my early career, firstly working as an optical systems engineer, especially working with the military.
Johnson: And many of you may know the company Thales. Thales is very big on systems engineering. It’s a core competence there and there I was able to already at a young age, deliver a very big category, a project for the infantry on some very complex systems. I then moved to Switzerland and in Switzerland, I moved to a space company called RUAG Space, which is now called Thales Alenia Space, Switzerland, and there as well as leading the systems engineering group. In addition, I was also a systems engineer, and probably my best application of systems engineering at that time was on the very, very quick development of a space telescope called CaSSIS. The CaSSIS is on the ExoMars Trace Gas Orbiter. Been in orbit since 2017 and we had to do end-to-end development and verification activities, et cetera, and deliver in under two years, which really, really was challenging. I must say though that it is also a very good application of systems engineering, especially from a value-oriented perspective.
There after five years at RUAG Space, I moved to Roche Diagnostics. I moved to the MedTech industry. There, I was head of systems engineering in the molecular division, especially all the systems there using PCR or the polymerase chain reaction, I was there for seven years with a group of about 30 people, business analysts, systems engineers, requirements engineers, et cetera, really specializing on a lot of the upfront product definition activities on these, again, very complex systems. Whether they’re pre-analytics or analytics or analytics systems, both are equally very complex, with many aspects that you need to consider. You can’t just go in and start writing software or start cutting metal as such. Also introduce many organizational initiatives across the whole of Roche Diagnostics, not just in our site in Switzerland. And then for the last two years, I’ve been full-time with my company SE-Training as a consultant and trainer.
So for this webinar, first topic I want to talk about is practical perspectives. The importance here of considering firstly many aspects of MedTech context and constraints. And I say this of course based a lot on my history and my history is that I’ve come from a strong systems engineering background in aerospace, defense, and then come into MedTech. So of course my views and my reflections are based very much on my experience here may not be the same for everybody. How do I see things? Well, number one, it’s a very high compliance-driven development process, so it’s very important in MedTech that you show evidence for what you’ve done or what you said you were going to do. That’s really important in the development processes. Now of course, if I’m just making a very simple product, just a few requirements, a few verification activities, well, that’s not so difficult, is it?
But of course,e if I’m making very complex systems, I have many different subcontractors supporting them as well, many aspects possibly changing, then actually having that evidence to show compliance is really important, especially since I’ve got a high level of confidence that everything is available and is consistent. Otherwise, I’m open very much to a lot of liability. So you’re going to expect that in this industry. In particular, in MedTech, the development process is very centered around usability and safety. Now of course, safety is called product risk, but it’s a term that I must say I’m not a particular fan of. I’d rather we call things safety, but these are core to the development processes. So right from the beginning of the development you circle around usability and safety is absolutely critical. And of course, we know why or any of us working in the MedTech industry know why, because we’ve seen how both usability and safety can lead to, of course, in many cases, deaths. Unfortunately, from the misuse of medical devices or from liability issues, et cetera.
I mean, it’s medical devices you could be connected to, which if they failed you could be dead within two or three minutes or seriously injured within two or three minutes. So of course these two quality attributes or -ilities or emerging or engineering specialties or emergent properties, whatever you want to call them, these two in particular are very, very critical and of course, we know that as we go through the development processes, we need to circle around them. In both these cases, we should already be thinking we want to be supported in implementing and executing these processes. Just so that I say something that’s obvious, there’s high pressure on time to market, no one’s in denial about that.
That’s probably one of the critical constraints on any project you work on in MedTech is the pressure to get to market first is absolutely as high as you can imagine from any other industry. Often, of course, projects have dropped because they’re not achieving their timelines or simply a competitor has moved in. An unexpected competitor has got their product to market before you, really, really critical time to market. And that’s where actually from my time in the space industry, I can relate to that as well with our developing telescopes. If we were late, we simply wouldn’t get onto the rocket. We simply wouldn’t have gone to Mars.
Johnson: So actually that’s quite similar and I used to say to people actually in the MedTech industry, I used to say to my colleagues often, imagine it’s a space rocket that you’re trying to get your product onto because the space rocket doesn’t work, doesn’t wait for you. I say this as well after working across all three industries. What I saw in MedTech, is often technically the most complex systems, especially when you start analyzing the complexity of the system of systems that they’re operating within. And interestingly here, it’s not just that it’s a very high level of complexity, but also what I often saw in MedTech was that the complexity was underestimated.
People weren’t realizing just how complex these systems were, whether they were taking over jobs that people could do, so automating activities, or doing some very high-level chemistry for the samples. But whatever they were doing, often the people themselves didn’t realize just how technically complex these things were, which I would say is actually quite different to the aerospace and defense industry. Often there actually I found that you didn’t so much underestimate the complexity. You were more aware of the complexity. Often actually I think you could do overkill, you could do too much, or get to try and navigate your way around the complexity. Whereas in MedTech, I often found it was quite underestimated and yet these were really, really complex systems.
So after the contextualization and constraints, look at alignment with standards. Now of course, the one big standard we should all know is the ISO 13485. Very interesting. If you do a control F, so you look at what’s in the ISO 13485 standard. Of course, you won’t find the word systems engineering. So having failed on your first control F, you start to look for other words, don’t you? You say, well, what is that is systems engineering? What do we find in there? It’s clear they want to see a high level of traceability throughout the design and development process. Now, you think typically that products can be developed, like mid-complex products may be developed in three to five years, scales, things like this, three to five years. And well, in those three to five years what can happen? A whole load of things can change, your scope can change, your design can change, your verification can change, da, da, da. A whole load of things can change.
Project team members can change, and subcontractor suppliers can change. All these things, of course, can change. And if at the end of it you say, the regulator comes to you and says, “Well, where’s the evidence that you did what you said you were going to do five years ago?” And you look back at them with a bit of surprise and you’ve got no way of showing that evidence through the traceability of the process and of course,e you’re in trouble. Which again is often why we will have infrastructure supporting us through that process.
The New ARP4754B and Techniques in Jama Connect® for Airborne Systems
ARP4754B, released on December 20, 2023, is a standard from SAE International that provides recommendations for the development of civil aircraft and systems, focusing on ensuring safety and compliance with regulations. It covers the entire aircraft development cycle, from system requirements through verification and validation. The latest revision includes new methods for safety analysis, such as Model-Based Safety Analysis (MBSA) and Cascading Effects Analysis (CEA). It is mandatory for all aircraft and systems worldwide, including emerging eVTOLs and UAVs, to demonstrate compliance with aviation regulations. This guideline aligns with ARP4761A, which was released on the same date, for safety assessment processes and offers increased flexibility in selecting validation and verification methods.
ARP4754B Applied in Jama Connect for Airborne Systems
ARP4754B and ARP4761A are both crucial guidelines, and the alignment between the two new versions has been enhanced to streamline development and safety assessments. In addition to the inclusion of the two new safety analysis methods, ARP4754B now places a stronger emphasis on identifying and mitigating unintended behaviors. It now includes consensus methods for demonstrating compliance within the development planning process and has also enhanced its flexibility in validation and verification.
Jama Connect can be used throughout the system development process as the primary system to manage the requirements and full product traceability. Figure 1 from ARP4754B outlines the relationships between the lifecycle and integral processes, which provide guidelines for safety assessment, electronic hardware and software lifecycle processes, and the system development process described herein.
There are always numerous ways to tailor the use of Jama Connect. Here’s how the updates to ARP4754B influence requirements management and how our Airborne solution is pre-configured to support them.
1: Adoption of Model-Based Systems Engineering (MBSE)
MBSE Integration: Updates encourage the use of MBSE to handle the increasing complexity of aircraft systems.
Modeling Languages: Use of modeling languages like SysML to create detailed system models that include requirements, behavior, and structure.
Jama Connect for Airborne Systems Model-Based Techniques
Model-Driven Requirements: Requirements are captured and managed within the Jama Connect data model, providing requirements management techniques that support model-based representations. The Solution comes pre-configured with element types that correspond to the levels of requirements called out in ARP4754B, function elements, WBS, verifications and validations, and safety-related elements. Jama Connect constrains the data to follow the traceability rules which enable rapid analysis, automated trace matrix generation, and querying and reporting.
Synchronization of Models and Textual Requirements: Ensuring consistency between textual requirements and model-based representations requires synchronization mechanisms. Jama Connect is often used in conjunction with SysML tools and all leading vendors offer native integrations.
Figure 2: Model-based elements replace documents and the Jama Connect for Airborne Systems’ traceability schema maintains consistency.
2. Enhanced Integration of Safety and Requirements Management
Safety-Driven Requirements: The updates emphasize integrating safety assessments directly into the requirements management process. This means that safety considerations become a foundational aspect of requirement definition and management.
Iterative Feedback Loop: There is a stronger focus on creating an iterative process where safety analysis results inform requirement updates, and changes in requirements trigger reassessment of safety analyses.
Jama Connect for Airborne Systems Safety & Requirements Management Techniques:
Traceable Within the Model: The outputs from safety analyses are captured and managed directly in Jama Connect. Our Airborne Systems solution provides the data model for a consistent trace and data strategy between safety, requirements, and tests.
Requirements Annotation: Requirements have built-in attributes for safety-related information, such as hazard classifications and safety integrity levels.
Tool Integration: Jama Connect integrates seamlessly with safety analysis tools such as ANSYS Medini, the LDRA tool suite and others to ensure seamless data flow and traceability between safety assessments and requirements.
Figure 3: Jama Connect for Airborne Systems solution on the left and SAE ARP4754B (page 102) on the right.
Bidirectional Traceability: Enhanced emphasis on maintaining bidirectional traceability between requirements, design artifacts, implementation, and verification activities.
Traceability to Safety Objectives: Requirements must be directly linked to safety objectives and hazard analyses derived from updated safety assessment processes.
Jama Connect for Airborne Systems Solution Techniques:
Robust Traceability Matrices: The solution comes preconfigured with views and filters required by ARP4754B. These sophisticated traceability matrices that map requirements to design elements, test cases, and safety analyses are also exportable. The Airborne Systems solution has out-of-the-box export templates that can also be tailored.
Automated Traceability: Instead of authoring content and then creating a trace to its related content after the fact, use the “Add Related” functionality built into Jama Connect. This use of automated trace creation to manage traceability reduces the risk of human error and improves efficiency.
Figure 4: Constrained set of data choices ensures users create consistent traces.
We’ve shared 3 of the 6 ways Jama Connect’s Airborne Solution supports ARP4754B influence requirements management.
Want the full picture? Download the whitepaper to explore them all!
Understanding ISO 13849: The Foundation of Functional Safety in the Machinery Sector
Like many industries, functional safety is a critical part of machinery design – ensuring the protection of operators, equipment (and surrounding environments) from hazardous situations. To help maintain functional safety in industrial manufacturing, most organizations use ISO 13849, a globally recognized standard that provides comprehensive guidelines for achieving and validating functional safety in machinery control systems. In this blog, we’ll look at the importance of ISO 13849, key components, and how it shapes functional safety in the machinery sector.
According to an informal ISO/TC stakeholder survey, more than 89% of machine builders and more than 90% of component manufacturers and service providers use ISO 13849 as their functional safety standard.
What is ISO 13849?
Officially titled “Safety of machinery – Safety-related parts of control systems”, ISO 13849 is an official standard that outlines the principles for designing and assessing the safety-related parts of control systems (SRP/CS). These are systems that directly influence the safety functions of a machine, e.g., emergency stops, interlocks, and protective barriers.
ISO 13849-1: Focuses on general principles for design and performance.
ISO 13849-2: Covers validation procedures for ensuring the compliance of safety functions.
By following this standard, manufacturers can reduce the likelihood of machinery-related accidents and improve overall safety compliance.
Why is ISO 13849 Essential in the Machinery Industry?
Is it mandatory? Well, no.
However, the machinery sector operates in environments where equipment malfunctions can lead to severe injuries, fatalities, and property damage. Functional safety – as defined by ISO 13849 – helps mitigate these risks by emphasizing:
Reducing Risk: Identifying potential hazards and designing systems to minimize them.
Reliability: Ensuring that safety-related control systems perform their intended functions under all expected conditions.
It’s also important to note that compliance with this standard can also help teams avoid legal and financial repercussions if something does go wrong.
ISO 13849 bridges the gap between innovation and safety, enabling manufacturers to integrate cutting-edge technology without compromising operator protection.
Key Info about ISO 13849
ISO 13849 revolves around several core principles:
1: Performance Level (PL) – Performance Level quantifies the reliability of safety functions, categorized from PL a (lowest) to PL e (highest). Factors influencing PL include:
Hardware structure.
Diagnostic coverage (DC).
Mean time to dangerous failure (MTTFd).
Common cause failure (CCF) protection.
2. Risk Assessment and Reduction – Part of this standard is the emphasis on conducting thorough risk assessments to identify potential hazards and determine the necessary PL for mitigation.
3. Validation – Validation ensures that the implemented safety functions meet design specs and operate correctly under foreseeable conditions. ISO 13849-2 provides specific procedures for this step.
4. Diagnostics and Redundancy – Built-in diagnostics and redundant systems enhance reliability, preventing failures from leading to unsafe conditions.
Implementing in Functional Safety Design
Successfully implementing ISO 13849 needs a structured approach:
Risk Assessment: Analyze the machinery’s operational scenarios to identify risks.
Determine Safety Requirements: Define safety functions and their corresponding Performance Levels.
Design Safety Systems: Develop control systems with redundancy, diagnostic coverage, and robust design principles.
Validation: Test and validate by comparing to ISO 13849-2 to make sure you’re compliant.
Benefits of Choosing to Comply
Adhering to ISO 13849 delivers a lot of advantages for machinery manufacturers and operators:
Enhanced Safety: Reduces the risk of accidents and improves operator confidence.
Regulatory Compliance: You’ll meet international safety standards, facilitating market entry and reducing liability.
Cost Efficiency: Minimizes downtime and damage from malfunctions.
Reputation Management: Demonstrates a commitment to safety and reliability, boosting brand credibility.
Implementing ISO 13849 can be challenging, especially for manufacturers unfamiliar with its requirements. Some common obstacles could be:
Complexity in Risk Assessment: Accurately determining Performance Levels requires expertise.
Integration with Legacy Systems: Retrofitting older machines can be resource intensive.
Validation Procedures: Comprehensive testing can be time-consuming.
Some thoughts on overcoming these challenges:
Engage Experts: Don’t go it alone – collaborate with functional safety specialists.
Use Certified Components: Choose components that meet ISO 13849 requirements.
Invest in Training: Help your team succeed! Equip them with the knowledge to apply the standard effectively.
ISO 13849 serves as a cornerstone of functional safety in the machinery sector. By following its guidelines, manufacturers can design systems that not only meet regulatory standards but also provide robust protection against operational risks. In an industry where safety is paramount, ISO 13849 ensures that innovation and reliability go hand in hand.
Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by Steven Meadow and McKenzie Jonsson.
Jama Connect Features in Five: Release Management via Reuse & Synchronization
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, Máté Hársing, Solutions Manager at Jama Software, demonstrates how Jama Connect helps teams streamline release management with its reuse and synchronization capabilities.
VIDEO TRANSCRIPT
Máté Hársing: Hello and welcome. My name is Máté Hársing, and I’m a Solutions Architect at Jama Software. In this video, we’re going to explore how Jama Connect helps teams streamline release management with its reuse and synchronization capabilities. Managing multiple product releases often introduces challenges such as tracking changes across different product versions, ensuring teams work on release branches without disrupting the main project, merging updates without losing critical information or creating inconsistencies, maintaining traceability and compliance in industries with strict regulatory requirements.
Without the right tools, these challenges can lead to delays, increased costs, and risks of errors. Jama Connect addresses these challenges with its reuse and synchronization capabilities.
By allowing you to duplicate projects or components, Jama Connect creates a release branch where teams can work independently. The platform provides powerful comparison tools at the item, set, and project levels, enabling you to see changes clearly.
When it’s time to merge updates, Jama Connect gives you full control, allowing you to select specific changes while maintaining traceability and alignment. Now let’s see this in action. I’ll start by showing the main branch of the project and how it’s in sync with a specific release branch, release 2.0. This release branch is a separate project that will include updates and modifications specific to this version once we start working on it. As you can see, so far, the synchronization is fully intact between these two projects.
Hársing: Now let’s take a look at the synced items widget starting at the item level. This widget shows the relationship between this specific operational time requirement in the main project and the release branch. You can see they are currently in sync, meaning there is no difference between them. If I change the operational time for release two zero to a higher number, as we want to ensure higher user satisfaction, you’ll see they are now out of sync.
By clicking on the button, we can see the red line differentiation between the main branch requirement and the release-specific requirement for release 2.0. Moving up to the set level, we can view how entire groups of requirements are synced. This provides a broader perspective, allowing teams to manage changes across multiple related items efficiently. Let’s add a new requirement to release 2.0 and delete an existing one so that you can see how the information will show up when comparing the two sets between the main branch and release 2.0.
Finally, at the project level, you can see an overview of synchronization across the entire project. This is particularly useful for tracking overall progress and ensuring alignment between the main branch and the release.
Now I’ll demonstrate how to merge changes back into the main project. Jama Connect allows you to make different kinds of merges. For instance, you can accept specific changes, reject others, or use the consolidation option to manage conflicting requirement descriptions side by side. This ensures the two versions of a requirement can be refined into a common denominator, maintaining clarity and consistency.
Hársing: I’d like to emphasize that both reusing and synchronizing are permission-controlled so that only appointed team members can execute these tasks. Each dedicated project can also be baselined creating a snapshot in time. This is invaluable for generating submission-ready documentation, especially in regulated industries such as medical device design and development. Additionally, any change made in either project, the main branch or the release branch, propagates reactive change management capabilities via the Suspect Link tool. This feature automatically flags impacted items, ensuring teams can quickly assess and address the downstream effects of any modification.
These features reduce risks, improve collaboration, and ensure compliance by keeping everything organized and transparent. Jama Connect simplifies release management so you can focus on delivering high-quality products.
Thank you for watching this demonstration of release management via reuse and synchronization in Jama Connect. If you would like to learn more about how Jama Connect can optimize your product development process, please visit our website at jamasoftware.com. If you are already a Jama Connect customer and would like more information about release management via reuse and synchronization, please contact your Customer Success Manager or Jama Software Consultant.
Use Cases and Strategies for Simplifying Variant Management
Variant management enables organizations to efficiently tailor requirements for diverse markets while maintaining alignment across teams.
Jama Connect® offers flexible strategies to simplify creation, adaptation, and tracking of multiple variants. These approaches facilitate efficient reuse, reduce complexity, and maintain traceability across complicated product lines.
Identifying and adapting product variants based on evolving market dynamics, regulatory requirements, and unique customer needs to ensure consistent compliance.
Streamlining variant creation by configuring specific versions of product components, optimizing reuse, and fostering alignment across complex product lines.
Leveraging a structured feature model to effectively manage options and better understand complex product variations.
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
Matt Mickle: We have a fun topic today, walking through variant management use cases with the goal of simplifying this sometimes complicated topic. I will start off by walking through some of the common use cases that we often hear, followed by some concrete examples of how we would see these within the industry. I’ll talk a little bit about how we’ll solve these within Jama Connect and then have some demonstration of this directly in the tool. I’ll do this for each use case as we proceed, and then we’ll move on to some Q&A and I’ll answer some of your questions.
So, what do I mean when I say variant management? Well, simply, I would describe variant management as any process or technique that is used to manage variability and assets within a project. This could be in the form of certain techniques, such as feature-based product line engineering, which we’ll talk a little bit more about later. Configuration management, product derivation, or branch and merge. A product can vary in many ways, such as different features, material or components, premium services, or levels of performance. Here are some examples you might recognize. Models of home appliances with different sizes or capabilities, like these refrigerators. Microcontrollers with a configuration of reusable IP blocks. Medical devices, such as insulin pumps or digital thermometers having an array of features based on setting, method of application or type of consumer. As well as everyday devices, such as smartphones or smartwatches with different uses or consumer profiles.
Nearly every product you could think of has some amount of variation. And the process of managing those variants extends from the conception of the products, all the way into their description at the point of sale, and maintenance thereafter. So, one of these methods, which we will mention in the discussion today, is product line engineering, or PLE for short. And for this, we’ll use the simple definition, a focus on engineering for a family of products with similar features, components or modules as a single product line to leverage commonality and variability, minimize the duplication of effort, and maximize reusability.
Mickle: Now, a couple of definitions that go along with that from the standards for product line engineering, from ISO 26550, the definition of a feature would be an abstract functional characteristic of a system of interest that end users and other stakeholders can understand. And from the product line engineering for feature-based product line engineering standard, ISO 26580, a product line would be a family of similar products with variations in features. So, product line engineering could be considered as the next step in maturity. Single system engineering. And as the ISO standard on software and system engineering for product line engineering and management states, product companies utilizing single system engineering and management approaches may end up with highly complex and low-quality products. Low productivity, high employee turnover, and less than expected customer satisfaction.
So, let’s instead talk about the benefits of moving from single-system engineering into product-line engineering. Product line engineering enables organizations to create product line architecture that allows for the systematic reuse of components, modules, and assets across different products within a product line. This promotes efficiency by reducing redundancy in the need to recreate similar functionalities for each product. By reusing existing components and assets, organizations can significantly reduce development costs. Product line engineering allows for economies of scale, as the investment in creating a core set of assets can be spread across multiple products, leading to cost savings in the long run.
With product line engineering, organizations can streamline the development process by leveraging existing components and architectures. Faster time to market for new products, since development efforts are focused on creating unique features, rather than rebuilding common functionalities. Product line engineering helps ensure consistency in products across the product line. By reusing well-tested and validated components, the likelihood of introducing defects or inconsistencies is reduced. And this will lead to higher overall product quality. As market demands change or new technologies emerge, product line engineering provides a framework that allows organizations to adapt and evolve their product line more easily. This enables the addition of new features or modification of existing ones without starting the development from scratch.
Mickle: Product line engineering supports efficient configuration management, allowing organizations to define and manage variations and products through configuration, rather than by creating separated versions or desynchronized copies of content. This simplifies the task of handling different customer requirements or market-specific adaptations. Product line engineering makes maintenance and upgrades more manageable. Changes or bug fixes can be applied to common components, and then the updates can be propagated to all of the products within the line, ensuring that each product benefits from the improvements without having to undergo individual modifications.
And finally, product line engineering helps mitigate the risks associated with product development by relying on well-established and proven components. Since these components have been used and tested across multiple products, the likelihood of critical issues arising is reduced. Now, of course, there are many benefits for product line engineering, but there are a lot of challenges that a company goes through in order to try and move towards product line engineering. For example, let’s say a company starts out with a single product and then begins to build variants on that product, turning it into a product line. As the number of variants and variation between them grows, the ability to manage them becomes more and more challenging.
When a change is made, it’s important to assess not only the impact of that change within the product, where the change is made, but also in any products that are part of the same product line. If the change is against common requirements, then the decision is needed on whether they need variation. New versions or configurations of components of a system will need to be thoroughly reviewed with regards to how they interconnect. This becomes even more challenging and complex when considered as the product development data moves from one development application to the next. Throughout the supply chain, information about progress and change needs to flow and be collected in order to see overall status.
This recognition is particularly meaningful because G2’s rankings are based on verified user reviews and insights from real customers, analyzed through their proprietary v3.0 algorithm. The Winter 2025 Grid Report reflects data collected through November 19, 2024, highlighting the best-performing tools in the field.
But that’s not all — Jama Connect received multiple accolades across all business sizes and regions, including:
Overall Leader
Momentum Leader
Small-Business Leader
Mid-Market Leader
Enterprise Leader
EMEA Leader
Europe Leader
Learn more about the Winter 2025 G2 Grid for top Requirements Management Software products: DOWNLOAD IT HERE
Why This Recognition Matters
This accomplishment underscores our commitment to helping customers transition from document-based processes to a modern requirements management platform. Jama Connect empowers teams to manage complex product, systems, and software development with unmatched clarity and collaboration.
We owe this success to the incredible feedback from our users. Here’s what they’re saying:
“Jama Connect is not only a ‘document oriented’ ALM tool, it gives the organization the ability to map the project structure to the product structure, making it an easy entry point for R&D folks. Configured properly, it is a real technical and regulatory ‘single source of truth.” — Frederic Fiquet, Director, Systems Engineering, G2.com
“Product Design teams need a requirements management tool like Jama Connect. Using Jama Connect allows our software development team to have a well-organized and well-written set of requirements. It allows us to more easily maintain a baseline of features in our continuously evolving software.” — Mark M., Mid-Market, G2.com
We are committed to providing the best possible experience for our users, and being named the overall leader by G2 is a testament to the success and satisfaction our customers have found with Jama Connect.
From all of us at Jama Software, thank you!
2025 Expert Predictions for the AEC Industry: How Technology, Emerging Trends, and Innovation Will Shape the Industry in 2025 and Beyond
As we look toward the next five years in the Architecture, Engineering, and Construction (AEC) industry, emerging technologies are set to revolutionize how buildings are designed, constructed, and maintained. From the rise of digital twins to the growing integration of AI and machine learning, the tools and strategies transforming the industry promise to boost efficiency, sustainability, and collaboration. As companies prepare for these advancements, understanding how these technologies will shape the landscape and adopting the right tools will be critical.
In part five of our annual predictions series, Joe Gould, Senior Account Executive at Jama Software, shares his insights on the trends, challenges, and innovations shaping the future of AEC.
Question 1: What emerging technologies or digital tools do you believe will most significantly reshape the AEC industry in the next five years, and how can companies prepare to integrate these advancements effectively?
Joe Gould:
Digital Twins – The use of digital twins to create real-time, virtual representations of physical assets is set to revolutionize operations and maintenance. This technology provides actionable insights, predictive maintenance, and enhanced asset performance management. Implement IoT sensors and connect data streams to develop digital twin capabilities. Start with pilot projects to showcase value and gradually expand their use.
AI and Machine Learning – AI-driven tools will enhance project planning, risk management, and resource optimization. Machine learning models can analyze historical data to predict delays, optimize schedules, and reduce costs. Integrate AI into existing workflows, such as predictive analytics for scheduling or automated quality control checks, to reduce manual errors and inefficiencies.
Modular and Prefabrication Technologies – Offsite construction and prefabrication are becoming more efficient with advancements in design automation and digital manufacturing tools. Adopt software platforms that integrate modular construction workflows with design and scheduling tools. Establish partnerships with prefabrication facilities.
Sustainability Focused Tools – These are tools for energy modeling, lifecycle analysis, and carbon tracking will drive environmentally responsible design and construction. Embed sustainability metrics into project KPIs and adopt tools that facilitate compliance with green building certifications like LEED or BREEAM.
Question 2: As sustainability goals become increasingly prioritized, what role do you see software and product development playing in achieving more environmentally friendly and energy-efficient designs within the AEC sector?
Gould: Software and product development play a pivotal role in advancing sustainability and energy efficiency within the AEC sector by enabling more data-driven, holistic, and collaborative approaches to design and construction. Tools such as Building Information Modeling (BIM), energy simulation software, and lifecycle assessment platforms allow architects and engineers to optimize designs for energy performance, material efficiency, and reduced carbon footprints from the earliest project stages. Digital twins extend this capability by facilitating real-time monitoring and optimization of building performance throughout its lifecycle, ensuring long-term energy efficiency and reduced environmental impact. By leveraging these technologies, companies can not only meet regulatory demands but also position themselves as leaders in creating environmentally responsible and energy-efficient designs that contribute to a sustainable future.
Question 3: With remote and hybrid work now a permanent reality for many industries, how do you anticipate these work models impacting collaboration and innovation in the AEC space, especially regarding software and project management tools?
Gould: With remote and hybrid work becoming the norm, the AEC industry is seeing some interesting shifts in how teams collaborate and innovate. While it used to be all about in-person meetings and site visits, now software and project management tools are stepping up to bridge the gap. Cloud-based platforms make it easier than ever for teams to share updates, track progress, and stay connected no matter where they’re working from. This new way of working is also pushing companies to adopt more streamlined workflows and better communication practices, which can actually spark innovation!
Question 4: How do you foresee AI and machine learning influencing decision-making and risk management in AEC projects? What are some challenges or limitations the industry might face in adopting these technologies?
Gould: AI and machine learning are definitely shaking things up in the AEC industry, especially when it comes to decision-making and risk management! These technologies can analyze massive amounts of data — like project schedules, historical performance, and even weather patterns — to predict potential delays, budget overruns, or safety risks before they happen. It’s like having an early warning system that helps teams make smarter, faster decisions. On top of that, AI can optimize workflows, improve resource allocation, and even suggest more efficient designs.
Question 5: As a follow up question: Do you have any concerns or anticipate any negative impacts as it pertains to AI & ML.
Gould: I believe there are some challenges to getting these tools up and running. One big hurdle is the quality of data — if your data isn’t clean or consistent, the AI’s predictions won’t be reliable. There’s also a learning curve; not everyone in the industry is ready to fully embrace these new tools, so training and change management are crucial. Plus, while AI is great for identifying trends, it still relies on human expertise for context and final decisions. So, while the potential is huge, there’s still some work to do in terms of adoption and integration in my opinion.
Question 6: Given the current emphasis on data-driven project management and predictive analytics, what strategies would you recommend for AEC firms to better leverage data for optimizing project outcomes and resource allocation?
Gould: If AEC firms want to get more out of data-driven project management, it starts with organizing their data. Centralizing everything — budgets, schedules, progress updates —into tools like BIM or Procore makes it easier to analyze and act on insights. Predictive analytics can then help spot issues early, like delays or resource shortages, so teams can adjust before problems escalate. The key is to train people to use the data effectively and start with small pilot projects to build confidence. When everyone’s on the same page and using the same data, decisions get smarter, and projects run smoother.
Question 7: Are there any additional insights you have regarding predictions, events, or trends you anticipate happening in 2025 and beyond?
Gould: Looking ahead to 2025 and beyond, I think we’ll see a bigger push for sustainability in AEC, with more focus on net-zero buildings and carbon tracking tools. AI and automation will likely play an even larger role in design and project management, making workflows faster and more efficient. Plus, digital twins and smart buildings will continue to grow, especially as IoT tech gets better. The challenge will be adapting quickly while balancing innovation with practicality, but the opportunities for transformation are huge!
FDA Issues Comprehensive Draft Guidance for Developers of Artificial Intelligence-Enabled Medical Devices
Guidance Shares Strategies to Address Transparency and Bias, while Providing Key Considerations and Recommendations on Product Design, Development and Documentation
Today, the U.S. Food and Drug Administration issued draft guidance that includes recommendations to support development and marketing of safe and effective AI-enabled devices throughout the device’s Total Product Life Cycle. The guidance, if finalized, would be the first guidance to provide comprehensive recommendations for AI-enabled devices throughout the total product lifecycle, providing developers an accessible set of considerations that tie together design, development, maintenance and documentation recommendations to help ensure safety and effectiveness of AI-enabled devices. This guidance complements the recently issued final guidance on predetermined change control plans for AI-enabled devices, which provides recommendations on how to proactively plan for device updates once the product is on the market.
“The FDA has authorized more than 1,000 AI-enabled devices through established premarket pathways. As we continue to see exciting developments in this field, it’s important to recognize that there are specific considerations unique to AI-enabled devices,” said Troy Tazbaz, director of the Digital Health Center of Excellence within the FDA’s Center for Devices and Radiological Health. “Today’s draft guidance brings together relevant information for developers, shares learnings from authorized AI-enabled devices and provides a first point-of-reference for specific recommendations that apply to these devices, from the earliest stages of development through the device’s entire life cycle.”
The draft guidance includes recommendations for how and when, in marketing submissions, sponsors should describe the postmarket performance monitoring and management of their AI-enabled devices. The proposed recommendations reflect a comprehensive approach to the management of risk throughout the device total product life cycle. The FDA encourages sponsors to engage with the agency early and often, and to use this guidance, once finalized, to guide their activities throughout the life cycle of the device, including during planning, development, testing and ongoing monitoring.
Importantly, this draft guidance also includes the FDA’s current thinking on strategies to address transparency and bias throughout the life cycle of AI-enabled devices. The draft guidance describes specific recommendations intended to help a sponsor demonstrate they have addressed risks associated with bias and provides suggestions for the thoughtful design and evaluation of AI-enabled devices.
Notably, this announcement is specific to AI-enabled devices. Today, the FDA also published draft guidance with recommendations regarding the use of AI to support development of drug and biological products. The publication of these guidances, among other actions, continues to demonstrate the agency’s efforts to provide transparency and to help ensure product safety and effectiveness while supporting innovation in this rapidly growing field.
The FDA is requesting public comment on this draft guidance by April 7, 2025. In addition to general comments, the FDA is specifically requesting public comment on the draft guidance’s alignment with the AI lifecycle; the adequacy of the recommendations to address concerns that may be raised by emerging technology such as generative AI; the approach to performance monitoring (including use of a performance monitoring plan as a means of risk mitigation for AI-enabled devices); the type of information about AI-enabled devices that should be conveyed to users and the most appropriate approach to deliver that information. The FDA will also hold a webinar on February 18, 2025, to discuss the draft guidance.
In this blog, we’ll recap a section of our recent Expert Perspectives video, “Integrating Safety of Intended Functionality (SOTIF) Into the Automotive Requirements Engineering Process” – Click HERE to watch it in it entirety.
Expert Perspectives: Integrating Safety of Intended Functionality (SOTIF) Into the Automotive Requirements Engineering Process
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 this episode, we speak with Dr. Hasan Ibne Akram on the topic of Integrating Safety of Intended Functionality (SOTIF) Into the Automotive Requirements Engineering Process.
Watch this video to learn more about:
The differences between SOTIF and functional safety
How to define and manage safety requirements addressing system limitations and edge cases
How to conduct a hazard analysis and risk assessment to cover intended functionality
Below is a preview of our interview. Click HERE to watch it in its entirety.
Kenzie Ingram: 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 Ingram, your host.
And today I’m excited to welcome Dr. Hasan Ibne Akram, an entrepreneur, computer scientist, book author, and CEO of engineering service company Matrickz based in Munich, Germany. With more than 17 years of experience in the automotive industry and working for two of the major German automotive OEMs, Dr. Akram brings a wealth of knowledge to this conversation. Today, we’re excited to showcase a discussion between Matt Mickle, Jama Software’s Director of Automotive Solutions, and Dr. Akram, on integrating safety of intended functionality, also known as SOTIF into the automotive requirements engineering process. Without further ado, I’d like to welcome Dr. Akram and Matt Mickle.
Matt Mickle: Thanks everyone for joining us today. My name is Matt Mickle. I’m the Director of Solutions for Automotive and Semiconductor at Jama Software. And I’m joined here today by Dr. Hasan Ibne Akram. Thanks very much for joining us today and answering some questions around integrating SOTIF into the automotive requirements engineering process. Dr. Akram, maybe we could start by just you telling us a little bit about yourself and your history with SOTIF and other industry standards and just a little bit about your background.
Dr. Hasan Ibne Akram: Absolutely. Thank you so much, Matt, for having me here. It’s amazing that we are having this conversation because this is very relevant today.
So my background in automotive started way back in 2005. So I was still a student, but I really wanted to go for a start-up. And back then, I landed a project with Continental. It was a braking system calculation project, and that’s how I got into automotive. And kept doing automotive stuff ever since.
And then, when I started my safety journey, I actually had no clue. So the first encounter to safety was a long time ago when I was actually working at a [inaudible 00:02:30] OEM as an external consultant. I was more responsible for the software. And during the lunch break, the functional safety colleague of that OEM, and in German, we call it FuSi, Funktionale Sicherheit, we used to call it FuSi. So I asked him, “What FuSi, the thing that you’re doing all the time? What is it about?” And quite condescendingly, he said, “We assume that whatever you guys are doing over there, every line of code, everything that you will do will go wrong.”
Akram: That was kind of like a light bulb moment for me. “Wow, that’s interesting. What happens when everything goes wrong? What do we do?” That was really my genesis of the functional safety journey. And SOTIF didn’t exist back then, was doing ISO 26262. And during my PhD, I was specialized in automotive cybersecurity, so cybersecurity and functional safety, I really wanted to bring them together.
And then, we realized, the automotive industry realized that, hey, there is something missing. Because with traditional safety, the definition of traditional safety is all about malfunction, if something goes wrong. Even when we’re doing security, it’s beyond malfunction, it’s all about attack now.Now comes autonomous vehicle, kind of like ADAS’s features, active distance control, automated emergency brake, active cruise control, and different levels of autonomy, Level 1, Level 2. The definitions came much later, but the idea of SOTIF was, hey, there’s something inherently required, there’s something required, something missing, inherently missing in the current standard because there can be hazards beyond malfunction.
It’s all about intention and this is where SOTIF was created, that we will talk about safety of the intended functionality. And my involvement, like you wanted to ask, my involvement with all these standards, I was following these standards before from the very ideas because the community is very, very close community. All the safety people in my podcast, I had Hans-Leo Ross, I had people who are the… Hans-Leo Ross even showed the birth certificate of ISO 26262 because he literally wrote the first lines and everything of ISO 26262. And I was privileged to be around these people who are actually shaping the future of these standards and how the engineering work will be done in the autonomous vehicle sphere and safety will be defined. So yeah.
Mickle: Nice. Well, that must’ve been quite enthralling at the time. So you mentioned that there was this gap sort of missing for functional safety and that SOTIF sort of filled that gap. Could you describe some of the key differences that are there between the standards?
Akram: Absolutely. So the key difference is, like I said, there was a gap. The gap was pretty evident, we’re talking about malfunction. If there is a fault, that fault would lead to a hazard, that’s ISO 26262, that’s traditional functional safety.
Now, what happens if there is nothing wrong in the vehicle, no malfunction, and we still have a hazard? So let me give you a metaphor. Imagine that you have a knife and you bought the knife. Your intention is to chop vegetables. So it’s a very sharp knife. The functionality is great, you’re chopping the vegetable, there is no malfunction, you’re chopping the vegetable. Now, by mistake, unintentionally, you cut your finger with it, it’s a hazard. Now, there is no malfunction still in the knife, the knife is 100 percent functional, it’s your intention that was to chop vegetables, but somehow, unintentionally, you cut your finger. And that’s where the safety of the intended functionality came in.
The famous example of such hazard is this high profile Tesla incident that happened, I don’t know, five, six years ago, where in a junction, because of the lighting condition, Tesla’s ADAS system could not recognize a truck that was passing the junction. And the driver happened to be watching Harry Potter and he didn’t pay attention. And this was fatal, I mean, the driver died. This was such a fatal accident. And there was nothing wrong in Tesla’s ADAS functionality, it’s just that this certain condition, there was no malfunction, this certain condition was not trained, and the ADAS system was not able to detect under certain lighting condition.
And that was the reason, but when we entered, when we started with this, it turned out vastly complex, the whole sphere of SOTIF, when you’re talking about the environment. I’ve just given you one example. So the environment is theoretically infinite. There can be infinite situations and there can be situations that we don’t know about. And the fact of the matter is, we don’t know what we don’t know. When you know something, you can take measure, that’s traditional ISO 26262. Now, we have this unknown unknown. You don’t even know what you don’t know. So that makes it extremely challenging and that’s why the whole process of autonomous vehicle development is going to be a continuous development process, we’ll have to continuously learn and incorporate safety and all those.