Tag Archive for: requirements management


G2 Names Jama Connect® the Leader in Requirements Management Software in their Spring 2022 Grid® Report

Thank You to Our Customers

Jama Connect® was again named the overall leader in the Spring 2022 G2 Grid® Report for Requirements Management Software!

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

    • Users Love Us: For products that have collected 20 reviews with an average rating of 4.0 stars.
    • Fastest Implementation: For products that had the shortest go-live time in their category.
    • Easiest Admin: For products that earn the highest Ease of Admin rating in their category
    • Momentum Leader: Based on employee growth, review growth, social growth, web growth, and year-over-year change
    • Leader: For products that are rated highly by G2 users and have substantial satisfaction and market presence scores.

Download the Spring 2022 G2® Grid for the top Requirements Management Software products HERE!


The “Users Love Us” category, in particular, is a testament to our commitment to our customers. We live vicariously through the successes of our customers. At Jama Software®, we strive to provide the highest level of service possible and look forward to continuing to provide our clients with the support and expertise they need to reach and exceed their product development goals.

“I like the freedom to store my documentation, requirements, risks, tests, and defects all in the same place. This, combined with Jama’s great tools for review and collaboration, make Jama an ideal tool to use for large teams and cross-functional activities..”

-From review collected and hosted on G2.com, Ryan Y, Process Engineer, Enterprise Market

Read Jama Connect reviews on G2

We are so grateful to our customers who took the time to provide open and honest feedback and review their experiences using Jama Connect for requirements management. We work hard to provide our customers with the expertise, attention, and resources needed to meet their goals, and we’re proud to be recognized in these categories and as the overall leader in requirements management software.

“Very easy to use; easy to set up reviews and track changes to requirements; like the option to export requirements into Word or Excel; worked well for a big team like ours-easy to manage the licences.”

-From review collected and hosted on G2.com, User in Transportation/Trucking/Railroad, Mid-Market

 

Review Jama Connect on G2

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


G2 scores products and sellers based on reviews, gathered from their user community, as well as data aggregated from online sources and social networks. Together, these scores are mapped on their proprietary G2 Grid®, which can be used to compare products, streamline the buying process, and quickly identify the best products based on the experiences of your peers.




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

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

What are FDA medical device class and classifications? 

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

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

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


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


Impact of the device class and classifications 

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

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

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


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


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

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

Learn more about developing medical devices with Jama Connect!



In this blog post, we recap a webinar discussing why Word & Excel are not enough to manage complex requirements. 


Product development is more complex today than ever before. Modern products are multifaceted and multidisciplinary, with hardware, software, and various engineering approaches coming together in the name of superior customer experience. Many industries — medical device, automotive, and aerospace and defense, for instance — also require that complex product developers adhere to rigorous safety standards and regulations. Companies must work effectively and efficiently if they’re going to keep their competitive advantage. And that all starts with requirements management.

In this webinar, experts will discuss how you can manage your requirements in a more efficient way than document and look at how to navigate between different versions (version control) and how to collaborate with your team on your requirements.

You will learn more about:

  • How using Word and Excel for requirements management introduces risk to your product development
  • The pitfalls of not having a formal requirements management solution
  • Benefits of a data-driven approach to requirements management
  • How Jama Software can help

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


Excel and Word Are Not Enough

Jerogen Frikken: All right. Thank you Marie for the great introduction. So today we’re going to focus on the requirement management tools and why Word and Excel just isn’t enough. We will first talk about the challenges in the pitfalls you will encounter when using a document based approach for your requirement management process. We will then show you the benefits of a data driven approach and why this is the preferred methods over a document approach. And we will end with an overview of how Jama could actually help you with this and close with a Q & A.

The development of products and the delivery of them are more complex today than ever before. Products today are having many different parts and are combining hardware, software, and various engineering approaches all together. Many industries like the medical device, automotive and aerospace and defense industry, for instance, also require that complex product developers apply to safety standards and regulations. Organizations have to work in a more efficient and […] if they want to stay ahead to their competition. Despite this, many teams are still using Word and Excel to manage requirements for these very complex products. This means they’re missing real time collaboration and insights, end to end traceability and integration with product testing.


RELATED POST: How To Write An Effective Product Requirements Document


Jerogen Frikken: Now, I am sure most of you are familiar with the term requirements management. But just in case you are not requirements management is the process of making sure you build just the right products. And for products that will have different releases or versions over time, understanding the changes to these requirements and their impact is a continuous process throughout the complete development cycle.

Basically you can view requirements management in three different ways. First, obtain and document the requirements. In a world of competing priorities and different opinions this is always a challenge and typically the responsibility of business analysts, system engineering and product owners.

Secondly, once we have documented the requirements we need to review and confirm they are the correct requirements. Are the requirements we document really what the user or the customer needs? Confirming this is often called the process of validation. And this is typically done by product managers, customers or users.

Last but not least. You may need to work with the requirements so you can confirm the teams have built the products according to the documented requirements. This process is typically called verifying the requirements or verification. Developers, testers, and quality assurance leads are key stakeholders in this process.

Watch the full webinar to learn more about Why Excel and Word Are Not Enough.

requirements-management-hub

READ MORE



Axendia

In this post, we recap a recent webinar hosted by Jama Software on the topic of requirements management in the medical device industry


Requirements management solutions enable the unification of siloed processes and data that often reside in outdated, disparate, and disconnected legacy systems. However ineffective and inefficient, the industry still relies overwhelmingly on static documents housed in Excel/Word and relies on manual processes that add significant risk to the development process.

Axendia conducted a research study focusing on the medical device industry’s approach to requirements management with a goal to identify and analyze the drivers, barriers, trends, and value of requirements management across the product development lifecycle.

9 out of 10 (87%) Executives surveyed for this report admitted to having a ‘not effective or somewhat effective’ requirements management process.

In a recent webinar, Axendia’s Senior Industry Analyst, Sandra K. Rodriguez and Jama Software’s medical and life science principal solutions lead, Steven Meadows, shared the outcomes of the research including:

  • The impact of having an ineffective requirements management process
  • The critical importance of requirements management to achieve improved patient outcomes, product quality, and time to market
  • The negative impact on budgets, verification and validation activities when relying on manual processes

Watch the full webinar to learn more about The Costly Impact of Ineffective Requirements Management in the Medical Device Industry.

 

Excerpt from webinar:

Requirements Management in the Medical Device Industry

