The requirement gathering part is partially done in problem analysis phase. The document created in first step would help you to get started in this page. This is tough phase and is very critical to the success of development. Clear requirement and thorough analysis is must for success of any project.

1. Prepare the questionnaire for the future users of the new Solution.
2. Ask very specific questions rather than high level.
3. Find out the Data Sources for the data.
3. Check if you can use existing system if any as a data source for the .
4. Find out the possible data to be inserted  .
5. Get a list of reports that is supposed to come out.
6. Understand the existing Business and terminologies.
7. Find out if client is ready for commercial BO tools or Open Source tools.

Requirement analysis and gathering is a bit tough as client might no be clear with his/her requirement. It’s your expertise in the design process and prior experience which help you to analyze the requirement and put it on paper. Once everything is clear make sure you get a sign off from the client on the requirement.

Measurable goals

Best practices take the composed list of requirements merely as clues and repeatedly ask "why?" until the actual business purposes are discovered. Stakeholders and developers can then devise tests to measure what level of each goal has been achieved thus far. Such goals change more slowly than the long list of specific but unmeasured requirements. Once a small set of critical, measured goals has been established, rapid prototyping and short iterative development phases may proceed to deliver actual stakeholder value long before the project is half over.

Prototypes

Prototypes are Mockups of an application, allowing users to visualize an application that has not yet been constructed. Prototypes help people get an idea of what the system will look like, and make it easier for projects to make design decisions without waiting for the system to be built. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of applications led to fewer changes later and hence reduced overall costs considerably.

Prototypes can be flat diagrams (often referred to as wireframes) or working applications using synthesized functionality. Wireframes are made in a variety of graphic design documents, and often remove all color from the design (i.e. use a greyscale color palette) in instances where the final software is expected to have graphic design applied to it. This helps to prevent confusion as to whether the prototype represents the final visual look and feel of the application.

Use cases

A use case is a structure for documenting the functional requirements for a system, usually involving software, whether that is new or being changed. Each use case provides a set of scenarios that convey how the system should interact with a human user or another system, to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end-user or domain expert. Use cases are often co-authored by requirements engineers and stakeholders.

Use cases are deceptively simple tools for describing the behavior of software or systems. A use case contains a textual description of the ways in which users are intended to work with the software or system. Use cases should not describe internal workings of the system, nor should they explain how that system will be implemented. Instead, they show the steps needed to perform a task.