Software Requirements Specification

For
Smart Maintenance and Security Management System

BY

S.ATISHYA EDDY

1602-16-733-070

CSE-B,BE ¾

VASAVI COLLEGE OF
ENGINEERING
Table of Contents

1. Introduction

1.1 Purpose

1.2 Scope

1.3 Definitions, Acronyms, and Abbreviations

1.4 References

1.5 Overview

2. General Description

2.1 Product Perspective

2.2 Product Functions

2.3 User Characteristics

2.4 General Characteristics

3. Specific Requirements

3.1 Functional Requirements

3.2 Performance Requirements

3.3 Non-Functional Requirements

3.4 Design Constraints

3.5 Interfaces

3.5.1 User Interfaces

3.5.2 Hardware Interfaces

3.5.3 Software Interfaces

3.5.4 Communications Interfaces

3.6 Licensing Requirements

3.7 Legal, Copyright, and Other Notices

3.8 Applicable Standards

4. Supporting Information
1.Introduction

1.1 Purpose

Purpose of the document this paper is the Software Requirement Specification (SRS)
for the Smart Security and Maintenance Management System. The purpose of this
paper is to describe the functionality, requirements and general interface of our project.

The main aim of the project is to provide utility to maintain day to day operations of
apartments. This software helps them to store all transactions electronically in a system,
which in turn saves lot time, money and energy. Now it is very difficult to manage all the
data manually, also if some information is required urgently then to obtain this is very
difficult. To solve this problem now they are looking for better alternative solution
Keywords: Databases, Programming.

Smart Security and Maintenance management programs are designed to provide utility
to the daily operations of apartment and this software enable to keep records of the
daily transactions in an electronocial manner which saves a lot of energy, time and
money. This application also ensures to secure the building by keeping a track of
people entering and leaving and also intimating the same to residents through
notification. This software helps to main the track records of sales, purchases, receipts,
installments, advances made, maintenances, discuss issues on common platform,
secured gated system and other related issues. It helps in replacing the manual system
of record keeping with the modern computerized system. It I a difficult task to manage
the records of each and every apartment in the manual system. It will not only take a lot
of time but it also increases the chances of errors.

1.2 Scope for development of this paper

This project will help the residents to manage day to day maintenance and security very
easily. By making it as a general project we can sell this project to many builders. The
specification identifies what such a system is required to do. The specification is written
in a format conforming to the IEEE Standard 830-1984. Subject to approval, the
specification will complete the Requirements phase and will be followed by detailed
design, implementation, and testing.

Sometimes even after repeated cross checks errors are found which lead to wrong
calculation of accounts and balance sheet. It creates a problem when you need details
of any particular project. All these problems lead to the rise of an alternative option This
software helps to mainly track the records of sales, purchases, receipts, installments,
advances made, maintenances, discuss issues on common platform, secured gated
system and other related issues efficiently and in a secured manner. It helps in
replacing the manual system of record keeping with the modern computerized system.
All of these sub-systems (maintenances, secured gated system etc) need to be
designed and implemented so that Smart Security and Maintenance management
system can run effectively.

1.3 Definitions, Acronyms, and Abbreviations

SMSMS Smart Maintenance and Security Management System

GUI Graphical User Interface

FLID Flat Identification Number

1.4 References

1) http://www.academia.edu/32391081/Apartment_rental_management_system

2)http://www.nitc.ac.in/mis_srs_detailed_2.0.pdf

1.5 Overview

This specification includes a brief product perspective and a summary of the functions
the software will provide. User characteristics are discussed and any general
constraints or assumptions and dependencies are listed.

Requirement statements are categorized as functional requirements, performance

requirements, non-functional requirements, or design constraints. Functional
requirements are further categorized in terms of patient management, nurse
management, or bed management. Non-functional requirements are further categorized
in terms of security, maintainability, and scalability.

2.1 Product Perspective

The SMSMS is designed to help the apartment administrator to handle owners, tenants
and staff, like security personnel’s, housekeepers etc, and information. The current
design goal is to build an internal system to achieve the functionality outlined in this
specification.

