IBM DOORS Reviews

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

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.

The DOORS Application provides object to object traceability, with user flexibility to build their own traceability reports without requiring administrator coding in DXL, XML, java or any other scripting language. In addition, out of the box features for generating baseline to baseline redlines is efficient when reviewing changes.

The documentation of history is automated, making the generation of reports for the change review board simple. I can extract redlines using Baseline Compare between the last approved baseline, and the ‘current’ module, which collates all of this history into a single redline report making change reviews a breeze.

Clean specification generation has become more difficult under IBM’s direction, than it was under QSS or Telelogic. Since IBM acquired DOORS, there have been bugs introduced into the out of the box print capability (Ctrl+P), while they developed a complex printing solution in Rational Publishing Engine. This takes printing out of the user’s hands, and requires administrators or software developers to build templates for generating documentation which makes the job of generating a document a project in and of itself.

I have been using and administrating DOORS since 1998 in multiple different roles, including in Systems Integration, Requirements Management, as well as Engineering Tool Support team member. I've also used v4.0.4, v4.1.4, v6.0 SR1, and v8.3 for requirements management and risk management for medical device development and on-market support.

DOORS has some issues with speed when setup in an enterprise environment. However, DOORS has been the most stable product amongst our engineering tools.

We have been very successful deploying the product to users in Dallas, Chicago, Ireland, Germany and Japan.

Customer service for all of our Engineering Tools has been trending down over the last 10 years, and DOORS is no exception. However, among the biggest of players that we use including Dassault Systems, Siemens, HP, Serena, we have found IBM’s level among the best. I have had direct customer access to the DOORS development team at multiple conferences, who have been able to find resolutions for problems, and have provided enhancement requests that have been developed into the tool over the years.

Prior to DOORS, over 17 years ago, we used a custom Lotus Notes database, but it did not provide traceability or easy reporting.

DOORS is a proprietary database, and it is a simple install of a server and a client, and you are off and running. Very straightforward in the Rich Client environment. It only begins to get complex if you begin setting up integrations using the IBM CLM environment.

In-house engineering tool support team is how we evaluated, tested and deployed DOORS in our company.

The products developed in our company that started with DOORS requirements in the late 90s are now a one billion dollar annual revenue product line. My advice on requirements management in a regulated environment, is that if you try to do it cheap, rather than efficient, your products will suffer during the market phase.

We have evaluated many tools over the years, including MKS, Siemens Teamcenter Requirements solution, and none of have met the ease at which a user can create and customize their own views and traceability reports, without an administrator performing customization.

The most valuable features were the structural flexibility of the documents and ability to specify the type of link between them. It was possible to organize a group of collections within a project, a group of modules together in a collection and a group of artifacts together in a module or a variation of that. Additionally, it was easy to design links to any of the previously mentioned entities in a variety of defined relationships.

This product improved the amount and accessibility of formalized documentation surrounding business processes. It also helped bridge the gap between business and technical documentation requirements which was a priority when trying to rebuild our CRM system using vendors in several different time zones.

In the future, I would like to see a better interactive table of contents or index page that updates in or close to real-time. As the repository grows, it becomes harder and harder to keep track of all the moving parts that contribute to the system as a whole.

I used Rational DOORS for approximately nine months during 2014 on a fairly consistent basis.

The predominant issue that was encountered was connecting Rational DOORs to Rational Software Architect. Although these two products were meant to work in conjunction with each other that never came to fruition. The result was creating a workaround by saving image files that couldn’t be automatically updated and caused the database to time out as the repository grew.

I would not rate the level of customer service and technical support very highly. Response times were high and self-serve help via their website was hard to follow for non-technical users.

No previous solution was used.

The product was being used for developing and tracking new requirements for a system we were working on. There wasn't one specific feature that comes to mind, as it was approximately 12 months ago that I was using the product to develop requirements.

The product was used to better track and structure requirements we were developing for a new product that was to be integrated into an existing system with its own requirements. It was a way for us to track new requirements and its impact on existing ones.

None comes to mind right now. I know that the group was discussing the movement towards model-based systems engineering where they were looking into alternate products that allows the integration of requirements, system diagrams, etc. all in one tool.

I used it last year, for one year.

No issues encountered,

No issues encountered,

I never had to use customer service.

I never had to use tech support,.

• Configuration management
• Requirements linking
• Access control
• DXL5

It enables us to manage our customers' requirements effectively and efficiently.

They need to improve the DOORS change proposal.

I've used it for six months.

No issues encountered.

It can crash, but it doesn't happen too often.

I've not used their customer service.

No previous solution was in place.

We did it in-house, but I wasn't involved.

Use right license model to suit your needs.

Get someone who is familiar with the product to manage

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.