e-Talk Radio: Davis, Alan, 8 March 2001


military-type or the large Department of Defense-type applications. So, Alan, before we went to break you were talking about this Internet time, what types of things we should be doing, and let me let you finish your thoughts there.

ALAN: Thanks, Carol. Just before the break I had mentioned there were three aspects of requirements management, let's talk about each one, and how you can diminish the effort without hurting your risk, or damaging your risks, too much when doing things in Internet time. In the category of elicitation, I would argue that no matter how pressured you are to build things fast you have to understand your market. An elicitation is nothing other than learning what your marketplace needs, and if you don't have a handle on what your marketplace needs, how can you possibly build a system that's going to be right. You could be absolutely lucky, and if you want to base a business on luck I would consider that be a highly dangerous route, especially for your investors.


ALAN: So, I would think at a minimum you want to do a market analysis. You want at least to do some interviews with some candidate customers. I happen to love brainstorming. So, I'd bring in a half a dozen people in the room who are experts in the marketplace and do some brainstorming for a half a day at an absolute minimum, just to understand what that marketplace does. When I was at Requisite, this is like seven or eight years ago we started...we did not want to talk to individual customers who had not yet produced our product. We basically brought in Ed Yourdon and myself as consultants in the requirements management space to act as surrogate customers. That is something you can do if you don't have access to immediate customers in this spot, find someone who knows the customer base.

CAROL: Right.

ALAN: That is an absolute must. You cannot get away with it...you can't get away with not doing it. You can do a triage - again I think it is absolutely essential to use a triage, even with time pressure. After all, what you're actually saying is, "I have a time constraint, I have to get this thing out in two weeks, two months, or two years, whatever it is. What can I do realistically within that time limit?" So, if you don't go through that process, what you're going to end up being is late for market.

CAROL: Right.

ALAN: What you should do in triage when you're in time constraint, is pick your schedule first. And then hack requirements into your baseline, accept requirements one at a time up until that's to a point where your risk of missing your schedule is too much for you to tolerate.

CAROL: And would set priorities there? You don't just randomly say, "Okay, this one is going to fit, this one is going to fit."

ALAN: Yeah. Absolutely, you're right, Carol. What you want to do when you collect the requirements during elicitation is entertain every requirement at least in two ways. The first way is, what its relative priority is in impact on the market.

CAROL: Right.

ALAN: The second one is, you must annotate your requirements in terms of how much effort you think is required, just a ballpark estimate of how much effort is required to satisfy the requirement. And with these two numbers, you can now start picking requirements from the high priority list and placing them in your baseline. Now, initially when you have no requirements

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

About the author

Carol Dekkers's picture Carol Dekkers

Carol A. Dekkers is President of Quality Plus Technologies, Inc., a management consulting firm specializing in creating peace of mind for companies who want to improve their software processes. Software measurement, software quality, process improvement, requirements, and software sizing (using function point analysis, as an example) are a few of the Quality Plus areas of specialization.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!