Automating Requirements: How Altium 365 Is Changing Engineering

Unlock the power of Altium 365 with automated requirements management! In this episode of the Altium OnTrack Podcast, host Zach Peterson sits down with Louise Linblad, VP of Product for Systems Engineering, and Gonçalo Ivo, Head of Product for Requirements & Systems Portal, to explore the revolutionary new tool for automating requirements within the Altium ecosystem.

Discover how Altium 365 Requirements & Systems Portal is designed to streamline workflows, reduce errors, and bring innovative solutions to life faster than ever before. Learn about the seamless integration of Valispace, and how this new feature is helping engineers connect requirements directly to CAD tools, enhancing collaboration and design accuracy.

Whether you're a product manager, system engineer, or electronic engineer, this episode is packed with insights on boosting your engineering efficiency with Altium 365.

Listen to the Episode

Watch the Episode

 

Key Moments:

• Altium 365 Integration
• Requirements Management Changes
• Requirements Automation
• Requirements Manager Demo

Links:

• Learn More About Altium 365 Requirements & Systems Portal

Transcript

Zach: Hello everyone, and welcome to the Altium OnTrack Podcast. I'm your host, Zach Peterson. Today we're talking with Louise Linblad, VP of Product for Systems Engineering, and Goncalo Ivo, Head of Product for Requirements & Systems Portal, both here at Altium. I'm very happy to be talking to them both about the new Requirements & Systems Portal app. You all may remember the Valispace acquisition. This is related to that. And this is a new product that's going to be available in Altium 365. So I am very happy to be talking to them both today. Louise, Goncalo, thank you so much for joining me.

Louise: Thank you. Great to be here.

Zach: So, the last time we discussed requirements management, Louise, I believe you were on the podcast, and we talked about the Valispace acquisition. What has happened since then, and how has that evolved into this new tool for requirements management?

Louise: Sure. Marco and I were on this podcast a few months ago, right after the Valispace acquisition. Just to recap a bit, Valispace was acquired to bring requirements and systems engineering context into Altium's products. Essentially, requirements are where you usually start a project—where you describe what you want to do, how you plan to build something, and what the project needs, right? That piece of the puzzle was somewhat missing in Altium 365 and Altium’s products. That’s why Valispace was brought in, to connect the requirements phase to the detailed design. And that connection is incredibly powerful.

I remember we talked last time about the idea that "one plus one is more than two," right? The more apps we have on the platform and the more we connect them, the more powerful it becomes for users. That vision is still true. We wanted Altium 365 to be a platform that spans from an initial idea all the way to manufacturing, connecting all the necessary tools. Over the past nine months, we’ve fully integrated Valispace as both a product and a team into Altium. The Valispace product is now an app on Altium 365.

As you mentioned, Goncalo is now the Head of Product for the Requirements & Systems Portal. We’ve also rebranded the app, so it’s now called the Requirements & Systems Portal on Altium 365. Our teams have worked incredibly hard over the last nine months to make this happen, and it’s a huge milestone for Altium, for the Valispace team, and for our customers. We’ve already started selling it to customers, and it's exciting to see how we can support them across the entire project journey.

We’re really proud of the work everyone has put in, from both the Altium and Valispace teams, and now we’re starting to see that "one plus one is more than two" concept come to life. It’s a very exciting time!

Zac: Now, what I find interesting about this, when taking a higher-level view of Altium 365, is that the Requirements & Systems Portal is just one of the apps available on the platform. There are actually multiple apps now. Goncalo, could you tell us a bit about the user experience and what types of apps users can access on Altium 365—not just the Requirements & Systems Portal, but also the other apps available?

Gonçalo: Well, as we mentioned, the Requirements & Systems Portal is one of the apps—one of the primary apps, I’d say—within Altium 365. But there’s another app, which I’d consider the first and most widely used, and that’s the BOM Portal. That’s a great example of another native application within Altium 365, along with Z2Data, where users can search for procurement data. These are the types of hubs we’re focusing on to expand the platform.

The main reason we created the Requirements & Systems Portal as an app was to give users a unified experience. Everything is integrated within a single environment, connected through a single digital thread. This way, users feel continuously connected—not just with their own team, but also with other teams and stakeholders. It’s not just for electronic engineers; it’s for everyone involved in the entire product development lifecycle.

That’s the goal: to continue expanding the application database. If you go to altium365.com, you can see the other available apps, as well as those that are coming soon—they’re all described there.

Zach: Now, when we talk about requirements and requirements management, I think a lot of companies use a wide range of different processes. So I’m curious if you both could explain how Altium 365 users would typically handle these types of requirements management tasks, and how that changes with the new Requirements & Systems Portal?

