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.

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

There are numerous projects that we are using with IBM Rational DOORS. They are isolated from each other and then we receive requirements from outside sources, load them into DOORS, and use them to do traceability into architectures developed in MagicDraw.

It has improved our ability to do traceability back to our initial requirements. The traceability allows us to be able to rapidly advise our sponsors.

I like being able to sort and categorize the requirements and the exporting functions.

I would recommend that fuzzy logic be added to the search capabilities. I think there is probably room to improve by offering free training.

I have been using IBM Rational DOORS for the past ten years.

IBM Rational DOORS is stable.

I think overall it is scalable and has measured up to everything we have tested it with.

I would rate technical support a six on a scale of one to ten. I have tried to contact them twice and never heard anything back.

Neutral

My initial setup and integration were more complex than I was expecting.

I believe they did the deployment in-house.

I would tell them to be very cautious about how they initially import their requirements into the product because that initial import seems to carry more weight and effect than I would have anticipated.

I would rate IBM Rational DOORS a seven out of ten.

The ability to link objects is most valuable, because this provides the traceability from the customer requirements to our product requirements, and ultimately our test results.

As the product development lifecycle progresses, DOORS helps to maintain the traceability as requirements change (base-lining), and as new requirements emerge.

The most difficult feature of DOORS is how it creates "DOORS tables" from tables that are imported from a Word document. There are ways to address this, but describing them in detail here would take up too much space. Workarounds include using embedded OLE objects of Excel spreadsheets or using an image of the table if it is a small one that is unlikely to change.

I've used it for 10 years.

Remote users, that access the network via a VPN, may encounter a bit of sluggishness maneuvering through the database - but that may depend on the speed of the network and the size of the database. There are ways to address this issue.

DOORS stability is quite reliable.

No issues encountered.

Excellent! IBM Rational DOORS team have always been quick to respond and knowledgeable about any issues I may have presented them.

Excellent, as well. Very knowledgeable.

Prior to IBM Rational DOORS, I've used a SLATE database to track requirements. It wasn't as user-friendly and at the time we switched to DOORS, the decision was based on what our customers were using to track their requirements. DOORS was the better choice and is still the most recognized tool for requirement traceability.

The initial setup was straightforward, thanks to the robust help files that IBM has maintained as a library that is accessible both inside the tool (Help button) and via the internet (on the IBM site). Aside from that, technical support was available as needed - even to the extent that phone support can be provided.

We used our own in-house team.

As the product life-cycle reaches maturity for a given project, the ability to re-use requirements, and their related data in other projects is very helpful. DOORS is also a great tool for discovering "orphan" requirements early in the cycle, as well.

IBM Rational will work with you if you decide to use DOORS. The support provided by the vendor is excellent.

Our primary use for DOORS is that we implement this product for our customers and build-out customized components.  

This product improved our organization because it has given us a means for improving the way we proceed through solution development.  

One of the most valuable features of the program is the usability. It is really simple to use and its logic, look and feel are familiar to most customers. Let's say it is more of an old-fashioned interface design. If you look at the software, you will notice that the layout is similar to the old Microsoft Windows Explorer. This is helpful to customers who have long-term experience because the look and feel is something they remember from the structure of Explorer and they find it familiar when they go to use DOORS.  

There are several other features in the product that are valuable to users and to us. These features would have to do with the traceability and the possibilities for customization of the RP (Relying Party). This is important because several of our clients run an awful lot of customizations.  

In the past, we communicated customization needs to Telelogic and IBM through huge customer meetings like conventions, but nothing happened. That was when we added our engineering offices and started our business using customization tools. The clients who can't find what they need come to me now and ask if we could please develop tools like so-and-so (whatever company and functionality). We make it for them and we make it better with customizations — specific to their purposes. As a tiny, small engineering office we often get called for special solutions, for special company needs, which formerly Telelogic and now IBM was not willing to do for the customer. This is a big reason why DOORS is valuable for us and has helped us make our business.  

