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
Business Requirements
I think that you are documenting both project tasks and use cases given the way you are stating the requirements.
Develop procedures and provide training for Customer Service staff sounds like a task.
Create correspondence for Providers sounds like a use case along with Maintain, Obsolete and delete.
One factor that creates difficulty is that many people talk about business requirements as if they are system specifications. But the business requirements should be documented independent of the technology implications. So you could accomplish them through pen and paper or through code in an application. Create correspondence for Providers is an example of this.