Requirements for me start with a business description in business terms so that no bad assumptions get made about how tools work or what data will or won't be included or if something can be done. This includes business defining the audience and security needs in their terms. Then you can get into tools, data sources, columns, breaks/groups, sorts and parameters and finally dig into security rules in IT terms. If there are calculations then those need to be laid out in detail. Provide spots to define charts and graphs,alternative calendars, foreign languages or specific output formats (ie PDF or XLS.) You may want to add a spot for testing and also make note of any unusual decisions or events that affected the final product.

You can have separate change control versions of this doc that only include deltas, who was involved in the request, the work and the testing, and if any tradeoffs had to be made.

One other thing to consider for the future is adding a report description into the original requirements template so while business is still sitting there they can help craft a short blurb that you can use for casual users. Most of the time they need a lot less documentation than you think.

Last point: in my humble opinion these docs are almost never searched or referenced except when something goes wrong, so maybe don't bother with a fancy system and stay with Word or Excel. If you have something on hand or there's a corporate standard then go ahead. But these have as much value of their value in CYA as anything else so they just need to be accurate, not powerful or integrated or whatever. MS file servers have the ability to search contents anyway, so simple might be better. YMMV.