What could make sense for this product is to improve is to develop a more efficient way to import and export documents from Office 365 like Excel, or Word and the other applications in this suite. Maybe, if possible, add a PDF document export or something like that. There are quite a few single steps that you have to take separately at the moment to make this happen. The parts are already implemented, but there could be a much more unified and efficient way to get that done. Again this is a repeated request from users and nothing has been done to implement it.  

What I would like to see is in the product is that eventually, IBM will implement additional software solutions for integration. There is one that I know of that used to have the name RPE. It stands for Rational Publishing Engine. I think it is a tool that should be implemented in DOORS because it belongs to IBM after they purchased Rational Software. With this integration, we would have a much better way to actually import and export between Word or other Office documents.  

On another side, it would be good to also see them integrate the GC (Garbage Collector) trace tool. It is a logical requirements engineering tool that would enhance some capabilities. It could be a specialty add-on but the integration needs to be there. This product is owned by IBM because formerly it belonged to Telelogic as well. It would be good for IBM and the users of these tools to have these solutions implemented in DOORS.  

I have been working with this product since Version 0.1. More than 20 years.  

The stability is quite nice at this point. After these last few major versions, they have made significant improvement and it is very stable.  

From my side, scalability is okay so far. I have not had any bad experiences in our own use or with clients.  

Our clients who use IBM Rational DOORS are usually large, enterprise companies, like airline industry companies, like Siemens, we work with Audi, Mercedes, and BMW. So we are not usually talking about small companies. But they are not all alike and we have clients of all sizes.   

In the past, I had a reason to contact IBM technical support, but I wasn't impressed. It was a lousy service. There is no question the technical support can be improved. It might not be a bad idea. The funny thing is that since IBM took over Telelogic and some of the guys from Telelogic have been moved over to IBM. If you get the ones who still work for Telelogic, you get fine and proper service and resolutions. But if you do not have the luck to reach one of the Telelogic people and you reach one of the ordinary IBM people, it is the worst case and you probably will not get what you need.  

Positive

Before we used IBM Rational DOORS, we just used Word and Excel to create our solutions.  

The initial setup is easy. The deployment usually takes a couple of weeks.  

In the deployment process, there are between three to seven people involved depending on the project.  

It is not simple to answer how many people are involved in the maintenance because we have decided to divide the way we look at supporting clients and products into different levels. Our support services have three levels now because all these different levels need different information about the tool in-depth to be able to use it properly for their purposes. If we do not provide them the information about the tool in-depth, we would not be providing proper support. In general, we have about six people providing the maintenance services.  

We do all of our own implementations.  

All my clients are running under a special agreement using a client-server version of the DOORS product where they get a discount on the product and then only pay maintenance. They pay the maintenance on a yearly basis. They are mostly huge companies and this is partly how they were able to get this special agreement. It works well for them because we have informed the clients how they could reduce their maintenance costs.  

Our evaluations are ongoing. As an independent requirement engineer and system engineer, I'm running my own engineering office. From time-to-time, I have a client that asks me for information about other tools. But most of them still use DOORS or some other classic tool which has grown up through the .Net generation. So we do the research, but the research is more often to propose something to our customers if they are interested in doing something different and more modern.  

We do not have any shortlist of other possible solutions at this stage because it may require changing operating systems. It's quite different if you compare both DOS and the next generation. I am still trying to figure out what is the best way to move forward. At the moment, I'm not really satisfied with the technology that is working with DOS next generation.  

I get the idea behind the viewpoint from IBM, especially if you understand the focus on the newer, improved platform. It makes sense. But for established companies that have hundreds or thousands of documents in a classic DOS database, it is not as simple as the IBM company thought to populate the next generation. Especially in a technical company, we need one more serious tool and with some evolved features. When that happens, it will be okay. But a total switch from what they were doing is not what most companies are looking for. In my impression, it is not important to have a lot of tools for the same discipline. I think it would be more worthwhile to get one nice mature tool which suits all the interests and at the end of the day. So far it does not exist.  

