Software testing - V-Model in detail

Almost all organizations follow V-model due to its flexibility structure, it reduces the total duration of the project life cycle as several activities goes in parallel.
When we say several activities goes in parallel means the verification and validation process.
In VERIFICATION(what has to be done) we normally maintain documents (in form of inspections (formal reviews) and walkthroughs (informal review)) which will be followed in whole process of SDLC to ensure we are on the proper track and VALIDATION is the actual implementation of the verification where we test actual product.
Normally when a requirement comes, business analyst analyses the document and then creating business req spec. then planning will be done by the project manager or senior manager and last both Dev and QA team will be notified from where the parallelism of verification and validation comes in to picture.
Once requirement is provided, both QA and Dev work starts where Dev write the code and testers creating the test cases for testing.
In the above diagram,
Verification Phases --> Validation phases
Requirements analysis --> UAT
In this phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). However, it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the system’s functional, physical, interface, performance, data, security requirements etc as expected by the user, The users carefully review this document as this document would serve as the guideline.
Users who understand the business functions/requirements run the tests as given in the acceptance test plans(requirement analysis phase), including installation and Online help.
System Design --> system testing
normally business analyst analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements is not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly, this document contains business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase.
System testing will compare the system specifications against the actual system, The documents prepared in system design phase are helpful to test the system testing in other words system testing test cases prepared at system design phase(verification) but actual testing will be done at system testing phase(validation). .
Architecture Design --> Integration testing
This phase can also be called as high-level design (HLD), Software architecture is commonly represented as two-tier, three-tier or multi-tier models which typically comprises of the database layer, user-interface layer and the application layer. The modules and components representing each layer, operating environment and interfaces are laid out in detail. The output of this phase is the high-level design document which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc.
Based on the architectural design (verification), integration testing is carried out in integration testing (validation) phase where separate modules will be tested together expose faults in the interfaces and in the interaction between integrated components.
Module Design --> Unit testing
this phase is also called as low-level design (LLD). The designed system is broken up in to smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module which includes database tables, with all elements, including their type and size - all interface details with complete API, references- all dependency issues- errors, message listings- complete input and outputs for a module. The unit test case design is developed in this stage and the actual testing is done at unit testing phase after coding is done.
Coding-->
This is kept separate/middle as coding starts after all requirements freeze and verification documents finalized and before actual testing of product.
Demerits of V-model –
Requirement freezes once we start v-model as in middle of process we cant change the requirement, so if a product is started to built we need to make sure the requirement is perfect, but in case of big projects requirement keep on changing depend on situation, effects n needs, so in most organization uses Iterative model which is just customized model of v-model where v-model repeats in each release where requirements come inform of change requests or enhancements.