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!