2.2 Product Functions

The AMS will allow the user to manage information about patients owners, tenants and
staff, like security personnel’s, housekeepers etc. Security management will include the
walking-in and walking-out of people to and from the apartment. The SMSMS will also
support the automatic backup and protection of data.

2.3 User Characteristics

There are three different types of users for the HMS system:

Type 1. Welfare Association Committee: This includes Secretary, President, and

Treasurer, Executive members who are elected on mutual understanding
among the owners or by voting. These are the main people who look into
the functioning of various activities like funds, maintenance etc. They are
assumed to be experienced and well versed with the technical aspects like
accessing the website and adding or retrieving information from database.
Meetings conducted are presided by these members as well as owners to
discuss issues and settle them efficiently.

Type 2. Owners and tenants: They comprise as residents of the apartment who
have all rights to raise issues, take part in meetings, avail facilities. They
are also bound to pay all bills, maintenance, rents on time. They should be
educated with the software being used to ensure that they make at most
use of the benefits.

Type 3. Working Staff: This includes people like supervisors, security guards,
housekeepers, plumbers, electrician, gardener etc, who carry out various
daily maintenance tasks. Of the three user types nurses have the least
computer knowledge. There is a requirement for staff to perform some
data entry. Supervisors, Security personals will need to make regular
scheduling changes, and so the interface should be easy to use.

Based on the above categorizations, in order to meet user's needs the following

preCautions should be taken:

 the interface should be designed with the computer novice in mind

 data entry masks should recognize and correct improperly entered data
 for deleting or revising a record the system should ask the users for confirmation
 report generation should occur in a timely fashion
 diverse computer education levels should be considered
  online help is important
 the design should not assume users will perform their jobs as expected
 error messages should be used
 system design should follow the manual process as closely as possible
 the interface should be easy to understand
 users should be consulted throughout design

2.4 General Constraints

The following constraints will limit the developer’s options for designing the system:

 the budget for this project is 100000 INR

 Implementation is required by the end of week 11, semester 2, 2020.

3. Specific Requirements

3.1 Functional Requirements

R 1. Residents Management Subsystem

R 1.1 SMSMS shall allow Type 1 people to update patient personal information
(name, flat number, telephone number, email,.…).

R 1.2 The SMSMS shall store all residents’ history information (like their
previous stay, identity proof info.…).

R 1.3 The SMSMS shall allow the user type 1 to add new residents
(owners/tenants) into the system.

R 1.3.1 The SMSMS shall assign a unique ID to new patients.

R 1.4 SMSMS shall allow users of type 1 and 2 to retrieve information of all
residents, i.e., by allowing them to retrieve name, phone number etc

R 2. Maintenance Management Subsystem

R 2.1 SMSMS shall allow type 1 and 3(supervisor only) to add new staff details,

R 2.2 SMSMS shall allow typ1 and 3((supervisor only)) to update staff details

R 2.3 SMSMS shall allow typ1 and 3((supervisor only)) to remove staff details
 R 2.4 SMSMS shall allow type 1 to add all information regarding staff being
hired for security purposes

R 2.5 SMSMS shall allow type 1 and 2 to access discussion platforms to tackle
issues and to make complaints

R 2.6 SMSMS shall allow Type 1 and 3 (supervisor only) to update notice board
info(by posting information to be circulated to residents and keeping a
track of all previous circulars)

R 2.7 SMSMS shall allow Type 1 to update maintenance payment details

R 2.8 SMSMS shall allow supervisor to update if any flats are vacant time to
time

R 3. Security Management Subsystem

R 3.1 SMSMS shall allow security person to update details of people entering
the apartment. R 3.2 SMSMS shall allow security person to update details of
people entering the apartment.

R 3.3 SMSMS shall allow type 1 and security to update staff info for allowing
only authorized people to enter

R 3.4 SMSMS shall allow type 3(only supervisor) to update vendors who are
allowed entry to the apartment

