Tag Archive for: Requirements & Requirements Management

In Vitro Diagnostic Regulation (IVDR)

This is part 1 of a two-part blog series covering our whitepaper, “The New EU In Vitro Diagnostic Regulation: What’s Changing and What You Need to Know” written by Vincent Balgos, Medial Solution Manager at Jama Software. In this paper, Vincent discusses the In Vitro Diagnostic Regulation (IVDR), developed by the EU Commission (CE), which was created to replace the previous In Vitro Diagnostic Directive (IVDD).

We will share the link to part 2 when it publishes. In the meantime, you can download the eBook HERE.

The New EU In Vitro Diagnostic Regulation (IVDR): What’s Changing and What You Need to Know

Learn more about how IVDR differs from IVDD, key takeaways from the new regulation, and guidance for how to adapt.

Disclaimer: The IVDR regulation is broad and requires focused review and interpretation by each organization — so by no means is this paper intended to be all-exclusive, as it will only discuss select topics.

Jama Software® is not an accredited regulatory body, so these are general discussions and insights from our experience working with many IVD customers, general research, and some internal subject matter expertise. It is suggested to work with a certified Regulatory Affairs consultant (a new IVDR regulation) to obtain formal recommendations for your organization.

If you’re looking for guidance on who to work with when it comes to regulatory compliance, TÜV SÜD has provided certification and testing services for manufacturers and suppliers of medical devices and in vitro diagnostics for over 30 years.

They combine expert medical product testing knowledge with a global network of internationally accredited laboratories and facilities, providing you with a one-stop solution. In fact, Jama Connect® is certified through TÜV SÜD as a software tool for development of medical devices according to IEC 62304. 

Introduction

In May of 2022 a paradigm shift emerged in how In-Vitro Diagnostics (IVD’s) will be developed, managed, and regulated in the European Union (EU). The EU Commission (CE) has developed new regulations named the In Vitro Diagnostic Regulation (IVDR) to replace the previous In Vitro Diagnostic Directive (IVDD). The main goal of the IVDR is to improve upon the quality, safety, and reliability of IVD’s within the European market. This will change the current status quo as IVDR has been predicted to have a significant impact in medical device organizations with IVD sale and business operations.

In this whitepaper, we will provide an overview of the new regulation, discuss some specific topics, and offer considerations for organizations as they adapt to this new paradigm.

Related: The Impact of ISO 26262 on Automotive Development

Overview of the IVDR and The Significant Impact on EU

Figure 1. CE Mark

Prior to the IVDR, the In-Vitro Diagnostics Directive (IVDD) was the governing regulation for devices placed in Europe. Officially adopted in 1997, the IVDD established the regulatory requirements for CE Marking approval for in vitro diagnostics¹. In order to sell and market IVD’s in the European Union, manufacturers need to show compliance with the essential requirements prior to marking the product with the CE label. The CE mark allows for legal distribution
of the IVD within the European Economic Area (EEA)². The CE mark indicates conformity across many different types of products and is based on compliance with specific European regulations based on the product type. See example marking to the left.

For medical devices and IVDs, compliance to the EU Medical Device Directive (MDD) and the EU IVDD was required to obtain CE marking, respectively.

Related: Medical Device: Reduce Project Risk in the Product Development Process

IVDD Overview:

  • IVDD was established in 1997 by the EU for trade within the EEA with 27 EU members plus Iceland, Liechtenstein, and Norway. 
  • IVDD applies to all Reagents, Calibrators, Kit, Instrument, Equipment, Systems used for in vitro diagnostics purposes in the EEA, regardless of origin of design and manufacturing.
  • IVDD is 43 pages providing general requirements. You can read the full document here.
  • Essential Requirements included requirements for design, production, labeling, and the instructions for use (IFU). Some specific requirements included the diagnostic’s analytical sensitivity and specificity, accuracy, repeatability, and reproducibility.
  • There are four general categories that are based on level of risk to public health and/or patient.
    • Annex II List A – Highest risk which require notified body review including HxV’s such as HIV, HBV, HCV
    • Annex II List B – Moderate Risk including IVD’s such as HLA, Glucose monitoring
    • Self-Test – Examples include pregnancy home tests, and cholesterol
    • General – No notified body required as OEM can ‘self-declare’ conformity

Key factors such as the device classification, risk level to patients/public, etc. would determine the manufacturer’s level of approach to developing, manufacturing, and documenting the IVD. A common industry practice for launching an IVD to the global market was that organizations would first launch their products in the EU, and then to broader markets. Due to less rigidity of the IVDD when compared to other countries, it was easier, faster, and more economical for companies to launch there first. The involvement of an external notified body was also less rigid, so many organizations tended to follow the least resistant pathway to market, with many following the ‘self-declaration’/ self-certification pathway. Learnings from the EU launch (e.g., clinical studies) could then be leveraged when then submitting to the more rigid regulatory pathways such as the U.S. Food and Drug Administration (FDA).

This common approach enabled organizations to get new products to the market faster through the regulatory pathway. In the author’s experience, this approach was practiced on many of the IVD’s developed throughout their career in multiple diagnostic applications. The general regulatory roadmap was to have initial launches in EU markets and then proceed with FDA pathway. This provided additional time to work on FDA submission activities since the level of rigidity and documentation was expected to be much higher. However, with the IVDR enforcement now in full effect, it is expected to have a tectonic shift in how manufacturers develop IVDs.

Related: Webinar: Understanding Integrated Risk Management for Medical Device

Compelling Events for Change

As seen with many types of general regulations, changes are commonly in response to mass incidents, generally with negative impact resulting in patient injury and sometimes even death. The US FDA has seen their regulations shift in reaction to mass incidents including the Therac-25 (radiation therapy) and Dalkon Shield (intrauterine device). The accidents led to significant legislative changes to prevent recurrences and improve industry practices to ensure ‘safe and effective’ products.

The emergence of IVDR follows a similar path, where there were European several high-profile events that led to the regulation update. The most notable was the Poly Implant
Prosthesis (PIP) breast implant scandal (based in France) that impacted many patients with high incidents of ruptured implants with unapproved industrial silicone filling. You can read more about the incident here, and the subsequent
clinical recommendations here.

This event led to significant updates to the medical device space with the culmination of the EU Medical Device Regulation published in 2017. Following the MDR initiative, the incumbent IVDD was also overhauled into the new IVDR paradigm which entered into force on May 26, 2017

Stay tuned for Part 2 of this blog series. To read the whitepaper in its entirety, download it HERE.


DOORS Next Gen

Why Modern Engineering Teams Aren’t Using IBM DOORS or DOORS Next Generation for Requirements Management

If you’re currently using DOORS for requirements management, you likely know that moving to a different solution is necessary, and you might be considering DOORS Next Generation. However, fast-shifting market dynamics require a new approach to accelerate innovation. As a modern alternative to traditional legacy platforms, Jama Connect® enables digital transformation with a more efficient and user-friendly approach to managing risk and compliance.

To adapt to increasing industry challenges and complexities, innovative organizations are now requiring best-in-class software to scale development, reduce risk, save time, and ensure compliance to quality and safety regulations — and migrating to a new requirements management tool, will be a necessity to keep pace with the competition.

The leader in requirements management software, Jama Connect outranks IBM DOORS Next®
for implementation time, adoption, ROI, & market presence

 

Related: Why Migration Efforts from IBM Rational DOORS to DOORS NG Are Failing – And an Alternative Path.

5 Key Reasons Teams Are Choosing Jama Connect over DOORS NG

Considering choosing Jama Connect over DOORS Next? Jama Connect consistently stands above DOORS Next (for requirements management tools) in the G2 Grid® for overall satisfaction, performance, user experience, collaboration, reviews and approvals, implementation, usability, user adoption, and overall ROI.

Fastest Time to Market/ROI

  • Deploy in weeks, not months with easy updates and high performance
  • Pre-configured frameworks to satisfy industry regulations
  • Intuitive user interface and workflows that drive efficiency
  • Jama Software in-house industry-focused subject matter experts

Highest Adoptability

  • Intuitive design with a better UX and ease of use that enables adoptability across teams and disciplines
  • Lowest learning curve, minimal training required
  • Actionable visibility into status, progress, and risks
  • Permissions-controlled access for your entire organization

Maximum Collaboration

  • Designed for connecting remote / distributed development teams and disciplines
  • Real-time communication captured in context
  • Secure access for internal and external stakeholders
  • Delivers end-to-end Live Traceability™
  • Improves productivity

Lowest Total Cost of Ownership

  • Simple and straightforward administration
  • No need for custom scripting or continuous updating
  • Scales easily without big infrastructure investment
  • Unlimited no-cost access for extended internal/external stakeholders

Built for the Modern Engineering Stack

  • Jama Connect Companion MBSE encourages and enables MBSE approach
  • Integrates with market-leading tools with open REST API
  • Teams can work in preferred tools with complete traceability visible in Jama Connect

Related: Moving from Modules to Models – Is it finally time to leave IBM® DOORS® behind?

See how DOORS Next stacks up against Jama Connect
in key areas below.

DOORS Next vs Jama Connect

Jama Connect is a proven IBM DOORS and DOORS NG alternative with flexible, scalable, and reliable migration solutions, including:

  • Operation in an IBM DOORS supply chain. Innovative companies leverage Jama Connect to get up and running fast with a modern requirements management process that tightly aligns with industry standards and practices that support regulatory compliance. Organizations can connect to customers and suppliers that use IBM DOORS through Data Exchange for Jama Connect.”
  • Integration services. Jama Connect provides integration with key product development lifecycle tools.
  • Coexists with IBM DOORS. IBM DOORS is embedded in many organizations and may take some time to migrate completely. Progressive teams and divisions can get started on Jama Connect quickly while the larger organization works toward replacing existing programs over time. This approach is supported through a mix of integration, migration, and exchange services.

In conclusion, DOORS has been a faithful requirements management tool that has served the product development community well for almost 30 years. But to stay competitive, it’s necessary to switch to a modern requirements management solution like Jama Connect.

To learn more about making the switch from IBM DOORS or DOORS Next Generation to Jama Connect, download our datasheet.


DOORS for Requirements Management


IBM Rational DOORS

Why Migration Efforts from IBM Rational DOORS to DOORS NG Are Failing – And an Alternative Path.

IBM Rational DOORS was built in 1991 when it became clear that document-based tools such as Microsoft Office did not offer the capabilities able to manage and analyze requirements traceability. And while it was revolutionary at the time, not much has changed about the product in over 30 years.

Many teams are looking to switch away from Rational DOORS because of IT mandates, poor usability due to an antiquated user interface, lack of collaborative features, and a host of other reasons.