But by the same token, what we have to take in account is it doesn't matter if a product is made by a company called IBM or whichever company it is, we have to take care about the philosophy as it is only by having better tools that we have better success in a project. I'm not an engineer who is against all new technologies, but at the moment my impression about the American leadership and about the software technology — the current direction is frightening.  

I think it is now time to think more about what direction the American software companies are taking us in. It may not be the right way or the best way to see the future of the computing world. I have heard managing directors say, "We have to find other solutions at the moment. This software we get is from America and we are not willing to accept this leadership and direction at the moment.  

What we actually have learned — or even maybe accepted and are comfortable with is now — is that for the user projects work best and most efficiently, it is absolutely nicer to work in a more structured way. This product helps order our projects. Because of what the tool does, we have a way to document the bare base engineering. What we did in the past, before DOORS, we all used Word and maybe Excel in our offices to set up our specifications for the product. In DOORS, we can now work in a different way. There are very nice features that help to structure your documents, to link your documents, and make a different analysis, test your approach and see it better. There were no tools like this in Word and Excel.  

You also have the possibility to re-use things. It is quite nice to use a tool that allows you to use all your experience from a technical point of view and create the solutions in one data source and one tool and use components you create for various other projects as well.  

On a scale from one to ten where one is the worst and ten is the best, I would rate IBM Rational DOORS as an eight-out-of-ten.  

• Traceability
• Baselines
• Ability to customize using DXL

Having clear requirements is essential in delivering the right product.

I've used it for 18 years.

No issues encountered.

No issues encountered.

No issues encountered.

8/10

8/10

When I started using DOORS, there were several other relational management tools in use at Boeing (where I worked then). We set DOORS as our standard. Now, I work for another Large US Aerospace Company, and DOORS is our standard.

The setup is very simple. It licenses, and runs the two executables, server and clent, and you are done.

Although DOORS is very easy to use, the actual database needs to be set up correctly and users must follow a well-defined process. This is where most customers have issues with DOORS.

The best advice is to use tokens so you can use all the appropriate IBM tools.

Over the years supporting requirements management, I have participated in many trade studies where tools were evaluated. DOORS won most every time. Tools under consideration were Slate, Requisite Pro, RDD100, RTM, Razor, and TcSE.

The most valuable feature is the management verification and login.

The user interface is old and clunky and in need of some improvement. In order for DOORS to be as good as it needs to be, you have to be able to get normal people using it. The problem is that because the GUI is so bad, you either have to spend a lot of money customizing the interface yourself, or a lot of money on training. Because the users avoid it like the plague, you don't get the power out of it. You end up having specialists in the requirements world doing the work instead of using it the same way you would an easier application, such as Word.  

I have been using IBM Rational DOORS for about ten years.

This solution has always been very stable and doesn't really ever let us down. We do have Citrix problems because we are centralizing it but as a general rule, it is a solid tool. There can also be problems that are caused by other people's DXL coding, as people are modifying it to work for them. However, it is the modifications that cause the problems rather than DOORS itself. In this context, there are more self-inflicted stability problems.

I have not personally contacted technical support but the feedback that I have heard is that it is like all tech support. It is normally about relationships with the technical support people. The response time is pretty standard, being a couple of weeks. In Australia, they're 24 hours and normally pretty good in terms of responding quickly.

My advice to anybody who is considering this solution is that if you're looking for a relational database, then it's probably not the first place that I would go. People are going to use it because the client requires it, as in our case, rather than because you choose it. There are much better database setups out there, which are scalable for non-IT database people. The learning curve is much shallower because they're designed from the ground up to work as a database for normal people.

Overall, DOORS is old and clunky but it does what it is supposed to do. The interface hasn't changed forever because there's no drive to make it easier to use.

I would rate this solution a seven out of ten.

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.