IBM DOORS Reviews

We primarily use the solution for giving requirements, both mechanical and electric.

The shell scripting is the solution's most valuable aspect.

The strict requirements for synchronization of the data could be relaxed. It requires a permanent connection with good bandwidth. This means that in an environment with remote networking that you need to go through a VPN or use some kind of virtual machine in the middle. We had some issues with the disconnection of desktop software and so on. The strict requirements of time synchronization between the DOS server and the client that request you to have a permanent good connection are difficult now that we are working more remotely due to COVID.

The solution has some scalability issues.

The performance could be improved. It doesn't run as smoothly as it could.

The usability when you're doing writing tends to be similar to Windows. It's a rational style. It needs to be able to do drafting with drag and drop, copy and paste, etc. There needs to be more usability in order to help people move data, create drawings, etc. 

The solution should be able to support different formats and texts.

I have been working with this solution for seven or eight years at this point. It's been a while.

The stability of the solution was okay, aside for the disconnection issues we faced, it was largely fine.

The original version has some scalability problems. In some specific cases, we had some problems managing all of the client's licenses and digital locks. 

We currently have about 25 to 30 licenses and that covers 50 to 70 users.

We've dealt with technical support in the past, especially at the beginning. We're mostly satisfied with the level of support we've been given. Sometimes it would take a while for them to get back to us, however, the support we received always helped and we were able to resolve any issues we had.

We worked together with one of our dealers in order to handle the initial implementation. We were handling a complex environment in order to fit our requirements. Due to our needs, the implementation and initial setup was more complex than straightforward.

Deployment took us a couple of months, including having time to review everything.

We have our own internal team that handles ongoing maintenance.

We used some FirePop Integrators to assist us with the implementation.

Our organization does have some commercial agreements with IBM. We're more of a customer, however. We arent an IBM partner.

Whether this would be the correct solution for a company depends on the installation and requirements. You'll need to prepare a specific environment for the company according to how it works. Therefore, it depends on the customization requirements. If they want it related to the environment itself or not, there may be some complexity in the setup that needs to be planned for. That said, I would recommend the solution overall.

I'd rate the solution eight out of ten. It's pretty good, however, it could improve its overall performance.

The most valuable feature for me is the ability to enter data into one table, or context, and link it across modules.

The GUI needs improvement in the following ways:

• The OLE embedding is not very user-friendly.
• The whole concept of having to lock and unlock, in order to switch the edit mode, is not user-friendly.

In the next release of this solution, I would like to see integration with other tools. For example, for change management, and with tools like IBM Rational ClearCase. I know that IBM has now linked ClearCase, ClearQuest, and DOORS, but we have an older version so I do not know how good the integration is.

This is a stable solution, although it depends on the network connection. It runs poorly on a slow network connection, so you need a fast connection.

In my opinion, the solution is scalable, but it is limited because you have to stay within one location. You cannot scale it across the whole world because of the dependency on network performance.

For this solution, we have several hundred users across several databases. In addition to the end-users, we have a system architect, system engineers who put in the requirements, functionality developers who break it down to the system requirements, software developers, and testers.

We have our own in-house experts who are quite helpful and responsive. I do not know if they have any experience dealing with the IBM technical support team.

We have used this same solution from the start.

We use predefined templates, so the setup for us was more or less straightforward.

Our in-house IT department handled the implementation of this solution.

My advice for anybody looking to implement this solution is to first get the processes right, and then look for the tools.

The whole idea behind this solution is great but, the execution and the handling is old fashioned. It would have been ok ten years ago, but we are used to having better tools now.

I would rate this solution a six out of ten.

Requirements management, however could be customized to track tests and even change requests through customization.

Requirements management is a key activity in any software development process and especially so in safety-conscious industries, i.e. where incorrect software can kill you, e.g. automotive, aviation, medical devices, etc. In these industries DOORS (any requirements management tool) shouldn’t be thought of as an improvement, but more as a key tool for doing your job, like a compiler or defect tracker.

