Roger Cauvin had an interesting post the other day where he stated that “most organizations place too much emphasis on functional requirements.” The following day he expanded on this position by concluding that the overemphasis on functional requirements is detrimental to product development because “it shows the product manager dipped into design and failed to document true requirements.”
Although I think Roger raises an interesting question that begs further exploration, I must say that he absolutely failed to sell me on his primary thesis. I would parse his conclusion, as quoted above, into its two component assertions:
A) Creating functional requirements must involve dipping into design
B) Creating functional requirements must involve a failure to document true requirements
Perhaps this boils down to a question of semantics with Roger’s terminology, but it doesn’t seem that way to me. Yes, the boundary between requirements and design can be hazy and many a Product Manager has strayed too far, but I have seen examples too numerous to count of well-written requirements that held firm to “what not how.” At the same time, and most certainly not by coincidence, these well-written functional requirements were the direct outgrowth of a solid documentation of the underlying true business/user requirements. I would suggest that the former naturally flows from the latter, at least in the hands of a skilled Product Manager.
Having seen this question raised, I most certainly feel it is one that deserves a more extensive discussion at some point in the future. We’ll put it into the blog hopper with a plan to tackle it a little later on.
