Product Requirements Specification: When Do You Need It?

by | 20/02/2020 | software engineering

Attention to requirements specification increased during the 1980s and 1990s in order to master the growing complexity of software and systems development. However, starting in the second half of the 1990s, the movement of agile development widely challenged the use of requirements specification documents.–Now, do we need product requirements specifications today?

The answer is: It depends. While a lean and agile approach to requirements and design is indisputably state-of-the-art, it may actually include the use of requirements specification. Because, sometimes, attempting to be too lean and entirely omit requirements specification does more harm than good.

When can you do without product requirements specification?

When is “pure” agile development without traditional requirements specification your best choice? These are situations where agile requirements practices mostly based on user stories will do a good job: One or few closely collaborating teams develop a system that exists in one or few instances only. This is, for instance, the case with low to medium size web services or mobile apps.

In addition to numbers of teams and product instances, you may wish a few more prerequisites to be in place for this approach to work out, for instance: Your development teams should have the opportunity of close customer and user involvement, and you may want your teams to be relatively stable (i.e., low turnover rate) over the system’s entire lifetime.

In this approach your requirements will hardly ever manifest explicitly in written form. User stories rather represent requirements but do not actually define them. Requirements mostly manifest in the implemented product release (or PSI, potentially shippable increment), and in your automated tests. But no kind of requirements statement will survive after the end of its development iteration or agile Sprint. The following figure illustrates this.Development without Product Requirements Specification

When do you need a product requirements specification?

There are quite some situations where you need a product requirements specification. (Of course, you should create and use it in a lean and agile manner.) These situations include:

High support and maintenance demands: Your customers or your business environment often raise questions of the types: Can the system do X or Y? What would be needed to accomplish Z? Having an up-to-date product specification will then tremendously ease your life.

Development of product variants: You develop not only one product but a wide spectrum of similar yet different variants. This is often the case with technical hardware/software devices like sensors or control units. Then you want to reuse existing assets instead of developing similar functionality again and again. Reuse of product requirements along with their implementation gives you the longest lever.

Subcontracted development: Here the degree of needed specification detail can vary, depending on your subcontractor relationship. However, nearly always some kind of requirements specification will form the core of the development contract. You better want to have this contract be clear and precise.

Regulatory compliance: You have no choice but to document your requirements explicitly. Requirements define essential product characteristics and design decisions that must be traced down further to implementation and test. The requirements specification also is the indispensable basis for controlled and auditable product change.

Wherever such situations exist, and they exist in tens of thousands throughout the industries, organizations will need product requirements specifications. These specifications complement product increments and preserve all relevant requirements information, as shown in the next figure.Development with Product Requirements Specification

Unfortunately, our competences to create and manage product requirements specifications have faded across many industries. Agile methods had too often been misunderstood that specification skills were not needed any more. And consequently, specification techniques did not keep pace with new agile approaches and have become outdated.

How can we revitalize effective and up-to-date requirements specification practices? The subsequent issues of this blog series propose an approach to requirements specification that fits well into modern agile product development and product management: