When a product support team receive a defect report they raise a ticket in their management system and do whatever needs to be done to resolve it. The ticket travels through whatever workflow is appropriate to it and eventually someone resolves the issue, verifies with the customer that all is well and then closes the ticket.
Generally requirements analysis isn't really done. Certainly discovery work as performed in the BA community isn't done. The support team tent to either know through their experience what business requirements apply to the problem area, or they look at the manual. Sometimes they may ask for clarification, but this is rare. The team are expected to know how the system works and how it supports user operations.
This is not to say requirements don't exist. It's just that they are independent of the support ticket.
User Stories are like that. They are the ticket that travels through a workflow.
(Of course I my model here is flawed. The "As a, I want, so that" strays into analysis and modelling territory addressing partitioning of work, user modelling, motivation modelling and even interaction modelling. But it doesn't do the whole job. Analysis and modelling remain distinct activities and artefacts.)