In Stay Sharp Episode 95, Bridging Hardware and Software: The Future of Product Development, Fernando Valera, CTO at Visure Solutions, joins co-hosts Jonathan Scott and Juliann Grant for a discussion on the intersection of hardware and software in product development. Fernando, part of the team that founded Visure, has more than 20 years’ experience in requirements engineering (RE), including a certification from the German International Requirements Engineering Board.
How RE Fits into PLM and ALM
Jonathan starts by describing product lifecycle management (PLM) as the system to manage data about physical products and application lifecycle management (ALM) as the same for software products. RE, he says, is “the process of capturing, managing, and tracing requirements and more.” Because the products in our marketplace are increasingly cyber-physical—comprised of mechanical, electrical, and software components—the challenge is managing product development across disciplines, especially when many PLM and ALM systems include some RE functionality, but often not enough.
RE sits at the intersection of hardware and software, according to Fernando. They’ve “worked as separate silos and the teams have not collaborated much together. They’ve used different methods, techniques, and tools—whereas the conception phase is where they have a common ground. That’s where the requirements engineering takes place,” he says. RE especially helps organizations handle a major difference between hardware and software: the cadence. Hardware is more stable, with fewer releases—once a month, a quarter, every six months, for example, whereas software is more changeable, with more releases, potentially every week or two.
Of course, introducing a third system into your product development process is its own challenge. Part of that is cultural, needing to change the organizational mindset of working from a product team perspective, not from a silo. “You are part of a bigger process,” Fernando says. “You cannot be delivering a product every three weeks, for instance. Somehow that software development has to align to a high level cadence of the product and the rest of the components. You have to define a product process and then align those process components with that system process.”
Systems Engineers and (Model Based) Systems Engineering
Systems engineers are leading the charge to blend different process approaches to make them work for all teams. Model based systems engineering (MBSE), Fernando says, is “very closely related to requirements engineering and also closely related to software and hardware products. It fits right in the middle of that intersection.” Furthermore, MBSE must be a combination of models and requirements, because models will eventually translate into components.
But MBSE isn’t just about using models, it’s making sure the system is considered from different perspective, Fernando explains. With MBSE, you’ve got a static model with behavioral elements that connect to requirements, on which you can do calculations and simulations for performance. Jonathan says, “Those elements mean you can take away some of the complexity of your 10,000 requirements by looking at them differently through that lens of MBSE.” MBSE’s capabilities have been driven, in part, by advances in digitalization and the creation of digital twins. “To a certain extent, we can rely on them as representations of the real world, but in digital. We can actually improve or expedite the cadence of the hardware as well, or the mechanical pieces at least,” Fernando notes. “MBSE is tying all of this together in the sense that we can have a very complex world that we know is going to iterate much faster. We somehow have it all tied together and ready to make changes and see how they affect the system.”
AI and RE
Fernando sees big impact and benefits ahead for requirements due to AI, because both requirements and AI function with natural language. He predicts AI will be useful as a generator working from prompts or as the creator of a requirements spec that complies with standards. But AI isn’t coming for everyone’s jobs. “Eighty percent of what a [requirements] engineer is doing can be done by AI … but it’s the 80% that is typically the low hanging fruit,” he says. “And then the engineers have to do the really innovative part, which the AI is not going to do.”
Learn More About The Bridge of Requirements Engineering
The full podcast contains more discussion and details on a variety of topics, including how the AI revolution is like the typewriter revolution, why Fernando says it’s critical to develop a systems engineering mentality across your organization, how the type of project management will impact how you do RE and how your tools need to work, and more.
Be sure to check out Stay Sharp Episode 95: Bridging Hardware and Software: The Future of Product Development and join us each week for a new podcast.
Follow the Razorleaf Podcast, Stay Sharp in Digital Engineering on:
