We have an existing software product that is being transitioned over to a agile process.
New requirements will be captured as user stories, but this has inspired the question around what to do with existing requirements and what the relationship is between user stories and product specification/documentation.
I can see value in capturing all the currently implemented and new requirements as users stories as a way to answer the question: "What exactly can users do with the product at this point in time?".
I don't specifically have a need for this right now but I can see it being useful to be able to show a customer: "Here: this is exactly what the product does". This may as be a good way to track our contractual commitments, or even a buy-out checklist.
In general though, user stories are used as a tool to capture and implement new requirements - and as far as I'm aware people rarely delete a user story once the requirement becomes obsoleted or not needed anymore. And without doing this 'pruning' you no longer have a full specification of your product functionality at a point-in-time.
I suppose the other way to capture this specification is via acceptance tests (Executable Specification thesis). With something like gherkin you have a tight coupling between story, acceptance test and specification.
TL;DR: If I wanted a way to capture a point-in-time list of functionality or "specification" of my software product, how would you go about it? User stories via an appropriate tracking tool seem to give us the power to do this but I have never seen them used for this.
Note: The team is already fairly familiar with agile so this question not about them getting familiar with the process.