•Depends on capturing and freezing requirements early in the life cycle
•Depends on separating requirements from design
•Feedback is only from testing phase to any previous stage
•Not feasible in some organizations
•Emphasises products than processes
•Emphasizes completion of two phase before moving on
•Emphasises early planning, customer input, and design
•Emphasises testing as an integral part of the life cycle •Provides quality gates at each life cycle phase
•Requirements can be set earlier and more reliably
•Requirements can be communicated more clearly and completelybetween developers and clients
•Requirements and design options can be inquired in to quickly and with low cost
•More requirements and design faults are caught early
•Requires a prototyping gizmo and expertise in using it – a cost for the development organisation
•The prototype may become the production technique
•It promotes reuse of existing application in early stages of development
•Allows quality objectives to be formulated during development
•Provides preparation for eventual evolution of the application product
•Eliminates errors and unattractive options early.
•It balances resource expenditure.
•Doesn’t involve separate approaches for application development and application maintenance.
•Provides a viable framework for integrated Hardware-software technique development.
•This technique needs or usually associated with Quick Application Development, which is hard practically.
•The technique is more difficult to manage and needs a different approach as opposed to the waterfall model (Waterfall model has management techniques like GANTT charts to evaluate)