Sandra Rodriguez: Thank you for that introduction, Marie, and good morning, good afternoon, or good evening, depending on where you’re joining us from today. Really quickly about Axendia, we were founded in 2005. Our headquarters are in Philadelphia, Pennsylvania. I’m physically located in San Juan Puerto, Rico, it’s a balmy 84 degrees today. What’s unique about Axendia is that our analysts all have industry experience. And combined, we average about 25 years of experience. We work with startup companies as well as fortune 500 global clients. And we really focus on the intersection of the business regulatory and technology trends that impact the industry. So really looking forward to sharing the outcomes of our latest market research on the state of requirements management in the medical device industry.

Just really quickly too, for the folks of you on the webinar today, congratulations, you will be the first to receive a copy of the research report. I’m not going to cover the report in its entirety today because we don’t want to take away the thunder of it, but we do hope that you will find today’s information valuable and timely and that you get some great takeaways from the report. Before I go into that, though, just a quick acknowledgment that the content of today has been sourced from our quantitative and qualitative research, as well as our interaction with FDA’s officials and industry executives, and then some firsthand experiences from our clients as well.

All right, so let’s start with the demographics. We surveyed a multitude of companies from around the world, companies that perhaps make more than one type of medical device product, but here you can see that the majority do market and sell single-use disposable consumable devices followed by diagnostic devices that have both hardware and software components and software as a medical device.

So those were the top three. As a result of that, we wanted to look at the data in a little bit more kind of slice it and dice it. So we specifically picked out software as a medical device, and you’ll see in the report, and as well as in the presentation today, how the opinions vary based on the type of medical device company that we surveyed for this report.

In addition, we got a good mix of small companies and large companies. The majority of the companies that did respond to the survey were under 50 million. So they could be startups, they could be a little bit pre-market followed by the $1 billion to $5 billion size companies when it comes to their revenue. So another thing that we did was we went ahead and compared these survey responses based on those two different size companies. We also got a significant number of R&D and product development personnel to take the survey, which is important.

These are what I call the boots on the ground, the companies that really understand requirements management inside and out. They’re the ones who are working on the new products as well as quality assurance personnel. And then we had a 17% representation of executive management. So another thing that you’ll see in the report is that we went back to the data and did do some comparison and filtering based on these three personas. And we were really surprised to see how the attitude shifted.


RELATED READING: 2022 Predictions for Medical Device Development


Sandra Rodriguez: From a geographic standpoint, we had a really good representation. Overall, the majority of survey respondents do work for companies that sell in market products in North America, so Canada, the United States, and Mexico followed by Europe and all the EU member states. And then, of course, Asia, South America, Africa, and Australia. So again, a really great representation of the medical device industry.

So this was our first question. And following the demographics, I think it’s really important to point out that this was the first question that it came when it came to requirements management processes. We wanted to understand from the market standpoint if people felt that their organization’s requirement management process was either effective or I’m sorry, not effective, somewhat effective, very effective or ideal. We were really surprised that when you combine not effective and somewhat effective, straight out the gate, we have a 68% of the market saying that there is a lot of room for improvement here. This is what I call aiming for average. And it’s definitely time for this to change because the complexity of the devices is changing. The regulatory landscape is changing. We have a lot more software as a medical device coming out there into the marketplace. And there’s a lot of hardware and software components that are going into these products, whether you’re doing remote monitoring of the products once they’re out in the field or in the patient.

So because of the complexity alone, you really need to have… You would want to see the very effective and ideal numbers go up because when we combine them, we’re only at 31%. And what’s really shocking is that only 2% of those companies that we surveyed for this research project believe that they have an ideal process. So we wanted to take a look at those numbers from the different personas. The quality personnel were of a little bit more positive. They believe that their requirements management process is very effective or ideal. So they account for about 53% of that. But when you look at the executive management, to have 87%, so almost 9 out of 10 executives indicating that their organization’s requirement process is not effective or only somewhat effective, that’s pretty shocking. Keep in mind that these are the folks that own the budgets.

So if you know that there’s a problem, we really need to do something to incentivize these folks to make the necessary change and get to that very effective or ideal state, even on the R&D and product development side, the same holds true with 68% of those professionals saying that their organization’s process is somewhat effective or not effective.

So we also asked the closed-loop system question. And we define a closed-loop system as one in which the desired output depends on the input signal and the feedback elements that are going to enable end-to-end traceability. So when you’re looking at a typical product development cycle, you have the finished product here in the middle. So you’re going from concept to prototype. Clinical, if you need to have a clinical trial for the type of medical device that you’re looking to bring to the market, going into manufacturing, marketing, commercial, and then obsolescence.


RELATED READING: Axendia Report: The Costly Impact of Ineffective Requirements Management


Sandra Rodriguez: So having that continuous feedback loop, really closing loop around that system, and having the necessary traceability that’s going to be required from a quality and from a regulatory standpoint. So we ask them, how effective is your organization at closing the loop across the product development cycle. Now, mind you, this was question number two. And we see here that 68% of the market, again, admitted that that process is not effective or only somewhat effective.

So again, really need to make the necessary changes there, and probably invest in the solutions so that you can close the gap and get that traceability and close the loop across the product life cycle. It’s interesting as an analyst because we don’t sell or implement software, but we stay really close to the market. And we follow these trends and we see significant investment in the life sciences when it comes to digital transformation or investing in business systems.

But it’s important to point out that without a product you wouldn’t be in business. So the solutions and the systems, the tools that you have in place when it comes to your product should be as important as the systems and tools that you give your salespeople, or your ERP, or however, you’re investing in those systems. You really need to make the necessary investments in order to make sure that your product is of the highest quality and that you can get to market sooner and on time and on budget because we’re going to learn in this presentation that the industry is really struggling with that.

Watch the full webinar to learn more about The Costly Impact of Ineffective Requirements Management in the Medical Device Industry.

READ MORE




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 second part of our five-part series, we ask Steven Meadows, Solutions Lead from Jama Software, and Ryan Moore and Carleda Wade, Solution Consultants from Jama Software – along with Thierry Marchal, Program Director for Healthcare Solutions at Ansys, and Ivan Ma, Medical Device Program Leadership, to weigh in on product and systems development trends they’re anticipating for medical device teams in 2022.  

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


Medical Device Predictions 

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

Steven Meadows, Jama Software 

Artificial Intelligence (AI) 

AI, and in particular machine learning (a subset of AI), has been expanding rapidly over the past decade and now has a market of over $6.7 billion across med tech. I see this trend continuing with extra guidance from the FDA helping developers produce safer software with AI elements. AI is particularly exciting as it can enable streamlined MRI and CT scans, instant blood and at-home rapid testing, and a whole host of otherwise manual and often error prone activities.  

 Minimally invasive devices  

