Tuesday, June 26, 2012

pushpendra sarswat




BRS --> SRS --> FRS

... this is the hierarchyBusiness requirement specification (BRS) : It's having all the business rules , it will prepared by Business analyst/Client, but we are unable to understand that business rules , so our domain experts will create FRS or SRS, so that we can easily understand. It contains brief description about the application. It is the 1st process that should be followed by every Organization in order to gather the Customer/client business requirements.
A Software Requirements Specification (SRS) is a comprehensive description of the behavior of a system to be developed. It includes use cases that describe all of the interactions that users will have with the software. Use cases are known as functional requirements. An SRS may also include hardware interfaces communication interfaces as well as other non-functional requirements such as performance requirements quality standards and design constraints. It's having all the software requirements information , so totally almost both are same (some what we can say). System Requirement Specification in which PM/PL collect the information of requirements which will be needed for the development of Application. SRS Prepared by the Developer TL/PM/PL by taking inputs from BRS.
After completion of developing BRS, Business Analyst people will concentrate to develop SRS Doc basing on BRS Doc . This Doc defines Customer Use case requirements and system requirements to be developed as new software.
It contains functional and nonfunctional requirements of the project suppose a function is there to add two numbers adding the function is functional requirement the color of the numbers, background color these type of details are non functional requirements.

The contents of SRS are



                 1. Use Case

                 2. Use Case Diagram

                 3. Task Flow Diagrams

                 4. Pictorial Diagrams

                 5. Actors

                 6. Pre conditions, Post conditions etc.

A Functional Requirements Specification (FRS) can be derived from the SRS. This document describes the processes that users employ when interacting with the system. It describes inputs (what a user does) and outputs (how the application responds to user input). This document is often used by members of a test team to create test cases. It's having all the information of functionality which are using in our project , its having all functional rules. Prepared by the developer.

A document that describes in detail the characteristics of the product with regard to its. Functional Requirement Specification in which mentioned all the details of System functionality. How system works. All the conditions and Validation as well as process are mentioned in FRS. Functional Requirement Specification is also called as Business Requirement Specification.
The contents of FRS :

                 1. Purpose

                 2. Objectives

                 3. Scope & Requirements

                 4. Functional & Non Functional requirements                    

                 5. Security levels

                 6. Existing & Non Existing environment


The Functional Requirements Specifications deals with the Client Requirements and the Software Requirements Specifications deals with the Company resources.To begin with, we should understand the difference between the two document types. Software Requirements Specification describes the system's functional as well as non-functional requirements (e.g. performance requirements, security requirements, availability requirements etc.). On the other hand Functional Requirements Specification (FRS) deals with the functional requirements only.



In a particular project, the following four possibilities exist.



1) Both SRS and FRS are available

In this case, you should find out which document is the latest one. As mentioned above, you may understand the non-functional requirements from the SRS and in case the FRS is the latest document, the functional requirements from there. Be warned that sometimes even non-functional requirements are documented in the FRS. The structure of the available SRS and FRS should be able to guide you in your study.



2) Only SRS is available

There is no confusion in this case. You may understand all the software requirements from this document.



3) Only FRS is available

You may understand the functional requirements from this document. However, you should find out about the non-functional requirements from the business analyst/ project manager/ customer support etc.



4) None of these documents is available

This can happen when the project has been running for a long time. Either the SRS or FRS documents will not be available or they will be quite out-of-date and therefore, unusable.

In such a case, you should find out the availability of any other documents/ material e.g. high-level business requirements, existing help files/ user manuals, existing test cases, user stories, customer issues and resolutions etc. In addition, it becomes important to discuss the requirements with various project roles that may be present e.g. system analyst, business analyst, product management, development, support etc. so that you may get your queries resolved. If you notice any discrepancies, you should point it out to the concerned roles and note their resolution.

On top of SRS/ FRS, the Test Engineer should refer Change Requests (mainly enhancements/ modifications to the software) and the resolution of customer issues.

By following the above guidelines, the Test Engineer can understand the requirements and subsequently perform testing.