You are on page 1of 7

This is a SRS document for Society Audit System.

The Society Audit System


project is a completely functional system that will assist all IT or computer-
related courses in developing it. The Society Audit System simply works by
storing information of all the persons within the community. This system is
working so well that anyone can understand this kind of project.

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 Function
2.3 User Characteristics
2.4 General Constraints
2.5 Assumption and Dependencies

3. SPECIFIC REQUIREMENTS
3.1 Functional Requirements
3.2 Design Constraints
3.3 Non-Functional Requirements
3.3.1 Security
3.3.2 Performance Requirements
3.3.3 Maintainability
3.3.4 Reliability

4. CONCLUSION

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. General Description
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:

1) User then will be able to e-book the documents/plot after login effectively.

2) User will be to transfer the report/plot of the 1st owner to second owner.
System shall have entire record of each Customer.

3) User will be able to view all the generated bills of the residential people.

4)All information of Users Data like Housing Size, Maintenance bill, Electricity
bills, etc will be displayed on software interface.

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 includes 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 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 an 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 theward 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 in order to get a clear cut idea to develop a project.

You might also like