Trend 3: Traceability

The principle idea of traceable requirements is really cool: being able to both top-down follow a requirement from its creation to its implementation and bottom-up from its implementation to its origin. Most textbooks give good-looking diagrams and tables showing how requirements are linked to other requirements and test cases. Unfortunately, these diagrams and tables have little to do with everyday practice.
 

System requirements follow systems engineering principles. Let’s take the example of a waterway lock. At the system level, there will be a requirement stating that the lock shall enable boats to travel upstream and downstream through the canal. How to break this down if we haven’t yet decided how to solve the problem, or in requirements terminology: how to satisfy this requirement?
 

In practice, we see a large variety of solutions, from the magnificent Scottish Falkirk Wheel (a true boat lift) to the Dutch locks at Eefde. Two completely different solutions for the same problem. So, what to do with the traceability of our system requirement?
 

In the case of Eefde, a lock consists of two gates and a chamber. Each component has its own capabilities but none of the components can satisfy the system requirement on its own. That’s why we need the design decisions as an anchor point in the requirements flow (top-down, requirement to design decision to requirement) and in the trace-back (bottom-up). Through the design, we understand that when we open one of the gates, the water level in the chamber will become equal to the level at the opened gate. Subsequently, the boats can move into the chamber through the open gate. Therefore, one of the so-called derived requirements for the gate subsystem is that it can be opened and closed.

[Courseinstructor heading=”‘Why do we have this requirement and why does it have this value?'”

The questions that we need to answer and for which we need the bottom-up traces are: why do we have this requirement and why does it have this value? The answers can only be found through traces from requirements at the subsystem level to the design decisions one level up, in our case the system level of the waterway lock.
 

System engineers also need to deal with resource budgets, like mass, volume, energy, operational space and material cost. All of these enter the requirements specification at the system level as individual requirements, but they’re never passed on to the subsystems without analyzing them in coherence, creating a design that takes all pros and cons into consideration and finally deciding on which solution best satisfies these system requirements.
 

In reality, there are many dependencies between, in this case, resource property requirements. Especially in the automotive industry, mass and material cost are two vehicle properties that are strongly intertwined. At the system level, the overall mass budget is established: the vehicle shall weigh less than 1,500 kg, and so is the material cost budget: the total cost of materials shall not exceed 7,000 euros. Then, in case tough decisions must be made, a priority is determined, eg less weight is more important than material cost.
 

The design will try to find a solution for this and allocates budgets for mass and material cost, balancing these requirements and, at the same time, assuming certain capabilities of the subsystems that contribute to these budgets. Finally, when a decision is made for a solution, parts of the mass and material cost budgets are allocated to the subsystems.
 

If you’re responsible for one of these subsystems and were given a mass budget of 100 kg, where would you look for answers to the questions: why do I have a mass budget and why is it 100 kg?