How to write a good SRS for your Project

A software requirements specification (SRS) is a description of a software system to be developed. It lays out functional and non-functional requirements and may include a set of use cases that describe user interactions that the software must provide.

The output of requirement engineering is the requirement specification document (SRD). it can be considered as a contract between the development team and the customer which can be also used to resolve any disagreement that may arise in future.

it is the specification for the particular software product , program or set of programs that perform certain function. it serves a number of purposes depending upon who is writing it. the srs document must be written in two phase:

First SRS should be written by the customer and second SRS should be written by the developer. first srs is used to define an expectations of the user and second srs is written for different purpose and serves as a contract document between customer and developer.

Why SRS?

In order to fully understand one’s project, it is very important that they come up with an SRS listing out their requirements, how are they going to meet them and how will they complete the project. It helps the team to save upon their time as they are able to comprehend how are going to go about the project. Doing this also enables the team to find out about the limitations and risks early on.

The following is a sample SRS that I wrote for one of my projects.

SRS’s characteristics include:

• Correct
• Unambiguous
• Complete
• Consistent
• Ranked for importance and/or stability
• Verifiable
• Modifiable
• Traceable

Project Plan: MeetUrMate

1. Introduction

This document lays out a project plan for the development of the “MeetUrMate” open source repository system by Anurag Mishra.

The intended readers of this document are current and future developers working on “MeetUrMate” and the sponsors of the project. The plan will include, but is not restricted to, a summary of the system functionality, the scope of the project from the perspective of the “MeetUrMate” team (me and my mentors), scheduling and delivery estimates, project risks, and how those risks will be mitigated, the process by which I will develop the project, and metrics and measurements that will be recorded throughout the project.

2. Overview

In today’s world, owning to the heavy workload on the employees, they are having a huge amount of stress in their lives. Even with the presence of so many gadgets in and around them, they are not able to relieve their stress. I aim to develop an application that would enable them to share the thing of their liking and meet the person who has the same passion as theirs. For eg. If someone wants to share their art, they can share it through the platform, if someone wants to sing any song, they can record it and share the same. They can also share videos (with some funny commentary in the background), share mysteries that other people can solve, post any question. Through my platform, I’ll enable them to meet people who share common interests and passions, chat with them, and have some fun.

2.1 Customers

Everyone. Anyone can use this application ranging from a child to an old-age person.

2.2 Functionality

• Users should be able to register through their already existing accounts.
• They should be able to share snaps/videos/snaps.
• People should be able to like and comment on any post. One person can follow another person who shares common interests and likings which would enable them to find mates apart from their usual friend circle.
• Each user can have his/her profile picture, status
• People can post mysteries and other people can solve the mysteries.
• Users will get points for the popularity of their posts/the number of mysteries they solve.
• Add own funny commentary on any video
• Post any questions regarding their interests and people can answer.

P.S. Italic points features can be inculcated later.

2.3 Platform

It will be launched both as a Web-based application and a Mobile app for Android.

2.4 Development Responsibility

I, Anurag Mishra, would be developing the software and I am responsible for the creation of the Database and all the other related kinds of stuff.

3. Goals and Scopes

• Users should be able to register through their already existing accounts.
• They should be able to share snaps/videos/snaps.
• People should be able to like and comment on any post.
• One person can follow another person who shares common interests and likings which would enable them to find mates apart from their usual friend circle.
• Each user can have his/her profile picture, status.
• People can post mysteries and other people can solve the mysteries.
• Users will get points for the popularity of their posts/the number of mysteries they solve.

4. Deliverables

I’ll deliver the following during the course of development:

• Feature specification
• Product design
• Test plan
• Development document
• Source code

5. Risk Management

5.1 Risk Identification

Following will be the risk involved in my project:

1) People are already using Facebook to find friends. So, what would be the real cause that would motivate them to join my application?

5.2 Risk Mitigation

Even though most of the users would already be using Facebook, our platform would still offer them many things that are not there on Facebook. For eg.

1. They don’t meet people who share common interests and passions as much. Our application would enable them to meet people (apart from usual friends) who share common interests and passions on a more frequent basis.
2. Users of FB cannot share songs on the go that they have sung whereas on our app they can do that on the go.
3. People can post mysteries/cases and other people can solve them. Moreover, people will get points in case they solve the mysteries or on the basis of the popularity of their posts.
4. More importantly, people need not register for my application, instead, they can log in using their already existing accounts of Google/Facebook.

Thus, I think that there is a considerable amount of difference between Facebook/Instagram/Twitter and my application and it would attract many people.

6. Scheduling and Estimates

7. Technical Process

Following would be the languages I would use to develop my application within the stipulated time period:

Front-end development: Jquery, HTML, CSS, PHP.

Back-end development: PHP, MySQL.

For Android app: Java on Android SDK.

An SRS (Software Requirements Specification) is a document that outlines the requirements for a software project. A well-written SRS is essential for a successful software development project. Here are some tips for writing a good SRS for your project:

• Start with a clear introduction: Provide an overview of the project and its goals. Define the scope of the project and explain what the software is intended to do.
• Use clear and concise language: The SRS should be easy to read and understand. Avoid using technical jargon and complex sentences. Use bullet points and tables to organize information.
• Describe the functional requirements: List the features and functionality of the software. Explain how the software will work and what it will do. Use cases to describe the interactions between the user and the software.
• Describe the non-functional requirements: In addition to functional requirements, there may be non-functional requirements that are important for the software. Examples include performance, scalability, security, and usability.
• Specify any constraints: There may be constraints that limit the software development project. For example, there may be limitations on the hardware or software platforms that the software can run on.
• Use diagrams and visual aids: Use diagrams, flowcharts, and other visual aids to help explain the software and its features. This can help to make the SRS more engaging and easier to understand.
• Define the acceptance criteria: Specify the criteria that must be met for the software to be considered complete and ready for release. This should include testing criteria and user acceptance criteria.
• Review and revise: Once the SRS is complete, review it carefully to ensure that all requirements are clearly defined and that there are no ambiguities. Make revisions as needed to improve the clarity and completeness of the document.

Overall, a good SRS is clear, concise, and comprehensive. It should provide a detailed and accurate description of the software project, its features, and its requirements. By following these tips, you can create an SRS that will help ensure the success of your software development project.