Legacy Software Archives

Tag Archive for: Legacy Software

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

Current market dynamics include disruptors that put innovation at the heart of your product development process. Organizations must be able to navigate these disruptions to remain competitive and sustain business growth.

Why organizations move away from legacy tools, the benefits of making the switch, and how to successfully migrate.

Requirements management (RM) tools started to evolve more than 25 years ago when it became clear that document-based tools such as Microsoft Office did not offer capabilities able to manage and analyze requirements traceability. Early requirements tools included QSS DOORS® (now IBM), Rational Requisite Pro (end of life), Borland Calibre RM (now Microfocus), and a couple of others. Legacy requirements solutions may have handled managing requirements in the past but are failing to keep pace over time due to increasing engineering complexity and the need for modern software to be far easier to use.

We will explore topics relevant to legacy requirements management tools, why organizations elect to move away from them, what benefits are realized after making the switch, and how to successfully migrate. We’ll also touch on how to navigate the data migration path from a legacy system to a new platform, and how innovation is realized in product development lifecycles with a modern requirements management solution.

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.

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.

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

As a modern alternative to traditional legacy platforms like IBM DOORS®, Jama Connect® enables digital transformation with a more efficient and user-friendly approach to managing risk and compliance. And although the benefits are innumerable, some organizations hesitate to migrate to a modern platform because they believe it’s a painful, slow process.

In our recent webinar, attendees heard directly from one of our customers, Rockwell Automation, about why they decided to migrate from IBM DOORS and how they were able to successfully move to Jama Connect.

In this session, the Rockwell Automation team answered the following questions, and more:

Why was now the right time to switch tools?
How easy was it to switch environments while preserving IP?
How did the Jama Software team assist you in making the migration process as smooth as possible?
What are the drivers for continued and expanded use of Jama Connect?
What are the key benefits you have realized since the migration?

Below you’ll find a recording of the webinar and an abbreviated transcript.

Sheila King:

Sheila King: Rockwell Automation has some business units that have functional safety products with the 61508. And although it’s not widely used Rockwell teams have solved their traceability and requirements management at the business unit level using Classic DOORS. Other teams were using homegrown requirements tools and traceabilities including Doxygen and yet other teams were using Word documents and Excel spreadsheets and doing the manual brute force way of doing traceability in requirements.

Sheila King: But then when the security landscape changed and we realized the vulnerabilities of industrial automation, the 62443 cybersecurity specification was invented and we decided that we needed to use it. Qw needed a site certification and in the process we adopted the IBM CLM product with the DOORS Next, RTC for planning, and RQM for test management.

Richard Watson: What led you to consider making a switch away from the tools that you were using and why was that change needed?

Sheila King: Well, we were already in the throws of adopting the CLM D and D tools and developing our product life cycles in order to meet the 62443 certification. And we decided in that process that we really needed to up our game. We needed better tools for planning tools, for our test integration and continuous integration and delivery and we needed better tools for requirements management that included the ability to move data widely between products because that’s real life. And in the current tools, the DOORS Next tools we needed to use the ReqIF which was really an administrative thing as opposed to people being able to move their own data.

Sheila King: We also had the solution for DNG and RQM and RTC and we hired a third party, or we contracted a third party vendor to manage that and we decided we needed a better integration for that for our vendor. We also, for the tools themselves, we needed variant and configuration management and native real-time traceability.

Richard Watson: Can we spend a few minutes looking at the primary considerations you have for selecting Jama Connect as opposed to DOORS Next Generation?

Sheila King: We actually created a grassroots working group to evaluate tools and we evaluated several. Our top two were of course, Jama Connect and Helix, the tiebreakers where these. Jama Connect had functional safety-ready certification, and anybody who goes through functional safety knows how much value that is for your audit. We needed a strong review center and Jama Connect has that. We needed baselines in order to be able to not have to use SAP for saving our documents. We like the rational database and the ability to configure different item types.

Sheila King: We not only use Jama Connect for our requirements but we use it for our threat models and our fault models. And we also like a lot the structure, the permission structure that allows you to specify all the way down to requirement if you need to how you’re going to protect your data in the tools, and with our fault and models are designed for security and threat models, that is our business risk or business restricted setting.

Richard Watson: Thank you. We know that the value of an organization’s environment is their data. You spend a lot of money buying tools and maintaining tools but the real value is the data that you have inside the tools. Can you share some of the concerns Rockwell had going into migration?

Sheila King: Yeah. First of all, we were going to having all our data in the cloud. And so we had our CISO team get involved in that and they did an evaluation because not only were we now putting requirements in the cloud, we were putting our source in the cloud. We were putting our planning, our tests in the clouds, our anomalies in the cloud, some kind of scary stuff to have in a cloud, and so we had a CISO audit and they decided that it was very safe to do that. Secondly, when it comes to actually keeping our data safe, the truth is we asked Jama Software to explain to us how they were going to keep it safe and they convinced us that they could and so they’ll tell you that they kept our data safe.

Richard Watson: Maybe that’s a good transition to the next question. This is just a discussion around were there any specific steps you took to protect your data and IP?

Sheila King: Yeah. Because we had such a short window for moving all the content over, we made backups as it was in our current tools and then moved them into the tools and we use the ReqIFs, the collections and all that stuff from DNG and just about every other way you can export data out of that and backed it all up. And then once we moved it into Jama Connect, actually just handed it over to the Jama Software team, Alisa and the Jama Software team, and they imported it and then we migrated the data once we had it inside.

Richard Watson: Maybe we can bring Alisa into this as well. And so can you and Alisa share some of the details around the migration approach?

Sheila King: Just as I mentioned we had six months to do it, so we had three phases that we started with. We worked with our stakeholders to identify all the content to be migrated and then we again had the extremely tight window. We elected, like I mentioned, to adopt to bring it over into Jama Connect as is. So we had everything brought in in the format that it was in DNG and then Alisa was on site within a week of our purchase to help us with the migration.

