Tag Archive for: Requirements & Requirements Management

Jama Software is always looking for news that will benefit and inform our industry partners. As such, we’ve curated a series of customer and industry spotlight articles that we found insightful. In this blog post, we share an article, sourced from the U.S. Food & Drug Administration, titled “Ramping Up Security to Meet Operational Resilience Rules” – originally published on April 29, 2024.

FDA Takes Action Aimed at Helping to Ensure the Safety and Effectiveness of Laboratory Developed Tests

Today, the U.S. Food and Drug Administration took action aimed at helping to ensure the safety and effectiveness of laboratory developed tests, or LDTs, which are used in a growing number of health care decisions and about which concerns have been raised for many years.

LDTs are in vitro diagnostic products (IVDs) that the FDA has described as intended for clinical use and designed, manufactured and used within a single clinical laboratory that meets certain regulatory requirements. IVDs can play an important role in health care; they are used in the collection, preparation and examination of specimens taken from the human body, such as blood, saliva or tissue. They can be used to measure or detect substances or analytes, such as proteins, glucose, cholesterol or DNA, to provide information about a patient’s health, including to identify, monitor or determine treatment for diseases and conditions.

The FDA announced a final rule today amending the FDA’s regulations to make explicit that IVDs are devices under the Federal Food, Drug, and Cosmetic Act (FD&C Act) including when the manufacturer of the IVD is a laboratory. Along with this amendment, the FDA issued a policy to phase out, over the course of four years, its general enforcement discretion approach for LDTs. The agency also issued targeted enforcement discretion policies for certain categories of IVDs manufactured by laboratories.

“LDTs are being used more widely than ever before – for use in newborn screening, to help predict a person’s risk of cancer, or aid in diagnosing heart disease and Alzheimer’s. The agency cannot stand by while Americans continue to rely on results of these tests without assurance that they work,” said FDA Commissioner Robert M. Califf, M.D. “The final rule announced today aims to provide crucial oversight of these tests to help ensure that important health care decisions are made based on test results that patients and health care providers can trust.”

RELATED: Jama Connect® for Medical Device & Life Sciences Development Datasheet

Although historically the FDA has generally exercised enforcement discretion for most LDTs, meaning that the agency generally has not enforced applicable requirements with respect to most LDTs, the risks associated with most modern LDTs are much greater than the risks associated with LDTs used when the FDA’s enforcement discretion approach was adopted many decades ago. At that time, many LDTs were lower risk, small volume and used for specialized needs of a local patient population. Now, many LDTs are used more widely, for a larger and more diverse population, with large laboratories accepting specimens from across the country. LDTs also increasingly rely on high-tech instrumentation and software, are performed in large volumes and are used more frequently to help guide critical health care decisions.

Moreover, there is a growing body of evidence that demonstrates that some IVDs offered as LDTs raise public health concerns; for example, they do not provide accurate test results or do not perform as well as FDA-authorized tests, including from published studies in the scientific literature, the FDA’s own experience in reviewing IVDs offered as LDTs, news articles and class-action lawsuits.

The FDA is aware of numerous examples of potentially inaccurate, unsafe, ineffective or poor quality IVDs offered as LDTs that caused or may have caused patient harm, including tests used to select cancer treatment, aid in the diagnosis of COVID-19, aid in the management of patients with rare diseases and identify a patient’s risk of cancer.

Without greater oversight of the safety and effectiveness of LDTs, patients may be more likely to initiate unnecessary treatment, or delay or forego proper treatment based on inaccurate test results or tests promoted with false or misleading claims. This could result in harm, including worsening illness or death, as well as unnecessarily increase health care costs.

Increased compliance with device requirements under the FD&C Act (such as premarket review, quality system (QS) requirements, adverse event reporting, establishment registration and device listing, labeling requirements and investigational use requirements) will put patients and health care providers in a better position to have confidence in IVDs regardless of where they are manufactured.

With increased oversight, the FDA will also be able to help promote adequate representation in validation studies, as well as transparency regarding potential differential performance and unknown performance in certain patient populations, which may ultimately help advance health equity.

“Today’s action is a critical step toward helping to ensure the safety and effectiveness of LDTs, while also taking into account other public health considerations, including continued access to critical tests patients rely upon,” said Jeff Shuren, M.D., J.D., director of the FDA’s Center for Devices and Radiological Health. “Through targeted enforcement discretion policies for certain categories of tests manufactured by a laboratory, we expect patients and health care professionals will continue to have access to the tests they need while having greater confidence that the tests they rely on are accurate.”

The phaseout of the FDA’s general enforcement discretion approach for LDTs over a period of four years will protect the public health by helping to assure the safety and effectiveness of these tests, while avoiding undue disruption to patient care. Better assuring the safety and effectiveness of LDTs may also foster test innovation and facilitate the collective efforts of the scientific and medical communities to identify promising technologies, new therapies or areas worthy of future research.

Importantly, the FDA considered the large volume of comments received on the notice of proposed rulemaking, and in light of that input, has adjusted the phaseout policy in a manner that better serves the public health. After this phaseout, the FDA generally will expect IVDs made by either a non-laboratory or laboratory to meet the same requirements, though certain IVDs manufactured by laboratories may fall within one of the agency’s targeted enforcement discretion policies.

The FDA intends to exercise enforcement discretion with regard to premarket review and most quality system requirements for certain categories of IVDs, including but not limited to:

  • Currently marketed IVDs offered as LDTs that were first marketed prior to the date of issuance of the final rule. This enforcement discretion policy is intended to address the risk that the perceived costs of compliance with such requirements could lead to the widespread loss of access to beneficial IVDs on which patients currently rely.
  • LDTs manufactured and performed by a laboratory integrated within a health care system to meet an unmet need of patients receiving care within the same health care system when an FDA-authorized test is not available. This enforcement discretion policy is intended to help avoid patients being deprived of critically needed LDTs where certain risk mitigations exist that may help laboratories to identify any problems with their LDT and may help inform appropriate use and interpretation of such LDTs.

The FDA has also included additional enforcement discretion policies, such as for LDTs approved by the New York State’s Clinical Laboratory Evaluation Program (CLEP), as described in the preamble to the final rule, where that program’s review of analytical and clinical validity helps to mitigate the risk of harm from inaccurate and unreliable LDTs.

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

Draft Guidance Documents

The agency also issued two draft guidances today. One provides the agency’s thinking about an enforcement discretion policy for certain laboratories offering certain unauthorized IVDs for immediate response to an emergent situation, such as an outbreak of an infectious disease, in the absence of a declaration applicable to IVDs under section 564 of the FD&C Act. The other provides insight into the FDA’s thinking about the factors the agency intends to consider when developing a policy regarding enforcement discretion for certain IVDs during a public health emergency declared under section 564 of the FD&C Act.

