Oh, I understand your point. I think we had the discussion in an earlier post a while back. My point isn't that I should get to say what is included entirely -- my point is that very often the people who are telling you guys what is needed don't know what they're saying.
As a case in point, a while back I was asked to UAT the transition of a major data source into our data warehouse. Previously, this source existed only as an ad hoc deliverable coming to us from our primary data vendor, so it was a fairly manual process to link the institutions in that data source to our customer master. This was good and bad from an end-user perspective: the bad was that it didn't allow us to easily link these institutions to the customer records we had for them in our customer master (no common ID.) But the good part of it was that this source was built on a completely different principle than our customer master - the customer master was built around locations only. This new source was built around a hierarchy of business relationships. For about 2/3 of the data, this was a non-issue. But for other 1/3 it created all kinds of problems. As anyone who has ever gone to a medical complex knows, a single building can house multiple group practices and physician offices. Under our existing structure, the all shared the same ID because they were all in the same physical location. But some of them were owned by different corporations, and the new source needed to reflect that. Of course there are workarounds for these types of things - I have my own ideas of the best way to do it, but I certainly recognize that it's not the only way and there are plenty of others that could legitimately work. The problem arose because the people who met with the architecture group who were building the new structure to accommodate this new source in the existing warehouse didn't recognize the problems that could arise between location-based and owner-based roll-ups, so they never communicated it, and an entire front end was built to merge and match up the data that undid all of those relationships. And when I discovered this and reported it, a lot of folks on the development side got angry at me. But I wasn't telling them they did it wrong - I was telling them they never had a chance to do it right. If myself or someone on my team had been made available for consultation, I'm sure we would have been able to work out something that would have fit our needs, even if it wasn't exactly what I thought it should be. But because that didn't happen, what we got was just wrong and it ended up taking considerable time, money and resources to fix. And that is a pretty typical example of my experience with UAT here. It's insane that the people talking to folks on your side continue to exclude users from their conversations with you on new projects. I don't know if it happens everywhere, but it happens at my place all the time.