Don't slam the DOORS! Finding the handle to IBM Rational DOORS
Having worked with software tools for a number of years, I understand that they all have their own personalities and quirks. It is always important for users to be formally trained in the use of the tools they use within their organization; however, in today's business climate not everyone has that luxury.
In this new blog series, I will look specifically at IBM Rational DOORS and describe what users should be aware of when they first approach the tool from the perspective of a requirements engineer.
In this first part, I will be looking at some of the fundamental characteristics of Rational DOORS and the basic terminology you need to know to get started using it. This will serve as the DOORS “frame” for subsequent blog posts.
Rational DOORS has its own database, which can be broken up or structured based on the needs of your organization, process or project.
All items in Rational DOORS have access controls that can be set for a user or for a group.
Rational DOORS maintains history information for objects and modules.
Objects: The DNA of Rational DOORS
Rational DOORS manages its basic information in containers called objects.
These objects usually contain information about requirements, but they can also contain information like the following:
· Embedded documents
Note that objects do not have a specific type; they just contain different types of information.
All objects have a unique number within the module called the "Object Identifier." This number never changes, even if the object is moved. If the object is deleted, the number is never reused within the module.
Links can be created to and from objects. By default, links can be created between any two objects in any direction, anywhere in a Rational DOORS database. Links are usually referred to as either “in links” or “out links.”
Modules: Documents ain't what they used to be
Objects are contained in (formal) modules. Modules are the Rational DOORS equivalent of a document.
Objects in a module can be organized in a hierarchy. For example, an object can be the parent of zero or many child objects.
Modules have views that define what information is to be displayed. Views contain:
· Columns: These usually display attribute values. However, they can also display dynamic information.
· Filters: These control what information is displayed based on specified criteria.
Attributes: It all hinges on these
Objects all have properties, called attributes, which can contain additional information for supporting your organization’s requirements process. By default, objects have some basic attributes. However, new attributes can be defined as needed.
Modules also have attributes that can contain additional information to support your organization’s requirements process.
Attributes for objects and modules are defined on a per-module basis. Rational DOORS does not support the definition of "global" attributes.
Each attribute has a type, which dictates what information can be stored within it: text, integer, Boolean, date and so on. Allowed attribute values can be restricted to ranges or be specific values that are specified as (enumerated) lists.
Folders of projects or a project of folders
Modules cannot exist at the root level of a Rational DOORS database, but they can be stored in folders or projects. Projects can contain folders and vice versa. The difference between the two is that projects and all they can contain can be backed up or archived; folders on their own cannot.
On its initial setup, Rational DOORS has no folders, projects or modules.
So now that you know where the DOORS are, how do you walk through them? And more important, what's on the other side?
In the next blog post in this series, we will look at how data is structured inside the tool. To learn more about the basics of IBM Rational DOORS, check out this YouTube video.
If you would like to discuss further, then please contact me on Twitter @ChrisHardy_68. And don't forget that if you ever need guidance or extra help, IBM