While user stories can absolutely be considered a type of requirement, there are distinct differences between user stories and other requirements that I don't see here or in the accepted answer on the Software Engineering site (though it is touched on in other answers).
Most important amongst those differences is the way in which they encourage the team and user to engage. Remember that in XP, where User Stories originate, that there is no product owner. The customer writes user stories. Because of this, the User Story is an exercise in understanding the needs of the customer. Some of the most effective user stories are completely lacking in any requirements and only discuss the need and let the team come up with a solution.
A common example I use to illustrate this difference is a hypothetical story from a tax filing application. This would be a bad user story:
As a tax payer, I want to fill out my tax form so that I can file my
This "user story" matches the commonly accepted form for a user story and would be relatively easy for a team to understand and implement, so why is it a poor user story? The problem is it fails at the fundamental purpose of a user story - understanding the customer. No one wants to fill out a tax form. A more appropriate user story would probably look something like this:
As a tax payer, I want my taxes filed accurately so that I get my
Notice, no implementation details at all. Just a need for the team to solve. Now, these are hypothetical, but if you've used TurboTax, you probably know that not only do they dominate their market, but they also never ask you to fill out a tax form, so it's not far off of reality.