Tag Archive for: Live Traceability

Medical Device Risk Management

Medical device developers must ensure risk is addressed as a core activity. The ISO 14971 standard, which has been revised three times, provides a proven and flexible framework around which developers can effectively manage the risk of devices for patients and stakeholders. Knowing the standard and applying some aspects, in a reactive way, is not sufficient to create a safe product. Implementing an effectively proactive process and achieving live traceability throughout development, while adhering to the standard will result in a higher quality and safer product fit for market use.

In this blog, I will share how proactive risk management along with Live Traceability™ are two key areas that every medical device developer should focus on when it comes to risk management.

Reactive vs. Proactive

A lot of medical device developers do not prioritize risk evaluation throughout the different design stages, but instead, consider risk a checkbox activity at the end of development. With important prototype deadlines, limited funding, and resource constraints, it’s very easy to make excuses for not running risk evaluations of initial user needs but waiting until entire subsystems have been designed. This may seem like a minor hiccup, but the lack of ongoing risk assessment from an early stage can be very risky for FDA approval, future patients as well as your business’s bottom line and reputation. The later that risk is addressed, the more expensive changes are to incorporate. Delays become the norm as well as budget overruns.

Jama Connect Enables Live Traceability™ Across Your Development Process: Learn more!

Live Traceability™

The number one cause of inspectional observations, product recalls & delays, increased CAPAs, and cost overruns is the lack of live traceability throughout different development stages. With complex medical devices, there can be thousands of user needs, product requirements, risks, mitigating requirements, tests being executed, and defects logged. At Jama Software, we’ve noticed that a lot of medical device developers are using different technologies and applications to store this information including Excel, Jira, Word, and others. The below image depicts that and shows the siloed world a lot of engineering teams are living in:

Unless you have a real-time system that can interface with spreadsheets, tools like Jira and other applications, it’s impossible to get a holistic view of development. This can cause several issues, some of the most critical being:

Late identification of defects/coverage gaps due to lack of visibility throughout the development process
Lack of requirement coordination and change management between hardware/software
Lack of ongoing risk assessment and change management
Cumbersome and risky effort to produce trace reports and other DHF artifacts

Requirements Traceability – Does My Data Model Matter?

Nearly all engineering organizations have one or more initiatives underway to improve their product development process. Live Traceability™, Model-Based Systems Engineering (MBSE), and digital engineering are the most common areas of focus. As engineers look over the fence and make fun of marketing types for being distracted by shiny objects, marketeers look back and see a similar behavior – just with geekier objects like SysML, digital twins, and simulation. The recurring pattern we see is that at some point during the early stages of the initiative, the realization hits that the data model for requirements across teams and projects is highly inconsistent and lacks consistent relationship rules among data objects. It becomes clear at this point that further progress on the initiatives cannot be made without first fixing the inconsistent and lacking data model.

Some teams will resist an effort to establish a consistent core data model. These teams will ask to keep the flexibility to refine their own engineering data shape and that is OK. The keyword is “refine” and not “define.” Having a consistent core data model, that some teams are allowed to refine for themselves, allows for innovation around the engineering process while still enabling process-wide, integration automation, Live Traceability, model-based systems engineering (MBSE), and digital engineering.

Current Requirements Data Model

For most companies, the data model mess came into existence through a project- and document-centric mindset with legacy requirements management tools. Each project team was allowed to modify their own data structures and each set of requirements lived alone as a document in a repository. This provided project teams with flexibility but over time and over dozens, hundreds, or thousands of projects has led to a challenging situation. We often find that teams have defined the same information in numerous different ways and that even within the same teams there is significant variance across documents. In short, the best way to describe the situation is as a repository of thousands of self-contained documents and no data model exists nor even a common definition of objects upon which to achieve Live Traceability, reuse across projects, MBSE, or digital engineering.

Achieving Live Traceability™ with Jama Connect^®

Jama Software^®‘s Live Traceability™ allows engineering teams to quickly and easily access the latest and most complete information for any requirement, no matter the stage of development or tools used. This real-time capability boosts productivity by ensuring teams work with the latest data and reduces risks like delays and defects by finding issues early. Research shows that issues found late can be much more expensive to fix, which is why Live Traceability is so important. Jama Connect^® helps overcome the limitations of older tools, leading to better results in many industries such as automotive, medical devices, aerospace & defense, and more. To learn more, visit Buyer’s Guide: Selecting a Requirements Management and Traceability Solution

What is Necessary to Move Forward

Organizations invest in software tools but have forgotten to invest in their data. A consistent data model is the best way to maximize the benefits of software tooling, but can only be achieved by spending time on analysis.

