Requirements are the bridge between nebulous ideas of what a business intelligence application or application suite might accomplish, and the completed, fully functional software and processes. They are the blueprint for the technical teams that will assemble the pieces of the BI initiative.
Requirements represent fully formed, clearly demarcated definitions of exactly what a piece of software will and won't do—and how it can accomplish the goals of the program.
Don't lump requirements management in with the project's other preparatory steps. The first priority of the requirements phase is to work out what functionality is required of the application(s). Any other design activity that takes place before that step is complete can jeopardize the entire program.
Managing requirements includes eliciting, organizing, communicating, and managing the specifications of the software and processes. Although all of these are important, eliciting requirements is first among equals.
But it's not always as simple as asking a question, and writing down the answer. Most analysts like the term elicitation rather than merely gathering—possibly because it's fancier, but more likely because it implies making the effort to draw out the requirements and business rules from the minds of the users and stakeholders; they won't just be lying around waiting to be picked up. You must shake the tree a little bit to get them to fall. And sometimes you ...