requirment requirment requirment requirment requirment requirment

 

Requirement Gathering & Analysis

Requirements Gathering

Typically, requirements gathering is done through a series of interviews/sessions with the stakeholders to understand the why’s and how’s of the project. These requirements are documented in theBusiness Requirements Specification. We understand that the most difficult part of requirements gathering is not documenting what the users 'want'; it is the effort of helping users figure out what they 'need' that can be successfully provided within the cost and schedule parameters available to the development team. Therefore, we make sure that the Requirements are actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.

Analysis

The analysis starts in parallel with the Requirement gathering so that any ambiguities/confusions are resolved with the client before moving on to development. This also saves on a lot of time spent on review and rework later on. During the Requirement Analysis the Functional and Non-Functional requirements are identified and clearly stated in theSystem Requirements Specifications document. It also includes a set of use cases that describe all of the interactions that the users will have with the software.

We also emphasize on review of the Analysis thoroughly internally as well as by the customer.

next phase: Development
Design and Coding Design and Coding Design and Coding Design and Coding Design and Coding Design and Coding

 

Testing

Unit Testing

Unit testing is a method of testing that verifies the individual units of source code are working properly. This is done by the Software engineers. The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. A unit test provides a strict, written contract that the piece of code must satisfy. Unit tests find problems early in the development cycle. This reduces a lot of effort on review and rework at a time of QA.

QA

Software is tested from two different perspectives:

  • Internal program logic is exercised using “white box” test case design techniques.
  • Software requirements are exercised using “black box” test case design techniques.

In both cases, the intent is to find the maximum number of errors with the minimum amount of effort and time. A set of test cases designed to exercise both internal logic and external requirements is designed and documented, expected results are defined, and actual results are recorded. When we begin testing we change our point of view. We try hard to “break” the software!

This way we catch most of the bugs/issues before the application actually gets deployed at the client’s server.

UAT

User Acceptance Testing (UAT) is a process to obtain confirmation by a Subject Matter Expert (SME), preferably the owner or client, through trial or review, that the software meets mutually agreed-upon requirements.

The UAT acts as a final verification of the required business function and proper functioning of the system, emulating real-world usage conditions on behalf of the paying client or a specific large customer. If the software works as intended and without issues during normal use, one can reasonably infer the same level of stability in production.

next phase: Release