Jama Software has developed a Data Model Diagnostic™ (DMD) to help tackle this challenge, taking data from your legacy tool (IBM® DOORS®), understanding its shape and size, and transitioning the data into a model-based framework (Jama Connect™). The DMD automates the analysis of the existing documents to determine the most common object definitions upon which to base a consistent data model going forward. Once a data model has been determined, the next step is to implement a model-based, requirements management solution that ensures compliance is maintained. As opposed to a legacy, document-centric requirements management tool, a model-based one ensures consistent application of all objects AND defines and maintains the relationship rules among the objects. This forms a model representation of the requirements in a consistent manner across projects and is a necessary requirement for MBSE and SysML modeling.

To Get Started With Your Free Data Model Diagnostic™ Consultation: CLICK HERE

Systems Engineers Career Path

Most Systems Engineers we speak with have a common perspective on their role within their organization. Systems engineering as a concept is understood and supported by leadership. And, if systems engineering best practices are followed across all engineering disciplines, leadership also acknowledges the benefits the organization can realize. However, leadership will not force change on engineering disciplines (software, hardware, electrical, risk, verification, and validation) to remove barriers to systems engineering best practice adoption. This leaves most Systems Engineers in the challenging position of possessing responsibility for achieving systems engineering benefits without the authority to ensure engineers adopt best practices.

The good news is that there is a way out of this situation. The first step to elevating your career is to realize that managing the product engineering process through data is the key and that the Systems Engineering role is the natural role to lead this. For most organizations, the product engineering process is the only process in the company that is not managed through data. No one can go to a system and see the status of all product requirements and where development, integration, risk, and testing stand at any point in time. There is no way to manage by exception. There are no alerts that requirements are not covered, test cases are missed or that hardware made a change that now impacts software. Most organizations have come to accept this state of affairs and try to manage the process through endless meetings, emails, and Slack messages.

Until the product engineering process is manageable through data, Systems Engineers will be stuck in their current trap — endlessly trying to address issues after the fact, holding unwanted meetings, and the uphill battle of trying to persuade changes in behavior. Below is a 3-step approach that Systems Engineers we work with have used to solve this organizational challenge and have thereby elevated their careers. As with any process change, it is best to do it in stages. You can start with the following steps.

Baseline current process performance
Build the business case for change to gain support
Deliver quick wins

To Get Started With Your Free Traceability Diagnostic, CLICK HERE

Step Two | Build Business Case for Live Traceability™

Once you have established a baseline, it is now possible to build a business case for change that will resonate with leadership. Based on your baseline, the Traceability Diagnostic determines the probability of negative product outcomes (defects, delays, rework, cost overruns, etc.) and the magnitude of these events. This quantifies the risk of maintaining the status quo and doing nothing. In addition to the risk reduction potential of Live Traceability, the Diagnostic also calculates the engineering productivity gains from eliminating the need for time-consuming, manual, after-the-fact traceability efforts.

Step Three | Start with Quick Wins

Once you have secured support to move forward, it is common to be able to deliver some quick wins to the organization shortly after project kick-off. The typical place to start is the painful and time-consuming after-the-fact traceability efforts. For example, continuous syncing between requirements and software development task management in Jira or Azure DevOps can be set up quickly to automate traceability from requirements to user stories, eliminating a large source of risk and manual, after-the-fact traceability effort. Once quick wins are shown, organizational momentum increases even further and puts you on the success path to begin managing the product engineering process through data.

Clients of ours that have taken this approach have received significant recognition, been promoted into roles with greater leadership, and have increased their external visibility through speaking engagements. Live Traceability is a unique opportunity to elevate one’s career. Don’t miss the chance.

Live Requirements Traceability

Achieving Live Traceability™ of product requirements, as necessitated by industry standards, across siloed engineering teams and tools, is the #1 unsolved problem for most product development organizations. One of the main barriers is that each engineering discipline (systems, software, hardware, electrical, risk, verification and validation) has optimized its own process and tools. When looking at the end-to-end product development process siloed teams, tools, and data make it very challenging to trace development activity from initial requirement definition through development and testing.

As a result, requirements traceability becomes a time-consuming, error-prone, frustrating, and manual, after-the-fact process. The inability for the product development organization to continually trace ongoing development efforts and changes back to user and system requirements results in missed requirements, defects, rework, delays, audit letters, and cost overruns.

How to achieve Live Traceability™ without forcing change on engineering teams

So how does an organization achieve Live Traceability across a best-of-breed tool environment supporting disparate methodologies, terminologies, fields, and statuses? The answer is a 3-step approach:

Step One | Live Traceability Model

Define a Live Traceability model across the end-to-end product development process with relationship rules for the traceable data elements across best-of-breed tools. An automotive functional safety example is shown below. Here you can see the operational instantiation of functional safety standards requirements in a relationship model within Jama Connect®. All necessary traceable information is included with continuous syncs to best-of-breed tools within engineering teams to deliver Live Traceability.

Step Two | Adaptive Data Field Mapping

To achieve Live Traceability, integrations with best-of-breed tools (such as those shown in the example) are required. The typical integration approach standardizes field names and statuses to ensure consistency across the connected tool, but this does not achieve the dual objective of Live Traceability with no changes required in how each engineering team works. Alternately, the proven approach is to apply adaptive data field mapping to ensure no change to engineering teams’ fields and statuses which simultaneously ensures a consistent, process wide, Live Traceability model. This is achieved through robust mapping and normalization logic functionality to easily address the various approaches taken by each engineering team.

LEARN MORE

2022 Engineering Predictions: Overcoming Three Key Industry Challenges

In many ways 2021 was a continuation of the changes brought about in 2020, a year that’s been described as “unprecedented” and “unparalleled.” In a unique way, 2021 has offered us an idea of evolving innovations and technology on the horizon for teams across industries. These changing conditions will present a variety of new landscapes and will offer unique challenges, opportunities, and more than likely, many surprises.

As we enter a new year of further changes, Jama Software asked select thought leaders – both internal and external – across various industries for the trends and events they foresee unfolding over the next year and beyond.

In the first part of our five-part series, we ask Josh Turpen, Chief Product Officer at Jama Software, to weigh in on product and systems development trends he’s anticipating for engineering teams in 2022.

Read our other 2022 Industry Predictions here: Part Two – Medical Device Predictions, Part Three – Automotive Predictions, Part Four – Aerospace & Defense Predictions, and Part Five – Insurance Development Market Predictions.

Engineering Predictions

Design Trends

Q: What product, systems, and software development trends are you expecting to take shape in 2022?

Josh Turpen: Complexity will continue to increase and supply chain challenges will be a multiplier. The “chip shortage” is a great example. There aren’t too few chips, there are too few of the chips that OEMs are used to. Adaptable OEMs, with advanced product management and traceability, have been able to overcome this challenge.

Q: In terms of product and systems development, what do you think will remain the same over the next decade? What will change?

Josh Turpen: Software will continue to outpace hardware development, but hardware will close the gap. Connected tooling, simulation, and a transition to collaborative, JIT processes will enable hardware engineers to ditch the “one big meeting” for a more natural, asynchronous communication flow.

Q: How do you foresee regulations shifting in product and systems development for engineering teams over the next decade?

Josh Turpen: I still think my previous prediction (2021 Predictions) is accurate. Regulations are coming for software in a big way. This is the tip of the iceberg.

RELATED: G2 Names Jama Connect® the Leader in Requirements Management Software

And of course, you do not do that in your own ecosystem. You have many, many connections around you that have input on those decisions and have input on those connections, so engineering partners, customers, other departments within the company can be invited to take part in that process. We’ll take a look at that a little bit later on.

So, in the Jama Connect solution, we will take a look at the first part for data to information, so how do we actually relate information together and what is involved in building those relationships. And when I have them, what leverage, what value can and benefits can I get out of those relationships and what kind of overview do they give me? Now then, on the question part, we’ll take a little look as well on all the different areas where Jama Connect allows you to collaborate and to capture decisions and information on the changes you make during the process of building up your requirement.

Why would we do all these exercises in the system? What is the underlying question? There’s a number of questions we get on a daily basis from our customers when it comes to traceability, so questions like, did we miss anything? Are we building a product that is still complying to what we originally set out to do? What was the original requirement? Where do we start off from? Do we have everything covered when it comes to the validation or the actual testing of parts? The embracing change is something that a lot of customers are on different levels when it comes to how they approach change, but when you look at change, and actually before you do the change, you can see what will happen if you do change that item and what will happen if you start editing the information you have at the top level or at a medium level, it gives you a lot more insight into what will happen and what will the impact be for the organization. So, change becomes a bit more, let’s say, easier to look at and to decide what you want to do.

Then lastly, the validation part is one I highlighted. When I have all these items and places, information and plans, how can I go back and say, “Okay, I have everything validated. I have everything verified. I’m compliant to standards internally or external standards or processes that we set out to comply to.”

Watch the full webinar to learn more about best practices for requirements traceability.

Whether you’re just learning the basics of requirements management, looking to improve your current requirements management process, or interested in benchmarking your process against industry leaders, you’re in the right place.

This article covers what requirements management is, why managing requirements matters, what the requirements management process entails, and how to manage requirements when creating complex, highly regulated products.

What is a need?

A need is an agreed-to expectation for a product or system to perform some function or possess some quality within specified constraints with acceptable risk. Needs communicate what the stakeholders need and expect from a product or system in order for a given problem or opportunity to be addressed.

What is a requirement?

A requirement is the result of a formal transformation of one or more needs or parent requirements into an agreed-to obligation for a product or system to perform some function or possess some quality within specified constraints with acceptable risk.

There are different types of needs and requirements that range from a business focus to a user focus to a technical focus.

Business needs and requirements, sometimes referred to as stakeholder needs and requirements, are those derived from the business processes or elicited from the stakeholders including customers, users, and other stakeholders involved in the project. The stakeholder needs represent what the stakeholders need the product to do to address the problem or opportunity the product is to address; stakeholder requirements are stakeholder-own product requirements that communicate what the stakeholders require of the product to meet their needs. Stakeholder needs are expressed in natural language without the use of “shall”, while stakeholder requirements are communicated with “shall” to make sure they are treated as binding requirements the product will be verified to meet.

Given there are multiple stakeholders, there will be multiple sets of stakeholder needs and requirements. It is up to the project team to elicit these needs and requirements, resolve conflicts, inconsistencies, and other issues. The results will be an integrated set of needs from which the product requirements will be transformed from. The resulting product requirements represents what the product must do in order for the needs to be met. Product requirements are sometimes referred to as system requirements, software requirements, or technical requirements.

What is requirements management?

Requirements management is the process of gathering, analyzing, verifying, and validating the needs and requirements for the given product or system being developed. Successful requirements management ensures that completed deliverables meet the expectations of the stakeholders. Requirements can be managed using documents, however, complex systems or products in highly regulated industries mitigate risk by using trusted requirements management tools.

Why is requirements management important?

Requirements management is important because it empowers everyone to clearly understand stakeholder expectations and confidently deliver a product that has been verified to meet the requirements and validated to meet the needs.

Requirements management is a sophisticated process that includes many moving parts and diverse groups of people. Typically, the product management department, specifically the product manager, is responsible for the requirements management process. They work with the stakeholders, including business teams, customers, users, developers, testers, regulators, and quality assurance.

Additionally, a product may have only 100 requirements, or it may have several thousand. This depends on its complexity and level of regulation. With all these elements at play, success hinges on the ability to get everyone on the same page, working toward the same goal.

Therefore, the business value of managing requirements is huge, as successful requirements management is key to project success. Benefits of requirements management include:

Enhance understanding of stakeholder needs, requirements, and expectations and the problem or opportunity the product is to address
Gain clarity on scope, budget, and schedule
Minimize costly and time-consuming rework
Increase product quality
Mitigate risk
Improve likelihood of delivering the right product, within budget and schedule with the required quality.

The importance of requirements management is intensified, however, when building complex or highly regulated products. This is because more time and budget are invested in development. The cost of getting it wrong — be it money, time, or reputation — is too great to risk. Hence, developers in regulated industries, or those who develop products with a lengthy list of needs and requirements, tend to rely on requirements management tools, like Jama Connect® to keep their projects in order.

Requirements management vs. project management

While it may seem that requirements management and project management are synonymous, there is a difference. Simply, project management is getting the product built within budget and schedule with the available resources. Requirements management is making sure the product is the right product built right.

The goal of the product development process is to create a successful product that meets stakeholder, customer, and market needs. The requirements management piece of product development includes managing the needs and requirements so that the product meets stakeholder expectations. Therefore, needs and requirements along with budget and schedule set the scope for the project.

However, the domain of project management encompasses tasks like providing budget, personnel, and resources needed to develop the product.

Stages of the requirements management process

So, how do you manage requirements? The most successful teams work from a defined requirements management process. Defining the requirements management process is important because requirements change throughout a project. When this happens, that change needs to pass through the same, repeatable process.

There are four main stages of the requirements management process — planning, development, system verification, and system validation — each with important considerations to the overall project. Change management, while not a stage itself, affects nearly every phase of the requirements management process.

Planning Stage

The product development methodology—waterfall, agile, or Scrum—helps decide how requirements move through the process. Waterfall models are typically linear with development moving from one process area to another with a completed product delivered with the required features and functionality. Agile development, including Scrum, is iterative in nature. In requirements management, agile teams, and those using the Scrum approach, may be working on different sets of requirements concurrently, delivering a product in increments, each increment adding value with additional features or functionality.

No matter which methodology is employed, the RMP is the documented process the team uses throughout product development. It contains information like stakeholder roles and responsibilities, which needs and requirement artifacts will be defined, how traceability will be competed and managed, how needs and requirements baseline will be handled, how interactions (interfaces) with external systems and users will be managed, how changes will be managed, how the product will be verified to meet the requirements, and how the product will be validated to meet the needs.

A successful Requirements Management Plan is visible to and has sign off from stakeholders, as it sets the course and expectations for all stakeholders throughout the product development journey.

Needs and Requirements artifacts

Part of the RMP is defining the needs and requirements artifacts that will be created during the requirements management process.

Needs and requirements artifacts include the data and information concerning the needs and requirements and related information. Examples include diagrams, and models, integrated set of needs, set of product requirements, use cases, design documents, testing plans and procedures. Requirements artifacts are used throughout the product development lifecycle to:

Describe the product being built
Identify the actions needed to develop the product
Capture the actions performed during development
Define the testing needed for system verification and system validation
Assist with stakeholder review, communications, and engagement

While some organizations will communicate this information in a document form (e.g., a Software Requirements Specification (SRS)), the increasing trend is to manage the needs and requirements within a requirements management software application.

The reason organizations are moving towards a data-centric practice of product development is that is hard, for any document-based approach to be flexible and scalable enough for complex agile projects. This is especially true for highly regulated industries that must prove compliance. Due to numerous factors—lack of consistent updating, human error, incomplete data, version control, the need to establish and maintain traceability, etc.—documents simply cannot be relied upon determine whether a need or requirement is fulfilled.

Agile product teams working on complex products in highly regulated industries will have much more success using a requirements management software application to streamline the requirements analysis phase of requirements definition and management. Modern requirements definition and management solutions, like Jama Connect®, define, establish traceability, manage, and validate complex product requirements automatically, which simplifies not only requirements analysis, but the overall requirements definition and management process.

It is imperative that needs and requirements and needs and requirements artifacts are linked to each other and to additional related artifacts. This can be difficult to achieve using documents, as the manual nature lends itself to myriad errors. This is especially true in the case of complex or highly-regulated products where traceability is a prerequisite for proving compliance.

Needs and Requirements attributes

To keep track of the requirements in a given project, each requirement should have a specific list of attributes. Requirements attributes are used to ensure that requirements are organized and uniquely identified across all requirements artifacts. The attributes also aid in managing the sets of needs and requirements, enabling reporting and dashboards to be defined to provide accurate and timely status of the project.

It is a best practice that the following requirement attributes are included for all needs and requirements:

Unique Identifier
Rationale
Owner
Type
Definition status
Priority
Criticality
Compliance
Version number
Change history
Trace data
Verification status (for requirements)
Validation status (for needs)

Needs and Requirements Baseline

A needs and requirements baseline is a point-in-time look at a committed set of agreed-upon, reviewed, and approved needs and requirements, or planned functionality and features to be included in the product. The purpose is to provide information to stakeholders so they can make informed decisions on and possibly modify the planned functionality and features using change requests.

The RMP defines a baseline strategy including timing and frequency of creation, needs and requirements prioritization (deciding which requirements should be included), publishing, change management, requirements verification, and requirements validation. In this context needs and requirements verification address the quality of the needs and requirements statements as well as the existence and correctness of the traceability. Needs validation is confirmation with the stakeholders that the integrated set of needs clearly communicates the intent of the stakeholder in terms of what the need the product to do. Requirements validation is confirmation with the stakeholders that individual requirements and the set of requirements clearly communicate the intent of the needs they were transformed from. The quality of the requirements is dependent on the quality of the needs from which they were transformed.

Establishing a requirements baseline is important because it implies that:

Scope has been defined and agreed to – Critical to control scope creep!
Formal change control begins
Staffing levels and budgets are set
Schedule commitments are made

Typically, baselines are stored in software requirements specification (SRS) documents. However, a complex system might need a variety of software, hardware, and interface requirement specifications to encapsulate the baseline’s components. This can be cumbersome to maintain during initial development and downright impossible during change management.

Alternatively, working with baselines in a requirements management solution allows baselines to be defined as a subset of the requirements already stored in the database. This streamlines the process from prioritization through stakeholder sign off.

Requirements development stage

The development stage is conducted using the organization’s requirements analysis process.

The needs and requirements development stage incudes eliciting needs and requirements from the identified stakeholders, properly defining and refining them, and analyzing them to ensure clarity and resolve issues and conflicts. Without successful needs and requirements development there would surely be gaps between what the stakeholders expect and what is ultimately delivered. The result of which could be disastrous.

Eliciting needs and requirements

Also called needs and requirements gathering, eliciting needs and requirements is the act of working with users, customers, and internal business stakeholders to identify stakeholder needs and requirements and get an understanding of the product or system requirements.

Needs and requirements definition

Needs and requirements definition is the time when the gathered needs and requirements are re-written in a clear and traceable way that enables effective communication throughout the product development lifecycle.

There are many do’s and don’ts for writing needs and requirements, but the following are basic characteristics of quality needs and requirements:

Necessary
Unambiguous
Feasible
Verifiable
Correct
Traceable
Appropriate

A needs and requirement’s traceability is very important. At the end of the day, needs and requirements traceability is the only way to know if a need or requirement has been fulfilled by the design and built product. Bidirectional traceability—the ability to perform both forward and backward traceability, usually made possible via requirements management tools like Jama Connect—allows teams to understand why a specific need or requirement exists and easily analyze the impact of changes.

Furthermore, products in regulated industries must demonstrate traceability to prove compliance with standards and regulations. Therefore, when writing requirements, it’s paramount that each requirement maps to all corresponding artifacts.

