The waterfall model is a linear and sequential model defined for software engineering life cycle. It is a classic and very popular model that distinctly defines various phases and the goals that each phase has to achieve. It is called a waterfall model because just like a waterfall once the course of life cycle has started there is no looking back.The water will flow from the top to bottom and not reverse its course. In similar fashion in this life cycle the course of software development cannot be reversed.
In waterfall model the approach is very strict and well defined but there is not much of scope for revision. Testing is a phase and does not go hand in hand with development. So, it is not possible to detect defects early in development stage.
The sequences of phases in waterfall model are as follows:
All phases mentioned above are cascaded with each other and one phase can start only after the previous phase has been closed successfully.
Waterfall model can be used in situations where the requirements are well defined and clear, the product is stable and there are enough of resources available for each phase. Waterfall model should be practically implemented only in small and easily manageable projects. It should not be used in projects in which the requirements are at moderate to high risk.Requirements Specification and Analysis
The development of a software application depends only one thing and that is how well the requirements are captured and documented. This process of identifying and then documenting the requirements for software development is called Requirement specification and analysis.
The client, the management team and the technical support team of the company discuss the requirement of the software in complete detail. These requirements are analyzed, discussed several times and then documented till they are clear and complete.
The requirements can be documented in the format defined by the company such as description in word docs, flow charts, drawings etc. The outcome of the entire exercise is a detailed document that describes what the customer wants. This is necessary so that one is able to understand the requirement of the client properly. In present day we say that defect is anything that is not in line with the requirement of the customer. If we capture the requirement incorrectly we will start the project on the wrong foot.User Requirement Specification
This document defines what a user wants and what his expectations from the software are. This document gives a clear picture about the business needs of a client. This document is written by the end users. These requirements are tested in the user acceptance testing. This document is not technical in nature. It talks about the business need of the user and forms the foundation for planning the next steps in capturing the requirements and system design.Software Requirement Specification
The software requirement specification defines how the user wants the software to function. The purpose of this document is as follows:
Software Design can be of the following types:
High level software design provides a clear picture about the database design and the function architecture of the system. High level Software design serves as a guide for the development team. Whenever there is any doubt regarding the design flow, the developers refer to High Level Design (HLD) document. In order to create this document it is important that the Software Requirements Specification (SRS) document should be absolutely clear.Detailed Software Level Design
Detailed software level design or Low Level Design (LLD) involves breaking the high level design in smaller sections and writing down the logic that would serve as program specification. LLD provides detailed information about the system and it cannot be created till the HLD is ready.Software Design Processes
Software design Processes can be classified as:
Top-down approach is a very systematic approach in which first the outline of the system is devised without defining details of any subsystem. Once the outline for the system is ready it is time to move down step by step to every subsystem. Every sub system is defined in complete detail till the specification reaches the base elements.Bottom Up Design Approach
Bottom up design approach is exactly the opposite of top down approach. In this case the first step involves defining the base elements in complete detail and then linking these elements to form various sub systems which are further linked together till the time the complete system is formed. This approach can be compared to planting a tree where at the beginning all that we have in hand in a seed but as we start working on it a tree is formed.