Inquiries
Media: James (Jim) McKinney, 240-328-7305
Consumer: 888-INFO-FDA

Jama Connect® Recognized as a Top Rated Requirements Management Solution on TrustRadius!

Jama Connect® has achieved notable recognition on TrustRadius, solidifying its position as a leading platform for requirements, risk, and test management. With an intuitive user interface, robust features, and exceptional customer support, Jama Connect has been honored with a “Top Rated” distinction by TrustRadius in 2024.

Visit the full report to discover why customers love using Jama Connect for product, systems, and software development. This recognition highlights Jama Software’s unwavering commitment to providing a reliable and efficient requirements management solution that empowers teams to drive innovation and attain exceptional outcomes.

RELATED: The Essential Guide to Requirements Management and Traceability

Jama Software values the feedback from our clients who have used Jama Connect and are committed to providing them with the best support, resources, and expertise to help them succeed. As the leading provider of requirements management software, Jama Software is proud to receive recognition for our commitment to enabling multidisciplinary engineering organizations to develop products, systems, and software to maximize their success.

“I’m VERY likely to recommend Jama Connect to a colleague because they’d struggle to get anything done without using it! That’s the tool we’re using for Requirements Management now, so I recommend to my colleagues that they get amongst it!”

-From a review collected and hosted on TrustRadius – Ian Webb, Systems Engineering Technical Writer – Enphase EnergyElectrical & Electronic Manufacturing

“For our company, it was imperative that we streamline all our processes and have a solution that is well controlled for audit purposes. Jama Connect has been able to satisfy these needs easily with its intuitive design which shortened the user learning curve. Furthermore, the configuration management of artifacts is built in from the start which is incredibly powerful for auditors of our products.”

-From a review collected and hosted on TrustRadius – Eric Zaremski, Lead Program Manager – FORT Robotics

From all of us at Jama Software® to all of you, thank you!

 

In this blog, we offer a preview of our comprehensive guide to understanding ANSI/AAMI SW96:2023 and mitigating security risks.

What You Need to Know: ANSI/AAMI SW96:2023 — Medical Device Security

Managing risk around a medical device’s entire lifecycle has become increasingly complex. Many devices use third-party components, which is especially true for devices that require a network to operate. This increased need for connectivity, along with other emerging threats, is putting security at the forefront of medical device industry standards.

A recent report titled “2023 State of Cybersecurity for Medical Devices and Healthcare Systems” found 993 vulnerabilities in the 966 medical products it examined—a 59% year-over-year increase from 2022. Software applications, including those that medical devices relied on to work, accounted for 64% of the vulnerabilities found.

With device vulnerability increasing, new standards aim to keep up with emerging threats. As a result, ANSI/AAMI SW96:2023 was created to help protect against threats, understand risk, and guide manufacturers in taking the most appropriate actions to enhance security. However, because the standard is relatively new, many device manufacturers are still finalizing the interpretation of how this impacts their organizational processes. If you’re still working to get familiar with the standard, we’ve created a complete guide to make the task easier.

THIRD-PARTY COMPONENTS MAY INCREASE SECURITY RISK, WITH ONE STUDY FINDING THAT SOFTWARE ALONE ACCOUNTED FOR 64% OF NOTED VULNERABILITIES.

What is ANSI/AAMI SW96:2023?

ANSI/AAMI SW96:2023 guides security risk management for medical devices, aligning with the processes included in ISO 14971:2019.

The new standard addresses the entire lifecycle of a medical device, including areas such as design, production, and post-production. It’s intended for use with AAMI TIR57 Principles for Medical Device Security – Risk Management, which addresses cybersecurity analysis, and AAMI TIR97, Principles for Medical Device Security, which guides processes for managing medical devices in the post-market space.

The goal of the new standard is to support manufacturers in ensuring that medical devices are reliable, work as intended, and don’t cause harm to patients, operators, or the environment. It also focuses on mitigating any potential risks around device failure.

RELATED: Understanding Integrated Risk Management for Medical Devices

Why is security for medical devices important?

Security has always been important to medical device manufacturers, which is why considerations are included in ISO 14971:2019. However, ANSI/AAMI SW96:2023 aims to deepen security-related standards.

Addressing potential security risks throughout the entire product lifecycle, including design, production, and post-production, enables manufacturers to identify and mitigate potential risks through a more focused and proactive approach. It helps manufacturers continually identify, review, and safeguard against fast-evolving threats

Understanding the security risk management process

As you get up to speed with ANSI/AAMI SW96:2023, the “security risk management process” section includes details for mitigating potential threats. It includes six major sections, everything from security risk analysis to production and post-production activities. Each section contains a detailed framework, but for the sake of simplicity, we’ve highlighted a few main points for each.

The 6 Sections of Security Risk Management

  1. Security risk analysis. It focuses on selecting product security standards, performing threat modeling, and establishing capabilities to identify and detect security vulnerabilities across a medical device’s entire lifecycle.
  2. Security risk evaluation. Establishes a security assessment strategy and testing processes.
  3. Security risk control. Identifies, designs, and implements security risk control measures, as well as verifying the implementation effectiveness of any security risk control measures.
  4. Evaluation of overall security residual risk acceptability. Determine if the “security residual risk” of a device is acceptable.
  5. Security risk management review. A security management report is prepared.
  6. Production and post-production activities. Potential vulnerabilities are monitored to identify any new security risks. Also, it establishes processes to stay aware of new threats, creating security incident response plans and other measures to identify ongoing vulnerabilities.

Section 1: Security Risk Analysis

The security risk analysis focuses on selecting product security standards, performing threat modeling, and establishing capabilities to identify and detect security vulnerabilities across a medical device’s entire lifecycle. It covers:

  1. Security risk analysis process: It suggests that manufacturers perform a security risk analysis, and the results are recorded in the “security risk management file.”
  2. Intended use and reasonably foreseeable misuse: The “security risk management” file includes reference documents developed in compliance with clause 5.2 of ISO 14971. It needs to account for “the use of a medical device in a way not intended by the manufacturer, but which can result from readily predictable behavior.”
  3. Identification of assets and characteristics related to security: You’ll also identify potential medical device vulnerabilities such as third-party components, hardware, and software.
  4. Security risk estimation: You will estimate the associated “risks” for each of the identified security vulnerabilities and potential impacts on areas like confidentiality and integrity.

Section 2: Security Risk Evaluation

