Don has a great post on Single Point Requirements. You get one example of the requirements: “This product needs to do this. Just this.” Sure enough some months (or years) later, that single example is not sufficiently general to do everything you want the product to do.
That's ok, as long as you plan to iterate the product development. If you really think that one example is all you'll need, you will be bitten. But if you (and your customer) are smart enough to say, “Ok, we'll get this for now, and see what happens over time,” you'll be ready to iterate.
This happened to me when I was converting a database from one platform to another over 20 years ago. I'd received the spec for the database and assurances that the data was “clean.” I expected to spend up to a week on the script to convert the database and any cleaning by hand. Only the first 20 records in the database were clean. Ok, maybe the other 10,000 weren't really out of spec, but over 1000 were, and all in different ways. What I expected to take a few tries (I was reading the database off a tape and writing to another tape–this is the olden days), took weeks of finding all the ways the data could be dirty.
I learned several things from that experience: to use a lab notebook to record what I was doing, including what had worked and what hadn't worked; and to plan to iterate on anything that looked like it might be “the only way the data can look.”
Single Point Requirements Require Iteration:
I totally agree with Johanna’s post on the view that Sigle Point Requirements Require Continious Interations and multiple examples. Nice article and thanks for sharing your experience.
Regards,
JJ