Alisa Eikanas: I remember that I arrived in Ohio on April 1st and I remember hoping that it wasn’t a bad omen, which of course it wasn’t, this wound up being one of the most rewarding and enjoyable projects I’ve ever had the pleasure of supporting. The sign that’s being presented now basically illustrates the standard migration approach utilized by the solutions team here at Jama. Every migration is going to have unique elements, needs, but in the case of Rockwell’s migration this template married very well, as Sheila is taking care of the planning and we transitioned seamlessly into analysis and discovery.

Alisa Eikanas: During the discovery and proof of concept stages we did come across a few issues that required some customized tool development, but once we had validated the integration tools and approach the execution of the final stages was a fairly straightforward process. Sheila was generating all of the extracts from the legacy systems. She would transfer those files to me and then I would load them into Jama.

Alisa Eikanas: And as Sheila said, in some cases we go through a cleaning of the data prior to migration but again given the short window we elected just to bring all of the data from DNG, which in some cases we had some modules that had over 170 attributes. But again with a short timeframe we just elected to bring everything in as is and clean it up afterwards because at the end of our migration window Rockwell was losing to their DOORS instance, so really for us a critical item was making sure that we got done on time.

Richard Watson: That sounds pretty comprehensive. Sheila, now that you’re at the other end, how would you rate your experience around migration and user satisfaction?

Sheila King: Well, the team was just great to work with. Again, Alisa, she just worked really hard to integrate and migrate our data. Anytime we ran into an issue we would tell the software group and they’d come in and they would write some code to add to their data exchange to manage the data that was coming out of the tools and it just worked really very well. And she worked with our team, like she mentioned, the classic DOORS group had 100 and I can’t remember seven fields and we were able to talk them down into just, I think it’s 10 now. Is that right, Alisa?

Alisa Eikanas: Yes, it is. Yeah, from 170 to 10.

Richard Watson: Wow. Is there any advice for teams hesitating making a similar move due to migration concerns?

Sheila King: No. I think it’s the water is warm, just hop in. And let me add to this, because we’ve been giving teams the ability to decide when they switch over to the tools, find a perfect time or find a space between projects and stuff like that. And the truth is there’s never a good space to migrate. And so we’re actually encouraging people to just go ahead and start because they will see efficiencies right away. And so it’s not just to get involved and to find a good spot because you won’t but you will find efficiencies right away.

I was the IBM® DOORS® Product Manager for nearly 20 years and the roller coaster journey was fun. I started by managing the creation of an integration between DOORS and Mercury TestDirector and eventually picked up the DOORS family, working with Telelogic and then on to the acquisition by IBM.

How did DOORS become a market leader?

“If Bill Gates can have Windows, I want to have DOORS. Now tell me, what does DOORS mean?”

Initially created by QSS and then Telelogic, DOORS was the market leading requirements tool in the 1990s and into the 2000s. Industry analysts moved focus to application lifecycle management (ALM) solutions in the 2010s and it was difficult for any vendor to claim a defined market share, let alone market leadership.

Three decades ago, it was possible to persuade prime contractors to mandate use of a single tool across their entire supply chain. With early success in the UK defense industry, DOORS became the market leading requirements tool; in the early 90s there was only two tools to choose between. Rational® entered the requirements business in 1998 and held 2nd place in the market.

The acquisition of Rational and then Telelogic into IBM saturated the requirements market from a single vendor, spread over four different requirements solutions: DOORS, Requirements Composer, Requisite Pro, and Rational® DOORS® Next Generation. Only two now survive to make up the DOORS family.

Where are we today with requirements management solutions?

Working styles have changed dramatically since the 90’s and teams are being asked to move fast and work collaboratively with teams across the organization. In order to satisfy this new way of working, requirements management vendors needed to adapt and invest in the interface and useability of their products.

Users are demanding ease of use so more people can enter information directly into a tool rather than sending Word or Excel documents to a tool user for import.

The industry has changed. It’s no longer possible for an OEM (Original Equipment Manufacturer) to mandate a single product or vendor across supply chains and in fact, standards such as ReqIF (exchange) and OSLC (integration) have come about to help products work better together. Again, this requires investment from the vendors so that interoperation does not sit just within a single tool chain.

What’s next after DOORS?

Requirements management has been accepted by the engineering industry as an essential discipline, no matter which process is used, or which type of system is being produced. What changes is the level of formality adopted (process), or regulation needed to be complied with (industry standard).

Best practices for systems engineering have been prescribed in many industries. It’s not just about DO178 or ISO 9001, we now see engineering regulation or compliance needs in automotive, medical, finance, and many other industries.

It is no longer possible for a single product or vendor to drown a marketplace. We have different users wishing to make their own decisions about which best of breed solutions are right for their organization. One tool will not fit all user’s needs. An organizations investment in their data is far more than the investment they make in tools, and the focus now comes down to availability of data and how that flows across an engineering community (integration) and the value chain (exchange). Don’t forget, it’s your data – not the vendor’s!

In summary

I have seen that there is life after being the Product Manager for DOORS and have chosen to work with a vendor (Jama Software) that has a single focus on engineering, reinvesting revenues into their products and therefore, investing in their users. Let’s see where this next roller coaster takes me. One thing I know for certain, there’s more fun ahead!

Why should you consider changing out your documents-based workflows for real-time collaboration tools? As product development processes become more complex, traditional document-based requirements management is showing its age and limitations.

Document-based requirements management (RM) is still widely used in highly regulated industries like healthcare, automotive, industrial manufacturing, aerospace and defense. As these industries progressively shift toward increasingly complicated products and systems, they must fulfill numerous software and hardware requirements before safely reaching market.

But many organizations haven’t upgraded their requirements and risk management tools and processes to keep pace with this innovation, putting themselves at risk of protracted development cycles, costly late-stage changes, and regulatory recalls.

Solving the Challenge of Document-Based Requirements Management (RM)

More specifically, outdated document-based requirements management workflows centered on Microsoft Word and Excel are too fragmented for efficient product development. Multiple conflicting versions of requirements documents may be in play at any time, while stakeholders struggle to consistently connect on feedback and conduct timely reviews and approvals.

