DOORS 9 – Page 3 – CiGi Technology Limited

Project Wide Information Structures

Example of a Product Breakdown Structure

It is very common practice to introduce a hierarchical breakdown of a project according to the products or systems. This is known either as a Product Breakdown Structure (PBS) or System Breakdown Structure (SBS). There are a number of ways to introduce this into the DOORS database. You could use an attribute in every module with an enumerated list containing all the PBS values. The disadvantage of this approach is that when you have to make a change to the list (and this is more common than people think) then the type has to be changed in every module. Whilst this is easy to achieve using the Module Administration tool (see Module Administration utility), the second disadvantage is that you cannot actually see a hierarchy in a flat list of elements. You also cannot see a combined list for all modules. So, if you wanted to see requirements allocated to System X then you would have to search all modules and somehow collate the results together.

A more effective approach is to build a PBS into a standalone module. This has a number of advantages:

The hierarchy is immediately obvious;
The list can be easily changed;
The item can have additional attributes such as a description;
By linking requirements to items in the PBS it is possible to display the values as a DXL attribute; and
Most importantly, by viewing the requirements from the perspective of the PBS you can see the impact of making a change to the PBS– before making the change. Impact analysis is greatly enhanced.

The principle can be adopted for any hierarchical list. For example, hazards can be broken down into causes.

Example of a Verification Breakdown Structure

The same principle for a PBS can be applied to a Verification Breakdown Structure (VBS). In fact, using DOORS as a relational database, it can be applied to any form of enumeration (Organisation Breakdown Structure (OBS) or Work Breakdown Structure (WBS) although over-use can result in spaghetti-like links.

The Verification Methods would be defined in the Verification Breakdown Structure, or its equivalent, and therefore it is very easy to identify all requirements that will be affected by a single Verification Method by looking at all the links from the VBS module. This permits the use of multiple Verification Goal modules structuring and ordering the Verification activities according to operational rather than functional needs. This approach makes the generation of the Test Procedures/Test Schedules very controlled as the modules provide the framework.

Another point to note is that there should always be a strict data model enforced within the database with reserved words for the link relationships. More details on how CiGi Technology can help you produce a data model can be found in Consultancy Services.

DXL Attributes can be used to show the results of the link.

Example of the use of References/Evidence Lists

It is commonplace to see in a requirement statement the phrase “in accordance with xxx” where xxx is the title of a reference or “ … in accordance with Reference nnn” where nnn is a unique number assigned to a reference. How is this managed in DOORS so that the references are controlled and that any change is propagated through the whole of the project?

In particular, it is very important to know the issue or version referenced from a requirement as any change in content may significantly affect a requirement and initiate an impact analysis (that determines what would be the impact of changing a reference). Unfortunately, there is nothing readily available in DOORS Classic that can help.

However, what we can do is to build a reference or evidence list. A reference list would contain all the documents that are referenced by the requirements. As well as the mandatory attributes such as the document reference number, title and version/issue we could add additional information such as the document type, who authored the document and when it was issued.

The question of what requirements would be affected can be automated using DXL to provide the identification of where it is used. Thereby considerably reducing the amount of time that the management of external and internal referenced documents would take for an organisation.

An evidence list has similar properties but it is used to identify documents external to DOORS that are used in the evidence trail. For example, Standard Operating Procedures, Test Cases, Test Reports etc.

Additional attributes may include Verification or Validation identification and external hyperlinks to a document repository. The important thing to note is that the traceability from evidence to the requirements is continuous.

In these examples we are using an internal repository module/table. We could have alternatively used direct traceability links such as provided by Open Services for Lifecycle Collaboration (OSLC). Support on OSLC synchronisation to external document repositories such as Aconex, Documentum or TeamBinder is also available.

Example of the use of Abbreviations

It is extremely useful if Abbreviations are defined either at the Company or at the project level. This will prevent misunderstanding if the same abbreviation has different meanings on different projects. An example of this could be ‘PBIT’ which could mean either “Power up BIT” or “Periodic BIT”. A misunderstanding in the use of this term between teams could lead to totally different functionality resulting in significant interface issues and rework.

In this type of implementation then a sophisticated DXL Attribute is used to display the ‘Where Used’ values – there are no links involved.

It is interesting to note that this functionality is already available in DOORS Next.

Example of use of a Glossary

A data repository is always needed because words can have different meanings in different contexts. They also can be highly specific:

Identification – A user (person or system) must supply an identifier and/or the system must in turn supply an identifier to the user so that the user knows that he is accessing the right system.
Authentication – The identity of the user must be authenticated (i.e., verified so that we know that the user is who/what the identifier is associated with). That is, authentication is the verification of the identity assigned during Identification.
Authorization – Once a user has been identified and the user’s identity has been authenticated, the user can use the services and access the data that the user is authorized to use and access. This can be done by membership in a group or done on an individual identifier basis.

Use of italics and/or Capitalisation of a word is often used as a means of indicating a glossary item, so that it is clear to the reader that it is not just a word in a sentence, but it has a defined meaning. A parser can now check the specification for undefined terms.

A glossary in a requirements specification, and which is project wide, is absolutely essential as it provides the precise definition of all terms.

In this type of implementation then DXL Attributes are used to display the ‘Where Used’ values – there are no links involved. As with the Abbreviation terms, then this functionality is already available in DOORS Next.

For information on a DXL Script that pulls all these features together then click here.

Simple Scripts – DXL Attributes

The uses for DXL attributes are enormous. They range from showing the specific content from links, or multiple links, or multiple hops through links, calculated values, filtered values etc.

Layout DXL can be easily generated by a user with the inbuilt traceability wizards. Primarily for performance reasons, Layout DXL should always be converted to a DXL attribute (again using the DOORS inbuilt functionality). But there are other advantages:

Although the code of a DXL attribute can exist within a module it is more commonly referenced to an external include file. This has the significant advantage of reuse. If a script is located in the addins folder then once that file is modified the changes are instantly propagated to all modules that use this attribute ensuring consistent use across the project. Of course, you only have to make a single modification.

You can even have a single include file with all the required functions embedded within it.

For example:

Example of a DXL script containing multiple DXL functions

This has the advantage that common functions for displaying text from buffers are all in one place.

The DXL attribute then consists of an include to this file and then a call to the appropriate function.

Example of a Project Menu

It is very simple to add custom menus for both the top level database menu (for project wide utilities) or for the module level. However, it is very important to ensure that the utility is added to the correct menu so that the two types of functionality are not mixed.

This is an example of a global type menu:

This menu can be added in two ways. The first is by the use of .idx files which are simple textual lists of the menu which are interpreted by DOORS or secondly by DXL scripts which use the DXL functions createMenu (), createItem () and separator().

The menus can also be used to directly launch help documents so that they are readily available to the users. No more searching through the team SharePoint site hunting for the training manual… It is available at the click of a menu.

This is particularly useful for user guides, data models and training material. Word, PowerPoint and pdf document styles are already embedded within our generic DXL script – and the list can be readily tailored for your project. For example, you could add work-flows displayed in Visio.

All of CiGi Technology utilities have additional protection so that project wide utilities can only be run from the main menu and that only module level utilities can only be run from within a module. There can also be protection added so that only authorised groups can use either the complete utility or specific functions within the utility.

History Viewer

Although it is very easy to see the changes since the last baseline. Paradoxically one of the hardest things to do in DOORS is to find the history of changes through all baselines. You have to open all the baselines manually and then go to the right object and then open the properties. And then sometimes combine them.

And what if you wanted to easily see what was changed, and by whom, for specific attributes. DOORS has all the data but how do we get to it?

This very easy-to-use utility solves this problem. It searches through all the history records for all baselines in the module. Once the data has been gathered, then you can then data-mine the results in many different ways, and where possible show the differences in the standard ~~deleted~~ and added Rich Text formats.

The sophisticated navigation functionality allows you to rapidly move through objects and even synchronise the viewer to the current object.

Compare with Baseline Viewer

The need to understand the changes between the current version and the last, or even between any version, is very common. This utility simplifies this need by displaying all the previous baselines in a module and allows the user to select a baseline to compare with.

Screen to choose the previous baseline for the comparison

It then produces a view showing the differences to the selected baseline (Note that this image is deliberately fuzzy in order to protect the contents).

Results of comparing the current module with the selected baseline

Text Box Metrics collection

This utility will collect metrics from multiple modules rather than just a single one. The modules within a project are displayed and are then selected manually. The values collected from the modules are displayed in a text box, separated with tabs.

The values can be copied directly into an Excel spreadsheet where they can be analysed and displayed in a graph or pie chart using Excel tools which are ideal for management summaries.

Metrics and Status Graphical Utility

The Metrics and Status Tool automatically calculates the traceability, review and verification status of all the requirements for a specific module.

It’s a great way to direct the user to the work required.

The status is represented as a traffic light system. Each of the view buttons apply a predefined filter to the module to only show the requirements with the specific value. For example, the user can select the View button to display the 315 objects that do not have the necessary traceability in place, so that the links can be added.

The values can also be directly exported to Excel using the Save Metrics button where they can be analysed and displayed in a graph or pie chart using Excel tools which are ideal for management summaries.

Module Administration

The management of modules, copying of views and attributes are all essential tasks for a database administrator and yet there is no in built functionality in DOORS Classic that lets you do these simple tasks.

This utility brings together all administration type functions. It works both at the project level – allowing you to manipulate modules – and at the module level which provides access to attributes and views.

Project Level:

The utility is opened via the DOORS main menu. It automatically determines the current project folder based on what is open and/or selected but the user can navigate to any other folder.

It then lists the module names within the project. Selecting a row will display the description and the prefix. The attributes or views in the selected module are also automatically listed. There is a further filter for attributes into normal, DXL or Module attributes.

Double click on the row and the module is opened but you don’t have to open the module in order to work on it. All operations take place in Read only mode unless a save is required in which case the utility takes care of this, checking for locks etc.

The box at the top displays a running display of the success or failure of any operation.

There are a number of operations that the user can perform such as loading up a standard set of attributes from an XML file which is great for pre-populating a module.

The user can also delete attributes or views for a selection of one or more modules at the same time which is extremely useful for making changes to all modules across a project.

The Project Report button produces an Excel report of the views and attributes for all modules in the project.

A DXL utility to manage modules within a project in DOORS 9.x — *Module Administration – Project Level*

Module Level:

The same utility also works at the module level where the user has access to shareable edit, and can manipulate attributes and views. For example, delete one or more attributes, convert all ticked DXL attributes for the current module into text or delete one or more views.

Attributes can be copied to other modules (with the relevant checks that they do not already exist in the target module) but perhaps the most useful is the copy view function where a selected view can be copied to one or more modules. This functionality is not easily performed in DOORS Classic.

There is also a button to reset all private views in a selected module into global access views.

A DXL utility to manage modules attributes and views in DOORS 9.x — *Module Administration – Module Level*

Managing Users and Groups

Although DOORS permits the database administrator to set up groups, unfortunately there are no in built report functions that let you understand, for example, which users are in what group, or the permissions a particular user has in a module.

This utility provides the DOORS database administrator with a series of very comprehensive reports. Most of the reports are simple text lists, displayed in the text console, with the data separated by tabs so that it can be directly copied into Excel.

A few of the reports ( marked with an (E) ) are very sophisticated and will export directly into an Excel worksheet including coloured backgrounds for specific functionality. Some of the more important uses are as follows:

Provide a list of the Users for ‘cut and paste’ into excel;
Provide a list of each group and the members in Excel;
If emails have been entered then provide a mailing list;
Extract the RMCDA access permissions for Users, Groups in each Module.

A utility to provide a listing of all Users and Groups within a DOORS database

The Excel listing of the groups and the members is worthy of specific mention as it is extremely useful in large projects where there are hundreds of users and groups. Here is an example listing:

An Excel output generated from all Users and Groups within a DOORS database. Groups are listed across the top and there is a row for each user. Details of the user are listed and ‘X’ identifies whenever a user is in a group.