The ease in which one can link requirements is very important to the general user since traceability is a core task in requirements management.

As an admin and developer, the DXL scripting language allows me to customize and extend DOORS in (almost) any way imaginable. (DXL is the scripting language used to customize and extend DOORS.)

Too numerous to enumerate. There are always wants by the DXL development community. Personally I would like to see a copy module function that optionally doesn’t include links and works on a baseline.

One huge improvement would be better support for distributed teams. The Rational DOORS client is terribly slow if you are not on-site with the server. Also, a better method of exchanging data between Rational DOORS servers or better yet a synchronization method.

But these will never happen because IBM is not interested in improving DOORS, it is focused on it's replacement: DOORS Next Generation (DNG).

Not if you take the proper precautions and train users. Bad user practices can undermine stability in the server.

I have never personally scaled Rational DOORS above approx. 100 active users and at that size we had no problems. I know of organizations that have 1000s of users. The key is to strategically divide your projects among several DOORS servers.

Customer Service:

I have never interacted with IBM Rational's customer service.

Technical Support:

I have only once interacted with IBM Rational's tech support. Had a good experience.

It's actually the other way around: it is a natural progression to migrate from DOORS to DOORS Next Generation (DNG) on the Jazz Platform. However I argue that DOORS is the superior tool and that organizations should not migrate to DNG.

Rational DOORS provides no guidance on best-practices for the product, or advice in requirements management using the product. So an initial setup is best done by someone with a deep understanding of both requirements management and the tool.

Only ever through in-house.

I would like to use this space to give an opinion on migrating from DOORS to DNG. I have been the sole person in charge of and doing the migration and I have provided input on other migrations.

I understand the desire for, and have in the past strongly advocated, the use of an integrated tool chain. IBM Jazz products like RQM, RTC, DNG, etc. provide, in theory, the holy grail: planning, defect/change management, requirements, and tests, all linking together. However...

Focusing just on DNG, it is in my experience a terrible product. Some features work really well. But others baffle me in their ineptitude, and these are legion. Almost everyday I run into an issue that makes me curse it under my breath.

People who have used DOORS to it's fullest extent, with a high-level of DXL customization, will hate DNG. One of the hardest parts of migration is convincing users DNG is better. I have given up on that because I am now of the opinion that DOORS is better than DNG.

Why? DOORS, at its heart, is not a requirements management tool. It is a highly extensible object linking system. That extensible-ness is absolutely key to making the product work for you.

I have come to the conclusion that if you are considering migrating from DOORS to DNG... DON'T! Instead of spending 100's to 1000's of hours doing migrations, invest those hours in a DXL programmer to make DOORS do what it isn't doing for you now.

Many new Rational DOORS users hate the product as a relic from the ‘90s. Most who have used the product over several years are generally ok with it. I like it, but I’ve made my living off it for years so I’m biased.

Rational DOORS can be an excellent requirements management tool, but only if:

1. All users of the tool are on-site with the server. Rational DOORS should not be considered for distributed teams unless you have a robust method like remote desktops.
2. All users are trained in how to use the basic features of the tool.
3. There is an experienced Rational DOORS admin and DXL developer (can be same person) that can support users and create customizations and extensions. Rational DOORS out-of-the-box will never satisfy the needs and desires of users or admins. Only an experienced admin/developer will understand the best-practices for the product and be able to quickly build a layer of customizations and extensions to make life easier for users and admins.

Please note that I consider these points extremely important. You cannot just buy a few Rational DOORS licenses and think you’re done. To be able to use Rational DOORS effectively you must invest in user training and at least one person who is experienced in Rational DOORS.

And finally, perhaps a little off-topic, users ought to be trained in requirements management, especially in safety-conscious industries. For example, earning FAA certification for avionic software is a process whose foundation is requirements management. Users must understand why requirements management is important and be taught how to apply its principles in their work.

The postings on this site are my own and don't necessarily represent Visteon's positions, strategies, or opinions. #iwork4visteon

