Вы находитесь на странице: 1из 42

A PROJECT ON

TOLL COLLECTION SYSTEM

SUBMITTED BY :-

INFERNO
ARPIT BHARDWAJ (07770102810) NASHIT ALAM (07970102810) NITIKA KAUSHAL (08370102810)

ACKNOWLEDGEMENT

Wisdom must not get lost in knowledge and knowledge must not get lost in information. At Ansal Institute of Technology, we have been groomed to become a wisdom worker through special modules on self analysis, emotional intelligence, problem-solving and coping skills that have helped us in achieving personal and academic excellence. We would like to thank our teacher Ms Vaishali Arya for giving us an opportunity to work on this project under her able guidance and her insurmountable help and support. Without her valuable time and continuous help, this project would not have been possible.

INFERNO

ARPIT BHARDWAJ (07770102810) NASHIT ALAM (07970102810) NITIKA KAUSHAL (08370102810)

CONTENTS
S.No 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Contents Problem Statement Context Diagram Data Flow Diagram Level-1 Data Flow Diagram Level-2 Use Case Diagram ER Diagram SRS Data Dictionary Pseudo Code Screen Shots Date 11/1/12 18/1/12 25/1/12 1/2/12 8/2/12 15/2/12 29/2/12 14/3/12 21/3/12 28/3/12 Signatures

Problem Statement

Electronic toll collection systems are designed to assist in the management of toll operations through technology that aids in streamlining traffic movement and through collecting data that can be used to make operational changes. Metro's systems gather and analyze data on traffic volumes, vehicle classifications, vehicle speeds, and the fares expected and collected. Metro's database and report capabilities allow for better management of tolling operations, ensuring maximum revenues.

A software needs to be developed to automate the toll collection on a newly built highway. The following are the guidelines for developing the software/system :-

The toll charge will be based on the category of the vehicle - Rs10 for motorcycle/two-wheeler, Rs20 for light motor vehicle(LMV), Rs30 for heavy motor vehicle(HMV) and Rs40 for bus, category being manually decided by the collection officer. A boom barrier will open on receiving the money and a receipt will be provided. Regular users will get the option of smart cards or tags. Cards will have to be flashed against the card readers that will be placed at collection windows whereas sensors will read the tag, which the user will stick on the windscreen. The software should provide the programming of these smart cards and tags. A tag will be issued against a single car only and will store the number of the licence plate of that car. An optical character reader (OCR) will read the car's licence plate and cross check the number stored in the tag. In case of a mismatch, it will ask for the toll and will also levy a penalty equal to the amount of the toll. The recharge for smart cards will be available in the denominations of Rs100, 200, 300, 400 and 500. Tags will be of two types - flexi and standard. In the flexi tag, a validity of 6 months or 1 year will be provided depending on the amount of recharge. A recharge of Rs500 will fetch a 6-month validity and a recharge of Rs1000 will get a year's validity.

On the other hand, a standard tag would attract a 50% discount on the toll and will have a fixed monthly liability of Rs150 for motorcycle/two-wheeler, Rs300 for light motor vehicle(LMV), Rs450 for heavy motor vehicle(HMV) and Rs600 for bus which will include 60 trips valid for one month. Both the tags and the smart cards will be issued against a refundable security deposit of Rs1000 and Rs500 respectively, account of which should be made in the software. A sensor placed 500 metres before the collection window will start monitoring the time taken by a tag user to cross the toll gate. Once the user reaches the toll gate, another sensor will stop the time. If this time is more than 5 minutes, no toll will be charged and the vehicle will be allowed to pass free of cost. The software should be able to record live footage of the cars passing through and should also take still photographs of the cars' licence plates with the help of cameras. It should also maintain a database of cars passed in last one week by reading the licence plates through OCR's. The software should also be capable of displaying graphs showing peak and off peak hours of the day and busiest days of the week. Security provisions like the login authenticity should be provided with each collection officer having a unique id and password. The system should also be able to print the above mentioned graphs and records and should have the option of updating the toll rates, if required (to be changed by the administrator only). The administrator will have a concise statement of all the tolls that have been charged throughout the day, through all the gates The tag or the card will be blacklisted once the balance gets over, giving the user only one extra trip. A time counter is needed to check the number of hours the software is used on a certain lane, helping us to manage the traffic efficiently

Use-Case Diagram

LOGIN

SMART CARD & TAGS

Admin

On road coordinator

Off Road coordinator

BASIC OPERATIONS

REPORT GENERATION

UPDATE

Security coordinator

SURVELLIANCE

On Road

NETWORK
8

Use-Case Template

Name: Login
Actors: Administrator, Off-Road Coordinator, On-Road Coordinator, Security Head

Description:
The login deals with the admission of different type of users into the system depending upon the type of role they play in the administration of the system. The login is user specific, i.e., each user has a different ID assigned to him/her and has a password requirement on each login. These IDs distinguish between: 1. Administrator 2. Off-Road Coordinator (OffRC) 3. On-Road Coordinator (OnRC) 4. Security In charge As per the role that has been entered, the different user will have access to the different modules of the software

