1.
Introduction
1.1 Purpose
In a society, all the work is decided in meetings and maintenance bills, contact
numbers of members are recorded on the papers. There is no automated system
for doing all the things that generally happens in society, so that members can
come to know what is happening in the society. The Society Audit System
allows members to login with their own account and get updated with society
happenings.
1.2 Scope
Society Audit System is a website portal to reduce conflicts among society
members. The system has automated functionality for calculating monthly
maintenance bill and members can view their bill status on their account. The
main functionality of this project is that, there is a voting system for different
society positions like Chairman, Treasurer, etc. Members can vote the
candidates that are standing for different roles in society. The system provides a
unique interface to every user to interact with the system. The system accepts
queries from users and evaluates the need of the query and fires it over the
database and results are displayed to the user.
1.3 - Definitions, Acronyms, and Abbreviations
SAS - Society Audit System
Login ID - a user identification number to enter the system
Password - a word that enables one to gain admission into the system
Web-based application - an application that runs on the Internet
MySQL - a query language to interrogate the system
GUI - Graphical User Interface
SRS - Software Requirements Specification
1.4 References
No formal documents have been referenced in this document
1.5 Overview
This Software Requirements Specification (SRS) is the requirements work
product that formally specifies Society Audit System (SAS). It includes the
results of both business analysis and systems analysis efforts. Various
techniques were used to elicit the requirements and we have identified your
needs, analysed and refined them. The objective of this document therefore is to
formally describe the system’s high-level requirements including functional
requirements, non-functional requirements and business rules and constraints.
The detail structure of this document is organized as follows:
Section 2 of this document provides an overview of the business domain that
the proposed Society Audit System (SAS) will support. These include a general
description of the product, user characteristics, general constraints, and any
assumptions for this system. This model demonstrates the development team's
understanding of the business domain and serves to maximize the team's ability
to build a system that truly does support the business. Section 3 presents the
detail requirements, which comprise the domain model.
2.1 Product Perspective
This system is developed to manage day-to-day activities of any co-operative housing society.
Generally, in society all the work is manually. As all work is done on paper so it is very difficult to
manage and keep track of all the work expenses in the society. This society management system will
computerize all day to day operation in the society.
2.2 Product Function
Registration: Society Office User will sign in himself to the application (accredited by way of
Admin).
Responsibilities: Admin will assign the rights to the customers.
Functionalities: User then will be able to e-book the documents/plot after login effectively.
Four. User will be to transfer the report/plot of the 1st owner to second owner. System shall
have entire record of each Customer.
Payment: Payment service shall have checkout transaction with precise person details.
2.3 User Characteristics
The Society Management System permits contributors to login with their very own account
and get up to date with society happenings. Society Management System is the internet site
portal to reduce conflicts among society contributors. The system has automated
functionality for calculating monthly protection invoice and member can view their invoice
status on their account.
2.4 General Constraints
In current situations, housing society management authorities use a traditional way of
communication which include a common notice board system operated by responsible
society member.
Many of societies also have started using automated chat systems which are definitely
useful up to certain extent but though fails to serve purpose.
The system must be User-Friendly.
2.5 Assumption and Dependencies
It is assumed there should be computer and proper Internet connectivity is
established before the system is installed and tested
It is assumed that Society will have enough trained staff to take care of the system.
3. Specific Requirements
3.1 Functional Requirements
Registration
SRS001 Add Residential People
The Developed Model shall allow the software system to add new residential people to the system.
SRS002 Assign ID
The Developed model shall allow front-desk staff to give each person a ID and add it to the
Person’s record. This ID shall be used by the person throughout his/her stay in
hospital.
SRS003 Delete Person ID
The Developed model in the ward shall be allowed to delete the ID of the person
from the system when the person checks out.
SRS004 Add to House list
The Developed model in the ward shall be allowed to put the beds just evacuated
in beds-available list.
SRS005 Person information
The Developed model shall generate reports on persons about the following information:
person’s PHN, person’s name, ward name, bed number and the doctor’s name
which was assigned.
SRS006 House Availability
The Developed model shall generate reports on bed availability about the following
information: ward name, bed number, occupied/unoccupied.
Database
SRS007 Person Mandatory Information
Each person shall have the following mandatory information: first name, last
name, phone number, personal health number, address, postal code, city, country,
person identification number.
SRS008 Update Person Information
The Developed model shall allow the user to update any of the person’s information as
described in SRS007.
3.2 Design Constraints
SRS009 Database
The system shall use the MySQL Database, which is open source and free.
SRS010 Operating System
The Development environment shall be Windows 2000.
SRS011 Web-Based
The system shall be a Web-based application.
3.3 Non-Functional Requirements
3.3.1 Security
SRS012 Person Identification
The system requires the person to identify himself /herself using PHN
SRS013 Login ID
Any user who uses the system shall have a Login ID and Password.
SRS014 Modification
Any modification (insert, delete, update) for the Database shall be synchronized
and done only by the administrator in the ward.
SRS015 User’s Rights
User shall be able to view all information in software interface, add new person
to Database but shall not be able to modify any information in it.
SRS016 Administrators' Rights
Administrators shall be able to view and modify all information in model.
3.3.2 Performance Requirements
SRS017 Response Time
The system shall give responses in 1 second after checking the Person’s information.
SRS018 Capacity
The System must support 1000 people at a time.
SRS019 User-interface
The user-interface screen shall respond within 5 seconds.
SRS020 Conformity
The systems must conform to the Microsoft Accessibility guidelines
3.3.3 Maintainability
SRS021 Back Up
The system shall provide the capability to back-up the Data
SRS022 Errors
The system shall keep a log of all the errors.
3.3.4 Reliability
SRS023 Availability
The system shall be available all the time
4.CONCLUSION
This SRS document is used to give details regarding Society Residential Management System.
In this all the functional and non-functional requirements are specified inorder to get a clear cut
idea to develop a project.
