As I see it, a tender is really an offer to build a piece of software right?
As such, I woudl include at a very high ( Something a manager can understand ;-) ) level that the QA team would be responsible for.
There really is no need to go into the nitty gritty saying how many hours a person will spend on testing a specific peice, but mention things like functional testing, performance, stress, etc. Basically an outline of which piece are going under test, and generally how you will test these pieces.
You miss User Requirements under (requirement management)
Design Requirement document (requirement management)
Master Test Plan covering Unit, System and Performance and acceptance testing.
You can talk to IEEE and get the sample test plan.
Acceptance testing plan is not required but however you have to provide the customer with use cases.
You are supposed to keep track of bug fixes and open bugs at the time of delivery with the assurance to fix it on a definite time frame.
If you have to certify your software through ISO 9002, then you have to take different direction from the start (away from CMM).
I recommend CMM. (Buy a book on CMM. For example, CMM by Pankaj Jalot of INFOSYS.
I hope this will help.
Don't forget to review the complete tender:
1. If all relevant (functional and non functional) requirements are there?
2. If acceptance procedure is detailed and specific anough?
3. If change control is described?
Often customers don't pay a lot of attention to formal QA stuff.
If your RFP QA requirements are specific enough?