According to IT research firm Gartner, only 55% of product launches happen on time, with product development issues such as missed bugs and feature creep being major causes of setbacks. Fortunately, better collaboration is possible with solutions that enable real-time interactions, shorter review cycles, and a consolidated system of record.

Let’s explore some of the challenges with document-based requirements management solutions in particular, and how to overcome them through a more modern approach.

What You Miss Out on With Document-Based Workflows

At a high level, document-based requirements management – i.e., RM that involves authoring requirements, traceability and risk matrices, and other items, all managed within discrete files such as Word documents and Excel sheets – isn’t scalable to the demands of modern product development. A single requirements document can be hundreds of pages long, or (if a spreadsheet) have an overwhelming number of rows. Plus, it will inevitably change throughout the product lifecycle.

When the unwieldiness of these documents meets the complexity of continually gathering, authoring, testing, and tracing requirements, the result is often something like the following:

Person A emails a requirements document to their entire team.
Persons B, C, and D each update it with their own feedback.
Those various updates get re-distributed among the team for another look.
Person A tracks the changes in Word and tries to manually maintain an agreed-upon version of the truth
The entire team participates in lengthy meetings to align on the final version or changes
Ongoing rework, within that complicated and detailed document, is required to keep everything up to date.

This highly manual type of collaboration can consume many hours. Ultimately, the product team ends up managing documents more so than the actual requirements within them, which leads to miscommunications and delays, on top of wasted time.

Beyond the time-related workflow issues outlined in the above hypothetical, channeling all RM through individual documents creates additional problems. With document-based RM solutions, teams miss out on the convenient collaboration and standardized, consolidated processes available with modern RM tools. Accordingly, they’re left with problems including greater difficulty in implementing and adhering to industry standards, inability to efficiently manage change, crucial feedback not making it through cross-functional and distributed teams, and often costly rework leading to slower time to market,

Standards Adherence

Product development has become much more complicated over time. As a result, so has product risk—and the accompanying regulatory compliance required.

When teams build products and systems that must meet functional safety and compliance standards during development (such as ISO 26262, IEC 61508, Automotive SPICE, CMMI, ISO 14971, and more), they introduce risk into the development process when they take a document-based approach to RM. Without an easily accessible source for RM information, teams are essentially starting from scratch each time, with no built-in mechanisms (e.g., industry-specific templates or reuse functionality) for baselining or aligning the work of cross-functional teams around the necessary standards.

Traceability of Requirements

Given that document-based requirements are often very lengthy and increasingly complex, and the workflows for updating and circulating them are inefficient, it is easy to see how risks can be overlooked during product development. To go back to our hypothetical example, it’s possible that Person A sends out a revised version of their document that integrates feedback from Person B and C, but not Person D. That oversight could result in missing test coverage or a critical defect being identified too late. Moreover, tests would become tougher to trace back to requirements, in part because there’s uncertainty about whether all risks have been accurately captured at any point in time. Additionally, when Person A needs change a requirement, it is difficult to accurately assess the impact of that change (i.e. perform impact analysis) to understand what other requirements or tests may be impacted.

Cross-Functional Team Collaboration

Although many team members from different departments are involved in product development, coordinating all of them is nearly impossible without the right requirements management platform. Lengthy cross-functional team meetings are often held for the sole purpose of updating just a few contributors on recent changes made to a key RM document. With people often being out of the loop on changes in disparate documents, last-minute adjustments become problematic, as do reviews and approvals requiring input from specific individuals. All of these issues lead to late stage changes and rework that ultimately lead to product delays.

Real-Time Collaboration as a Replacement for Document-Based Requirements Management

To successfully move on from document-based processes, a particular type of RM solution is needed – one that can:

Enable real-time collaboration with full context and conversations around requirements, risks and tests.
Simplify the process for pulling in contributors and connecting them in real time.
Provide out-of-the-box templates for adherence to industry standards from the start.
Offer a single system of record for requirements, risks, and tests.
Support risk analysis throughout the development process
Easily export reports for proving compliance and passing audits.

In Jama Connect, real-time collaboration in one convenient place replaces the fragmented workflows spread across multiple documents and communication channels. Rather than emailing collaborators with new changes and requests or leaving them comments in Word or Google Docs that could easily be missed, contributors can manage requirements and risks in real time in the same system, providing a single source of truth.

To see the difference, consider how risk impact analysis changes when using a modern RM platform. Items downstream from modified requirement get automatically flagged as “suspect,” and specific individuals can be quickly notified and given context on what action is required. Once they make updates in Jama Connect, their inputs are automatically saved and can be viewed by others with the confidence that the data is the latest available. This process is much more straightforward than playing email tag or reconciling static documents.

Watch this recent webinar to learn more about moving away from document-based design control and risk management and how a modern platform can improve team collaboration and streamline processes.

WATCH NOW

Do you know the most common product development challenges engineers face? In this post, we have identified them and provided solutions that enable a more modern and efficient product development process.

An ideal product development process requires close collaboration between teams, up-to-date knowledge of applicable regulations, and efficient requirements management platforms for defining, verifying, and validating requirements. However, not every manager is convinced that his or her team needs to do a better job on requirements development and management, or that such an investment will pay off—despite numerous industry studies which indicate that requirements issues are a pervasive cause of project distress.

With the growing complexity of products and software, the more complicated the process required to build it becomes—and the accompanying increased risk of flaws which can lead to expensive, and potentially reputation-harming recalls.

These new complexities have raised the stakes—and made the case—for the need to optimize the product development process from end to end. Engineering and design teams need solutions to the most common product development challenges that provide purposeful, structured collaboration; connect globally distributed team members; and accurately capture and facilitate feedback, decision making, and context for requirements under review.

Doing so requires first overcoming some significant obstacles. To help navigate the journey toward better product development, let’s examine ten of the most prominent product development challenges engineers face and their corresponding solutions.

1. Move on from outdated legacy or document-based solutions

The Product Development Challenge: The traditional approach to managing risks and requirements is highly manual. Teams that operate with a documents-based approach, exchange numerous spreadsheets, and versioned documents via email. This method has real drawbacks:

