[Webinar Recap] Best Practices for Live Traceability™

In this blog, we recap a section of our recent webinar, “Best Practices for Live Traceability™” – Click HERE to watch it in its entirety.

Drive Better Outcomes Using Live Traceability™

Managing product development across complex teams and toolchains can result in incomplete traceability, delayed deliveries, and costly rework. But it doesn’t have to.

In this session, you’ll learn how Jama Connect^® enables engineering teams to achieve Live Traceability™ as a natural part of their daily workflows — unlocking faster, more efficient product development.

What You’ll Learn:

Experience Live Trace Explorer™: Visualize and investigate the full impact of changes across your entire product lifecycle.
Built-In Traceability: Learn how everyday engineering works within Jama Connect to builds and maintain end-to-end traceability.
Speed Up Change Impact Analysis: See how structured data supports faster, more informed decisions.
Boost Quality and Coverage: Ensure complete test coverage, mitigate risk, and improve delivery timelines

The Above Video Is A Preview – Click HERE To Watch The Entire Webinar

VIDEO TRANSCRIPT PREVIEW

Jakob Khazanovich: Good morning, good afternoon, and good evening to everyone joining us. Today, we’re going to explore Live Traceability, what it is, why it matters, and how you can achieve it with Jama Connect. My name is Jakob, and I’m a Senior Solutions Consultant at Jama Software. My job is to help customers be successful in their product development goals by using Jama Connect. My expertise is in systems engineering for the medical device industry, and I’ve also had roles in test and quality engineering. My goal today is to give you clear, practical insights into how traceability works within Jama Connect to help you meet regulatory compliance requirements, ensure complete development and testing coverage, and streamline Change Impact Analysis. We’ll start with a brief introduction to Jama Connect, and then I’ll walk you through what complete traceability looks like in action. We’ll see how this ideal state strengthens development and sustaining engineering practices, and I’ll share the steps to get there. We’ll wrap up with a short Q&A so you can get your questions answered.

So when we talk about capturing data for complex product development, we all know that data in our organizations exists in many different forms. We have documents, we have Excel sheets, those Excel sheets contain rows, and all of those rows have data around a certain requirement or a certain artifact. Now, that’s all fine, but usually, documents or requirements are not so useful in and of themselves. What we actually are after is complete information for our system. Where did our requirements come from? What elements in the design implement that requirement? Did we test to make sure the requirement is met? And so on. When information is fragmented, whether that is requirements, testing, work management items, system architecture, risk management, product management, regulatory, or any other commonly siloed function, this increases risks to the product and end user, increases time to develop, and increases development costs.

What we are looking at here is a typical V-model of development. We have design inputs down the left side, design outputs on the bottom, and testing up the right-hand side. These are typically the steps in a product development effort. Now, this slide highlights a study finding that many will find intuitive. The earlier in the development process the changes are implemented, the less costly it will be to implement that change. But I still found the number staggering. On average, it costs 110 times more to make a change once you are in the design validation phase of your development compared to early on in the requirements definition phase. This hammers home the importance of thorough requirements identification, traceability from requirements to every downstream element in the development, and the need for a streamlined way to evaluate and to implement changes when necessary.

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution

Khazanovich: This is a typical development ecosystem. This structure often leads to negative outcomes, as described in the previous slides. When teams develop documents and designs and siloed tools, then identification of coverage gaps, inadequate change management, failure to assess and manage risk proactively, and countless hours and days building trace matrices are practically expected. Jama Connect solves these challenges and more. Complete information is created by building trace relationships and structure around individual artifacts in the system. When you do that, you basically empower your users to find any information and context to complete their work in the most accurate and efficient way possible. This is done in real-time, creating full traceability as a byproduct of engineering work rather than as a retrospective effort. We call it Live Traceability.

Now, you can go a step further than just traceability, and that would be understanding where decisions come from. You want to capture the why of a change. Why did we change the requirement or the occurrence estimate for a particular risk evaluation? This is invaluable information when changes are being considered or implemented in the product in the future. We will briefly discuss how Jama Connect supports documenting decisions and ensuring that institutional knowledge is minimized as much as possible.

