Bansilal Ramnath Agarwal Charitable Trust’s
i. Vishwakarma Institute of Technology, Pune-
37
(An autonomous institute of Savitribai Phule Pune University)
Experiment 2:
To prepare a Software Requirement Specification (SRS) document, based on several types of
system requirements, such as functional and non-functional requirements.
Year Third
Branch CS(AI&ML)
Division A
Batch 1
PRN 12210066
Roll no. 21
Subject Software Engineering
Name Pushpak Gadhe
Software requirement specification
(SRS) document template
Project
name:
BodyOS
Date: 1
May 2025
Version: 1
By: Pushpak Gadhe
Table of contents
2 Functional requirements
1
Introduction
1.1 Product scope
1.2 Product value
1.3 Intended audience
1.4 Intended use
1.5 General description
3
External interface requirements
3.1 User interface requirements
3.2 Hardware interface requirements
3.3 Software interface requirements
3.4 Communication interface requirements
4
Non-functional requirements
4.1 Security
4.2 Capacity
4.3 Compatibility
4.4 Reliability
4.5 Scalability
4.6 Maintainability
4.7 Usability
4.8 Other non-functional requirements
5 Definitions and acronyms
1 Introduction
Describe the purpose of the document.
1.1 Product scope List the benefits, objectives, and goals of the product.
BodyOS helps users monitor their health through tracking various exercises and maintaining
historical data. The application processes sensor input or manually entered data to calculate
metrics such as calories burned and workout effectiveness.
1.2 Product value Describe how the audience will find value in the product.
This application provides value by offering an intuitive way to maintain and visualize health data,
helping users stay motivated and aware of their fitness progress.
1.3 Intended audience Write who the product is intended to serve.
This product is intended for fitness enthusiasts, personal trainers, and anyone seeking to improve
their physical health.
1.4 Intended use Describe how will the intended audience use this product.
The app will be used to record exercise sessions, analyze trends, and generate feedback based
on individual performance over time.
1.5 General description Give a summary of the functions the software would
perform and the features to be included.
The system accepts user input for exercises, processes the information to compute metrics like
repetitions and calories burned, and displays results in a simple graphical interface. It supports
modular integration with wearable sensors or manual entry.
2 Functional requirements
List the design requirements, graphics requirements, operating system
requirements, and constraints of the product.
- Users can input exercise type and body part involved.
- System estimates repetitions and calories burned.
- Feedback is provided after each exercise set.
- Results are stored for long-term analysis.
3 External interface requirements
3.1 User Describe the logic behind the interactions between
interface
requirements the users and the software (screen layouts, style guides,
etc).
A simple and responsive interface for inputting exercise data, viewing feedback, and checking
historical stats using graphs or lists
3.2 Hardware List the supported devices the software is intended
interface to run on, the network requirements, and the
requirements communication protocols to be used.
The app can optionally interface with hardware like mobile sensors or fitness wearables for
exercise tracking.
3.3 Software Include the connections between your product and other
interface software components, including frontend/backend
requirements framework, libraries, etc.
The backend uses Python. Optional frontend could be web-based (HTML/CSS/JS). Interfaces with
utilities for exercise detection and feedback using custom modules.
3.4 Communication List any requirements for the communication
interface programs your product will use, like emails or
requirements embedded forms.
No specific communication protocol required for this version. Optional email integration for
reports can be added later.
4 Non-functional requirements
4.1 Security Include any privacy and data protection
regulations that should be adhered to.
User data will be stored securely with access restrictions. Optional login/authentication
mechanism may be implemented in future versions.
4.2 Capacity Describe the current and future storage
needs of your software.
Supports hundreds of exercise records per user; scalable to store years of history depending on
device storage.
4.3 Compatibility List the minimum hardware requirements for your software.
Compatible with Python 3.7+ environments. Can run on macOS, Linux, and Windows with
appropriate Python setup.
4.4 Reliability Calculate what the critical failure time of your
product would be under normal usage.
The app is designed to run offline and provide reliable tracking in standalone mode with minimal
external dependencies.
4.5 Scalability Calculate the highest workloads under which your
software will still perform as expected.
Modular design supports future expansion with APIs, sensor integrations, or cloud sync.
4.6 Maintainability Describe how continuous integration should be used to
deploy features and bug fixes quickly.
Well-documented code and separation of concerns through modular scripts enable easy
maintenance and feature extension.
4.7 Usability Describe how easy it should be for end-users to
use your software.
Designed for ease of use with minimal input needed from users. Visual feedback and summaries
enhance user experience.
4.8 Other List any additional non-functional requirements.
SRS - Software Requirement Specification
UI - User Interface
ML - Machine Learning