The security risk evaluation establishes a security assessment strategy and testing processes. A few areas it considers:

  1. Evaluation of each security risk: Identify each security risk area, determining if a “security reduction” is required.
  2. Evaluation of security risks with a potential safety impact: Consider every potential risk to determine any potential safety impacts.

RELATED: The Complete Guide to ISO 13485 for Medical Devices

Section 3: Security Risk Control

This section is focused on identifying, designing, and implementing security risk control measures, as well as verifying the implementation effectiveness of any security risk control measures, including:

  1. Security risk control option analysis: Determine if a security risk control measure is appropriate for mitigating security risks to an “acceptable level.”
  2. Implementation of security risk control measures: Security risk measures are selected based on the prior step.
  3. Security residual risk evaluation: After the security risk control measures are implemented, the manufacturer evaluates the security residential risk and records this evaluation in the security risk management file.
  4. Benefit-risk analysis: If a security residual risk is found to be “acceptable” using the criteria created in the security risk management plan, and further security risk control isn’t practical, the manufacturer conducts benefits versus security risk analysis.
  5. Risks arising from security risk control measures: The manufacturer reviews the effects of the security risk control measures to understand whether new security vulnerabilities and threats are introduced that could impact security, safety, or privacy.
  6. Completeness of security risk controls: The manufacturer periodically reviews security risk control activities to ensure all vulnerabilities and threats are considered and security risk control activities are complete.

Section 4: Evaluation of Overall Security Residual Risk Acceptability

After the security risk controls are implemented and verified, the manufacturer determines if the overall “security residual risk” created by the medical device is acceptable.

Section 5: Security Risk Management Review

The standard recommends a review of the execution of the security management plan before releasing a new device. According to ANSI/AAMI SW96:2023, the review should ensure:

  1. The security risk management plan has been appropriately implemented.
  2. The “security residual risk” is at an acceptable level.
  3. Methods are in place to gather and review details in the production and post-production phases, and leadership has reviewed and approved the plan.

Section 6: Production and Post-production Activities

The final section is focused on establishing, documenting, and maintaining a system to monitor, assemble, and review information about medical device security in the production and post-market phases. Also, it establishes processes to stay aware of new threats, creating security incident response plans and other measures to identify ongoing vulnerabilities.

To Access This Content In Its Entirety, Visit:
What You Need to Know: ANSI/AAMI SW96:2023

Jama Software is always looking for news that will benefit and inform our industry partners. As such, we’ve curated a series of customer and industry spotlight articles that we found insightful. In this blog post, we share an article, sourced from Innovation News Network, titled “Ramping Up Security to Meet Operational Resilience Rules” – originally published on April 8, 2024.

Ramping Up Security to Meet Operational Resilience Rules

Philip Pearson, Field Chief Information Security Officer at Aqua Security, discusses how meeting operational resilience targets is crucial for effective cybersecurity measures.

Operational resilience is the ability to prevent, withstand, recover, adapt and learn in the face of disruption, including cyber events.

Currently, it represents a far-reaching set of issues that are increasingly important to private sector organizations and lawmakers alike. In both the EU and the UK, stronger regulatory frameworks are evolving, accompanied by serious consequences for those who fail to comply.

For instance, the Digital Operational Resilience Act (DORA) and the NIS2 Directive are two major pieces of European cybersecurity legislation aimed at strengthening operational resilience and cybersecurity across various sectors, including finance. While they share common goals, they focus on different aspects and have distinct scopes of application.

Designed to strengthen IT security across a wide range of financial entities, DORA comes into force in early January 2025.

It focuses heavily on improving resilience “in the event of a severe operational disruption.” It is relevant to financial services industry organizations that supply services inside the EU. Failure to comply can result in penalties of up to 2% of the total worldwide revenue for any organization found to be in breach.

For any business leaders that operate within the parameters set out by GDPR, the jurisdiction rules will have a familiar ring about them, and the UK’s position outside of the EU will, for many organizations, be an irrelevance.


The NIS2 Directive has been active since January last year. It aims to improve the level of cybersecurity protection across the EU, with an emphasis on harmonising security requirements and reporting obligations. In addition, it encourages member states to integrate new areas, such as supply chain security, vulnerability management, and cyber hygiene, into their national cybersecurity strategies. The Directive also promotes improvements in knowledge sharing, collaboration, the development of an EU-wide vulnerability registry, a Crises Liaison Network, and improved cooperation, among other measures.

RELATED: Jama Connect® Amazon Web Service (AWS) GovCloud US Hosting

The role of Critical Third Parties in meeting operational resilience targets

In the UK specifically, regulators have looked closely at the role played by Critical Third Parties (CTPs) – external organizations whose services are vital to the operational integrity and operational resilience of financial institutions. CTPs could include cloud service providers such as AWS or Microsoft and a range of other technology businesses that play a key role in supporting the sector. Additionally, the Cross Market Operational Resilience Group, chaired by the Bank of England, provides detailed guidance on operational resilience for the financial services sector, which, whilst not legally binding, acts as a good base for best practice.

Our recent survey conducted at the Cloud & Cyber Security Expo at Tech Show London in March with 100+ cloud professionals indicated that awareness remains low around new compliance obligations. Nearly half – 46.5 % – were unsure of their organization’s ability to comply with supply chain regulations and frameworks such as NIS 2 or SBOM. And of those respondents who work in the finance sector, 30% were unaware of the Digital Operational Resilience Act (DORA). Just over a third – 35% – were confident of their organization’s ability to comply.

Additionally, the shift towards cloud-native technologies, with their distributed systems and microservices architectures, presents a new set of challenges for regulatory compliance and operational resilience. This environment, characterized by dynamic resource scaling to meet demand, introduces complexities in maintaining compliance amidst the fluid nature of containerized deployments and autoscaling practices.

Autoscaling, a hallmark of cloud-native environments, allows for efficient resource management but necessitates a nuanced approach to operational resilience. The ability of systems to automatically adjust resources complicates adherence to stringent regulatory frameworks, requiring organizations to adopt innovative monitoring and management strategies that align with the fluid dynamics of cloud-native operations.

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

How can organizations be compliant, secure, and agile simultaneously?

So what impact are these regulations making (or will they make) in practical terms, and what technology priorities should organizations address to ensure compliance?

Across the current financial industry ecosystem, for example, there is an increasing reliance on the provision of agile, scalable, and reliable applications, with Kubernetes and DevOps among the platforms and methodologies playing an important role in software development and delivery strategies. In this context, resilience and security are – understandably – key considerations.

Operational resilience ensures that organizations working with Kubernetes and cloud environments deploy robust, secure infrastructure and applications capable of swiftly recovering from disruption. This includes implementing best practices for Kubernetes security, ensuring high availability and disaster recovery capabilities, and effectively managing third-party risks associated with cloud service providers.

