IBM DOORS Reviews

We use IBM Rational DOORS to migrate from DOORS to other systems like MagicDraw. Additionally, we can accept data from these systems and migrate it for storage. This process involves syncing data between various applications.

IBM Rational DOORS is quite stable and useful, especially regarding gathering requirements, addressing them, and linking them. The user interface (UI) is simpler, cleaner, and stable.

One of the most valuable aspects of IBM Rational DOORS is how it structures data. When working on multiple projects, you'll find that each project contains various models. These models are akin to Word but offer additional functionalities. DOORS Security provides capabilities that Word lacks.

Under each module, you can organize requirements hierarchically and trace the requirements via internal and external links. Unlike Microsoft Word, DOORS enables versioning, allowing you to baseline your requirements and effectively freeze them when necessary. These functionalities make the tool highly useful and stand out among similar tools.

When the requirements increase within a single model in IBM Rational DOORS, it takes time to save. The requirements are associated with an absolute number in DOORS. For instance, they possess creation dates, modification dates, and information about the creator of each requirement. One specific attribute is absolute number.'The DOORS database automatically generates this absolute number and remains unmodifiable through the API. Therefore, it is not feasible when migrating data from one DOORS system to another or attempting to alter the absolute number through the API. The database generates this absolute number, which is unchangeable. DOORS cannot control or modify these auto-generated absolute numbers.

I have been using IBM Rational DOORS for a couple of years. We are using both V9.5 and V9.7 of the solution.

The product is stable.

I rate the solution’s stability a nine out of ten.

10-15 users are using this solution. Four to five users are using this solution every day.

I rate the solution’s scalability a seven to eight out of ten.

Both technical support and documentation are really helpful.

Neutral

The initial setup is simple and takes only half an hour to complete. For deployment, you need to click, provide some inputs, and execute fairly simple actions.

I rate the initial setup a seven to eight out of ten, where one is difficult and ten is easy.

We did the installation by ourselves. One person is enough to do the deployment, depending on the knowledge of software and administration.

There is no maintenance required until your license needs fixing. However, it is entirely maintainable. You don't have to handle any maintenance until you upgrade to the next version of DOORS, and even then, the process remains straightforward.

IBM Rational DOORS is highly useful for project requirement management. I strongly recommend utilizing DOORS for requirement management and offer flexibility.

DOORS is a valuable tool, and it has attracted numerous customers. Many organizations, including Fortune 500 companies, use DOORS for their operations.

Overall, I rate the solution an eight out of ten.

My primary use case is for the development and management of requirements, traceability of requirements up and down the architecture chain, and verification.

I like the user interface with regard to creating links between requirements and tracing links to requirements.

I like the DXL Wizard, in particular, to build custom views that I save.

I am a fan of the DOORS Change Proposal System, although a lot of people where I'm working have their own homegrown system. I continue to push them to migrate to the DOORS CPS.

The user interface for the Change Proposal System could be improved. When creating a proposal it is great and I have no problem with it. On the other hand, during a review phase, when many people are trying to look at the change and decide whether to accept it or not, the user interface is not really helpful because it just shows you the specific change. What we have done over the years to accommodate this is to create a specification module where we pull the proposed change features into that view. I can then look at the changes in the context of everything around it, and we can decide whether it is the change that we really want to make.

If there were a way in the change proposal window to view the specific change in the context of the other things around it, including potentially other changes, then that would be helpful. The workaround that we have created allows us to view all of the potential changes in concert with everything that is not changing, which is ideally what the change proposal GUI should do.

One of the people that I work with has expressed interest in a process where you have to propose changes to links, rather than just create them. In this way, you can maintain traceability under some form of configuration management for them as well. Personally, in 20 years, I have never had a program where we tried to control links to that degree. We would monitor them, but never had any formal change process for links.

We are not allowed to use DOORS as our configuration management tool and instead have to use Agile PDM. This requires us to export data from DOORS and import it there. However, if DOORS were tailored a little bit better then we could use it as our CM tool and avoid using the other one altogether.

