Enhancement Request - Export Data

 

Exporting Data feature supports exporting Project, ItemzType or Requireemnt Itemz with it's sub Requirements Itemz hierarchy structure. In this article we are going to discuss about analysing overall request to allow exporting of data from OpenRose and considering different features that has to considered to provide holistic working solution to support this enhancement request.

Direct Link to YouTube Video : 

https://www.youtube.com/watch?v=QGyb2Y1OCwY

Video Transcript :

Welcome to OpenRose!

Today, we are going to discuss exporting data.  

Let’s begin by navigating to our GitHub repository for OpenRose. This repository contains all the information related to the source code, as well as wiki documentation.  

Enhancement Request: Exporting & Importing Requirements Data  

One of the enhancement requests we have received involves exporting and importing data within OpenRose. In the OpenRose project, we have a user story related to exporting and importing requirements data.  

The request is quite straightforward:  

As a user of the OpenRose application, I want to be able to export project requirements—either by item type or individual requirement items—to the file system. This allows me to share the data with others or import it into another OpenRose repository.

This simple three-line user story centers on exporting and importing data, but it specifies exporting at three different levels:  

1. Project Level – Exporting the entire project’s data.  
2. Requirements Item Type Level – Exporting requirements at the item type level, which is just below the project level.  
3. Requirement Level – Exporting a specific requirement along with its child requirements.  

While these requirements are clear, they cannot be directly used as input for the development team to start implementation. Additionally, this request cannot be completed in a single iteration or sprint. Before development begins, we must conduct a detailed analysis of the user story and create a solid execution plan.  

Focus on Export Functionality  

This video will focus solely on our analysis of the export functionality based on the user story. Our team conducted a brainstorming session to refine the initial ideas and generate more precise requirements. These requirements—or user stories—are ultimately linked to the epic user story, which is focused on exporting and importing requirements data.  

To better communicate this information with the community, we have also documented our findings in the wiki environment. Now, let's review the key considerations outlined in the wiki.  

Exporting Data from OpenRose  

As per the original request, we are going to support exporting data at three levels:  

• Entire Project – Exporting all data related to a given project.  
• A Specific Requirement Type – Exporting requirements associated with a particular item type.  
• Individual Requirements (Including Child Structures) – Exporting a requirement along with its child requirements in a breakdown structure.  

To better illustrate this, let’s examine a diagram:  

OpenRose utilizes a SQL Server database that stores multiple projects.  Each project contains multiple item types.  Each item type has requirements, some of which have child requirements.  

Within this hierarchy, users can choose which level of data they want to export:  

1. Whole Project Selection – Export all data within the project.  
2. Item Type Selection – Export all requirements related to a specific item type.  
3. Individual Requirement Selection – Export a single requirement and its child breakdown structure.  

Our goal is to enable structural data export based on single-record selection so that users can retrieve precisely the data they need, whether at the project, item type, or individual requirement level.  

Exporting Repository Details  

Now that we have a clear understanding of the three different single records that can be selected for export, let's move on to the repository details section.  

Each repository will be assigned a unique ID, ensuring proper identification when exporting data. This will be useful in the future, particularly for implementing import logic, where exported data could be updated within the same repository. Although we are not utilizing repository IDs extensively at this stage, they will play a critical role in future enhancements.  

Excluding Attachments from Export

Currently, OpenRose does not support attaching binary files such as images, videos, Word documents, Excel files, PDFs, or other file types to requirement objects. Since OpenRose does not allow such attachments, we will not export them.  

At this stage, OpenRose exports only textual data, including:  

• Requirement Name  
• Status  
• Priority  
• Description  
• Severity  

If any requirement links to documents stored in Google Drive, Dropbox, SharePoint, OneDrive, or other external locations, we will not fetch or export those files. The export function remains limited to textual data.  

Handling Special Characters in Exported Data