Preconditions:
The necessary preconditions are: 1. The user should be an employee in the Toll Management Office, as the logins are given to each and every employee. 2. The Login should have the password which is to be defined by the user at the time of creation of the account.

Post-Conditions:
The Users should have access to the various modules of the software depending upon the role that has been entered by them. The rights for accessing anything outside the prescribed modules will not be allowed

Flow of Events
The login ID and password is to be entered into the system, and the role depending upon the part the user plays in the software needs to be selected. If the password and User ID match with the selected role, then the user is given access to his/her department on the software

Alternate Flow of events


If the login ID and password dont match the Role or either other, then the user will not be given any access to the software , a screen printing Wrong User Name or Password will pop up , and after a delay for 5seconds , will reset the screen at the default User ID and Password screen.

Related Use Case Diagrams:


1. Smartcards and Tags 2. Basic Operations 3. Report Generation 4. Surveillance 5. Update 6. Networking

10

Name: Smartcards and Tags


Actors:
OffRC

Description:
This module of the software deals with the smartcards and tags. This module comes under the category of the section of the software that can be managed by the OffRC. The major dealings of this module are: 1. Issue 2. Return 3. Recharge /Update The cards and tags will be issued at the various prices that are offered and certain security charge. This module will also deal with the recharge of the smartcards and tags, on the predefined values, and also with updating of the smartcards, i.e., changing of the user, the license no. of the car, or changing the tag, in case of damage etc.

Pre-Conditions:
1.) The user should have the OffRC rights , i.e., ID and password to give access as the an Off-Road Coordinator 2.) Issue of new card involves the fulfillment of some of the basic requirement, like and ID proof the customer, and also the RC No. of the Vehicle it is using. 3.) Return of Card involves the refund of the security, after special deductions. 4.) Update will require the exchange of tag, or renewal of the license to use it.

Post-Conditions:
1.) This step issues the new cards or tags for the use by customers in the tag lane ( for tag) and cards ( for all lanes) 2.) The recharge is carried out on the basis of the various denominations given. 3.) The refund will involve full payment of the security , and the balance left is nullified , so no refund is to be given on that

Flow of Events
For the issue of the cards/tag, an ID proof of name and residence needs to be provided by the customer. Also a copy of the RC has to be given, for the registration of the vehicle. Then a card/tag is issued which as a RIFD sensor, which is programmed according to the Vehicle RC No. and also the users name and address. For the return of the card/tag, the card/tag is taken, and the security deposit is refunded, after deduction of any overheads. The left over balance is cancelled, and the account containing the ID on the tag/card and the RIFD codes are washed, for re-usage, in case of re-issuing. For the Recharge of card/tag, the specific denomination is being selected and then, the recharge is made to the specific tag/card For any updating /renewal / reissues the tag/card is taken and is changed depending upon the conditions and application.

11

Related Use Cases:


1.) 2.) 3.) 4.) Login (As OffRC) Update Report Generation Basic Operations

Name: Basic Operations


Actors:
OnRC

Description:
This module of the software deals with the On-Road functioning of the whole software. This involves the division of work on two bases: 1. Tag lane This includes the deduction of single entry thoroughfare, depending upon the type of vehicle going through the toll, i.e., whether a LMV, HMV, Two Wheeler or Bus. It also includes the Blacklisting of tags in case when the tag runs out of cash balance, and the balance goes into negative. This allows the customer to go through the toll this once more, after this the tag is blacklisted and the customer wont be allowed to go through, till a recharge is made, or a penalty is paid by them. 2. Cash Lane This involves a simple single thoroughfare on the basis of the vehicle going through, on cash basis, i.e., single entry is allowed on cash payment basis. An added feature is the return pass, which allows the customer to get a round through, which will allow him to cross back from the toll on the same day, i.e., 24-hours, on a discounted rate, thus encouraging the customer to take a return pass, in case he wants to travel back on the same day. A receipt will be printed with every cash payment defining the vehicle going through and the fare charged, and also whether its a single through or a return pass Also, this will handle the recharging on cards/tags, in case the balance is not available and the card/tag is blacklisted.

Pre-conditions:
1. The customer passing through, through the tag lane, should have a valid tag, which is not blacklisted, and is using it on the license no. is has been issued on, as in, the same car, for which it is issued. 2. The receipt of the return pass and the single entry will differ, so that its easier to recognize which is which. 3. For the recharging of tag/card, it should be blacklisted, and there is an added Rs.25/charge for every recharge which is done on the road, and not in the office. 12