DOORS is a customizable requirements management tool. The main feature that DOORS is used for is the traceability, which through it you can perform an analysis on the requirements how they decompose down to the lowest level. Also you can perform an impact analysis on the proposed changes and see the cost of your change. History of changes in DOORS is also important, as a lot of time there is a need to find out who performed the change as in a large team with people moving from place to place sometimes is needed to trace to the originator and understand the reason.

The way that new attributes can be created and the access management in all level is also another feature that is very useful in DOORS as with distributed teams and external contractors there is always the need to manage the data that users are allowed to access and modify.

Of course with the use of DXL all those things can be automated and be reported. DXL is very dynamic and came a long way from 5.4 and earlier. And as a lot of development and effort has been put into it, companies are reluctant to move to DOORS NG as this feature does not exist (or anything similar to it).

We are using DOORS together with IBM Rational Publishing Engine for reporting that makes everything a bit easier instead of using DXL to export the reports to Word.

It is important to understand that DOORS is just a tool that should help you to manage the requirements, or better documents that needs to trace to other documents in a controllable way providing history of changes and details of the change that do not need to be reported but they need to be stored. It is important to understand also that the first thing before managing, is that a process needs to be in place that identifies what it has to be done and the way that it will be done described in a simple and clear manner. Then DOORS can be customised to support that process and ensure that the process has been followed. In that way DOORS can ease the burden on the user to follow cumbersome steps of process as there is no alternative. This way the quality can be improved and audits become easier. DOORS is heavily used in aerospace, space, automotive (especially safe critical or mission critical systems) as this way can ensure a full history and lifecycle of the requirements it can be combined with change management tools to control and track the changes and only allow changes to happen when there is a need. Also allows through traceability to identify the effect of the proposed change to the system down to the component (hardware or software). Furthermore it can be customised that way to record the verification and reports can be produced at all levels to identify that requirements have been validated and verified and the system performs as expected. In the organisations that I worked for and I’m still working DOORS has made a lot of things possible that reduce the development and verification time.

I have used DOORS since 2000 from version 5.4 to 9.6

There were some issues with deploying DOORS 9.6 64bit as the server had to be upgraded in a specific sequence especially if the client was also installed. In general if the instructions from IBM are followed then is usually safe. It pays at the end if there is a test system and the upgrade is tried first there before the production server is upgraded.

The latest version of DOORS is very stable. Earlier versions had problems but a lot of them have been fixed. One issue with the 9.6 version is the new feature of resizing and positioning the main DOORS explorer window and opening the last opened modules during start. This feature can give an error message some times which is not easily reproducible. IBM has been informed and there is an open problem.

DOORS can be scaled to a large number of users and usually modules can contain many attributes and objects. The main issue is the local drives, the faster the drives that DOORS data reside the faster the response on the client. Servers on virtual machines might sometimes be slower because of the way the local drives have been attached to them (storage SANs). But usually is pretty fast. I have worked in environments with more than 300 users and the only issues encountered are the data that were within modules (number of objects) and the history that was recorded. If there is a design behind it on what you need to record within DOORS then usually there are no issues. Sometimes in projects people are getting over excited and from the point that there was no tools and no control and everything was done in paper, they tend to create a lot of attributes to track even the smallest thing, this can create a performance issue as the data recorded are too many.

DOORS can be delivered to distributed teams with Citrix. This in my experience is the best solution as the performance impact through remote access is minimal (XenApp or XenDesktop). It is not advisable to be delivered trough Microsoft terminal server alone as there are performance issues and DOORS is not so usable. Then it can be secured with Netscaler, and delivered to any devise so when people are on the road they can use DOORS to perform their activities from anywhere.

IBM provides one of the best customer services that I have encounter. There are always there to support you and there are quick to response.

I have used IBM technical support a number of occasions to report issue with DOORS or RPE there are always come back quite fast (within a few hours of the issue), and there are always find a solution or a fix to the issue. Also IBM has forums that can be searched for solutions and issues that other people have encountered, post questions and someone from IM will reply. Online help is always good and up to date.