Operational resilience in these environments also involves continuous monitoring, incident response planning, and regular testing of recovery procedures to ensure that the organization can maintain its critical functions under a variety of adverse conditions.

In relation to DevOps, which has become a widely adopted software development methodology globally, security can be improved by integrating advanced measures directly into development and deployment processes. This includes implementing ‘Compliance as Code’, which integrates automated compliance checks within the CI/CD pipeline.

The most effective approaches enforce compliance policies and regulatory requirements directly in the infrastructure as code (IaC) templates and container configurations. This ensures that every deployment automatically adheres to necessary compliance standards, reducing manual review processes and the potential for human error.

This should be accompanied by the use of immutable security policies for containerized applications and Kubernetes clusters. By defining strict security policies that cannot be altered once a container or service is deployed, this approach ensures that any attempts to change the security posture can only be made through the CI/CD pipeline, enforcing consistency, audibility, and compliance with existing security standards.

Looking more closely at the issues associated with CTPs or the wider supply chain, the creation of a Software Bill of Materials (SBOM) is a critical component in ensuring the security and integrity of software applications and their dependencies. This approach is increasingly relevant in the context of broader cybersecurity strategies and compliance with regulatory requirements such as DORA and is important for several reasons:

  • Transparency: SBOMs provide a clear, comprehensive view of an application’s software components, including open-source and third-party libraries. This transparency is vital for assessing software products’ security posture and compliance
  • Vulnerability management: With an SBOM, organizations can quickly identify which components might be affected by newly discovered vulnerabilities. This capability allows for rapid assessment and remediation, significantly reducing the window of exposure to potential threats
  • Compliance and reporting: Regulatory frameworks, including DORA, increasingly recognize the importance of understanding and managing the risks associated with software supply chains. SBOMs facilitate compliance with such regulations by documenting the use of components and ensuring that they meet the required security standards
  • Risk assessment: SBOMs enable organizations to perform detailed risk assessments of their software inventory, identifying potential security and compliance issues. This proactive approach supports DORA’s ICT risk management requirements by enabling financial entities to manage and mitigate risks associated with their software supply chain
  • Incident response: In the event of a security incident, having an SBOM allows for a quicker and more accurate determination of impact, supporting effective incident response strategies as outlined in DORA

However, while SBOMs provide a comprehensive inventory of all the components present in a software application, including those that may not be actively loaded into memory or called during runtime, these inactive components can still pose security risks.

Inactive but vulnerable components could potentially be used as part of an exploit chain or become an active threat later if the application’s functionality changes over time.

Therefore, SBOMs are a critical tool for risk management in the supply chain, but they must be part of a larger holistic security. It’s essential to consider the security implications of all components within a software application, even if they are currently unused. Maintaining a comprehensive SBOM and regularly reviewing it for vulnerabilities, even in inactive parts, are crucial security practices.

Additionally, alongside utilizing SBOMs, organizations must take a more comprehensive approach to vulnerability management, including continuous monitoring, prioritization, and proactive remediation.

Organizations must act now to stay ahead of the curve and ensure compliance with emerging regulations. Some concrete steps they can take include:

  • Educate staff on the requirements of DORA, NIS2, and other relevant regulations and take steps to assess the current level of compliance
  • Engage with industry peers, regulatory bodies, and security experts to stay informed about best practices and evolving threats
  • Develop a roadmap for enhancing your security posture, prioritizing initiatives that align with regulatory requirements and their overall business objectives
  • Partner with trusted security vendors and service providers who can provide the expertise, tools, and support needed to implement effective security measures and maintain compliance over time

Looking ahead, these represent just some of the key considerations for organizations operating in and around the finance industry ecosystem. In a climate where the role of regulation seems likely to increase even further, organizations that can integrate security into their development processes now will be better placed to adopt future changes in regulation as they emerge.

It’s essential to consider the security implications of all components within a software application, even if they are currently unused. Maintaining a comprehensive SBOM and regularly reviewing it for vulnerabilities, even in inactive parts, are crucial operational resilience practices.

CONTRIBUTOR DETAILS

Philip Pearson, Aqua Security  Field Chief Information Security Officer
Website: https://www.aquasec.com/

In this blog, we recap our webinar, “Leveraging Jira & Jama Connect® for Enhanced Requirements Management” – Click HERE for the full version.

Leveraging Jira & Jama Connect® for Enhanced Requirements Management

Is it time to scale up your requirements management?

Many companies developing software try to manage requirements using a combination of Word and Jira. However, for all the effort that goes into documenting requirements, teams who rely on Word and Jira alone often struggle with a lack of traceability, inefficient requirement reviews, little insight into development, and an inability to quickly and easily understand the full impact of change.

While tools like Jira play a crucial role in the development lifecycle, leveraging its strengths with Jama Connect® offers a more traceable and seamless product development process.

In this insightful webinar, host Susan Manupelli, Senior Solutions Architect at Jama Software®, will walk through the pitfalls of inefficient requirements management and how Jama Connect can help. In this session, gain an understanding of key features of Jama Connect, including:

  • Live Traceability™ – help ensure requirement coverage and allows you to easily identify exceptions (missing upstream or downstream requirements) to close any gaps.
  • Review Center – come to a consensus faster on what needs to be built.
  • Jama Connect® Integration with Jira – gain insight into development and avoid scope creep by ensuring that development tasks tie back to requirements.
  • Impact Analysis – be nimble react quickly to change while reducing risk.

Discover how Jama Connect can help you understand the current state of your system and how to optimize your development process by leveraging Jama Connect and Jira together

Below is a preview of our webinar. Click HERE to watch it in its entirety.

The following is an abbreviated transcript of our webinar.

Leveraging Jira & Jama Connect® for Enhanced Requirements Management

Susan Manupelli: Many companies developing software try to manage requirements using a combination of Word and Jira alone. And for all the effort that goes into documenting requirements, the results often fall short. And this can be in the form of frequent rework, missed deadlines, slower rollouts, and overall poor quality. In today’s webinar, we’ll address these challenges and I’ll show you how Jama Connect can be used to improve development outcomes. As we get started, I’d like to review the agenda for today. So first, we’ll start off with a brief introduction of myself, as well as my company Jama Software. Next, we will review the challenges of using Word and Jira alone for managing requirements. For each of the challenges raised, I’ll show you how Jama Connect can solve the challenge and improve the outcome of your software development projects.

