Yeah, we’re one of the places dipping a toe into the Agile pool, not doing it exactly right. Cest la vie.
About your last paragraph describing the process, how do you handle disputes or requirements traceability? For example at the beginning of the project Sammy Stakeholder says he needs X, somewhere along the way X gets discarded, and at project delivery, Sammy demands to know where his X is. Was there documentation somewhere along the way about why X was discarded? (We don’t do any of that, either, and I’m wondering if it’s going to come back and bite us in the rear.)
The purist Agile response would be that Sammy was involved in the project start to finish so he knows exactly why X was discarded. Obviously, that doesn’t work in most business environments. Handling situations like that is a good reason you need some level of documentation. Working from user stories instead of a detailed requirement list might be a good middle ground - you get down the high level feature Sammy wants along with his reason for wanting it, without a lot of time spent documenting it to a gnat’s ass. If you track the user stories somewhere, then you can add notes about when and why it was discarded. The trick is finding the proper level at which to document user stories.