Everything begins with the customer. With your customer!

At the beginning of product development, there is no technical process. What matters is the person who will ultimately hold the product in their hands. Who is this person? Do you know what matters to them, what they pay attention to, and why they would buy your product?

Answering these questions allows you to condense a requirements list that connects the consumer's wishes with technical feasibility and economic considerations. This list is sorted hierarchically and accompanies the project from then on as a binding reference.

What is the purpose? Over the course of a project, requirements, constraints or setbacks emerge that could not initially be foreseen. A sub-supplier might discontinue production of a necessary component. Or a seemingly minor change leads to disproportionately higher tooling costs. An unwanted chemical process causes problems in manufacturing. The required recycled material cannot be sourced.

In practice, these examples lead to conflicts in goal definition. For instance, a desired feature cannot be realised within the cost framework. This is where the requirements hierarchy comes into play: a look at the list reveals which requirement takes precedence when customer requirements, feasibility and economic viability conflict with one another.

In research, this ordering is called requirements prioritisation. One of the most established methods, the Analytic Hierarchy Process by Thomas Saaty, follows the same basic idea: it structures the decision problem as a hierarchy of goal, criteria and sub-criteria, and derives a ranking of requirements through pairwise comparisons.

“Without a hierarchy, a conflict of goals sparks a discussion. With a hierarchy, the answer is already there."

The Kano model can be used to classify the type of a requirement: some things a product simply must be able to do, others increase satisfaction proportionally to their fulfilment, and still others positively surprise the customer. However, this classification alone does not determine how much weight an individual requirement carries in a conflict; we define this weighting individually for each project.

Why early testing pays off

From the hierarchy, we distil the technical feasibility: we check what can be built, and how. But the loop remains open, and at every milestone we ask the same question again – does what has been created still fulfil all the requirements?

In quality management, the rule of ten describes this relationship as a rule of thumb: for every phase a requirements error survives undetected, the cost of fixing it roughly increases tenfold. A NASA study quantified this increase for complex systems: if fixing the error costs one unit during the requirements phase, it costs three to eight units during design, up to sixteen during manufacturing, up to seventy-eight during testing – and many times that during operation.

This means a large part of the later manufacturing costs is already determined during the concept phase. Testing early and repeatedly is therefore the most economical approach.

---

Sources

1. Saaty, T. L. – Analytic Hierarchy Process (1980), applied to requirements prioritisation by J. Karlsson. Application to product requirements: Prioritization of Product Requirements using the Analytic Hierarchy Process (2012).

2. Kano, N. et al. – Kano model (1984); overview: Empirical research on Kano's model and customer satisfaction.

3. Stecklein, J. M., Dabney, J. B., Dick, B. N., Haskins, B. et al. – Error Cost Escalation Through the Project Life Cycle (NASA/INCOSE, 2004).

4. Stecklein, J. M., Dabney, J. B., Dick, B. N., Haskins, B. et al. – Error Cost Escalation Through the Project Life Cycle (NASA/INCOSE, 2004).