User Story captures what the user wants to do with the system at a high level. I understand that the user story would further drive a number low level requirements. Is user story same as high level requirement for the system?
To be honest, after spending close to two years immersed in Agile development, I still think "user story" is just a fancy term for "functional requirement".

It's different at a superficial level, e.g. it always takes a certain form ("as an X, I want Y so that Z..."), but the key elements - identifying the stakeholder and the rationale - are also inherent in well-written functional requirements. It's just as easy to write a bad user story as it is to write a bad requirement ("as [our company name], I want [vague feature] so that I can [do something that's self-evidently part of my job, like 'sell more to customers']").

What user stories almost never capture, in my experience, are non-functional requirements like performance and security. These kinds of requirements are very difficult to write properly and the format of the user story simply isn't very good for capturing them, because they're more about general product quality and mitigating (but not eliminating) risks rather than meeting a specific user's need.

So, I really think of user stories as a subset of requirements, with a specific formula, and still use the terms pretty much interchangeably.

The one major advantage user stories do have over requirements is that the word "requirement" suggests that a feature is required where it is often just desired. User stories can in theory be prioritized and slotted in for any release, whereas requirements appear to be a prerequisite for every release.

Of course, for the aforementioned distinction to matter, your customers and/or senior management must embrace it; it does you no good whatsoever if you have 30 user stories all grouped into a "project" that must all be completed at the same time. You might as well call them "requirements" in that case because they are in fact required.