However, thinking that migrating to DOORS Next Generation is the easiest, most logical next step is a mistake. In this post, we’ll discuss why many migration efforts from IBM Rational DOORS to DOORS NG are failing, and provide a simpler, more modern alternative.

Considering a switch? If you want to move away from IBM Rational DOORS, you are not constrained by a specific path of migration.

Leaders might already understand the need to switch from Rational DOORS, but they aren’t sure of the next best step. Some lean toward switching to IBM DOORS NG with the assumption that it will be easier to learn and deploy than starting from scratch with a new solution.

However, the only thing that DOORS Next shares with the original DOORS is the name; otherwise, it’s a completely different platform that takes the same level of migration effort that any migration away from DOORS legacy would take. Any expensive DXL customizations — which can sometimes add up to more than a million lines of code — cannot be migrated to DOORS Next.

As you make your decision on whether to migrate away from DOORS or not, consider the risks associated with DOORS and the benefits of choosing a different option.

Risks may include:

  • Loss of control and employee frustration. Employees frustrated with DOORS work outside of DOORS, most often in Microsoft Word or Excel, which means that requirements are no longer maintained in a central system and a rigorous process is not followed. This leads to an inability for management to monitor key metrics for the end-to-end process to identify process risk patterns.
  • Increased operational costs. Continuing the existing path of using DOORS increases an organization’s risk and expense complying with ever demanding IT security regulations.
  • Disruption in business. New users are reluctant to pick up the antiquated user interface of DOORS, expecting software to be as intuitive as applications in their social environment. Not having the ability to move fast and scale business to meet innovative market demands will cost your business time and resources.
  • Missed market opportunities. Errors, defects, and omissions not found until the end of the process cause costly delays and overruns. A company’s long-term success can be hindered by delayed launches and missed market opportunities.
  • Increased exposure to risk in regulated markets. A requirements management tool helps you stay compliant and increase visibility in regulated markets. Limited customer and cross-functional involvement in the review and approval of requirements and a lack of stakeholder alignment create unnecessary risks. And, the absence of process exception tracking, which determines if requirements have been omitted or modified, creates additional exposure. With more stakeholders refusing to use DOORS, compliance is checked after the fact with the arduous task of tool admins importing data and then running trace analysis. Extended stakeholders who are using DOORS are only able to see any errors long after they have been introduced and eventually imported.
  • Distraction from the core business. An ineffective requirements management tool encourages organizations to create customizations rather than simply configuring a tool to meet process needs. Developing and maintaining ad-hoc customizations forces an organization to focus on how to create requirements management functions rather than focus on core business. A modern requirements management solution enables teams to work faster and more efficiently, leading to faster time to market.

Related: The Inside Story: Data-Model Diagnostics for IBM® DOORS®

Need more proof? Here’s what IBM says about migrating from IBM Rational DOORS to DOORS NG

Looking at Rational DOORS and DOORS NG Side-by-Side

It may sound like migrating from Rational DOORS and DOORS NG is just a click of a button, the two systems have completely different infrastructure, processes, and structure. It’s a very complex and manual process. In fact, migrating to DOORS NG will cause major architectural shifts that will impact performance and require extensive employee training.

DOORS

Related: Requirements Traceability, Does My Data Matter?

There are a number of data types, including historical data, that can’t be migrated at all. But don’t take it from us; IBM says it themselves.

Additionally, there is no upgrade path from Rational DOORS to DOORS NG

5 Common Migration Myths Debunked

Transitioning to a new solution doesn’t have to be challenging; however, there are some assumptions that mislead us into thinking that difficulty is inevitable. Consider the following myths:

MYTH 1: Migrating away from IBM solutions will be more expensive. The amount of work that goes into upgrading to DOORS Next or transitioning to a new RM solution is the same, differentiated only by the quality of the tool and services available to help with migration. An option other than the DOORS family is most often a better fit for your organization.

MYTH 2: Customization will carry over to DOORS Next. You spent a lot of time customizing IBM DOORS and may believe those customizations will transition seamlessly to DOORS Next. However, this isn’t the case and is the reason selecting a different solution doesn’t involve more work.

MYTH 3: DOORS is already deployed and cheap to maintain. Continuing the current path with IBM DOORS is an expensive option in the long term, and often requires dedicated personnel. Switching to an alternative RM solution can improve efficiency while saving money.

MYTH 4: Business disruption is too difficult. The right RM tool will empower teams to effectively hit deadlines, collaborate, and improve business outcomes

MYTH 5: The user experience will suffer., Many people refuse to use DOORS due to a challenging user experience. DOORS Next is a completely new tool with a new user experience. Adopting a user-friendly solution allows teams to collaborate far more effectively as team members can accelerate concepts, designs, and validations for faster times to market.

Related: Moving from Modules to Models – Is it finally time to leave IBM® DOORS® behind?

Migration Away from IBM Rational DOORS is Inevitable – Here’s An Alternate, Easier Path

The fact is, IBM DOORS is extremely outdated, and at some point, updates and support will inevitably end.

If you’re currently using DOORS, you likely know that moving to a different solution is necessary, and you might be considering DOORS Next. However, fast-shifting market dynamics require a new approach to accelerate innovation. As a modern alternative to traditional legacy platforms, Jama Connect® enables digital transformation with a more efficient and user-friendly approach to managing risk and compliance.

