Pareto and Non-Functional Requirements: Is it Really Done once "It's Working"?

Time to Read 2 min

Innovation departments and start-ups, especially those that arise from research projects, invest a lot of time and money until the principle or the product works. And then they think: "If it works, we have achieved 80%!"

Even if it is a harsh statement at that moment: we often see that the actual function, the "secret sauce", is only a small part of the effort. This because as soon as a marketable product is to be created, two types of non-functional requirements come into play, which easily account for 80% of the total development effort.

One category are customer-oriented non-functional requirements: usability, industrial design, manufacturability (i.e. unit price) etc. In many markets, I think most, the actual function is a given. What drives success is differentiation through e.g. intuitive operation or through the larger touch display, even when the underlying function is not the best in the market. Just think of the (for its time) inadequate technical data of the first iPhone...

The other category consists of regulations which are even more underestimated: electromagnetic compatibility (EMC), personal and fire safety, explosion safety (Ex, ATEX), functional safety (FuSa), cybersecurity and privacy, reliability etc. required for a CE or UL certificate. All these aspects can affect the whole product including software, electronics and mechanics. If these issues are not considered from the first sketch of the idea, then the whole concepts may have to be revised again. And according to Murphy, it always affects the parts whose change generates the greatest effort.
In this area, the perfidious thing is that there is no Minimum Viable Product (MVP) that is only partially safe or only partially compliant with standards. The engineers are forced to take the development to the end because otherwise the product is not allowed to be sold!

This is why I think it is worthwhile from the beginning to include as many non-functional requirements as possible in the product design, at least conceptually. This helps to avoid surprises and to secure the business case.

In both categories we can support you with concepts, solutions and also with the estimation of possible efforts.

Andreas Stucki

Do you have additional questions? Do you have a different opinion? If so, email me or comment your thoughts below!