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

Non-IT Requirements
Ed Barkley
Part of my response relates to who the audience is for these requirements and if the "business stakeholders" object to reading your PRD for these. If these can be tied to the implementation of the applications I'd think everyone, especially the PM, would be grateful for these since they would point to tasks on the gannt chart (which I believe you state). Being in the PRD it'd seem this would make it easier on the PM to justify the resources (show the impact to all stakeholders) that were going to have to be expended for total project success. If, on the other hand, the business stakeholders want these in a "simpler" document so be it but that means yet another document to maintain. I'd just create another section (like you do for non-functionals) for these and perhaps put it way up front just to make it easy for them to see. Not that you are but I wouldn't get tangled up with the pure definition of "Business Requirements" since just about everything we do is a business requirement, isn't it? Definitions are changing every day.