Requirements or tasks?
I'm am the Lead BA in my organization, and am struggling with a particular issue regarding requirements documentation. I work for an insurance company and typically the projects in the portfolio have some IT componenets, usually changing parts of the Legacy systems to accomodate new benefits, but our BA's also work with the business units to understand the things that need to be done to complete the project that are not IT related.
The BA's document the IT requirements and the non-IT requirements in our Project Requirements Document (PRD). The BA's typically document these non-IT requirements as "Business Requirements". I disagree with the categorization of these, as I think of Business Requirements as much higher level, but there really isn't any other place in our document for these. Some examples of these requirements are:
Develop procedures and provide training for Customer Service staff
Create correspondence for Providers
Update Provider directory
Our PRD has sections for Business Requirements, Business Rules, Functional Requirements, and many different types of Non-Functional Requirements (Performance, Usability, Security, etc). We also have PM's on our projects, and they (somethimes) take these requirements and expand on them in the project timeline with who is responsible and when they will be done.
Anyone else document these types of things? What is the true classification for these requirements? My Manager has insisted that we need to capture these things, because they are things needed by the stakeholders to achieve an objective. This satisfies the definition of a requirement in the BABOK.
Thanks - MPS

Requirements or tasks?
The suggestion to ask "why?" about each of these tasks-posing-as-requirements is an excellent one. That approach is sure to lead to the real business requirement. If you can't get that far, even changing the wording so that it indicates that the "solution must include a provider directory" is better than putting the task to create the provider directory into the requirements document. This may imply that "solution" is defined more broadly than the software solution.