Month: July 2022

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?

Can we objectively say that a requirement is of good quality? What would be the measure for good? Is there something like ‘good enough’? Most of the answers to these questions can be found in the work of Philip Crosby, William Edwards Deming and Joseph Juran. These three quality gurus are no longer among us, but their ideas remain a great source of inspiration.

As requirements are the result of a requirements engineering process, it seems logical to check if a requirement meets the goals of the process. Firstly, the stakeholder needs have been established, and secondly, a correct and complete transition of the stakeholder needs is ensured up to the decomposition level where requirements can be implemented into hardware or software components. I will focus here on the second goal.

A distinction is made between intrinsic and extrinsic requirement quality. Intrinsic means that the requirement’s quality is determined by the way it’s documented or presented to the reader – the requirement’s syntax. This can be either purely textual or embellished with images, tables and more. The check can be done, in theory, by persons or applications lacking subject matter knowledge. They don’t need to understand what the requirement is about but rather see if it violates rules for writing requirements. Deming speaks of “pride of workmanship” and “well-crafted requirements.” In the course of the last 10-15 years, software tools to support these quality checks have become more and more advanced. In tools such as QVScribe, checklists like the Writing Requirements guideline of the International Council on Systems Engineering (Incose) are completely embedded and intrinsic quality checks are fully automated (including various requirements templates like EARS and IREB).

Note that the intrinsic quality only covers one-third of the total requirements quality. But the intrinsic quality checks do have value. If they’re carried out and corrections are made before the requirement is reviewed by subject matter experts and relevant stakeholders, these tools can save time and indeed be helpful to improve the quality of requirements.

But tools won’t help you determine if your requirement is meaningful to the intended audience. This is where the extrinsic quality of requirements comes in. It applies in two directions: back to the stakeholders who requested a specific feature of the product to be developed or a product characteristic or behavior (the source audience), and forward to the receivers of the requirement (the target audience).

Let’s consider the following requirement: “The responsiveness of the system shall be less than or equal to 0.5 ms.” This requirement will most likely pass the automated quality checks with flying colors. In practice, it’s often formulated as: “System responsiveness: ≤ 0.5 ms.” Would you say these requirements are of equal quality? From a syntactical perspective, the first will give a higher score as it contains a directive, but it isn’t until we ask the relevant stakeholders that we have some idea whether the intended meaning was translated correctly.

[Courseinstructor heading=”‘equirements engineers need to have their requirements checked and judged.'”

Quality is conformance to requirements, says Crosby. Did we, as requirements engineers or business analysts, correctly translate the stakeholder’s need into a system requirement? This can only be answered by the stakeholders who posed the original need. So requirements engineers need to have their requirements checked and judged – an activity that’s perceived as difficult.

Suppose the customer says that the engineer hasn’t understood the request? Or that he completely missed the point? Such feedback isn’t always pleasant and that causes a requirements engineer to avoid these confrontations. He often takes the safe route by contacting someone from the project to represent the customer or stakeholder.

That’s not a smart attitude. We want to make sure we’ve understood the stakeholder’s needs and translated them correctly and completely into requirements. Therefore, there’s no other way than to ask these difficult questions directly.

Quality is fitness for purpose, says Juran. Requirements must contain sufficient information and detail for designers to come up with solutions. The requirements are expected to be quantified to enable testers to verify and validate their successful implementation. In short, they must be clear, unambiguous, meaningful and have sufficient detail for those who receive the requirement as input for their work.

I’ve seen cases where no requirement documentation existed between an OEM and one of its component suppliers. Just a verbal agreement. Although this may seem an unacceptable situation in some cultures, the goals of the requirements engineering process were met. The supplier has been delivering the component with constant quality to the satisfaction of the customer for over twelve years now.

What would you do in situations like these? How do you see the quality of requirements in your company? How would you handle stakeholder needs like “I want the next version of the car to be more energy-efficient”? I’d be happy to hear from you, to learn and pass it on.

A question that pops up in almost all of my system requirements engineering classrooms is: how can we make sure that our requirements specification is complete? This is a valid question. Missing requirements usually means missing capabilities of the products we’re developing. It will have consequences for the success of those products. Either users of a product are disappointed because they expected something that’s not delivered or the product isn’t competitive enough compared to others with similar functionality.

Practice shows that requirements specifications are seldom complete. It’s just very difficult to make and keep them complete. Fortunately, over the past decades, we’ve learned some techniques and methods that can help us in our pursuit of completeness.

First of all, templates and checklists really work. Originating from the early days of engineering, they help us not to forget the obvious requirements. Today, there’s help abound. The internet is littered with checklists especially focused on requirements.

 
You’ll also need to do some digging yourself: find all stakeholders with a potential impact on the product’s success. Forgetting stakeholders often means that you also won’t capture their needs and expectations of the product’s capabilities. That’s a recipe for failure. Of course, you’ll have to question and challenge your stakeholders to find out what their real needs are. It also helps to make these needs explicit. Don’t invite the fire brigade when you commission a newly-built tunnel just to find out that you may have missed some essential safety measures. You need to involve the firefighters in the early stages during requirements gathering.

 
Make sure to look at the product-to-be-built from different perspectives. View it through the eyes of actual users, owners and investors. Include stakeholders who also experience the negative effects. These perspectives are sometimes best described in a concept of operations, user stories, use cases and scenarios.

 
Realize that the requirements elicitation step (where you identify stakeholders and their needs) takes place at every decomposition level of your product architecture for every system element! At each level, you’ll find new stakeholders specific to that system element at that level. Think of software coding standards in a multidisciplinary product.

 
Analyze the needs in a structured manner. This means differentiating between the main function of a product and its subfunctions, between a function, its properties and its design constraints. In the end, you need to find a balance between performance and resource property requirements for functions.

 
If we take a passenger car as an example and say that “transporting people” is its main function, we need to express and quantify how well we need to transport people: how comfortable, how reliable, how many people, how safe? These are examples of performance properties (or qualities) of a function. They’re balanced with the resource properties, like: how much energy may this performance cost, how much material cost, how much noise? Whereas the analysis identifies the functions, properties and constraints, the requirements specification step quantifies the properties.

 
This is part of the structured requirements analysis method and is one of the effective ways to discover the so-called emerging properties – properties that weren’t requested by any stakeholder but represent a specific product aspect resulting from choices made in the design. For example, choosing a combustion engine gives noise and toxic gas emissions as emerging properties. Some of these emerging properties may suddenly become very important after having been disregarded for a long time, as we’ve seen for NOx emission. Point is that once a design choice has been made, you should look at the consequences (good, bad and ugly) to see if new requirements should be created to manage the emerging properties.

 
Over the years, the names of the product development departments have changed quite a bit, especially the groups responsible for writing the requirements at the product (or system) level. From product definition, via systems engineering, we now see groups (sometimes departments) named in such a way that it’s very clear what they stand for, like “Product Properties and Customer Functions.” Similarly, the title of Porsche’s Hansjörg Maier says it all: “Leiter Produkt-Eigenschaften und Kunden-Funktionen.” This gives a tremendous focus on what’s key for the product, both its functionality and its properties, and what makes the product stand out from the competition.