More and more companies are getting involved with model-based systems engineering (MBSE). I know that DOORS has direct interfaces with many of these tools, although I have never used any of them so I don't know how simple they are to use. That said, anything that can be done to streamline and simplify the tool-to-tool interface between DOORS and other products is a good thing. For example, it should be easy to exchange data between DOORS and MagicDraw, CORE, Genesis, and others.

We have been using DOORS for many years, since about 2000.

I have had no problem with stability and I think that it's worked very well. I have been using it for many years and from a user's perspective, other than the change in the name, it's been very stable and very consistent.

I have worked on programs that varied in size from a couple of hundred requirements up to tens of thousands of requirements in the database. It always seems to work beautifully, irrespective of the size. In this regard, I think that it scales well.

On any given day, we have potentially dozens of administrators and hundreds of users. We have facilities from Florida to New York to California and everywhere in between.

I have not personally been in contact with technical support. When I need help, I see our administrator. I know that some of our administrators in the past have worked with technical support. Also, one of our former administrators belonged to a DOORS community user forum on the internet. This was a source of information that offered ideas and provided support. 

Our in-house IT administrators are responsible for setting up and maintaining our software, including DOORS.

My advice for anybody who is implementing IBM Rational DOORS is to start using it early in the program and use it consistently. In other words, don't let people do their own thing. Instead, come up with a standard process of what you do, which attributes you can use, consistent attribute naming, and consistent standard views. This way, everybody is using the same thing.

There will always be custom things coming up later, but you need to have a core standard. For example, every program will have 10 standard views and 40 standard attributes, which enforces consistency. As you go from program to program, people can understand it. That's all part of the initial setup phase, where you make sure that everybody is doing the same thing.

One of the things that I've been a big advocate for over the years is to remove the human from the process as much as possible. For example, I have to generate a file from DOORS to put in my configuration management tool for a formal release. This is usually a Microsoft Word file. The problem comes about when people edit the file after it is generated because they want to change the formating and other such things. When this happens, there is a risk of human error. Although there are ways to minimize this, I can't eliminate it. As it is now, I have no way of taking the human out of the loop completely.

I would rate this solution a ten out of ten.

By far and away the most useful feature of IBM Rational DOORS is the Dynamic Extension Language (DXL) syntax & manual that it comes with (then again I must be biased having been coding in DXL for 13 years and counting). With each new release going back to when I started with DOORS 4.1 the vendor (used to be Telelogic, until IBM bought them out) provides a DXL Reference Manual as part of the product which is free to anyone using DOORS - explaining which functions the IBM development team is using themselves to extend the DOORS client functionality (and inviting all software developers to take their crack at customizing the DOORS client to better suit the needs of their company)

By learning how to write reusable DXL, I've been able to write a single script that can then be plugged into all DOORS clients at my company, meaning if I can save one person 1 hour we can then multiply that by hundreds (if not thousands) of system engineers which equates to quite a lot of time & money saved.

Getting started with DOORS Administration, how to setup a project, how to maintain it, and how to get started with DXL are all areas that need quite a bit of experience to master. I highly recommend finding someone certified in being an IBM Rational DOORS v9 deployment specialist and better yet using him/her as a mentor as you learn yourself. Skipping the all important project architecture workshop is going to cause you a lot of frustration throughout the lifecycle of your project.

I have been using DOORS for 15 years, 1st two as a software developer that looked up the requirements for the GUI he was assigned to develop, the latter 13 for everything from writing DXL to meeting with clients, being a technical lead for a distributed set of DXL developers = lots of fun.

Not having the right people bought in at all levels of management to have a smooth flowing process for deployment, it takes the work of quite a few individuals to make it all work, IT, software, systems, configuration management, quality - getting everyone on the same page and the training they need just in time is quite a challenge.

By placing the DXL we've developed under heavy levels of scrutiny with code reviews, configuration control, change control boards and frequent interactions with the actual users of the solution we've been able to avoid the typical pitfalls that might come with developing customizations.

