The Agile V-Model?
The V Model is a well known representation of a system development life-cycle.
It’s kind of linear moving from requirements analysis, architecture, design through coding and all kinds of testing until final deployment.
It’s goal is to minimize risk, improve quality and improve communication and understanding among all stakeholders.
One good thing about it is that it proposes a verification step after each development step. In the Requirements Analysis phase for example a requirements document is written that is verified by the users and that serves as input for writing acceptance tests. The Requirement document also serves as input for the next phase of design. After Requirements Analysis the System Design starts. System design is verified by system tests that are written during system test design and then the next step etc.
One problem with the V-Model is that it suggests a linear approach with limited feedback cycles. Feedback is based on documentation and assessment on documentation but not on real working software! Risk is not handled that well because final testing is done very late in the development cycle where any unpleasant surprises, and there are usually quite a lot, can put a project in deep trouble.
In Agile we would say that the requirements are most (e.g. usability being excluded) of the acceptance tests. See Robert Martin’s paper Tests and Requirements; Requirements and Tests on this.
Furthermore we would do acceptance testing all the way during the project and let the acceptance tests drive our architecture and system design. Yes acceptance tests also cover performance, scalability and so on. Because we do acceptance testing all the time there is no need for a separate system testing or integration testing phase. System and integration tests are just part of acceptance testing!
In designing modules for realizing a particular acceptance test we would write unit tests. These unit tests would drive our module design and our coding. So, no need for Module Design as a separate phase anymore.
If we take out these phases of system design, module design, system testing and integration testing we end up with a model like
In this model we can see that requirements are expressed as acceptance tests. The acceptance tests drive architecture design through unit tests and coding. The iterations of unit testing, coding and architecture design is executed until the acceptance test completes. On the resulting system an acceptance test is performed by the customer which results in further insights of requirements.