I am working with an organisation that has a continuously evolving product. Although original product is in production, business is regularly giving new requirements or change requests. The teams are following agile methodology. While new requirements are clear, it is not clear how the change requests to a delivered User Story should be handled. Some times the change request impacts multiple business stories. Should such change requests be tracked as a specialised work item type and linked to impacted user stories and should the original user stories be updated to reflect the new functionality (single source of truth for product definition) or should the change request itself is enough to handle and let the User Stories be kept as is as they are already marked as done.
Please note we are managing work items in products like TFS or Jira (depending on the project) but the process is similar.
[Update after response by Todd as the comment field was too short to fit]
My concern is also about the single source of truth. As we get past initial releases, the design of the software tends to degrade due to local fixes in absence of a complete view. Many times the change request user stories only focus on local aspects and developers loose the big picture. This can be avoided by the CR updating the original US and then the US being part of the work rather than the CR. CR would simply be linked to impacting US. CR can still be considered for work item tracking. But the acceptance tests would still be from the US. Does this sound practical? This should also help new team members joining. People change is common and in larger projects, there is also a practice of rotating team members. In absence of updated US, new developers need to depend on BA maintaining the documents outside the ALM systems like TFS/Jira.