V-model is an extension of Waterfall model, so don't expect it to be hugely different.
Basically, you follow V-model from left to right, just like in Waterfall model. In Waterfall, you do requirements, design, implementation, verification and finally maintenance. In the same way, in V-model, you do requirements, design, implementation, verification and maintenance: same steps in both cases.
The major differences with Waterfall are the way it is presented and the emphasis on testing.
Representing the flow as V-shape helps making the difference between everything which comes prior to coding (requirements, architecture and design) and everything which follows coding (essentially testing). While tests are just one of five steps in Waterfall, it looks like practically half of the process in V-model.
The diagram in your question is a bit more complicated. What it tries to show is that, for example, system design step leads not only to the system design document, like Waterfall model would suggest, but also the system tests design, which will later help writing system tests. The diagram just puts even more emphasis on testing. Finally, doing system test design helps in architecture design (it would be awkward to do architecture design regardless system test design).
Searching what other explanations on the internet, I can't avoid quoting the following article by Bhakti Satalkar:
The main difference between waterfall model and V model is that in waterfall model, the testing activities are carried out after the development activities are over. On the other hand in V model, testing activities start with the first stage itself. In other words, waterfall model is a continuous process, while the V model is a simultaneous process. As compared to a software made using waterfall model, the number of defects in the software made using V model are less. This is due to the fact, that there are testing activities, which are carried out simultaneously in V model. Therefore, waterfall model is used, when the requirements of the user are fixed. If the requirements of the user are uncertain and keep changing, then V model is the better alternative.
This explanation is misleading. It would be true only if you replace “V-model” in the quote by any Agile method.
Unlike the article states, in V-model, testing is done after the coding; for example, see Wikipedia:
a common practical criticism of the V-Model is that it leads to testing being squeezed into tight windows at the end of development when earlier stages have overrun but the implementation date remains fixed.
While, in V-model, system test design follows system design without waiting until product implementation is done, this doesn't mean that tests themselves are performed before coding. The author confounds V-model with Agile approaches like Test Driven Development (TDD) in Extreme Programming (XP).
