In most mid-sized IT organizations the process of gathering
requirements is a little more advanced than scribbling a few wire frame
representations of what the screen for the new system should look like. (A wire
frame is simply a line drawing with boxes, rectangles, and text which roughly
describes what the final product may look like.) This mechanism for collecting
requirements is quick. After a few minutes and a handful of sketches, enough
information can be gathered to start developing a solution.

While this may be required for some projects, it’s more
often than not going to create more challenges down the road as small details
escape everyone’s attention until very late in the process — where changes and
fixes cost the most money.

This technique does have its place. It’s a necessary part of
the overall process. However, there’s more to requirements gathering than
getting an initial framework. Understanding the differing goals of the
requirements process is an important key to understanding how to get
requirements done right.

Requirements for scope

The first stage of requirements gathering is designed to
establish a rough scope of the project, a process often called simply scoping. Occasionally it’s done as a part of the budgeting
process. The objective is to provide a general framework for how much activity
will be necessary to create the solution without delving into the specific
algorithms, formulas, and techniques which must be used.

The scoping part of the
requirements process is designed to meet a continuous monitoring need for
projects of all sizes. The initial scope and associated rough estimate,
sometimes called a “guestimate,” since it is often
times more of a guess than a formally constructed estimate, are designed to be
a way for the potential benefit of the solution to be weighed against the
costs.

In the initial parts of the requirements process, it’s
important to make and refine estimates of how much effort will be involved in
the solution so that, if the solution will end up costing more than the problem
is worth, the project can be scrapped for a different set of requirements or a
different approach.

The initial scoping exercises are
also useful for helping to define a budget. At the beginning of the budgeting
cycle the complete set of requirements may not be available and more often than
not it isn’t feasible to perform a complete requirements process. Instead an
initial scoping requirements session can be done very
quickly and a rough “order of magnitude” type of estimate can be made for
inclusion in the budget.

The key to managing requirements for scoping
is to remember that it’s a continuous process where the accuracy of the
estimate improves with additional information about the problem. However, the
process is logarithmic. This means that even a basic understanding of the
problem creates a rough idea of the overall cost for the solution. Although the
more you know about the problem and the solution the more accurate the estimate
will be, the amount of additional accuracy in the estimate gets smaller and
smaller. Eventually you plateau where no amount of additional knowledge will
make the estimate more accurate.

The scoping part of the
requirements process should start the requirements process and provide a
foundation for the estimated costs. Periodic review of the scope and associated
estimate can help you make sure that you’re on track. A final estimate, which
will become the basis for the project plan, should punctuate the close of the
requirements phase.

Requirements for detailed understanding

The requirements phase that most people think about when
talking about requirements is the phase where detailed requirements are
gathered so that a detailed design specification can be created. The
requirements process is often thought of as the prelude to the design phase and
is a phase where detailed user requests are cataloged, prioritized, and
organized.

This part of the requirements process–capturing detailed user
requests and organizing them–is needed to proceed to a design step. Whether
the process is a traditional waterfall process or something more radical, it’s
necessary to understand the problem and, in some cases the proposed solution,
in order to be able to design a solution or to design how the solution will
work.

As a general rule the part of the requirements process that
deals with the detailed user requests and needs will be substantially longer
than the process of scoping the project.

TechRepublic’s free Strategies that Scale newsletter, delivered each Tuesday, covers topics such as how to structure purchasing, when to outsource, negotiating software licensing or SLAs, and budgeting for growth. Automatically sign up today!