spending the money, or committing the money, before seeing a floor plan.
CAROL: Oh, no, if they came up to something and saw a foundation poured, I think there would be major trouble.
ALAN: Right. Yes.
CAROL: Well, go on.
ALAN: You also hinted here in your last question about the relationship between design and requirements.
CAROL: Uh hum.
ALAN": The floor plan of a house is really the architecture...the architectural equivalent, there would be architectural design of the software. And so what you're actually bringing up now is another issue, which is, "Shouldn't you have an architecture?" Shouldn't you need an architecture before you commit large amounts of money toward development. And I think that's true also. That would fall very nicely into a talk like this on designing in Internet time.
ALAN: As opposed to requirements in Internet time. Now, the case of designing in Internet time, I agree with you, before you commit to large sums of money to build your product, you must have a design, the floor plan of the house, so to speak.
ALAN: If you want to get back to the requirements analogy, and would you even need the requirements for the house before you want to commit to building it, and I say, obviously, yes. You want to know what the house is going to look like, how many rooms it's gonna have, even re-plan of the floor plan. And we will talk some more after the break.
CAROL: Yes, we will. And we'll sum up and come back more with Dr. Alan Davis. And we've been having a wonderful hour here talking to Dr. Alan Davis about requirements management in Internet time, and our time is almost up. I can't believe it. We have talked about some of the things that we should be doing, the fact that we can't ignore requirements, that they're very important. One thing that you mentioned earlier that I think is...that some people may have picked up on and some might not have; you mentioned earlier about letting the schedule drive your requirements.
ALAN: Um hum.
CAROL: Rather than the other way around. And I can see some people probably squirming in their seats and saying, "Ooh, that's not the way TSP or PSP or some of these new things tell us we should do, and CMM doesn't say that." Do you want to elaborate a little bit more on that?
ALAN: Yes, absolutely. I think it is a very new idea. I've not seen it written about anywhere, but I see companies over and over again getting into a dilemma where marketing defines the market window, and they're basing it on their experiences and their intuitions, and their knowledge of the marketplace, and they say, "We need to have the product out in nine months." And then they list these 200 requirements, let's say 100 requirements. And then everybody tries to figure out how are we going to cram these 100 requirements into the deadline. The fact is, that the deadline tends to be very, very firm. The requirements are very pliable. They're giving any one number of requirements in many ways of solving that requirement, some of which are very simple ways that would just capture the marketplace easily, some are providing the customers with exactly what they want. So, there is full spectrum there, plus given all the requirements not all of them are absolutely essential. It seems so natural to me to take that deadline, which is absolutely firm, and figure out which requirements can be done realistically