Experiment – 03

Project Name: Real-Time Object Detection Using YOLO

Software Requirements Specification (SRS) Report

INTRODUCTION

Purpose:-
The purpose of this document is to define the software requirements for the "Real-Time Object
Detection using YOLO" system. It outlines the objectives, features, and specifications necessary
for the development of a system that can detect and classify objects in real-time using the YOLO
(You Only Look Once) algorithm.

Scope:-

This project will implement a real-time object detection system using a YOLO model (e.g., YOLOv5
or YOLOv8). The system will capture video from a webcam or video feed, process each frame,
and detect multiple objects in real-time. It can be used in surveillance, robotics, autonomous
vehicles, and other vision-based applications.

Definitions & Acronyms:-

YOLO: You Only Look Once

FPS: Frames Per Second

GUI: Graphical User Interface

API: Application Programming Interface

OVERALL DESCRIPTION

Product Perspective:-

This Real-Time Object Detection Using YOLO is a self-contained system that manages activities of
the object detection system.
Due to improperly managed details, medical center faces quite a lot of difficulties in accessing
past data as well as managing present data. The fully functional automated object detection
system management system which will be developed through this project will eliminate the
disadvantages caused by the manual system by improving the reliability, efficiency and
performance. The usage of a database to store frame, employee, stock details etc. will
accommodate easy access, retrieval, and search and manipulation of data. The access limitations
provided through access privilege levels will enhance the security of the system. The system will
facilitate concurrent access and convenient management of activities of the medical center.

Product Functionality:-

 Provide access to authorized users only.

 Registration of new users — video frames, detection module and staff members.
 Enable frame to view their results.
 Enable frame to update their results.
 Enable video frames to schedule frame processings.
 Enable detection modules to confirm frame processings.
 Video Frames can do payment.
 Modification in schedule by frame/detection module.
 Healthcare provider updates frame’s detection output section.
 Sends requests to YOLO models for frame’s object classes/drugs.
 YOLO Model and detection module send result logs for drugs and counseling session,
respectively, to frame.
 Result Launch Interfaceg and finance personnel generate result log/receipt and verify
payment.

User Characteristics:-

1. Video Frames:
 The system should be intuitive and easy to navigate.
 Secure and authenticated access to their health results.
 Schedule, reschedule, and cancel frame processings easily.
 Receive frame processing reminders via SMS or email.
 Seek quick access to medical results, test results, and treatment plans.
 Options for virtual consultations and messaging with detection modules.
2. Detection Modules:
  Quick access to frame information, medical history, and treatment plans.
 Update video frames’ detection output, treatment plans and test results.
 Provide a system for documenting frame visits, treatment, and outcomes.
 Provide effective communication tools for sharing updates and collaborating with
other detection modules, or different departments.
3. Result Launch Interfaceg and Payment Personal:
 Proficient in accounting and result launch interfaceg processes.
 Streamlines result launch interfaceg, insurance claims, and financial reporting.
 Manage frame processings, admissions, and discharges.
 Robust security features to protect video frames’ data and ensure compliance.
 Generate financial reports, analyze result launch interfaceg data, and manage
accounts receivable.
 Track financial performances.
4. YOLO Models:
 Manage object classes inventory, dispensing, and tracking.
 Process detection outputs, manage frame object classes profiles, and drug
interaction checks.
 Integrates with EHR and provides alerts for object classes-related issues.
 Records and access detection output data.
 Effective communication tools for clarifying detection outputs and consulting with
detection modules.
 Manages object classes inventory, including stock levels and expiration dates.
 Automates the ordering process and updates inventory in real-time.
5. Developeristrator:
 Configure and setup HMS.
 User friendly interface for system setup, including adding users, defining roles, and
configuring system preferences.
 Manage user accounts permission, and access levels.
 Tools for creating, modifying, and removing user accounts, and managing user
privileges.
 System maintenance, updates, and troubleshooting.
 Tools for monitoring, backup management, and resolving technical issues
promptly.
 Ensure the system complies with data security standards and regulations.
 Generate comprehensive reports and analytics o various aspects of object
detection system operations.
 Access of KPIs for decision-making and strategic planning.
