IBM DOORS Reviews

We primarily use the solution for governmental management.

The recommendation aspects of the solution are good.

It's difficult to set the code on the solution. 

The testing part needs to be improved, but they have too much legacy to move to the latest IBM versions. 

I do not believe there are any more plans for this product. It's now a legacy solution. They should just ensure that they keep the technical support they have in place to assist existing users.

The solution is stable.

The solution isn't scalable.

We previously used a different solution, but the change was the company's choice.

The initial setup was complex.

The solution can be used in the studio environment, but you need to manage it correctly.

I would rate the solution six out of ten.

I use DOORS for capturing a system requirement and subsystem requirement. I also use it for recording a system of architecture.

The most valuable features include:

• Traceability (the ability to link between different items)
• Configuration Management (ability to baseline things and create new views)
• User Access (to control who does what to different items)

They have recently upgraded the product. And, it is definitely more user-friendly. It was really clunky to use previously. It might not be very fancy, but it always gets the job done. 

I think it would be nice if there was better integration with other tools, particularly diagrammatic tools so that you can do things like enterprise architecture. 

It is very expensive. But, it depends on the project. The project must warrant the expense paid.

I am within the automotive electronics industry. The requirements management widely used in my field for change management is the key to delivering your product without any hitches. It is hard to manage requirements in a big project, therefore having a traceability feature is great.

Traceability on requirements for a huge project in an organization is a big gain.

• Traceability
• The ability to use any type of document in any format.

These features make our job easier in requirements management.  

I would like to see them improve in agile management the Scrum/Kanban Board to work with overseas team members.

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

We use DOORS to document system requirements and inherit customer equirement maintain standard and conformity. It helps in traceability of requirements and restricts changes to requirements by anyone. In order to make changes to the requirements, one needs RCR (Requirements change request) which would be reviewed and approved before applying changes. It would help in impact analysis and version tracking.

It is a great tool for requirement gathering and elicitation. It brings all the business analysts in a team on the same page as everyone has the same understanding on requirements.The traceability to system requirements, customer requirement and test cases helps all teams to reference each other's work in an easier manner.

IBM DOORS has helped in keeping requirements wording and structure standard across all customer documents. It's export functionality helps in producing quality requirements with ease within short time frame. This helped in supporting multiple clients at the same time with lesser chances of errors.

• The product is less configurable in terms of Menu options. The replication of data is not as easy as excel across the rows/columns. In order to replicate, the user needs to go to each cell and make the change
• Upon losing connection to VPN/internet, DOORS can lose the content written and this requires it to be redone. The product should at least send a notification to the user about lost connections to avoid rework
• The images added in DOORS are not exported easily in word documents. They do not scale as expected

I used the tool for two years.

The software came pre-installed with the machine but DOORS upgrade took long time. It slows the machine and additional RAM is required on machines with DOORS.

Customer service is good as we got an IBM consultant to fix issues or code, but his support is limited to minor bugs. Major enhancements and bugs had to be escalated and sent to IBM which had a longer turn around time.

I have used HP Quality Center but DOORS provides better standardization and maintainability of requirements.

It was straightforward as it came pre-installed on my company machine.

It was through a vendor team. The implementation and training was smooth, but the enhancements and bug fixing took long time.

It is an expensive software but worth the spending for a larger firm which require standards across customers.

I was not offered any other option. The company has used this tool for years for requirement gathering and maintenance.

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 features that I've found most valuable are organization, trace, connection to other products via external links, and DXL.

It helps us to manage and track requirements for complex products. This allows for quick and easy safety certification.

It needs word processing captioning as well as references within a module.

I've used it for 12 years.

We had no issues with deployment.

There have been no issues with stability.

It has scaled for our needs.

Customer services is great.

Technical support is also great.

We used Interleaf and other tools, but they don't allow for easily readable trace and control.

The initial setup was easy. It's easy to provide access to users.

We implemented it in-house, though it does require basic knowledge of the tool.

We've found that floating licenses work best.

Don't use Citrix or a virtual environment to implement a global solutions. It causes problems when linking between tools.

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