Defining, and then detailing requirements is a challenge of its own. While defining requirements is essential, detailing it is often overlooked. And,  when doing so, the devil is always in the details.


Writing software that fully meets its specifications is like walking on water. For each, the former is easy if the later is frozen and near impossible if fluid.

– Unknown

When I worked IT services, we got a lot of joy out of this cartoon. (I don’t know who made it, but if you do, let me know so that I can credit them.)

The-software-project

While it might seem overly exaggerated, trust me when I say this, it does happen. More often than not, what the customer explained, was not documented – and that is the root of the problem. Even when the customer’s requirements are well understood, documentation ensures that everyone is on the same page (pun intended). And, this is more important when you consider where and how requirements are typically used.

When a prospect, that’s where customers/clients come from, want to engage an implementation partner, a proposal (bottom line: estimations and commercials) and agreement need to be prepared. Even with existing customers, enhancements require estimations that need approvals. These estimates are based on requirements, and how well they are defined, tends to make the estimates that much better. And, it doesn’t stop there.

The execution team, development and quality assurance alike, tend to base their plans and implementation/testing approach on the requirements – either detailing it further, or if detailed enough, using it as is. It also helps define the scope of the feature – the length and breadth of what needs to be implemented, and how it needs to be implemented. But, more on that in the next one.