The performance requirements are constraints on the functionality. You may wish to
outline a minimum browser configuration for use of the site. Maximum page weights are
a good idea. If the client is dictating that a certain technology be used, it should be noted
in this section. It's good to know in advance that while you will be allowed to use PHP,
you have to deal with Oracle and Internet Information Server on Windows NT.
The exception-handling section describes how the system deals with adversity. The two
parts of this are disaster and invalid input. Discuss what should happen if the Web server
suddenly bursts into flame. Decide whether backups will be made hourly, daily, or
weekly. Also decide how the system handles users entering garbage. For example, define
whether filling out a form with a missing city asks the user to hit the back button or
automatically redisplays the form with everything filled out and the missing field marked
with a red asterisk.
If the client has a preference for the order of implementation, outline it. My experience
has been that, faced with a dire deadline before the project begins, the client will bargain
for which functionality will appear in the first round. Other requirements may not be
critical to the system, and the client is willing to wait. If there is a preference in this area,
it is very important for the designer and implementers to know in advance.
Farther in the future are the foreseeable modifications. The client may not be ready to
create a million-dollar e-commerce site just yet, but they may expect to ask you to plug
this functionality into the site a year from now. It may not make sense to use an
expensive database to implement a 50-item catalog, but building a strong foundation for
later expansion will likely be worthwhile.
The last part of the requirements specification is a collection of design hints. This
represents the requirements writer's forethought about pitfalls for the designer. You might
summarize a similar project. You might suggest a design approach.
Writing Design Documents
Once you have created a requirements specification document, you will have to decide
whether to write a design document. Often it is not necessary, especially when a few
people are working on a small project. You may wish to choose key elements of a
complete design document and develop them to the point of usefulness.
The first part of design is concerned with the architecture of the system. The system
should be broken into sections that encompass broad groups of functionality. A Web
application for project management might break down into a module that handles project
information, a module that handles users, and a module that handles timesheet entries. An
informational Web site can be broken down by the secondary pages—that is, the pages
one click away from the home page. The "About Us" section serves to inform visitors
about the company itself, while a catalog area is a resource for learning about the items
the company sells.