Tag Archive for: risk management

Image showing currency, meant to portray the importance of investing in a Requirements Management and Traceability Solutions as a wise financial choice.

A Wise Investment: Requirements Management and Traceability Solutions During an Economic Downturn

In the realm of business, the economy is a dynamic force that ebbs and flows, much like the tide. Economic downturns, while challenging and sometimes scary, can also present unique opportunities for businesses to reevaluate their strategies, streamline their operations, and invest wisely for future growth. One such investment — that might not be immediately obvious but holds immense potential — is in requirements management and traceability solutions. In this blog post, we’ll explore why it makes sense to invest in these solutions during an economic downturn.

1. Enhanced Efficiency and Resource Optimization:

In times of economic uncertainty, operational efficiency becomes paramount. Requirements management and traceability solutions provide a structured framework for capturing, organizing, and tracking project requirements throughout their lifecycle. By optimizing requirements management processes, businesses can ensure that resources are allocated to the most critical aspects of a project. This reduces the risk of scope creep, minimizes wasted effort, and enhances overall project efficiency. With a clear understanding of project goals and dependencies, teams can work cohesively, to not only avoid both unnecessary and costly duplication of work but also enable organizations to allocate resources where they are most needed.

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

2. Risk Mitigation:

Economic downturns often come with increased financial constraints, so allocating resources to any new software investments might seem counterintuitive. But investing in requirements management and traceability solutions can truly act as a risk mitigation strategy. The right requirements management and traceability solutions facilitate comprehensive end-to-end impact analysis, allowing businesses to understand how changes to requirements can affect other aspects of the project or organization. By foreseeing any potential pitfalls and addressing them proactively, companies can increase process efficiency, minimize costly errors, rework, and recalls, and streamline development to accelerate time to market — ultimately safeguarding their investments in both time and resources.

3. Regulatory Compliance and Quality Assurance:

In certain industries, compliance with regulatory standards is non-negotiable. Implementing robust requirements management and traceability solutions can streamline the process of documenting and demonstrating compliance. These solutions enable clear documentation of how each requirement maps to relevant regulations, making audits smoother and reducing the risk of non-compliance penalties. Moreover, well-managed requirements also lead to improved quality assurance practices, ensuring that products or services meet the desired standards even during challenging economic periods.

4. Agility and Adaptability:

Economic downturns often require businesses to pivot their strategies quickly to address changing market dynamics. Requirements management and traceability solutions provide a foundation for agile decision-making. When requirements are well-documented and linked, it becomes easier to assess the impact of changes, make informed decisions, and adapt to shifting priorities without causing disruptions. This agility allows businesses to seize new opportunities and respond to market demands more effectively.

RELATED: Requirements Traceability Diagnostic

5. Long-Term Cost Savings:

While the initial investment in requirements management and traceability solutions might seem significant, it pales in comparison to the potential long-term cost savings. When requirements are managed efficiently, projects are less likely to overrun budgets or experience delays due to misunderstandings or miscommunications. The cost of fixing issues after they’ve occurred is far higher than preventing them in the first place. By investing in proper requirements management, businesses can avoid the financial strains that arise from project failures or inefficiencies.

Conclusion:

In the face of economic uncertainty, investing in requirements management and traceability solutions might not be the most obvious choice, but it’s certainly a strategic one. These solutions offer a structured approach to managing projects, reducing risks, enhancing efficiency, ensuring compliance, and promoting adaptability. By making this investment, businesses position themselves for not only surviving economic downturns but also thriving in the long run. As the tide of the economy inevitably turns, those who have laid a strong foundation in requirements management will be better equipped to ride the waves of change.

Download the complete eBook to access simple, interactive ROI calculators and learn the financial benefits of investing in a requirements management solution during an economic downturn >>
Why Investing in Requirements Management During an Economic Downturn Makes Good Business Sense


Image showing a lock for security in product development

“While the security of IT hardware and software has strengthened in recent years, the security of Internet of Things (IoT) … has not kept pace,” Microsoft’s Digital Defense Report 2022.

The Internet of Things (IoT) promises a flood of amazing new products, including autonomous cars, networked medical devices, home automation, and new devices in industrial applications. But data breaches affect millions annually, and there is real fear that hacked devices could be used for surveillance, fraud or even weaponization. With 17 billion IoT devices in the world the surface area for attack dwarfs that of traditional computer malware.

Make Security a First-Class Citizen During Development

Too often with IoT devices, security is an afterthought; sometimes it even gets scrapped due to time and resource constraints. But organizations cannot provide reliable security after the fact. Security must be addressed from day one, by both product development and leadership.

Consider architecture: There are many chipsets available that provide a security architecture for embedded devices, but less than 4% of new devices in 2018 include embedded security. The explanation for this oversight is obvious: Development begins without security in mind, leading to an architecture that omits it. And it’s not feasible to change the underlying architecture of a product after release to account for security.

RELATED: Four Key Considerations When Choosing a Cloud-Based Engineering Tool Provider

OtA Updates Should Be a Requirement

