Article Corvis And Telelogic/'s Excellent Adventure With Docexpress ...
Article
Corvis and Telelogic’s Excellent Adventure with DocExpress/Factory
August 15, 2002
Cliff Sadler, Director of Business Development, and Product Manager for DocExpress,
Telelogic
Corvis and Telelogic's Excellent Adventure with DocExpress/Factory
Introduction
This article will describe the issues overcome by Corvis Corporation for creating and
maintaining requirements documentation for the world's first multi-band switch, the
CorWave OCS by using Telelogic DOORS, and Telelogic DocExpress. It will explore the
techniques used to fully automate the process of data-mining across the more than 38
functional domains and subsystems that comprise the CorWave OCS. The techniques
presented in this article should be applicable to other DOORS customers as they look to
automate their document generation.
Architectural Implementation in DOORS
Corvis decided that the best approach to managing requirements that may be reused
across products was to divide them into functional areas, and have separate DOORS
modules for each of those areas. While simplifying the management of functional areas, it
did present a challenge of how to create a single document that represented a particular
product, or feature of a product when the actual requirements were stored in many
different modules. In fact, this issue was compounded by the fact that the development
teams needed separate requirements documents for each area as wel . This currently
translates into some 40 documents that need data from over 50 modules to be combined
into a single, transportable document in Microsoft Word.
Telelogic DocExpress bridges the gap
In December of 2000, Telelogic acquired ATA, Incorporated, who are the inventers of
DocExpress. This product has been in the industry for many years, helping organizations
promote consistency, accuracy, and automation to the process of generating
documentation for engineering use. DocExpress was evaluated by Corvis, and it was
determined through a proof of concept, and prototype, that with some customization, it
could perform the daunting task of building so many documents from such a diverse set of
modules, and yet remain flexible as their project data changed. The customization would
revolve mainly around automating the maintenance of setting up new documents, and
build instructions as the DOORS database and Corvis product lines expanded. Telelogic
Consulting Services was brought in to assess the data's architecture, and then make a
recommendation on a solution for their situation.
Automation requirements
Each module in DOORS is arranged functionally to cover some aspect of hardware or
software as it applies to a given product. The applicability of a given requirement to a
piece of hardware, software, or other is captured in a multi valued DOORS Attribute. This
way, a given requirement can be assigned to more than one aspect of the product or
release. What emerges from this arrangement is the need to know what all of the different
modules are for a given document, and what particular attribute value Corvis is looking to
create a document for. Both the number and name of modules can change, as wel as the
list of attribute values, and the frequency in which they are found.
To try and execute this manually would require nearly as much work as maintaining the
requirements. Plus, it could be an error prone process with potential misspellings, or
missing newly added and subtracted items. A plan was adopted to extend the functionality
of DOORS via a DXL script that could query the modules in the project, and build up the
necessary files for DocExpress document builds without user interaction. This script would
create a list of DocExpress Variables based on the different modules available to get data
from, as wel as build all of the individual control files for enabling DocExpress to access,
select and format the appropriate requirements info.
Final y there was a requirement to put this into a "fire and forget" environment by setting
up Windows Task Scheduler to control when document builds were to take place. This
would allow Corvis to run the builds during non-peak hours to minimize network traffic.