Another trend I see in medical continuing in 2022 and beyond is the rapid growth and development of minimally invasive devices. Open heart surgeries are becoming a thing of the past, with cardiothoracic applications becoming the norm. Minimally invasive devices are also becoming heavily utilized throughout most orthopedic surgeries, and increasingly in urology procedures. We have seen a lot of start-ups attempting to bring the next best minimally invasive device to market. 

 Wearables 

Medical wearable devices demand continues to rise, with apps on wearable devices beginning to provide recommendations to users, to improve their health. Heart rate and temperature sensing continue to be the most popular features on wearable tech today but there is increased investment in smart glasses, ‘earables’, and clothing. 

Software development 

Software will continue to be an integral part of many medical devices next year and beyond. We consistently see that our software customers have adopted, or are transitioning to, an Agile methodology when creating their medical system, a shift that has been happening for some time. Gone are the days of slow waterfall-based development practices. 

As I mentioned before, AI based software development will continue to trend and grow next year, and AI software development practices will be geared around a tailored regulatory framework, good machine learning practices, and a patient centered approach. The FDA will continue to refine guidance around AI/Machine Learning (ML.)

Cybersecurity and in particular data security will continue to be a top priority for our software customers, with data breaches and hacks on the rise. The FDA is planning to soon release extra guidance around cyber security in medical devices with a particular emphasis on quality system considerations and content of premarket submissions. 

Ryan Moore, Jama Software 

I anticipate a trend toward more software-based toolsets and digitization. Also, an increased amount of automation and robotics 

Carleda Wade, Jama Software 

I expect greater integration of software tools such as with Requirements Management software with eQMS software. 

requirements-management-hub

Thierry Marchal, Ansys 

The dramatic COVID pandemic has amplified a trend that appeared a decade ago – progressively calling for the adoption and deployment of in silico medicine. Stormed with the COVID pandemic, the world could not wait for 10 to 15 years to get a new vaccine fully tested and approved using a traditional approach. Furthermore, this COVID disease is impacting people differently, while elderly people are impacted the most, possibly leading to long term disabilities and treatments.  


EDITOR’S NOTE: According to The University of Sheffield’s Insigneo Institute, In silico medicine (also known as ‘computational medicine’) indicates modeling and simulation technologies that directly contribute to the prevention, diagnosis, prognosis, treatment planning & execution, or management of the disease. In silico methods complement traditional in vivo approaches (working with animals and human beings) and in vitro testing (working in a lab.)


Thierry Marchal, Ansys:  

This pandemic highlights what we have been observing for decades: with an aging population, the cost of chronic diseases (especially for old people) is weighing a lot on the healthcare cost. The solution will come from personalized medicine and preventive medicine combining pathologies detection in its early stage to treat diseases before they impact people. The continuous monitoring of patients to detect pathologies early are calling for e-health and mobile health (m-health): wearable and implantable devices continuously and safely watching the patient and soon feeding your own digital twin or Personal Digital Avatar (a computer model of yourself, connected with you, and properly stored in the cloud to guarantee your data privacy) is now an emerging trend. Digital twins will be a crucial innovation for the software necessary to use patient specific data to predict the evolution of the connected patients.

As medical innovation will be essential soon, this evolution cannot be slowed down by an extremely long and costly regulatory approval process: a digitalization of drug and medical device approval, including in silico (clinical) trial is another major trend that we are observing. 

Ivan Ma, Medical Device Program Lead: 

Technologies that enable capabilities via telemedicine with more than just a face and a voice over the screen will make “seeing” the doctor digitally as common place as working from home. 

Protecting patients, physicians, and staff by reducing or eliminating exposure to harmful forms of imaging such as fluoroscopy will always be a valuable endeavor.   

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

 Steven Meadows, Jama Software: 

A lot of the areas I mentioned that will trend in 2022, will more than likely trend over the next decade. 

AI, not only in medical but across most industries, is on the rise and patients will continue to see improved outcomes, quicker diagnoses, and a better quality of life.  

Medical wearable technology will continue to evolve, with improved functionality helping keep us fitter and safer. 

Minimally invasive devices will continue to be expanded across different medical areas, improving recovery times, and surgery outcomes. Increasing emphasis on cybersecurity will resume, to prevent malicious actors from hacking sensitive data and for connected systems to remain operational. 

COVID-19 is not going away any time soon so a reliance on collaborative product development tools, like Jama Software, will continue to be an integral part of any organization placing an importance on quality and overall product and patient outcomes.  

Ryan Moore, Jama Software:  

Medical devices will still be comprised of mainly hardware (HW)/software (SW), while automation and robotics will be a driving force. And users will still need to power devices.  

Carleda Wade, Jama Software:  

Medical device development will mostly stay the same as the regulations are fairly stable. HoweverI do expect increased usage of software in the process since much of the workforce may now be working in various locations. I also expect to see an increase in AI and Software as a Medical Device (SaMD) as a whole in the industry.  

Q: What are some of the biggest challenges you think engineering firms will be working to overcome in 2022?  

Thierry Marchal, Ansys 

Contrary to other industries, innovation in healthcare faces the challenge of human variability: as we are all different, it is not acceptable that a treatment would work well for a few people and poorly for most others. Using computer modeling and simulation (CM&S a.k.a. in silico methods) is a cost-effective way to test new treatments efficiently without compromising with patient safety, on large cohorts of virtual patients. 

An accurate prediction of the treatment outcome for a given patient will require combining traditional modeling techniques with biological models, often extracted from big data observations using AI. 

Finally, the community remains skeptical about the reliability of computer model and digital evidence to predict correctly and accurately what is happening in the real life. This credibility challenge will be continuously addressed by more validations and comparisons with in vitro and in vivo data. 

Ivan Ma, Experienced Medical Device Developer:  

The development of medical device hardware will always require teams to gather in front of and handle hardware. As the pandemic continues, and in-person work still not back to what it once was, it is time to think of strategies that maximize time on developing hardware with minimal people in the room. Could digital Operating Room technologies be reconfigured and brought in to support the verification and validation phases of medical device development? The tenets are the same. Minimize the number of people in the room, allow the expert to drive the hardware from afar, make data acquisition, observation and learning access as easy as clicking on a link. 

Q: How do you foresee regulations shifting in medical device product and systems development over the next decade?  

Steven Meadows, Jama Software 

Although AI has been utilized in medical device and life science products for decades, guidance has been lagging. It’s clear to see that AI has incredible benefits for patients, and so there will continue to be increased regulatory guidance available, to help developers build products which contain AI in a safer and standardized manner. Check out a blog Jama Software authored around machine learning in SaMD and shifting regulations here. 

