I'm trying to understand the different between a user story and a requirement.Is there a hierachy like the requirements come first and then user stories created in the backlog. Maybe I'm confusing myself but always thought the user stories are just a way of representing a requirement and then acceptance criteria is the functional aspect? But then unsure how this relates to a product requirements document?I often hear that agile doesn't mean you don't have a requirements document,so how does that relate and interact with the user stories? I Would really appreciate some input to how everyone structures and approaches the documentation of requirements in agile.

Userr stories are specifically not requirements. They are, as Ron Jeffries, the "inventor" of user stories, says, "tokens for communication".  The idea is that when the agile team selects a specific user sroty to do in the next iteration, the developer and user discuss the story. The developer asks questions that, when answered, give the developer the specifications, or requirements, for creating the software that completes the user story as requested. The developer also asks the user "what do you need to see to prove to you that this user story is complete?" and together they define the acceptance criteria or tests for the story.

As a result, user stories can be ambiguous, vague, incomplete, redundant, wordy, incorrect, and so forth, all of which is ironed out in the conversation, and none of which is allowed for a requirement (at least accoding to the IEEE).