Client requirements: Are they really infinite and unknowable?

A tale of Dostoyevsky, deserts, Wile. E. Coyote and Road Runner

By Gordon Rugg

“We always imagine eternity as something beyond our conception, something vast, vast! But why must it be vast? Instead of all that, what if it’s one little room, like a bath house in the country, black and grimy and spiders in every corner, and that’s all eternity is? I sometimes fancy it like that.”

“Can it be you can imagine nothing juster and more comforting than that?” Raskolnikov cried, with a feeling of anguish.

Fyodor Dostoyevsky, Crime and Punishment

If you’ve ever had to deal with a demanding set of client requirements, and you were offered the alternative of spending eternity in a black, grimy spider-infested country bath house, then you’d probably hesitate about which choice to go for.

At one level, client requirements actually are infinite and unknowable. At another level, though, there’s a more positive message. Yes, the complete set of client requirements is ultimately infinite and unknowable, but that isn’t the real point. The real point is that you don’t need the complete set. You just need enough for the task in hand, and that’s a much more tractable problem.

This article is about ways of getting your head round the concepts involved.

They’re important concepts, because they have far-reaching implications for how we approach the whole issue of requirements and what people want, not just for product design, but also for bigger issues like architecture and what people really want out of life, and how to design the human world to meet those wants and needs. Fortunately, the concepts required are actually fairly straightforward, if you have the right tools for thought. The tools for thought that we’ll be using in this article are a desert highway and a large number of scattered boxes.

Here’s an image of infinity. It’s a desert that stretches on forever. There’s a highway running through it, and a cactus to one side of the highway for artistic relief. Readers of a humorous disposition can imagine that Wile. E. Coyote and/or the Road Runner are hiding behind the cactus.

Now let’s imagine that this infinite desert contains an infinite number of red boxes. It’s tempting to think that the desert would now look like this.

(I haven’t tried showing every individual box, but you get the general idea.)

That is indeed one way of having an infinite number of red boxes in the infinite desert. However, it’s not the only way. Here’s another.

This version of the desert also contains an infinite number of boxes. They’re just much more sparsely scattered across it than in the first version. There are only two of them visible in this image, but because the desert stretches on forever, even if there’s only one box every ten square miles, there’s still an infinite number of them eventually.

Here’s an intermediate version, where the desert again contains an infinite number of boxes, but they’re not so sparsely packed.

There’s something else that’s different about this image compared to the previous ones. In this image, the boxes are showing a tendency to be more common near the road. There’s still an infinite number of them, but that doesn’t stop them from clustering in places.

Here’s yet another version. In this one, the boxes are strongly clustered near to the road, and also near to the viewing point at the front of the picture.

So what does this have to do with client requirements?

To start with, the set of possibly relevant client requirements is infinite, and therefore unknowable, like the potentially infinite number of boxes in the desert.

However, in reality, you don’t need to know all of the possibly relevant requirements. You just need to know a subset of the requirements, using a criterion such as “criteria that have a greater than one-in-a-million likelihood of cropping up during the lifetime of this product”.

That’s a completely different game, involving a much smaller set of requirements. Now, the requirements you’re dealing with are a lot more tractable. In terms of the diagram, it’s the equivalent of only having to deal with a set of boxes that are close to one particular finite stretch of the road, not every box across the whole of the infinite desert.

A second issue is that the product you’re designing fits within our present-day world. That also cuts down the number of potential requirements issues. There’s a lot of shared knowledge that you and the client can take for granted, such as what modern Western houses are like, and legal manufacturing standards, and standard grades of materials and components, and so on. That’s what I’m getting at in the illustration by having a lot of the boxes near the viewing point; a lot of the key requirements, options and constraints are going to be fairly close to what you already know.

There’s another factor that makes the problem even more tractable. Often there are numerous potential solutions, and you just need to know the requirements for the solution that the client prefers. That reduces the number of requirements still further. The problem now looks more like the diagram below, where the requirements for the client’s preferred solution are represented by the red boxes with yellow edges. There are only a few of them, and most of them are fairly near to the viewing position (there’s one beside the cactus that would be easy to miss, that I’ve included to make the point that just because the number of requirements might be tractable, that doesn’t mean that they’ll always be easy to find).

Conclusion

So, in terms of heavy meta-theory, we’ve seen that the landscape of infinity can vary from densely packed to sparsely packed, and that the contents of that landscape can be clustered close to your starting point – they don’t have to be scattered evenly across infinity.

Rephrasing that in practical terms of client requirements, we’ve seen that the number of possibly relevant requirements is infinite, but that in practice the number of relevant requirements can be much smaller and more accessible.

Looking forward from that conclusion, there’s a further set of issues about how best to find out which solutions appeal most to the client, and how to find out the requirements for the favoured solution or solutions.

I’ve already addressed some of those issues in a previous post about why users usually can’t initially know all their requirements, and how this problem can be fixed. I’ll return to this theme repeatedly in later posts.

Notes
Crime and Punishment is available on Project Gutenberg here for free download:

http://www.gutenberg.org/ebooks/2554

The cactus in the images is from Wikimedia:

http://commons.wikimedia.org/wiki/File:Cactus_chandelle.svg

For why clients don’t know what they want:

https://hydeandrugg.wordpress.com/2013/07/03/knowing-the-unknowable-revisited-why-clients-cant-know-their-requirements-and-some-ways-to-fix-the-problem/

Advertisement