No single source of truth: A spreadsheet with a project’s traceability matrices could have many cells, but no guarantee its data was authoritative or even up to date. Different versions might be floating around, requiring any changes to be painstakingly manually coordinated to achieve team-wide alignment.
Limited collaboration: Sending complex requirements documents over email leads to important updates getting lost in people’s inboxes and projects being delayed. As remote teams become more common, such issues are even trickier to manage.
Excessive rework: Without effective change management—which is very hard for teams who rely on static, emailed requirements documents—teams often end up developing (or testing) off of older versions of requirements which inevitably leads to misalignment and costly rework.

The Solution: Jama Connect™ provides the single source of truth absent from document-based solutions. Teams from anywhere can collaborate in real-time on a unified platform and capture accurate feedback, review progress, and conduct approvals. That leads to earlier identification and control of risks, which helps reduce rework and keep projects on schedule and under budget.

2. Simplify compliance and meet regulations or standards

The Product Development Challenge: Product development has become much more complicated over time. As a result, so has product risk—and the accompanying regulatory compliance required.

A Jama Software-sponsored survey on Engineering.com found that 62% of respondents reported being reprimanded by regulatory agencies for product development issues. More broadly, recalls have been increasing in certain industries, with medical device recalls more than doubling year-over-year in Q1 2018, due primarily to software-related defects.

The Solution: To address these product development challenges, Jama Connect is engineered to ensure quality with frameworks aligned to key industry standards that streamline design, development, and risk management while maintaining compliance.

Jama Connect helps customers in industries like medical device, aerospace, and automotive solve this product development challenge by streamlining their quality and risk management processes with defined processes for development and production and detailed traceability—from the high-level user needs and systems requirements through to validation and verification. Teams can streamline their product development with templates aligned with industry standards, compliant reviews and approvals, and end-to-end traceability making audit preparation and record-keeping a straightforward process.

3. Establish and implement effective review cycles

The Product Development Challenge: Without the right platform and processes in place, review cycles can be time-consuming and fragmented. For example, under the manual approach to requirements management described earlier, a review cycle can be repeatedly delayed due to versioning issues with documents and lack of visibility throughout the review process. Teams can also spend hours per week in review meetings, just to ensure everyone is on the same page.

Streamlined review cycles require:

One source of truth for requirements and tests
A straightforward way to send items like requirements, user stories, or test cases for review
Best practices for each of the major roles involved (i.e., reviewer, approver, moderator)
Real-time collaboration within a shared, dynamic requirements management platform
A formal approval process to capture and record sign-off

The Solution: Jama Connect Review Center can solve this product development challenge by serving as the single place for reviewers, approvers, and moderators to collect and manage all requirements and feedback for a project in real-time.

Inviting internal and external collaborators into a review cycle is easy, plus roles can be assigned and all agreed-upon requirements approved much more quickly than with manual processes. Pharmaceutical manufacturer Grifols reduced its planning time by 80% by using Jama Connect to accelerate review cycles.

4. Enable secure, cross-functional collaboration across teams, customers, and complex supply chains

The Product Development Challenge: People working together is at the very core of all product development work. The ability to effectively collaborate is critical for innovation. In this era of rapidly accelerating change, structured and strategic team collaboration is the key to improving the product development process for all team members. And in this era, the “team” includes everyone across the supply chain.

Today’s market demands require companies to build partnerships and seek solutions with more specialized materials. These partnerships mean greater sharing of data across distributed teams, partner organizations, and business units, sending a ripple effect through the supply chain as subsystem suppliers must anticipate features on the finished products and get ahead of release schedules and component costs.

But for engineers who are used to working on internal, siloed teams, these new partnerships present previously unforeseen challenges. What worked before doesn’t work today.

Aligned requirements management is necessary for developing products that meet all customer and market requirements while adhering to industry regulations and standards. More specifically, optimized gathering and authoring of requirements are needed to ensure product quality and meet specific requirements, minimize risks, accurately scope projects, enable collaboration, and align teams.

The Solution: Requirements gathering should follow a systematic process, focused on what eventual end users will do and the requirements that must be met to support those behaviors. This approach ensures that both high- and low-level requirements and their dependencies are covered and that corresponding tests can be set up and run.

As teams seek input and feedback on product and systems requirements, tools like Jama Connect are critical in capturing these insights in real-time. With everyone having access to the most up-to-date information, stakeholders can stay informed and aligned, reviews can be streamlined, and teams have better visibility into the progress of their work. This helps reduce the complexities of communication and saves time by having a single source of information regardless of geographic or institutional location, which enables collaboration across a variety of relationships. Having a single platform where these teams can come together to review and connect will keep programs on track, keep teams collaborating, not let insights slip through cracks, and allow for innovation.

Engineers typically collaborate with outside companies by exchanging requirements. Data Exchange for Jama Connect enables the transfer of requirements and associated metadata between customers and suppliers. The solution allows for the import, export, and update of requirements data to create an ongoing exchange throughout the product development lifecycle, allowing for collaboration to extend to remote engineering teams and companies.

RBC Medical saved an average of $150,000 per project by upgrading to Jama Connect eliminating the back-and-forth email tag that characterized its previously manual processes.

5. Ensure product quality and improve change management with complete traceability

The Product Development Challenge: Maintaining cross-team visibility and staying on top of disparate documentation and processes along the way is a central challenge of working with manual, document-based workflows. It becomes difficult to accurately assess the impact of a proposed change (i.e., perform impact analysis) and to ultimately ensure requirements are properly tracked across the entire product development lifecycle.

The Solution: To make impact analysis more scalable, teams need end-to-end traceability. In Jama Connect, links that are downstream from modified items get automatically flagged as “suspect,” and relevant contributors can be notified right away to take corrective action. Modern traceability software maps out the relationships and interdependencies in product development, allowing for assiduous tracking of risks and requirements in their full historical context.

Important data, such as the percent of downstream test cases that have passed and where coverage may be missing, is also easy to view, while the system’s requirements can be updated in a centralized place as the project progresses.

