The Need for Requirements Revisited

A Worthy Opponent

A few weeks ago, my wife forwarded me a link to a blog from a developer who had finally “seen the light”. That’s what she does, my wife, she sends me links. Of course, to understand that, you probably have to know that my wife is not only my wife. She is also my primary researcher (source of all my knowledge), my literary critic, (source of all my insights), and my guide in life (source of all my wisdom). But that is beside the point.

The point is the aforementioned blogger and his insights (or her insights – in the blogosphere, no one knows for sure. For the sake of simplicity – and not to affront any gender but my own – I’m going to refer to this individual in the masculine form. Also, to maintain the anonymity that is uniquely electronic, but to maintain the social conventions of referring to people by their name, I’m going to anoint him “The Man”.).

The Nature of Requirements — According To The Man

The Man’s insights had to do with user requirements. The gist of The Man’s blog was that user requirements are a joke. In his opinion, the problem is not that we have difficulty getting good user requirements; the problem is that we are wasting our time trying. To quote The Man, "did you ever notice that the applications and technologies we use most, probably >90% of the time, were never, ever conceived by the people that actual use them? For example, did you personally participate in the design and user requirements for email, browsers, operating systems, spreadsheets, microprocessors, word processing, disk drives, presentation software, monitor, voice mail, routers, etc? No. Nor is it necessary that you do. The very idea of a lengthy ’user requirement’ activity for technologies and applications is nonsense, absurd. "

So these applications, as I understand The Man, were, “obviously” designed by intelligent designers who understood the basic needs of all humans well enough to develop these products without bugging the fictive “process owners” and “subject matter experts” with questions and demanding decisions they (the process owners and subject matter experts) were ill-equipped to make.

The Logic of History

After reading The Man’s blog, I was elated. I (thanks to my loving wife) had finally found The Man. He was the Holmes to my Moriarity, the Superman to my Lex Luthor. The Man had seen the light and, in so doing, had ignited a light in my mind that darn near blinded me. The Man awakened me to my true calling, showed me my mission in life. I, the consummate requirements analyst, finally knew why I was put on this Earth. I was destined to fill this gaping void by reverse engineering the user requirements for these ubiquitous programs that have blessed our daily lives for so long.

Actually, I don’t know why it hadn’t hit me a lot sooner. I mean, it is common practice in Corporate America to buy a software product and then give the business analysts the assignment to define what the heck it’s good for. At least, that’s the way many projects I know about got started. Why, oh why hadn’t I applied this simple yet economically ruinous concept to the products upon which I depend for a livelihood? But enough of bemoaning fate, now I was finally, finally ready to seize the moment, to go where no man had gone before, to accept my destiny and, in so doing, to change the way the world perceived user requirements forever.

So without further ado (and we have had plenty ado, haven’t we?), let me start. To start with the obvious, since I had to use a word processor to capture my insights and revelations on this topic, I am going to write the missing user requirements for it. (As an added incentive, the recursive concept of using a word processor to capture the requirements for the word processor itself also appeals greatly to my inner Geek!) So, here are the first–cut, reverse–engineered user requirements for this versatile tool.

The Reengineered Requirements

1. The system should capture my keystrokes and render them electronic thereby allowing me to store them in files that I can never find again.
2. The system should allow me to change the files I have created and automatically save the changes in places that I would never think to look.
3. The system should automatically check my spelling while I type and distract me by red-lining any incorrectly spelt word.
4. The system should offer spelling alternatives for a red-lined word to further confuse me by suggesting words that I never even knew existed.
5. The system should auto-magically switch languages whenever my misspellings approach proper French, German or Italian words and assume that I meant to become proficient in that language. (Since I am fluent in German, I am astounded at the translated suggestions it offers.)
6. Once it has switched languages, the system should then assume that everything I wrote up to that point has to be rechecked to ensure that my text meets the spelling rules for this new language, adding additional comfort to my eyes with more red lines.
7. The system should further confound me by refusing to offer spelling suggestions for words that are not red-lined but for which I want to check the spelling in advance to avoid the red-line distraction.
8. The system should automatically inform me of grammatical strokes of genius by green-lining passages for no apparent reason.
9. The system should hone my social skills by telling me why it chose to green-line my text with cryptic messages that I have to call my 8th grade English teacher to translate for me.
10. The system should automatically format my text into bulleted lists, paragraphs, pages and tables in such a manner that it can truly confound my every effort to achieve a page break where I want it.
11. The system should wow me by numbering my numbered lists in such a way that amazes me and, again, removes any temptation to comprehend the rationale let alone manipulate the numbering to meet my needs.
12. Finally, the system should offer hope by allowing me to modify any and all settings and then confound me by hiding this flexible feature behind a barrage of menu entries and secret key strokes.
13. Oh, and one more thing. The system should be re-released every few years, just when I start to get the hang of it but before I gain the level of proficiency to which I strive and the new release should offer the same functionality as the old but better disguised behind yet again different modes of interaction such as “ribbons”.

The Last Word

OK, thirteen is the maximum number of requirements allowed for a tool this simple, so I have to quit now. At this point, I could launch myself into defining the user requirements for my spreadsheet program, my presentation tool, and (my personal favorite) my email / contact / time-manglement application that I rely on to keep my life orderly. Unfortunately, I am discovering that this is really hard work, so maybe The Man was right after all. We should just quit wasting our time trying to define the future features, functions, facts and behaviors that the proposed IT solution should enable, execute, enforce, or exhibit when it is delivered. We should just stand aside and let the developers like The Man do their job. After all, we are just annoying The Man with our “user requirements” and, obviously, the requirements don’t help The Man anyway. The Man knows what we need a lot better than we do, so let’s get out of The Man’s way and let The Man work, shall we?

Tom Hathaway
Managing Partner
Requirements Solutions Group, LLC

A Note from the Editors

For those of you who still believe in the critical role that business requirements play on projects (and we happen to belong to that esteemed group!), we at RSG would like to point out what we actually do believe.

1. There are novel, paradigm-changing applications for which asking the targeted end-users what they want would be a waste of time. To quote Henry Ford, "If I had asked people what they wanted, they would have said, 'A faster horse'." These projects require a guiding vision and a lot of luck to succeed. Just like any business endeavor, the failures far exceed the successes.
2. Applications that improve the way people work are best based on the experience of those people. If we ignore that experience, we ignore reality. A business is far too complicated to be run by technology alone. For the non-believers, we recommend studying the published failure rates (and reasons) for projects in our industry.

Whereas it might be a lot more fun and challenging for developers to work on projects as defined in point 1) (speaking as an ex-developer, I know it was for me!), there are a lot more projects that fit point 2). So, as a recommendation to The Man and others like him, you can spend your time and money looking for or inventing the next great gadget (and we sincerely wish you luck) or, if you prefer to make a living as a developer in the business world, you can also reduce your frustration by getting a better understanding of what business requirements are and why they are important. We offer a lot of courses on that topic.

Requirements Solutions Group, LLC.