Requirements Are Not

I’m not the first person to come to this conclusion, but over the years, I’ve really come to dislike the entire concept of a “requirement.”

I’ve learned that so many things that look like “requirements” really are just a perception, or assumption, or an illusion.

Customers especially think they have “requirements” but really they’re just a hypothesis on what might solve some probably unstated problem.

Stakeholders have “requirements” that are really just their personal theories or assumptions on what might solve again a probably unstated problem.

On the other hand, I’ve learned that the true requirements are often not at all obvious at the start, and mostly emerge later when observing and interacting with real users.

I’ve also learned that the design directions you take will often lead to very different functional requirements.  It really is true that form and function are completely intertwined.  The old Waterfall theory of software had it essentially backwards.

It’s also rarely black and white, where a requirement is either totally absolutely essential, or not.  Very often you can build up the value in one area to compensate for other areas.  Or, if something isn’t feasible technically, we can come up with other approaches that suffice, or even work better.

I find defining and designing product is more like cooking in this respect in that if an ingredient is unavailable, you can often get creative and substitute something else or a combination of things that aren’t quite the same but may be even better.  It’s the result that matters, not our pre-conceptions.

I much prefer Agile methods like Scrum over Waterfall because of how much less weight is given to “requirements” in Scrum.  However, even if expressed in a user story, there are still dangers with Product Owners and their teams thinking something is more of a “requirement” than it really is.

Our only real requirement is to discover product solutions that work well for our users, our customers and our business.