Assumptions:-

 Each user must have a valid user id and password

 Server must be running for the system to function
 Users must log in to the system to access any result.
 Only the Developeristrator can delete results.

SYSTEM FEATURES & REQUIREMENTS

External Interface Requirements:-

1. User Interface:
This software product will have a user friendly based interface. Following screens will be
provided:
 A launch interface screen for entering username, password and role will be
provided. Access to different screens will be based upon the role of the user.
 A form to search the details of a frame.
 A form for creating a new frame result will contain text fields where the Frame ID
will be machine generated and the rest details will have to be filled up.
 A form for generating the test reports.
 A form to produce a result log will create fields such as Frame ID, Frame Processing
No., Detection Engine’s charges, object classes charges, etc. will need to be filled
up.
2. Hardware Interface:
 Processor: Quad Code 2GHz or higher
 RAM: 512MB or above
 Input Devices: Keyboard, Mouse
 Output Devices: Monitor
3. Software Interface:
 Operating System: Windows 7 or higher version
 Front End: HTML, CSS
 Back End: MySQL, Python
Functional Requirements:-

1. Launch Interface:
 Frame, Detection Module and Developer can launch interface using unique id and
password.
2. Registration:
 Frame can register by filling all the required details, after this system will verify
the details and check if frame is already registered or not.
3. Make Frame Processing:
 Frame can select detection module, date time and make an frame processing
request.
4. Cancel Frame Processing:
 Frame can cancel frame processing if they want by just one click and ask for re-
schedule or refund of payment.
 Detection Module can cancel frame processing if they want by just one click. This
will send a message to frame.
5. Payment:
 Frame can pay their result log online.
6. Detection Module Module:
 Developer can add a new detection engine by filling all the details, and can also
remove them.
7. Frame Module:
 Frame can view payment history or can search for a particular result log. They can
also search for a detection engine by entering department name or detection
engine id.
8. Add Detection Output:
 Detection Engine can enter frame id and access the treatment details and
medicine, remark and advice for the frame.
9. Generate Result Logs:
 YOLO Models and detection engines can generate a result log for the frame using
their frame id, including their object classes and counseling result log.
NON - FUNCTIONAL REQUIREMENTS

Perfomance Requirements:-

 Response time: The system will give responses within 1 second after checking the frame
information and other information.
 Capacity: The system must support 1000 people at a time
 User Interface: User interface screen will response within 5 seconds

UML Diagrams :-

 User Case
 Class Diagram

 Data Flow Diagram

 Activity Diagram
 State chart Diagram
 Object Diagram
 Component Diagram
 Deployment Diagram
 Experiment – 07

Project Name: Real-Time Object Detection Using YOLO

Class and Object Diagram

Class Diagram : A class diagram is a type of UML (Unified Modeling Language) diagram that
visually represents the structure of a system by showing its:

 Classes

 Attributes (data)

 Methods (functions)

 Relationships between classes (like inheritance, association, etc.)

Key Components:

Class A box that represents an object (e.g., Car, Person, Student)

Attributes Variables/data each class holds (e.g., name, age, colour)

Methods Functions/behaviors (e.g., drive(), speak())

Relationships How classes are connected (e.g., a Student has a Course)

Types of Relationships:

 Association → Regular connection between classes

 Inheritance → One class (child) inherits from another (parent)

 Aggregation → Whole-part relationship (but part can exist independently)

 Composition → Whole-part relationship (part cannot exist without whole)

Object Diagram : An Object Diagram is like a photo of your system that shows:

 What objects are currently present

 What actual data they have (values of attributes)

 And how those objects are connected to each other

 Experiment – 08

Project Name: Real-Time Object Detection Using YOLO

Sequence Diagram

Sequence Diagram : A Sequence Diagram shows how objects interact over time, step by step
— who sends what to whom and when.
It’s like a conversation timeline between parts of the system.

Steps in the Process (Sequence Flow):

1. User starts the application

2. Camera captures live frame

3. Frame is sent to the Object Detection Module

4. Object Detection Module sends frame to YOLO model

5. YOLO model processes and returns detection results

6. Object Detection Module processes results

7. Display shows detected objects with bounding boxes

