Software Requirement Document When a System or an application needs to be developed there will be an objective what that system is going to serve. Requirement document is written in order to make sure that the application is developed and tested in such a way that the application will serve the same objective once it’s released. Let’s discus about Software Requirement Document in brief.
Software Requirement Document In other words, all the expected functionalities out of the application are documented in terms of “Requirements” and the same document is called as Requirement document. This Document is taken as a benchmark from various people in the project team like developers, testers, Business Analysts etc. to understand the functional requirements of the application. It is also called SRS document which System Requirement Specification Document.
We will now write few Requirements for the GMAIL website for better understanding. As it was explained earlier gmail is developed with an “Objective” of providing free email services. Now we will take few functionalities of gmail and write Requirements for them. 1. Home Page.
Let’s assume gmail is our client. Client has asked for an authentication functionality to identify unique users in the Home page of gmail. These requirements are written only to demonstrate how requirements would look like, and they are not real. Our first requirement would look something like this. 1.1 Login Functionality: Home page of the website should have login mechanism in order to identify unique users. The same page should also have the options to reset password for already registered users. There should also be an option for New Registrations for new users. 1.2 Home page: When the user is providing the login credentials, there should be an option to remember his login so that if the user closes and reopens the browser, his login session should be still active. 1.3 User ID Field: User id field should have all the field validations. 1.4 Password field: Password textbox should be present to enter the password. As we can see these are very raw requirements and this document is called as High Level document.These requirements will further be divided into low level requirements for the ease of understanding. The same document is called as low level document. We will take the same requirements what we have written for gmail and break them into low level requirements. Ex: 1.1 Login Functionality: (Original High Level Requirement) Home page of the website should have login mechanism in order to identify unique users. The same page should also
have the options to reset password for already registered users. There should also be an option for New Registrations for new users. Low level Requirements for the same. 1.1.a Home page of the website should have a userid and password text fields with a submit button for login functionality. 1.1.b Home page of the website should have a link for already registered users where they can reset the password. 1.1.c A Button called “Create Account� should be present for new users for account creation. 1.2 Home page: (Original High Level Requirement) When the user is providing the login credentials , there should be an option to remember his login so that if the user closes and reopens the browser, his login session should be still active. Low Level requirements. 1.2.a Home page should have a option to remember the login session. 1.2.b On closing and reopening the browser the user session should be still active if opted to remember the login by user. 1.3 User ID: Field. (Original High Level Requirement) User id field should have all the field validations. Low Level requirements. 1.3.a User ID field should throw validation message if exceeds more than 15 characters. 1.3.b User ID field should throw validation message if its less than 3 characters. 1.3.c User ID field should throw validation message if only numbers are entered.
1.3.d User id Field should throw validation message if any special characters are entered. 1.4 Password field: (Original High Level Requirement) Password textbox should be present to enter the password. Low Level requirements. 1.4.a Password field should not accept more than 15 characters 1.4.b Password field should not accept less than 3 characters. 1.4.c Password entered should not be visible and only dots should be displayed. The high level and low level requirements shown here are only examples. Real time requirements can vary based on different scenarios.