A requirement’s traceability is very important. At the end of the day, requirements traceability is the only way to know if a requirement is fulfilled. Bidirectional traceability—the ability to perform both forward and backward traceability, usually made possible via requirements management tools like Jama Connect—allows teams to understand why a specific requirement exists, easily analyze the impact of change, and help prioritize requirements.

Furthermore, products in regulated industries must demonstrate traceability to prove compliance. Therefore, when writing requirements, it’s paramount that each requirement maps to all corresponding artifacts.

Many teams use a requirements traceability matrix (RTM) to track requirements and manage the scope of a requirements change. The RTM is static and maintained manually. The problem is that change is ubiquitous in the product development process. When change happens, teams must manually search the RTM document for all related upstream and downstream needs and requirements, dependent requirements and verification and valdidation tests that may be affected by the change.

Scouring through an excel spreadsheet for each change may not be that daunting if there are only one hundred or so needs and requirements. However, if the product has hundreds or thousands of needs and requirements—think complex, regulated products—managing the scope of change becomes a cumbersome and time draining exercise fraught with risk.

Requirements management tools are designed to streamline the process—even for highly complex, regulated products. Jama Connect, specifically, uses the benefits of Live Traceability™ to:

Easily determine the impact of change
Automate compliance
Enable end-to-end process improvement
Increase productivity
Reduce product risk
Increase quality

Requirements analysis

Sometimes, there is a gap between what stakeholders say they want and what they actually want. The purpose of requirements analysis is to ensure all business, software, and product requirements accurately represent stakeholder needs and requirements. The goal of requirements analysis is to get a clear understanding of stakeholder needs so the deliverable matches stakeholder expectations.

System Verification Stage

System verification means determining if the finished product meets the baselined product requirements. This is different than system validation (discussed below), which evaluates whether the product satisfies the stakeholder needs. are both important but system verification always comes first.

Planning for this stage starts when the product requirements are being defined. Planning includes, determining which system verification events are needed to confirm that product requirements are fulfilled.

To ensure successful system verification, the following attributes should be defined for each product requirement before the requirements are baselined, to set the expectations for the tests and quality assurance work that needs to be done and reduce the risk of rework efforts later.

Success criteria (what must be proven to show the requirement was met)
Method (test, demonstration, inspection, or analysis)
Strategy (approach to be used, operating environment, test environment, system configuration, etc.)

System Validation Stage

System validation means determining whether the product satisfies the stakeholder needs. are both important but successful system validation is what leads to product acceptance for its intended use, by the intended users, in the actual operational environment. For highly regulated products, approval for use is dependent on successful system validation. Final product acceptance by a customer also depends on successful system validation.

Planning for system validation starts when the integrated set of needs are being defined. Planning includes, determining which system validation events are needed to confirm that needs are fulfilled. One approach is to define a set of attributes that address system validation for each need.

To ensure successful system validation, the following attributes should be defined for each need before the needs are baselined, to set the expectations for the tests and quality assurance work that needs to be done and reduce the risk of rework efforts later.

Success criteria (what must be proven to show the need was met)
Method (test, demonstration, inspection, or analysis)
Strategy (approach to be used, operating environment, test environment, system configuration, etc.)

Challenges with requirements management

Requirements management has its share of challenges. As change management is so prevalent in the requirements management process, it’s a big hurdle teams need to address at the beginning of the project.

When building products that have thousands of requirements and countless changes, teams can spend hours circulating, editing, and tracking changes in an attempt to maintain traceability and simply keep development on track.

This is especially challenging when maintaining the needs and requirements in document form. Version control issues are one challenge that results from change. Versioning problems can arise on the artifact itself, for example someone might be giving feedback on SRS version one but there is already an SRS version two with different, additional edits. But version control can even be more granular, within the document as well. For example, requirement one might be on version three, which is linked to test B on version two.

Add that to consolidating feedback from multiple stakeholders via email or meetings, analyzing the impact of change across various versions of requirements artifacts, and communicating the correct changes and statuses to the right people. It’s a nightmare just thinking about how to keep it all straight.

The following are the top five challenges of requirements management:

Last-minute feedback
Decision rehashing
Change tax
Attention deficit
Mismatched expectations

It’s easy to recognize that problems are compounded when managing requirements using documents, or legacy systems based on documents, instead of a purpose-built requirements management tool. Most of these challenges, and more, can be overcome by switching from a document-centric to a data-centric approach to requirements management.

How to successfully manage requirements in complex products and highly regulated industries

The challenges above are real and mastering them can have significant impact on development timelines and budget. Developers in regulated industries — like automotive, aerospace, medical device, government, and industrial manufacturing — are further challenged by the need to prove compliance with regulations and standards.