Customers agree, naming Jama Connect the overall leader (#1) in requirements management software on G2, outranking IBM DOORS Next for implementation time, adoption, ROI, and market presence.

Jama Connect is a proven IBM DOORS alternative with flexible and reliable solutions, including:

Operation in an IBM DOORS supply chain. Innovative companies leverage Jama Connect to get up and running fast with a modern requirements management process that tightly aligns with industry standards and practices that support regulatory compliance. Organizations can connect to customers and suppliers that use IBM DOORS through Data Exchange for Jama Connect.

Integration services. Jama Connect provides integration with key product development lifecycle tools.

Coexists with IBM DOORS. IBM DOORS is embedded in many organizations and may take some time to migrate completely. Progressive teams and divisions can get started on Jama Connect quickly while the larger organization works toward replacing existing programs over time. This approach is supported through a mix of integration, migration, and exchange services.

Are you considering DOORS for requirements management or considering making a switch? Learn more in our eBooks, Why Move Away from IBM® DOORS® Legacy, and Why Now? and Moving from DOORS Next® to Jama Connect® for Requirements Management

The IBM DOORS Migration Experts are Now Employees at Jama Software

Migrating from IBM Rational DOORS to any other solution has never been easier. Our DOORS Migration team has a total combined experience of over 165 years with IBM DOORS. You won’t go it alone — as DOORS experts, this team is here to support you through every step of the migration.

IBM Conversion Team

To learn more about the three flexible approaches to support companies moving away from IBM DOORS and how our migration team can help, download our datasheet.


DOORS for Requirements Management


reqif

Supply chain collaboration: Interactive or ReqIF. Which is right for you?

There are two main types of requirement collaboration in the supply chain: Interactive and ReqIF. While interactive collaboration is on the rise and offers the most benefits, there are cases where it is not feasible. Jama Software supports both methods and, in this post, we will discuss each method’s use-case and pros/cons.

Interactive Collaboration: The High-fidelity Option

We all know that collaboration in product development helps improve quality, reduces risk and speeds up development. For this reason, Jama Connect® has context-based, interactive collaboration built into the platform. Reviews are a formal, effective collaboration method that guides teams in fulfilling regulatory requirements.

In addition to using these industry leading capabilities in-house, our customers frequently use these capabilities to collaborate with external stakeholders. For instance, Jama Connect allows you to invite reviewers simply by email (Jama Connect licenses include more than enough reviewer licenses for this purpose). This works extremely well in practice. In fact, one medical device developer, RBC Medical Innovations, was able to shed hundreds of team-member days during development to save $150,000 in cost savings per project.

As a fully web-based software as a service (SaaS) product, Jama Connect offers customers a standard and secure web interface for cross-department or cross-company collaboration. Inviting customers or suppliers into your Jama Connect system is as easy as sending an email. User security can limit what is seen and allows for granular control of permissions. Our full version tracking enables everyone to see what has changed, who changed it and all impacts on upstream/downstream traceability.

RELATED: The Limitations, Drawbacks, and Risks of Using Legacy Requirements Management Tools

The Alternative: Controlled Data Exchange via ReqIF

Data exchange between organizations is nothing new, and many organizations have collaborated for decades, typically by exchanging documents. While this approach technically works, it results in unstructured data that provides no traceability, no understanding of changes between versions and no easy way to provide structured feedback.

The automotive industry is a great example of complexity across the supply chain with OEM’s traditionally working with hundreds of suppliers. It’s not unusual to find tens of thousands of requirements in an automotive specification, so managing these requirements is a challenge. In response, the industry developed an international standard for the lossless exchange of requirements called Requirements Interchange Format (ReqIF) and the standard was finalized in 2011.

A requirements exchange with ReqIF has some similarities to the old (and dreaded) document exchange process: One party exports a ReqIF file and hands it to the other party. The transfer can happen via a portal upload, automated exchange or even as an email attachment.

But here’s where the similarities end: A ReqIF file contains structured requirements data consisting of individual requirements with visibility into structure, attributes, related elements, and traces. ReqIF also supports incremental updates. If one party creates another version and exports a month later, you could import that version into your environment and the tool would show you clearly which elements, attributes, and traces have changed. For instance, you could use suspect links to re-validate only those items that have changed. Compared to trading .pdf files, which yes believe it or not many organizations still do, this is an extremely significant time saver and error avoiding capability.

While the standard is certainly more advanced than simple document sharing, it does have drawbacks. Not every tool adheres to the standards in the correct way. Data exported can be missing embedded images, required fields in one system are not required in another and user information (meta-data) is not universally available.

 

RELATED: Jama Connect in the Digital Engineering Ecosystem

Collaboration via ReqIF

ReqIF is commonly used to solicit feedback from a supplier. A producer could export the requirements for a supplier, including attributes for providing status feedback and comments. The supplier would then import the ReqIF file into the tool of their choice, where they could fill out the supplier attributes and send the resulting export back.

In addition, they could start integrating the imported requirements into their own development system. For example, they could establish traceability from the customer requirements through to design while keeping the process invisible to their customer.

Image Source: IREB Magazine

There are other use cases that ReqIF supports as well, but for all of them, the foundation is a controlled asynchronous exchange of structured requirements that keeps individual items, attributes and traces intact. Jama Connect supports this workflow and we have many customers that are using it today.

Bottom Line: How to Collaborate?

If you are using Jama Connect, the built-in collaboration capabilities are the most effective way to work together. Having 100% Live Traceability™ has been proven to increase product quality while reducing time to market.

However, if you are working with people outside your organization, that may not be able to collaborate using your Jama Connect instance a ReqIF-based collaboration could be an acceptable alternative.

Learn more about the benefits of upgrading your requirements management process with our paper, “Getting the Most from a Requirements Management Tool.”


DOORS for requirements management

Considering DOORS® for requirements management? There is a more modern solution.

If you’re considering IBM® DOORS® for requirements management, it might be because it’s considered a “safe” move, you’ve used it in the past, or because you’re unaware that there’s a significantly more modern and easier to use alternative to DOORS requirements management.

IBM DOORS was an amazing tool – when it was originally published in 1991, over 30 years ago. DOORS for requirements management has many capabilities for working in regulated industries, but the limitations far outweigh the benefits. It does not deal well with increasing complexity or the need for collaboration and seamless integration in existing tool ecosystems. Let’s have a look at some of the limitations of DOORS:

Traceability: DOORS has powerful traceability capabilities, but they are hidden behind a cumbersome interface. This leads to outdated traces. Users find traceability maintenance to be difficult with DOORS, and sometimes traces are created “after the fact” for compliance audits and nothing else. This is a missed opportunity. Having a more modern tool, like Jama Connect® with an easy-to-use traceability matrix creates transparency and confidence when reacting to change. Traceability also enables agility.

Related: What is Requirements Traceability and Why Does it Matter for Product Teams

Change Management: The traceability of DOORS does support change management, e.g., via suspect links in principle. Unfortunately, this information is hidden and hard to utilize. Compare that to the actionable traceability of Jama Connect, which proactively points out issues in the traceability matrix and suggests how to fix them, instead of doing this reactively, after-the-fact.

Compliance Reporting: DOORS requirements management allows you to report on virtually everything – but almost everything requires custom scripting with its proprietary scripting language, DXL. Unless you have a responsive (often costly) programmer on your team, you will have a hard time getting the information you need, when you need it.

Best Practices: Every “module” (document) in DOORS has its own fields, and without an in-house expert, users sometimes find themselves with little guidance on how to use the tool. This results in inconsistencies, which in turn results in confusion and lack of transparency. Consider two “system specifications” with inconsistent data values for “priority.” Likewise, standardized workflows guide users through their daily work. In DOORS, you need a programmer to provide this functionality.

Related: Requirements Traceability, Does My Data Matter?

Market Drivers Are Pushing Engineering Teams and Technology to Evolve Past IBM DOORS’ Capabilities

Today’s products and software have become more complex. This complexity, combined with rapidly evolving customer and market demands, is forcing engineering teams to change the way they work. Now, far more stakeholders need to get involved in the requirements, driving the need for requirements tools to be more collaborative and have functionality that is applicable to diverse users.

Organizations that successfully transform to support this new way of working understand that effective and optimized product and system development requires highly collaborative solutions and methodologies.

To reduce risk in product development while still accelerating system design and delivery, teams need access to real-time data and alignment across disparate teams as well as across engineering, business, and product management lifecycles.

Leading-edge companies who are successfully supporting transformation of their engineering teams:

  • Invest in new technologies and agile processes to continually improve product development: Engineering teams prefer to make their own decisions about which best-of-breed solutions support their specific discipline and optimization of their activities – one single tool will not fit all users’ needs. It’s no longer possible for a Prime Contractor or OEM to mandate a single product or vendor across supply chains, and in fact, standards such as ReqIF (Requirement Interchange Format) and OSLC (Open Services for Lifecycle Collaboration) have come about to help products work better together. Modern development solutions prioritize integration across the ALM-PLM ecosystem.
  • Take a data-driven approach to product development: An organization’s investment in their data is far more than the investment they make in tools, and the primary focus now comes down to availability of data and how that flows across an engineering community (integration) and the value chain (exchange). What is required is a loosely coupled approach that ties together the necessary metadata across disparate tools in a way that connects the desired outcome (user and system requirements) to downstream activities – the digital thread. The digital thread is the best approach to reduce the risk of negative product outcomes while preserving engineering autonomy and productivity.
  • Support more formal processes to address increased regulation: As product complexity increases, so has the need for more formal processes and compliance with industry standards. Best practices for systems engineering have been prescribed in many industries. This formal process adoption started with the need to comply with aerospace standards such as DO178 or ISO 9001. Now we see engineering regulation or compliance needs increase across automotive, medical, finance, and other industries, which require the same level of rigor in their development process. Investment in tools that support the generation of the necessary proof of-process compliance to standards, most commonly: requirement validation, verification, traceability, risk assessments, and test results, are critical to supporting efficiency while reducing risk.

Related: What is DOORS and Why Does DOORS Software Fall Short for Requirements Management

IBM DOORS for Requirements Management vs. Jama Connect

Today’s product development teams must innovate and adapt quickly to changing market demands in order to remain competitive. Many find legacy solutions like DOORS are unable to adapt to support these needs. The following are the top reasons why some of the world’s most forward-thinking companies are electing to switch to Jama Connect:

Easy to use, intuitive modern user experience

Jama Connect supports multiple development methodologies and engineering disciplines to drive cross-team collaboration and alignment.

Flexible, scalable, and secure deployment models that provide manageable total cost of ownership (TCO)

Jama Software offers flexible license and deployment models with unlimited licenses for reviewers to promote collaboration across product development teams. Deployed in the cloud or on-premise, the solution ensures flexible access for distributed teams anywhere.

Open architecture to integrate with the tools teams want to use

Jama Connect enables integration with best-of-breed tools across the entire product development lifecycle. We provide a powerful network of options to get the right technology stack aligned to meet each client’s unique business needs.

Are you considering DOORS for requirements management or considering making a switch? Check out this webinar, Moving from Modules to Models – Is it finally time to leave IBM® DOORS® behind? Watch it here

DOORS for Requirements Management


requirements traceability

Derived requirements traceability is a form of requirements management focused on tracing requirements that aren’t explicitly defined in higher-level requirements, but which are necessary for meeting them and for making the overall system work as expected. In derived requirements traceability, teams will document the dependencies and logical links between these lower-level requirements and other system elements.

Derived Requirements, Explained

For example, let’s say a hypothetical automotive system has a higher-level requirement stating that it must be capable of traveling at very high speeds. A derived requirement in this case might say that the system also needs to be lightweight. While this requirement is not defined by the project stakeholders, satisfying it is essential to the engineering process of the entire system. If the end result is not light enough, the original requirement for fast travel won’t be met, either.

Another way to look at it: Derived requirements are decomposed from other requirements, including business and stakeholder requirements. Adequately tracing them serves several general purposes:

  • It facilitates impact analysis, by helping identify all the work products that might need modification before implementing a proposed change.
  • It follows the life of a requirement, both forward and backward in relation to customer needs, and from origin through implementation.
  • It creates a roadmap, showing at which points each requirement or business rule was implemented.
  • It simplifies the packaging up of requirements baselines, which are snapshots of approved requirements assigned to product releases at points in time.
  • It helps meet certain medical regulatory requirements, such as the design controls under FDA CFR 21 820.30 for aligning device design inputs and outputs.

In practice, proper derived requirements traceability will involve cataloging all of the connections between derived requirements and other types of requirements, plus business rules, architecture and design components, source code modules, test cases, help files, and documentation. This process ensures that the product in question is ultimately maintainable, compliant, and tightly aligned with customer expectations.

Enabling Traceability as Part of Requirements Management

For sufficient derived requirements traceability, each requirement must have a unique and persistent label that allows for unambiguous tracking throughout the project. A centralized, modern requirements management solution is preferable to numerous discrete requirements documents for this purpose.

Not only does such a management tool provide one convenient place for collecting feedback and collaborating in real time on reviews and approvals, but it also supports live traceability of upstream and downstream relationships, with clear visibility into the impact of changes on all levels of requirements as well as test coverage. Accordingly, project teams can set up four distinct types of traceability links for their derived requirements.

Four types of requirements traceability

Figure 1. Four types of requirements traceability.

RELATED: Vave Health Migrates to Jama Connect® to Accelerate Development and FDA Clearance

The Four Types of Derived Requirements Traceability

1. Forward to Requirements

When customer needs evolve, requirements may have to be adjusted in response. By making these adjustments, project teams can keep pace with changes in customers priorities, introductions of new business rules, and modifications of existing rules, among other events.

2. Backward From Requirements

Tracking backward from requirements can provide clarity into the origin of each derived requirement. For instance, a requirements management tool could show the link between the derived requirement, the requirement it came from, and the customer use case being addressed.

3. Forward From Requirements

Once derived requirements begin flowing into downstream deliverables during product development, it’s possible to draw trace relationships between requirements and their corresponding elements. This type of link provides assurance that every requirement is satisfied by a particular component.

4. Backward to Requirements

Finally, this type of link allows for visibility into why certain features were created. Consider how most applications include lines of code that don’t directly relate to stakeholder requirements. Even so, it is important to know why a software engineer wrote that code in the first place.

While a full accounting of all four types is beyond the scope of this piece, let’s look at a more in-depth example of the fourth type. Suppose a tester discovers unexpected functionality with no corresponding requirement. It could indicate two divergent possibilities:

  • The underlying code might have been implemented to meet a legitimate implied (derived) requirement, which could then be added to the requirements specification.
  • Alternatively, it might simply be orphan code that no longer belongs in the current product.

Traceability links create clarity in such situations, shining a light on how the different pieces of a system all fit together. Conversely, test cases derived from – and traced back to – individual requirements offer a mechanism for detecting unimplemented requirements, because the tester won’t find the expected functionality.

Some possible requirements traceability links.

Figure 2. Some possible requirements traceability links.

There are many types of traceability relationships possible within a project, and not all of them will be needed on every project. However, there are good motivations for implementing derived requirements traceability, via a best-in-breed solution with flexibility that can be leveraged as needed for a given project.

RELATED: How Jama Connect® Helps Program Managers with DOD 5000 Adaptive Acquisition Framework

The Main Motivations for Derived Requirements Traceability

At a high level, traceability contributes to a more efficient product lifecycle and superior project management. More specific reasons for implementing it include:

Certification

Traceability data can support certification of safety-critical products, by demonstrating that all requirements were implemented.

Impact analysis

By tracing derived requirements, it’s less likely that something will be overlooked when determining the effects of changes to requirements.

Maintenance

Clear traceability simplifies maintenance, as changes (e.g., in response to updates to government regulations or corporate policies) can be performed with more confidence. A modern requirements management tool makes it easier to show where each applicable rule was addressed in requirements.

Project tracking

Traceability information offers an accurate record of the implementation status of planned functionality, with missing links indicating work products not yet created.

Reengineering

List functions in a legacy system set for replacement and use traceability data to record where they were addressed in the new system’s requirements and software components.

Reuse

With derived requirements traceability in place, it’s more practical to reuse product components by identifying packages of related requirements, designs, code, and tests.

Risk reduction

Documenting component interconnections reduces risk in the event that a key team member with essential knowledge about the system departs the project.

Testing

The links between requirements, tests, and code help indicate the likely locations of bugs when a test yields an unexpected result. Also, knowing which tests verify which requirements will save time by allowing for the elimination of redundant tests.

The second article in this series discusses the requirements traceability matrix, and the final part proposes a procedure for making requirements traceability work on your projects.


What is requirements traceability

Product complexity is growing at an exponential rate. As it does, requirements move between more and more departments and stakeholders throughout the course of the development process. Requirements traceability helps product teams overcome one of the biggest challenges they face with requirements management.

The number of decision points is higher than it’s ever been. Each decision needs to be made understanding the impact on the requirement itself and on the product overall. It is essential to maintain visibility into the activity taking place and to be able to tie it all together.

That’s where requirements traceability comes in. What follows is a look at the definition of requirements traceability, as well as its purpose, importance, and benefits. You’ll also find common challenges of requirements traceability, along with a few ideas to help you start overcoming those obstacles today.

Common challenges 

If all this sounds like traceability is too difficult, fear not. While there are some challenges to requirements traceability, there are also many templates and tools you can use to streamline the process (more on that below). For now, let’s tackle some of the challenges so you can see how they can be overcome.

Differing organizational viewpoints.

Not everyone has the same understanding of why and how traceability should be performed. Stakeholders in sponsor or management positions may only view requirements traceability from a standard or regulatory perspective. They see it as a “must-have” but may not understand the additional benefits of requirements traceability (as discussed above) in the way a project or systems engineer might.

One way to tackle this obstacle is to educate stakeholders on what can be achieved if end-to-end traceability is achieved. Share this article with everyone involved in your development process so they can have a basic understanding of why requirements traceability is an essential part of requirements management, beyond simply knowing they need it to cover their bases.

Organization-wide adoption.

There are a variety of reasons a company might be slow to adopt traceability. Training is one such example. As considered regarding stakeholders, not all teams or individuals working on a project know why traceability is so crucial, or they simply may not know how to execute proper traceability correctly. Additionally, some people may be worried that traceability data from their decision points could come back to bite them.

If this is a challenge for your organization, again, education is imperative. But even beyond that, you need to create a culture in which traceability is seen as an inherent part of the development process. Start by creating clear policies regarding how the organization manages traceability. Then develop a positive training program for all new and existing employees to complete. If you choose a requirements management tool, make sure it has a strong track record of being intuitive and easy to use software that adapts to your process—not the other way around.

Want the inside scoop? See what users are saying about Jama Connect
Cost of implementation.

Getting an entire development organization on the same page regarding requirements traceability, then ensuring proper execution, can be a costly endeavor. The time spent developing policies, conducting training, and creating/maintaining traceability data add up and can even make folks feel less productive. Additionally, you may choose to adopt a traceability tool to streamline your process, which means upfront costs will be higher than previous projects.

Overcoming this obstacle requires a mindset change. We urge you to consider the cost of doing nothing. Unproductive work time, lengthy time-to-market, rework, and defects are all extremely expensive symptoms of inadequate requirements traceability. Each of these carries a hefty price tag. For a look at exactly how much these complications could be costing your organization, check out the calculators on pages 9-11 in our Buyer’s Guide. While there are costs to implementing requirements traceability and management tools, the amount saved throughout the development process far outweighs the short-term investment.

Managing change.

When building complex products, change is inevitable. It is essential that team members know about the changes and scope their impact across the product development lifecycle. That means looking closely at any related system requirements, downstream requirements, and verification tests that may be affected.

Performing this activity can be cumbersome and time consuming with manual requirements traceability tools. And the associated risks are similar to doing nothing, simply because you cannot be sure you’ve accounted for everything when dealing with static documents and human error.

If you’ve experienced this setback in your organization, it may be time to explore automated requirements management tools that enable live traceability with living requirements.

Jama Connect’s Requirements Management Enables Live Traceability™ Across Your Development Process

Bridge engineering siloes across development, test, and risk activities. Provide end-to-end compliance, risk mitigation, and process improvement with our intuitive, award-winning requirements management platform. Learn more! 

Improper management tools.

Some development teams are still tracing requirement relationships using Word or Excel documents and collaborating via email. A Requirements Traceability Matrix is one example of a document that manually traces elements of requirements management including, business requirements, objectives, design elements, and test cases via a spreadsheet. Teams input the list of requirements and fill in the related data. The spreadsheet is static but is updated manually by the team throughout the development lifecycle.

There can be advantages to using a Requirements Traceability Matrix if you are developing a product that doesn’t have many requirements. And it is better than not tracing at all. You can even use a template to create a Requirements Traceability Matrix. However, if your product is complex, with many requirements, you’ll likely experience many of the challenges discussed above.

In the case of complex products, a Requirements Traceability Matrix does not have the functionality you’ll need to keep up with the pace of change and create a quality product in the timeframe required by stakeholders. Flexible requirements management tools like Jama Connect can even capture trace relationships across teams and toolsets, further enhancing the benefits of traceability.

Insufficient compliance framework.

Regulated industries need requirements management to demonstrate compliance with industry standards. There are specific ways reviewers and regulators must receive regulatory submissions. To pass an audit you must present proof of comprehensive traceability.

If comprehensive traceability wasn’t performed throughout your development process, a lot of time will be committed to gathering the necessary information after the fact. Even if traceability was meticulously maintained in Word or Excel, there will still be time spent compiling it into an acceptable format for regulatory submission. In the meantime, competitors that make traceability inherent to their process will be first to market.

Sound familiar? Luckily, there are tools that perform end-to-end traceability and come with frameworks aligned with industry standards. Requirements management tools like Jama Connect simplify the audit process with export templates, thus speeding up the compliance presentation process.

RELATED POST: Requirements Management Tools and Software

Templates and tools to streamline the requirements traceability process

There are numerous tools available to assist with the requirements traceability process. It’s important to assess your needs to know what is best for you.

Are you creating a straightforward product that doesn’t have functional safety or regulatory requirements? If so, a Requirements Traceability Matrix may suffice. Download this Requirements Traceability Matrix template to get started today.

Are you creating a multifaceted product with both software and hardware components? Will you be required to prove functional safety or regulatory compliance? In these cases, you’ll need a requirements management tool with bidirectional traceability and compliance templates you can easily export.

Here’s some additional recommended content on traceability you might find helpful:


What is Traceability?

What is traceability? In this blog, learn its definition and why it is crucial for product teams.

Product complexity is growing at an exponential rate. As it does, requirements move between more and more departments and stakeholders throughout the course of the development process. Requirements traceability helps product teams overcome one of the biggest challenges they face with requirements management.

The number of decision points is higher than it’s ever been. Each decision needs to be made understanding the impact on the requirement itself and on the product overall. It is essential to maintain visibility into the activity taking place and to be able to tie it all together.

That’s where requirements traceability comes in. What follows is a look at the definition of requirements traceability, as well as its purpose, importance, and benefits. You’ll also find its common challenges, along with a few ideas to help you start overcoming those obstacles today.

The Definition

Traceability (or requirements traceability) is the tracking of requirements throughout the product development lifecycle. It is a documented thread that provides forward and backward visibility into all activity surrounding each requirement (including design, development, testing, and support). Requirements traceability helps minimize the risk of negative outcomes and maximize productivity. Its benefits include greater team efficiency, easier regulatory compliance, and higher-quality products.

Complex Upstream and Downstream Requirements Traceability

What’s its Purpose and Importance?

Traceability enables product teams to associate a specific requirement with all the related project artifacts, as well as other requirements, both forward and backward, so that anyone can see how the activity relates to the requirement—and vice versa—at any point during development. This functionality, also called live traceability, fosters team collaboration and enables early detection of possible production risks.

Think of it this way: How important is it to have your products developed correctly in terms of definition, quality, and timing? Mission critical, right? That’s why requirements traceability is so critical.

Let’s take a look at some of the benefits of requirements traceability throughout the product development lifecycle. For example:

  • Simplifies project estimates
  • Enhances process visibility
  • Increases development efficiency
  • Improves impact analysis of change
  • Demonstrates verification and validation
  • Strengthens product quality
  • Proves compliance or functional safety

A single line of sight on a requirement, or a digital thread, is supremely important for application lifecycle management (ALM) and product lifecycle management (PLM). Both endure tight timelines and increasing numbers of requirements — including those from regulations, where compliance is non-negotiable.

Knowing the relationship between requirements, risk, tests, and so forth, is the difference between developing a compliant product on time and getting stuck in rework, delaying launches, and dealing with unhappy stakeholders. With requirements traceability, you don’t have to compromise on speed or quality.

The bottom line is that end-to-end traceability confirms you’re building the right thing and helps you prove compliance or functional safety. Without it, your development efficiency and product quality are in jeopardy.

Forward, backward, and bidirectional: The mechanics of creating a digital thread

To connect all the phases of the product development lifecycle, from customer needs through support, four distinct kinds of links must be used to thread the process end-to-end. This includes high-level requirements as well as derived requirements—those not specifically defined but necessary for meeting defined requirements or having the system work as expected. Derived requirements must also be adequately traced to reap the full benefits of live traceability.

RELATED POST: Building an Audit Trail Through Live Traceability

Forward

There are two kinds of forward traceability: forward to requirements and forward from requirements. They both trace from an upstream component to downstream artifacts. The difference is in where they begin.

Forward to requirements traces from customer need to requirements. This is important because customer needs can evolve over time. If they do, requirements may need to change as a result. Following this type of forward traceability enables teams to be informed of changes in priorities at any time throughout development.

Forward from requirements traces relationships between requirements and corresponding downstream artifacts, including test cases. This type of trace ensures that each requirement is not only satisfied but verified and validated.

Backward Trace

Backward

Like forward traceability, there are two kinds of backward traceability. This pair traces from an endpoint, or downstream work product, to upstream elements. The two types of backward traceability have differing starting points.

Backward from requirements gives insight on how a requirement came to be by linking the requirement to the customer use case it addresses. This enables teams to improve decision making by understanding the origin of a requirement.

Backward to requirements begins at performed work and traces to its requirement. It gives visibility into why specific items were created and how different pieces of a system fit together. Tracing in this way also allows testers to find gaps or missing requirements.

RELATED POST: Checklist: Selecting a Requirements Management Tool

Bidirectional

Bidirectional requirements traceability is the ability to perform both forward and backward traceability. Bidirectional traceability is optimal because it gives teams full visibility from requirements specifications through building, testing, changes, defects, and back again. Traceability of this caliber can only be achieved through automated requirements management tools, such as Jama Connect®.

Requirements Traceability Relationship Map

Here’s some additional recommended content on traceability you might find helpful: