I worked on one team that had this and it was amazing. It implicitly helped with burnout too. It was an "Agile" team, but we followed more of a scrumifall model that worked well for that project.
I've been on a bunch of Agile teams (some more than others) since then, but the requirements processes are all garbage. Then the leaders wonder why things take so long, there's so many bugs, burnout is high, etc. It's really not surprising.
It was an app that was heavily focused on business processes, like routing items between different groups. We had spreadsheets and process maps for each business process. This means the business actually had to think about the possible routes it could take and the data required on each step. So the spreadsheet would tell us all the possible data exposed on the step including how it was treated (R, RW, required, formats/types, etc). It was magical.
Once a process was created the business would have to sell any process changes to the product owner by either showing it was a regulatory/legal issue, or using a cost study to show it would save money. So not back and forth or superfluous changes.
This is the type of engineering method that I try to instill in my teams. It's very dependant on good practices at every level of requirements management.
I worked on one team that had this and it was amazing. It implicitly helped with burnout too. It was an "Agile" team, but we followed more of a scrumifall model that worked well for that project.
I've been on a bunch of Agile teams (some more than others) since then, but the requirements processes are all garbage. Then the leaders wonder why things take so long, there's so many bugs, burnout is high, etc. It's really not surprising.