I’ll show you how to achieve Live Traceability™ with Jama Connect. Live Traceability ensures requirement coverage and allows you to easily identify exceptions. And what I mean by that is missing upstream or downstream requirements, so that you can close any gaps. We’ll discuss the review process. Trying to manage reviews in Word is time-consuming and prone to error. I’ll show you how Jama Connects’s Review Center significantly improves the efficiency of reviews for both your internal and external stakeholders. Jira is used by many companies to manage their development tasks. Using Jama Connect’s integration with Jira, you’ll get insight into development and avoid scope creep, by making sure dev tasks tie back to requirements. I’ll also cover how to use Jama Connect to understand the current state of your system, see why Jira alone cannot be used for this purpose. And finally, change happens in software development. And in fact, agile principles support embracing change. With Jama Connect’s impact analysis, you’ll have the critical information to allow you to quickly react to change while reducing risk.

So just a little bit about myself. I’ve spent more than 20 years in product development, primarily in the testing capacity as a principal test architect for various requirements and test management tools. I have experience in several phases of the software development lifecycle, including traceability of artifacts from requirements definition, to implementation, verification, and validation. As a Solutions Architect here at Jama Software, my role is to demonstrate the power of Jama Connect in Live Traceability. And I work with our clients through their Jama Connect trials to help them realize the value of requirements management as well as test management when done properly.

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

Manupelli: With that as a backdrop, let’s jump into the main focus of today’s webinar, the challenges of using Word and Jira alone to try and manage your quantitatives.

So the first issue with trying to use Word and Jira alone is lack of traceability. Word is a flat file with no relationships between requirements. Any attempt to traceability is going to be manual, time-consuming, and prone to error. The next challenge is inefficient requirement reviews. Reviews with Word are also manual. Even though you may use the track changes feature in Word, reconciliation of changes from multiple stakeholders takes significant time. Managing participation and tracking feedback is also very difficult. The next challenge is little or no insight into development. Once you approve a BRD, a business requirements document, development will go off and will start to code, often with no feedback loop back to the requirements.

There’s often this throw-it-over-the-wall approach. So we’ll address that issue in today’s call. No clear definition of system. The development work to be done is defined in Jira. Once a development task is marked on it’s closed out. Changes that come along as part of new requirements or maybe because of a defect fix, might actually invalidate previous completed tasks, leaving you with an incomplete view of the functionality of your current system. Inability to understand the impact of change. So change happens in software development. It comes from a variety of sources. If you don’t have your requirements traced and connected to your development items, it’s going to be extremely hard and likely impossible to accurately analyze the impact of change. So let’s take each one of these one by one and dig in a bit further.

RELATED: The Essential Guide to Requirements Management and Traceability

Manupelli: So first, the first challenge, lack of traceability. Trying to manage requirements in a flat file like Word or Excel is just not enough. Manual traceability, it’s resource intensive, it’s prone to error, and missing coverage, and you end up with a complete lack of visibility into development. So really, you never really know how far along you are in the project. Lack of traceability is the number one cause of negative project outcomes. So let’s take a moment to show the desired level of traceability. This is the common V model in systems engineering. You define your customer needs in the upper left, decompose those needs into requirements until you get to the bottom of the V, where implementation and integration takes place. While the right side shows verification and validation.

Notice the cost to fix defects increases substantially the later in the life cycle the defect is discovered. This is 110 times more expensive, assuming you find it at the validation time. For defects that escape even this and are not found until customer deployment, the cost is exponentially higher. So this V model is the goal. Capture the needs, trace them to well-defined requirements, make sure you’ve got no gaps in coverage or gaps in testing, and make sure the development tasks to fulfill the requirements are connected as well. But for teams using Word in Jira, their V often looks like this. Noticed all the red X’s identifying broken coverage. So the customer needs may be captured in Word or some other document-based tool. Maybe there’s an effort to break these down into requirements in Word or Excel, but then there’s no connection between these.

So there’s really no way to make sure that every need is covered with a requirement. Perhaps at some point the requirements are transferred from Word or Excel into Jira in the form of user stories or some other development item. But again, there’s no connection back to the requirements that the customer needs. So if your teams are siloed and lack good collaborative capabilities, you could wind up with implementations that end up failing your verification and worse, even your validation. So basically, your team spent time building something that does not satisfy those customer needs. So Jama Connect solves this with something we call Live Traceability. Live Traceability is really a digital thread through every level of development. So let’s jump in and I’ll show you a demo of this.

CLICK HERE TO WATCH THIS WEBINAR IN ITS ENTIRETY:
Leveraging Jira & Jama Connect® for Enhanced Requirements Management

In this blog post, we summarize our Whitepaper titled “Critical Alignment for Security, Safety, & Product Teams in Automotive Development”. Click HERE to read the full Whitepaper.

Critical Alignment for Security, Safety, & Product Teams in Automotive Development

As automotive product development becomes increasingly complex with multiple standards for compliance, alignment between different teams is more critical than ever. Yet in many organizations, specialized teams such as cybersecurity, safety, product development, and even project management work separately. In other cases, teams may be dispersed across organizations or geographies, making alignment even more challenging. Is collaboration and alignment even possible within these complex environments?

How Safety and Security Teams Become Siloed

On the safety side, the standard for functional safety in automotive, ISO 26262, has been around since 2011, and the safety work has been around even longer than that. For original equipment manufacturers (OEMs), tier ones, and some tier twos, the organizational competency, processes, tools, and culture of safety are quite mature. Enter the cybersecurity side, which is a new discipline in automotive development. Cybersecurity has new standards, audits, and assessment requirements, and requirements are coming very rapidly from OEMs and tier ones worldwide. Cybersecurity teams are still going through training. The processes for doing product development according to standards like ISO 21434 are new or still in development. The discipline itself is new and transforming out of IT security.

The differences between the two disciplines lead to siloed teams of specialists even though both of those standards and both of those disciplines require automotive V-model development, with strict requirements for documentation, quality, and compliance with the V-model.

As organizations strive to align these disciplines along with product development, they typically begin cross-communication by sharing vehicle-level risk analysis and handing safety or cybersecurity top-level requirements to product development teams. While this is a good step towards effective collaboration, a lack of transparency and the ability to fully collaborate across teams and tools still present significant problems and add unnecessary risk. Both safety and security standards are risk-based. ISO 26262 addresses systematic and random hardware faults which mitigate the risk of harm to persons due to defects in the system or from hardware wearing out prematurely. On the cybersecurity side, the risk of harm to persons is measured in terms of safety, financial, operational, or privacy impact and addresses the possibility or risk of an attack to critical system assets by a bad actor.

RELATED WEBINAR: Effectively Managing Cybersecurity in Jama Connect® for Automotive and Semiconductor Industries