Post Conditions:
1. A single through fare will only involve receiving of cash payment, and issuing of a receipt in favor of the payment made. 2. The return pass, will give an added discount over the normal charge, and a different color receipt will be printed, for easy recognition. 3. The tag , will simple deduce the amount of the thoroughfare , depending upon the vehicle , and will do so if the cards not blacklisted 4. If the card is blacklisted, it will issue a warning, for payment on the next entry, and a charge of 25/- will be charged for on the road recharge of card, or a fine of 10/- for a single pass. 5. Person without a tag, entering the tag lane will be charged an extra Rs.10/- over the actual fare, as the fine. Flow of Events: The customer, if he/she has a tag, can enter the tag lane and simply drive up to the boom barrier. If the sensor code of the initial scan, which has been set at 500m from the toll, matches her code, it will open, and the person can go through. If the person chooses to go through the cash lane, he has to simply get a single thought fare receipt, and pay the given amount, and he can go through the barrier.

Alternate Flow of Events


1. The tag code doesnt match both the sensor, so the person has to get the tag check, and has to pay the difference in the amounts. 2. If the person wants a return entry pass on the cash lane , he has to pay the nominally different charge , and can take the different colored slip and can pass through 3. If the Tag/Card is blacklisted , then the person entering the lane , can get it recharged at the lane station only, by the paying the amount , for which he wants the value for , plus an addition Rs.25/4. If the card is blacklisted and person doesnt want to get a recharged done at that time , then he has to pay for a single trip and also a penalty of Rs.10/-

Related Use Cases:


1. Login ( as an OnRC) 2. Update 3. Report Generation

Name: Report Generation


Actors:
Administrator

13

Description:
The module, deals with generating of reports after a certain period of time. The reports that will be generated will give a brief and concise account of all the toll earnings throughout the day, whether cash payment or tag/card transfers. This also deals with keeping an account of the traffic that pass through , measuring the heavy hours and the lighter hours of the day , of the traffic . It also enables, the better understanding of the lane usage, providing us the ability to manage the lanes, and see when to open how many, so as to make a lane-traffic balance. The reports can be generated in the form of graphs, or otherwise printed to keep a hard copy record of it.

Pre-Conditions:
1. There should be a certain time period for which the reports need to be generated, whether a day, a week or a month. 2. The type reports generated must have the specific data.

Post-Conditions:
1. The reports can be generated on a softcopy and a hard copy basis. 2. An account of the road traffic , and the lane usage will be provided

Flow of Events:
A specific choice is entered, and the administrator can draw out the reports as he wants it, i.e., either a hard copy, or a soft copy

Related Use Case:


1. Login 2. Smart Cards 3. Basic Operations

Name: Update
Actors:
Administrator

Description:
The UPDATE, deals with the updating of the system. This involves: 1. Change of fares 2. Accounting standards 3. Change of Role 4. Login Management 5. Change the Report Generation standards (like the graph format could be changed on requirement) 6. Networking changes This also deals with changes in the live feed status. 14

Preconditions:
1. The user must have administrator rights to access this section of the software 2. The specific changes have to be sanctioned by the management before they are made on the system 3. A backup needs to be taken before the system is updated, so as to recover in case of system failure.

Post Conditions:
1. The Update changes will be issued on the next reset of counters on the system 2. The Role changing will enable the transfer of 1 OffRC to OnRC etc. 3. New logins will be issued for the new logins for recruits , and also the closing of the accounts for the coordinators who quit the job 4. This updating also provides wad the facility of resetting the password for a user, incase he/she forgets the password.

Flow of Events
The administrator has to login in using his unique ID and password and then can manipulate the system, as the changes are required. He can change the Role of the employees and even manage the change of fares. Also login management and Accounting standards are his job, so any changes will have to be made by him only. The networking changes and the Report generation changes will also be managed by him only.

Related Use Cases:


1. 2. 3. 4. 5. 6. Login Smart Tags and Cards Basic Operations Networking Report Generations Surveillance

Name: Surveillance
Actors:
Security Head

Description:
The surveillance deals with the live feed on each and every lane, so that a record of each and every car passing through will be stored on the system. This allows us to keep an extra check on the traffic movement, and also the security. The OCR will scan the image of the number plate, and store the license no. on the data base. The image will then be deleted, and the number will be saved for future references, and surveillance.

Preconditions:
1. The User must have a security login and password to get access to the security section

15

2. The live feeds will save all the numbers on a database , that will be maintained for a month , so as to keep a check on the movement of vehicles if needed

Post Conditions:
1. This will give a record of every vehicle that pass through the toll , as it is the border , so will keep an extra check on the movement of vehicles in and out of the Capital 2. The Security Head will also be able to keep a live check on all the vehicles moving in or out of the city, with the help of the Live-feed cameras installed in each and every lane

Flow of Events:
The OCR will scan the image of the number plate, and store the license no. on the data base. The image will then be deleted, and the number will be saved for future references, and surveillance.

Alternate flow of events:


Of the vehicles without a tag or card, the live feed will only work, because of the lack for further information regarding that specific vehicle.

Related Use Cases:


1. Login 2. Update

Name: Networking
Actors:
Administrator

Description:
This deals with the management of the whole software; this is less of a module, and more of an access to each and every department, and the interconnectivities, which will enable us to manage the system better. This also deals with the servicing, and management of the lanes on the servers

