The information gathering process is the critical step of any successful functional spec. Just as important as the finished document is the thinking process you have to force yourself through in order to begin writing. It makes everyone think about what they are building, why they're building it, who will be using it, how they'll be using it, and what it will end up doing. At this early stage, everyone may have various shades of ambiguity about what they're getting ready to build and it's unlikely that anyone is in total agreement about what exactly the finished product will do. Here is a quick checklist of the general questions you should be asking (and depending on what the project is, you'll probably come up with more specific questions) at this early stage:

• What is the application supposed to be?
  Pretty basic but critically important. Make sure you have a strong grasp on what the product is before you start anything; additionally, make sure the team you're working with, and the management team ultimately responsible for the product, also have a strong grasp on what you are all doing. Expect lots of arguing and discussion during this stage!
• What is the application supposed to do?
  Now that you know what the product is supposed to be, you should start dissecting what it is supposed to do. Identify the main objectives of this project based on its mission critical factors. Typically, there are one or two core pieces of functionality that make up the bulk of the final product with a bunch of other smaller items thrown in. Identify those core pieces and make them a priority. Do not allow the smaller items to get in the way, but make sure you’ve made a note of them. A good way to do this is to simply create a list of all the functions you want the application to perform and then rank them based on priority.
• Who is going to be using this application?
  Find out who the audience is (i.e., who is going to be using this product). Knowing your audience is important in understanding why and how they are going to be using the final application...which is important in defining the scope of the project. Better yet, create use cases and develop user personas. User personas can be a great tool for allowing you, as the writer, to enter the world of your users and see everything from their perspective.
• What are the metrics?
  Most projects have a performance metric attached to them somewhere; e.g., revenue, page views, new members, etc. Make sure this is clearly known from the beginning. It will help focus your approach and the approach of the team as well, because even if you develop a great product it can still be a failure if it doesn't meet its metrics.
• Is there a precedent for this application?
  If what you're developing is similar to other products out there, it can make your learning curve much easier by researching those applications and discovering what works and what doesn't. Make it a point to perform a very thorough competitive analysis. Not only will it help you gain speed faster, but it will also give you an idea of what your competition is like and how to do it better.