The controls or the mitigations for these types of risks might result in conflicting requirements — for example, how to handle a communication channel such as vehicle to network (V2N) or vehicle to device (V2D). In this example, the safety and security teams must work together, along with product development, to solve requirements discrepancies and build an integrated system that works cohesively.

Of course, automotive manufacturers and consumers have dealt with safety issues, recalls, crashes, and fatalities for years. Now that most automotive systems include cellular, Bluetooth, and other ways to connect into the vehicle, development teams and manufacturers need to consider and address cybersecurity issues. The surge in cybersecurity threats stemming from connected cars and the expanding software content in vehicles has prompted the industry to swiftly embrace the new ISO 21434 cybersecurity standard. This is evident in scenarios ranging from managing vehicle fleets to halting production lines and posing safety hazards.

Effective communication plays a critical role in tying together disciplines of safety, security, and product development together. Safety analyses and threat analyses can’t happen in a vacuum. Teams must coordinate, communicate, and align to achieve a comprehensive development picture that fulfills every team’s requirements. In fact, both ISO 21434 and ISO 26262 require teams to establish communication channels between safety, security, and other disciplines such as quality.

If not identified early, conflicting requirements often result in costly rework. Typically, the safety and security teams each write their own requirements with limited interaction at different times in the product development cycle. Sometimes, cybersecurity requirements come late and conflict with safety requirements, causing rework late in the cycle after software has already been developed, tested, and integrated. That rework results in unpleasant surprises in schedules, retests, and additional costs.

RELATED: The Impact of ISO 26262 on Automotive Development

How the Right Collaboration Tools can Improve Alignment

One trend driving teams toward better alignment and collaboration is the continual increasing complexity of software in the vehicles. Standards such as R155 and R156 are driving cybersecurity adoption as well as software-supplied services into the car, ADAS, and AI. Continuous updates are driving unsustainable growth in the amount of software in the vehicle.

The rising threat of cyberattacks, exacerbated by the integration of additional software into vehicles, is a key driver of cybersecurity adoption. The ISO 21434 standard seeks to address these new cybersecurity requirements, but because it’s so new, the communication channels are not yet well established.

This graph depicts relative growth overtime, for automotive features.

The OEMs are rushing to support cybersecurity, which throws cybersecurity players right into the middle of a massive increase in software development. The OEMs are bringing software in-house and building Agile software factories, and tier ones and tier twos are racing to comply.

This diagram depicts the difficulty of adopting Agile software in automotive. In some cases, it’s like running into a compliance wall.

This image shows a car hitting a brick wall to depict how ISO 26262 and ISO 21434 keeps automobiles safe.

Some OEMs and tier ones are responding by picking and choosing the pieces of Agile they would like to implement. But these organizations are finding that it’s difficult to develop embedded automotive software that’s compliant with these standards in an Agile way, such as running Scrum with mini V-models.

Alignment and visibility when rapidly developing software — and in a compliant way — is critical to bringing together product development, safety, security, and other teams. When Agile methodologies such as Scrum are implemented, there is a risk of accruing technical debt if safety, security, and product development are not harmonized, often due to the demanding documentation needs and heightened quality standards for stories and epics.

TO DOWNLOAD THIS WHITEPAPER IN ITS ENTIRETY, VISIT:
Critical Alignment for Security, Safety, & Product Teams in Automotive Development

In this blog, we recap our webinar, “Concurrent Engineering in Aerospace and Live Traceability™” – Click HERE for the full version.

Concurrent Engineering in Aerospace and Live Traceability™

In this webinar, you will gain an understanding of the essential components of concurrent engineering, which include:

  • The process itself
  • Forming a team with members from different disciplines
  • Utilizing a unified design model
  • Collaborating in a shared workspace
  • Implementing a software tool infrastructure
  • Model-Based-Systems-Engineering (MBSE) and Live Traceability™ for Concurrent Engineering inside Jama Connect

Take this opportunity to discover how to speed the analysis of feasibility, programmatics, risk, and cost in addition to surfacing and resolving technical issues early between a space agency (customer) and contractors (suppliers).

Below is a preview of our webinar. Click HERE to watch it in its entirety.

The following is an abbreviated transcript of our webinar.

Concurrent Engineering in Aerospace and Live Traceability™

Cary Bryczek: A simple agenda for today’s webinar. I’ll begin with explaining just what concurrent engineering is, and then I’ll give you a demonstration of Jama with some ideas for how to adopt those concurrent engineering practices. And then I’ll just open up the floor for some Q&A.

I’ll start by telling you a little bit about my company, Jama Software. We’re the leader in requirements management. Our purpose is to ensure that innovators succeed with client success at the forefront of everything that we do. Through years of industry-specific experience and thousands of client engagements, we provide best practices and pre-built frameworks to help teams manage their product, system, and software requirements with live traceability through the development cycle.

Our clients believe from faster cycle times and speed to market, increased process efficiency, visibility, control and quality, and streamlined reviews, compliance and risk management, all in a single source of truth. Our Jama Connect software and services help teams manage complex development in regulated industries such as medical devices and life sciences, automotive, semiconductor, space systems, airborne & defense, as well as non-regulated industries such as industrial manufacturing, finance, insurance, and software development.

The reality at most companies is that the end-to-end systems development process is fragmented into domain-specific tools and spreadsheets that have no built-in collaboration. This leads to fragmented requirements traceability and requires significant manual effort through emails, meetings, and luck to try and prevent delays, defects, rework, and cost overruns.

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

Bryczek: Most companies have come to accept the situation as an unchangeable reality given the lack of a single platform to enable the entire process, nor a method to integrate spreadsheets and desktop tools. Concurrent engineering practices can help solve some of the lack of traceability and communication, but a collaborative requirements tool like Jama is what helps communicate the evidence and make sure what is being developed aligns with the mission, goals, and needs.

Let’s dig in. As defined by the European Space Agency, concurrent engineering is a systematic approach to integrated product development that emphasizes the response to customer expectations. It embodies team values of cooperation, trust, and sharing in such a matter that decision-making is by consensus, involving all perspectives in parallel from the beginning of the product lifecycle.

Traditionally, engineers faced with the task of designing a new complex system or architecture work in sequence, one step at a time, passing the design from one subsystem specialist to the next without interaction with the rest of the team. That’s the traditional, that’s the old style.

As seen in the figure on the left, this sequential engineering begins with customer requirements and then progresses to design implementation, verifications, and maintenance. The approach for sequential engineering results in large amounts of time devoted to product development. This drives higher cost and is less efficient as products can’t be made quickly.

And this is a big deal in the space industry because when we’re in the early phases of mission analysis, you can’t afford to have a really long, lengthy product development. Sequential really just doesn’t make sense. It’s just too expensive and you need to come up with those variants right away.