R 4. Other Requirements

R 4.1 The SMSMS shall backup residents, maintenance and security related
data every 24 hours automatically.

3.2 Non-functional Requirements

R 6. Security.

The security requirements are concerned with security and privacy issues. All residents’
personal information, security system information is required by law to be kept private.
Only after the request sent to resident is accepted signs can view the additional details
about any particular resident. Residents need to be informed through notifications sent
through software about any visitor claiming to want to visit them.

R 6.1 The SMSMS shall support different user access privileges.

 R 6.1.1 User type 2 and 3 shall have security privilege level 1. They
can only read whether flat is occupied or not, flat numbers and
contact information. They can’t access patient payments
information.

R 6.1.2 User type 1 and 2 shall have security privilege level 2. They
can read and write residents information. They can keep track of
payments and maintenance information

R 6.1.3 User type 1 shall have security privilege level 3. They can
read and write staff, resident’s information. They can keep track of
payments and maintenance information

R 6.2 The SMSMS shall protect residents, maintenance, and security

information.

R7. Maintainability

The maintainability requirements are concerned with the maintenance issues of

the system.

R 7.1 The repair time of SMSMS shall be under a half hour.

R 7.2 System down time for maintenance should be less than 6 hours per
quarter of a year.

R8. Scalability

The scalability requirements are concerned with the scalable issues of the
system.

R 8.1 The HMS shall be able to scale up to support more workstations.

System performance shall not degrade if up to twenty percent
(20%) more workstations are added.

3.4 Design Constraints

R 9. The HMS shall use a graphical user interface.

R 10. The HMS must run in the 3rd year computing labs.

R 11. The HMS must be written in Java.

3.5 Interfaces
3.5.1 User Interfaces

Will make use of the existing Web Browsers such as Microsoft Internet Explorer
or Netscape. The user-interface of the system shall be designed in the user-interface
prototypes.

3.5.2 Hardware Interfaces

The existing Local Area Network (LAN) will be used for collecting data
from the users and also for updating the Database.

3.5.3 Software Interfaces

A firewall will be used with the server to prevent unauthorized access to the
system.

3.5.4 Communications Interfaces

The Online System will be connected to the World Wide Web.

3.6 Licensing Requirements

The usage is restricted to only apartment that is purchasing the Online Library
System and signs the maintenance contract.

3.7 Legal, Copyright, and Other Notices

This cannot be used without its consent.

3.8 Applicable Standards

The ISO/IEC 6592 guidelines for the documentation of computer based

application systems will be followed.

4. Supporting Information

The use-case storyboards or the user-interface prototypes are not available. The
appendices are not to be considered as part of the requirements.
 Data Flow Diagram:

Level 0:
Smart
maintenance
user Database
and security
management

Level 1:

Admin/executive
authentication
body/supervisor

1.3

Track security

1.1
1.2
maintenan
ce Residents
details(add/delete/ database
update/retrive)

Update
payment database

Residents(owners/te
nants)

Generate
bills
Level 2(1.1):

Residents
Post
queries/issues

Make database
payments/Bill
s

Track and
register
visitor’s details

database
Level 2(1.2):

Security/Executive
Members Register
residents,wor
king staff Database

Update visitors
deatails
entering Notify residents
premisis

Database
 Level 2(1.3):

Track
discussion
forum
Executive body/supervisor
Solve
issues/Probl
ems

Conduct
meeting

Update
payments

Handle notice
board

Update working
staff details Database
 Log_in()

Admin team Update_noti

SMSMS FD Diagram: ceboard() Add_Resident()

removeResident()

Track_maint updateResident()
enancepay()

Log_in()
security
addStaff()

visitorDetails()

notifyResidents()

SMSMS FDD log_in()

owner
postIssues()

payBills()

Log_in()

tenants
payIssues()

payMai tenance()

Log_in()

supervisor
updateStaff()

checkIssues()
UML DIAGRAM
Interaction Diagrams:
Collaboration diagram