High Tech Institute trainer Cees Michielsen highlights a handful of trends in the field of system requirements engineering.
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. In practice, however, you can’t include all requirements in the traditional functional breakdown. Typical examples are the physical properties of products – mass, volume, that sort of information.
It would be wise to expand the V model to what I call the W model. This model starts with two parallel trajectories in the left leg: the functional and the physical flow. Both accommodate separate system aspects: the functional flow is primarily concerned with ensuring that the required functionality is implemented, while the physical flow ensures that the physical aspects are budgeted down to the relevant system elements.
The two left legs join forces at the so-called ‘building block’ level, where the elements of a functional system, eg the braking system of a car, are specified and designed according to their requirements. These elements have both functional and physical characteristics. In the braking system example, one of the building blocks is the brake pedal, which is specified by functional requirements that make clear what the pedal is supposed to do and by physical requirements that specify the constraints concerning the pedal mass, the allowed design envelope, material and more.
Building blocks are defined at the level at which specific functionality is specified, designed and implemented. This doesn’t mean that they’re always single parts; they can be quite complex, like the motor of an electrical car. It is important, however, that they always have two ‘parents’: a functional parent (to ensure that the braking system can rely on the functionality of the brake pedal) and a physical parent (to ensure that the pedal fits the intended location and that it meets the volume restrictions in the driver’s cabin, as well as other interfaces).
The use of building blocks prevents models from becoming too detailed. At the same time, it enables practical product management, especially for complex systems, both within the product design and within the manufacturing domain. For an average passenger car, around 400 building blocks are defined; the latest ASML machines have around 2,000.
Once released, the building block design is virtually integrated into the functional and the physical structure, both all the way up to the system level. The purpose is to demonstrate that the design satisfies the requirements at each level, functional as well as physical. These are the two upward legs that form the middle part of the W model.
This approach has several advantages. It brings clear responsibilities at the system level for both functional and physical requirements throughout the system’s life cycle. It enables unambiguous budgeting of physical aspects such as mass and volume downstream. It facilitates the early detection of possible integration issues (“it doesn’t fit, product not balanced, too heavy, interfaces not adhered to”) – during the design phase, before regular product integration. It makes the responsibilities for the ‘functioning’ of the elements explicit – the team designing the braking system must demonstrate that it works according to the requirements; there are no excuses to wait until the whole product is integrated.
It’s good to realize that the average functional subsystem, like a braking system or a level sensor, doesn’t appear on a manufacturing bill of materials. You don’t order a braking system, you order its building blocks. This means that, in the manufacturing or logistic environment, it’s difficult (if not impossible) to say what function a component on the factory floor or even in the end product fulfills. If, however, you would follow the logic as explained in the W model, it would be a piece of cake as the implementation of the building block also traces back to its functional parent(s).