Gonçalo: That’s an interesting question because we’ve collected data from Altium users, as well as from webinars and research, and as you mentioned, most users engage in some form of requirements management. Even if they’re not fully managing requirements, they still need to consider them while designing—especially electronic engineers. But what we’ve found is that around 30 to 50% of users are doing this in Excel, spreadsheets, or other loose-text tools like Notes, or even by adding notes directly onto the design. That came up quite often. Others are using tools that aren't really built for requirements management, like task management tools, for example, Jira.

There’s a smaller percentage of users, or companies, that have more structured requirements management processes using tools like DOORS, Jama, Valispace, or similar. But overall, what we see is that much of this work is still disconnected from the design process, which leads to communication issues and data gaps.

With the Requirements & Systems Portal, we aim to bring the requirements lifecycle much closer to the electronic engineering lifecycle. It’s about having requirements readily available and directly connected to the design process, reducing miscommunication and ensuring accurate data sharing. That’s the value the Requirements & Systems Portal will bring to the world of electronic engineers.

Zach: Yeah, I think a lot of companies maintain a master document that contains a list of requirements, but it can be so long that nobody really wants to read it. So, maybe there’s one person who actually knows what all the requirements are, and it’s usually the author of that document. And then, that document has no direct connection to the CAD tools. So, is it fair to say that the Requirements & Systems Portal breaks down those big documents into individual pieces and provides that connection to the CAD project via Altium 365? Is that an accurate way to describe it?

Louise: Yeah, that’s one way to describe it, but the Requirements & Systems Portal is more than just putting the documents and pieces together. It’s really a comprehensive system for managing your requirements. It’s not just a place to store requirements; it also provides traceability—showing the history of who changed what—and allows you to track the status of verification. So it’s much more than just a document repository.

On top of that, there are all the collaboration features, right? Everyone is already familiar with the collaboration tools in Altium 365, where you can comment on requirements directly where they are. You don’t have to send an email asking about a specific requirement; you can comment on it within the platform itself. All of these capabilities come together with the Requirements & Systems Portal.

Zach: So, what's a good way to describe the workflow and how that requirements checking is automated within the Requirements & Systems Portal?

Louise: Yeah, of course. Our goal is always to streamline the workflow for engineers—that’s the whole purpose of the Requirements & Systems Portal and Altium 365, right? We often talk about three main benefits, or values: first, faster time to market—being able to iterate more quickly; second, getting it right the first time—so fewer errors; and third, fostering more innovation.

To dive a bit deeper, you mentioned that there might be just one person who knows all the requirements, but they’re not shared across different departments or with the engineers working on the project. That lack of visibility is a major problem. You might spend weeks designing something without knowing that a requirement has changed or that there was even a requirement you were supposed to follow from the start. One interesting point from the survey we sent out, which Goncalo mentioned, is that a lot of people said they never saw a requirement during the design process. That’s a huge problem because, without that, what are you designing against? Engineers need to have visibility into the requirements they’re working toward. When these things are misunderstood or misinterpreted, it costs both time and money.

What we’re trying to achieve is to help engineers iterate faster and foster better collaboration among different teams. The second key benefit is getting it right the first time. Mistakes are costly, both in terms of time and money. It’s difficult to measure exactly how much an error or an inconsistent requirement will cost because it’s often discovered late in the process. But by connecting all the data—so you know which requirements apply to which design and where they’ve been verified or implemented—you’ll be able to get it right the first time, instead of redoing things because of miscommunications or mistakes.

And of course, if you can achieve both of these, engineers will have more time to focus on what they were hired to do: actual engineering, rather than hunting for requirements in documents. This leads to a more innovative way of working. Instead of being afraid to make changes because you don’t know what effect they’ll have, you’ll be able to experiment more, make changes, and see the impact on the rest of the process or design. This ultimately allows your organization to be more innovative because there’s more time for experimentation and improvement.

Zach: One thing I'm really eager to see is a demo of this new new app on Altium 365. I believe, Goncalo, you've got something prepared for us?

Gonçalo: Yes, sure, I'll give it a go.

Zach: Okay, I see we’re live. And just for everyone listening to the audio, you’ve got a few different windows open in your browser. One of them is the Requirements and Systems Portal, where it looks like you have a big list of requirements. And then I see you’ve also pulled up a project in Altium 365 in your other windows.