Standards and Regulations can be a source of a large number of requirements the product must be compliant. Often not all of the requirements in a regulation or standard apply to your specific product. Often standards and regulations contain requirements not only on a product, but on the organization developing the product, as well as requirements concerning system verification and system validation (acceptance, certification, and qualification).

In addition, often requirements within standards and regulations are written poorly and ambiguously. As part of identifying drivers and constraints at the beginning of the project, the project team needs to identify which standards and regulations apply to their product and which requirements in those standards and regulations apply as well. Then they must write well-formed product requirements to address the intent of those requirements that will result in a product that is compliant with the applicable standards and regulations.

Regulations are not requirements. Requirements must be written to adequately satisfy the regulatory standards. A keen understanding of the standards or regulations is paramount in writing requirements that will lead to a product’s compliance. Once written, a regulatory requirement should be attributed as such in all requirements artifacts. This can be done be assigning a “compliance” attribute. This provides all team members visibility throughout development, which assists with decision making and change analysis.

In addition to expert knowledge of the standards and regulations, the following are needed to maintain product compliance when building a product:

Collaboration between teams
Single source of truth for defining, verifying, and validating compliance requirements
Standard frameworks aligned to standards and regulations
Traceability across all development activities and resulting artifacts.
Simplified audit preparation and data exports

Reporting is key when faced with a compliance audit. Teams must know what data is required for the audit and how to easily access it when needed. Often, audit trails are an afterthought in which teams are scrambling to pull together data from several sources. This is a dangerous practice, though, because it can risk delivery timelines and delay launch, or risk failing to launch altogether. Any teams that must show compliance, must eliminate this risk with a digital, detailed audit trail that can be easily exported whenever needed. Establishing and managing traceability is critical to be able to maintain the audit trail.

Many leaders in regulated industries rely on requirements management tools to reduce the risk of failure to comply with standards and regulations during the product development process. Jama Connect, for example, can track standards and regulations and compliance when building products. These industry leaders leverage Jama Connect to keep them at the forefront of innovation:

Benefits of requirements management tools

The advantages of requirements management tools are many. A modern solution can eliminate the risks and inefficiencies of documents and legacy systems.

A valuable requirements management system, like Jama Connect, can bridge engineering siloes throughout the development process, including test and risk activities. An effective tool helps improve the product development process by:

Ensuring quality and compliance
Managing risk
Increasing efficiency and optimizing processes
Easily understanding and responding to change
Improving traceability
Streamlining and accelerating reviews
Enabling real-time collaboration and iteration
Saving time
Improving quality

There are many requirements management tools available, but only a few that can help reap all the benefits listed above. When thinking about the most important features in a requirements management system, first think about what’s being built. The industry and complexity level will help inform the features that will be best for your team. This guide to buying a requirements management tool may also help.

From our experience, and what we hear from customers, the most important features of a requirements management system are:

Live bidirectional traceability
Real-time collaboration communication
Efficient and scalable review process
Simplified test and quality assurance management
Always-on risk analysis
Reusable requirements and baseline catalogs
Standardized validation and functional safety kits
Comprehensive visibility and compliance reporting
Fast implementation
Flexible configuration
Easy-to-use interface/administration
Automated integrations
Quality assessment of requirements and traceability

The good news is that you don’t have to pick and choose. Jama Connect helps navigate complexity and provides end-to-end compliance, risk mitigation, and process improvement with all the features listed above—and more.

See how Jama Connect can streamline complex requirements management.

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!

Audit trails are integral to regulatory compliance in industries ranging from medical device manufacturing to automotive production. But what’s the best way to build an audit trail that stands up to scrutiny?

Building a solid audit trail all starts with live traceability.

Why Live Traceability™ is Necessary

Live traceability is the tracking of requirements across the product development cycle. It documents the status of everything being worked on and shows the history of development along with the impacts of specific changes. Its benefits include easier regulatory compliance, more in-sync teams, and higher-quality releases.

In 2019, there were 50 medical devices recalled by the FDA — the most since 2014. Among other purposes, an audit trail helps strengthen product development controls and in turn curb the risk of recalls.

The top three reasons for recalls throughout the 2010s were device design flaws, software issues, and defective production processes. Audit trails document how such problems emerged. But too often, audit trails are assembled after the fact, without live traceability. Information may be pulled from numerous discrete documents, such as spreadsheets with hundreds of outdated entries. In contrast, live traceability happens along the way, adding supporting context for data relationships and contributing to better decision-making and future planning.

Live traceability makes it possible to both manage and respond to change in a systematic, auditable, and confidence-enhancing way. In our new infographic, we examine the ways that live traceability allows teams to build an audit trail.

Modern Product Development Requires Live Traceability™

One of the main reasons for implementing traceability software is to simplify regulatory compliance. Let’s say that a hypothetical medical device manufacturer is planning to bring a new connected device to the U.S. market.

