“Product Owner” is a term from Scrum, which is only one form of Agile. Scrum is really designed around the notion of small teams of seven plus or minus two, who do all the development and testing of the project solution. The Team would work with a Product Owner, who owns what goes into the project and what does not.

To scale Scrum, organizations have formed what is known as a Scrum of Scrums where there are numerous teams, each the size mentioned above, and each with a Product Owner. A representative of each team (or possibly the Product Owner) then participates as a member of a sort of meta-team, which coordinates what the individual teams are doing. This team would have its own Product Owner, who owns the larger solution. In a huge project, there may be another tier (a Scrum of Scrums of Scrums), but that’s really risky.

You could follow this model, giving each system a team and a PO, and then coordinating between the POs. Or you could try a different Agile approach, such a Kanban or Crystal.

Shouldn’t the project have a business analyst / solution designer in order to capture the requirements properly and come up with a solution which states how the the requirement could be fulfilled and which systems must do what activity?

At a high level yes but the phrase ‘capture the requirements properly’ catches my eye. The product owner knows the requirements at the highest level. Properly.
They are not defined in a lot of detail because with Agile you play out the implementation with actual code and demos. Similarly for ‘which systems do what’, that is not defined at a details level until it is actually built and able to be seen. At which point the user / product owner / business will refine their requirements.