Not all requirements are equally valuable, nor do they all require the same time and attention. But if you're focused on the big picture—the broad spectrum of requirements—it can be hard to decide where to invest your time. Don't let the big picture overwhelm you. Break the requirements into smaller, manageable components. Then determine each component's priority, as well as how much time and energy it will take. Finally, allocate resources to the components based on their priority and the availability of people and time.
The process of breaking things down into smaller, chewable bites is often called "decomposition." A good place to start is by identifying the highest-level functions and processes, with the help of business context diagrams and business process models . As you decompose things into manageable chunks, requirements traceability will help ensure that the lower-level processes can be traced back to higher-level processes.
For example, consider a project to improve the efficiency of an online catalog ordering system. Within the business function of "online catalog orders," there are endless details: functions, sub-functions, processes, and sub-processes, from design, printing, and distribution of catalogs, to email confirmation that orders have shipped and online support for customer questions. An analyst could easily be swept away by the need to manage the endless details of the catalog production and ordering processes. Breaking the higher functions into their smaller components makes it much easier to identify the areas that deserve the most attention. Decomposition allows you to spend the appropriate time, energy, and resources on each requirement.
In the online order catalog example, note that catalog distribution is important (customers can't place orders without a catalog), but it isn't the most important component for the stated business goal of improving the efficiencies of the orders. (It's less important to make the catalogs pretty or easier to ship.) Therefore, you would want to spend more time working with sub-processes, such as launching the website, browsing the Web catalog, managing a shopping cart, placing an order, etc.
The important thing is to categorize and break down the requirements into the appropriate set of functions, sub-functions, processes, and sub-processes, and then prioritize them. At that point, you can allocate all of the functional requirements and many of the business rules to one or more processes or sub-processes contained within the solution. Once you know how the requirements are allocated across functions, you can use that information as an aid to prioritize work, assign resources to requirements tasks, and schedule releases (in the case of phased releases). Of course, you'll want to give highest priority to the "valuable few."
You'll spend a certain amount of added time and planning effort up front on the functional decomposition and requirements allocation, and you'll need to review the allocations periodically throughout the project, particularly when changes are requested. But the initial effort will deliver huge value, by ensuring that the right focus is on the right things, at the right time.