Requirements are just a starting point?or at least they should be. I?ve had many customers who feel that once they?ve documented their requirements their job is nearly over. Many seem to feel that requirements get dumped into Visual Studio and out comes an entire system. I am exaggerating, of course. However, I am routinely asked to give a fixed price bid, for instance, to a set of requirements. This is absurd and dangerous at best. On larger projects it is negligent, in my opinion. There is just too much risk involved. I explain it to customers like this: ?I can estimate how long it takes a developer, given a particular architecture, to code a screen, a business object, a database table, a stored procedure, a service, and so on. However, I can?t tell you how long it takes (or how much it costs) to satisfy a requirement.?
What is required, of course, is decomposition of those requirements. This means analysis, the creations of use cases, a functional specification, a solution architecture, possibly a prototype, logical models, and physical models. This is hard work. However, it serves to validate and refine the requirements as well as eliminate a lot of risk. These deliverables also lead to artifacts (forms, classes, tables, and so on) that can be estimated based on complexity factors. The result is less risk to the project team (and stakeholders) and higher confidence that what is being built is what is actually required.