Many devices that are shipped to consumers have little to no update mechanism, or their update mechanism requires the customer to be aware of an update and go through a cumbersome process. This inevitably leads to out-of-date software that is an easy exploit for hackers.

Just like the PC industry, IoT developers must embrace secure, OTA updates to keep their customers safe. It is not enough just to offer updates; developers should push security updates to devices that are connected to their services. This is not just good business practice; it protects the service provider’s critical SaaS infrastructure as well.

The Argument for Security in IoT Devices

Security is often seen as a cost, but if you understand it correctly, you can turn it into a value proposition or a competitive advantage that customers are willing to pay a premium for. For instance:

  • Today’s customers are increasingly concerned with security and privacy. Companies like Apple can charge a premium because they address these concerns.
  • Insufficient security can lead to counterfeiting.
  • Good security increases brand value and decreases the risk of brand erosion.
  • Security is required by law, and failure to comply can result in heavy fines.

RELATED: What is DevSecOps? A Guide to Building Secure Software

Security as an Integral Part of Product Development

Once you recognize the importance of security, it’s logical to make it an integral part of your product development process. This means, amongst other things:

  • Security is part of the stakeholder needs and therefore must be part of the core requirements. This also applies to regulatory requirements, such as those derived from legislation like GDPR.
  • Make sure your architecture fits your security requirements, since architecture is one of the most difficult (and expensive) things to change after the fact.
  • Ensure your security requirements are tested. You achieve this by maintaining correct end-to-end traceability from requirements to test results.
  • Collaborate on all levels. If you want to prevent security from being patched on an ad-hoc basis, make sure that all teams communicate properly. For instance, an engineer might be tempted to write custom code to detect a Denial of Service (DoS) attack, but this might be addressed more efficiently on the architecture level.
  • Implement a product line strategy and perform systematic reuse. Security extends to the complete lifecycle of products, so you must be prepared to provide security updates for years to come. Also, reuse allows teams to use previously tested elements, improve quality and accelerate development.

Embracing security today provides more than just a competitive advantage – it may be crucial for survival. While a product development platform alone is not enough to address security, it is an integral component for implementing security policies and frameworks.


ISO 240891

ISO 24089, developed by the International Organization for Standardization (ISO), is a standard that provides guidelines for managing software updates in a methodical and orderly way. Planning, testing, deployment, and monitoring are all included in the framework for managing the software update process that is specified by the standard. The main requirements and advantages of ISO 24089 as it relates to software update management systems will be highlighted in this post.

Software is a crucial building block of the modern connected and automated vehicles. Once the product is sold to the customer it starts its utilization phase. Important software updates are needed to keep the vehicle up to date, roll out new features, eliminate defects or bugs and most importantly redress security vulnerabilities. These software updates are in most cases delivered remotely through over-the-air technologies. There is no need to necessarily take the car to a workshop in order to install these updates. These over the air technologies make the whole process vulnerable and a proper framework needs to be set up to organize this process and make sure that the right updates are delivered to the right vehicles. Therefore, companies producing cars must have a software update management system. An organization may run the risk of security flaws, software bugs, and compatibility problems if software upgrades are not managed properly. The UNECE (United Nations Economic Commission for Europe) has put a new regulation R156 in place to regulate the Software update and software update management system which by this regulation become mandatory for the type of approval process in the regulated markets. The goal of ISO 24089 is to provide a thorough method for managing software updates that reduces risks and guarantees that updates are implemented in a consistent and efficient manner to support compliance with the UNECE R156.

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

The framework of ISO 24089 revolves around a list of conditions that must be fulfilled in order to comply with the standard. These prerequisites consist of:

  1. Policy Planning: Establishing a policy for software updates and creating a plan for handling updates are requirements for the organization. The goals and parameters of the software update management system should be specified in the policy, along with the roles and duties of the various participants.
  2. Risk Management: The company must evaluate the risks posed by software updates and put precautions in place to reduce those risks. This entails locating potential security gaps and making sure upgrades don’t interfere with business as usual.
  3. Testing and Validation: Before updates are deployed, the organization needs to set up a process for testing and validating them. This procedure should make sure that updates are compatible with the current software environment and do not add any new errors or compatibility problems.
  4. Deployment: A procedure for deploying updates to production environments must be established by the company. This procedure should guarantee that updates are distributed in a regulated and safe manner, reducing the possibility of operations disruption for the company.
  5. Monitoring: Establishing a process for monitoring and evaluating the software update management system’s performance is necessary for the company. Regular audits and evaluations of the system’s effectiveness and the identification of potential improvement areas should be part of this process.

RELATED: [Webinar Recap] Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System

Businesses can make sure that their software update management system is well-designed, efficient, and compliant with ISO 24089 by following these requirements. The standard offers businesses a framework for creating a dependable and consistent procedure for managing software updates, lowering the risks involved with updates, and making sure upgrades are applied quickly and effectively.

One of ISO 24089’s major advantages is that it aids businesses in raising the caliber of their software updates. Organizations can guarantee that updates are adequately tested and verified before deployment by putting in place a structured procedure for testing and validation, which lowers the chance of errors and compatibility problems. As a result, the organization’s overall operational environment becomes more solid and reliable.

The ability to lower the risk of security vulnerabilities brought on by software upgrades is another advantage of ISO 24089. Organizations can lessen the risk of cyberattacks and other security breaches by putting in place a risk management plan that involves the identification and mitigation of potential security threats.

Additionally, ISO 24089 supports businesses in enhancing their adherence to legal specifications for software updates. Numerous regulatory frameworks mandate that businesses have a formal, written process in place for handling software changes. Organizations can demonstrate compliance with these criteria and lower their risk of regulatory fines and other consequences by adhering to ISO 24089.

ISO 24089 assists enterprises in lowering the risks related to updates, enhancing the quality of their software environments, and meeting regulatory obligations by providing a thorough framework for managing updates. A more effective, dependable, and secure software update management system can help organizations that use ISO 24089 improve their overall operational performance and lower risk.

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


Research Note

In this blog, learn how a Traceability Score™ can act as an empirical way to reduce the risk of late requirements.

Traceability Score™ – An Empirical Way to Reduce the Risk of Late Requirements

Executive Summary

One of the main causes of rework, delays, and cost overruns in product development is the creation of new requirements late in the process. This is a well-known risk in product development, but what management practices can empirically be shown to reduce this known risk?

Using our proprietary database of metadata from over 50,000 complex product development projects, we were able to determine that the Traceability Score™ is an empirical method to reduce late requirements. In fact, teams that maintain a high Traceability Score reduce the burden late requirements have on their project by 67% compared to teams with low traceability scores.

  • With this knowledge, our recommendation is that practitioners measure and monitor the Traceability Score™ of their projects to resolve issues early and ensure that the risk of late requirements is kept to a minimum.

Dataset Background

Jama Software® has the world’s largest, live dataset of engineering process performance with over 50,000 engineering projects updated and growing continuously. Leveraging this dataset, it is now possible to determine empirically which management practices improve the performance of the product development process. To learn more about our benchmarking, please review our Traceability Benchmarking Report.

The Empirical Questions

In this analysis we will explore three key questions:

  1. What are late requirements?
  2. How do late requirements negatively impact projects?
  3. Does maintaining a high Traceability Score reduce the risk of late requirements?

What are late requirements?

For the purpose of this analysis, we define “late requirements” as those requirements created after the completion of a project’s requirement decomposition phase which we estimate as spanning the middle 50% of all requirement creation activity (creation and refinement). To illustrate what late requirements look like, we show two actual projects below with requirement activity plotted over time.

Requirement Creation Over Time

 

In the Timely Project, requirement creation occurs in a defined requirement decomposition phase to form a necessary and sufficient set of requirements, with very few requirements being added after the fact (e.g. in fig (a), only 1.3% of requirements created late). In the Late Project’, requirement creation bleeds into future phases of the project, leading to a significant amount of late requirements (e.g. in fig (b), 9.2% of requirements are created late).

RELATED: Requirements Traceability Benchmark

How do late requirements negatively impact projects?

We can measure the outsized burden late requirements have on project teams, which we have illustrated for our two projects below. We define late requirement burden as the total number of requirement activities (creation and refinement) attributed to late requirements as a percentage of all requirement activity.

Impact of Late Requirements on Project Team Activity Burden

In the Timely Project, minimal late requirements enable better forecasting of project completion, and limits the rework and cost brought on by late requirements (e.g. in fig (c), late requirements only create an additional 8% burden).

In the Late Project, the high volume of late requirements makes it much harder to forecast project completion as the scope of the project is constantly changing, and project teams need to accommodate the late requirements (e.g. in fig (d), late requirements contribute an additional 31% burden).

Unsurprisingly, this additional burden of late requirements has an impact during testing for requirement validation. In our actual project examples, the Late Project has a test failure rate over 3x that of the Timely Project.

percentage chart

RELATED: Unlocking The Power of Live Traceability with Jama Connect®

Does maintaining a high Traceability Score reduce the risk of late requirements?

A core theorem of Systems Engineering is that maintaining high requirement traceability from the start of a project reduces the risk of late requirements and negative product outcomes. With our project dataset we can now test this theorem empirically. We define traceability as a measure of a project’s ‘expected’ traceability that has actually been established and calculate the Traceability Score as follows:(1)

established over expected

For our example projects, the Timely Project achieved a Traceability Score over 6X that of the Late Project; suggesting that maintaining a high Traceability Score throughout the project reduces the risk of late requirements.

traceability chart

To further determine if Traceability Score correlates to late requirements, we divided our dataset of projects into quartiles based on their Traceability Scores (Quartile 1 = bottom 25% traceability score, Quartile 4 = top 25% traceability score) and then compared the distribution of ‘Late Requirements Burden’ across these quartile groups. What we found is that projects within the bottom traceability quartile had a median Late Requirements Burden 3x greater than those in the top traceability quartile. In other words, the evidence supports that projects managed with higher traceability generally experience less risk from late requirements.

Recommendation