8. Loop continues for real-time detection

 Experiment – 09

Project Name: Real-Time Object Detection Using YOLO

Activity and State-chart Diagram

Activity Diagram : An Activity Diagram is a type of UML diagram that shows the flow of
activities (steps) in a process or system.

It focuses on what actions happen, in what order, and under what conditions — like a
flowchart.

Main Elements:

Symbol Element Meaning

● Start Node Where the process begins

🟦 Activity/Action A specific task or step

◆ Decision Node A condition check (Yes/No or True/False)

➡️ Arrow Flow of control

⏹️ End Node Where the process ends

State chart Diagram : A State Chart Diagram (or State Machine Diagram) shows how a
system or object changes its state in response to events.

It tells:

 What state your system is in

 What event causes a change

 What the next state will be

 Experiment – 10

Project Name: Real-Time Object Detection Using YOLO

Component Diagram

Component Diagram : A Component Diagram shows how your software system is divided
into modules or components, and how these components interact.

It helps you understand:

 How your project is organized internally

 Which parts depend on others

 How external systems or libraries are connected

Components YOLO Project:

We can divide your project into these components:

1. User Interface
→ Displays results and provides control (start/stop)

2. Camera Module
→ Captures real-time frames

3. Frame Preprocessor
→ Resizes and normalizes the frame

4. YOLO Model Engine

→ Performs object detection

5. Detection Processor
→ Filters results, interprets YOLO output

6. Display Renderer
→ Draws bounding boxes and labels
7. External Libraries
→ OpenCV, PyTorch, etc.
 Experiment – 11

Project Name: Real-Time Object Detection Using YOLO

Deployment Diagram

Deployment Diagram : A Deployment Diagram is a UML diagram that shows:

 Hardware devices (like servers, laptops, cameras)
 Software components deployed on them
 How devices are connected or communicate
It’s used to represent the physical architecture of your system.
 Experiment – 12
Hospital Management System
Testing

Introduction to Testing: -
The goal of this document is to develop a test plan for the Hospital Management System.
This document defines all the procedures and activities required to prepare for testing of
the functionalities of the system which are specified in SRS document. The objectives of
the test plan are to define the activities to perform testing, define the test deliverables
documents and to identify the various risks and contingencies involved in testing.

Test Levels: -
This section describes the overall procedure of the testing which ensures that each
feature and the combination of the features are adequately tested.

Unit Testing:-
Unit testing is when every module of the application gets tested respectively. It is done
by the developer himself. After the code is written for a feature, the developer ensures it
is working fine. Unit tests are the smallest testable components of the application.
Nowadays we have Junit, Pytest, and TestNg frameworks for unit testing the application.

Integration Testing:-
Integration testing is a testing technique where two or more independent components
are tested together. It is done by the developer. Here test cases are written to ensure the
data flowing between them is correct. For example, testing the signup form where UI
validations are correct, data reaching API, and getting stored are all validated. Integration
testing is done when the application is still developing to find bugs early on in the
development process.

System Testing:-
System testing is done by the tester where the entire application is tested as a single unit.
Hence, system testing test cases are also performance test cases, load testing, and stress
testing test cases. It is done to find the errors which might have been overlooked during
unit or integration testing. System testing evaluates both functional and non-functional
test cases.

Acceptance Testing:-
Acceptance testing is done by the client where he evaluates whether the product is made
by the requirement he listed out. It is done at the UAT server where a well-tested product
is deployed by the team for the client's reference so he can track ongoing changes in the
project. There is a defined acceptance criterion that is laid at the time of requirement
listing so that the client can validate that the product is meeting the acceptance criteria.
Once the client completes acceptance testing the product goes to production where users
can use the final application.
 Experiment – 03

Project Name: Real-Time Object Detection Using YOLO

Software Requirements Specification (SRS) Report

INDEX

 Introduction
 Overall Description
 Product Functionality
 User Characteristics
 System Feature Requirements
 Functional Requirements
 Non Functional Requirements
 UML Diagrams
o User Case Diagram
o Class Diagram
o Data flow diagram
o Activity Diagram
o State Diagram
o Object Diagram
o Component Diagram
o Deployment Diagram
o Collaboration Diagram