One of the prominent questions I often hear in software development projects is when to start with architecture design. Sometimes, architects hesitate to start until almost all requirements are available in high quality. This strategy is highly recommendable when you like to postpone architecture design forever. There is not a single project with medium to high complexity I remember where we knew all forces in full depth and breadth at project start.
First of all, it heavily depends on the software development process. In a Waterfall model without iterations you are stuck anyway. Thus, I generally recommend an iterative-incremental approach. In software developments with all their volatility only piecemeal growth can succeed.
It is important to have a sufficient quality and quantity of requirements available, for example, the most important 30%-50% of use cases and non functional qualities with unique priorities. This way, you can come up with a conceptual architecture which you can then use as a base for iterative-incremental refeinement.
After the baseline is available prioritize all user requirements (use cases), map them to end-to-end scenarios and integrate them into the architecture, keeping the non-functional qualities in mind. To deal with non functional qualities let key developers, architects or even teams work on principles and guidelines how to address these qualities. Do this after the baseline architecture design but before starting the end-to-end iterations.
As soon as new requirements appear or have been concretized assign them priorities and put them into the “backlog”.
To introduce a kind of safety net for embracing change, introduce test-driven design methods, flash architecture reviews after each iteration, and (architecture and code) refactoring activities after each flash review.
Keep in mind that sometimes you need courage to decide even when not all details are available. It is typical for all creative and volative acts that not all details are known in advance, nor the ways how to cope with them.
As a consequence, it is much more productive and effective to follow wrong paths sometimes instead of following no path at all.
To keep it simple: Prefer acting over reacting