When exporting fields such as description or name, special characters need to be properly handled for JSON compliance. JSON uses double quotes (`" "`) to define key-value pairs, and if special characters are present in text—such as `"sponsors"` or `"press reporters"`—we must escape them using a backslash (`\`).  

For example, if a description contains:  

"Sponsors, press reporters, and attendees for the charity fundraising event"

These special characters will be escaped to ensure JSON formatting remains intact. This internal mechanism allows serialization and deserialization between C# objects and JSON objects while maintaining data integrity.  

Exporting Field Metadata

Some fields in OpenRose, such as status, priority, and severity, operate using dropdown lists  Alongside individual records, the export will include metadata for these fields, ensuring future data mapping aligns with import requirements.  

For example, if a status field allows five different values, all five possible selections will be included in the export JSON file, providing context for potential data transformations during an import process.  

Exporting Traceability Data

OpenRose allows extensive traceability between requirements, meaning different records can be linked together. As part of the export process, traceability information will be included, but only for records within the exported dataset.  

Traceability Inclusion Rules:

• If an entire item type is exported, all traceability links within the dataset are included.  
• If only a subset of records is exported, traceability links outside the exported scope will be excluded.  

Handling Circular Traceability

Some traceability relationships may form circular references, where:  

• Record A links to Record B  
• Record B links to Record C  
• Record C links back to Record A  

To prevent an infinite loop, circular traceability will be identified and removed in the exported data. Any duplicate traceability references will be excluded to maintain a clean export file.  

Excluding Change History Data

Over time, requirement records undergo multiple updates and modifications. However, when exporting data, we will only include the current snapshot—not historical revisions.  

For example, if a requirement initially had a status of New and was later changed to Approved, only the latest state (Approved) will be exported. The same applies to all fields—priority, severity, and other attributes will reflect their most current values, excluding past modifications.  

Exporting Data Without Filtering Criteria

While filtering is a useful function, we will not allow filtering data prior to export in this iteration. The primary reason is to preserve hierarchical structures and traceability links.  

For example, if a fundraising event requirement includes multiple sub-requirements, exporting only one sub-requirement would break the structural integrity of the dataset. To maintain proper data representation, entire hierarchical structures will be exported rather than selective filtering based on criteria such as status or severity.  

Filtering Criteria for Exporting Data

One major concern when allowing data export by filtering criteria is the possibility that some records may be excluded, potentially breaking the hierarchical structure.  

For instance, suppose "Plan Video Content" does not meet the filtering criteria, but "Draft Script & Visual Concepts" does. If we allow filtered exports, how can we export the child requirement while excluding its parent?  

Will the child automatically become part of a different requirement such as "Create and Publish Social Media Videos"? This scenario would disrupt the overall context and structure, which is why we have decided not to support filtering-based data exports at this time.  

Exporting Data from a Baseline

As we know, OpenRose allows users to capture baselines within a project. A baseline serves as a snapshot of project data at any given point in time.  

Creating a Baseline

Let’s assume there are no baselines currently found for the charity fundraising event. However, users can create baselines by project or by item type.  

For example, let’s create a Demo Exporting Data Baseline—this serves as a simple baseline for demonstration purposes. Once created, we can view the baseline to see a structured representation of the project's snapshot.  

Exporting Data from a Baseline Selection

When exporting from a baseline, users should be able to select:  

1. Entire Baseline – Exporting all data recorded in the baseline.  
2. Baseline Item Type– Exporting a specific item type within the baseline.  
3. Individual Baseline Record – Exporting a particular baseline requirement along with its child items.  

For example, selecting "Create and Publish Social Media Videos" as a baseline requirement item should allow users to export that record along with its breakdown structure of all related baseline requirement items.  

Handling Exclusions in Baseline Export

A key feature of baselines in OpenRose is their ability to support negotiation with customers or teams regarding which features will be delivered.  

Let’s say the "Publish and Promote Video" feature is not ready in the current iteration. We can exclude this requirement from the baseline while retaining the rest of the related items.  

Effect on Exported Data

• If a higher-level requirement is exported, all excluded child requirements will not be included.  
• For instance, exporting "Create and Publish Social Media Videos" should only include data up to "Edit Videos for Social Media Platforms", while the publishing-related requirements are omitted.  

Users should be provided with an option to choose whether they want to:  

1. Export only included requirements (default behavior).  
2. Export both included and excluded requirements.  

Handling Traceability Data in Baseline Exports

If a snapshot of the project is created, any traceability between requirements must be carefully handled.  

Excluding Traceability for Excluded Requirements

• If a requirement is excluded from the baseline, any traceability links associated with that requirement will not be exported.  
• If a baseline includes only four records, then traceability links outside those records will be omitted.  

Circular Traceability Removal

Circular traceability happens when:  

• Record A links to Record B  
• Record B links to Record C  
• Record C links back to Record A  

To prevent infinite loops, OpenRose will automatically remove duplicate traceability references in the exported dataset.  

Export Format and Versioning

As discussed earlier, the export format will be JSON, ensuring structured data compatibility with various import processes.  

Additionally, exported files should include a version number, such as v1.0.0, v1.1.0, or v2.0.0, similar to product versioning. This allows future schema changes to be reflected in exports and ensures proper compatibility when importing data.  

Alternative to Export & Import: Copy Feature

For users who simply wish to transfer data within the same repository, OpenRose offers a Copy Feature that enables:  

1. Copying an entire project  
2. Copying a specific item type  
3. Copying a requirement item  

This method is faster and more efficient than exporting and importing back into the same repository.  

Final Thoughts  

The export & import feature is a critical addition to OpenRose. Ensuring proper implementation will allow organizations, teams, and individuals to leverage this open-source requirements management tool effectively.  

We encourage users to share OpenRose within their communities and contribute to the project—whether through source code contributions, documentation improvements, or requirements management expertise.  

If you have experience with Agile, Scrum, or other development methodologies, your insights could further refine OpenRose’s capabilities. Whether it’s IT product development, event planning, or structured task management, OpenRose provides a robust framework for handling requirements efficiently.  

Thank you for your time and support! We appreciate your contributions toward making requirements management simpler and better for everyone.  

Have a great day! 😊  

 OpenRose, a free and open-source requirements management application. For more information, visit 

https://github.com/openrose