Software Requirements Specification

For

RGMCET Notifications

Prepared by:

Team-10

M. HariKrishna (16091A0534)
E. KeerthiPriya (16091A0550)

M. Binitha (16091A0517)

C. Bharath (16091A0514)

Dept. of CSE, RGMCET, Nandyal.

Table of Contents

1. Introduction
1.1 Methodology
1.2 Purpose
1.3 Scope
1.4 Definitions, Acronyms and abbreviations
1.5 Tools used
1.6 References
1.7 Technologies to be used
1.8 Overview
2. Overall Description
2.1 Product perspective
2.2 Product functions
2.3 User classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation constraints
2.6 User Documentation
2.7 Assumptions
3. External Interface Requirements
3.1 User Interfaces
3.2 Hardware Interfaces
3.3 Software Interfaces
3.4 Communications Interfaces
4. System Features
4.1 System Feature1
4.2 System Feature2 (and so on)
 5. Other Non-Functional Requirements
5.1 Performance Requirements
5.2 Safety Requirements
5.3 Security Requirements
5.4 Software Quality Attributes
5.5 Business Rules
6. Other Requirements

Appendix A: Glossary

Appendix B: Analysis Models

Appendix C: To Be Determined List

Revision History

Name Date Reason For Changes Version

1. INTRODUCTION

1.1 Methodology

The Rational Unified Process brings together elements from all of the generic
process models, supports iteration and illustrates good practice in specification and design.
The RUP is described in three perspectives:

A dynamic perspective that shows the phases of model over time.

A static perspective that shows the process activities that are enacted.

A practice perspective that suggests good practices to be used during the process.

The different phases are

Inception

The goal of the inception phase is to establish a business case for the system.
Identifying all external entities that will interact with the system and defining these interaction.
This information is used to assess the contribution of system to business.
Elaboration
The goals of the elaboration phase are to develop an understanding of the problem
domain, establish an architectural framework, develop project plan and identify key project
risks.
Construction
This phase is concerned with system design, programming and testing. Parts of the
system are developed in parallel and integrated during this phase.
Transition
This is the final phase of RUP and is concerned with moving the system from the
development community to the user community and making it work in real environment.

1.2Purpose

The purpose of this project is to develop an android application to provide students

an easy access to notifications,information about college events,fee payment and timetable.
1.3 Scope

The RGMCET Notifications provide the information to users within the time.

The major benefits of the software are:

1.It is a software which helps to organize event without any paper work.

2.It has a wide variety of modules.

By few clicks the user can have access to documents provided, notifications
regarding college events, fee payment and time table can be accessed.

1.4 Definitions, Acronyms and Abbreviations

.apk file- Android application package file

SDK-Software Development Kit

SRS-Software Requirements Specification

Servers: Machines that store all the information and records

GUI-Graphical user interface

dex file- Dalvik Executable file

adb- Android Debug bridge

VM-Virtual Machine

Module-A Module is a software component or part of a program that contains one

or more procedures. One or more independently developed modules make up a
program.

Employee/Staff member-An individual who works part-time or full-time under a

contract of employment, and has recognized rights and duties.

Administrator: He has the authority to add/delete the users and maintains the
database
1.5 Tools Used

ANDROID STUDIO: Android Studio is the official integrated development environment (IDE)
for Android application development. It is based on the IntelliJ IDEA, a Java integrated
development environment for software, and incorporates its code editing and developer tools.

1.6 References

Software Engineering book by Roger Pressman and Ian

Sommerville IEEE SRS format

1.7 Technologies to be Used

● ANDROID SDK
● FIREBASE-CLOUD MESSAGING
● FIREBASE-AUTHENTICATION

1.8 Overview

Existing system
The present RGMCET notifications app is created from the existing manual
announcement of notifications in college by the administration which may or may not
reach to students within the time.
Disadvantages of Existing System

• Difficult to reach

• Time consuming

• Everything is manual

• Paper Wastage

• Overhead due to high amount of audience

Proposed System
RGMCET notifications app is developed to push notifications for the candidates who
installed the app in their mobiles. It is developed in android platform. The notifications
are delivered by using firebase-cloud message.
Advantages of Proposed System
Student get easy access of notifications, important dates and information of the
college. Student can know the information within time.
The provided documents, pdf’s and timetable can be easily downloaded by selecting
them.
Our Plan
Register and login for users
Reach notifications within time
Can download documents and can view them

2. OVERALL DESCRIPTION

Describes the general factors that affect the product and its requirements. This section
does not state specific requirements, instead it provides a background for those
requirements.

2.1 Product Perspective

Our project is enhancement of existing system. It also reduces the time and work of
users to access notifications. Here admin maintains the all information about the database.The
system will provide users with complete information of college. Here the system will store the
data for fast and easy reference, it also provides the information about important dates. Thus, the
system will reduce the time and complexity of maintaining the data.

2.2 Product Functions

Some major project functionalities of the system are:

● To provide the student to get easy access of getting notifications, important

dates and information of their college.
● Administrators sends the notifications using fire base cloud messaging .
● Users can document easily by selecting them.
2.3 User classes and characteristics

Primary users of the system is students and staff working in college and administrator for
uploading files and notifications.
 Student(favoured) The Student is person or people who studies in
institutions and need to login and get access to
the information.

Staff(favoured) The Employee is person or people who work

for organizations/institutions and need to
login and access to the information and can
provide some documents.

Administrator Administrator is the person or people, who

will have any and all the privileges of all other
user types. They will be able to impersonate
other employees within the system. They
have authority to upload documents and
provide information through notifications.

2.4 Operating Environment

Open source, Mobile phone.

