I hear a couple of things in here. First, a PO is not a rebranded BA from waterfall. The Product Owner owns the health and priority of the backlog, but is not a gatekeeper between the business and the team. Rather, the PO should facilitate more effective communications. If the team is saying that the requirements are bad, that is as much on them as it is on the PO. Either can reach out to the business to get more information. If they are using User Stories, one or two sentences is all they should start with. (Fun fact: the reason that User Stories were originally written on 3x5 cards was because there wasn't enough space to write all of the requirements down, making a direct conversation necessary).
Now, regardless of who has the conversation, documentation traditionally served two purposes: one is to understand the ask, the other is to make it clear how the application behaves after the fact.
Understanding the Need
Many teams find that 1-2 sentence user stories with bullet-point acceptance criteria is enough. Other teams may add some sketches for UI or spreadsheets for financial functions. Really, whatever the team needs, they should ask for - again, they can ask the PO, but a lot of times they need to ask the user. If you want to take it further, I'd suggest looking at options like Behavior-Driven Development, in which the PO, Dev Team, and User can all collaboratively write up scenarios that the new functionality will fulfill.
Documenting the Behavior
In waterfall, you used to just look back at the requirements specs, but in agile there is usually a bunch of different documentation, all used when it is the most appropriate. Automated test cases (like the BDD ones) make create documentation because it not only describes how the application should behave, but when you run them it tells you if it really works that way. Of course, end users probably don't want to look at those, so WIKI's and user manuals are still common.
Making Time
Reading into your question and comment a bit, it sounds like there is a time constraint. It's important to remember that Scrum asks the team to do everything needed to call a backlog item done at once. In other words, documentation, testing, and other non-development work is grouped in with the development. This is intended to be non-negotiable. This keeps the team from building up technical debt. This even includes documentation. If they team doesn't spend the time to update the documentation that they need to keep track of how the system works, soon every new feature will need an impact analysis and extensive design cycles, making it very expensive to add even the smallest feature.
