Including Names in exported Requirements Traceability data

 


Requirements management is often the difference between project success and failure. When requirements are unclear, poorly communicated, or difficult to trace, teams waste time, effort, and resources. OpenRose, a free and open-source requirements management tool, was built to help individuals and teams do it right and reduce waste.

One of the most requested improvements from our community was to make exported data more human-friendly. While machines and AI systems can easily process GUID-based IDs, humans struggle to interpret them without context. That’s why OpenRose now includes Requirement Names in all exports — JSON, Baseline, and Mermaid flowcharts. This enhancement bridges the gap between machine precision and human usability.

The Past: ID-Only Traceability

In earlier versions of OpenRose, traceability records in exports contained only IDs. For example:

{
"FromTraceItemzId": "0381fbbc-740c-481a-b5ca-972780ea4b2c",
"ToTraceItemzId": "e2d0713a-f617-4ec4-814c-7189fde93cef",
"TraceLabel": "DRIVES"
}
  • Technically precise: Machines could process these IDs perfectly.
  • Human challenge: Without names, it was difficult to know which requirements were connected.
  • Time-consuming: Reviewing traceability meant constantly cross-referencing IDs back to the project tree.

The Now: Names Included in Exports

With the new enhancement, exports now include both IDs and Names:

{
"FromTraceName": "Plan the Fundraising Campaign",
"ToTraceName": "Execute the Fundraising Event",
"FromTraceItemzId": "0381fbbc-740c-481a-b5ca-972780ea4b2c",
"ToTraceItemzId": "e2d0713a-f617-4ec4-814c-7189fde93cef",
"TraceLabel": "DRIVES"
}

This makes traceability instantly understandable. Humans can see relationships like Plan Video Content → Publish and Promote without decoding GUIDs.

Baseline Exports: Snapshots with Names

Baselines are snapshots of requirements at a given point in time. They capture the state of your project for audits, reviews, and historical comparisons.

  • Past: Baseline exports contained only IDs.
  • Now: Baseline exports include both IDs and Baseline Requirement Names, making snapshots easier to review and compare.

This means that when you look at a baseline snapshot, you can immediately see relationships such as Monitor Event Progress → Evaluate Success Metrics without needing to decode GUIDs.

Mermaid Flowchart Exports: Visual Clarity

Mermaid diagrams have also been enhanced. Previously, relationships were defined only by IDs. Now, requirement names are included as comments:

%% "Plan Video Content" -.-> "Publish and Promote"
b999b251-7efe-4388-b3c1-f0b9d166743b -."DEPENDENCY".-> addb53e7-0b53-4687-a78e-9f7c938493e1

 

  • Comments provide context: Humans can immediately see which requirements are connected.
  • IDs remain authoritative: The diagram still uses IDs for plotting and linking.
  • Readable traceability: Relationships like Monitor Event Progress → Evaluate Success Metrics are clear at a glance.

Import Behavior: IDs Remain Authoritative

It’s important to note that during imports, OpenRose ignores names (FromTraceName and ToTraceName in JSON, or comments in Mermaid).

  • Names are included only for human readability.
  • IDs remain the authoritative keys for data integrity.
  • This ensures imports are consistent and reliable, even if names change.

Key Benefits of Including Requirement Names

  1. Improved Readability: Humans can instantly recognize requirements in exports.
  2. Better Collaboration: Teams can discuss traceability using names, not cryptic IDs.
  3. Reduced Errors: Clearer context minimizes mistakes during reviews and audits.
  4. Audit-Friendly: Baseline snapshots with names make compliance checks faster.
  5. Visual Clarity: Mermaid diagrams are easier to interpret with names included.
  6. Consistency Across Formats: Names are now included in JSON, Baseline, and Mermaid exports.

Why This Matters

OpenRose’s mission is to empower teams to manage requirements with clarity and confidence. By including requirement names in all exports, OpenRose makes traceability:

  • Human-friendly: Easy to read, share, and discuss.
  • Machine-precise: IDs remain the backbone for imports and integrity checks.
  • Audit-ready: Baselines with names provide clear historical snapshots.
  • Collaborative: Flowcharts and JSON files are now accessible to both technical and non-technical stakeholders.

Conclusion

By extending requirement names into JSON, Baseline, and Mermaid exports, OpenRose ensures that requirements traceability is not only technically robust but also human-friendly. This enhancement was driven by community feedback and reflects our commitment to helping teams do it right and reduce waste.

OpenRose continues to evolve as a community-driven project. With every improvement, we aim to make requirements management more effective, collaborative, and accessible. Whether you’re reviewing live project data or historical baselines, OpenRose now gives you the clarity you need to succeed.


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

https://github.com/openrose



Comments

Post a Comment

Popular posts from this blog

Introduction to OpenRose - Requirements Management

Image
Watch it on YouTube at : https://www.youtube.com/watch?v=P0x3ZaHg8sA OpenRose - Requirements Management Application VIDEO TRANSCRIPT Hello, and thanks for joining in for the launch of OpenRose, an open-source requirements management application. The main purpose is to help users and teams "do it right" and ultimately reduce waste. OpenRose is released on GitHub at [github.com/OpenRose](https://github.com/OpenRose). Users can look at the source code and documentation at the same location. Let me do a quick demo of the application. In this environment, I'm using Windows 11 on a desktop computer, not a server. I have installed IIS and deployed a web deployment package over IIS. When you connect to OpenRose, on the homepage, you will see a welcome message like this: "Welcome to OpenRose." One would start by creating a new project. For this demo, I've created two separate projects. The first project is a small example of how I converted a document published b...
Read more

What is Requirement?

Image
What is Requirement? OpenRose - Requirements Management An Open Source and FREE Requirements Management Application / Tool Direct Link to YouTube Video : https://www.youtube.com/watch?v=3qQzKbfvRPA Video Transcript :   Hi, welcome to OpenRose, an open-source and free requirements management application. Please visit https://github.com/openrose for more information. Let's go to the project dashboard, and this time, let's open a deep hierarchical level project. This is just a demo project, so when I open that project in the TreeView and start expanding the project, I can see some sample item types along with a Parking Lot, which is the system item type. Inside item type one, I have a top-level item, then item one and item two, which are broken down into further items. You can see I've given the names which indicate a kind of logical hierarchical structure in the name. Here, you can see L1, L2, L3, L4—that's the level. The project is considered as level one, and item ...
Read more

Agile Loves Clear Requirements

Image
  Agile Loves Clear Requirements OpenRose - Requirements Management An Open Source and FREE Requirements Management Application / Tool Direct Link to YouTube Video :  Agile Loves Clear Requirements Video Transcript : Today, I would like to talk about the importance of requirements in project delivery or product delivery, especially when using Agile methodologies like Scrum or Kanban. In the Scrum ways of working, we have user stories that are put into the Sprint backlog. From the Sprint backlog, the team pulls out certain user stories for a given Sprint, which could be a two to four-week Sprint. During this Sprint, the team has daily standups to discuss progress and blockers. At the end of the Sprint, it is expected that the team will deliver a product increment, which could be a service delivery or a product delivery. Let's consider a project where we have team members, represented by circles. The size of the circle indicates their knowledge, seniority, experience, and sk...
Read more