Managing requirements for even a simple project is a nightmare. As projects get more complicated, "requirements management" mutates into "systems engineering". The requirements for, say, an entire IT migration, or an automobile, or a lunar lander turn into a tree of requirements, where each implementation step is traced back to an overall master requirement at the root of the tree. Five to one, your average project isn't this complicated, but you don't want to ship a product missing features and have to say "it slipped my mind".

Enter a certain large vendor's Dynamic Object Oriented Requirements System (DOORS). Doors allows the requirements for a large, complicated product, to be organized into objects which are further organized into modules, where each object is a requirement, paragraph, section, table, figure, or anything that explains the nature of requirements.

Greg L's team adopted DOORS for managing their requirements. Unfortunately for them, DOORS stored all its data in a proprietary database. If you wanted to automate anything in DOORS, or even if you just wanted to say "show me this requirement, its siblings, and all of its ancestors", you needed to learn the Doors eXtension Language (DXL).

DXL was not the kind of language that would make you get up and dance. No, it would make your average developer an unhappy girl.

For example, if you wanted to access the currently opened object, you could use the keyword current, but current was only available when using the assignment operator. You could assign to (and from) current, but not do anything else. Unless you're in a loop. Then it's fine.

Property names on objects were allowed to have spaces, and many of the default properties did, so get used to writing o."Object Text" = "some text".

Speaking of spaces, a single space was the concatenation operator. So, this would be one way to print out a list of variable values: print i " " r " " s " " d " " b "\n". It's also worth noting that non-string variables, like integers, can't be printed out unless they're converted to strings, which can be done via concatenation to an empty string: `print i " "

Strings are also stored in a global string table. Each time you create string literals the entire literal ends up in that table and will live there for ever, so if you keep building strings incrementally, you'll very quickly fill up that table and crash the application with an out of memory error.

Why is it like this? Well, we could say that people are strange, but the reality is that DXL was the kind of thing one employee invented to make their work easier, and then management and customers got wind of it and demanded that it be included in the product.

Once there was an extension language, internal developers had to use that extension language, which means many features in DOORS were implemented in DXL. That includes the very obvious feature of "export your requirements as a human-readable word document".

I'll let Greg explain:

At some point in the application's lifetime it became apparent that users might want their requirements documents exported to Word or Excel. They could have implemented this by adding a feature to DOORS, but instead the vendor chose to provide some DXL scripts for this task. This required thousands of lines of DXL, most of which is poorly formatted and not commented in any way. If you have the misfortune if needing to tweak it (as I did) then you will find this little gem at around line 335:

// insert some text
    // cycle through styles
    // delete the text
    /*
        We have to go through this sorry farce because Word in it's infinite wisdom
        keeps track of whether or not styles have been used.  If they haven't, and
        some text is pasted in in a style which has the same name as one which already
        exists, then the style is updated to match what is in the clipboard, rather
        than keeping it's own formatting properties.

        The last thing we want to do is overwrite styles in the current template,
        so we make sure that they are all used before we start
    */

This comment doesn't explain the whole logic, but it hints at the awfulness involved. DXL was not used to create a Word document directly. No, it used the Windows copy/paste buffer and COM+ automation libraries to interact with a running Word program directly. So it was all hacks: throw text in, use all the Word styles, and then delete the text (to enable all the default styling in Word), then lock the copy buffer, and spend the next few hours copy/pasting from DOORS to Word. And yes, it took hours for this job to run, and it ran on your desktop (since it needed a running copy of Word), which meant you couldn't use copy/paste for the duration of the run.

Greg adds:

After four years of writing DXL (and re-writing what was provided by the vendor) I eventually moved to a different job, where I am able to "conveniently forget" that I know anything about DOORS and their nightmare of a language.

Tell all the people that using DOORS isn't a walk down Love Street, but at least Greg was able to break on through (to the other side).

[Advertisement] Keep the plebs out of prod. Restrict NuGet feed privileges with ProGet. Learn more.