I haven't heard of a standard template (even based on the industry) for requirements gathering. Anyway, even if such thing exists, it is not a good idea. The first step in gathering good requirements is to know and accept that requirements are unique.
Once you're past that step, you have to understand that, in most projects, clients have a general idea about what they want, and they want you to help them identify their requirements, and the best way to do this is to understand the business.
Initially, your questions (to the client) should not be "what do you want", but rather "how does your business run", and "what do you expect that the product will accomplish?" Asking detailed questions should be at a later stage, once you understand the business model of the client and the reasons behind his project, and what he wants to accomplish with the project.
Once you gather the high level requirements from the above based on the client's business and needs, then you can go into the details. For example, in a web project, you can EXPLAIN to the client how you see his project, at a microscopical level. In a web project, you can do mockups of the design, the pages (with sample content), the forms, and explain the triggered actions on every form, and then ask the client to approve them. Guiding the client through this process will not only make both of your lives easier, but will increase your standing as a project manager, and the client will respect you more and trust you more.
If you follow the 2 steps above, then there is little chance of scope creep "creeping" on the project, unless the client starts treating you as a "pal" (which may very well happen when he trusts you enough), and starts asking you to do things as a "favor" (changing/adding/removing requirements), in this case you should draw the line, or otherwise, you'll fall into the trap as your project will be a victim of scope creep, and you'll lose all the hard work you put into gathering the requirements, and managing the project in general. At one point, as a project manager, you have to say "No" to your client, and trust me, you will not lose his respect, nor his trust (they won't even be affected).