Trend 1: Getting you system requirements complete

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.