IBM DOORS Reviews

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

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.

We capture the requirements of the clients and gain acceptance. We can also review the requirements and adjust further developments as necessary. 

The data logs are ver conveneint. 

The setup is very easy.

It is user-friendly. 

The speed lags based on the server and the remote connection.

They need to provide users with information on what options would be best for their setup. 

The export of the requirements does not allow me to see the linking of the requirements. I'd like to see some sort of visualization or flow chart so we would have an overview from a system perspective.

I've been using the solution for four years. 

You can request licenses if you need more access from more users. 

I've never contacted technical support. The setup is done, and we have cleared the requirements. We've never had any technical difficulties that needed us to reach out.

You can create a whole server inside the project. It's easy to set up. 

I wasn't directly involved with the deployment and do not know how long it takes. 

You do have to pay for a license per person. 

It is worth the money given the market options. There's good compatibility between you and your clients that makes it valuable. 

We are a customer and end-user. 

We have a server-based deployment. 

The solution has some of the most advanced features on offer, which is why we chose the solution.

I'd rate the solution seven out of ten. It can meet the needs of any developer. However, it does lag a bit. 

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

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.

I use DOORS to support my customers, who are heavy users of the tool. I try to figure out what's wrong whenever they have some issues. For example, if they need some help, I use the tool to recreate my customers' environments and work with it to find solutions for them. About 10 people in my company do the same thing as me.

When you install DOORS locally, you have the flexibility to do what you want with the solution. You can add functionality and do many things that you can't do with other tools or do well enough to satisfy your users' requirements. For example, you can save linked versions when you do baselines, and then I can handle linked changes between different baselines. You can't do this with other tools, or it's hard to do.

The web application DOORS Web Access doesn't have the same functionality as the standard client, so it's not a real substitute. For example, web Access only provides writing requirements, but you can't do much more with it. If you want to change multiple attributes or something like that, it's better to use the standard client. I would also like to see some improvements in the reporting.

I've been using Rational DOORS off and on since 2001.

DOORS is stable. I have seldom have problems with it.

DOORS is a file-based data storage system, so it isn't that useful for large user communities. If they want to work with the standard client, it is crucial to have a solid connection between the client and the database software because there's a lot of communication back and forth, so the scalability is not so great. Some of my customers have installations with upwards of 100 clients. 

IBM support for DOORS is helpful and quick. You get a real solution in a short time most of the time.

Setting up DOORS is easy, and I can handle it by myself. The initial installation takes around an hour, but the total deployment depends on your environment. However, you can handle it with a remote install, and installing the client itself takes only a few minutes. 

I rate IBM Rational DOORS eight out of 10. 

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.