Unambiguous requirements are important for successful validation, but they’re difficult to establish in practice. By more clearly defining, structuring and tracing the development process of a system, many problems at a later stage can be prevented, TMC’s Bart van Liere learned at a training from High Tech Institute.
When a surgical robot needs to place a suture at the microscale, the functional requirement seems clear: Position and move with an accuracy of a few tens of micrometers. But when the type of tissue the suture should be placed in hasn’t been specified, this immediately creates room for interpretation. Soft tissue requires a different force buildup than rigid or fibrous material, which affects both the required actuation and the choice of suture material. During validation, it turns out that a specification that looks correct on paper has been designed in practice with assumptions that weren’t made explicit anywhere.
“Meeting the requirement” is what Bart van Liere, integration engineer at TMC, seconded to MTA, deals with on a daily basis. He’s at the back end of the development process, where he needs to demonstrate that a system does what it was designed to do. “During validation, we find out if a requirement is formulated too vaguely, a restraint has remained implicit or stakeholders haven’t been able to properly convey what they had in mind for the same ‘functional’ goal.”
Design and practice
After completing his bachelor’s degree in mechatronics, Van Liere went on to obtain a master’s degree in AI for engineering systems at Eindhoven University of Technology. He’s now active as an integration engineer through TMC. TMC deploys technically trained professionals, so-called “employeneurs,” on a wide range of projects at various high-tech clients.
At MTA, Van Liere is currently involved in a project for Microsure, centered on a surgical robot that has to operate with an accuracy of 50 micrometers. In his role as a system integrator, he forms the link between design and practice. He works with engineers on the technical implementation and with stakeholders on translating requirements into concrete specifications and validation criteria.
Van Liere is no stranger to the role. Previously, he co-founded his own company to develop a drone for deployment in high-risk areas. “In that process, we noticed how important it is to get a clear picture of exactly what you’re trying to build right from the start,” he says. “If you miss the essence there, you’ll end up with an end product that doesn’t fully meet the vision you had in mind.”
Sharper choices at an early stage
In practice, this problem rarely arises from incompetence, but from the way in which requirements are established. A stakeholder formulates what the system must achieve, while an engineer tends to implicitly translate that into how the system could do it. These two perspectives aren’t automatically the same. Without an explicit definition of the primary function and the preconditions, a set of requirements emerges in which intention and implementation are intertwined. As a result, specifications appear to be comprehensive, but on closer inspection allow for multiple interpretations.
To avoid different interpretations of requirements throughout the process, a more structured approach to drawing up these requirements is necessary. This means both documenting what a system should do and keeping track of why choices are made and under what conditions they apply. To get a better grip on this, Van Liere immersed himself in the “System requirements engineering” training at High Tech Institute, taught by Cees Michielsen.
“In this course, we learned that clearly and unambiguously formulating the requirements starts with asking the right questions,” explains Van Liere. “What’s the primary function of the system, and which constraints are decisive? Everything you then put on paper must be tested against these conditions.”
This method forces you to make sharper choices at an early stage. “Engineers tend to include everything in a brainstorming session,” Van Liere says, amused. “You end up with a list that looks complete on paper, but with little focus. Moreover, everything seems important.” By first determining what’s minimally necessary for the system to do what it’s supposed to do, it becomes easier to distinguish secondary matters from essential requirements and the nice-to-haves. This provides more clarity in the design phase and takes the final validation into account.
Tracking changes
Van Liere was able to apply the method directly in an ongoing project where he was involved in drawing up requirements from the validation angle. “You notice that you look at it from a different perspective,” he says. “Instead of immediately formulating demands, you first go back to the core: What are we actually trying to achieve here?”
By making that step explicit, the process became more focused and the distinction between which requirements were essential and which could wait emerged more clearly. “This takes a little more time at the start, but it’s still cheaper and faster than having to modify a prototype because the requirements weren’t properly formulated.”
In addition to asking the right questions, trainer Michielsen also addressed recording and keeping track of changes during the development process. He cited examples from his experience at DAF and ASML, among others. “During the development process, insights can change and choices are made for particular reasons,” Van Liere points out. “However, during validation, you want to know whether an outcome is the result of a mistake or a deliberate choice during the development process.” By systematically recording changes and underlying argumentation, the development of a requirement and the basis on which decisions were made remain transparent.
Structured thinking
During the training, Van Liere was joined by participants from a variety of areas, from high-tech to the energy sector. “The context differs, but the problems are the same,” he notes. “The discussions I have with my stakeholders are the same as theirs. Apparently, that’s where the challenge often lies.”
For Van Liere, the main value of the training lay in the way it structured thinking around requirements. “You learn to ask more targeted questions and to better capture what’s actually meant. It’s precisely this structure that helps you make more conscious choices and have sharper discussions with stakeholders.” The course reader now has a permanent place on his desk, as a reference book for when he wants to apply that way of thinking again.
The pace started leisurely but then picked up quickly. “It’s a two-day training on top of your regular work, so the balance is different than for a university course. But there was enough room to go into depth and bring in your own cases. Michielsen’s extensive experience meant that he was able to accommodate the diversity of input well.”
The theory was immediately tested against real cases. “You truly learn to follow the entire process, so that later you can trace back why a requirement was established and what choices were made along the way.”
This article was written in close collaboration with High Tech Institute.
