How many requirements do we really need?

It is astonishing how many - or how few - requirements are articulated for comparable products. The automotive industry is notorious for the sometimes incredibly high number of requirements (Audi recently named the figure "60 million" in a keynote speech). Of course, this is not entirely fair: after all, requirements have to be formulated at many levels. Nevertheless, we sometimes find tens of thousands of requirements for comparable products, and sometimes only a handful. Why is this the case, and what can we learn from it?

Separate levels

If we were to install a finished microchip with billions of transistors, then of course we would not count the chip manufacturer's internal requirements. The Audi example (60 million requirements) is therefore not entirely fair: on the one hand, we are talking about 100 vehicle models, and on the other hand, requirements from different levels have certainly been included here (customer requirements, system requirements, etc.). But even if a clear distinction is made, we find large quantities of requirements in the automotive sector: When tendering for a component, it is not unusual to receive specifications with tens of thousands of requirements.

Tens of thousands of requirements in a specification sheet are not unusual [tweetthis]Tens of thousands of requirements in a specification sheet are not unusual[/tweetthis]

In a requirements specification, we should assume that the requirements are at the same level, at least for the most part. The requirements should describe how the component behaves without going into the implementation. We'll look at whether this is always the case in a moment.

Sometimes three requirements are enough

The three requirements used by Wikispeed to describe the body are a stark contrast (from 8:45 in the video):

• Must pass the offset frontal impact test
• Must cost no more than $5000 in material
• Must have 3 m³ of lockable space

Now you can rightly say that this is not enough to commission the bodywork. I'll go into what's missing in a moment. But: even if something is missing here, and traditionally there are a few too many in the tens of thousands of requirements, there is a discrepancy here that cannot be ignored. Why?

Extreme Manufacturing: How to design, build and sell a roadworthy car in seven days

Interfaces

Interfaces are an important aspect: The interfaces are also described in a typical requirements specification. If these are not explicitly separated from the requirements, they are typically included.

Lumping requirements and interfaces together is not a good idea: the requirements describe what is to be developed. The interfaces represent the framework conditions under which the solution is to be realized. However, this implies different stakeholders: The requirements have a meaning for "outsiders": Users, investors and authorities. The interfaces, on the other hand, only affect the parties who use them. In the case of the bodywork, for example, this would be the team responsible for the chassis, as these two parts are to be connected. They can clarify this among themselves without having to involve the external stakeholders.

Another common situation is the use of a standard interface: for example, it would never occur to the developer of a coffee machine to specify the plug for the power supply. It would be sufficient to reference the corresponding standard.

Layers will break through

Even if it has not been explicitly mentioned up to this point: We naturally want cleanly separated layers, modules or components. We would prefer to buy components off the shelf without knowing anything about their inner workings. Unfortunately, this is easier said than done: in practice, the encapsulation of components is often broken. There are many reasons for this, two of which are worth emphasizing:

1. Insufficient experience in writing requirements. Writing good requirements is damn hard! A popular beginner's mistake is to describe the "how" and not the "what".
2. Functional aspects run through many layers. A function (e.g: "Illuminate street" can run through many layers: How do you deal with it, should it be repeated at every level? In addition, sometimes a technology that has nothing at all to do with the function makes its way to the customer. Examples are "Xenon light" or "Intel inside". Here, too, the separation is difficult to maintain.

The situation is also exacerbated by the fact that the relationships and dependencies are not always clear, especially in document-based work. Requirements are then copied from generation to generation because nobody dares to delete them. After all, they could be important.

Too many demands are unhealthy!

The initial question was: How many requirements do we really need? There is no general answer to this question, but there are guidelines. These guidelines go hand in hand with other recommendations. For example, we can hardly make a recommendation for the length of a specification without first clarifying whether the interfaces are part of the specification or not.

Hence my recommendations:

• Effectiveness stands and falls with breaking up the system to be developed. If a system is poorly designed, it artificially complicates the interfaces and frustrates the team.
• Interfaces should not be mixed with requirements. In addition, requirements should describe the problem, not the solution. Working with interfaces could be a separate article.
• The requirements should fit on a maximum of 5 pages. This does not include the cover sheet, etc., i.e. really only the request text. This rule may be broken. But we have to be guided by people's ability to absorb information. It is comparatively easy to recognize contradictions on five pages. On 50 pages, it is much more difficult. Incidentally, I deliberately used the word "pages" here. Of course, models can also be used. In this case, a "textual representation" of the model should not include more. And if it should be much more: Go back to the first point and break it down differently (or further).

Conclusion

Three requirements for a body is extreme, and many manufacturers will not practically be able to go to such extremes. But 10,000 requirements for a specification sheet is a time bomb, as dozens of errors are guaranteed to lie dormant in such a work.

Five pages of requirements, without interfaces, that's my pi times thumb recommendation. You can work with that.