Preconditions:
1. 2. 3. 4. A login ID and password for an Administrator access is needed. The lanes are interconnected to each other and also to the main server The Office systems are also a part of this network only and are on the server only. The lane system is not working properly

PostConditions:
1. The Network is fixed and its working properly now. 2. The network services and checking for faults and loose connections is done

Related Use Cases:


1. Login 2. Updating 16

Context Diagram

17

18

Entity Relationship Diagram

19

Entity Relationship Diagram


OFF ROAD COORDINATO R
Emp_id Console_id manages

USER
name address

BUY S

TAG
validity licence plate no

balance recharges Amount collected

RFID no

TOLL
category amount

charges

ON ROAD COORDINATO R
Emp_id Console_id Amount collected

updates

ADMIN
Emp_id

generates

REPORT
Rep_no graphs attendance

amount Tags/cards issued/ returned

manages

CAMERA

manages

SECURITY HEAD
Emp_id

Cam_no

20
Feed_no

Software Requirement Specification

21

1. INTRODUCTION
This document aims at defining the overall software requirements for " Toll collection system. Efforts have been made to define the requirements exhaustively and accurately. The final product will be having only features and functionalities mentioned in this document and assumptions for any additional functionality/feature should not be made by any of the parties involved in developing/testing/implementing/using this product. In case it is required to have some additional features, a formal change request will need to be raised and subsequently a new release of this document and/or product will be produced.

1.1PURPOSE
This specification document describes the capabilities that will be provided by the software application "TOLL COLLECTION SYSTEM. It also states various required constraints by which the system will abide. The intended audience for this document is the development team, testing team, and the end users of the product. This will also give an account for the systems behavior in terms of, input data, required processing, output data, operational scenarios and interfaces.

1.2 SCOPE
Software is needed to be developed to automate the toll collection on a newly built highway. The system gathers and analyzes data on traffic volumes, vehicle classification and the fares expected and collected. The data generated by the help of the system allow for the better management of the tolling operation. This software should also provide with the necessary live-feed for the security purpose of the state.

1.3 Definitions, acronyms and abbreviations


The major terms used through the software are as: 1. On-Road Coordinators- The personnel related to the on-road functioning for the system 2. Off-Road Coordinators- The personnel related to the off-road dealings of the system, which involves Tag / Smart card manipulations etc. 3. Tag/Smart Cards - These are cards being used by the customers for easy and viable thoroughfare. 4. Administrator The personnel who supervises the whole software and has the rights to make changes according to requirements. Following are the major abbreviations have been used throughout the document: 1. Admin: Administrator 2. OnRC: On road coordinator 22

3. OffRC: Off road coordinator

1.4References
1. IEEE Recommended practice for software requirements specifications-IEEE Std 8301993. 2. http://www.mtibugs.com/Howsrs.php for added help and simplification.

1.5 Overview
The SRS document hence for deals with what the customer wants in the software, and the various other requirements of the system, which are needed, so as to make the projected software fully functional and successful. The various requirements have been broken down into the hardware and software requirements that will be required and how they will interact with each other.

2.Overall Description.
The "Toll Collection System" will have capability to maintain information about the registration number of cars to which tag is issued, the type of tag, validity of the tag and smart card, Amount value left in the tag, maintain a database of cars passed in last one week. The software will be capable of programming of smart cards & tags and various security provisions like login authenticity. It will also provide the capability of a single-thoroughfare depending upon the type of vehicle. The software will generate and print summary reports regarding peak and off-peak hours of the day and will also maintain the list of blacklisted users.

2.1 Product Perspective


This application will be a window based, self-contained and independent software product. But at the total system level, it will be a part of the whole set of software relating to the management of the toll, which will include, the accounting software, programs related to cameras and livefeeds, programming of RFID and also the OCRs.

2.1.1 System Interfaces None 2.1.2 User interfaces The application will have user friendly and menu based interface. Following screens will be provided. 23

1. A login screen for entering the username, password and role (Admin, OnRC, OffRC, Security head) will be provided. Access to different screens will be based upon the role of the user.

2. There will be a screen for capturing and displaying information regarding the total no of smart cards and types of tags issued till date in addition to their users information i.e. the date of issue, type of vehicle, License no of the vehicle, validity of the tag & smart card and blacklisted users etc) 3. There will be a screen for capturing and displaying information regarding which all user accounts exist in the system, thus showing who all can access the system. 4. There will be a screen for displaying information regarding various new offers and plans for the new and the existing users. 5. There will be a screen showing the total no of vehicles passed through different lanes at different hours of the day. It will also show the total money collection at different lanes. 6. There will be a screen showing toll charges in accordance to the type of the vehicle, which are broadly categorized into two wheelers, LMV & HMV. The screen will also have the recharge option of the smart cards & Tags. 7. There will be a screen, which will display the information (photographs and footages) about the vehicles, which passed the tollgates in last one week. 8. There will be a screen for displaying and printing graphs, records and the toll receipts. 9. There will be a screen that will show the time taken by the vehicle to pass through the tollgates as it comes within 500mtrs range of the tollgates. The following reports will be generated: 1. Traffic Density graphs: - Printable graphs will be generated to show the peak and Offpeak hours. 2. Revenue detail: - a report will be generated which will contain information about the total revenue through different toll lanes that particular day. 3. New users: - For each day their will be a printable report showing the total no of new users and information about the issued Tags and smart cards. 4. Blacklisted users: - There will be a printable list of blacklisted users.