Our analysis has shown that late requirements negatively impact projects and that managing projects through a Traceability Score is the only empirical way to reduce the risk of late requirements. Below you can see how one can measure the Traceability Score over time as a project progresses to ensure system engineering best practices are being followed. A low or falling Traceability Score can quickly identify areas to address to reduce the risk of late requirements.

Here you can see how managing the Traceability Score directly as the project is underway would have identified the risk early in the Late Project.

Benchmark Chart

To learn more about achieving Live Traceability™ on your projects, please reach out for a consultation.

Interested in learning more? Download the entire Research Notes: Traceability Score™ datasheet HERE.

 


ISO 13485

In this blog post, we will cover key components of the important medical device standard ISO 13485 and cover steps for successful adherence. 

In the complex world of medical device development, teams not only face challenges of innovation, but also a shifting regulatory environment and evolving standards.

Balancing the competing interests of customers and stakeholders with the guidance and regulations from different entities across global boundaries presents challenges that even the most organized and methodical teams may struggle to meet.

In this environment, systems thinking can greatly improve the ability of medical device development teams to get products from the idea stage to market. By breaking down complex problems into manageable pieces, teams can better evaluate their systems and streamline and strengthen processes.

Using an applied systems approach will also help resolve inefficiencies in the development process and produce the outputs necessary for the design history file (DHF).

A growing number of organizations and teams are already pursuing a general systems approach by applying the guidance in ISO 13485:2016. This standard helps define a framework for the Quality Management System (QMS) for medical device development and pushes the development process naturally toward a systems approach. But for those teams that have not yet adopted the standard, adding one more document or piece of guidance to the overall process can feel like another layer of complication.

It doesn’t have to be. Adopting this standard can help standardize and systematize the medical device development process. Though it may look daunting at first, once adopted, ISO 13485 can streamline processes and position organizations for a better outcome with regulatory requirements.

RELATED: How to Executive a Successful Design Review When Building Medical Devices

The Purpose of ISO 13485

The standard was developed by the International Organization for Standardization (ISO) to outline the standard for a Quality Management System (QMS) for the design and manufacture of medical devices.

The ISO defines “medical device” as “a product, such as an instrument, machine, implant or in vitro reagent, that is intended for use in the diagnosis, prevention and treatment of diseases or other medical conditions.” It is a stand-alone document designed for use by organizations of any size involved in any stage of medical device development, from design to production to installation to service of devices. Both internal and external parties can use the standard to support the auditing process.

ISO 13485 is the most common standard for quality management in the field of medical device development across the globe. Adoption of the standard indicates a commitment to the highest quality and safety across the development process, and it provides a foundation for QMS requirements.

While not required by all government entities, the standard does provide a good foundation for addressing regulations such as the EU Medical Device Directive and the EU Medical Device Regulation. In 2018, the FDA proposed a rule that would align US FDA 21 CFR 820 with ISO 13485:2016; this rule would make this standard the mandatory QMS for medical devices.

Note: The rule was set for release in 2019; however, as of December 2020, the rule was still forthcoming. Check for current guidance.

RELATED: Your Guide to Selecting a Medical Device Development Platform

Requirements for ISO 13485 Adherence

Though adoption of ISO 13485 may look complicated or daunting, in reality, adhering to the standard helps eliminate some of the ad hoc nature of requirements and systems in the medical device field.

With increasing worldwide adoption of ISO 13485 by both companies and government entities, the medical device industry should start to realize some harmonization and consistency of processes and systems. This standardization will help streamline the industry overall and allow important innovations a smoother and potentially faster route to market.

The requirements to obtain ISO 13485 certification start with a QMS. ASQ defines a Quality Management System as “a formal system that documents the structure, processes, roles, responsibilities and procedures required to achieve effective quality management.” The QMS must include documentation that defines the overall scope and implementation of the QMS; important documentation includes Quality Policy, Quality Objectives, and Quality Manual.

Bottom Line These documents should be sure to address customer requirements. In addition, organizations need to create mandatory and additional processes and requirements necessary for all stages of development. Examples of documents required by ISO 13485:2016 can be found here.

Key Takeaways from Our Complete Guide

  • ISO 13485 and systems thinking go hand-in-hand; teams will find that adoption of ISO 13485 directs them toward systems thinking.
  • Adoption of this standard will streamline processes and position medical device teams for better regulatory outcomes.
  • ISO 13485 is a stand-alone document; however, it closely aligns with ISO 9001:2008 and EN ISO 13485.
  • ISO 13485 and ISO 14971 are related, but ISO 14971 is more focused on risk management – the two standards can be used in tandem.
  • This standard is not mandatory; teams can develop a Quality Management System (QMS) without the standard as long as it meets regulatory requirements. However, adoption of the ISO 13485 will create a QMS that is ideally positioned to meet the requirements of various regulatory and legislative entities, including the EU.

Jama Software’s Complete Guide to ISO 13485 for Medical Device Development covers requirements for adherence, the difference between ISO 13485 and other medical device standards, and steps for successful adoption and certification.

Download The Complete Guide to ISO 13485 for Medical Device Development to untangle everything there is to know about this important standard.

SEE THE FULL GUIDE

How EN 50128 Establishes Functional Safety Standards for Railway Software