The right requirements management technology can provide clear traceability that allows teams to maintain a rigorous formal change management process; reveals interdependencies with the process; and enables alignment, making it easier to bring in the right decision-makers at the right time. This level of traceability, with visibility into who made each change and for what reasons, has become especially important as products and systems become more complex and software-driven.

The result is improved confidence that teams are working with the right requirements, have the information they need to conduct useful impact analysis and are generally able to trace forward from, and back to, requirements as needed.

6. Manage development complexities across hardware and software teams

The Product Development Challenge: Software is an ingrained part of modern product development and one that can greatly increase risk if not properly managed. Moreover, complex software requirements have to be managed in tandem with those for hardware. The growing connectivity embedded into today’s ever more complex and often safety-critical products, puts pressure on both software and hardware teams to manage their development processes with more efficiency and effectivity. In fact, in a recent study from Engineering.com, over the last five years, 76% of respondents reported dealing with three or more increased measures of complexity and 25% saw their products become more complex in five or more ways.

The Solution: In a platform like Jama Connect, risks and requirements related to software and hardware can be managed proactively, not reactively. Teams can quickly see the full historical context around a requirement when they receive invitations to contribute to a project. Out-of-the-box frameworks that include industry-specific, software development methodology and risk management also minimize setup time, so that important risks in software and hardware can be identified, assessed, and acted upon as early as possible.

Configurable workflows accommodate various process styles, development methods, and tools to ensure adoption, with flexibility to support your Agile, Scaled Agile or Hybrid development process. Requirements data can be integrated with other tools across the development process to ensure everyone stays aligned.

One of the most common scenarios is integration of requirements to Atlassian Jira. With the Jama Connect for Jira integration, product teams can maintain critical information about their product requirements and test cases and directly connect them to development activities in Atlassian Jira, including sprint planning, task management, estimations, and defect and issue tracking.

7. Increase quality and efficiency by testing earlier in the lifecycle

The Product Development Challenge: It’s well understood that identifying potential defects earlier in the lifecycle prevents costly rework. But how can organizations proactively involve QA at the front end of the process?

The Solution: Early testing prevents defects from surviving until the late stages of the lifecycle, when they become especially costly to fix. In addition, early and frequent testing allows for innovation.

The National Institute of Standards and Technology has estimated that the relative cost of fixing a software bug is 30 times higher in production than in the requirements and architecture stage of development.

Conducting some form of testing, at every stage of the product development lifecycle, is highly recommended. Getting the right feedback at the right time ensures that you can deliver a high-quality product on time.

In the early stages of development, performing customer exploratory testing is the most cost-effective way to make sure your product strategy is on the mark. And, at the end of the development lifecycle, conduct system integration tests to ensure components are working harmoniously.

Jama Connects helps engineering and quality assurance teams define, organize, and execute requirements-based test plans and test cases to ensure quality and compliance. Teams can streamline reviews and approvals, perform manual testing, and integrate with trusted test execution and automation solutions.

8. Implement effective requirements versioning, baselining, and change management

The Product Development Challenge: Legacy requirements management systems frequently complicate version control, due to the prevalence of conflicting requirements documents that are manually managed, often owned by varied teams and then distributed cross-functionally. Likewise, they don’t provide the right infrastructure for effective change management, because of the difficulty involved in identifying the latest versions and applying any needed changes amid all of the different documentation in question. Changes might ultimately be made only at a late stage, and at great cost.

The Solution: A requirements management platform like Jama Connect can solve this product development challenge by allowing teams to align their releases to ensure they deliver a cohesive solution/product to their customers. With versioning, baselining, and change management of the requirements in place, teams are able to manage and reuse requirements throughout the development lifecycle. This allows development teams to improve reuse, reduce design inconsistencies, and reduce the discrepancies found during testing, verification, and validation.

Jama Connect offers full control over the requirements you are choosing to reuse. You can not only choose the set of requirements you want to reuse but also the version of those requirements as well. This allows you to take the best and most applicable version of your requirements forward to your next project.

Studies reveal that 60 to 80 percent of requirements, code, and tests are shared between projects. With Jama Connect, you can reuse your data for effective sequential or parallel product development which saves your development teams time and improves time-to-market.

9. Make it easier to coordinate remote engineering teams

The Product Development Challenge: Remote work is on the rise. Although it has many benefits in team flexibility and cost savings for the organization as a whole, it can complicate collaboration and result in additional operational silos as each remote engineer settles into their own workflow and preferred set of tools.

The Solution: Modern platforms that enable real-time, structured collaboration simulate the efficiency of engineering teams working together in a shared physical workspace. For example, engineers can be easily invited into Jama Connect conversations and reviews, notify each other with custom messages and supporting context, and be assured that they’re always working with the latest information.

Such a setup solves this product development challenge by reducing silos and keeping everyone aligned. Buffer’s State of Remote Work survey for 2020 found that communication and collaboration were among the most cited challenges with telecommuting. Teams that still operate in silos with legacy systems will not be equipped to meet the demands of the market going forward. In this era of rapidly accelerating change, structured and strategic team collaboration is one of the best ways to address the product development challenges and obstacles of the modern product development landscape.

10. Build a more effective and efficient product development process

The Product Development Challenge: Product development is complex and, in most cases, will span multiple teams, solutions, and methodologies. Outdated legacy tools and a documents-based approach aren’t enough for this reality, as they aren’t purpose-built for complicated requirements management.

The often-quoted CHAOS Reports from The Standish Group indicate that three of the biggest contributors to projects that fail or are “challenged” are:

Lack of user input
Incomplete requirements and specifications
Changing requirements and specifications

The Solution: An evolutionary leap forward comes from modernizing requirements definitions as well as engineering and management processes—including minimizing the time your team members spend eliciting, analyzing, documenting, validating, and managing the requirements for their products.

Do you have product development challenges you need to solve?

Jama Connect is a solution for managing complex product requirements from idea through development, launch, and iteration. It brings people and data together in one place, providing visibility and actionable insights into the product development lifecycle. Our platform equips teams to track decisions and ensure the quality of the product they set out to build.

