Welcome to Books for Geeks

I l @ ve RuBoard

It's a bright, beautiful Monday morning, and you're having your initial meeting with the CTO of Books for Geeks and her staff. You've landed the contract to implement the e-commerce Web site that's going to make the company the leader in online sales of technical books.

Having already won the business, you should know a fair amount about the application you'll be designing. In fact, in most cases, you'll already have seen an FRD of some kind. After all, how can you bid on a piece of work if you don't know what the work entails?

Unfortunately, having an FRD available during the proposal stage can be more the exception than the rule when doing development. Often the FRD is as basic as "We want a Web site to sell stuff." It's your job as developer to review whatever specifications do exist and to clarify as early as possible any uncertainties before they turn into problems.

The FRD is a description of how a site should work from the perspective of a user (either end user or administrative). It also should describe any legacy systems that will need to interface with the application. In addition, it might specify certain platforms or technologies that are required, such as LDAP or J2EE.

Developers often find themselves locked into a technology because someone in a position of power heard that it was cool or was "the next big thing." Part of the requirements process might involve explaining the impacts of using a specific piece of software, both on the schedule and on reliability.

In some cases, the client might not have any idea about how he wants the application to work. In that case, it's your job to act as a knowledge engineer, helping to refine the FRD toward something that you can code from.

The FRD is used to generate the use cases that, in turn, drive the object model and database design. As you review each piece of functionality with the client, ask yourself these questions:

• What are all the possible paths that lead to this piece of functionality?

• What state must be preserved through the action?

• What are all the possible exits from this action?

• What errors can occur during the processing of this action?

• Are there access restrictions on this action?

• What other systems is the action dependent on?

You also need to listen for key phrases that will clue you in to the objects that will need to be modeled , such as user, product, cart, order, history, and so on.

I l @ ve RuBoard