This phase consists of two distinct activities, namelyRequirements gathering and

analysis Requirements specification The goal of the requirements gathering

activity is to collect all relevant information from the customer regarding the
product to be developed. This is done to clearly understand the customer
requirements so that incompleteness and inconsistencies are removed. The
requirements analysis activity is begun by collecting all relevant data regarding the
product to be developed from the users of the product and from the customer
through interviews and discussions. For example, to perform the requirements
analysis of a business accounting software required by an organization, the
analyst might interview all the accountants of the organization to ascertain their
requirements. The data collected from such a group of users usually contain
several contradictions and ambiguities, since each user typically has only a partial
and incomplete view of the system. Therefore it is necessary to identify all
ambiguities and contradictions in the requirements and resolve them through
further discussions with the customer. After all ambiguities, inconsistencies, and
incompleteness have been resolved and all the requirements properly understood,
the requirements specification activity can start. During this activity, the user
requirements are systematically organized into a Software Requirements
Specification (SRS) document. The customer requirements identified during the
requirements gathering and analysis activity are organized into a SRS document.
The important components of this document are functional requirements, the
nonfunctional requirements, and the goals of implementation. DEPT OF CSE & IT
VSSUT, Burla Design: - The goal of the design phase is to transform the
requirements specified in the SRS document into a structure that is suitable for
implementation in some programming language. In technical terms, during the
design phase the software architecture is derived from the SRS document. Two
distinctly different approaches are available: the traditional design approach and
the object-oriented design approach.Traditional design approach -Traditional
design consists of two different activities; first a structured analysis of the
requirements specification is carried out where the detailed structure of the
problem is examined. This is followed by a structured design activity. During
structured design, the results of structured analysis are transformed into the
software design.Object-oriented design approach -In this technique, various
objects that occur in the problem domain and the solution domain are first
identified, and the different relationships that exist among these objects are
identified. The object structure is further refined to obtain the detailed design.
Coding and unit testing:-The purpose of the coding phase (sometimes called the
implementation phase) of software development is to translate the software
design into source code. Each component of the design is implemented as a
program module. The end-product of this phase is a set of program modules that
have been individually tested. During this phase, each module is unit tested to
determine the correct working of all the individual modules. It involves testing
each module in isolation as this is the most efficient way to debug the errors
identified at this stage. Integration and system testing: -Integration of different
modules is undertaken once they have been coded and unit tested. During the
integration and system testing phase, the modules are integrated in a planned
manner. The different modules making up a software product are almost never
integrated in one shot. Integration is normally carried out incrementally over a
number of steps. During each integration step, the partially integrated system is
tested and a set of previously planned modules are added to it. Finally, when all
the modules have been successfully integrated and tested, system testing is
carried out. The goal of system testing is to ensure that the developed system
conforms to its requirements laid out in the SRS document. System testing usually
consists of three different kinds of testing activities:α – testing: It is the system
testing performed by the development team.β –testing: It is the system testing
performed by a friendly set of customers.Acceptance testing: It is the system
testing performed by the customer himself after the product delivery to determine
whether to accept or reject the delivered product. System testing is normally
carried out in a planned manner according to the system test plan document. The
system test plan identifies all testing-related activities that must be performed,
DEPT OF CSE & IT VSSUT, Burla specifies the schedule of testing, and allocates
resources. It also lists all the test cases and the expected outputs for each test
case. Maintenance: -Maintenance of a typical software product requires much
more than the effort necessary to develop the product itself. Many studies carried
out in the past confirm this and indicate that the relative effort of development of a
typical software product to its maintenance effort is roughly in the 40:60 ratios.
Maintenance involves performing any one or more of the following three kinds of
activities:Correcting errors that were not discovered during the product
development phase. This is called corrective maintenance.Improving the
implementation of the system, and enhancing the functionalities of the system
according to the customer’s requirements.

This is called adaptive maintenance. Shortcomings of the classical waterfall

model The classical waterfall model is an idealistic one since it assumes that no
development error is ever committed by the engineers during any of the life cycle
phases. However, in practical development environments, the engineers do
commit a large number of errors in almost every phase of the life cycle. The
source of the defects can be many: oversight, wrong assumptions, use of
inappropriate technology, communication gap among the project engineers, etc.
These defects usually get detected much later in the life cycle. For example, a
design defect might go unnoticed till we reach the coding or testing phase. Once a
defect is detected, the engineers need to go back to the phase where the
defecthad occurred and redo some of the work done during that phase and the
subsequent phases to correct the defect and its effect on the later phases.