Teamwork for an architect

One day we had a dream team built to deliver a technical proposal for one client working in bioinformatics.
Business used very special language so we had a team of business analysts to form functional requirements. BAs had PhD in bioinformatics and understood the business.

How would the ideal process look like?
BAs form functional requirements and then an architect starts working with them.

What did we have?
Everyone worked at the same time since the project had a limited time frame.

Developing an architecture having a base of functional requirements changed constantly was quite a pleasure :-)
In the end we had 3 days remaining and I found out that a new major requirement was added that changed the whole picture completely.

What did we do?
It's not possible to reconsider whole architecture in remaining days.
We presented the solution as is stating explicitly that the last requirement should be taken into consideration as soon as the next phase of the project starts.

Why did that happen?
BAs said that it was clear for them that the problematic requirement was actual since day 1. They added it to internal notes and posted to the shared space in the end only, it's my problem I don't attend all BAs meetings and don't know all their notes.
BAs said they did a great job - their job was to produce functional requirements and they did that.

What was wrong?
Somehow overall success of the project was not a goal of BAs. It was a goal of me (the architect) and delivery manager but we were busy with our own work expecting each party will highlight important aspects with others.
But what if each party doesn't know what another party needs? Plaid old management issue.

How can we improve it?
Concurrent work having natural dependency between workers requires high discipline of the team and mature processes tuned to support high collaboration in a small time frame.
It's much easier and efficient to follow natural dependencies and do the work one by one.