Chapter 4. The Sample Application Functional Requirements Document

I l @ ve RuBoard

IN THIS CHAPTER

• Welcome to Books for Geeks

• A High-Level View

• Diving into Design

Functional requirements documents (FRDs) are to projects what DNA is to an organism. If done right, everything needed to bring the project to a successful conclusion should be a logical result of the information contained in the FRD.

But FRDs don't just happen by themselves . They're a product of a careful collaboration between the development team and the client. The client, as stakeholder, is the only entity that understands what is really needed. And you, as the developer, have the responsibility to translate that set of requirements into an end product that meets those needs. The FRD represents those needs outlined on paper.

To illustrate how to create an FRD, you'll be taken through the process of developing one for the hypothetical Books for Geeks (BFG) site. Not only is it a useful exercise in its own right, but this is also the blueprint for the code that will be written in the remainder of the book.

FRDS: A CAUTIONARY TALE

If you don't get the details right the first time, you can end up paying the price at the end, as I once found out.

Working on a $2 million documentation project, we were in the final days before signoff and final delivery. Suddenly, the customer informed us that at page 100 in a document, the standard being used required that page to be printed as page 99-1 instead. Unfortunately, the page autonumbering code that we had been using for the previous two years in the code didn't support this kind of sequence. And, of course, the requirements document didn't say a thing about page numbering one way or the other. We had to rip it all out and write our own, at the cost of an extra two to three man weeks.

The moral of the tale? If you don't ask for the details up front, you might make assumptions in your coding that don't meet the customer's expectations.

I l @ ve RuBoard