Software Requirements Specification Version 1.

Pratyush Verma BE/1299/08

GSM BASED REMOTE MONITORING AND BILLING

SRS

TABLE OF CONTENTS TABLE OF CONTENTS...................................................................................ii TABLE OF FIGURES......................................................................................iv 1............................................................................................................................5 1.0. Purpose.........................................................................................................5

1.1. Introduction.....................................................................................................................5 1.2. Scope............................................................................................................................5 1.3. References.......................................................................................................................5 2..............................................................................................................................................6 1.4. Document overview........................................................................................................6

3............................................................................................................................7 2. Overall Description........................................................................................7

2.2. Functional requirements definitions................................................................................7 4..............................................................................................................................................8 2.3. Use cases.........................................................................................................................8 3.4. System Evolution18

4.0 Tools and platforms

4.1 Hardware Requirement..19 4.2 Software Requirement19

SRS

ii

SRS

TABLE OF FIGURES

Figure 7. Data Flow Diagram...13

iii

SRS 1

1.0. Purpose
1.1. Introduction With the ever-increasing popularity and accessibility of the Internet, it is only natural that the manual reading of the electricity meters installed throughout the country should be removed. By using the internet and web we can make this system a complete online system. For this we may need to understand the complete existing system so we may propose a complete online solution for the same. We can build a system in which the reading of the meter installed at comsumers site will be sent to the server automatically. The failure or inconvenience ,if any, at the consumers site would be detected and eradicated.

1.2. Scope Gsm based remote monitoring and billing replaces the process of reading the meters manually at the consumer site. This is beneficial because the meter can be monitored automatically by the system. If there is an error at the consumer side , it can be instantly detected and rectified. This system would even cut costs and improve transparency to a very large extent. Even frauds at the consumer side may be detected and managed. Moreover, no manpower would be needed to manage the home made meters.

1.3. References [IEEE] The applicable IEEE standards are published in IEEE Standards Collection, 2001 edition. The principal source of textbook material is Objective Oriented Modeling and Design by J.Rambaugh.

SRS 2 1.4. Document overview The remainder of this document is two chapters. The first providing a full description of the project for gsm based remote monitoring and billing. It lists all the functionas performed by the system. The final chapter concerns details of each of the systems functions and actions in full for the software developers assistance. These two sections are cross-referenced by topic; to increase understanding by both groups involved. This srs will provide a detailed description of the Gsm based remote monitoring and billing. This document will provide the outline of the requirements, overview of the characteristics and constraints of the system.

SRS 3

2. Overall Description
2.1 Product Perspective The gsm based remote monitoring and billing will provide a complete online facility for electricity billing. It will have a electricity board server in each state. The custom build gsm meters would update in real time through sms. The server will continuously monitor the meters at the consumer side. The profile of every type of consumers would be stored in the server. The server would also have account related information for each of the users. The users would have a login id and password. This would facilitate the users to login into the server and get his account details. The user may also report any problems online. The server would also provide a complete billing solution.

2.2. Functional requirements definitions i. Secure registration and profile management facilities for all the users in the system. ii. Instant updates on the server through SMS or compatible media. iii. Retrieval system on the GSM meter for up-to date billing amount. iv. Grievance handling and status reporting to the users. v. Backup and log facilities to control access of sensitive data. vi. Reliable GSM system handling and management. vii. A Complete billing system for the electricity board. viii. Billing system compatible with existing tariffs and monthly/bimonthly bill creation. ix. Consideration for peak hours and special timings in the billing system.

SRS 4 2.3. Use cases A use case is a technique for capturing the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use case diagrams depict: 1. Use cases: A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse. 2. Actors: An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures. 3. Associations: Associations between actors and use cases are indicated in use case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use case. Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line. The arrowhead is often used to indicate the direction of the initial invocation of the relationship or to indicate the primary actor within the use case. 4. System boundary boxes (optional): We can draw a rectangle around the use cases, called the system boundary box, to indicate the scope of the system. Anything within the box represents functionality that is in scope and anything outside the box is not. System boundary boxes are rarely used.

SRS The actors in the system are : consumers of the electricity ,electricity board administrator, and elecrtricity board officers. Activities performed by users : Registration

SRS

Activities performed are by consumers are: Registration Update Profile View Account Report Error

Activities performed by the administrator are: Failure Detection Bill Generation Fraud Detection Account Maintenance