It is my sincere hope that one day, someone who has just been tasked to administer DOORS for their company and who knows nothing about DOORS will come across this entry and think a little bit before jumping in head first.
Merriam-Webster defines a database as “a usually large collection of data organized especially for rapid search and retrieval.” In this sense, DOORS is a database. There is a DOORS server, with organized data that can be accessed by clients.
But just because DOORS is a database, that does not mean that it’s just like every other database. And I’m not talking about the difference between, say, MySQL and PostgreSQL. Or even Access and Oracle. Yes, Access and Oracle are vastly different, but all of the database servers/tools listed above have one thing in common: most of the time, the customers of the data they house never see the structure of the database.
DOORS is different in this regard. It’s a client application that can generate Word and Excel files. Objects can be linked together and users can even create their own attributes. Further, there are many different types of users: Engineers, Managers, Lawyers, Marketers and Testers may all need to use DOORS.
Chances are that you’ve been given the title of DOORS Administrator and are being told to learn DOORS because you’re pretty good at databases. You understand the concepts and have developed tools and maybe even applications that leverage a local database or even an ODBC connection.
If you approach DOORS in the way you’ve approached other databases, you are going to cost your company much more money than they should spend, as well as frustrate to no end the administrator who comes in to clean up your mess.
Telelogic will be more than happy to send a consultant to fix your problems. For a price. And when they hold PAWs (Project Architecture Workshops) the deliverable to the customer isn’t a DOORS implementation, it’s a document of a DOORS implementation with a path forward. And while Telelogic’s consultants will answer your questions, they definitely want you to call on them for support.
I do not mean to sound anti-Telelogic here. Many of their consultants know DOORS rather well and for most projects having a PAW is definitely better than not having one. It’s just that they’ll answer your questions–but you have to know which questions to ask to truly get your money’s worth. They know DOORS and its strengths and limitations, and you know what it is you and/or your management wants out of DOORS.
You can avoid paying Telelogic, and consultants like me, much more money and avoid a lot of pain and frustration if you keep the following paragraph in mind.
DOORS is a PUBLIC database. It is SEEN. It is VIEWED. Changes in where modules are stored are NOTICED. Changes in module names are noticed. The data is updated DIRECTLY, not via a GUI abstraction layer.
This problem is not unique to DOORS. I have seen a few requirements databases in my time run by admins who had no concept of the above. One database had DOORS modules named with acronyms and no description, with no obvious rhyme or reason to most of the schema structure. Modules were named in the context of their path–meaning that there might be 10 SRS modules in the database, and the only way to differentiate them without opening them was to note where in the schema they fell (i.e, which folder contained the modules: this SRS is for subsystem A, while this one was for subsystem B, etc.). Experienced DOORS admins know that there are all sorts of unintended consequences to this type of schema and naming convention. (For those inexperienced admins reading this, try running meaningful metrics that are easy to read with this naming convention. You can differentiate the modules, but your user has to read the entire path to do so.) This naming convention also violates the biggest principle of writing requirements–requirements stand alone and should not need context in order to be complete. But I digress….
If one is new to a project and just got access to DOORS and started browsing the database, would she just know what the HR2D SSDD module represents? Or the CEMT IRS module?
Shouldn’t anyone know before actually having to open the module?
While you may be the DOORS administrator and you may know everything, because you were presumably told to create the CEMT IRS module, other users may not know what an IRS is. Please keep in mind that your users, each and every one of them, are your customers. The database may be yours to manage, but the schema certainly belongs to everyone.
In my next entry, I’ll explain some guidelines that will help new and old DOORS admins alike avoid creating messes they might otherwise make, hopefully saving you time, money, and energy in the process.