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).
More than five years.
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:
- 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.
- All users are trained in how to use the basic features of the tool.
- 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
I have experience of DOORS In distributed teams using remote access, Of course, access to the server must be carefully setup (ass the access to DOORS DB itself) but this solution works well.