© Copyright 2001 Cutter Information Corp. All rights reserved. This article originally appeared in the January 2001 issue of Cutter IT Journal, and is reproduced here with permission.
>Contact Us for a Free Trial Subscription
>Read a Sample Issue


To the editor:

Stuttgart on a rainy October morning. No one to keep me company over breakfast except a back issue of the Cutter IT Journal. Oh well, invite it along for such insight as it may have to offer. Seems to be an issue about requirements engineering (see Cutter IT Journal, May 2000). No longer my field, of course. Now the strong voices are the Robertsons and Karl Wiegers, good people with fresh ideas. Look, there's an article here by Karl. Also Nancy Mead, another strong contributor. I know her from past work on the IEEE editorial boards, where she has been always incisive, always thoughtful.

So, why am I so glum as I read through the articles? Why aren't I saying, "Aha!" more often? So much of what I read on requirements strikes me as correct but somehow belittling of the problems real requirements efforts face. Take this suggestion offered by Karl: "Get extensive user involvement." He has gone to some lengths to show that projects don't fare well when they don't have extensive user involvement. So his advice makes sense, doesn't it?

The problem is that it is more or less the equivalent of a doctor's advice to "get healthy." (Or while we're at it, Steve Martin's advice on how to become a millionaire: "First, get a million dollars.") No doctor would tell you "get healthy" for fear that you wouldn't pay his or her bill. It's not really advice at all, since it's not explicitly actionable.

What your doctor might tell you is "lose weight." This is actionable, and it might be good advice for a given patient, but certainly not for all. It's not advice you'd want to fall into the hands of an anorexic teenager or a thin-as-a-rail elder. And there in a nutshell is the great dilemma of process: advice that is general enough to apply to all is platitudinous and almost totally useless; advice that is explicit enough to be actionable is no longer general. It may be counterproductive or even dangerous in some cases. Actionable advice when extensive user involvement is not forthcoming might be, "Try to get people fired when they don't cooperate with you." That might be the perfect prescription for one particular project, but certainly not for all.

I wish Karl had thought to tell us what to do when users won't get involved, when they're too busy or openly hostile, when they don't agree with each other, when they are unevenly involved, when some are so "cooperative" that they load the system down with extra "requirements," when we can't get to the real users because someone in marketing insists on fronting for them. These are the real problems of requirements engineering.

Elsewhere in the issue, Nancy Mead tells us about requirements management. Am I just grumpy, or does the suggestion that we managers manage abstractions annoy others as well? The Software Engineering Institute is particularly keen on this notion. It has us doing requirements management, process management, change management, customer relationship management, risk management, and configuration management. The trouble is that if you're a manager, you don't manage abstractions. You manage Carole and Elwood and Janeesh and Elaine and Chandra and Harold. When I think about "requirements management," I think about managing a person who is collecting and analyzing requirements. Maybe she is blue because progress is slow or because one user is problematic or because the work takes two steps forward and one back. Maybe she's tempted by stock options at a neighboring company. Maybe she's thinking of the pretty office our competitor might put her in instead of the noisy, crowded cubicle that is the best we can offer. These are the real problems of managing requirements efforts.

I liked the advice from Carol Dekkers and Mauricio Aguiar about scoping requirements with function point analysis (FPA). I just wish they had thought to tell us what not to do to make up the time that FPA will take up. (Come to think of it, I wish I'd thought to tell people what not to do in order to save enough time to follow some of my prescriptions.) We seem to be stuck in "add" mode, piling new methods and metrics onto a lifecycle and never taking anything away. No wonder our process is so heavy. No wonder we can't do anything quickly anymore.

Tom DeMarco
Atlantic Systems Guild
Camden, Maine

Cutter IT Journal | Cutter Information Corp.

Cutter IT Journal is published 12 times a year by Cutter Information Corp., 37 Broadway, Suite 1, Arlington, MA 02474-5552. Tel. +1 781 641 5118 or + 1 800 964 5118. Fax: + 1 781 648 1950 or + 1 800 888 1816. E-mail: info@cutter.com. Please contact customer service for more information or for a free trial subscription.

© Cutter Information Corp. All rights reserved. Unauthorized reproduction in any form, including photocopying, faxing, and image scanning, is against the law.