We’d love to speak with you and share how Jama Connect can help your teams find solutions to your unique product development challenges and overcome these 10 common ones. Connect with us today and get started with a better approach to managing requirements in product development.

To learn more about optimizing engineer team collaboration to streamline product development, download our eBook now!

DOWNLOAD NOW

Editor’s Note: This post about moving beyond legacy systems for requirements management was originally published here on DevOps.com May 12, 2020, and was written by Josh Turpin, Chief Product Officer at Jama Software. We’re always proud to share great thought leadership and this informative post from one of our own is no exception!

Getting Past Legacy Software Pains in Requirements Management

If you feel like you have outgrown your requirements management (RM) software, you are far from alone. From complex systems, such as IBM Doors, to document-based tracking through Microsoft Office, legacy RM tools are having a hard time catching up to the innovation occurring in highly-regulated industries. As we see the line between hardware and software become increasingly blurred, development methodologies are evolving faster than ever before. Sometimes, these changes happen day-to-day or even hour-to-hour, making project traceability feel impossible.

No matter how complex the software or notable the reputation, RM providers don’t always deliver a system that matches the goals of teams that need to quickly adapt, innovate, and grow. This misalignment can create several pain points that interfere with productivity. While some can be attributed to shifts in the marketplace, others are directly rooted in the software tools you are using to meet compliance.

Here are some common snafus and how to work your way out of them.

Multiple Stakeholders, Multiple Problems

From avionics to automotive to Medtech, highly-regulated industries see many different stakeholders and players, and that is a good thing. In order to reach peak public and functional safety, it’s crucial to value the input of multiple roles and skillsets. But, what happens if one or some of these folks don’t know how to use your RM software? At best it’s a shame that they can provide their two cents and at worst this begins a recipe for compliance disaster. To sidestep this conundrum, opt for software that seamlessly flows with multiple roles. More so, make sure whatever software you choose integrates user-friendly traceability. It’s crucial that each and every individual on the project be able to see the progress made from beginning to end.

So, You Missed a Deadline…

It happens to the best of us. You were asked to provide feedback on a requirement and you missed your shot to chime in. Whether a colleague left a comment for you in a Word or Google Doc or shot over an email to glean your opinion, the mode of collaboration you have in place failed you. That’s right, this isn’t all your fault. Review processes are too complex these days and they require collaboration software that sets the intentions of the users clearly. This requires real-time editing and notifications to help keep you and your team on track. To prevent falling into this trap, look for an RM tool that prompts the next steps, and sends timely notifications with clear instructions. Conversations about “who dropped the ball” aren’t productive or fair, the RM software you integrate should fill this gap in human error.

You’ve Been Blocked

You are frantically trying to enter crucial data into the system but you are somehow locked out. You can’t get a hold of the person who manages access and you are beginning to feel frantic. This isn’t just frustrating for you, it also poses some substantial risks to the company. On top of losing a couple of hours trying to break into the system, this clunky process inevitably chips away at the desire to provide feedback with any regularity or confidence. This goes against the entire purpose of collecting data in the first place. To facilitate continuous growth and data collection, your RM tool should be open, accessible, and intuitive. Only then will you encourage the kind of constant input and collaboration from stakeholders that is necessary to keep up with breakneck innovation.

When an Upgrade Spells Doom

Back in the day, we all used to get skittish when an iPhone software upgrade notification popped up on our screen. Will I lose all my photos and contacts? What about all those passwords I saved to log-in to my favorite apps? With the advent of the Cloud, much of this fear has dissipated. When it comes to your RM software, your team shouldn’t be afraid to upgrade the system to fix issues, improve security, and access the latest features.

Yet, these systems are often so customized or patched-together that an upgrade could mean disaster. Because the products you are building change and improve over time, you should have an RM system that can adapt quickly. When it’s time to purchase legacy software, weigh the opportunity costs of investing in something so stale. Ultimately, is the pain of being locked-out or unsupported on various platforms worth the headache?

Pain points aside, we are living in an age that has bred the most disruptive and creative products to date. From ultra-fast and sleek electric cars to life-like prosthetics to self-piloted spaceships, we have some of the best and brightest minds toiling away on how to propel us into the future. At the same time, the regulatory environment has become even more stringent to meet both the demands of the marketplace and public safety. It is going to take synced and streamlined teams to decrease time-to-market and meet the ever-increasing demands of compliance. To pull this off, you need collaboration infrastructure in place that keeps your team organized and catches mistakes often missed by disconnected individuals.

If you’re interested in learning more about requirements management, we’ve compiled some great resources for you here.

LEARN MORE

This post on scalable migration solutions is part of a series. You can find Part II on legacy software pains here, Part III on enabling innovation here, Part IV on the difficulties of compliance here, and Part V on moving from DOORS to Jama Connect here.

Over the last couple months, we’ve been detailing the harsh realities of using a legacy requirements management (RM) tool for complex product development and the various benefits of moving to a modern solution like Jama Connect™ in our blog series Legacy Sunset. You can go back and read those posts if you’re interested in learning more about pain points, proven alternatives, and more.

Now that we’ve covered some of the reasons to make the switch, how do you go about migrating to a modern requirements management solution while minimizing business disruption? The process of migration does not have to be daunting.

Jama Software offers four key migration solutions to support companies in their migration from a legacy requirements management solution like IBM® DOORS® (IBM Engineering Requirements Management – DOORS Family) to Jama Connect. These flexible solution components allow customers to replace legacy solutions, co-exist with these legacy systems, or simply use Jama Connect and connect to the customers and suppliers using legacy requirements management tools.

Customers leveraging our migration solutions will work with Jama Software consultants to adapt Jama Connect to fit their individual product delivery process, identify and migrate required data, and train teams to quickly achieve sustainable results.

Let’s review each of the migration solution options:

Jama Connect Import