Gonçalo: Yes, I'll start by showing the Requirements & Systems Portal app. It's accessible either through a direct link or, as we can see here, while navigating from the workspace. It’s available in the nine-dots menu as an application, so we can navigate to it from there. What we’re seeing here is a full list of requirements, which, as you mentioned, could be the initial list provided by the project manager or systems engineer. These are the requirements that a board, for instance, needs to comply with during the design process.

The Requirements & Systems Portal is flexible and can be used for more than just electronic requirements; it can be applied across the full development lifecycle. The example we have here involves a full drone. For the drone, there are different subsets of requirements, starting with high-level requirements for the drone itself, which are then broken down into power requirements, flight requirements, and so on. These can eventually be further decomposed to specific components, like the motherboard or the flight management unit that an electronic engineer would need to design.

Those requirements can be assigned to what we call a "block" within the RSP. So, we can say that this block should adhere to a specific subset of requirements. This can be set by the system engineer, or the electronic engineer can specify what needs to be done to implement those requirements, such as X, Y, Z steps. You can then trace all of that.

But that’s just the first part of the process—determining which requirements need to be followed. The next part is the connection to the electronics side, the deep integration we’re building. For instance, when we define this block as electronics-related, we can link it to the project being built in Altium Designer or Altium 365, which we refer to as the "Altium Dream."

Once this connection is made, two things happen from the Requirements & Systems Portal side. First, we can quickly review what’s already been designed on the electronics side. Second, and more importantly, we address the automatic verification point you mentioned earlier. With this deep connection, it’s not just about exposing requirements in Altium 365 or Altium Designer—it also pulls back data from the design. For example, it retrieves key properties like the number of layers or the minimum/maximum trace width from the Altium project.

Zach: Here, you have a list of objects. I see, for example, the blind via count. You mentioned minimum and maximum trace width. It’s actually pulling in objects from the Altium Designer PCB doc file. So now, the Requirements & Systems Portal can see the objects in your PCB doc and compare them against the specifications you’ve set up in the Requirements & Systems Portal.

Gonçalo: Yeah, as an example—this is a simple one—let’s say we have a requirement that the board shouldn’t be designed with more than seven layers, right? If you're unaware of that, by automatically pulling in the number of layers or other values from the design, we can instantly check if you're complying with that requirement. Using a simple mathematical rule, we can directly validate whether this requirement is being met or not, and if it’s failing or deviating from the requirement, it will warn the user. That’s one example.

Now, on the Altium side or the Altium 365 side, I’ll show part of it in Altium Designer and part of it in Altium 365 via the web interface. The requirements assigned to these projects will be accessible through what we call the requirements panel. While navigating the requirements panel, you can view the context of the requirements and see what they are.

There are three main actions available to the electronic engineer while designing with these requirements in context. The first is placing the requirement. You can indicate where in the design the requirement has been implemented. The second action is to assign the requirement as a task to someone else. You can easily create a task for another person and track where the requirement has been placed or tasked. The third action is that the electronic engineer can directly contribute to the validation and verification of the requirement by setting the status of the validation from within the Altium environment—whether in Altium Designer or Altium 365. This status will then be reflected in the validation activities within the Requirements & Systems Portal.

From the system engineer’s perspective, they no longer need to constantly check with the electronic engineer to ask, “Is my requirement being fulfilled? Is it being considered or implemented?” Every time an electronic engineer places a requirement, the system engineer—or other electronic engineers—can directly navigate to the specific location in the design where the requirement has been implemented using the design references. All of this is happening within the same Altium 365 environment, where you can easily switch between the web viewer, Altium Designer, Altium 365, or the Requirements & Systems Portal.

Zach: Yeah, this is really interesting, what you just did. You tagged one of the requirements to a specific schematic sheet, and it automatically appeared as a link in the Requirements and Systems Portal. Now, there’s automatic validation, but of course, someone can still go through and manually select it to validate more deeply if they want to. So, it doesn’t completely remove the human element from the process.

Gonçalo: Yes, exactly. The human always has the final say. And now that you mention it, even when writing requirements, we have some AI-assisted features that can help you create and refine them. These features, which we call the ValiAssistant, can assist in generating or improving requirements and even provide suggestions for further breaking them down. But it’s always just assistance. Ultimately, it’s up to the user to make the final decision, and it’s the engineers who make the final call.

Zach: Since we’ve gotten to this point, maybe one or both of you could answer this question: how long does it typically take to define all those requirements inside the Requirements & Systems Portal? And how does that compare to setting it up in some other system? Or is that not really a valid comparison? Because it sounds to me like if you invest the time in the Requirements & Systems Portal, it saves you review time on the backend by streamlining some of that automated checking.