RELATED: The Essential Guide to Requirements Management and Traceability

Bryczek: So concurrent engineering, on the right, is based on teamwork and focused on a common design model that evolves iteratively in real-time. As the different subsystem experts provide their contributions, designers, and customers agree on requirements and take decisions in real-time to allow the best design for the right cost within the programmatic constraints. So concurrent engineering, it allows for all stages of product development to occur essentially at the same time.

As seen in sequential engineering versus concurrent, the figure in the middle of the screen that you see, initial planning really is the only requirement before the process can occur, including planning, design, implementation, testing, and evaluation. The concurrent design and manufacturing approach allows for shortening that product development time, gives you higher efficiency in developing, and producing the parts earlier, and it lowers those production costs.

The European Space Agency commonly produces a costed, risk-assessed, conceptual space mission or system design complete with various options including the scheduling, testing, and operations in only just a few weeks, and they’ve been doing it a really long time.

We think that concurrent engineering and design manufacturing, it emphasizes parallel types of tasks. So you have an integrated product development approach, some people might call it. It really has it so that where the functions of the design, engineering, and manufacturing are working in parallel at the same time, highly collaborative to bring that new product to market.

Who uses something like concurrent engineering? There’s a lot of people. Space agencies like the European Space Agency and NASA, automotive companies like Toyota and Harley Davidson, contract manufacturing companies, and even large energy and oil companies. There are a lot of organizations out there that are doing it and doing it very successfully.

CLICK HERE TO WATCH THIS WEBINAR IN ITS ENTIRETY:
Concurrent Engineering in Aerospace and Live Traceability™

G2® Once Again Names Jama Connect® the Overall Leader for Requirements Management Software for Spring 2024

In the competitive landscape of requirements management solutions, Jama Connect® has once again emerged as the overall leader in the Spring 2024 G2 Grid® Report for Requirements Management Software.

G2 rates products and sellers based on reviews gathered from our user community, as well as data aggregated from online sources and social networks. They apply a unique algorithm (v3.0) to this data to calculate the Satisfaction and Market Presence scores in real-time. The Grid® Report for Requirements Management | Spring 2024 is based on scores calculated using the G2 algorithm v3.0 from reviews collected through March 05, 2024

In addition to the honor of being named the leader in requirements management software, we are proud to showcase that we were awarded several additional medals for Spring 2024 in requirements management, including:

  • Enterprise Leader
  • EMEA Leader
  • Europe Leader
  • Small-Business Leader
  • Mid-Market Leader

Download the full report to see why customers love using Jama Connect for product, systems, and software development. 

Learn More About the Spring 2024 G2 Grid for the top Requirements Management Software products HERE!

DOWNLOAD

Jama Software® is honored to be recognized as the leading requirements management solution. We are grateful to our customers for providing valuable feedback on their experiences with our product, services, and customer support. This recognition is a testament to the value our industry-leading software brings to our customers, particularly those who have transitioned from a document-based approach to complex product, systems, or software development.

“Jama Connect effectively resolved our requirements management issues” -From review collected and hosted on G2.com, Stephan T. — Mid-Market

Our goal is to provide our customers with the best possible experience when using our platform. Being named the overall Leader demonstrates how much our users enjoy working with Jama Connect.

“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.” -From review collected and hosted on G2.com, Verified User — Mid-Market

Read Jama Connect for Requirements Management reviews on G2

From all of us at Jama Software to all of you, thank you!

Jama Software is always looking for news that will benefit and inform our industry partners. As such, we’ve curated a series of customer and industry spotlight articles that we found insightful. In this blog post, we share an article, sourced from MedTech Intelligence, titled “FDA Outlines its Approach to Artificial Intelligence Regulation” – originally published on March 17, 2024.

FDA Outlines its Approach to Artificial Intelligence Regulation

 

“Artificial Intelligence and Medical Products: How CBER, CDER, CDRH, and OCP are Working Together” outlines how FDA’s medical product centers plan to address regulation of AI used in medical products and their development.

U.S. regulation of artificial intelligence (AI) in medical devices will involve cooperative work among multiple departments within the FDA. On March 15, the FDA released “Artificial Intelligence and Medical Products: How CBER, CDER, CDRH, and OCP are Working Together,” which outlines how the agency’s medical product centers plan to address the efforts required to protect public health while fostering responsible innovation in AI used in medical products and their development.

RELATED: The Complete Guide to ISO 13485 for Medical Devices

The paper outlines four priorities for cross-center collaboration to foster consistency across the FDA in regulating the development, deployment, use, and maintenance of AI technologies throughout the medical product life cycle.

They include:

Foster Collaboration to Safeguard Public Health

  • Solicit input from a range of interested parties to consider critical aspects of AI use in medical products, such as transparency, explainability, governance, bias, cybersecurity, and quality assurance.
  • Promote the development of educational initiatives to support regulatory bodies, health care professionals, patients, researchers, and industry as they navigate the safe and responsible use of AI in medical product development and in medical products.
  • Continue to work closely with global collaborators to promote international cooperation on standards, guidelines, and best practices to encourage consistency and convergence in the use and evaluation of AI across the medical product landscape.

Advance the Development of Regulatory Approaches That Support Innovation

  • Continuing to monitor and evaluate trends and emerging issues to detect potential knowledge gaps and opportunities, including in regulatory submissions, allowing for timely adaptations that provide clarity for the use of AI in the medical product life cycle.
  • Supporting regulatory science efforts to develop methodology for evaluating AI algorithms, identifying and mitigating bias, and ensuring the robustness and resilience of AI algorithms to withstand changing clinical inputs and conditions.
  • Leveraging and continuing to build upon existing initiatives for the evaluation and regulation of AI use in medical products and in medical product development, including in manufacturing.
  • Issuing guidance regarding the use of AI in medical product development and in medical products, including: final guidance on marketing submission recommendations for predetermined change control plans for AI-enabled device software functions; draft guidance on life cycle management considerations and premarket submission recommendations for AI-enabled device software functions; and draft guidance on considerations for the use of AI to support regulatory decision-making for drugs and biological products.

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

Promote the Development of Standards, Guidelines, Best Practices, and Tools for the Medical Product Life Cycle

  • Continue to refine and develop considerations for evaluating the safe, responsible, and ethical use of AI in the medical product life cycle (e.g., provides adequate transparency and addresses safety and cybersecurity concerns).
  • Identify and promote best practices for long-term safety and real-world performance monitoring of AI-enabled medical products.
  • Explore best practices for documenting and ensuring that data used to train and test AI models are fit for use, including adequately representing the target population.
  • Develop a framework and strategy for quality assurance of AI-enabled tools or systems used in the medical product life cycle, emphasizing continued monitoring and mitigation of risks.

