Customer-side BA here, currently in the middle of a large-scale enterprise data warehousing and infrastructure modernization initiative. The project teams use Jira instead of TFS, and though the concepts are the same, our use of the platform is mainly as a tracking and reporting tool to interface with the core (enterprise) Agile development team. The focus of our user stories are mainly to discuss and track testing, enhancement requirements, defect reporting - all of the type of feedback that comes "after the fact" of each sprint's work-product, so to speak, and well after the initial requirements have been published.
Key commentary on the BRS/SRS specifications - these should be solicited from end-users in the planning/prototyping phase in order to prioritize architecture development and to develop the overall project plan; this can be accomplished with a survey or other requisition assessment tool, drafted by technical leads and the E/PMO and sent out to consumer leads in the initial stages of planning. This allows the E/PMO to gauge the baseline scope and feasibility of the draft requirements, make necessary resource allocations, and prioritize work to waves, sprints, along a kanban board, etc. for the methodologies in play.
User stories, on the other hand, tend to be more focused on responding to feedback over particular channels, services, domains, or templates that arise after consumers have conducted feasibility and gaps analysis against the prototyped release.
In short - while the exact purpose of each document will vary across different organizations and projects, the requirements documentation and user stores are ultimately apples-to-oranges, however all three could feasibly be combined in the same basket of fruit. Emphasis on the role of each should be tailored to the interests of the group(s) driving the initiative.
End-users will set their requirements ahead of time and independently of the work being done in each sprint; they will likewise continuously adjust their plan in alignment with BA/DevOps feedback along the way - this communication gets relayed through the user stories during development as a tracking bulletin of sorts. The three are complimentary, but oftentimes they'll serve to document the interests and needs or distinctly different shareholder groups.