“Requirements tooling suppliers aren’t up to date and it’s frustrating”

The profession of requirements engineering moves so fast that tool suppliers can barely keep up. “The software from major suppliers hardly takes into account the latest insights in our field,” says Cees Michielsen, trainer of System requirements engineering at High Tech Institute.

Customers becoming more central, systems becoming more complex and the design process becoming more and more intertwined. In a nutshell, these are the factors that drive change in requirements engineering. “Requirements engineering is out of its bubble,” says Cees Michielsen, trainer of system requirements engineering at High Tech Institute. “It’s now an integral part of systems engineering.”

“In the past, we only looked at the intrinsic value of a requirement. That’s also how the tooling was originally set up. In the meantime, we’re focusing more and more on what such a requirement does in the entirety of the product development. We zoom out more. Unfortunately, the software tools haven’t grown with us.”

In the coming months in Bits&Chips, Michielsen will highlight a handful of trends in his field. In this interview, we kick off with some of the topics he’s going to cover.

Major trends

Requirements engineering is about ensuring that customer wishes enter the product development process in a clear, unambiguous manner without losing information. That information can be very concrete: a 2,700-K, 350-lumen LED lamp. But it can also be vague: a comfortable truck. “We have to arrive at the right product,” notes Michielsen. “We have to implement what the customer wants in an efficient but correct way.”

Roughly speaking, Michielsen sees a handful of major trends in requirements engineering. For example, getting the requirements for a product complete is a perennial challenge for engineers. “It’s a recurring question from participants in my training courses,” observes Michielsen. There’s also a desire to increase the quality of requirements. Although not always exciting, this is a challenge for engineers because language and wording play a key role in drawing up good requirements and product specifications.

The increasing need for traceability could perhaps be called a truly new trend. “That term refers to being able to track all events and decisions in the requirements engineering, design and decision-making process, from stakeholders to product implementation,” Michielsen explains. “Conversely, it’s important, especially in larger projects, that for any requirement at any decomposition level, you know how to find your way back to the stakeholder’s needs. Why replace a side mirror on a truck with an exterior camera and a display in the cabin? You want to know why such a requirement exists in the first place and why it has the value it does. What should the features of that camera be, how large and what resolution is the display? What decision-making led to those specific values for that requirement?”

“A good requirements engineering process ensures that the stakeholder needs get to the implementation through the various development iterations without losing any information, including the intent of the customer requirement. Also, no requirements should be added for which there’s no stakeholder.”

Why is it so important to record not only the outcome of a decision but also the decision-making process?

“You want to be able to make changes to your product quickly and efficiently. To do that, you also need to know the reasoning by which you arrived at a solution. If you don’t record the decision-making process, you have to redo the entire reasoning process whenever changes are made. You have to go through the whole process again and start thinking again at a high level about what the proposed change means.”

“When you do record the decision-making, you save an awful lot of time. Especially in organizations that work with many product variants. When you know that an adjustment only has to do with the distinction between variant 1 and variant 2, you’re done much faster. You can work much more efficiently.”

That’s important when you’re making a hundred different shavers.

“Yes. For numbers like that, when you bring good traceability into your requirements engineering process, your administrative overhead is almost gone.”

Trainer Cees Michielsen

To Michielsen’s big frustration, almost all requirements tooling vendors substantially lag behind the reality in product development. Things like traceability and the relationships between requirements have hardly been filled in in the software tools of suppliers like IBM and Siemens. “It seems as if they’ve never studied the stages that requirements go through from stakeholder needs to implementation. The lack of a functional and physical breakdown of the system means that you can’t link the requirements to those specific system elements. You’re actually missing most of the functional and physical breakdown – the left side of the V model.”

“I think vendors of product lifecycle management tools currently have too limited a view of the role of requirements engineering within systems engineering. In addition, they don’t or insufficiently support the left side of the V model. For this reason, I think they’re unworthy of the title ‘PLM tool vendor.’ After all, they only support a limited part of the lifecycle.”

Could you give an example to explain what’s wrong?

“In the traditional way of working, engineers keep track of the extent to which each part or product is part of a functional module. Take as an example a bicycle handlebar of type X with an integrated bicycle bell Q in the handle of that handlebar. For bicycle handlebar type X, this is a fixed component. Bicycle handlebar type X contains bicycle bell type Q.”

“Assume that bicycle handlebar type Y has multiple options for placing a bicycle bell, including an integrated version. Bicycle handlebar type Y optionally contains bicycle bell type Q. Traditionally, we record the relationship between the object bike bell Q with the bike handlebars X and Y as characteristic information of bike bell Q. This results in the object bike bell Q having to be modified each time with each new relationship with a bike handlebar. The version or revision number, the status, and so on. In addition, all existing links must be checked. This means a large administrative overhead.”

“But this really isn’t necessary because the object bicycle bell Q hasn’t changed at all. Only the relationships between the parts have changed. The solution is relatively simple: make sure that the information indicating the nature of the relationship between objects is a conditional relationship. However, this capability is missing from current tools. The administrative overhead works through to the requirements, which also describe the relationship to other objects as an attribute. We’re talking about tooling from the big PLM vendors here! At the moment, they just can’t do it. So there’s still a lot to gain here.”

You say that big players like IBM and Siemens with their enormous development departments aren’t up to date?

“They sure aren’t, yet. The requirements engineering practice has made huge steps, but these haven’t been followed by the tool vendors. Even smaller players like Top Team, Cockpit and Contact Software aren’t there yet. That’s a big frustration.”

New tool vendors have a market to conquer and should be motivated to add functionality.

“They don’t do that enough yet, while as newcomers, they do have the flexibility to do so. The Dutch company Relatics from Ridderkerk is a supplier that’s doing well, but they’re mainly focused on civil engineering and not mechanical engineering. Relatics has built its whole tool around semantic modeling, where you consider the whole world as objects and relationships between them and all the attributes that go with them.”

Requirements engineering also influences the way we look at product creation. In high tech, people often refer to the V model when they talk about the process from initial ideas to product implementation. This model starts with a functional breakdown, the left leg of the V. Michielsen: “A practical problem is that you can’t include all requirements in the traditional functional breakdown. That applies, among other things, to the physical properties of products. Mass, volume, that sort of information. It would be wise to start two parallel trajectories in that left leg. Because later it will turn out that in the ascending leg, when you integrate, you can’t test what you’ve specified. This occurs, for example, when a submodule or function is distributed or divided among several physical modules. In that case, you can’t test those particular subsystems as separate modules, one at a time.”

The subsystem can only be tested once the entire machine has been assembled?

“You would like to be able to test such a feature right at the start, but indeed, that doesn’t work. You then actually need two parallel development trajectories, including the responsibilities and budgets that you can allocate to them. Before you have anything made or assembled at all, you use simulation tooling to do a virtual functional integration and a virtual physical integration. The goal is to first establish that the design is correct. That everything works and everything fits.”

“When you get to the end of that virtual development, you also know exactly that you’ve developed the right building blocks. You’re complete with respect to functionality. At the same time, you also know where those building blocks end up in the different physical modules because you can demonstrate that through your physical design. Once it fits virtually, you start implementing, constructing, programming, and so on.”

The W model, as Michielsen calls this form of development, will be the topic of a separate episode in his trend series.

The system requirements engineering trend series is also available as Bits&Chips podcasts on Apple, Buzzsprout and Spotify.

This article is written by René Raaijmakers, tech editor of Bits&Chips.