System is not dependent on geographical areas
There should be no constraints on users being able to access the system at a given time
Continuous service is preferred, but as long as there is no data loss, interruptions can to
tolerated

2.5 Design and Implementation Constraints

All the data must be stored in databases and the system will work with high performance,
user friendly, security based system, validation of users, very fast response time.

2.6 User Documentation

No user documentation information at this time.

2.7 Assumptions

Assume that all information entered by the user will be correct. If any wrong
information then system will notify an alert saying wrong credentials. Although basic password
authentication and security mechanisms will be used to protect from unauthorised access.
Redundant Database setup as the role of backup database server when primary database is
failure.

3. EXTERNAL INTERFACE REQUIREMENTS

3.1 User Interfaces

Some of the User Interface Screens are described in table 1.

Table 1: LES User Interface Screens

Screen Name Description
Login Log into the system.
Welcome Display the screen with the application name and available options.
Feedback Navigate based on user feedback.
User Views the uploaded files and access to notifications.
Admin Sends the notifications by using FireBase cloud messaging.
Database Contains files and user details.
Sideview Presence of all available options of application and user profile.

3.2 Hardware Interfaces

The system shall run on:

Operating system: Any Android Mobile

A computer with minimum requirement of 4 GB Ram , 500 GB HDD(10 GB free space)

Web browser: Google Chrome, Mozilla firefox.

3.3 Software Interfaces

Programming Language: Java, sql

IDE: Android Studio

Data base : Firebase database

3.4 Communications Interfaces
The System supports Google chrome and Mozilla Firefox web
browsers. The System should send the notifications to the users.

4. SYSTEM FEATURES

Some of the system features available in this system are:

4.1 Student management

4.1.1 Description and Priority

Administrators will be able to log into the system and manage student
information and can also able to add/drop student they are managing.

Priority: high.

4.1.2Stimulus/Response Sequences

Stimulus: User requests to add employee.

Response: System checks user permissions and if employee does not already exist
in database adds it and displays list of current employees with newest
employee, by displaying employee added.

Stimulus: User requests to remove employee.

Response: System checks permissions and if employee exists in database removes

it and displays list of current employees displaying as employee
removed.

Stimulus: User requests to edit employee.

Response: System checks user permissions and recalls from the database the
information that has been saved, and fills in the data on a new form for
the user to fill out.

Stimulus: User requests to submit changes to employee.

 Response: System checks user permissions and updates employee in database and
returns to list of employees with recently added entity.

4.1.3Functional Requirements

Student Add The system shall let a User that is an

administrator with correct permissions who is
logged into the system to add Students.

Student Remove The system shall let a User that is an

administrator with correct permissions who is
logged into the system to remove Students.

Student Edit The system shall let a User that is an

administrator with correct permissions who is
logged into the system to edit Student.

4.2 Generate and print reports

4.2.1 Description and Priority

Application will need to be able to generate reports for HODs/Managers

and administrators. They print reports for student’s records.
Priority: medium.

4.2.2Stimulus/Response Sequences

Stimulus: User requests to generate a report.

Response: System displays form containing parameters and submit button.

Stimulus: User requests to submit a report generation form.

Response: System retrieves information from database and displays report in web
browser along with ‘Print’ button.

Stimulus: User requests to print report.

Response: System redirects user to print the generated report.

 4.2.3Functional Requirements

Upload Document The system shall allow the user to upload

a document to be sent through the
application.

View Document The system shall check to see if all

required information is present, and
displays the documents to the user.

Download Document The system shall recall data from

database, to downloads the generated
documents.

4.3 Impersonate other users

4.3.1 Description and Priority

Administrators will have the ability to impersonate other users,

allowing them to troubleshoot more easily and correct information if necessary.
Priority: medium.

4.3.2Stimulus/Response Sequences

Stimulus: User requests to impersonate user.

Response: System changes currently logged in user to the selected user.

4.3.3Functional Requirements

Impersonate User Submit The system shall allow a user who is logged
in and is an administrator with the correct
permissions to impersonate other users.

Impersonate User Invalid The system shall check to see if the desired
user is valid, and prompt the user to choose
a different user and resubmit if it is not.
5. OTHER NON-FUNCTIONAL REQUIREMENTS

Non-functional requirements define the needs in terms of Performance, logical

database requirements, design constraints, standard compliance, reliability, availability,
security, maintainability and portability

5.1 Performance requirements

It provides the better performance as the interface is easy for the user and feedback
acceptance for the future modifications.
5.2 Safety requirements
No harm is expected from the use of the application either to the OS or any data that
resides on the client system.
5.3 Application security requirements
The product is protected from unauthorized users from using it the system allows only
authenticated users to work on the application. The users of the system are an admin and users.
5.4 Software Quality Attributes

5.4.1 Standard Compliance

There shall be consistency in variable names within the system. Graphical user
interface shall have a consistent look and feel.

5.4.2 Reliability

Specify the factors required to establish the required reliability of software system at
time of delivery.

5.4.3 Availability

The system shall be available 24X7

5.4.4 Maintainability

The RGMCET Notifications is developed in Android Studio using Java and deployed
in mobile phones which is easy to maintain.

5.4.5 Portability

The leave management shall run in Android environment and is used on any device.
 5.5 Business Rules

No Business rules information at this time.

6. OTHER REQUIREMENTS

Appendix A: Glossary

.apk file- Android application package file

SDK-Software Development Kit

SRS-Software Requirements Specification

Servers: Machines that store all the information and records

GUI-Graphical user interface

dex file- Dalvik Executable file

adb- Android Debug bridge

VM-Virtual Machine

Appendix B: Data flow diagrams

No data flow diagrams information at this time.