The Food and Drug Administration requires compliance with regulations such as FDA 21 CFR Part 11, regarding electronic records and e-signatures. Creating a detailed audit trail to comply with these rules is more straightforward if a unified system of record with full version histories – i.e., a software traceability solution – is in place.

Modern traceability software (like Jama Connect) maps out the relationships and interdependencies in product development, allowing for assiduous tracking of risks and requirements in their full historical context. Real-time collaboration also enables even geographically distributed teams to stay on the same page in tracking and tracing work items. This level of traceability, with visibility into who made each change and for what reasons, has become especially important as products become more complex and software-driven.

Download the full infographic to learn more about building an audit trail through live traceability.

SEE FULL INFOGRAPHIC

Being a former McKinsey consultant, I have spent too much time immersed in frameworks, maturity models and methodologies. As I age, and my pragmatism grows, I find that many maturity models are too high level and vague and do not reflect the actual progression companies go through as they mature a given business function.

What I do find extremely useful are empirical maturity models since they categorize what companies are ACTUALLY doing TODAY in response to given challenges and pressures. Unfortunately, most models, rather than providing empirical data, are often just theory. The reason for this is because frequently, the author does not have access to large numbers of relevant companies willing to share their experience.

At Jama Software, we are quite fortunate to be working with hundreds of organizations immersed in maturing their requirements management approach within a broader product development process. Some are motivated to mature their requirements management process to reach compliance with relevant standards, others have experienced significant delays, cost overruns, or defects and are looking to improve process performance while the most advanced are able to measure end-end process performance and benchmark themselves against others.

The table below shows the key dimensions of requirements management and the five maturity levels we observe within our customer base.

Requirements Management Maturity Model

Let me start by describing the key dimensions:

Change Control – The process by which requirements are documented, versioned, reviewed, approved, tracked, centralized, access controlled, updated, and referenced post–decomposition into development.
Compliance Reporting – The generation of the necessary proof of process compliance to standards, most commonly: requirement validation, verification, traceability, risk assessments and test results.
Live Traceability™ – Visibility and traceability of the state of each requirement and its downstream decomposition, development, and testing at any time from requirement draft through to product release. Requirements that are static and trapped in documents have no system linkage to the entire product development process. Live Traceability reduces common product development risks of delays, missed requirements, rework, compliance gaps, limited reuse, defects, and recalls.
Process Improvement – Manage the product development process through data with the end-to-end visibility provided by live requirements traceability. Cycle time targets at various stages, rework percentages, process exception reporting, etc.
Benchmark – Once the end-to-end product development process can be measured, it can then be compared to peer organizations to determine areas to focus on for further process performance gains.

Organizations are at different levels of requirements management maturity across these dimensions. Here are descriptions of each level:

(0) No Formal Requirements – No documentation exists for user or system requirements. Instead, development operates off user stories with no clear distinction between the functionality of the system being built and the expected user experience.

(1) Document-Based Requirements – Static requirements documents are created and most often maintained by each author on his/her desktop with various emails, Slack comments, etc. containing more information.

(2) Siloed Requirements Tool – A standalone tool is in place to draft, review, track comments, version, and store static requirements documents.

(3) System-Based Compliance – Compliance is the forcing function to shift to live requirements traceability to meet standards for requirement validation, verification, and traceability in a single end-to-end system.

(4) Product Risk Reduction – A process-centric focus to reduce the likelihood of all forms of product risk via system–enabled Live Traceability. This requires detection and alerts for specification and functional changes, process exceptions, and test failures with the resulting impact analyses. The risks mitigated include:

(a) Failure to meet the needs of customers
(b) Failure to perform specified functions
(c) Delays
(d) Cost overruns
(e) Defects
(f) Compliance and regulatory gaps, delays, fines
(g) Recalls

(5) Development Process Improvement – Moving past compliance and risk and into the spirit of the standards based on quality management and process control. A focus on measuring, managing, and improving the product development process.

Current Level of Maturity

Now that the model has been described, the first question is: Which maturity level best describes your organization today? Before working with us, most companies we speak with are either using Microsoft Word/Excel and at level 1 or frustrated with their current tool and struggling to move much past level 2. Our top customers are at level 4 and moving to level 5.

Desired Level of Maturity

Once you have made an honest assessment of what level your organization is currently at, the next step is to determine your desired maturity level and gain organizational support for the change. We generally do not recommend jumping more than 2 levels for the first stage of a process change.

Next Step

Once you have completed your self-assessment of current and desired maturity levels, we would encourage you to reach out to us to speak with one of our consultants. We will listen to understand your organization’s unique needs and provide some guidance on best practices based on years of clients’ success.

To learn more on the topic of requirements management, we’ve curated some of our best resources for you here.

SEE MORE RESOURCES

Tag Archive for: Live Traceability Page 2