24

2.1.3 Hardware Interfaces (i) Screen resolution of at least 800x600- required for proper and complete viewing of screens. Higher resolutions will not be a problem. (ii) Support for printer (dot-matrix/DeskJet/inkjet -any will do)-that is, appropriate drivers are installed and connected printer will be required for printing of reports and receipts. (iii) Standalone system or network not a concern, as it will be possible to run the applications on any of these. 2.1.4 Software Interfaces 1. Any window-based operating system (windows 95/98/2000/XP/NT). 2. MS Access 2000 as the DBMS-for database. Future release of the application will aim at upgrading to oracle 8i as the DBMS. 3. Crystal reports 8-for generating and viewing reports. 4. Visual basic 6- for coding/developing the software. Software mentioned in pts 3 and 4 above, will be required only for development of the application. The final application will be packaged as an independent setup program that will be delivered to the client. 2.1.5 Communications Interfaces 1. The management of the software as well as the functioning will totally depend on the type of routing that is done. 2. Also the IP addresses and the computer MAC addresses will be defined so as to further enhance the system management, and also the data accessibility by the administrator 3. The server is also routed and interconnected to all parts of the system, which will enable the transfer and storage of data. Also it will provide appropriate space to say the live feeds and other databases 2.1.6Memory Constraints 1. At least 1GB RAM and 2GB space on hard disk will be required for running the application. 2. The server requirement is minimum of 10TB, for storage and accessibility 2.1.7 Operations This product will cover any automated housekeeping aspects of the database. The Administrator at the client site will be responsible for manually deleting old/non-required data; otherwise the system will automatically deleted the data depending upon the time that is to be predefined by the administrator. Database backup and recovery will also have to be handled by the Administrator. However, the system will provide a 'RESET SYSTEM' function that will delete (upon confirmation from the administrator) all the existing information from the database.

25

2.1.8 Site adaptation Requirements The terminal at client site has to support the hardware and software interfaces specified in above sections.

2.2 Product Functions


The system will allow access only to authorized users with specific roles (Admin, OffRc, OnRC and Security head). Depending Upon the users role, he/she will be able to access only the specific modules of the system. 1. A summary of the major functions that the software will perform: 2. A login facility for enabling only authorized access to the system 3. User with role OnRC will be able to generate printable tax receipts to be given to the customer. 4. User with role OnRC will be able to manage the blacklist of the tags and cards 5. User with role security head will be able to access all the data regarding Security Surveillance .User with role OffRc will be able to Issue/ Return the tag/smart cards. 6. User with role OffRc will be able to Recharge Tag/Smart cards. 7. Users with role OffRc will be authorized to create/modify/ delete new/existing customers information. 8. User with role Admin will be able to generate printable reports. 9. User with role Admin will be able to Reset the system leading to deletion of all the existing information from the backend database. 10. User with role Admin will be able to create/modify/delete new/existing user accounts. 11. User with role Admin will be able and authorized to revise/look after software and networking requirements.

2.3 User Characteristics


1. Education level: - Understanding of English language, with a formal degree, at least, standard 12th or equivalent degree. 2. Technical expertise: -Should be comfortable using general-purpose applications on a computer. 3. Management requirements: - The administrator should be very familiar with the networking and interconnectivities, and also with the server management, i.e., MS Access, which is being used by our system to maintain data. 26

2.4 Constraints
1. Since the DBMS is being used in MS Access, it will not be able to store a very huge number of records; therefore a cleanup is required, after a certain time duration being set by the administrator. 2. Due to limited features of DBMS being used performance tuning feature will not be applied to the queries and thus the system may become slow with the increase in number of records. 3. Due to limited features of DBMS being used, database auditing will also not be provided.

2.5 Assumptions and Dependencies


1. Administrator has information about the technicality of the computer and server systems

2.6 Apportioning of Requirements


Not Required

3. Specific Requirements
This section contains the software requirements to a level of detail sufficient to enable designers to design the system and testers to test that system.

3.1 User Interfaces


In our specific software we are planning to add the date and time feature to each and every screen. Also along with this we will provide a message communication facility that will enable all the users to send messages over the LAN. A logout option is also given on every account, which will revert us back to the main login screen. The following screens will be provided.

27

1. Login Screen
This will be the first screen that will be displayed .It will allow users to access different screens based upon the user's role. Various fields available on this screen will be:

1. User ID: Alphanumeric of length unto 10 characters.


2. Password: Alphanumeric of length unto 8 characters. 3. Role: Will have the following values: Admin, OnRC, OffRC and Security head.

