BRS

This is the first document that we generate for a project. It specifies what the Client needs in Non-technical terms. This document is the outcome of the requirements gathering phase. It contains the details of the end to end business. After the client interview sessions are over we generate this document and get a sign-off from the stakeholders. This is done in order to make sure that the client understands what to expect from the system.

SRS

A Software Requirements Specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all the interactions the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains nonfunctional ( or supplementary ) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints).

TDD

A Technical design document (TDD) is a written outline of the development of a course or a description of a software product that a software designer writes in order to give a software development teams an overall guidance of the architecture of the software project.

The TDD contains the following documents:

Test Plan

A test plan defines the objectives and scope of the testing effort, and identifies the methodology that the team will use to conduct tests. It reflects our entire project testing schedule and approach. It also identifies the hardware, software, and tools required for testing and the features and functions that will be tested. Our well-rounded test plan notes any risk factors that jeopardize testing and includes a testing schedule.

Test Result

Once testing is completed, testers generate metrics and make final reports on their test effort and send it over to the developers who in turn work on the defects identified by the testersOnce a defect has been dealt with by the development team, it is retested by the testing team. And after the testing team agrees to close the defect only then the application is ready to be deployed on the client’s server.

Deployment Plan

The Deployment Plan describes the set of tasks necessary to install and test the developed product such that it can be effectively transitioned to the user community. It provides a detailed schedule of events, persons responsible, and event dependencies required to ensure successful cutover to the new system.

Deployment can impose a great deal of change and stress on the customer's employees. Therefore, ensuring a smooth transition is a key factor in satisfying the client. Our Deployment Plan minimizes the impact of the cutover on the client’s staff, production system, and overall business routine. Our Deployment plan includes:

Release Plan

The release plan is used both for the initial planning of software releases, and then for tracking the plan during development and making informed changes in either delivery dates or feature content as the need arises. It is such that clients can make decisions with up-to-date information and in such a way that the common problem of development over-commitment is avoided.

The release-plan also provides a place where the client can get an immediate and accurate appraisal of current development status. Our release plan includes:

CR Log

This document gives a complete description of the Change requests as sent by the client. We have a Software Change Request Log Register which registers the changes requests as and when they come from the client. Each Change Request is first registered in the CR log and then documented in the CR document. This document has the complete details of reproducing the error, explanation, priority, severity etc.

This CR log helps the client and development team in understanding the changes being done on the application. It also comes handy while testing.