Let's take a traditional functional requirement:The system shall allow the user to create an account with an email address and  passwordA user story that covers this requirement might be:As a shopper I want to create an account so that my preferences will be retainedAnd the acceptance criteria for this story might look like:If I am a shopper I can create an account by submitting an email  address and passwordThe functional requirement is very similar to the acceptance criteria. And I can think of no examples of functional requirements, that wouldn't translate directly to acceptance criteria for the story that implements it.
Are agile user story acceptance criteria the same as traditional functional requirements?
agile;functional requirements
I don't think that there's a 1-1 mapping between functional requirements and user stories or acceptance criteria.First, your example of a functional requirement isn't a good requirement. It's not atomic - I would write your functional requirement as multiple requirements:The system shall require an email address to create an account.The system shall require a password to create an account.I would then add additional requirements to address uniqueness of email addresses, any kind of password requirements, and perhaps even validation of email addresses. In the end, I would have around 5 or 6 traditional shall statements relating to the users creating an account.As you can tell, there's nothing in these requirements about storing preferences, which is a key aspect of your user story. Looking at your acceptance criteria, you have design decisions codified that aren't part of the user story. There's a disconnect there.In an agile project that uses user stories, I would create an epic for user accounts and profiles. One story under this account would be creating an account: As a shopper, I want to create an account with an email address. You may have other stories about logging in with Google or Facebook (or some other SSO) that are part of this epic. Your acceptance criteria would be created to define cases: What should happen when the same email address is used twice? What should happen if a user enters the wrong email address? What happens if something that isn't a valid email address isn't entered?I would recommend not trying to map concepts from traditional project management methods to agile methods. You tend to do the same types of things, but there isn't a clean 1:1 mapping between things.