2. Administrators Menu This screen is accessible only with an appropriate administrator login ID, and will enable us to deal with all sections of the software and system.
The various options given to us are: 1. Security: Enabling us to enter as the security head and access live feeds and other security records etc. 2. Account management: Allowing us to manage the various user accounts on the network. This involves opening and closing of accounts for the user and other management facilities like changing or resetting of password etc. 3. Network Administration: Provides the option of checking whats going on in the system and how everything is function over. Also enables to repair and make changes if needed 4. Report Generation/Analysis: This option on the administrators screen, allows us to interact with the system and get reports on various items like traffic, funds, earnings etc. The administrator can use this option to generation the reports of the various options over a period of time, and also allow analyzing them and printing them so that it can be produced later.

3.Security Head Menu


This screen deals with the security section of the software, which enables a person to login as the security personnel, who works on the live feeds and other records. The various options available on the Security Head Screen are: 1. View Live Feeds: This allows us to view the cameras that have been put up on the various parts of the whole area of the functioning, i.e., around the toll area region, and enable us the keep a live account of how things are working. 2. View Recorded Feeds: This allows us to view the live feeds that have been recorded in the past. The time period for the viewing can be given which will allow us to watch the live feed for that duration 3. Delete Records: Allows us to delete records manual, or enables us to put a date on which the records will be deleted automatically 28

4. Submit Reports: Allows the user to submit the final reports on the live feeds to the administrator which can be accessed by him and help him to generate reports

4. on-Road Coordinator Menu This screen of this login time, by simply pressing a button. The OnRC also has the access to give recharges to the customers, of various plans. The features available are: 1. Vehicle Category: Drop down selection of the choice of vehicle 2. Cash Tendered: Automatic generation of the amount depending on the vehicle category we have chosen 3. Balance: Automatically generate as per the cash can only be accessed if we login into the system through the OnRc account. The OnRC will deal with the on road functioning of the program, which involves taking of fare and printing of receipt of money. The OnRC can even submit the summary received. 5. Off-Road Coordinator Menu This screen deals with the Off-RC and the various functions that he needs to perform. The access to this is only granted after a valid login as the Off-RC. The various options available on the screen are: 1. Recharge Tag/Card: Enables the user to recharge the tag/cards on the given schemes and accounts. 2. Issue of Tag/Card: Enables the user to issue new tag/card after fulfillment of all the formalities. 3. Return of Tag/Card: Involves the returning of tag/card and accepting it back, and redeeming of the security, if not used, or the card/tag havent been damaged. 4. Update: This involves: 1. User information change 2. Plan change 3. Incase of loss or damage, issue of an alternate tag 5. Enquiry: This involves keeping an account of the various aspects, and having information about and answering various queries of the customers.

29

6. Tag Card Issue menu:This screen deals with the issuing of new tag cards to the users. The admin and the Off-RC can access it. The various options available on the screen are: 1. Tag Id: The Tag Id being issued is automatically scanned. 2. 3. 4. Name: Alphabets of length upto10 Characters. Address: Alphanumeric length up to 40 characters. Vehicle Reg No: Alphanumeric up to 15 characters.

7.Tag Card recharge menu: This screen deals with the recharging of tag or smart card. The admin and the Off-RC can access it. The various options available on the screen are: 1. Tag Id: The Tag Id being recharged is automatically scanned. 2. 3. 4. 5. Recharge Amount: Drop down selection of the choice of amount. Special Recharges: Drop down selection of the choice of type recharge. Amount Received: Numeric value is entered.( The amount given by the customer) Balance: Numeric value. Automatically generated as per the cash received.

8.Tag Card return menu: This screen specifically deals with returning of the tag cards and smart cards. The admin and the Off-RC can access it. The various options available on the screen are: 1. Tag Id: The Tag Id being returned is automatically scanned. 2. Vehicle Reg No: The Vehicle registration no of the Tag being returned is automatically scanned. Security Refund: Displays the numeric value of the amount to be returned to the customer if any. User Information: Alphabetical and alpha numeric.( Contains all the information of the customer such as Name, address, type of Id etc submitted at the time of issuing of tag card.)

3.

4.

30

9.Information Edit Menu: The screen deals with any changes or editing in the user info i.e. The customer information provided at the time of issuing of tag. The admin and the Off-RC can access it. The various options available on the screen are: 1. Tag Id: Alphanumeric value up to 10 char. 2. Name: Alphabets of length upto10 Characters. 3. Address: Alphanumeric length up to 40 characters. 4. Vehicle Reg No: Alphanumeric up to 15 characters. 5. Account Type: This tells us about the type of tag being opted by the customer.(Flexi or Standard).

