You are on page 1of 4

Business Requirement

This document describes user’s needs for the application. This is done over a period
of time, and going through various levels of requirements. This should also depicts
functionality that are technically feasible within the specific times frames for delivery
of the application. As this contains user perspective requirements, this document
would serve as a base for UAT test preparation.

This document is used to understand the user requirements and find the gaps
between the User Requirement and Functional Specification.
Test team should break the business requirement document into modules depending
on how the user will use the application.

Functional Specification
This document describes the functional needs; design of the flow and user
maintained parameters. These are primarily derived from Business Requirement
document, which specifies the client’s business needs.

The proposed application should adhere to the specifications specified in this

document. This is used henceforth to develop further documents for software
construction and validation and verification of the software. In order to achieve
synchronization between the software construction and testing process, Functional
Specification (FS) serves as the Base document.

The testing process begins by first understanding the functional specifications. The
FS is normally divided into modules. The tester should understand the entire
functionality that is proposed in the document by reading it thoroughly.

It is natural for a tester at this point to get confused on the total flow and
functionality. In order to overcome these, it is advisable for the tester to read the
document multiple times, seeking clarifications then and there until clarity is

A high level understanding of the data requirements for respective modules is also
expected from the tester at this point. Interaction with test lead at this point in time
is crucial to draw a testing approach, like an end-to-end test coverage or individual

Design Specification
This document is prepared based on the functional specification. It contains the
system architecture, table structures and program specifications. This is ideally
prepared and used by the construction team. The Test Team should also have a
detailed understanding of the design specification in order to understand the system

System Specification
This document is a combination of functional specification and design specification.
This is used in case of small applications or an enhancement to an application. Under
such situations it may not be advisable make two documents

It explains what are the roles involved. It's a process of developing a software
system in an organized, controlled, and predictable way

Waterfall Model
This is the most common and classic of life cycle models, also referred to as a
linear-sequential life cycle model. It is very simple to understand and use. In a
waterfall model, each phase must be completed in its entirety before the next phase
can begin. At the end of each phase, a review takes place to determine if the project
is on the right path and whether or not to continue or discard the project.

* Simple and easy to use.
* Works well for smaller projects where requirements are very well understood

* Adjusting scope during the life cycle can kill a project
* High amounts of risk and uncertainty.
* Poor model for complex and object-oriented projects.
* Poor model where requirements are changing.

V-Shaped Model

Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution
of processes. Each phase must be completed before the next phase begins. Testing
is emphasized in this model more so than the waterfall model though. The testing
procedures are developed early in the life cycle before any coding is done, during
each of the phases preceding implementation.

Requirements begin the life cycle model just like the waterfall model. Before
development is started, a system test plan is created. The test plan focuses on
meeting the functionality specified in the requirements gathering.

The high-level design phase focuses on system architecture and design. An

integration test plan is created in this phase as well in order to test the pieces of the
software systems ability to work together.

The low-level design phase is where the actual software components are designed,
and unit tests are created in this phase as well.

The implementation phase is, again, where all coding takes place. Once coding is
complete, the path of execution continues up the right side of the V where the test
plans developed earlier are now put to use.


* Simple and easy to use.

* Each phase has specific deliverables.
* Higher chance of success over the waterfall model due to the development of
test plans early on during the life cycle.
* Works well for small projects where requirements are easily understood.


* Very rigid, like the waterfall model.

* Little flexibility and adjusting scope is difficult and expensive.
* Software is developed during the implementation phase, so no early prototypes
of the software are produced.
* Model doesn’t provide a clear path for problems found during testing phases.