Requirements, Grandma, & Apple Pie

Posted by Tony Higgins on January 7, 2011

Today I was dragged into yet another debate between two co-workers on whether something was a requirement or design. Before that topic could be put to bed, the discussion took a right turn into whether the requirements were complete and sufficiently detailed. My earliest recollection of this exact same discussion was at my very first job out of college; it’s taken place countless times since then, and here I am (many) years later watching two people go through it – yet again.

Typically we’d go drag out the definition of a ‘requirement’ seeking enlightenment. Off to the “tablets” – the IEEE definition, and definitions from any number of prominent textbooks on the subject. But hang on – whenever you go about building anything you need to have some requirements. Even if they’re only spoken, or just in your head, you still need requirements. And we’ve been building things for a whole lot longer than there’s been an IEEE and long before any of those books were written. So a hundred or two hundred years ago if I asked “what is a requirement” what would the answer have been? Until I have the time to go research that, I’ll just rely on my time-tested method for getting answers … what would Grandma say?

Scene: Grandma’s kitchen years ago

Grandma has invited some people over for dinner and decides to bake an apple pie but discovers she’s missing a few ingredients. She decides to have me, a young boy at the time, ride my bike to the store to get them – a small bottle of cinnamon, a pint of cider vinegar, and a pound of sugar. She hands me some money and tells me not to make any side-trips since she wants the pie made in plenty of time before dinner. Knowing how easy I can head off on tangents (caused by things ranging from a turtle crossing the road to noticing the store-keeper’s daughter Donna), she writes all this down on a list and hands it to me.

Grandma made a series of decisions: she decided to have some guests over, she decided bake a pie, decided to have me go to the store, decided I should take my bike, decided I should get cinnamon, cider vinegar, and sugar, decided I should pay for it with the money she provided, and decided I need to go directly to the store and back. Before this mission is complete there are several more decisions needed but Grandma didn’t make them. Exactly which route I should take (there were three routes basically of equal distance)? Should I take the same route there and back? Which specific brands of these items should I buy? Which cashier should I use? Does Grandma want them in a box, paper bag, or a plastic bag?

When you boil it down, getting something done whether it’s baking a pie or building a software application requires a series of decisions. Somebody makes a decision, and others act on it. For those who act on the decision, they see the decision as a ‘requirement’.

Another way to look at it is that there’s no such thing as requirements or design, so we should stop wasting our time debating it. They’re all just “decisions” made by various people along the way, each decision aligned with the previous but getting progressively more detailed. I first heard this point of view from Alistair Cockburn in a Requirements.net podcast which I highly recommend you download and listen to.

Of all the decisions that Grandma made that day, not all were “requirements” for me. Her decision to have guests over wasn’t my requirement. I wasn’t even aware of some of her decisions, like the one to bake the pie at 350F. This wasn’t my requirement either. But many of them were, like these:

Use bike to get to and from the store
Get bottle of cinnamon, pint of cider vinegar, pound of sugar
Pay using money Grandma gave me
No side trips

But what about all those decisions Grandma didn’t make that I need answers to, like the route to take and boxes vs. bags? Are my requirements incomplete? Are they not detailed enough? The answer to this is “maybe”. It is possible that Grandma was absolutely correct in the set of requirements she had given me, and that it was her intention to leave all the remaining decisions up to me, trusting my judgment. From Grandma’s perspective the requirements she provided were complete and sufficiently detailed (we’ll call this the “I don’t care about the details, just get me my stuff” scenario). On the other hand, it’s possible that Grandma did care about the details but was in such a tizzy about these guests coming over she simply didn’t think things totally through. In this case my requirements were not complete and, unless by some miracle I make the exact choices Grandma would have made, things won’t be pretty when I get back (we’ll call this the “cider hits the fan” scenario).

The journey of building something involves a long series of connected “decisions”. Your process should describe when the decisions need to be made and who (or what group) makes them. Consider the set of decisions found in a Requirements document for a software application. Generally, this set of decisions is made by the client – hopefully leveraging the services of a Business Analyst – and they need to be acted on by the developers, testers, and others involved in delivery of the solution. As for when these decisions are made, as mentioned this depends on your process. In a traditional waterfall-style project these decisions are made early – around the 25% mark in the planned project duration. The classic pitfall is that waterfall-style processes often prescribe that these decisions must be made at an early point even if we lack information on which to base them. Not surprisingly some percentage of the decisions end up being wrong and the project suffers large amounts of unplanned rework. More modern agile approaches are based on the assumption that you don’t know everything at this early stage so the decisions are made incrementally along the way as you acquire valuable knowledge from building and testing “portions” of the system.

So where does the Business Analyst fit in? They play a critical role in helping to prevent the cider from hitting the fan. Their skills in analysis and facilitation help the client (Grandma) make the right decisions and clearly communicate them so that she gets what she needs to solve her business problem (impressing her guests with an amazing apple pie in time for dinner without going broke). Skill-full questioning and brainstorming discovers if Grandma does in fact care about some of the details she’s overlooked (she hates plastic bags), validates her requests (sugar now comes in smaller sizes so does she really need 1 lb.?), and explores the risks and their mitigations (if you see Martha “coupon-queen” Smith in the express line, head to a different checkout). As part of their job the Business Analyst recognizes and leverages the skills of the stakeholders like Grandma’s expertise in pie-making and check-out selection, and my expertise in high speed bike-riding while avoiding traffic – and Donna.

Try to avoid getting wrapped around the axel debating the line between a requirement and design. From what I’ve seen these debates really only happen around a small percentage of the “decisions”, but can be very distracting. Instead, focus on who should be making the “decision”(who has the expertise to make it, who has the ‘right’ to make it, who is impacted by it) and if this is the right time to make the decision (are other urgent decisions depending on it, do we have enough information to make it).