In increasingly complex, rapidly evolving, and highly regulated industries, product development teams must build safety-critical products, while streamlining risk management and keeping accuracy and security at the forefront. This blog post will define functional safety and EN 50128 and explain why compliance with safety standards is critical to railway software and industrial manufacturing teams.

What is Functional Safety?

As part of the overall safety of a system or piece of equipment, functional safety is a key component that builds upon automatic protection. The best way to reduce risks in industrial manufacturing is to ensure automated protection systems have predictable responses to malfunctions or failures.

The concept of functional safety applies to everyday life and every industry you can think of. The International Electrotechnical Commission (IEC) provides this example of transportation functional safety:

“When you board a train, the subway or a cable car, functional safety ensures that the doors close before the vehicle departs and that they don’t open while it is in movement. They also ensure that the railway signaling system helps avoid that an oncoming train crosses your train’s path.”

When systems fail to operate, significant disasters can occur. Safety standards, such as EN 50128, are designed to reduce risk tolerance around these events.

What is EN 50128?

EN 50128 is a certification standard issued by CENELEC (the European Committee for Electrotechnical Standardization). The international version of this standard is IEC 62279. This standard specifies the requirements for railway applications, including communication, signaling, and processing systems for railway control and protection systems software.

RELATED: IEC 61508 Overview: The Complete Guide for Functional Safety in Industrial Manufacturing

According to Engineering360, the European standard “specifies the process and technical requirements for the development of software for programmable electronic systems for use in railway control and protection applications.” It aims toward any practical use where there are safety implications. This European Standard applies exclusively to software, the interaction between software and its system, and all safety-related software used in railway control and protection systems, including:

  • Application programming
  • Operating systems
  • Support tools
  • Firmware

Why compliance with safety standards such as EN 50128 is critical to railway software and industrial manufacturing teams

Eliminating all chances of risk may not always be possible. However, manufacturers must continuously seek strategies to mitigate potential safety issues, which is why industry experts in industrial manufacturing have created standards, such as EN 50128, and IEC 62279, to reduce risk and support the development of safety-sensitive products.

According to TUV SUD, “functional safety ensures that safety risks due to hazards caused by the mal-functional behavior of systems are reduced to an acceptable level. These safety risks are increasing in the rail industry as rail technology is becoming more and more complex, with both hardware and software interacting in different ways and components that are sourced from multiple markets.”

RELATED: The Top Six Things You Should Know About TÜV SÜD

How Jama Connect® Can Help Organizations Achieve EN 50128 Compliance

Compliance is an essential goal for organizations in regulated industries, but it is not the only factor when delivering safe and reliable products to market. Organizations need defined processes for development and production and detailed end-to-end traceability to achieve compliance, from high-level user needs to validation and verification.

Jama Connect® is TÜV SÜD certified for developing safety-related products. Jama Software® is the first vendor that is both SaaS and Agile to receive the certification. In 2019, Jama Software completed additional certification as a software tool for railway applications according to EN 50128.

Focus and rigor in the product development lifecycle drives compliance as an outcome. While the ultimate responsibility of functional safety remains with the customer, Jama Connect eases the path to compliance so companies can focus on building products right.

Ensuring Compliance & Managing Risk with Jama Connect

Jama Connect is engineered to ensure quality with frameworks aligned to key industry standards which streamline design, development, testing, and risk management while maintaining compliance. Teams can quickly see the full historical context around a requirement when they contribute to a project — reducing the probability of errors as well as the time and overhead spent on risk analysis.

Interested in learning more? Watch our webinar, Lessons Learned for Reducing Risk in Product Development


In this blog, we recap the “Implementing Requirements Management for ISO 21434” webinar.

As the automotive industry becomes more complex and more connected, cybersecurity is emerging as a major concern, and therefore priority, for development teams.

According to Juniper Research, there are 206 million cars on the road with embedded connectivity and by 2025, the number of vehicles leveraging 5G embedded connectivity will surpass 30 million –– over eight million of those in the United States alone.

One standard in particular has been developed to address cybersecurity risks in the design and development of car electronics – ISO SAE 21434 “Road vehicles — Cybersecurity Engineering.”

In this session we will discuss:

  • Overview of managing requirements in ISO 21434
  • Similarities between requirements for functional safety and cybersecurity
  • Updating an example requirements management data model for cybersecurity requirements
  • Proposal for implementing a TARA in a requirements management database

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

Implementing Requirements Management for ISO 21434

Adrian Rolufs: Welcome to this webinar on Implementing Requirements Management for ISO 21434. My name is Adrian Rolufs, and today I’ll be taking you through the process we went through at Jama Software to update our data models for supporting 21434. I am the Director of Solutions at Jama Software, focused on our automotive and semiconductor business, and my experience is primarily focused on working with customers who are implementing requirements management and traceability solutions in the automotive industry. Today, we’ll go through an overview of what the impact on requirements management is from 21434. We’ll discuss the similarities between the requirements for functional safety and cybersecurity as it applies to requirements management. We’ll go through an example of how we updated the requirements management data model to support the cybersecurity requirements. And then we also have a proposal for how to implement a TARA in their requirements management database. We’ll go through reasons why you might want to consider such a solution. So, let’s dive into it.

First of all, let’s spend a little bit of time explaining what Jama Software is. Jama Software is a company that produces a requirements management solution. We focus on providing a complete tool for implementing a V model, all the way from high-level needs analysis into requirements and system design, through to integration and verification and validation. Our customers use Jama for managing requirements, building traceability to verification and validation, and reviewing all of that in a live online database to make sure that their documentation is of high quality, as well as making it as easy as possible for engineers to do that. And as you can see, there are a lot of companies across industries, especially in automotive, that have adopted our solution as their primary requirements management solution.

So let’s talk a little bit about the impact that 21434 has to requirements management. As you’re maybe familiar, there’s a number of clauses in 21434 focused on the cybersecurity engineering best practices for development of road vehicles. It focuses on development of electronic and software systems and specifically goes through and defines best practices for the processes for identifying cybersecurity risks, identifying ways to mitigate those risks, as well as development of the products that are going to implement features to mitigate those cybersecurity risks. And it supports the implementation of a cybersecurity management system which is required for many automotive manufacturers these days.

Related: What is the Urgency Behind Automotive Cybersecurity?

Adrian Rolufs: So within the framework of ISO 21434 there are specific areas that have the biggest impact to your requirements management process. The first one is within the cybersecurity activities and assessments. There are planning documents, there’s a cybersecurity case that has to be developed, and there are work products that have to be managed to be compliant with ISO 21434. And a lot of those have an impact to the work that would typically be done in a requirements management solution. So we’ll be looking at taking those requirements into account in how you would use a requirements management solution. The really core piece of it is the concept and product development phases of ISO 21434. Those directly result in new requirements that need to be managed, designed, that needs to be implemented to meet those requirements and verification and validation activities. And these are the core activities that are typically managed in a requirements management solution, like Jama Software’s Jama Connect.

This is also a really important area to avoid creating silos in an organization. It’s very easy to create different organizational structures for managing cyber security from traditional requirements management processes. And it’s our belief at Jama Software that all requirements should be managed in a comprehensive and consistent way so that development teams can easily see what all the requirements they need to meet, and the organization can track all requirements in the same way. This leads to higher quality products, leads to more consistency, and it leads to more on time delivery. So as we’ll see today, we have developed a framework that allows you to manage these requirement design and verification and validation artifacts that are specifically required for cyber security in the same way as you would manage other requirements in verification and validation.

Related: Design Transfer: Best Practices for Translating Your Device Design into Manufacturing Specifications 

Adrian Rolufs: So another standard that a lot of organizations are following when they’re thinking about cyber security is ISO 26262. So this is the standard for functional safety and road vehicles, and it’s very common that a product or a system that needs to adhere to the cybersecurity standards also will have functional safety considerations as well. And so it’s very common to have a process that needs to accommodate both of these standards. Fortunately, there are quite a few similarities between them so it’s quite easy to develop a process that can allow you to build systems that meet both standards. Both of the standards start from the identification of an item, which is also commonly the system that you are analyzing, and help you identify the risks to functional safety or to cybersecurity, and then derive new requirements on your system in order to be able to mitigate against those risks.

They both define a V model that allows you to organize requirements and validation and verification according to system engineering best practices. And they both cover the development of a conceptual system, the full system, and then the hardware and software within those systems. And specifically, they both focus on the electronics and the software that runs on those electronics as opposed to mechanical systems, which typically don’t really have a functional safety or a cybersecurity consideration.

So in order to bring those aspects of those standards into a requirements management data model, we need to take a look at what those standards require and how is that similar or different than how you would typically implement requirements management without taking those standards into consideration. So let’s take a look at the key aspects that feed into product development. So for many organizations, they’re already considering functional safety analysis as an input to their product development. So developing a new product starts with market analysis, understanding what the needs in the market are, understanding what types of products you could build to meet those needs. And that’s the key driver for the business justification for developing the products in the first place, and building a product that’s going to meet the needs of the market. So, that’s always the first and foremost consideration.

To watch the full webinar, visit: Implementing Requirements Management for ISO 21434

RELATED


Risk Medical

In this blog, we recap the “Understanding Integrated Risk Management for Medical Device” webinar.

Companies involved in developing medical devices understand the importance of risk management, but their approaches can vary significantly in terms of the time it takes to manage risk, the ability to connect risks to specific requirements and tests, and the capacity to pull together relevant documentation for an audit. To meet these challenges, medical device developers need a comprehensive approach to risk management.

In this presentation, industry and solution experts will explore how teams can integrate risk-based thinking into their product development lifecycle.

Attendees will learn more about:

  • Risk management in the medical device industry
  • Guidance and best practices to follow
  • How to manage risk analysis
  • The importance of risk traceability throughout project activities

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

Understanding Integrated Risk Management for Medical Device

Mercedes Massana: So today we’re going to talk about risk management. First, we’ll start with the basics, the things we need to know to understand risk management, then we’ll talk about the elements of a risk management process, about some risk management tools that we can use, and then we’ll end with risk management and incorporating that into your traceability matrix.