Initial setup of the software is straight forward. Just follow the steps described in the IBM site. The complexity starts on the use case of the business that wants to employ DOORS. Different businesses have different use cases and different users have different needs. At that point an expert is needed to design the Database and the relationships in that way that can be maintainable for the future and provide an ease of use. DXL tools and customisations always add an extra level of complexity.

In-house implementation

I have worked with DOORS since 2000. I have used DOORS as an engineer managing my requirement, verification and tests, as an expert user, creating DXL scripts to export documents to Word, as an admin managing users and the entire database (multiple databases through the sites). I have developed Verification Tools in DOORS that control all the process of verifying the requirement from creation of the test procedure and script to writing the results and running the test (reviews, accesses etc.). I have a big experience in DXL and I can achieve anything with DXL (with some limitations). What I have seen over and over again is that the use of DOORS is incorrect in a lot of companies. Most of the companies try to adjust the processes to the tools provided instead of adjusting the tools to the correct process. DOORS can be adjusted to the process that you would like to work with, if you think about the process first in isolation of the tool, then, you cannot go wrong with DOORS. The other way around will lead in a lot of effort to put everything right. Standardisation is another issue that companies get it wrong. Users does not want to standardise, they want to do their own thing. The effect is that they use DOORS and for the same work there are a lot of different ways of doing it. They use DOORS as a repository and not as a tool to help them achieve their work easier. DOORS can help you to standardise, minimise mistakes and effort needed to achieve your goal, which can lead in reducing the cost of your development, validation and verification of your product.

The DOORS Application provides object to object traceability, with user flexibility to build their own traceability reports without requiring administrator coding in DXL, XML, java or any other scripting language. In addition, out of the box features for generating baseline to baseline redlines is efficient when reviewing changes.

The documentation of history is automated, making the generation of reports for the change review board simple. I can extract redlines using Baseline Compare between the last approved baseline, and the ‘current’ module, which collates all of this history into a single redline report making change reviews a breeze.

Clean specification generation has become more difficult under IBM’s direction, than it was under QSS or Telelogic. Since IBM acquired DOORS, there have been bugs introduced into the out of the box print capability (Ctrl+P), while they developed a complex printing solution in Rational Publishing Engine. This takes printing out of the user’s hands, and requires administrators or software developers to build templates for generating documentation which makes the job of generating a document a project in and of itself.

I have been using and administrating DOORS since 1998 in multiple different roles, including in Systems Integration, Requirements Management, as well as Engineering Tool Support team member. I've also used v4.0.4, v4.1.4, v6.0 SR1, and v8.3 for requirements management and risk management for medical device development and on-market support.

DOORS has some issues with speed when setup in an enterprise environment. However, DOORS has been the most stable product amongst our engineering tools.

We have been very successful deploying the product to users in Dallas, Chicago, Ireland, Germany and Japan.

Customer service for all of our Engineering Tools has been trending down over the last 10 years, and DOORS is no exception. However, among the biggest of players that we use including Dassault Systems, Siemens, HP, Serena, we have found IBM’s level among the best. I have had direct customer access to the DOORS development team at multiple conferences, who have been able to find resolutions for problems, and have provided enhancement requests that have been developed into the tool over the years.

Prior to DOORS, over 17 years ago, we used a custom Lotus Notes database, but it did not provide traceability or easy reporting.

DOORS is a proprietary database, and it is a simple install of a server and a client, and you are off and running. Very straightforward in the Rich Client environment. It only begins to get complex if you begin setting up integrations using the IBM CLM environment.

In-house engineering tool support team is how we evaluated, tested and deployed DOORS in our company.

The products developed in our company that started with DOORS requirements in the late 90s are now a one billion dollar annual revenue product line. My advice on requirements management in a regulated environment, is that if you try to do it cheap, rather than efficient, your products will suffer during the market phase.

