I'd be outraged too if I was supposed to be in design meetings and was instead told about a change after it was "complete", rather than after it was requested/noticed.

I'm going to agree with Jeff completely; given a competent QA team, having them involved in the requirements and design phases is incredibly valuable. You save time later on when you don't have to explain to them what's going on, you save time in the middle when you know what they need before your write up documentation for them (instead of after, requiring rewriting), and you get a completely different set of insights from a group which often has the closest thing to many aspects of an end user's point of view as exists in IT.

Let me say that again - a good QA department's suggestions at requirements and design time are as close to an end user's suggestions would be as you're going to find in IT. QA tends to want things well defined, wants to know they'll be usable, wants to know they'll work right when things are right and break in the desired manner in exception cases, and if you're very lucky, wants to know that the software will have a good workflow and fit well into the rest of the workflows. Likewise, if you're lucky, QA works with all the various groups, and may have some insight into what other teams have tried or need. With a good QA department, you can end up with much happier end users, and with better products.