↓Skip to main content

Entreprise-scale requirements release tool

·3 mins
Requirements Management IBM DOORS DXL PowerBI SQL Server Problem Solving Automation V-Model Systems Engineering Automotive ASPICE Process Optimization Enterprise Automation Safety Critical Traceability Workflow Automation Engineering Tools Software Engineering
Table of Contents

Enterprise-Scale Requirements Release Automation tool for IBM DOORS using DXL #

Problem overview #

In a previous automotive project where I have worked in the past, the specifications release process inside of IBM DOORS (the tool used for requirements management) was a critical yet highly manual operation tied directly to ASPICE V-Cycle compliance.

Each specifications release required :

  • Validating multiple requirement layers (Customer → System → SW → HW → MEC)
  • Performing data integrity checks
  • Comparing modules data with baselined modules
  • Exporting data through DOORS eXchange into ReqIF from the developement stage into the production one
  • Running post-import scripts
  • Baselining, and documenting the release process

Due to the complexity of this cycle and DOORS constraints, this process regularly became a bottleneck for the release train.

Solution overview #

I architected, together with a colleague, a complete release automation tool entirely in DXL, combining GUI components built using the DXL DB and DBEs, the IBM DOORS internal APIs, and core components that encapsulated all release logic into deterministic procedures.

NOTESI Logo

The DXL Specifications release tool has the following features :

  • Automated modules validation (views, attributes, Change Trigger checks, link-set integrity)

  • Automatic dev ↔ prod areas synchronization

  • Controlled ReqIF export/import with lock/unlock safeguards

  • Automated synchronization to prevent accidental requirement drift

  • Execution of post-release checks & validations including attributes locking, logging, and baseline management in both dev & prod areas.

  • A friendly GUI with 6 simple steps that was designed so that non-expert users could trigger full releases with predictable outcomes in only a few clicks.

  • End-to-End Traceability Pipeline : In addition to the previously mentioned features, a robust logging system was implemented to ensure complete traceability of releases. This system records structured logs directly into dedicated DOORS modules. These logs are subsequently extracted, processed, and persisted where they can be accessed for dashboards, analytics, and reporting.

    1. A scheduled Batch DXL extractor exports log modules into structured text files.
    2. A Python pipeline parses, cleanes, normalizes, and validates these text files.
    3. The pipeline uploads structured release data into SQL Server, enabling persistance.
    4. PowerBI dashboards visualized live release metrics, failure rates, module throughput, and project statistics.

This transformed a manual, time-consuming process into an automatic, measurable & controled release system.

Impact & key results #

The tool improved overall release execution time by 94%, enabled parallel releases, eliminated missing baselines and manual errors, and democratized the release process beyond requirements engineers. It significantly improved release reliability, traceability, and compliance, freeing engineers to focus on high-value work rather than chores

Following deployment, the solution has been rapidly adopted by projects teams.

NOTESI Logo

Technical Challenges #

  • Memory-efficient data handling
    In the absence of garbage collection. Standard strings in DXL are memory-heavy, using buffers was the solution to optimize memory & avoid overflows.

  • Skip-list–based storage
    Large collections of objects were stored using skip lists to prevent memory spikes and maintain fast lookup times.

  • Custom DXL testing framework
    A bespoke framework was built to simulate both unit and integration tests, compensating for the lack of native testing tools.

  • Optimized, atomic baseline handling
    Baseline creation and traceability operations were implemented as atomic steps, preventing partial or inconsistent states.

  • Print-based debugging strategy
    With no debugger available, structured and contextual log tracing was engineered to make complex logic diagnosable.

  • No IDE or IntelliSense
    All code was developed manually without autocompletion, requiring strict modularization and naming conventions for maintainability.

  • Single-thread constraints
    Long-running operations were optimized, chunked, and monitored to prevent blocking the user’s DOORS session.

These engineering decisions allowed the tool to scale to large modules and long release chains without failures.

keywords : Problem solving, ASPICE, V-Model Programming, Automation, Time optimization, Release management, DXL scripting, IBM DOORS, Workflow efficiency, Real-life engineering, Process improvement