ONLINE COMPLIANT REGISTRATION AND

MANGEMENT SYSTEM

Software Requirement Specification

Version
Date
SHIVANSHU KR GUPTA
Lead Software Engineer

Prepared for
ONLINE COMPLIANT REGISTRATION AND

MANGEMENT SYSTEM

Revision History:
Date Description Author
Comments

Document Approval:
The following Software Requirements Specification has been accepted
and approved by the following:
Signature Printed Name Title Date

ONLINE COMPLAIENT REGSTRATION AND

 MANGEMENT SYSTEM

1. Introduction
This project is used to help the public in knowing their place details and getting their
problems solved online without going to the officer regularly until the problem is solved.
By this system the public can save his time and eradicate corruption in government
offices. Its main purpose is to provide a smart and easy way through web Application for
Complaint registration and its Tracking and eradicating Bribing system and thus to
prevent Corruption. We want to develop a web application for Complaint management.
To transform the existing manual compliant management system into an automate
system. For the better management of complaints to improve efficiency.

1.1 Purpose
It helps the public in knowing their place details and getting their problems
solved in online without going to the officer regularly until the problem is solved.
Its main purpose is to provide a smart and easy way through Android Application
with the location mark in Google Map for Complaint registration and its Tracking
and eradicating system and thus to prevent Corruption. We want to develop and
we application for complaint management system where public can register
complaints for streetlight, water pipe leakage, rain water drainage, road
reconstruction and garbage system. To transform the existing manual compliant
management system into an automate system.

1.2 Scope

1.3 Definitions, Acronyms, and Abbreviations

1.4 References
1.5 Overview

2. General Description
This software is divided in several module. In which the process of first module
(Registration module) is divided into two sub processes in which one registers the
complete details of the customer who wants to submit the compliant, other registers
the complete details of the compliant. In second module (Monitoring Module) is
dedicated to monitoring the complaints by searching the complaints and updating the
status of complaints at any time. In third module (Reports Module) is dedicated to
produce reports based on the information to given by the user. In last module
(Administration Module) is dedicated to administrating the users, divisions, categories,
sections, and Eros etc.

2.1 Product Perspective

The “Online Complaint Management System” software is an independent
application. Itis a self-contained product. The system interfaces, user interfaces
and hardware interfaces related with this software are defined as follows

2.2 Product Functions

 The major functions include.
 Providing product complaint details.
 Complaint registration for a particular product id, date and time and
providing with a pin code as a customer address.
 Allowing the customer to view status of the complaint.
 Displaying a report of the number of complaints for a particular product.

2.3 User Characteristics

 Register
 Post Complaint
 Location Mark in Google Map
 View complaint status
 Feedback
 Get Admin Contact details

2.4 General Constraints

 The process is order and more nebulous of the two, deals with understand
the problem, the goal, and constraints.
 The system would require disk space of 10GB and a 256 MB HDD and 64
MB RAM for client systems.

2.5 Assumptions and Dependencies

 We assume that the Office personnel do all the data entry based and the
correct values obtained from forms and registers.
  We assume that the computers that will use the software will be part of
the having proper platform to run it.
 Users with administrator access should be careful in deleting or modifying
any information knowingly or unknowingly with will lead to inconsistency
of the database.
 The end users of this software are assumed to have basic level of
computer knowledge i.e. point and click.

3. Specific Requirements
Software Requirement Specification (SRS) is the starting point of the software
developing activity. As system grew more complex it became evident that the goal of
the entire system cannot be easily comprehended. Hence the need for the requirement
phase arose. The software is initiated by the client needs. The SRS is the means of
translating the ideas of the minds of the clients (the i/p) into a formal document (the
o/p of the requirement phase).The SRS phase consists of two basic activities:

Problem or requirement analysis:

The process is order and more nebulous of the two, deals with understand the problem,
the goal, and constraints.

Requirement Specification:
Here, the focus is on specifying what has been found giving analysis such as
representation, specification languages and tools, and checking the specifications are
addressed during this activity. The requirement phase terminates with the production of
the validate SRS document. Producing the SRS document is the basic goal of this phase.
The Software Requirements Specification (SRS) begins the translation process that
converts the software requirements into the language the developers will use. The SRS
draws on the use-cases from the User Requirement Document (URD)and analyses the
situations from a few perspectives to discover and eliminate inconsistencies,
ambiguities, and omissions before development progresses significantly under mistaken
assumptions.

Role of SRS:
The Purpose of the software requirement specification is to reduce the communication
gap between the clients and developers. Software requirement specification is the
medium, through which the client and user needs are accurately specified. It forms the
basis of software development. A good SRS should satisfy all the parties involved in the
system.

3.1 External Interface Requirements

3.1.1 User Interfaces
The screen formats and menu structure should be in such a way that even
have users will find it easy to use. The product must be use-friendly and very
inter-active. The functionality provided by the system like displaying error
messages should adapt itself to the different users of the software.
3.1.2 Hardware Interfaces
 The system would require disk space of 10 GB and a 256 MB HDD and
64 MB RAM for client systems.
 Operating System: Any Windows OS. Client Software: Any Web
Browser (Internet Explorer). Communication Network: Internet.
3.1.3 Software Interfaces
The client systems should be able to share the data available in the data base
through the network connection.
3.1.4 Communications Interfaces
 Communications Interfaces are the interface that belongs to any
communications functions that are required and are used in our
software.
 Communication standards and Network server communications
protocols, electronic forms, Message formatting, Synchronization
mechanisms.

3.2 Functional Requirements

 Operating System: Any Windows OS. Client Program: Internet Explorer.
Server Program: Apache Tomcat 6.0. IDE: My Eclipse 8.6. Editors: Adobe
Dreamweaver, Photoshop. Language: JAVA (JSP JDBC) & HTML. Client-side
Scripting: Java script. Database software's: Oracle 10g. Intermediate
Language: JVM.
 Processor: P4 Ram: 512 MB Communication Channel: Internet Hard Disk:
10 GB Monitor: VGAColor (256)

3.3 Non-Functional Requirements

 Performance:
1. Response time of the Online Complaint Management System should be less
than 2second most of the time. Response time refers to the waiting time
while the system accesses, queries and retrieves the information from the
databases.
2. OCMS shall be able to handle at least 1000 transactions/inquiries per second.
3. OCMS shall show no visible deterioration in response time as the number of
users or flight schedule data increases.

Reliability:
1. OCMS shall be available 24 hours a day, 7 days a week.
2. OCMS shall always provide real time information about flight availability
information.
3. OCMS shall be robust enough to have a high degree of fault tolerance. For
example, if the user enters a negative number of passengers or a value too
large, the system should not crash and shall identify the invalid input and
produce a suitable error message.
4. OCMS shall be able to recover from hardware failures, power failures and
other natural catastrophes and rollback the databases to their most recent
valid state.

Usability:
1. OCMS shall provide a easy-to-use graphical interface similar to other existing
reservation system so that the users do not have to learn a new style of
interaction.
2. The web interface should be intuitive and easily navigable Users should be
able to understand the menu and options provided by OCMS.
3. Any notification or error messages generated by OCMS shall be clear,
succinct, polite, and free of jargon.

Integrity:
1. Only system administer has the right to change system parameters, such as
pricing policy etc. The system should be secure and must use encryption to
protect the databases.
2. Users need to be authenticated before having access to any personal data.
3.4 Inverse Requirements
3.5 Design Constraints
3.6 Logical Database Requirements
3.7 Other Requirements