So let’s start with the basics. So what is risk management? It’s the systematic application of management policies, procedures and practices to the task of analyzing, evaluating, controlling and monitoring risk. And in this case, we’re talking about product risk, not so much project risk, right? So all medical devices carry some level of risk, no matter how simple they are. There’s always some level of risk for the medical device, and we need to consider who can be hurt by the medical device. Who does this risk apply to? And that can be obviously the patient, but it can also be the operators or clinicians, right? The nurses. It could be bystanders, it could be service personnel working on the device. It could be even other equipment if we interfere with other medical equipment, and it could even be the environment.

Related: Requirements Debt: A Medical Product Program Risk

Mercedes Massana: It is the responsibility of the manufacturer to determine how much risk they’re willing to accept, or the market is willing to accept for the intended use of the device. So the regulatory agencies don’t tell you what is acceptable from a risk perspective, but it’s up to the manufacturer to determine that.

So why do we practice risk management? Well, first of all, it’s so that we can produce safe products and release only safe products, right? So we want to prevent safety-related problems in the field. Having to recall product is very bad for companies, right? There have been companies that have gone out of business because of safety issues in the field. Having a good, well-documented risk management file can substantiate due diligence if somebody tries to sue you, so you have the documents that can help support that you did the right things.

It can also encourage a defect-prevention mindset. So when you start practicing risk management early on in development, you start designing with defect prevention in mind. You want to prevent defects that can cause harm and risk. It helps you identify potential safety issues early while you can still influence the design, right? And then, from a regulatory perspective, documents from your risk management files are always needed for submissions, and in audits, most likely these documents would be presented in audits.

And then it also allows risk-based decisions to be made throughout the product life cycle. So we think of risk management just as the product and things we need in order to get regulatory approval or to have in an audit, but really, having a robust risk management file can help us make decisions and verification, validation in manufacturing, even for our suppliers and what controls we ask them to implement. So having a robust risk management file can really help us in every facet of product development.

Related: 3 Ways Requirements and Risk Management Continue After Market Launch 

Mercedes Massana: So compliance is a big part of risk management. ISO 14971 is the application of risk management to medical devices. It is an FDA-recognized standard. It’s actually even called out in a couple of guidance documents from FDA, and it is referenced by a number of IEC standards. So we need to be compliant with ISO 14971 in order to get through FDA, and in order to achieve the CE mark. ISO 13485 mentions risk management 15 times, and it says that we must consider risk in supplier controls, for verification, for validation, in testing and traceability, for CAPA, even for training of personnel.

So this tells you how important risk management is to having a medical device, developing a medical device, and maintaining a safe device in the field. So risk management should be practiced first as a system-level activity, so we should start risk management from the top down. That means that very early in development, when we start our design efforts, we analyze the risk that the system can perform, just by knowing the intended use. We don’t even need to have a design. Then we attempt to mitigate those hazards and we drive risk controls through requirements that then get implemented in our design, so only the system can actually cause a hazard. The system might have many components, but unless I have all of the system put together, I can’t cause a hazard.

To watch the full webinar, visit: Understanding Integrated Risk Management for Medical Device

RELATED


reduce risk product development

In this blog, we will recap a webinar on reducing risk in product development

Over the last 20 years, product development complexity has expanded exponentially, creating innovations in areas such as space tourism, autonomous vehicles, satellite communications, and more. In this webinar, Kemi Lewis, Senior Consultant at Jama Software, will demonstrate how Jama Connect© creates Live Traceability™ through siloed development, test, and risk activities to effectively reduce risk in the product development process.

In addition to a walkthrough of the platform and our Live Traceability dashboard, we’ll cover:

  • The critical challenges to reducing risk in product development
  • Why deeming requirements “good enough” to allow teams to proceed with an acceptable level of risk culminates in static requirements, unplanned rework, and compounded product risk
  • How “Project management” activity is a fallacy — it is the management of requirements, people, risks, change, opportunities, expectations, resources, commitment, and suppliers

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

Reducing Risk in Product Development

Kemi Lewis: Today’s agenda covers a deep dive into the critical challenges to reduce the risk in product development, what are the viable solutions to this problem, key takeaways, and wrapping up with a question and answer session at the end of the webinar

Let’s get right into it. What are the main critical challenges that product development teams are facing? In my experience, the main factors that lead to adverse product outcomes and risk are, number one, no upfront and iterative collaboration during requirements and design creation and review stages due to limited customer and cross-functional team involvement in the review and approval of requirements. This lack of cooperation results in missed and misunderstood requirements driving the product design into severely costly errors later on.

Second factor, no digital thread connecting the product and team to the end to end product life cycle process. What do I mean by the digital thread? A digital thread is a data driven architecture that links together information generated from across the product life cycle and is envisioned to be the primary and authoritative data and communication platform for a company’s product at any instance in time. Without this digital thread, there’s no ability to track the life of a requirement through development, test and release.

Related Reading: What Is the Definition of a Digital Thread

