There are two main reasons to bother to define requirements: so you know what you're building and so you know what you're not building. Jesse James Garrett examines the importance and process of defining the scope of your website, including defining requirements and functional specifications.

This chapter is from the book

Defining the Scope

We do some things because there’s value in the process, like jogging or practicing scales on the piano. We do other things
because there’s value in the product, like making a cheesecake or fixing a car. Defining the scope of your project is both:
a valuable process that results in a valuable product.

The process is valuable because it forces you to address potential conflicts and rough spots in the product while the whole
thing is still hypothetical. We can identify what we can tackle now and what will have to wait until later.

The product is valuable because it gives the entire team a reference point for all the work to be done throughout the project
and a common language for talking about that work. Defining your requirements drives ambiguity out of the design process.

I once worked on a Web application that seemed to be in a state of perpetual beta: almost, but not quite, ready to roll out
to actual users. A lot of things were wrong with our approach—the technology was shaky, we didn’t seem to know anything about
our users, and I was the only person in the whole company who had any experience at all with developing for the Web.

But none of this explains why we couldn’t get the product to launch. The big stumbling block was an unwillingness to define
requirements. After all, it was a lot of hassle to write everything down when we all worked in the same office anyway, and
besides, the product manager needed to focus his energy on coming up with new features.

The result was a product that was an ever-changing mishmash of features in various stages of completeness. Every new article
somebody read or every new thought that came along while somebody was playing with the product inspired another feature for
consideration. There was a constant flow of work going on, but there was no schedule, there were no milestones, and there
was no end in sight. Because no one knew the scope of the project, how could anyone know when we were finished?

There are two main reasons to bother to define requirements.

Reason #1: So You Know What You’re Building

This seems kind of obvious, but it came as a surprise to the team building that Web application. If you clearly articulate
exactly what you’re setting out to build, everyone will know what the project’s goals are and when they’ve been reached. The
final product stops being an amorphous picture in the product manager’s head, and it becomes something concrete that everyone
at every level of the organization, from top executives to entry-level engineers, can work with.

In the absence of clear requirements, your project will probably turn out like a schoolyard game of “Telephone”—each person
on the team gets an impression of the product via word of mouth, and everyone’s description ends up slightly different. Or
even worse, everyone assumes someone else is managing the design and development of some crucial aspect of the product, when
in fact no one is.

Having a defined set of requirements allows you to parcel out responsibility for the work more efficiently. Seeing the entire
scope mapped out enables you to see connections between individual requirements that might not otherwise be apparent. For
example, in early discussions, the support documentation and the product spec sheets may have seemed like separate content
features, but defining them as requirements might make it apparent that there’s a lot of overlap and that the same group should
be responsible for both.

Reason #2: So You Know What You’re Not Building

Lots of features sound like good ideas, but they don’t necessarily align with the strategic objectives of the project. Additionally,
all sorts of possibilities for features emerge after the project is well underway. Having clearly identified requirements
provides you with a framework for evaluating those ideas as they come along, helping you understand how (or if) they fit into
what you’ve already committed to build.

Knowing what you’re not building also means knowing what you’re not building right now. The real value in collecting all those great ideas comes from finding appropriate ways to fit them into your long-term plans.
By establishing concrete sets of requirements, and stockpiling requests that don’t fit as possibilities for future releases,
you can manage the entire process in a more deliberate way.

If you don’t consciously manage your requirements, you’ll get caught in the dreaded “scope creep.” The image this always brings
to mind for me is the snowball that rolls forward an inch—and then another—picking up a little extra snow with each turn until
it is barreling down the hill, getting bigger and harder to stop all the way down. Likewise, each additional requirement may
not seem like that much extra work. But put them all together, and you’ve got a project rolling away out of control, crushing
deadlines and budget estimates on its way toward an inevitable final crash.