DOORS Baselines – CiGi Technology Limited

Module Compare

When two companies are using DOORS and need to exchange information then the requirements are often provided from one company to another by means of DOORS module archives (.dma). This means that the version that you have been working with your own changes is now superseded by a new module.

You may also have used modules as separate baselines or as variants whilst trying out combinations of requirements.

So how do you identify the differences between the versions before you update your module? A comparison of 2 modules is part of classic DOORS but it works by comparing text, attempting to match similar text. Unfortunately, if you have a lot of commonality in the requirements, then it will match, (apparently at random) completely different requirements and give totally incorrect results.

This wizard based utility solves this problem by using the DOORS Id (which is constant between versions) as the key. Note that it can be adapted to work with other data models which use other attributes as a key by simple DXL changes.

The start screen introduces the utility. Notice that it has been designed more or less along the same lines as a DOORS wizard. Some introduction text on how to use the utility is displayed. The script automatically checks that the user is part of a group that can run the utility. This allows the utility to be placed on a generic DOORS menu.

Module Compare Wizard – Identification screen

The second ‘Identify’ step allows the user to identify the two different versions of a module. A log file is always created, and the user will also determine where this log file will be saved. This log file will contain the result of the comparison and can be examined by any text editor. This is very useful when the comparison is of modules that contain thousands of requirements

As well as the comparison matching the requirements, authorised users will have the ability to permanently create links between the matched objects so the associated link module can be optionally added in this screen. Normally this is set to ‘compares’ and links will be automatically created via this link module to link matched requirements.

The ‘Next’ step performs the comparison and shows the changes between the 2 modules.

Selecting a specific ID will show the Old text, the New text and the difference using the standard colours and fonts. Objects that contain graphics and pictures are ignored. If the right attributes are present in the new module, then comments can also be added.

For modules that contain a lot of requirements, then filters can be applied.

Metrics such as the number of requirements are also displayed for both versions of the module.

If a user has the necessary privileges, and if the link module has been defined, then once all the objects have been examined and checked then permanent links between the matched objects can be established.

Document Manager

In almost every project I have worked on there is a need to export the requirement set into Word as a requirement specification and get it reviewed, approved and distributed. And in a lot of cases that is how the requirements arrive; as a requirement specification that has to be imported into DOORS.

When importing or exporting then the front pages of the Word document are not part of the requirements – or at least they should not be. The requirements module should only contain the requirements and not the front matter. Where does all that information go? You also need to correlate the document versions with the module/project baselines. So how is this done?

The contents/index can be easily generated in Word but maintaining the version history, the reviewer and the distribution data is not so easy. Yes, you could put this in as ‘Information’ in embedded tables at the front of the requirements, but this is messy to edit. You could even have a separate module for the data and link it in on the build. But this makes life more complicated.

By far the simplest way is to store this information as module attributes. Clearly a DXL utility to extract, display and edit these module attributes is going to be extremely useful.

This DXL Utility is extremely comprehensive and has been designed to manage all aspects of document management from within DOORS ranging from document issue, performing baselines and export to PDF.

Firstly, you select the document number- as this tool allows different documents to be exported from the same requirement module – so you could export a requirement specification, a VVRM matrix ( pulling in linked data from the test cases and even test results) and an interface specification ( filtered on interface requirements). Then select the version or issue of the document (as matched with the module baselines). What is then displayed is the document title, additional document information (which can be tailored for your company), the names of the document signatories and the document distribution record. Often this information is the same for each document and version, but it can be modified for any combination.

Depending on the user group access then these fields can be either read only or editable (in the former case the Edit button is disabled). They can also be locked down if a document is published.

What is also displayed in the lower part of the screen is the document change history and a series of buttons.

The buttons allow the creation of a new document (which is how the module can used for multiple documents as described above), creation of a new issue by execution of a new baseline (major or minor), or the generation of a pdf. This latter operation is an export using LaTex functionality and it will use all of the information above, plus a predefined company/document template containing the company headers and footers to build the complete document. As an alternative this could be linked to Rational Publishing Engine.

Before the document is produced the user can also enter the pdf file name and location and whether change bars are required.

The Working Copy entry is for when a document is needed to be exported for review but not as a formal issue. In which case the document is water marked as Draft or For Information Only.

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