Kemi Lewis: This missing digital thread results in static requirement documents rarely viewed by critical stakeholders maintained in Word, Excel or standalone tool used only by a few as a repository. I’ve personally experienced this at companies where only the systems engineers were accessing the repository and the rest of the product development team from product managers down to testing and integration engineers never accessed it.

You can only imagine how this turned out. Countless rework during testing and integration in addition to postlaunch rework this early, which was severely costly to the customer and left them very unhappy. So lacking this digital thread leads to no management visibility into crucial metrics for the end to end process and no identification of process risk patterns, such as delays in development, multiple test failures, rework cycles, etc.

Third main factor is having a low level of requirements management maturity. Let’s discuss this in more detail. Level zero: There are no formal requirements. So no documentation exists for user or system requirements. Instead, development operates off of user stories with no clear distinction between the functionality of the system being built and expected user experience. Level one: Document based requirements. Static requirement documents are created and most often maintained by each author on their desktop with various emails, slack comments containing more information. This especially gets fun when you have to merge 10 different versions of the same document from 10 different people from 10 different timeframes, none of which have visibility to each other’s feedback in real time. I’ve seen this at several companies where they lose technical product proposals due to this inefficiency of being able to get a proposal out in time representing the right design specifications of their product.

Related Reading: Bridge Engineering Silos with Living Requirements Management in Jama Connect

Kemi Lewis: Level two: Siloed requirements tool. A standalone tool in place to draft review, track comments, version and store static requirements documents, compliance steps, limited reuse, defects and recalls. Level three: System based compliance. Compliance is the forcing function to shift from static to live traceability to meet standards for requirement validation, verification and traceability into a single end to end system. Level four: Product risk reduction. A process centric focus to reduce the likelihood of all forms of product risk via a system enabled live traceability. This requires detection and alerts for specification and functional changes, process exceptions and test failures with resulting impact analysis. The risks mitigated include failure to meet the needs of the customer, failure to perform specific functions, delays, cost overruns, defects, compliance and regulatory gaps, delays and fines in addition to recalls.

And the last level of maturity, level five: Development process improvement. Moving past compliance and risk into the spirit of standard based on quality management and process control. These stages place focus on measuring, managing and improving the product development process. The unintended result of this fragmented process is that critical function such of requirement, traceability, verification, validation, risk mitigation, product integration and compliance are often fraught with information gaps, defects, delays, reworks, recalls, missed requirements and significant manual effort. This includes all areas of the complex product system and software delivery life cycle that can experience negative outcomes and should be actively managed to reduce the likelihood of appearance, such as performance.

Watch the full webinar to learn more about Lessons Learned for Reducing Risk in Product Development

One of the early steps I advise my clients to take when developing their medical device is to determine the class and classifications of their medical device. In conjunction with the complexity of the device, understanding the class and classification sets the foundation for your product development timeline and effort. 

This post gives a basic introduction to FDA medical device classes and classifications and the implications for your product development schedule and requirements management. 

What are FDA medical device class and classifications? 

The FDA established three regulatory classes based on the level of control necessary to assure the safety and effectiveness of the device. Classification is based on the intended use of the device and indications for use, as well as the risk the device poses to patients and users.   

There are three classes: Class I, Class II, and Class III. Class I devices are those with the lowest risk, Class II devices have a greater risk, and Class III includes devices with the greatest risk.   

The FDA also established classifications for over 1,700 generic types of medical devices and grouped them into 16 panels, or medical specialties. Example panels include Cardiovascular Devices and Radiology Devices. Each of the generic types is assigned as Class I, Class II, or Class III. 

RELATED POST: Complying with FDA Design Control Requirements Using Requirements Management

Impact of the device class and classifications 

The class and classification of the device impacts what FDA premarket submission or application is required for clearance to market. The common premarketing submission or application for each class are:  

Note: These are the common regulatory submission and applications for each class of device. There are exemptions, limitations on those exemptions, special controls that may apply, and exceptions, so be aware whether any of these applies to your device. For example, about a quarter of Class I devices are not exempt, and a 510k premarket submission is required. 

As the process for the 510k submission is 30-90 days, and the process for the more in-depth PMA submission is 180 days to accept or reject, this time should be understood and planned into your product development schedule.   

RELATED POST: Customer Story: Medical Device Startup, Proprio, Chooses Jama Connect® to Drive Innovation

Similarly, expect elements from the required design control process and design history file to be included as part of a 510k and PMA. Also keep in mind that when design controls are required for your device classification, the full design history file can be scrutinized as part of an FDA inspection of your organization. Since the FDA evaluates whether a device is effective and ensures the risk to the patients and users is appropriately addressed, good requirements and risk management is key. It’s important to have an organized manner in which to demonstrate and document that risk management and user needs are successfully traced through design inputs, design verification, and design validation. A requirements management tool like Jama Connect™ allows for this traceability in an efficient, collaborative, and regulatory-compliant manner. 

Understanding your device class and classification is a key step to understanding the path for FDA regulatory clearance and subsequent design control requirements for your medical device development. Knowing those expectations up front will make for a smoother medical device development journey.  

Learn more about developing medical devices with Jama Connect!