Develop a strategy for requirements gathering

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.

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. 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 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

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.

This requirements process will take longer time compared to requirements scoping.

(read complete article)