Our most-used method of importing requirements data from DOORS into Jama Connect directly is the Jama Connect Import Tool. This solution can be easily accessed through the Import Directory which allows data to be pulled directly into Jama Connect, downloading an HTML set of images. There is no additional fee and this option is included in the standard purchase of Jama Connect. Instructions for using the Jama Connect Import Tool are covered during the services onboarding phase of the implementation. When data is simple and the volume of data is moderate, this is a good migration option.

See how Jama Connect can transform your requirements management process for legacy software customers in our whitepaper, “Jama Connect: A Modern Requirements Management Alternative to IBM DOORS.”

Data Exchange Services

Data Exchange Services allow you to manage requirements across suppliers and customers without necessitating online data integration, which in turn reduces data duplication by leveraging round trip exchange. This service allows customers to operate within a legacy ecosystem while adopting a modern requirements management tool within select departments and across organizations where legacy requirements management (like IBM DOORS) is the standard.

Data Exchange for Jama Connect allows the import of modules or sets of modules in the industry standard ReqIF format directly into Jama Connect from legacy RM tools. This solution takes a level of permissions to export the data from DOORS into a ReqIF file. In order to import data into Jama Connect, it is possible for this tool to be extended and customized to meet specific client needs.

DOORS Migration Engine

Powered by Sodius, the DOORS Migration Engine was created to help support customers with more complex requirements data, or those who have large volumes of data, as they migrate from a legacy solution to Jama Connect.

The DOORS Migration Engine extracts directly from the old data in legacy RM tools and imports it into Jama Connect. This scales to manage large loads of data migrated from solutions like DOORS 9.X to Jama Connect. Customization is possible with this migration solution to support any unique data requirements for customers.

REST API

Customers can also perform the data migration on their own using the Jama Connect REST API. This option scales from small to enterprise customers. For those who choose this option, it’s important to mention that even though you are handling the data migration on your own, Jama Software’s Professional Services team is available to assist customers through this process.

Whichever path you choose, switching to Jama Connect requires a migration approach that scales to your people, process, and data. It’s not just about migrating the data from one database to another; onboarding and training teams on the new solution is also a critical component to long-term success.

Migrating off of a legacy RM tool takes planning. And regardless of which migration solution you choose, we’re here to support you throughout your transition and help you figure out the best way to use Jama Connect, and not just recreate the clutter of your existing legacy tool.

For a deeper dive into why leading organizations are leaving legacy solutions behind, check out our recent webinar, “Top Benefits of Moving to a Modern Requirements Management Tool.”

*IBM® and DOORS® are registered trademarks of IBM Corporation.

This post on innovation in automotive engineering is part of a series. You can find Part II on legacy software pains here, Part V on moving from DOORS to Jama Connect here, and Part VI on migration solutions here.

Few industries are as visibly affected by digital transformation as the automotive industry. Over a century ago, Henry Ford started to produce the production of the famous Model T and jump-started the success of the car as a consumer item. There has been lots of incremental innovation ever since, but nothing compared to what we are seeing today, like self-driving cars, over-the-air feature enablement, or transportation as a service.

Challenges for New and Established Organizations

It is unclear who is in a better position for exploiting the exciting opportunities in the automotive market. Established vendors have a solid, financially-strong foundation to operate from, combined with decades of experience in building cars. But this legacy is also slowing innovation down, as manufacturing processes and production lines are based on long development cycles. There are reasons for it: Existing automotive design processes evolved from a paper-based mindset, where every additional iteration in is expensive. Likewise, the production line was tuned for high throughput at low per-unit prices, but this makes changes very expensive.

New players in automotive engineering, on the other hand, are generally more agile and open. They can react faster and are willing to think outside the box. But their lack of experience can result in major issues with respect to compliance and production, creating expensive delays at late stages in development.

The First Generation of Requirements Management Tools

For decades, the automotive industry had recognized requirements as a key factor for success. The German automotive industry, in particular, started to introduce dedicated requirements tools in the ‘90s, and they encouraged their suppliers to do the same. Their solutions were establishing a new paradigm, using an item-based data model, rather than documents. This means that every requirement was an atomic item, with its own attributes, like priority and version history.

IBM® DOORS® (IBM Engineering Requirements Management – DOORS Family) was pioneering the idea of item-based requirements, and until the mid 2000s, there was really nothing like it available on the market. But by that time, some of the shortcomings of DOORS were becoming apparent. As a result, requirements specifications with tens of thousands unstructured requirements were not unusual, leading to redundancies and inconsistencies.

As a result, the first generation of requirements management tools were effective in helping the industry to scale. To a degree, they also helped in managing complexity. But they did not help in making the industry more innovative.

See how one Fortune 100 semiconductor company is managing the complexity of automotive development in our whitepaper. Read now.

Innovating with the Current Generation of Requirements Management Tools

Jama Connect™ was created to address the shortcomings of the first generation of requirements management tools. Specifically, Jama Connect was designed to solve the top challenges faced by regulated systems development teams. This fits the situation in the automotive industry today, and the following capabilities are key enablers for innovation:

Ease of Use – Requirements are used by everyone involved in automotive engineering. Not just the development team, but also engineering, quality, product marketing, sales, and leadership rely on requirements for an up-to-date product description. Good requirements also help departments make informed decisions. By contrast, first-generation tools were so hard to use that many important stakeholders refused to use them.

Single Source of Truth – Innovation requires trade-offs, which must be based on facts. It is crucial that facts — possibly derived from various sources — are instantly available. The first generation of tools typically only held a fraction of key data, and generating meaningful reports was a tedious, manual process.

Collaboration – Innovation requires heavy collaboration. First-generation tools did not have collaboration features, which meant that it took place outside the tool, i.e. via email or in meetings. But that creates a lot of friction and leads to situations where important information is missed. Modern solutions, by contrast, allow collaboration in context. This means that you have visibility into all relevant data and access to all relevant stakeholders while collaborating. And not just that…

Audit Trail – While first generation tools already had proper versioning, modern solutions go much further: For instance, the context-based collaboration leaves an audit trail in the tool (rather than in Outlook). This is crucial for efficient risk management and compliance. Developing new, innovative products typically results in much more activity. Context-based collaboration records decisions, issues, and answers exactly where you need them for compliance, and where you find them when you make reviews and trade-offs.

