By Jack Ganssle

I Desperately Need Stinkin' Requirements

Summary: We need requirements, and must spend more energy gathering them.

In a recent article on this site titled "I Don't Need No Stinkin' Requirements" (http://www.eetimes.com/design/embedded/4205794/I-don-t-need-no-stinkin--requirements-) author Jon Pearson writes about the all-too-real issue of dealing with changing requirements. He goes on to outline some very useful steps for handling such changes as the project proceeds.

But I take issue with the underlying philosophy, which is becoming nearly a universal scream in this industry, that requirements cannot be known more or less up front.

In my 35+ years in the embedded world I've seen that requirements don't change. At least not to the extent experienced by people doing, say, web design. Sure, there are tweaks and additional feature requests. And, yes, rarely a revolutionary twist requires a major redesign. But more often the requirements changes we moan about are a product of poor requirements gathering.

There's a meta-meme at work, one that's ever-more prevalent in today's vicious political arena. As an engineer I'm constantly appalled to listen to some pundit or soon-to-be convicted politician expound on how we should fix X, where X is really a symptom of some problem. Focusing on symptoms is like bailing a leaking boat. Better: plug the hole first.

And that's the issue here. Do a poor job at eliciting requirements and the symptom will be a never-ending scramble to patch up the project. Band-aids instead of avoiding the injury in the first place.

In the embedded world, poor requirements gathering is endemic. We jump in and start writing code and designing circuits far too early. Some agilists commend this practice; I think it's a mistake.

In many cases we blame outside forces. The boss wants us to start today. Marketing keeps making changes (see my thoughts on that here: http://www.eetimes.com/electronics-blogs/break-points/4204547/Listening-to-Your-Customers). There are truly forces at work that may be insurmountable, but all-too-often we're culprits as well, either in our zeal to get started or our unwillingness to educate the other stakeholders.

Shockingly, many of us know little about requirements gathering. Have you read a single book on the subject? Few of us have. (My favorite is Karl Wiegers' Software Requirements). I scanned the course catalogs of several universities and found not a single CS or EE course title or description that contains the word "requirements."

Yes, of course requirements change, and we need strategies for coping. But we have a responsibility to do a great job on eliciting them at the outset to ensure the project doesn't collapse. I'm reminded of an old parable: In ancient China there was a family of healers, one of whom was known throughout the land and employed as a physician to a great lord. The physician was asked which of his family was the most skillful healer. He replied, "I tend to the sick and dying with drastic and dramatic treatments, and on occasion someone is cured and my name gets out among the lords.

"My elder brother cures sickness when it just begins to take root, and his skills are known among the local peasants and neighbors.

"My eldest brother is able to sense the spirit of sickness and eradicate it before it takes form. His name is unknown outside our home."

There is no glory in getting the requirements right at the outset, but it's the essence of great engineering.

Published August 12, 2010