The medical device regulation (MDR), which was accepted and implemented in the EU in 2017, has been amended over the past few years. The latest change focuses on increasing the responsibility and accountability of medical device companies throughout the entire development of a product. Expect more guidance over the next decade, as gaps are addressed to ensure product safety is at the forefront of any market clearance.   

Ryan Moore, Jama Software 

I would expect compliance and regulations to be more defined as we move forward. Currently, there is a lot of grey area in how standards/regulations are interpreted. The FDA will need clearer guidance for modern technology that arises 

Carleda Wade, Jama Software 

With an uptick in AI and SaMD I expect the FDA and foreign regulatory bodies to begin providing more clarity on how these complex systems and software needs to be developed, validated, and maintained.  


RELATED POST: EU MDR What You Need to Know


Q: What changing regulatory guidelines do you anticipate having an impact on companies in 2022? 

Thierry Marchal, Ansys:  

The US authorities developed, without any doubt, the most advanced regulation in terms of adoption of computer model results for the regulatory approval process. However, the number of published cases reporting the actual use of in silico methods by sponsors remains limited. New results will be published in 2022 further encouraging companies to confidently follow this process. 

The European Medical Device Regulation (MDR), in application in Europe since May 2021, is opening the door to digital evidence and in silico approach; unfortunately, the process to validate a model and report simulation results has not been clarified yet. Similarly, as the European authorities are updating their pharmaceutical strategy in 2022, this document is expected to make references to computer modeling and simulation. 

In the rest of the world, we observe a growing interest for in silico methods and the need to regulate this approach. After years of compiling information and experience from other parts of the world, we are expecting that some Asian authorities will start to communicate about this topic in 2022. 

Q: What sorts of process adjustments do you think medical device development teams will need to make to be successful in 2022?  

Steven Meadows, Jama Software 

One of the biggest process issues we see across our customers is that they view quality as a secondary function and a necessary checkbox activity once a product is developed, or close to being finalized. Because of that, products tend to contain more defects, resulting in more in field CAPAs, negative patient outcomes and even have a greater chance of being recalled. Development teams should ensure quality is prioritized from the get-go.  

Although we have noticed a large shift with software teams adopting an Agile approach when it comes to development, we can’t emphasize enough the importance of adopting a lean and iterative approach.  

Ryan Moore, Jama Software:  

Continue to follow standardized process with focus on aligning with FDA / compliance in parallel with building safe products 

Carleda Wade, Jama Software:  

Teams will need to find the sweet spot of trying to collaborate and innovate while not being physically in the same location at the same time. Due to the pandemic, many teams will now transition to being fully remote permanently or have a hybrid schedule and it may make things more difficult when developing new products with a cross-functional team.    


RELATED POST: Realigning Engineering Teams for Remote Work with Minimal Disruption


Q: From an engineering toolset perspective, what are some of the processes you believe forward-thinking firms will be working to leverage or incorporate into their process and why? 

Theirry Marchal, Ansys:  

As we see the healthcare community adopting in silico method with more enthusiasm both for design and regulatory approval (not mentioning emerging clinical applications), the software community is rushing to deliver the supporting in silico tools. We could mention three major avenues followed by Ansys. 

As in silico clinical trials requires a large number of simulations, specific Simulation Process and Data Management (SPDM) tools structuring the digital evidence following the ASME VVUQ40 standard will greatly facilitate the adoption of this approach. Ansys is customizing its Minerva tool in a Minerva VVUQ 40 template for medical device and pharmaceutical companies. 

It is crucial to model the behavior of a new treatment in its working environment, usually the human body. Human organs such as the heart, the lungs, and the brain are extremely complex to model and validate: this requires a collaboration of various actors. Ansys is closely working with leading academics, global healthcare companies and startups, and clinicians to continuously update and validate virtual hearts, lungs, and brains in collaboration with a large ecosystem. 

Although everybody recognizes the potential of digital twin and Personal Digital Avatar, the necessity of developing quasi-instantaneous modeling capabilities despite the complexity of the model is a real challenge. Ansys is taking advantage of its experience with other industries already using digital twin of equipment to help the pharmaceutical industry to develop digital twin of drug manufacturing equipment and initiate the first steps towards Personal Digital Avatars. 

Ivan Ma, Medical Device Program Lead:  

Engineers need tools that minimize the volatility and error that occurs when bringing hardware and electronics from the drawing board to parts in hand. How do organizations reduce hardware prototype cycles, recognizing that even if the design is right on paper, the production of that design can pass through many hands before it is made into a real part, thus decreasing the probability of a successful build.     

Q: What do you think will be some of the differentiators between a company surviving to see 2030, and those that do not? 

Steven Meadows, Jama Software 

