Before you can design a system, it is important to understand what it's supposed to do.
Too often this comes in the form of a verbal request such as, "We need a home page with
a guest book and a visitor counter," which is never further defined. This usually leads to
the building of a prototype that is 25 percent of what the client wants. Changes are made
to the prototype, and the site is now 50 percent of what the client wants now. During the
time the changes were made, the client has moved the target.
The solution to this problem is to set a target and stick with it. This should start with a
statement of the goals for the project. In my experience the most important question left
unasked is about motivation. When a client asks for a large animated scene to appear on
their index page, often the motivation is a desire to seem familiar with leading-edge
technology. Instead of blindly fulfilling the client's request, it is better to look for the best
solution for the "Why?". A slick graphical design can say more about the client's
attention to advances in technology.
Once you have asked "Why?" enough times, you should have a list of several goals for
the project. These goals should suggest a set of requirements. If one of the system's goals
is to generate more business, one requirement may be to raise visitor awareness of items
in the client's catalog. This may evolve into a requirement that products appear
throughout the site on a rotational basis. This could be implemented as banners or kickers
strategically placed within the site. Don't, however, tie yourself down with design issues.
This earliest stage of site development should concentrate solely on the goals of the
system.
From a solid base of goals, you can begin to describe the system requirements. This
usually takes the form of a requirements specification document, a formal description of
the black-box behavior expected from the site. The goals will suggest a collection of
functional requirements and constraints on the design. As I've said, having a goal of
increasing sales suggests, among other things, that the site should raise customer
awareness of catalog items. Another requirement could be that the site provide some free
service to attract visitors. An example is a loan company offering a mortgage calculator.
It is a good idea to informally explore possible solutions to requirements, but it's still
important to keep design decisions out at this time.
The requirements specification is formal and structured, but it should be understandable
by nonexperts in the implementation technology. The description of the system's
behavior serves partially as a contract between the client and developer. Clear statements
will eliminate misunderstandings that have a high cost later in development. That is not
to say that the document shouldn't be precise. When possible, state requirements in
measurable terms. Constraining page size to 30K is an objective standard and easily
tested. Requiring the site to inspire confidence in the client company is not easily
measurable, but sometimes it's all you have.
Table 21-1 lists six things toward which a requirements specification should aspire. It
should only specify external behavior. Every requirement should be expressed as the
answer to a "What?" question. It should specify constraints. These are best expressed as
quantities: How many hits per day? Maximum page size? Maximum page depth? The