Clients don't always say what they mean

When I wrote my last post, I worried [rightfully so, it turns out] about readers reading too much into the example client requirements. My intent was to simply explain how to breakdown a chunk of verbiage into a checklist of manageable requirements. Unfortunately, I planted a few too many language bombs in my contrived example and a former colleague (Craig Walker) ran with it and posted a follow-up over on his blog.

Craig focuses on the first and last sentences of the example requirement verbiage. My intent was to use those sentences as examples of non-requirements, since they merely expressed opinion and speculation from the client. But, as Craig astutely pointed out, they are good warning flags that what the client expects doesn't match up with what the client requested. The client expects fewer mistyped passwords and better security, but the client requested changes that might not necessarily deliver those results. Craig outlines some guidelines for digging deeper and finding the root cause of the problem rather than taking the client's proposed solution for granted.

As a side note, if you're not subscribed to Craig's blog feed, I highly recommend it. He's one sharp guy. He was my right-hand man in the Java world for a great many years and he recently set off on his own to dabble with .NET, which he rants about quite frequently in his "Stupid .NET Tricks" posts.