In Business Requirements Document: A High-level Review the author defines business requirements as making reasonable estimates of how big a project is and how much it is going to cost.
He then explains what would be in the Business Requirements Document (BRD):
The most common objectives of the BRD are:
- To gain agreement with stakeholders
- To provide a foundation to
communicate to a technology service provider what the solution needs
to do to satisfy the customer’s and business’ needs
- To provide
input into the next phase for this project
- To describe what not how the customer/business needs will be met by the solution
So, to answer your questions:
What should this type of requirements contain?
See his long article for all the details. It's almost like a legal document between your team and your customer describing the deliverables, their dates (delivery milestones) and their price.
Included would be who decides something is fully delivered and who tests it and decides it's fully functional.
What is the best way to manage and maintain it?
Same as usual: periodic review during the life of the project. However, changes have to go through a predefined Change Process - which should be documented in the original document.
Beware of the The Quick, Small change that kills projects, schedules, budgets and morale.
Best practice: Changes should all go into the next release, otherwise you're shooting at a moving target. Exceptions to this rule should be rare and border on emergencies.
As a project manager should I be responsible for delivering and maintaining both?
That would depend on your company's culture. Sometimes it's the Project Manager, other companies have a separate Product Manager to deal with the business side of projects.
Either way, the Technical Requirements and the Business Requirements have to be a perfect match. And that is the responsibility of the Project Manager.