10. Message menu: The screen can be used to send messages across different consoles in the network.The various options available on the screen are: 1. Console Id: Drop down selection. 2. Messages: Mixed up to 1000 characters. (Alphabetical, alphanumeric, digits and numeric) 11. Network Menu: The screen gives information about the various consoles on network i.e. which of them are running or down. The various options available on the screen are: 1. Console Id: Drop down selection. 12. Network Edit Menu: The screen is used to edit the network parameters of the various consoles connected on the network. The various options available on the screen are 1. Console Id: Drop down selection. 2. 3. IP Address: Numeric values up to 12 characters. Gateway: Numeric values up to 12 characters.

Subnet Mask: Numeric values up to 12 characters. 3.1.2 Hardware Interfaces 1. Screen resolution of at least 800x600- required for proper and complete viewing of screens. Higher resolutions will not be a problem. 2. Support for printer (dot-matrix/DeskJet/inkjet -any will do)-that is, appropriate drivers are installed and connected printer will be required for printing of reports and receipts. 31

3. Standalone system or network not a concern, as it will be possible to run the applications on any of these. 3.1.3 Software Interfaces 1. Any window-based operating system (windows 95/98/2000/XP/NT). 2. MS Access 2000 as the DBMS-for database. Future release of the application will aim at upgrading to oracle 8i as the DBMS. 3. Crystal reports 8-for generating and viewing reports. 4. Visual basic 6- for coding/developing the software. 3.1.4 Communication Interfaces None

3.2 System Features


3.2.1 On-Road operations Description: The system will perform the task of collecting the toll, maintaining the database of blacklisted users. Thus, preventing people from evading toll tax. It will automatically flash the amount expected as soon as the type of vehicle is entered. It will also flash the balance amount to be returned as soon as the amount received is fed into the system. The system will also mention the date and time of the trip while printing the receipts.

Validity checks
1. Only the OnRC and the Admin are authorized to access the on road application system. 2. Category of the vehicle cannot be left blank, and the type of vehicle can be selected by clicking a hot key. 3. Amount received cannot be left blank. 4. Vehicles will not be allowed to pass with expired tags (only one trip allowed). 5. Date and time of the trip. 6. A receipt has to be issued every time the respective toll is received.

Error handling/response to abnormal situations


If any of the above validation does not hold true, appropriate error messages will be prompted to the user for doing the needful. 3.2.2 Off-Road operations Description: The system will maintain information about all the tags/smart-cards issued or returned till date. It will maintain a proper database of the vehicles to which tag/smart card have been issued, which will include vehicle type, registration no, type of Id proof submitted, date & 32

time of issue, Id of the smart-card/tag being issued. It will also maintain a proper database of the amount left in user tags/smart-card, their validity & schemes. The system will also undertake the recharging and updating of tags/smart-cards.

Validity checks
1. Only the Off-RC and the Admin are authorized to access the Off Road operations system. 2. While issuing of Tag following cannot be left blank 1. Name of the vehicle Owner 2. Address for Vehicle Owner 3. Vehicle type 4. Registration number 5. Type of Id proof. 6. Type of tag /smart card issued. With full information about the validities and schemes. 7. Date and time off issue cannot be left blank. 8. Every tag will be issued unique Id.

Error handling/response to abnormal situations


If any of the above validation does not hold true, appropriate error messages will be prompted to the user for doing the needful. 3.2.3 Security operations Description: For security considerations the system will maintain a proper database of the vehicles, which have passed the tollgates. It will maintain a proper record of the vehicles with their type, registration no, Tag/Smart-card Id, date and time of the trip and live footages and photographs with the help of the cameras. Due to the memory limitations the database needs a cleanup after some time so as to feed in new data.

Validity checks
1. Only the security Head and the Admin is authorized to access the database. 2. Vehicle type cannot be left blank. 3. Registration number cannot be left blank. 4. Date and time of the trip is to be mentioned.

33

Error handling/response to abnormal situations


If any of the above validation does not hold true, appropriate error messages will be prompted to the user for doing the needful. 3.2.4 Network Administration Description: - It will take care of the overall networking and the hardware requirements of the system for its proper and efficient working. The system will generate new login Ids & passwords for new employees. It will allow the Admin to revise or reset various system requirements such as passwords, interconnectivity, transfer of data & accessibility options. The network will allow the various personnel to interact with each other allowing them to send messages in case needed.

Validity checks
1. Only the user with the role Admin will be authorized to access the system. 2. IP address must be entered to access the system. 3. Hardware related updating would be done only after Admin approval. 4. Data has to be sent to the main server. 5. Proper camera connections are to be assured for the working of the system. 6. New login Ids will be issued. 7. Password resetting after regular time interval to prevent misuse. 8. Regular connectivity and wire checks for proper functioning of the system. 9. User can log in only on one machine in the network with his/her login id at a particular time. 10. The messaging will require mentioning the username and consoling no. And also whom to send.

Error handling/response to abnormal situations


If any of the above validation does not hold true, appropriate error messages will be prompted to the user for doing the needful 3.2.6 Report Generation

34

Description:
For each day a report will be generated containing the list of coordinators present that day, graphs depicting on & off traffic peak hours, total amount collected, total no of vehicles passed along with their vehicle type. It will also contain information about the Tag / Smart card issued or returned that day. 3.2.7 User account information