We have evaluated many tools over the years, including MKS, Siemens Teamcenter Requirements solution, and none of have met the ease at which a user can create and customize their own views and traceability reports, without an administrator performing customization.

In my experience with IBM, I received initial customer requirements, which I stored in an Excel spreadsheet. These are then integrated into DOORS for comprehensive management throughout the project lifecycle, including contractual obligations with suppliers and stakeholder requirements adjustments.

The platform's traceability capabilities are invaluable. They provide a solid foundation for certification processes and manage requirement changes across project lifecycles.

Enhancing security measures, particularly when handling multiple projects simultaneously, would be beneficial to prevent data loss within DOORS.

The platform has proven stable when managing several concurrent projects.

The product is scalable, but it's crucial to ensure robust security measures when managing multiple projects simultaneously.

IBM's support services have been commendable. Their support team was responsive and helpful whenever I needed assistance managing requirements in DOORS.

Positive

IBM DOORS is more user-friendly for requirement management and offers superior traceability compared to Cradle, which has a less intuitive interface.

Setting up the platform can be complex, especially when configuring modules and building diagrams.

I rate the process a seven. 

The product generates a return on investment for large-scale projects where meticulous requirement management is critical for successful outcomes.

The licensing costs for the product are quite high.

I recommend the platform, particularly for its effectiveness in managing complex requirements.

I rate it an eight out of ten.

We use the solution internally in our organization.

The product creates an ID for each requirement update. It is very detailed. The product enables users to divide the requirements and export them. So, I need not give my customers access to my database. They can review it and send it back. The next-generation features are good.

The customer must also have the tool to import the changes and accept them as a part of the review. It is a disadvantage to us if the customer does not use the tool.

I have been using the solution for two years.

We do a lot of testing compared to other companies. We face a lot of downtime, even for a normal website. There are a lot of bugs, but the vendor has not solved anything yet.

The initial setup was difficult. My organization did the deployment. Online licensing includes a lot of processes that I am not aware of. Once the organization installed the solution, I requested an additional license. It is difficult to use the tool. The solution is deployed on my laptop. I have an internal link to access the product and GUI.

The licensing cost is too high.

If I had considered the latest next-generation features, it would have been easier for me. I'm not a full-time requirement engineer. I am exploring other tools. My organization decides which tools to use. Overall, I rate the tool a six out of ten.

We use DOORS for aerospace applications. I'm a systems engineer and we are customers of IBM. 

The solution uses a custom object-oriented scripting language called DOORS Extension Language or DXL. It allows you to manipulate the software to your liking. It's very customizable and can be as powerful as you want it to be. User management is pretty straightforward and I generally enjoy using the solution. As the administrator for the program, it's very quick and easy to add a user, change permissions, rights, things like that within the software.

The software is very dated and old. It's hard to get people to use it because the GUI looks like something from one of those giant Mac computers. It's not very user-friendly and can become slow very quickly, especially if you're not on site. It's been detrimental in this recent work from home era. If you have a lot of employees working from home, DOORS will operate more slowly than if they were on site. The DXL will be very slow if you write an inefficient tool and then your client will suffer. Not everything is necessarily written by IBM software engineers who know the system well and it will slow down as you put more tools and information into it. There's a tendency for garbage accumulation which is the simplest way I can put it. Processing of images needs to be improved. 

I've been using the solution for one year. 

There are a few bugs, some of which get addressed in updates, but there are still a few that you have to fix right out of the gate. 

The product is very easy to scale, in my opinion. It will slow down as you scale, but it's the best way to handle a large project in my opinion. It can chew through something big, it just might do it slowly. We have around 500 user accounts. 

IBM can sometimes be slow and convoluted. It can take in the order of two or three weeks to really resolve a problem on the IBM side. It requires an IBM account and a lot of hoops to jump through before you can get to them on the phone and get a straightforward answer.

For anyone wanting to use this solution, it's important to take the time to learn DXL. Don't take it for granted because understanding how it works will make a big difference. 

I rate the solution six out of 10.