EXPERIMENT 3

Functional and Non-functional requirements

FUNCTIONAL REQUIREMENTS:

1.One to one call

Platform should support one to one call.

2.Group video calling

Platform should support group video call so that many people can interact with each other.

3. Audio/Video/Screen share

Platform should support audio so that the speaker’s voice is audible to the members in the

call, should support video, able to share the screen.

4.Record the video

Platform should be able to record the video call so that user can view the video later.

NON-FUNCTIONAL REQUIREMENTS:

1.Superfast

Platform should be superfast.

2.High availability

System should have high availability.

3.Data loss

Now let us see how client application talks to the server.

 Experiment-4

1 What is SRS?
A software requirements specification (SRS) is a document that captures complete description about
how the system is expected to perform. It is usually signed off at the end of requirements
engineering phase.

2 Need & Scope of SRS

 Need

 The users and the client get a brief idea about the software while in the initial stages.
 The purposes and the intentions as well as the expected results are properly defined.
It hence lays the outline for software design.
 The desired goals are defined thereby easing off the efforts of the developers in terms
of time and cost.
 It forms a basis for the agreement between the client and the developer.
 It becomes easier while transferring and using the solution elsewhere or with new
customers as the basis of functioning of the software is mentioned.
 It acts as a material for reference at a later stage.
 It acts as the basis for reviews.

 Scope
We have earlier realized the face-to-face education system of India ; it was important to discuss how
combining face-to-face lectures with technology gives rise to blended learning and flipped
classrooms. This type of learning environment can increase the learning potential of the students.
Students can learn anytime and anywhere, thereby developing new skills in the process leading to
life-long learning.

3. Structure of SRS Introduction

3.1 Purpose:

This tragic outbreak of the Corona-Virus has shaken up the education sector, and this fear is
likely to resonate across the education sector globally. This project focuses on developing an
E-learning website that facilitates students in a manner that the learning, evaluation;
assessment do not remain limited to the four walls of the class. This website works by finding
new ways to make an institute a centre of excellence in education by Providing all the study
material, exams available to students online. It provides a facility for students to
communicate with faculty regarding academics It is considered to be a relatively cheaper
mode of education in terms of the lower cost of transportation, accommodation, and the
overall cost of institution-based learning. We aim to understand the start-up which has
changed the horizon of Indian education.
 3.2 Definition

This document defines and describes the functional and non-functional requirements for
the ZOOM . It will be use as the basis for the design phase and as a reference for
development and validation stages.

3.3 Scope of SRS

The overall objective of the ZOOM is to develop a customizable, decentralized system that allows
individuals or organizations to easily, efficiently, and precisely schedule meetings in accordance
with practical limitations of virtual and real-world meetings. The ZOOM will be a web-based
application designed to support the meeting scheduling needs of an organization. It will not
require a client- based application; instead, it will be accessible and conform to standard HTML
Web Application practices. The SDMS will interface with and utilize third party resources to
facilitate all of the users’ meeting scheduling needs (e.g., database services, email communication,
etc.).

3.4 Intended-audience

1. Students(Participants)
2. Administrators and the Faculty(Hosts)

4. Overall description

4.1 User-Interface

The student is expected to be Internet literate once he/she can log in to the system and
navigate between Webpages he/she must be able to use the basic functionality of the
system. Instructors are expected to be internet literate and to be able to use more complex
functionality of the system .The user interface designed for the app is made to be user
friendly and all the required functionalities are easy to access, so yeah no hassles !!.
Participants can also chat as well as react using emoji reactions shown separately near the
chat window, this in-turn will not interrupt the whole audience and the host can separately
answer the queries of viewers.

4.2 System Interface

The application supports all major web browsers that makes it convenient for the user to
access the system with ease. The back- end i.e., the database services are used to a great
extent and hence it is quite efficiently designed .Timely updates are also available which are
notified to the user and are undertaken easily when allowed by the user.
 4.3 Constraints and Assumptions

 Hardware Constraints

 An internet connection – broadband wired or wireless (3G or 4G/LTE)

 Speakers and a microphone – built-in, USB plug-in, or wireless Bluetooth
 A webcam or HD webcam - built-in, USB plug-in, or:
 An HD cam or HD camcorder with a video-capture card
Note: See the list of supported devices.
 Virtual camera software for use with broadcasting software like OBS or IP cameras
Note: For macOS, Zoom client 5.1.1 or higher is required .

 Software Constraints

 macOS X with macOS X (10.10) or later

 Windows 11*
*Note: Windows 11 is supported on version 5.9.0 or higher. 
 Windows 10*
*Note: Devices running Windows 10 must run Windows 10 Home, Pro, or Enterprise. S
Mode is not supported.
 Windows 8 or 8.1
 Windows 7
 Ubuntu 12.04 or higher
 Reliable antivirus software
 The ZOOM will provide support for database interaction with a third-party property
management system.
 The ZOOM will provide a standardized API so that third-party programs may access
information programatically from the SDMS system.

 Design Constraints:
Each user must keep their password confidential. Moreover, the user must have an individual ID
for creating a login in the software.

 Implementation Constraints:
Only the Administrator can control user addition and deletion in the system. Also, this group has
access to all the official activities. The main challenge faced during the implementation of this
project was to capture the video and broadcast it to the client computers in real-time. The next
obstacle was the availability of a fast and reliable internet connection

 Assumptions:

It is assumed that the requirements described in this document have different levels of priority.

4.4 User Characteristics

The users shall be familiar with normal meeting scheduling activities in the real world.
The users shall be familiar with web browser operations.

5. System Feature Requirement

5.1 Functional Requirements:

 The system shall allow the administrator to add users given the following information:
 NAME
 EMAIL ADDRESS
 ROLES
o Regular user
o Administrator

 ORGANIZATION (OPTIONAL)
 The system shall allow the administrator to modify user information of following fields:
 NAME
 PASSWORD
 EMAIL ADDRESS
 ROLES
o Regular user
o Mediator
o Administrator

 The system shall allow the administrator to remove users.

 The system shall allow the administrator to create instances of three types of locations like
meeting room,virtual sessions,etc.
 Administrators can disable users. An account that is disabled will prevent the user from
working till it is reenabled by the administrator. The administrator will inform the same to the
email address with the reason for disabling.
 The system will allow users to log in with a password if they already possess a valid account on
the system. The system will protect passwords and other user information and ensure that it
will not be viewable by others except the administrator.
 Users can edit information themselves and change the password once logged in. Any change
saved in the system will be confirmed via an email.

5.2 Non-Functional Requirements:

1 Security Requirements :
The server on which an E-learning web application is should have its own security to prevent
unauthorized write/delete access.
2. The software should be portable i.e moving from one OS to another OS does not create any
problem
3. The app must be able to handle large number of users simultaneously.
4.The software must run at low internet speed.
5.3 Logical database requirements:
5.4 External Interface requirements:

6. Delivery to Approvals:
7.Advantages and Disadvantages of SRS Document:
 ADVANTAGES:
o An SRS establishes the basis for agreement between the customer and the supplier on what
the software product will perform.
o An SRS provides a reference for validation of the final product/software.
o A high-quality SRS is a prerequisite to high-quality product/software.
o A high-quality SRS reduces the development cost.

 DISADVANTAGES:

o It would be difficult to develop the system according to customer needs, without having an
SRS document
o Software developers will not know whether they are developing the product according to
the customer need.
o Software Engineers find it difficult to understand the functionality of the software, during
the maintenance phase.
o User document writer will face many difficulties writing the “user manual” without
understanding the SRS documents.