IBM DOORS Reviews

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. 

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.  

We use it to manage requirements. For the defense projects, we basically do a waterfall design methodology. So, we input the customer's requirements at the top level, and we flow down through all of the design requirements and the testing requirements. We keep it all managed through DOORS.

Many of our defense customers give us the requirements in a DOOR file, so we can instantly import it. Nobody has to sit there playing with spreadsheets or anything else. In minutes, we have the requirements, and we can begin the flow down to the various levels of the design as we work on it. The thing that we like about it is the fact that it's compatible with what our defense and also space customers use.

I like the way we can simply link requirements with one another and with test descriptions and then automatically produce reports that are required to show compliance to our customers. It is a combination of requirements management and reporting that I like, but I really have very little to do with the reporting part of it. I don't know how easy or hard it is to create those reports.

One thing that I would like to see is a lower-cost version of it that we could use for smaller projects. Sometimes, we do projects for commercial customers who would benefit from something like DOORS, but it's just so expensive. It's just a monster, so a lower-cost version would be the thing that we'd like to see.

I have been using this solution on and off for about eight years.

It is incredibly stable. We've never had a problem with its stability.

In the projects we've done, we've never bumped into a limit where we needed to do anything to accommodate the project. It just works. So, we've never had to scale it.

In terms of the number of users, we're limited to about three people who use it, and they're all hardware and software engineers. 

It is being used extensively. We use it every day. We could apply it to other things. If there was a lower-cost version of it, we would probably use it more widely through our projects, so that's really more a function of the cost of the product than the usability of it. 

I didn't have any encounters with them.

DOORS is the only system we've used for this purpose. In other cases, we create massive spreadsheets that have links in them and are completely unmanageable, but they do the work.

I wasn't involved in that.

I don't personally know what the numbers are. I just know that one of the reasons we've limited it to three seats is a function of cost.

I would rate IBM Rational DOORS a 10 out of 10. The main reason is that it's what our customers use and what we've been using for many years now, and I don't see any reason to change, frankly.

We used DOORS to elicit and gather user needs and then document them. We would then document these needs with diagrams and pictures that could be used to implement products and tests. We also used it for traceability purposes.

System engineers, software requirements engineers, software development engineers, software manual test engineers, software automated test engineers, software DevOps teams — these were the people who mainly used this solution.

We went from an ad hoc Word document to a table-driven model that could be reviewed without submitting any documents. That was a big help.

This solution is the Cadillac of similar solutions. I liked that we could export to Excel and Word. We could also link to other off-shelf tools.

Compared to other tools that I have used over the past 20 years, DOORS is the best of the best. It's expensive. It's a heavy-duty tool. 

It would be nice if it could be scaled-down so that it could be installed and implemented without much learning or training. That would also make the price more attractive.

You have to pay the premium price, but if you're a startup company or a medical device company, you'll want to create traceability immediately. It's actually simpler to use it straight out-of-box. It requires a lot of administrative work. The initial setup is not very easy — at least on-premise. A lot of training is required. It should be easier to use. 

I began using this solution in 2000. I used it at my old company; I don't use it anymore.

This solution was very stable. It took our staff a while to transition from previous technology to DOORS. Otherwise, the tool itself was very stable. In the end, people saw the difference. Especially when it came to traceability from the system requirements to the product requirements, to the software requirements.

The technical support was very good. Better than Microsoft.

An implementer did the initial installation. Based on what I heard, it's not easy to install. I don't want to say it was complex, but it wasn't very easy either. It's not just like installing  Word or Microsoft Office — it wasn't that easy.

We were a big organization complete with different teams. There were some disagreements on how the tool should be set up, how the traceability should be set up, etc. These discussions delayed the delivery or the final implementation. Otherwise, it could have been set up quickly. A lot of customers made it much harder. 

Overall, on a scale from one to ten, I would give this solution a rating of nine.

IBM DOOR is the best tool you can purchase; it's the Cadillac of all tools. Don't be scared of its vast amount of features. Use only what you need, and don't panic about the complexity or the completeness of the tool

We had a large number of requirements coming in as a federal contractor and we put them in DOORS. We did exports from that to map those requirements to what we were doing and the architecture that we were building. We did that in MagicDraw, which we attempted to integrate with DOORS.

Being able to track changes to requirements and being able to export is the solution's most valuable aspect.

Starting to use the solution is pretty straightforward. There isn't too much of a learning curve.

I found the user interface to be unintuitive. It's something they need to work on. I wouldn't say it is bad, per se. It is just like learning to write cursive.

I would push for more extensive integration with other tools since, for example, I needed it to integrate with MagicDraw. Building in that type of integration and other such integrations would be helpful for our purposes.

There could be a better structure around onboarding to get people started. It was unintuitive as to how to get started. It needs to be clear as to what the first things a user has to do in order to get going. 

There needs to be quicker access to tech support. When I have a two-minute question that takes two minutes to answer, it shouldn't take me 45 minutes and/or a few days of callbacks to get to the right technical support person. It's unnecessary and frustrating for the user.

I've been using the solution for about two and a half years so far.

I don't recall any issues with stability, at least no more issues than anything else has. It's not buggy and doesn't suffer from glitches. I can't recall it crashing or freezing. It's pretty reliable.

The solution seems pretty scalable, from what I have seen.

In our organization, we have about 25 people on the solution currently. We've extended slightly. I believe we have at least 50 licenses out there that can be used.

Technical support is okay. I would say it took a long time to get to the right person. That said, when I get to the right person, I found they were helpful. Overall, I'd say that their support could be faster and more responsive. They tend to be slow to react and hard to reach.

From my point of view, I didn't do the initial setup. However, from the moment I started using it, I found it to be straightforward. 

I'm not sure how long deployment takes.

I was not aware of anybody outside the organization coming in to handle the implementation, however, that doesn't mean that someone on the IT side didn't have that. I'm unsure if we had outside help.

I don't have much information about pricing. I do know that our organization bought more licenses than we need, however, so we can easily add more people to the solution when we need to.

Although I cannot say with certainty, I do not believe my company has a business relationship with IBM.

I do not know which version of the solution we are currently using.

I would recommend the solution to other organizations.

Overall, I'd rate the solution seven out of ten. While it's largely helpful, there are just a few things, like unresponsive technical support and difficulty with the general learning curve, which could make it more user-friendly.

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.

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.

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.