I think part of the problem is that the distinction between requirements and design makes it seem as if there are two levels. As you say in the article, these are really levels of abstraction. The way I look at is that there are essentially three levels of abstraction

• what the user needs — problem to be solved (Stakeholder Requirements)
• what must be done to satisfy the user needs (System Requirements)
• what will be built to do the work needed to satisfy the user needs (Design)

Other levels of abstraction fit inside one of these. When I first came across the idea of separating into three levels as opposed to two, I at first found my difficulty in separating Stakeholder and System Requirements changed to a difficulty in separating System Requirements and Design.

Then there is the question of choice. The stakeholder(s) have a choice about which problem to solve. Having decided that, the choice at the system requirements level of all about how much and how well that problem will be solved. In the limit, MVP versus big-bang. And design is all about choice.

And what is design? Design is essentially a decomposition of a system into a number of subsystems and their interactions / interconnections. And how do we define each subsystem? Through its system requirements and interfaces. This is how we get the “one person’s how is another person’s what”.