Tricky DOORS 9.3.0.7/RPE Bug with DOORS Tables

Posted by on Oct 7, 2012 in DOORS, Rational Publishing Engine | One Comment

Friday was not a fun day for me. I had to troubleshoot a bizarre issue with Rational Publishing Engine. Anyone who has worked with RPE knows that while it’s a very good tool, troubleshooting document errors is a long process that can absolutely test every ounce of patience you have.

The issue in this particular case was that in certain modules, an extra heading would be added to a table. This did not happen in every module, which seems to point to not being an issue with the RPE template (a .dta file) but rather with the data of the table itself. The problem was that the tables appeared to be identical!

Reproducing The Problem

I’ve been able to replicate the problem in Word 2010, DOORS 9.3.0.7 and DOORS 9.4, and RPE 1.1.2.2. Here’s what to do.

Create a new Word Document. Put a table in it. Here’s what I did. You can click the number next to each photo for a fullsize view.

Export from Word to DOORS

Initial Word Document

]1 Initial Word Document with Tables

Exporting to DOORS

]2 Exporting to DOORS

New DOORS Module

]3 New DOORS Module based on Word Document

Okay, everything so far looks good. Let’s export with RPE. I’m going to use the doorsData.dta file that comes with RPE just for demonstration purposes.

doorsData.dta

]4 doorsData.dta

Let’s do an export and look at our output.

Extra Table Heading!

]5 Where did that Table Heading Come From?

The red arrow shows an erroneous heading! What’s going on here? I didn’t put that there. Those italicized Table captions comes after each table, and that’s controlled by the .dta file.

Troubleshooting The Problem

I could write lots of paragraphs here boring you with everything I tried. I’ll tell you this to speed things up: I tried multiple .dta files and multiple DOORS modules and the results appeared consistent between modules. What I mean is, one module would consistently output table headings and one module would consistently not output table headings, regardless of the .dta file used to export. Strange indeed. I’d look at random table cells in each table and they all looked identical.

I know what might work! Inserting a DOORS Table into a module that was behaving like this. So that’s next.

Creating another DOORS Table.

]6 Creating another DOORS Table.

Now we export again and check the results.

A tale of two tables.

]7 A tale of two tables.

Ok, so it’s not a module-by-module basis, it’s a table-by-table basis on which this error occurs! I’m stumped. The only thing I know for sure here is that it is not a .dta problem. It appears that tables captured from Word documents behave this way, while tables created in DOORS don’t.

I talk this problem over with a colleague and she tells me that there are other modules that are exhibiting this behavior. She did a little research and ultimately determined the problem.

DOORS Tables (Suck)

If you are a religious person, and you use DOORS, you must believe that DOORS Tables are a tool of the devil. When I train people in DOORS, I explain that having tables in modules is not just a DOORS issue, it’s a requirements management issue. Tables can make it easy to digest information, but they can also obscufate requirements. Is each cell a requirement? Each row? A combination of rows? The entire table? Since the purpose of requirements management is to make requirements clearer, tables go against the very nature of effective requirements.

Over a decade ago, Telelogic had a problem. DOORS did not support tables. Their clients were demanding table support, so some designer came up with the idea to “hack” DOORS objects and make tables consist of these hacked DOORS objects. Each DOORS table has an “invisible” table header object, and each row has an invisible row object. Why did I put the first “invisible” in quotes? Well, because you actually can see these invisible DOORS table header objects, under the correct circumstances. How?

Click View->Show->Table Cells. It’ll likely be checked when you see it in the menu. Clicking it will uncheck this option.

How to view invisible table headers

]8 How to view invisible table headers

Ok, now that you’ve done that, you’ll see objects that appear to have a Heading of > > Table. Like so:

Invisible Table Headers!

]9 Invisible Table Headers!

So now that we can see these table headers, I can now get to the properties of the invisible table headers. TBLISSUE-6 represents the table where the problem is showing up. I right-click the object and choose Properties and am presented with this!

Here's the problem!

]10 Found the problem!

This table header object has an Object Heading of Table! Where did it come from? The Microsoft Word export process now sets the Object Heading of each invisible DOORS Table Header object as “Table”, thus putting a bug into every single RPE template that deals with DOORS data!

The only way I can think of to fix this, for sure, 100% of the time, without affecting data in any of your modules is to remove this Object Heading from each DOORS table exported from Word. What a pain! But let’s do that and see what happens.

Problem solved, for now.

]11 Problem solved, for now.

Thoughts

I wasted almost an entire work day trying to troubleshoot and solve this issue. I’m not very happy about this, and am posting here in order to help others who may encounter the same issue. This fix was not at all obvious and even the problem occurs sporadically.

I read the release notes for each DOORS release I implement and I either completely missed this change to DOORS or more likely, this change was not documented. It’s also angering, because as a user, if I want to put Object Headings on my invisible Table Headers then I will do so. Also, the latest RPE sample files do not reflect this change, as demonstrated, so in my opinion, the DOORS developers introduced a bug into RPE!

Even more frustrating is that I’ve entered PMRs and RFEs for DOORS behavior that I believe are outright bugs and they get ignored outright or I have to justify changing them because of how much they cost my clients. Yet stuff like this happens with no warning and my clients eat the cost of me and others trying to figure out what’s happened here.

Friday I announced on this site that Baselines Incorporated is now an authorized reseller of IBM Rational Software. I stated that I would ensure that the content of this site along with my opinions would not be affected by us selling IBM Rational DOORS and Rational Publishing Engine and the like. The bad news is that this bug exists at all, but the good news, for me anyway, is that I got to prove that I am a man of my word.

I sincerely hope this article helps people save some time in the future and that IBM fixes this issue in a soon-to-be-released future release. In the mean time, a PMR/SR has been entered and I am engaging my IBM representatives about this horrible change.

1 Comment

  1. Baselines, Inc. » IBM Technote on Imported Word Table Captions
    October 24, 2012

    […] wonder if my last post had anything to do with […]

Leave a Reply

You must be logged in to post a comment.