Developing skilled & experienced specialists that know how to setup DOORS projects and help existing ones adopt best practices takes time and the only way to get real experience is to do it, hard to find the people distributed across the geographical boundaries to fill these roles over prolonged periods of time.

it's gotten considerably better since the early years of the Telelogic acquisition, once you submit a few tickets you get the hang of it. It would be nice the same person answering all your questions all the time so you get the rapport, but that might be asking too much.

Once you get into the advanced use cases of using your own DXL, most of the time the support can be handled in house.

I started my career with DOORS & DXL and have not looked back. I have helped programs go from SLATE to DOORS.

It was quite complicated, luckily for me I learned from the best and was able to continue to network and continue learning from the brightest minds in the industry. Combining this with my own experiences and the many clients I have worked with have equated to superb amount of real like challenged faced and overcome.

Have had vendor in house for very select engagements, mostly self created solutions based on many in house meetings and sound software development.

A good question... lots of time & money saved.

I've been able to bypass this question for the most part in my line of work and focus more on the client experience once the DOORS server & licenses are available.

I absolutely believe for any company to be successful with DOORS they must invest in an in-house support team of architects & trainers who's full time job it is to deploy DOORS and help programs learn how to use it effectively.

We are mainly using IBM Rational DOORS for managing requirements.

IBM Rational DOORS keeps everything organized.

The most valuable feature is the verification requirements for peer reviews.

It has a user-friendly interface.

Some of the search queries could be improved. The interface needs an area to be able to type your query and actually be able to find them.

It could be more stable.

In the next release, they could scale it down a little bit and make it more stable.

I used this product up until three months ago. I have been with this company since February.

If I have left it open for too long, there are times where we experience a session timeout, and we have to stop or force-close it to restart the application.

From the time that I have been using it, it's been pretty good. Like anything that has been left open, you will experience a timeout.

IBM Rational DOORS is scalable.

We have approximately 300 users within the region.

I have not contacted technical support.

The initial setup was straightforward.

We have our computer management who instructed me to download IBM Rational DOORS.

It was simple to download and get started.

We may have used a retailer to help us with the deployment.

We are currently using IBM Rational DOORS on-premises but we are trying to migrate everything over to a Cloud service.

IBM Rational DOORS is good for privacy, it's good for the management of software requirements, and also for keeping everything organized. It does a pretty good job.

I would rate IBM Rational DOORS an eight out of ten.

• Centralised location for better team collaboration
• Scalable access control
• Traceability by linking items on the global requirement life cycle
• Integrations (modelling tools)
• Full customization using DXL
• Wide user community
• Available as a web based solution

We used it to implement a requirement management process in a CMMI evaluation. DOORS improved the way requirements were shared across the organization, and helped implement reuse strategy. It also improved the way the requirements concept was perceived in the organization, in that way it had also an impact on validation activities.

DOORS weakness is in the interface with the outside world, as the database is not standard, data cannot be easily managed by other tools. Import/export capabilities have huge room for improvement though importing a Word or Excel document is simple. There are no simple extensions available to generate good synthetic documents (RPE not being user friendly). Another item that is needed in any requirements management tool is the capability to manage the requirements data model at project/database level, attributes/types definitions in particular.

I've been using it for around 10 years since 2006. I was responsible for deploying it, including defining data models, training teams, and administrating the database for two different organisations. Both organisations are worldwide, and In the second, the user community was over 400 people worldwide.

As stated earlier, the missing ability of the tool to globally manage data model often leads to inconsistencies in the deployment phase, as processes are often being defined while deploying the tool. It's difficult to retrofit an incorrect implementation once started.

It's low. Since IBM acquired Rational. The support is basic and limited to the tools usage which is not what experienced users need. Experienced users need support for advanced features and DXL usage, which is somehow mandatory for any organization who wants to take full advantage of the tools capabilities.

No other solution was used before. Some other departments in the company were using a custom system based on MS Word with macros and reqtif.

We used Telelogic support to train the teams and initiate the datamodel construction

We used a benchmark study in which 10 other tools were rated, including Reqtify (which is not a real REQM tool), Requisite Pro, Caliber, and Cradle.

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