Support Research Related to the Evaluation and Monitoring of AI Performance

  • Identify projects that highlight different points where bias can be introduced in the AI development life cycle and how it can be addressed, including through risk management.
  • Support projects that consider health inequities associated with the use of AI in medical product development to promote equity and ensure data representativeness, leveraging ongoing diversity, equity, and inclusion efforts.
  • Support the ongoing monitoring of AI tools in medical product development within demonstration projects to ensure adherence to standards and maintain performance and reliability throughout their life cycle.

Manage by Exception

In this blog, we recap our eB00k, “Manage by Exception: Data-Driven Practices to Improve Product, Systems, and Software Quality” – Download the complete paper HERE.

Manage by Exception: Data-Driven Practices to Improve Product, Systems, and Software Quality

Requirement errors in product development cost time and money and create potential liabilities. The expense of these errors can make up between 70% and 85% of all rework costs. When leaders don’t have data related to the execution process, teams aren’t tracing requirements back to the “‘why’,” and when there’s a lack of insight into aspects like verification coverage, you’re much more likely to encounter programs late in the development cycle, resulting in expensive problems.

This creates the all-too-familiar scenario seen in the news of product, systems, or software defects and the resulting fallout. Organizations can avoid many of these challenges by accessing the right data at the right moment — and ideally early — in the development process. As most executives and managers know, you can’t manage what you can’t measure. Using data to measure allows your teams to spot recurring patterns and abnormalities early, before they grow into larger challenges later in the development cycle.

Requirement errors in complex product, systems, and software development can consume between 70% and 85% of all project rework costs.

Why “Data-Based Management” is Critical, and How it Uncovers Gaps

Management by exception is a method that empowers your team with data focused on early warning indicators. It’s these warnings that help support faster and more informed decisions.

As a result, leaders can focus on exceptions rather than needlessly micromanaging and intervening with teams when the data shows that development is going as expected.

In other words, when using data, the goal isn’t to micromanage, but to do the opposite: leverage the data to do less micromanagement.

The result is fewer manual requests, fewer status updates, fewer test procedure specification reports, and fewer unnecessary meetings.

Data-driven practices help you automatically evaluate exceptions without needlessly relying on a person to manually hunt them down, evaluate them, and communicate about them. Instead, abnormalities and oversights are brought forward to reduce managerial workloads by minimizing unnecessary intervention and allowing more time to be spent in areas that have the greatest impact.

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

Examples of Exceptions in Daily Product, System, and Software Development and Requirements Management

As you adopt a data-driven approach, there are several considerations, but the first is identifying the expected or acceptable process for your research and development function.

Many organizations don’t have a defined practice; instead, operations are based on how things have always been done. Defining processes gives you greater focus.

Once you have an expected process, you can leverage the data to manage by exception but also take things a step further by managing requirements quality, traceability, and completeness. These capabilities will help predict and prevent poor outcomes in product, system, and software delivery.

A tool such as Jama Connect® can help you successfully manage exceptions, such as in these four examples.

1. Version and Change Management – The Jama Connect dashboard shows requirements missing verification. For example, it might flag two requirements missing verifications, and if you click for more details, you can view a filtered list of those requirements. And you can ask Jama Connect to show those missing a downstream verification. The filters are a powerful way to understand and create audits for capturing those exceptions in your process.

2. Derived Requirements Missing Rationale – Using a filter, Jama Connect allows you to see if a particular requirement has a missing rationale. For example, a hardware or software engineer may create a new requirement. But when that’s done,
it’s crucial to have a solid rationale for why, especially if the requirement is not directly related to a stakeholder’s need or contractual requirement. You don’t want to introduce unnecessary capabilities that aren’t going to align with the actual user needs or have a real rationale behind them.

3. Remediate Rejected Requirements – Jama Connect has a capability called Review Center. It allows you to send requirements into a review with colleagues, which can increase the quality of the requirements and create a shared understanding. Leaders can quickly spot the rejected requirements and discuss how to move forward. With many organizations working remotely, this capability helps increase asynchronous collaboration so that working sessions and meetings can more efficiently focus on exceptions.

4. Find Poorly Written Requirements – The International Council on Systems Engineering (INCOSE) created a handbook of recommended rules to author well written requirements. For example, requirements using vague terms that are not testable could be flagged for improvement.

With Jama Connect Advisor™, powered by natural language processing, INCOSE’s best practices, and the Easy Approach to Requirements Syntax (EARS), teams can now check the quality and accuracy of their requirements.

RELATED: Requirements Traceability Diagnostic

Critical Metrics to Consider

Having data, a way to view it in context, and metrics to track it empowers your leaders to make the right decision at the right time and predict how well the project or product development will trend. Metrics are an essential part of that equation, and here are two to consider tracking.

1. Requirement Quality – Most product, system, or software failures are due to undocumented, poorly written, or misunderstood requirements. And the later in the product lifecycle the problem is discovered, the higher the cost. Measure your requirement quality, and if you need support, your Jama Software team of in-house experts can help with audit assessments, training, and other resources to help improve the quality of your requirements.

2. Traceability Score™ – Traceability is a core tenet of building complex products, but it hasn’t been measured in a standard way in the past. But if you can measure it, you can improve it.

For example, Jama Software has aggregated and anonymized over 40,000 projects and over 6,000 traceability models using Jama Connect. And we’ve defined an actual approach to measure a Traceability Score™.

Our Traceability Benchmark study shows this traceability score produces a clear correlation between quality and time to market.

It starts with setting up the expected behavior of your engineering team – the traceability model. We take the number of established relationships among the different model elements in the traceability model and divide that by the number of expected relationships defined by the project’s relationship and traceability model. This gives us the traceability score.

For example, a requirement should have three different elements:

Imagine an example where you have two of those established, but one is missing. The Traceability Score is 66%, and with that metric, you can take the appropriate action. Our above-mentioned benchmarking research showed that higher Traceability Scores™ equaled improved product quality and faster time to market.

Integration of your digital engineering tool suite is critically important. In product development, many tools such as Excel, development applications, modeling applications, testing applications, and others are used. These tools capture critical data about your product and system development lifecycle.

But if they aren’t integrated, you can’t measure critical information like your Traceability Score. As a result, managing by exception isn’t possible due to a lack of data, which risks product delays, extra costs, and even compliance and audit failures. Ensure that critical tools are integrated to support real-time data visibility.

TO LEARN MORE, DOWNLOAD THE COMPLETE WHITEPAPER HERE:
“Manage by Exception: Data-Driven Practices to Improve Product, Systems, and Software Quality”