Along the lines of what I mentioned companies should focus on in 2022 to be successful, medical device companies that embrace a proactive approach to quality (Link here – https://www.jamasoftware.com/blog/three-ways-to-proactively-vs-reactively-incorporate-design-controls-in-medical-device-product-development/ )will ultimately find fewer issues with their products, improve customer satisfaction, and stay competitive for the foreseeable future. Companies that invest in best-of-breed medical device development solutions like Jama Connect will have the upper hand in reducing risk and complying with various standards and regulations. 

New cutting-edge technologies in the medical field – like robotics nanotechnology, AI, and wearable health tech devices – bring complexities for medical device companies and risk for patients and consumers. Jama Software will continue to serve as the leading solution and partner to help innovative companies bring medical products to market, in a collaborative, safe, and efficient way. 


RELATED POST: Improving Quality Processes for Medical Device Development


Ryan Moore, Jama Software:  

Defined process, building quality products that meet a specific market need 

Carleda Wade, Jama Software:  

Truly understanding the market needs and being willing to allocate resources so that you become a pioneer in a certain industry will help a lot of companies to succeed; however, having passionate and qualified personnel will be the biggest success factor. Companies that only want to develop “me too” devices will struggle to gain market share, and even if they are able to survive it will be difficult for them to thrive.  

Q: Where do you see Jama Software fitting in as the product development landscape evolves, and what can our customers expect as 2022 approaches? 

Steven Meadows, Jama Software:  

Jama Software provides incredible value for hundreds of medical device companies ranging from start-ups to established corporations. With COVID-19, we’ve seen an uptick in customers looking for an easy-to-use product development tool that offers differentiating collaborative capabilities to keep people connected throughout different design stages. Jama Software continues to invest heavily in the application, and we will see improved core product capabilities as well as integrations, strengthening the tool’s ability to seamlessly work alongside other systems. 

Ryan Moore, Jama Software:  

Jama Connect can be used as the core toolset for requirements, testing, and review/approvals. Jama Software’s ability to branch out into further workstreams (in order of priority: risk management, test automation, modeling/design outputs) will bring exponential value to teams using Jama Connect.  

Carleda Wade, Jama Software:  

I can see Jama Software bringing value to not only the start-up but the established company in the future. As a medical device company, the first goal of the company is to make a good product that meets a market need, this happens even before establishing a quality management system in many cases. Having a tool like Jama Connect will ensure that as products are developed that all the bases are covered. Later, when it is time for regulatory approval having a tool like Jama Connect in place will make the regulatory submission process very simple.  


Thanks for tuning into our 2022 Predictions Series! To see some of the incredible products, software, and systems our customers are building with Jama Connect, visit our CUSTOMER STORIES PAGE. 

 




Requirements Management Plan 

Product success depends upon the successful project management of the product’s requirements. Effective requirements management, in turn, requires thoughtful planning. 

 A requirements management plan describes how you will gather, analyze, document and manage the requirements of the project. It should describe how you intend to gather the high-level project and product requirements from project stakeholders, industry standards and governmental regulations, as well as the more detailed product requirements you will collect and develop over the project lifecycle. Your requirements management plan should also specify how you will manage changes to requirements after they have been approved. 

Your requirements management plan is a tool for communication. It provides all your project’s stakeholders with a common understanding of how the product’s requirements will be managed to ensure success. 

In this article, we’ll describe the requirements management planning and the recommended components of a requirements management plan. 

What is Requirements Management Planning 

Requirements Management Planning is the process of documenting how you will gather, analyze, document and manage the requirements of a project, manage changes to requirements once they have been approved, manage the configuration of the requirements documentation, and track verification of the project’s requirements. 

Components of a requirements management plan 

A solid requirements management plan will be composed of several components. Here, we’ll describe our recommended sections. Depending upon your industry and organization, not all of these sections may be applicable to your situation. 

Project overview 

Briefly describe the purpose of the project. Explain the need the product will fill for the customer or target market and how its development will benefit your company. Mention important goals for the project and any notable constraints that may have been imposed upon it.  

Roles and responsibilities 

This section lists the roles of those who will be involved with managing the requirements through the rest of the project lifecycle, along with the responsibilities of each role. 

Typical roles include: 

  • Project manager 
  • Lead analyst / lead requirements engineer 
  • Analyst / requirements engineer 
  • Stakeholder 

The project manager typically has overall responsibility for managing the scope of the requirements for the project.  

The lead analyst / lead requirements engineer may also be a lead systems engineer or lead developer. This role is generally given overall responsibility for requirements development and integrity.  

Analysts and requirements engineers assist the lead analyst / lead requirements engineer and are typically tasked with following the specified procedures for managing the subset of the project’s requirements for which they have been given responsibility. 

Other project stakeholders who provide input to the requirements base are generally given responsibility for reviewing the requirements at specified milestones. 

Tools 

In this section of your plan, describe any automated tools that will be used to manage the requirements. Provide a brief overview of how those tools will be used during the requirements management process, and reference any documented procedures governing the use of the tools.  

More detailed descriptions of how the tools shall be used in the various steps of the process should be provided in the sections of the plan that describe those steps. 

Requirements gathering 

Describe the process that you will use to elicit, analyze and document the requirements. Then, describe the requirements gathering techniques you will use and with what groups you will use them. 


RELATED POST: 11 Requirements Gathering Techniques for Agile Product Teams


Categorization and assignment 

Here, you will describe your process and procedures for dealing with various types of requirements. 

Describe how requirements will be categorized within your requirements management system. Typical categories include:  

  • Functional 
  • Non-functional 
  • Internal 
  • External 
  • Regulatory 
  • Performance 
  • Quality 
  • Training 
  • Support 
  • Maintenance 

 The difference between functional and non-functional requirements—what the product must do versus any constraints on how the product must be constructed—normally impacts how the requirement will be verified. For more information on non-functional requirements and their impact on product development, click here. 

Internal requirements will generally be driven by the needs of stakeholders within your organization. External requirements will include those driven by customers, market forces, government regulations industry standards, etc. 

A requirement’s category will dictate, in part, how it is assigned for development, implementation and verification. Your plan should describe your policies and procedures for assigning requirements to subsystems or components or by work breakdown structure (WBS). 

Prioritization 

Companies will prioritize the fulfillment of some requirements over others. Reasons for high prioritization may include market demand, regulatory compliance, contractual obligation, or internal stakeholder need. 

That’s why it’s important to plan and document how you will prioritize requirements for development and release. Keep in mind that you will likely describe in detail your rules for prioritizing requirements in your Product Requirements Document. 

Traceability 

Describe your overall process for tracing requirements throughout the product lifecycle: from gathering, through decomposition, development, implementation and verification. Mention the tools to be used to accomplish the traceability process. 

Requirements and their attributes need to be tracked throughout the project lifecycle to ensure fulfillment. Attributes to be tracked may include: 

  • Name
  • Type 
  • Project unique identifier 
  • Source (stakeholder, document, parent requirement, etc.) 
  • Children (lower level requirements derived from the requirement) 
  • Assigned element of the WBS where it will be addressed 
  • Verification method (if your project requires a variety of methods) 
  • Verification reference (to the procedure that will verify the requirement) 
  • Compliance reference (applicable regulations/paragraphs) 

RELATED POST: What Is Requirements Traceability and Why Does It Matter for Product Teams


Change management 

As a project evolves, requirements will need to be added or modified. Therefore, your requirements management plan should include a section that describes your policies and procedures for change control. 

Change management (or change control) generally involves documenting each proposed requirements change in a change request. Once written, the change request is analyzed by affected stakeholders for any possible impact on project objectives or other requirements. The change request then goes before a change control board where it is either accepted (to be implemented) or rejected (and either revised or dropped). Your procedures for change control (raising, reviewing, tracking and approving change requests) should be described or referenced in this section. 

Configuration management 

Describe how you will monitor and control changes to your requirements documentation. Configuration management deals primarily with how documents will be revised and released during a project. 

For many projects, depending upon your organization, this section may be combined with the Change Management section just described. For very large projects, you may want a separate Configuration Management section. If you have a separate Configuration Management Plan you’ll probably want to reference it and keep this section brief. 

Verification 

Finally, describe the methods and metrics you will use to verify requirements. Specify how their achievement will be measured, tested, etc.  

If you use a variety of verification methods to verify different types of requirements, you will likely want to give a brief explanation of the procedures for each and how each type of verification is documented.  

Benefits of requirements management planning 

As mentioned earlier, your requirements management plan is a tool for communication. It helps your analysts, systems engineers and developers get up to speed and stay on the same page when it comes to managing your project’s requirements. Plus, it gives higher-level stakeholders a warm, fuzzy feeling that your product’s requirements will be properly managed to ensure your product’s success. 

For more in-depth information… 

Requirements management and requirements management planning can be greatly simplified through the use of a state-of-the-art requirements management tool like Jama Connect. For a deeper dive, visit our Essential Guide to Requirements Management

requirements-management-hub




In the quest for a successful product development process, there are any number of steps that could go wrong or lead to release delays or cost overruns. Few, however, are as vital to a good outcome as the requirements gathering process.

The requirements gathering process is central to a timely and efficient release of a product that fulfills expected deliverables. Unfortunately, this important step is too often rushed, condensed, or truncated. When all of the relevant stakeholders aren’t consulted for input, the requirements document won’t include everything necessary for a successful product, and the process may be doomed to failure before design even begins.

To help you gather the right requirements from the right people, Jama has assembled this step-by-step guide to the requirements gathering process.

A Step-By-Step Guide to the Requirements Gathering Process

If you’ve waited until project kick-off to start gathering requirements, you may have already waited too long. Requirements gathering should begin as soon as possible—even before the official beginning of the project, if possible.


RELATED POST: What is Requirements Gathering?


And requirements gathering should be an ongoing process. Obviously, there’s a point where the real design work must begin, but you should always have an ear and eye open to catch additional requirements as they arise. The earlier you can catch new or revised requirements, the easier it will be to integrate them and avoid delays or cost overruns.

With that somewhat fluid and holistic perspective in mind, there is still value in defining a more linear process that can give a framework for ongoing requirements gathering. Here is a good starting point for gathering requirements for your next project, broken down into three phases:

Phase One: Requirements Elicitation

The initial phase of requirements gathering is elicitation, which is just a process of collecting all of the top-requirements from all relevant stakeholders through a series of sessions, meetings, surveys, interviews, or other means. The elicitation process can be broken down into four steps:

1: Establish stakeholders. The very first step in requirements gathering is figuring out whose input to include in the process. You can split stakeholders into three basic groups:

    • Internal stakeholders: These are the people inside the company or on the development team who have a direct interest in positive outcomes. Internal stakeholders can include the project sponsor, managers, SMEs, and others.
    • Technical stakeholders: Technical stakeholders are the teams and leaders responsible for developing and implementing the project or product. This group may include developers, testers, solution architects, and other support teams.
    • External stakeholders: This group will have an interest in the outcome of the project, but will not necessarily be directly involved in development. External stakeholders may include compliance and regulatory groups, business analysts, or customers and end users.

2: Define initial scope of the project. Defining project scope is key to avoiding scope creep along the way. While it’s important to recognize that the scope may change after requirements gathering sessions, defining the initial scope can help keep the project from getting out of control early on.

3: Set up requirements gathering sessions. Once you’ve established the various stakeholders, start holding sessions to gather requirements. These meetings could include internal or external stakeholders or even a combination of both. For a successful session, follow these guidelines:

    • Establish a clear agenda ahead of time. Write out the main points to be covered in the meeting, including any specific questions or development items for which you need to write requirements.
    • Take notes. Never assume that someone else is taking notes! Write your notes under each agenda item so that you start grouping requirements. For example, if you know that a particular integration will be necessary, make notes under that heading on your agenda to keep those requirements together. Review your notes immediately after your meetings and send to internal teams to make sure everything is captured in one place. Save your notes to a shared folder for the entire team.
    • Start creating tasks. After notes are completed, use them to start creating tasks and action items and defining deliverables. Set up future meetings as needed to capture additional action items and requirements.

4: Get creative. Initial requirements gathering sessions may be focused more around technical stakeholders or business analysts, but be sure to include time to gather input from creative team members—marketing, design, and others. It’s also good to include sessions with end users, sales team members, and others who can offer input on what features and benefits the final product should include.


For a deep dive into requirements gathering techniques, visit: 11 Requirements Gathering Techniques for Agile Product Teams


Phase Two: Requirements Documentation

In the documentation phase, the development team organizes input in the form of user stories, functional decompositions, feature descriptions, and the like. We break this phase into three steps:

  1. Write the Marketing Requirement Document (MRD). The MRD is the document that expresses a customer’s needs or wants in a final product from the development team. This document will help define customers and their pain points, identify competitors, and establish business needs and desired business outcomes.
  2. Revise scope, if necessary. This isn’t an opportunity to completely redefine the project concept or scope, but rather a modification step that takes into consideration all of the requirements gathering sessions. The point of this step is simply to make sure the scope is defined as completely as possible to avoid future scope creep.
  3. Write the Product Requirement Document (PRD). Or collect the requirements in some other format that your team or organization has agreed to use—a spreadsheet, a database, or a requirements management tool like Jama Connect. This document should include relevant insights from the MRD and other supporting early notes. It should also integrate user stories, feature descriptions, functional and non-functional requirements, etc. It should have four main components: purpose, features, release criteria, and timeline.

 Phase Three: Submit for Review

Once you’ve conducted multiple requirements gathering sessions and completed the initial documentation, it’s time for review.

  1. Confirm requirements with stakeholders. Involve as many of the original stakeholders as possible. Ask them to review the requirements as defined in documentation. Are the requirements clear to all parties? Did the product development team miss any important requirements? Revise any requirements that are unclear to all parties. Be sure to get sign-off on individual requirements by relevant stakeholders.
  2. Conduct prototyping and testing. Wherever possible, conduct initial prototyping and testing on a working model of your specification. Perform feasibility, usability, and product concept testing. This step should be conducted at the same time as the previous step so that results can be shared with stakeholders.
  3. Prioritize requirements. Once requirements are clarified and signed off, the team should prioritize them with as specificity as possible. More than just noting whether a requirement is a “must have” or “nice to have,” prioritization should also involve ranking each requirement within the higher categories.

There is much room for overlap between these phases and steps, and it may feel overwhelming to undertake the entire requirement gathering process before any design or development begins. However, spending the time to conduct a thorough requirements gathering process can save time and money and create a much higher probability of success for your project.

Common Pitfalls of Requirement Gathering

Even when a thorough process is undertaken, teams can encounter challenges and pitfalls along the way that risk introducing delays into the project development process.

  • Making assumptions or not clarifying requirements. When faced with a long list of stakeholders or requirements gathering sessions, it’s tempting to make assumptions. Take the time to clarify, ask more specific questions, and get as much detail as possible. And be sure to be as specific as possible in your confirmation process!
  • Focusing on HOW instead of WHAT. Requirements should address WHAT a product MUST do (the functional requirements) and WHAT constraints it will have on how it achieves that functionality (the non-functional requirements). Don’t let assumptions about tools, features, techniques, implementation, or other development concerns influence how you gather and write requirements. Just listen to the needs of stakeholders and write the requirements to those needs.
  • Failing to adequately consult stakeholders. This pitfall could take several forms. It may mean not conducting enough sessions at the beginning of the process, or it could mean not adequately confirming requirements before beginning design and development. Be sure to get a thorough review and sign-off of all requirements before moving on to the next phase. One way to do this is with a good requirement management (RM) tool such as Jama Connect. With a requirements management tool, everyone has access to the same information, and notes and other feedback can be attached directly to requirements for traceability purposes.

Requirements Gathering for Agile Development

While the requirements gathering process outlined above is ideal for many projects, Agile teams have different needs, and an extensive requirement gathering process could interfere with their results. Agile teams expect to work fast, and scrums and sprints are typically just a few weeks, at most.

For Agile teams, a robust requirement management tool can streamline requirements gathering and management without sacrificing results. With a tool like Jama Connect, teams have transparency and access to requirements at all times, allowing easy annotation and clear traceability. Requirements management products encourage collaboration throughout the ALM product development process and offer clear advantages over static tools such as spreadsheets or simple documents.

Comprehensive requirements gathering is the key to a successful product development process. By clearly defining requirements and scope up front and getting sign-off from all stakeholders before full design begins, teams will have a much clearer path to product development success. While it’s no replacement for a requirements management solution like Jama Connect, which automates Live Traceability™, download this project requirements template to make things simpler.

 

requirements-management-hub




This is Part 2 of a series examining the role legacy requirements management solutions, such as IBM® DOORS®, play in introducing project risk to the product development process. To read Part 1,  visit Why Migrate, Why Now?: Part 1

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 IBM 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.

requirements-management-hub

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.

“Jama Connect lowers the complexity and burden of having to manually keep requirements, architecture and specifications all in sync and traced to each other. It’s a formidable problem that is virtually eliminated courtesy of Jama without the hassle of having to learn a clunky UI (IBM DOORS).” Alan M., Chief Product Officer

Jama Connect® created Live Traceability™ management which reduces project development risk by forming a digital thread through siloed development, test, and risk activities. The flexible platform is designed to support the end-to-end product development process with:

  • A simple, single repository so it’s easy for remote teams to gather, review and execute on requirements.
  • Structured reviews and collaboration — teams can elicit feedback, review product features in real-time with stakeholders and track critical decisions across teams and locations.
  • Change management throughout product development — end-to-end traceability and real-time collaboration improve visibility and make it easier to adapt to changes and track their impact.
  • Integrations across the ALM-PLM ecosystem.

Moving from IBM® DOORS® Next to Jama Connect® for Requirements Management

To adapt to shifting and ever-increasing challenges and complexities and keep pace with the competition, innovative organizations are now requiring best-in-class software to scale development, reduce risk, save time, and ensure compliance to quality and safety regulations.

Download this paper to learn how Jama Connect stands out above DOORS Next in the G2 Summer 2021 report for requirements management in the following areas:

  • Overall satisfaction
  • Implementation
  • User adoption
  • ROI

Go live with Jama Connect 2.7x faster than IBM® DOORS Next®


In Conclusion

Products, systems, and software development are only getting more complex and not modernizing your requirements management process will increase the probability of negative outcomes in your product development process.

As your team requires the ability to adapt, innovate, and grow, continuing to use IBM DOORS will become more difficult and will introduce significantly more risk in your product development process. Think about DOORS as a landline rotary phone that stopped being on the receiving end of upgrades after the industry switched to marketing push-button touchtone phones. (And now there are smartphones available, which are mobile and make you even more connected and productive.)

Transitioning to new technology provides your teams with the tools required to innovate, meet deadlines, and succeed. A modern requirements solution can help you to define, manage, and validate complex systems requirements while eliminating the risks and inefficiencies associated with documents and legacy systems.

Hear about the experiences of the more than 50 companies that have made the switch from IBM DOORS to Jama Connect.

Connect with us today to learn how you can enable end-to-end compliance, risk mitigation, and process improvement with our intuitive, award-winning requirements management platform.

To read this series in its entirety, visit this whitepaper: Why Move Away from IBM Doors Legacy and Why Now

 



Impact and change Analysis are two important concepts in requirements management. Understanding how a change made to one requirement, impacts the upstream and downstream relationships is essential in assessing the scope a change may make.  What happens when a change IS made to an upstream requirement, and you are a downstream stakeholder? How will you know and how can you manage this change? This is where suspect notification plays an integral role in informing users of changes to the requirements that they care about. 


RELATED POST: The Essential Guide to Requirements Management


When relationship links are established between requirements, Jama Connect users can utilize the Impact Analysis feature to inform them as to the downstream or upstream impact of changes to a particular requirement. This helps to indicate the scope a particular change may make across the system of linkages. If suspect linking is enabled, and a change is made, users are alerted of these changes through various indicators and views in Jama Connect:  

  • Displayed in the Relationship Indicator column with a red exclamation point icon (which you can hover over to see how the item violates relationship rules.)
  • Displayed in the individual requirement in the “Relationship” view as “Causing Suspect” for each linked requirement that is suspect. 
  • Displayed as a Project-wide view under “Project > Suspect Links” 

If a linked requirement is marked suspect, users can take advantage of Jama Connects’s Compare Versions feature and get a side-by-side visual comparison of the changes between versions of requirements to determine what has changed. This allows them to assess the impact of the change that caused the suspect and make appropriate changes to the linked requirements.  A good example of this is if a set of verification tests are linked downstream to a functional requirement. If a change to the details of the functional requirement is changed, then all downstream verifications will be marked suspect, and the test lead can impact the change and update the tests accordingly. When the changes are complete, the suspect link can be “cleared” (either individually or in bulk). This ability to control and react to change is especially important in meeting regulatory standards, such as DO178C, ISO26262, ISO 13485 (and many others). We cannot assume requirements are static and must have visibility to what changed, and the impact that change will have.   

Suspect linking can be configured in the Jama Connect Org Admin setting, per item type field. This allows for granular flexibility for users to set which field changes will trigger a suspect link. This level of flexibility is extremely important as it allows users to define suspect rules according to their process and what fields are essential to track for change. 

Conclusion: 

Don’t let suspicious requirements scare you! Understand that they are an important part of the requirements change process and are there to help you control and react to updates made to linked requirements.  Let’s face it, requirements change, and getting a clear understanding of when something changes and what changed is essential. 

 



why-move-away-from-IBM-DOORS-now-part-1

Examining the role legacy requirements management solutions, such as IBM DOORS, play in introducing project risk to the product development process.

 


Are Legacy Development Tools Putting Your Development Process at Risk?

The past few decades have ushered in a new way of working and now teams are expected to work more efficiently and collaboratively across the organization and supply chain. Companies building highly regulated and complex products often rely on legacy tools such as IBM® DOORS®, yet as product development methodologies evolve, legacy requirements management tools have not kept pace. Misalignment between what teams need vs. what legacy solutions provide can result in increased risk in the product development process, leading to inefficiencies and lack of visibility that result in missed deadlines, defects, compliance gaps, and rework. Companies that have migrated to a modern solution from IBM DOORS have achieved faster development times, greater efficiencies, and reduced expenses. As you plan your next move, we’ll cover everything you need to consider moving forward, including market challenges, how engineering teams are adapting, and why waiting to make a change will continue to expose you to greater unnecessary risks.

Market Drivers Are Pushing Engineering Teams and Technology to Evolve

WHAT HAS CHANGED?

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 POST: Migrating from IBM DOORS – Why and How Rockwell Automation Made the Switch


Why Organizations Originally Invested in a Requirements Management Tool

Requirements management (RM) has long been accepted by the engineering industry as an essential discipline, no matter which process is used, or which type of system is being produced. Organizations originally invested in a requirements tool such as IBM DOORS to establish a standard requirements management practice and process that allowed teams to align on a single source of truth for requirements. They invested in RM with the goal of:

  • Encouraging and motivating teams to follow common requirements practices. 
  • Establishing a single source of truth for requirements to ensure teams were working off the same information. 
  • Creating minimal disruption to the business with an off-the-shelf solution that allowed teams to focus on their core business. 
  • Integrating RM into core workflows and business without impacting how people work. 
  • Tracking the life of a requirement through development, test, and release.

We had this idea that a complete redesign of the requirements process and technology would be a game-changer — reducing the time it took for us to implement solutions for our clients and making it easier for clients to review and collaborate year-round. From the outset, we said that we’re not going to be throwing documents at our clients to mark up with their edits — there was a better way to do this.” Elizabeth Rosenberg – Alight Solutions

The Drawbacks Organizations Have Found with IBM DOORS

You may currently be using a solution which was implemented with all the intentions of producing positive business outcomes. But over time, the market has changed and, as a result, your organization’s needs have changed.

If you feel like you’ve outgrown your requirements management software, you aren’t alone. Complex systems such as IBM DOORS have inherent drawbacks and have also had trouble keeping up with the innovation occurring in highly regulated industries. Continuing to use a solution that your organization has outgrown comes with a variety of challenges, including:

A cumbersome user experience. DOORS has a complex and challenging architecture and an outdated user interface. Existing users are losing the motivation to continue to use DOORS while new users are reluctant or refuse to learn.

A system lacking robust collaboration abilities and a single source of truth for requirements. With stakeholders reluctant to work within DOORS, “librarians” must enter information into the system to keep everything up to date, while the real collaboration happens outside of DOORS in emails or conversations. As a result, organizations lack the ability to perform robust reviews or examine the audit trail for requirements evolution. Additionally, teams using DOORS often must retain dedicated staff, a cost that is unnecessary in today’s competitive market where teams are being tasked with doing more with less.

Risk is introduced due to aging technologies. DOORS 9.6 is already outside of its original support window, which raises questions about how long DOORS will continue. Inevitably, IBM will at some point discontinue support for the DOORS legacy platform, and that leaves customers in a high-risk situation trying to protect their intellectual property. Additionally, a cloud option is not available, which creates challenges with remote working.

A high cost of ownership and reliance on customization. Organizations need to focus on their core business and using a bespoken RM tool interferes with that goal. Companies often struggle to achieve the benefits promised by DOORS without complex customization, and those customizations don’t transfer to IBM DOORS Next.

For example, if a company makes cars, then their core business is to focus on cars. If, instead, they need to spend a lot of time writing customizations for a requirements tool then the focus is on creating a requirements tool and not on cars. The time spent on the creation of customizations is a detriment, moving their focus away from core business. Many customizations are also decades old, and it’s increasingly challenging to recruit or replace staff with DXL skills, once again adding risk to an organization.

Stagnant infrastructure doesn’t support change. At rest, DOORS is working and has a low IT man-power cost of ownership. Changes are constantly happening and ignoring them creates additional risk. Users oftentimes refuse to use DOORs and wind up working in Word/Excel and collaboration is done in meetings and emails leaving decisions and details lost outside of DOORs. As the IT industry faces more demanding regulations, supporting the DOORS architecture is growing increasingly difficult.

Lack of vertical frameworks to support compliance. As industries establish increased regulatory and compliance rules, new and updated industry engineering frameworks have been created (e.g., DO178 A, B & C). Legacy requirements tools made early attempts at providing engineering frameworks, but these have not kept up with industry changes and are now mostly left to users to create for themselves.

Risks and Costs Associated with Staying with IBM DOORS

Tools that are difficult or frustrating to use and require experts to operate will not only slow down development but will also breed resistance and hinder adoption. This creates fragmented processes that introduce unnecessary risks for organizations that must stay current with compliance regulations while developing integrated, complex products that sustain business and maintain market relevance.

The unintended consequences of a fragmented development process are critical functions such as requirements traceability, verification, validation, risk mitigation, product integration, and compliance can be fraught with information gaps, defects, delays, rework, recalls, missed requirements, and significant manual effort. In the complex product, systems, and software delivery lifecycle, organizations can experience negative outcomes such as: 

  • Performance: Product fails to perform specified functions. 
  • Quality: Product defects are discovered by customers post-launch. 
  • Delays: Product release deadlines are missed, or costs are overrun. 
  • Fit to requirements: Product fails to meet the needs of customers. 
  • Compliance gaps: Gaps identified late and require extreme cost to rework and fix. 
  • Regulatory action: Product is not approved for launch or recalled post-launch.

RELATED POST: Is There Life After DOORS? The High Cost of Poor Management Requirements


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

Leaders might already understand the need to switch from IBM DOORS, but they aren’t sure of the next best step. Some lean toward switching to IBM DOORS Next 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 to 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 force 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.

This blog is Part I – Part II is available here – of a series covering this whitepaper:  Why Move Away from IBM Doors Legacy and Why Now