At first sight, I liked this methodology to think about the development. It's (like almost all the time) a software development guide but it can be easily transported to hardware.
The first thing to notice is that the x-axis is time and the y-axis is how detailed is the design. So we begin with requirements that comes from the user's needs. The first phase depends on how much envolvement you get in your product development.
Then, from the requirements and standards that need to be on the design should be writen, always remembering that it should be a test case on the acceptance test.
This is important so that these requirements are not vague or impossible to be tested. If a requirement can't be tested how is it possible to determine in the end of the project that all user's needs are achived?
In my opinion, it's always better to have a simple and clean requirement document that it's always revisited than some forgotten document in a folder on the project manager's pc.
Then, we have the analysis of the requirements and hardware architecture design. For me, in this phase, it's necessary to draw one master block diagram, with all major blocks, connections between boards, cables, color coded voltage rail, isolation between circuits, etc.
From there, it's a good practice to draw simple block diagrams for power distribution, cables with all connections, isolation, etc. So that it's really simple to start the next phase, the actual design, with schematic, cable designs and a document with the test cases needed for the next phase.
The other part of the V are the tests. The lowest one are the tests on the PCBs and cables from the design phase. It can be divided by a board bring up (a simple test - to see if nothing burns) and a formal verification test based on the test cases from the design phase, when it's necessary to stress the board to the limit (maybe beyond).
The next test is the integration, when you integrate 2 or more PCBs and cables, and run a test, and then integrate it with the mechanics, for example, and test it again, until all project is assembled and full integration test is done.
The last test is related to all user's needs and standards. You should probably do some standards tests, for example EMC testing before this last phase, we don't want to find out a big problem on this phase.
I guess the V-model is always important for people with no technical background to understand the difficulties that arise from a change on the requirements when you are already on the test phase. This might lead to a lot of rework. So, I would say it's really important to get all phases the time needed, do not rush on going down the V when the previous tasks are not done and freezed. See this post about project milestones.