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

[article]

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.

CAROL: Yes.

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

About the author

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!