No-code integration platform for rich bi-directional sync
Zero downtime migration to tool of your choice
Keep Historical Data, Without Slowing Down Your Tools
Migrate or restructure Azure DevOps Instances
Real-time, context-rich data lake for AI or analytics
By Role
Accelerate delivery with clear insights
Transform smarter with a connected digital thread
Confident transitions for every enterprise change
By Initiative
Modernize and move to cloud without disruption
Build a compliant digital thread for complex environments
Build the foundation for smarter AI
By Domain
No-code integration across teams & systems
Enable collaboration between IT, support & business teams
Connect PLM & engineering teams for smarter products
Ensure regulatory compliance from start to release
Explore the latest in technology and best practices
Success stories from the field
Actionable insights for your business challenges.
See solutions in action
Learn, plan, and execute with confidence
Official announcements and updates
Join discussions that drive results
Stay ahead with curated insights
Replacing an ALM system shouldn’t mean losing years of engineering history. Learn why legacy data retention matters, why common workarounds fail, and how purpose-built ALM data archiving helps organizations preserve traceability, compliance, and institutional knowledge after migration.
For semiconductor and chip design companies, achieving comprehensive traceability throughout the pre-silicon phase—from planning, design, verification, simulation, testing, and redesign is crucial for minimizing errors and reducing costs. Discover how Verisium Manager and Jama integration empower requirements management and verification teams to collaborate seamlessly through real-time information exchange, eliminating manual intervention. This advanced integration fosters digital continuity, building a robust digital thread that drives digital transformation initiatives forward.
Powered by OpsHub Integration Manager (OIM), the Verisium Manager and Jama integration ensures seamless bidirectional data exchange with 100% accurate and reliable synchronization, even for complex entities.
Schedule a 30-minute live demo with our integration experts
Let’s begin with the demo. Let’s assume that the product management team is using the requirement management tool Jama, and the verification team is using the verification tool Verisium Manager. The product manager has received a requirement related to wireless communication support via System-on-Chip (SoC); for the same, a couple of requirements are defined at the Jama side. For example, one could be wireless communication via Bluetooth Low Energy System-on-Chip.
Along with this requirement, the product manager has defined additional details such as the description, acceptance criteria, priority status, and so on. The product manager believes this requirement can be completed by performing two major verifications: power consumption verification and frequency band verification. For the same, sub-requirements related to power consumption verification and frequency band verification can be defined at the Jama side.
Now, we will go to Verisium Manager. Upon refreshing the Verisium Manager, we can see that there are no requirements listed. This means the verification engineer won’t know about these requirements unless they are explicitly defined in the tool. To synchronize the data between the requirement tool and the verification tool, we will use OpsHub Integration Manager.
Next, we go to OpsHub Integration Manager, where we activate the integration to synchronize data from Jama to Verisium Manager. It will take a couple of seconds to synchronize all the requirements. Meanwhile, we return to Verisium Manager, wait for a few seconds, and refresh it to see the synchronized data.
Once refreshed, the requirements from JAMA are synchronized as sections and subsections in Verisium Manager, preserving the same structure and details as defined in Jama. For example, the Bluetooth SoC requirement includes details such as severity, acceptance criteria, and status, identical to what is defined in Jama. Along with these, additional details such as the entity ID of the Jama requirement and a link to that requirement are also available. These details enable the verification engineer to trace the Jama requirement associated with a section, and the link allows navigation to the specific requirement.
With OpsHub Integration Manager, traceability between the two systems is achieved. Now, let’s assume the power consumption verification requirement is assigned to a verification engineer. The engineer updates the status of this section to “In Progress.” While working on the requirement, the engineer determines that verification can be performed based on different modes of Bluetooth, such as idle and active modes. Consequently, the engineer further breaks down this section into subsections: one for active mode with an “In Progress” status and another for idle mode, also with an “In Progress” status.
The verification engineer has now defined these subsections. Here, we observe that requirements updated by the sync tool have a flag raised on the icon label, whereas those created or updated by the verification engineer do not. This flag helps the engineer identify which requirements are updated by the sync tool. If the engineer approves these changes, the flag can be cleared using the “Clear All Flags” option in the UI. After clearing the flags, we observe that they disappear, but any subsequent updates made by the sync tool will raise the flag again. This allows the engineer to track the updated entities easily.
Changes made in Verisium Manager are also reflected in Jama. By refreshing Jama, we can see the latest changes, including subsections created in Verisium Manager, now available as sub-requirements in Jama with the same details. For example, the status update performed in Verisium Manager is also reflected in Jama.
If the product manager updates the description of the active mode requirement, such as adding “low power consumption,” and saves it, the change will also be reflected in Verisium Manager. Refreshing the Verisium Manager will show the updated description in the active mode subsection. This ensures that any changes made by the product team are available to the verification team.
The verification engineer, having started work on this subsection, can define tasks related to it. For example, a task related to the active mode section could involve validating current and voltage levels.
Similarly, for the idle mode, the test case could be low-power state validation. Similarly, for the frequency band verification, the engineer has defined two different test cases: one could be 1.6 GHz frequency validation, and another could be 2.1 GHz frequency validation.
For the purpose of this demo, we assume that the verification engineer has already run the regression, and the golden regression results are available in the metrics. The engineer will now associate the relevant metrics with the corresponding metric ports. Once all the metric ports are associated with the relevant metrics of the golden regression, we notice that the details of the verification metrics are not available at the metric port level because, in Verisium Manager, the regression results have not persisted in the database.
To address this, we will run a script to copy the results from the verification metrics to the metric ports in Verisium Manager. After running the script, we refresh Verisium Manager and observe that the verification results are now copied to each metric port level. These results will also get synchronized to Jama. Additionally, at the Verisium Manager side, the results are rolled up at the sections and subsections level, and the same rolled-up results are also available in Jama at the requirement level.
Next, we go to Jama to view the latest changes from Verisium Manager. After refreshing JAMA, we can see that all the test cases defined in Verisium Manager are now also available in JAMA, along with the verification metrics from Verisium Manager. The rolled-up results are displayed at the requirement level, and we can see the cumulative results as well.
If the product manager, based on the requirement results related to the verification metrics, decides that a requirement cannot be passed because it lacks any passed runs, they can change the requirement status to “Draft.” This will prompt the verification engineer to rerun the regression for the sub-requirement. Conversely, if the product manager deems the requirement acceptable based on the verification metrics, they can update the status to “Published,” allowing the verification for this requirement to be closed.
These updated changes will also be reflected in Verisium Manager. We then revisit Verisium Manager to confirm the latest changes. Upon refreshing Verisium Manager, we observe that the product manager’s decision to reject a requirement and set its status to “Draft” is now reflected in Verisium Manager. Similarly, for the idle mode, the status has been updated to “Published,” indicating it was accepted by the product manager. These changes from the product manager are now available to the verification team.
This demonstrates how synchronization between the verification tool and the requirement tool can be performed seamlessly via OpsHub Integration Manager.
Thanks for watching the demo.
Schedule a 30-minute live demo with our integration experts