Learn how to avoid some of the biggest mistakes while developing automotive products for ISO 26262 compliance. Read the guide.

Managing Change – More than anything else, innovation requires the ability to react to change, no matter whether from the outside (new market needs) or inside (new technologies). The first generation of tools already acknowledged that by offering traceability-based functionality. But it was cumbersome to create and maintain the traceability, and many traceability-related issues were not apparent during day-to-day work but required running special reports. Modern solutions, by contrast, offer actionable traceability: Gaps in coverage or items that are marked as suspect due to change are visualized in many places, and allow fixing with a few clicks. This takes most of the friction out of the management of the traceability and allows for faster development iterations.

Reuse – Ironically, using what we already designed is an enabler for innovation. Without effective reuse, a lot of time and energy is wasted on re-designing what had already been designed and to re-test what had already been tested. It allows to focus our energy on the 20% that are truly new and truly innovative.

Integration – Last, the first generation of requirements tools created internal silos by making it very hard to get data in or out. Large vendors often offered half-hearted integration with their own software tools. While this was better than nothing, it often resulted in mediocre tool chains that were not based on need, but on availability. Jama Connect, by contrast, embraces openness by offering powerful interfaces that encourage integration with best-of-class tools.

Innovation in automotive engineering is only possible if all stakeholders can collaborate effectively, even in the context of very complex products, without being held back by the need to collect data from multiple places, or burdensome regulatory overhead. This is only possible with current generation requirements tools like Jama Connect.

*IBM® and DOORS® are registered trademarks of IBM Corporation.

Learn how the combination of Jama Connect and our Automotive Services tightens your development process by reading our datasheet.

This post is part of a series. You can find Part I modern alternatives to IBM DOORS® here, Part III on enabling innovation here, Part IV on the difficulties of compliance here, Part V on moving from DOORS to Jama Connect here, and Part VI on migration solutions here.

For decades, companies building highly regulated, technically complex products and systems have relied on legacy tools like IBM® DOORS® or even Microsoft® Office® for requirements management (RM).

As software becomes more prevalent in physical products and development methodologies evolve, legacy RM tools like these have struggled to keep up with the modern speed of capturing, sharing, and managing requirements.

See how Jama Connect stacks up to legacy software tools like IBM® DOORS® in our whitepaper.

Legacy tools are powerful, but even with their complex capabilities and reputation for stability, they don’t always match the goals of teams who need to adapt, innovate, and grow.

Noticing this misalignment can surface as painful moments — like when your team struggles to get work done. Sometimes those issues are process or market related, but in some cases they are actually because of the exact software tools you’re using to make your life easier with requirements management.Here are some critical signals that your team is no longer aligned with your legacy solution for requirements management, and how you might consider a change going forward.

Painful Moment 1: You value the input of multiple roles and skillsets, but you realize only a handful of people know how to use your RM tool (or worse, they’re not allowed into it).

Why It Matters: This is a signal that the RM tool was not set up with the whole team in mind. For companies innovating quickly, this lack of visibility into what you’re working on and why is a major risk. If it were possible for only a handful of people to build complex products, teams and companies wouldn’t have the diversity of skills and thought processes they do today.

What to Do: Consider a system that supports the workflow of multiple roles with advanced, user-friendly tools for different data types and views that still all roll up to the same goals. User-friendly traceability is essential.

Are you getting the most from your requirements management? Read our best practices guide.

Painful Moment 2: You miss the deadline for feedback on a requirement because the notification was unclear. Now you have to go outside the normal channels to have your input seen.

Why It Matters: This is an instance not always appreciated by those who wrote the processes. However, with legacy software that doesn’t make the intentions of users clear (such as wanting input by a specific date), it’s hard to avoid miscommunication and lost time.

What to Do: Look for RM tools that make the next action required of you clear and sends timely notifications with clear instructions.

Painful Moment 3: You try to enter data into the system, but it’s locked, archived, or somehow just not visible.

Your decision is blocked. The person you know who provides access and training is unavailable (for example, on vacation… or no longer at the company).

Why It Matters: Having company-mission critical software that only a handful of people understand and have access to is a huge risk for many reasons – some not as obvious. On the lower end of severity, you lose a few hours trying to access the right data. However, if the trend is that fewer people have permissions and training to use your RM tool, then you’re at risk of data being lost or your system eventually needing to be replaced entirely.

What to Do: Data can get richer over time; it doesn’t have to go stale. Invest in requirements management tools that support your team’s continuous growth and capture continuous input and collaboration.

Painful Moment 4: Your team wants to upgrade its legacy software to fix issues, improve security, and access the latest features. Unfortunately, it’s so customized and patched together that you can’t update without major consequences.

Why It Matters: The products you’re building change and improve over time. The software tools you use to get your work done every day need to keep up with you, at a pace that balances change with allowing users time to learn.

What to Do: Consider the risk and costs associated with stale software, and look for options that avoid getting you locked in to unsupported versions and brittle customizations.

There’s a lot of requirements management solutions on the market. Cut through the clutter with our buyer’s guide.

Painful Moment 5: You want to change the way your team uses the legacy software to match a new process, but there are no configuration experts available.

What if you break something? You hope you can create an experiment project on the side that will ultimately integrate back into the big picture, but it’s not clear how to create this outcome.

Why It Matters: If teams are struggling to get on the same page with their requirements management process, it’s a signal that whatever your building may have misalignments as well.

What to Do: Consider RM solutions that balance each team’s need for autonomy with the need for alignment. This can be supported by software that have services experts available to adapt the tools to your needs as you change, rather than one big rollout that attempts to predict the future.

It’s tough to have to work around legacy software to get your job done. It’s also expensive. Maybe you can’t change the RM tools you use on demand, but if you start to notice these painful patterns it becomes easier to build a business case for making a change that supports the whole company’s vision.

Learn the benefits of switching from legacy software tools for requirements management with our paper, “Jama Connect: A Modern Requirements Management Alternative to IBM DOORS.”