Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Software Requirement Document

DZone's Guide to

Software Requirement Document

In this article, we'll review how to craft a Software Requirement Document for both high-level and low-level software documentation.

· Agile Zone
Free Resource

The single app analytics solutions to take your web and mobile apps to the next level.  Try today!

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 discuss the Software Requirement Document briefly.

Software Requirement Document

In other words, all the expected functionalities out of the application are documented in terms of “Requirements” and this document is called a 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 an SRS document, which stands for System Requirement Specification Document.

Software Requirement DocumentWe will now write few a Requirements for the Gmail website to help you gain a better understanding. As it was explained earlier, Gmail was developed with the “Objective” of providing free email services. Now we will take a few functionalities of Gmail and write Requirements for them.

1. Home Page

Let’s assume Gmail is our client. The client has asked for an authentication functionality to identify unique users on Gmail's home page. These requirements are written only to demonstrate what requirements would look like, and they are not real. Our first requirement would look something like this:

1.1 Login Functionality:

The homepage of the website should have a login mechanism in order to identify unique users. The same page should also have the option for registered users to reset their password. There should also be an option where new users can register.

1.2 Homepage:

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 a High-Level document. These requirements will further be divided into low-level requirements for the ease of understanding into a low-level document. We will take the same requirements that we have written for Gmail and break them into low-level requirements.

Example: 

1.1 Login Functionality:

(Original High-Level Requirement) The homepage of the website should have a login mechanism in order to identify unique users. The same page should also have the options to reset the 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 The homepage of the website should have user id and password text fields with a submit button for login functionality.

1.1.b The homepage 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 The homepage: (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 still be active.

Low-Level Requirements:

1.2.a The home page should have an option to remember the login session.

1.2.b On closing and reopening the browser the user session should still be active if opted to remember the login by the 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 it's 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.

--------------------------------------------------------------------------------------------------------------------Also Check:

Requirements Traceability Matrix (RTM)

CA App Experience Analytics, a whole new level of visibility. Learn more.

Topics:
requirements management ,system design ,agile ,document requirements

Published at DZone with permission of Rohit Sharma. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}