Sviluppo e interazione agili con gli sviluppatori

"Product Owner" è un termine di Scrum, che è solo una forma di Agile. Scrum è davvero progettato intorno al concetto di piccoli team di sette più o meno due, che fanno tutto lo sviluppo e il test della soluzione del progetto. Il team lavorerebbe con un proprietario del prodotto, proprietario di ciò che entra nel progetto e cosa no.

Per scalare Scrum, le organizzazioni hanno formato quella che è nota come Scrum of Scrums dove ci sono numerosi team, ciascuno delle dimensioni sopra menzionate, e ciascuno con un Product Owner. Un rappresentante di ogni squadra (o eventualmente il proprietario del prodotto) partecipa quindi come membro di una sorta di meta-team, che coordina ciò che i singoli team stanno facendo. Questo team avrebbe il proprio Product Owner, proprietario della soluzione più ampia. In un progetto enorme, potrebbe esserci un altro livello (una Scrum of Scrums of Scrums), ma questo è davvero rischioso.

Potresti seguire questo modello, assegnando a ciascun sistema una squadra e un PO, e quindi coordinando tra gli OP. Oppure puoi provare un approccio Agile diverso, come un Kanban o un Cristallo.

Il progetto non dovrebbe avere un analista di business / progettista di soluzioni per acquisire correttamente i requisiti e trovare una soluzione che indichi in che modo il requisito potrebbe essere soddisfatto e quali sistemi devono fare quale attività?

Ad un livello alto sì, ma la frase "cattura i requisiti correttamente" attira la mia attenzione. Il proprietario del prodotto conosce i requisiti al più alto livello. Correttamente.
Non sono definiti in dettaglio perché con Agile si esegue l'implementazione con codice e demo effettivi. Allo stesso modo per "quali sistemi fanno cosa", che non è definito a livello di dettagli finché non è effettivamente costruito e in grado di essere visto. A quel punto l'utente / proprietario / azienda del prodotto affineranno i loro requisiti.