Software Requirements Specification.docx

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: user

Smart maintenance and security management

Database

Level 1:

Admin/executive body/supervisor

authentication

1.3 Track security 1.1 1.2 maintenan ce

Residents details(add/delete/ update/retrive)

Update payment

Residents(owners/te nants) Generate bills

database

database

Level 2(1.1): Residents Post queries/issues

Make payments/Bill s

Track and register visitor’s details

database

database

Level 2(1.2): Security/Executive Members

Register residents,wor king staff

Update visitors deatails entering premisis

Database

Database

Notify residents

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

SMSMS FD Diagram:

Update_noti ceboard()

Add_Resident() removeResident()

Track_maint enancepay()

security

updateResident()

Log_in() 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