Moving Ahead

I l @ ve RuBoard

Now that you understand the application, you need to put in place the database schema that will underpin it. That's the mission of the next chapter. When you have data in place, you'll be ready to start coding, beginning with the user registration portion of the application.

In a real project, you would go back after the use cases were complete and refine the ERD to reflect any new discoveries that you made during additional discussions with the client. In this case, the ERD that you started with is good enough to take you into database design. There are also aspects of the object model that would be much more complex in a live e-commerce site. For example, you haven't done anything about representing shipping methods .

As with any large application, the ERD and use cases presented here will have to evolve as the actual application comes together. Some things have been forgotten or overlooked, and other things will turn out to be clumsy or impractical in practice. That's the purpose of change control ”to allow both the client and the implementers to make course corrections midstream without anyone panicking. Most major projects have a person at the management level whose main purpose is to handle change control and "scope creep."

CHANGE ISN'T ALWAYS GOOD

As used in software engineering, scope refers to the set of features or functionalities that are required to be present in the finished product. Items are either in scope or out of scope. It is usually the job of the project manager to work with the client, handling change control to the FRD.

For example, if you were developing software for an automated teller machine, it would probably be in scope for the machine to be capable of giving the correct amount of money on a withdrawal (at least, one hopes that it would be in scope ).

However, the client might suddenly decide that the bank customer should be allowed to specify how the withdrawal should be paid out (in five $10 bills rather than two $20s and a $10, for example). Unless that had been mentioned up front during requirement gathering, it would probably be considered out of scope by the development team.

At this point, the project manager would contact the client, indicate that the request was out of scope, and look for direction from the client. On a time and materials project, in which the client pays by the hour , the project manager would present an estimate for the cost of the new requirement. On a fixed-price contract, the client would need to increase the cost of the project, remove another requirement, or drop the request.

It's common in large projects to see requirements bargaining, in which new requirements are traded for less important ones already in the FRD. When the client manages to sneak in new requirements because the FRD was vague or because he has the clout to push them through, developers complain about scope creep.

I l @ ve RuBoard