Once you have produced a rough design document then you can use the ‘technical features’ statements to help you to start thinking about the systems that you will be using to implement your design. I like to identify the large scale systems / requirements at this stage to guide the overall architecture.
Some systems will be common to all games / engines although most will have multiple possible approaches to satisfy the system requirements. For instance, pretty much all games require systems to manage the rendering, input, sound effects, music, scene management, loading / saving, etc. etc. but how they are implemented can be completely different.
Jason Gregory, in his excellent in-depth book ‘Game Engine Architecture’, discusses how the runtime engine architecture is built in layers, each layer depending upon the layers below to operate. Layers include the hardware, drivers, and Operating System, 3rd party libraries, a Platform Independence Layer, the Core Systems, Resources, low-level systems, front end and gameplay foundations, and finally game-specific systems.
Microsoft XNA Game Studio enables us to skip over some areas as it will handle those for us, acting as a framework to build our own work upon. As long as the Operating System is supported (and the hardware/drivers meet certain requirements) we can ignore much of the lowest levels of the architecture. Many 3rd party libraries are available for C# and XNA including physics, animation, scripting or other technologies. We don’t directly need a Platform Independence Layer as XNA handles that (as long as we code with alternate platforms in mind) and also provides some of the Core System and low-level rendering functionality as well.
The idea here is not to get too bogged down in the minutiae of the individual system implementations but to have a rough idea of the overall systems that will be used and how they will connect / communicate. If you are also using a particular design methodology or pattern(s) then this is the place to consider it and how that may guide the architecture.
Try not to over-analyse what you will need / implement or you may end up spending so much time on this that you lose impetus (known as analysis paralysis).
Another issue to avoid is becoming ‘locked in’ to particular design choices. You may find that an early design choice is not really appropriate later on, so rather than rigidly stick to the early design you have to be willing to adapt and evolve.
The balance between flexibility and the original goals should be a personal / team decision and clearly communicated early on, don’t be afraid to explore new ideas or change / trial different elements but keep the main aspects / key features in sight to keep you moving forward.