Tag Archive for: DO178B

Compliance Audit with modern requirements management

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

As the devices around us become increasingly powerful, their ability to harm us may be increasing as well. And while the majority of connected devices and products are safe, there are recent headlines that reinforce the importance of compliance audits and properly managing risk.

Recently, a hacker remotely killed the engine of a car while a motorist unknowingly drove down the highway. Another recent example happened to Toyota, when mistakes during development caused failing brakes and random accelerations, resulting in the automobile maker recalling almost two million cars.

But in spite of dramatic incidents like these, today’s products are remarkably reliable. We generally feel safe stepping into a plane or taking a ride in our car. We feel safe, because those in the automotive and aerospace industries must prove compliance with industry standards and regulations that ensure their products adhere to high safety standards.

Regulatory Compliance is Good for Business

Even though corners are sometimes cut, most companies recognize that compliance is essential in the long run. While the ethical argument is a no-brainer, compliance with regulatory standards also enables customer confidence, boosts quality, and motivates employees.

Compliance audits are based on standards like ISO 26262 for automotive developers or DO178B/C for aeronautics. These have been around for decades and have helped shape the design of countless safe products. Many of these standards are based on IEC 61508, which conceptually describes best practices that lead to safe systems.

Using safety standards for compliance audits

Regardless of whether you are developing a car component or nuclear reactor, there are certain capabilities that your development process must exhibit in order to pass a compliance audit. In this day and age, it is next to impossible to do this without the support of quality solutions. Selecting the right product development solution will help you:

  • Prove complete traceability throughout every step of the development process
  • Standardize best practices, ideally with automated compliance reporting
  • Visualize and effectively manage the impact of changes
  • Support your product schedule and ensure that it is not compromised by quality and compliance requirements
  • Act as your single source of truth for risk, test, and requirements

Learn more about requirements traceability by downloading our eBook, “The Jama Software Guide to Requirements Traceability.”

Complex Product Development Demands More than Legacy Requirements Management Tools

IBM® DOORS® (IBM Engineering Requirements Management – DOORS Family) was an amazing tool – when it was originally published in 1991, almost 30 years ago. A new product was developed from scratch, called DOORS Next (IBM Engineering Requirements Management – DOORS Next) and released to the market in 20121. Yet many users of DOORS hesitate to switch. This is because instead of an easy transition to DOORS’ new product, there is a lengthy migration to DOORS Next required that’s usually very costly.

DOORS has many capabilities for working in regulated industries, but the limitations far outweigh the benefits. It does not deal well with increasing complexity or the need for collaboration and seamless integration in existing tool ecosystems. Let’s have a look at some of the limitations of DOORS:

  • Traceability: DOORS has powerful traceability capabilities, but they are hidden behind a cumbersome interface. This leads to outdated traces. Users find traceability maintenance to be difficult with DOORS, and sometimes traces are created “after the fact” for compliance audits and nothing else. This is a missed opportunity, as an up to date, easy-to-use traceability matrix creates transparency and confidence when reacting to change. Traceability is also an enabler for agility.
  • Change Management: The traceability of DOORS does support change management, e.g. via suspect links in principle. Unfortunately, this information is hidden and hard to put to use. Compare that to the actionable traceability of Jama Connect™, which proactively points out issues in the traceability matrix and suggests how to fix them.
  • Compliance Reporting: DOORS allows you to report on virtually everything – but almost everything requires scripting with its proprietary scripting language, DXL. Unless you have a responsive programmer on your team, you will have a hard time getting the information you need.
  • Best Practices: Every “module” (document) in DOORS has its own fields, and without an in-house expert, users sometimes find themselves with little guidance on how to use the tool. This results in inconsistencies, which in turn result in confusion and lack of transparency. Consider two “system specifications” with inconsistent values for “priority.” Likewise, standardized workflows guide users through their daily work. In DOORS, you need a programmer to provide this functionality.
  • Collaboration: Collaboration is the foundation for high-quality product development and a foundation for compliance, which requires transparency and managerial oversight. But when Rational DOORS was released, the Word Wide Web was just two years old. Initially, no collaboration capabilities existed at all.
  • Single Source of Truth: DOORS provides you with a single source of the truth – as long as the truth resides in DOORS. In 1991, nobody was thinking about integrating various tools into a seamless tool chain. And therefore, DOORS is an isolated silo. Due to the complexity of the user interface, often stakeholders refuse to take a peek into that silo.

See how IBM DOORS customers can migration to Jama Connect by viewing our datasheet.

What about DOORS Next?

The only thing DOORS Next shares with the DOORS solution is the name. Otherwise, it’s newly developed software. This means that the raw requirements data can be migrated, but this is possible with virtually all requirements solutions on the market. The customizations that were done to DOORS cannot be migrated. This means that users who want to switch away from DOORS are not constrained by a particularly attractive migration path.

Whether you migrate from DOORS to DOORS Next or to Jama Connect, the effort is the same. And that allows you to compare the capabilities of solutions on the market without having to worry about the migration path: It will take some effort, no matter which solution you choose.

Leaving Legacy RM Solutions in the Past

We at Jama Software acknowledge everything that legacy RM solutions have done in the past for the discipline of requirements management and requirements engineering. But after almost 30 years, it’s time to reinvent modern requirements management.

In particular, the demands for compliance for today’s complex products can no longer be satisfied by legacy RM tools. Transparency, collaboration, best practices, and oversight – all these were non-issues in 1991 when legacy RM solutions were built.

If you are in an organization that uses a legacy RM solution, it is time to assess if it’s up to the challenges ahead and you have a choice of many modern requirements management solutions on the market.

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

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

1 IBM United States Software Announcement 212-505, dated November 27, 2012