We did a design exercise with the leadership team in one of our global centers a little while ago. We had a lot of fun with the hands-on nature of the activity, and learned a lot from our de-brief afterward.
In our ensuing discussions, I noticed that several of our group used the word “requirements” when talking about the interaction they had with their “client” in the exercise. For example, “My user’s principal requirements were . . . ,” or “One of her requirements was that the wallet . . . ”
I pointed out that nowhere in the materials we had used for our exercise did the word “requirements” appear. Rather, it was all about gaining an understanding of user needs. And I challenged the team to think about the difference between “requirements” and “needs.”
This interaction reminded me of why I dislike the word “requirements” so much in software development. A “requirement” sounds so absolute, so dictatorial, so final. You can almost envision the all-powerful customer proclaiming, “I REQUIRE that the system does this.”
But no one talks like that—at least not the kind of customers that I have worked with. Instead, people say things like, “I would like it if the system could do X.” “I’m thinking that the app needs to do “Y.” “I believe it’s crucial that we have the Z feature before we release.” These are all statements of want or desire and feeling and belief. They might come from a very informed place, or they might be a whim of a thought.
But as soon as we turn these statements into “requirements” we elevate them artificially. These statements are not absolutes. They do not represent the edicts of a great and wise deity from on high. Requirements are not immutable statements of fact just waiting to be “gathered.” And they should not be the end of the conversation.
The discussion with the team concluded by saying that what we usually think of as “requirements” are ideas for how to meet the user’s needs. We discover a need, figure out one way to address that need, and bingo we have a “requirement.”
But this remains someone’s idea of what to build. Or several people’s collective thoughts about what we might create. And there are always other solutions to needs. There are invariably other ways to meet those needs that we haven’t yet thought of. And if we focus too much on “requirements” we forget to focus on the underlying needs. We miss opportunities to discover those alternative solutions because we have boxed ourselves in.
So let’s talk all we want about “ideas for what to build” or “deciding what to build.” But humor me and please don’t call them “requirements.”
Pingback: Maria Smith()