At a very basic level, the primary purposes for documenting requirements are to communicate what is needed (whether buiness process, software functional & non-functional capabilities, or services); and to monitor and manage delivery on those requirements.

For business processes and software systems, there are generally quite a few steps in between the communication of the requirement and the ultimate delivery that need to be managed.  Requirements documentation templates and practices are built to support this end-to-end tracking.  For functional requirements, for example, you may start with a use case that gets translated into class diagrams, design specifications, test cases, etc.

Services tend to follow a bit different path, so my suggestion would be to focus on the life-cycle for your service requirements.  I would suggest looking at ITIL for service management rather than ISO if your focus is primarily on services (whether insourced or outsourced) :

http://www.fastitiltemplates.com/service-design/service-catalog.html

If you expect to end up producing some type of service level agreement from your service requirements, this will take you right down that path.  The link above has some good examples for building a service catalog, which can be a great way to document service requirements.

Sandra