Louise: For sure, I think there are several points to this. One is what Goncalo just showed—the AI functionalities, right? We can actually help you create and break down requirements. So, imagine you have a high-level need, like building a drone that flies autonomously for one hour without needing a recharge. That’s a very high-level need, and it would usually take a system or requirements engineer quite some time to break that down and think through the subsystems and solutions needed for the product. We can help take that first step.

As Goncalo said, it’s not about doing all the work for you, but rather assisting with the process. Some tasks are creative, while others are just about finding values in the requirements, so you don’t have to manually check that each value is correct—you can set up automatic rules. If you set it up well from the start, with connections to the design and automatic validations, the process will be much smoother later on. So, I think the main benefits are that we help you get started, break down the requirements properly, and ensure there are no inconsistencies. And, we also support automatic validation, so you don’t have to manually check every document. The system will flag problems or confirm that everything is correct so you can move forward more quickly.

Goncalo: And to add to that, for those 30 to 50% of users who already have requirements in Word or Excel, Excel files can be directly imported into the RSP. It’s just a drag-and-drop process. You won’t have to start from scratch—you just upload the file, link it to a block, and in minutes, you’ll have everything set up with traceability. It’s a simple and straightforward import feature.

Zach: Very cool. That was actually something I was going to ask—can you drop a Word document into the system, and it pulls out all the individual requirements?

Goncalo: Word is trickier because it depends on formatting, but we can help with that, and we’ve been assisting customers with it. Excel is much more straightforward.

Zach: Okay, okay. Another question I have, going back to the list of requirements—you showed things like blind via count and trace width. What other objects can the system pull from a PCB doc file? Can it pull reference designators, net names, net classes, or specific design rule values?

Goncalo: For now, it’s only pulling project data, specifically the project definition data assigned to a project. This is the first step in the direction we want to take. We aim to continue expanding data-sharing capabilities. For example, we plan to pull net data, as you mentioned, and even BOM properties. The long-term vision is to enable requirements to specify that all components on a board must operate within a specific temperature range, say minus 20 to plus 55 degrees. The goal is to pull that data directly from your components during the selection process. This will benefit everyone in the loop, from electronic engineers to procurement teams, because you’ll be able to design faster, catch errors sooner, and deliver value more efficiently.

Zach: Yeah, it sounds like you’ll be able to leverage Z2Data integration and check that kind of data coming in from Z2Data.

Goncalo: Exactly, that’s the long-term vision.

Zach: Speaking of the long-term vision, what else is in the future for the Requirements & Systems Portal? I understand you’re expanding the objects you can access within a PCB doc, but what else is on the horizon?

Goncalo: That’s one aspect, yes. Another is linking to more standardized requirements that are common in the electronics industry. We’ll continue tailoring the RSP to meet the needs of electronics use cases. Louise can share more on what’s ahead for the full requirements ecosystem.

Louise: Yeah, for sure. One priority is improving the RSP app and deepening its connection to Altium and Altium 365. Another is ensuring traceability of requirements across all apps in the platform. Requirements aren’t something you just set at the start of a project—it’s not like you have an idea, define the requirements, and then start designing. It’s a back-and-forth process between requirements and design. You begin with high-level requirements, then as you design subsystems, you add more detailed requirements. As you go deeper into the design, and then back up to manufacturing, you get additional requirements.

So, while the Requirements & Systems Portal as an app is great, we’re also expanding the context of requirements across the entire Altium ecosystem. Requirements give engineers the context they need to understand what they’re building. With that context, we can assist engineers in making better decisions and working faster. Ultimately, helping engineers make better decisions is the goal.

Zach: As this unfolds and the app evolves, we’d love to have you both back to share updates. Hopefully, we’ll have some folks sign up and start using it. Where can interested users go to learn more about the Requirements & Systems Portal? Should we send them to altium365.com?

Goncalo: Yes, altium365.com is the main site. Users can also explore the documentation section to learn more about the integration and how it plays out across both Altium Designer and the web viewer of Altium 365.

Zach: Excellent. Louise, Goncalo, thank you both so much for joining us today.

Louise: Thank you, Zach.

Goncalo: Thank you, Zach, for having us.

Zach: Thanks! To everyone watching and listening, we’ve been talking with Louise Linblad, VP of Product for Systems Engineering, and Goncalo Ivo, Head of Product for the Requirements & Systems Portal. If you're watching on YouTube, be sure to hit the Like button and Subscribe to stay updated with all of our podcast episodes and tutorials. And as always, don't stop learning, stay on track, and we’ll see you next time. Thanks, everybody.