agreed to, you have 100% chance of making this schedule.
ALAN: As you add the high priority requirements, you'll see your probability of making a schedule going lower and lower, and eventually you'll either run out of high priority requirements, in which case you put some medium priority requirements into the baseline, or you may never even get to all of your high priority requirements before you get to the point where you're at risk of missing your schedule becomes intolerable. So, those two annotations and the balancing of the requirements against meeting the schedule, again, I don't know how to...I can't imagine working on Internet time without that.
CAROL: And we're talking about kind of the worst case. When you don't have solid users, when you're really trying to aim for a moving target, which is, you know, "What are the features that the marketplace is going to grab? What can we put in a Web site?" And I think that one of the things that we've seen is extreme programming come up when you've got a lot of requirements changing rapidly, that they can easily follow this type of thing, and I think they support a lot of the concepts that you're bringing forward, which is, "Let's grab something small. Let's grab the highest priority. Let's work on those." Rather than building this whole huge monolithic two-year set of requirements documents.
ALAN: Yes. I absolutely agree that the only way to build systems properly this day is to manage your requirements against your given schedule. And if your time to market says you must build things very, very quickly, and the only way of doing that is to build systems incrementally. The small increment initially, then a larger increment, then another larger increment, etc. It's the only way to do it. There are two advantages to that. One of them is you get to market fast. The other one is you get feedback from the customer base before you have to make commitments to the next generation.
ALAN: Which gets you a higher probability of actually meeting their needs in the long term.
CAROL: Now, what do you think is the right amount of effort to spend on requirements? I have been in a lot of the, you know, the newer shops, the older shops, and I have never once, and I have yet to be in an XP shop, which I'm looking forward to going into, but I've never seen users get up on a Monday morning and say, "Yes, today is the day that we get to do those jazz sessions or those focus groups, or ...... systems is going to listen to us." How do you get the user involvement? How do you get them to be involved productively, and what is the right amount of time that someone should spend on doing requirements?
ALAN: First of all, I have had different experiences than you. I find people very excited about doing that. Because they want to make sure they build the right system. So, from a development point of view, they want to make sure they build the right system and from a customer point of view they want to be involved because they want to influence the development organization to build the thing that they want.
ALAN: Than what someone else wants. So I see lots of enthusiasm in my world. As far as time goes, NASA has done a study that was published about five or six years ago that showed that, they had some studies,