Of course, teams do not develop complex systems in their own specific habitats. They are connected to a greater ecosystem, the many, many connections around them that have input on decisions and have input on those connections. So, engineering partners, customers, and other departments within the company can be invited to take part in that process and must be considered in development and change management processes. In the latter half of this presentation, we will show how we can actually relate information and what is involved in building those relationships. And once we have those relationships, what leverage, what value, and benefit can we get out of those relationships? What kind of higher-level perspective do they give us?

Traceability helps us confirm that we actually built the product we intended to and that every identified risk has been addressed and controlled. Second, embracing change. Products and requirements evolve. Traceability lets us quickly see what parts of the system are impacted by change so we can manage it without introducing new risks or gaps. Next, validation and verification. We need objective evidence that our product meets requirements and user needs. Traceability also lets us confirm that the risk control measures we put in place are truly effective. Live Traceability is the gold standard in product development. It allows you to see the status of your development effort in real-time and enables many benefits that we will later discuss. In Jama Connect, the easiest way to visualize your live traceability is with the Live Trace Explorer, so let’s jump into the tool and see what our gold standard looks like.

RELATED: Traceable Agile™ – Speed AND Quality Are Possible for Software Factories in Safety-critical Industries

Khazanovich: Now, we are in Jama Connect, and we can see the Live Trace Explorer in action. The first thing we can see in the upper right corner is the overall traceability score, which is the number of relationships created, divided by the total expected relationships, based on your defined Traceability Information Model (TIM). This has been filtered down to only consider the relevant and expected trace relationships for this particular project. I can see a nice green symbol in the upper right corner, which, as I remember from my business school days, means that things are going well in my product development. Throughout the development of the product, I saw this score increase from red to yellow to green, with the percentage associated as the traceability was created and completed. Going through the various tiles, here we can see the different sections of the explorer tree and have a more detailed view of which relationships have been created.

For example, I can see that all of my user needs are traced to system requirements, and all of my user needs are traced to validations. Additionally, I can see what percentage of my relationships are valid relationships, meaning that they’re not suspect links. We will discuss suspect links a bit more later. The Live Trace Explorer mirrors the traditional V-model layout, with design inputs on the left-hand side, testing on the right-hand side. I can see that 100% of my user needs are traced to validation test cases, and all of those test cases are included in test plans. I can see a summary as well of any open conversations, which will clue me in to why traceability may be missing or any outstanding questions that the team is trying to align on. If I want to get any additional details on a specific tile, I can click on the desired trace pair, for example, from user needs to requirements, and a new window will open showing my Trace View for the relationship pairing. Within the Trace View, I can then navigate one-by-one and get a preview of my items, like user needs and system requirements.

So, in the Live Trace Explorer, we mentioned the Trace Score™, and you’re probably wondering, how can we compare or calculate a trace score when there are many different ways to create Traceability Information Models, depending on your project and industry? As mentioned previously, the Trace Score is calculated by taking the number of established relationships among model elements, divided by the number of expected relationships among model elements, as specified by the project’s traceability model. Looking at the left diagram here, we can understand that for a single requirement, in this example, there are three expected relationships: one relationship to the user need, one to the subsystem requirement, and one to a verification. In this example, we are missing the trace to verification, so out of the three total traces that we’re expecting, we only have two of those created, resulting in a 66% Traceability Score.

Now, if we look at multiple requirements, let’s say there are three requirements and each of them have a trace to a subsystem requirement, but maybe only one of them is traced to a user need and only two are traced to verification items, now we can see that overall, for those three requirements, we have six of the traces created out of the nine that we’re expecting based on our model. On the right side, you can see how this would be scaled up to the entire project level. We’re going to look at every item that’s created, how many items are expected to trace to it, and then how many items are actually traced to it, and we’re going to look at that as a total for all items. Here, we see 101 expected relationships, 73 of which are established, and that leads to a 72.3% Traceability Score.