Description:
The system will maintain information about various users who will be able to access the system. The following informationwould be maintained: User name, User ID, Password and Role.

Validity Checks
1. Only user with role Admin will be authorized to access the user accounts module, and manipulate it. 2. User ID cannot be left blank. 3. User ID should be unique for every user. 4. Password cannot be left blank. 5. Role cannot be left blank. information

Error handling/response to abnormal situations


If any of the above validation does not hold true, appropriate error messages will be prompted to the user for doing the needful.

3.3 Performance Requirements


None

3.4 Design Constraints


None

35

3.5 Software System Attributes


3.5.1Security The application will be password protected. Users will have to enter correct username, password and role to access the application. 3.5.2Maintainability The application will be designed in a maintainable manner. It will be easy incorporate new requirements in the individual modules (user account info, report generation, toll charges and schemes etc.). 3.5.3Portability The application will be portable on any window-based system (windows 95/98/2000/XP/NT) that has MS Access 2000 installed.

3.6Logical Database Requirements


The following information will be stored in a database 1. TAG info: Type of tag being issued, date of issue, registration no of the vehicle using tags, type of vehicle & total no of tags in use. 2. Smart cards: Total no of smart cards issued, registration no and the type of vehicle. 3. Blacklisted Users: - Registration no and type of vehicle. 4. User account info: - User name, User ID, Password & Role. 5. Livefeeds: Recordings of the cars passing through all the 8 tollgates in a day. 6. Toll Info: Category and amount.

36

Test Cases

37

Login Screen

Inputs

Alpha

AlphaNumeric

Digits

Special characters

Mixed Input

Expected Output

Abhishek Abhi1loaded

Valid Valid 92313813 ?:// Ab|as Valid Invalid Valid

Login

Password Electer1

Valid Valid 11253345 ?:Ele?1r Valid Invalid Valid

Password

Login Screen

Inputs

Alpha

AlphaNumeric

Digits

Special characters

Mixed Input

Expected Output

Abhishek

Invalid Abhi1loaded 300 10,001 ?:// Ab|as Invalid Valid Invalid Invalid Invalid

Cash

Tendered
(upto 9999)

38

Login Screen

Inputs

Alpha

AlphaNumeric

Digits

Special characters

Mixed Input

Expected Output

Abhishek

Invalid Abhi1loaded 300 10,001 ?:// Ab|as Invalid Valid Invalid Invalid Invalid

Amount Received (upto 9999)

Login Screen
Inputs Alpha AlphaNumeric Digits Special characters Mixed Input Expected Output

Abhishek Abhi1loaded

Valid Invalid 92313813 ?:// Ab|as Invalid Invalid Invalid Invalid Electer1 Valid

Name

Password

Address

11253345
?:C-4/54 ABC Password

Invalid
Invalid Valid Invalid

Vehicle Reg. No.

Electer1 11253345 ?:Ele?1r

Valid Invalid Invalid Invalid

39

Login Screen

Inputs

Alpha

Alpha-Numeric

Digits

Special characters

Mixed Input

Expected Output

Abhishek
Abhi1loaded

Valid
Invalid 92313813 ?:// Ab|as Invalid Invalid Valid

User Information

Login Screen
Inputs Alpha AlphaNumeric Digits Special characters Mixed Input Expected Output

Abhishek Abhi1loaded

Valid Invalid 92313813 ?:// Ab|as Invalid Invalid Invalid Invalid Electer1 Invalid 11253345 ?:Ele?1r Invalid Invalid Valid Invalid Electer1 11253345 ?:Ele?1r Valid Invalid Invalid Invalid

Name

Password

Address

Password

Vehicle Reg. No.

40

REFERENCES

http://en.wikipedia.org SOFTWARE ENGINEERING (THIRD EDITION) by K.K.Aggarwal and Yogesh

Singh SRS EXAMPLE

www.cse.msu.edu/~chengb/RE-491/Papers/SRSExample-webapp.doc SOFTWARE ENGINEERING RESOURCES

http://www.rspa.com/spi/

41

FUTURE SCOPE

In the times to come, more and more projects like this will be taken up by the government in association with private construction companies on the same concept of build operate and transfer. Highways with access control are becoming popular world over because it helps in better manageability of the traffic thereby making it easy to commuter by road. With the help of such software, the overall functionality reduces to only a few clicks with minimal human intervention. The project that was undertaken by our group involved careful utilization of computer resources to control traffic movement and density. Ever increasing traffic volumes demand for new ways to regulate it. Our software enables the use of latest technology to collect toll , manipulate the traffic volumes , and also to analyze the traffic conditions and the various steps that need to be taken in case to avoid it from going out of hand. Also in view of increasing crimes in the country, surveillance is an important feature which is becoming a must these days. In future, the whole process can be automated which will work without any man power. This will greatly reduce the cost incurred by the construction company in managing the whole system.

42

Вам также может понравиться