Software Design Specification - Advanced Software Engineering | CS 430, Study Guides, Projects, Research of Software Engineering

Download Software Design Specification - Advanced Software Engineering | CS 430 and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity!

Software Design Specification

RFID Parking Garage

Matt Nichols

Tony Nichols

Contact E-Mail: [email protected]

March 11, 2008

1.0 Introduction Finding parking spaces for automobiles and motorcycles can be a problematic venture due to limited space and time, while the selling of parking spaces is potential lucrative endeavor. Currently, most large parking garages, including airport parking, use a ticketing system in which users get a time-stamped ticket when entering the structure and pay a time-relative fee when exiting. The transmission of these disposable tickets is a time inefficient process, susceptible to error. These tickets can easily be lost; and with the lost tickets, the entire process becomes disoriented. The manual payment process can also be time consuming when traffic is at a high rate. An RFID (radio-frequency identification) parking system would improve this by allowing the user to interact with the parking area with an RFID card at the entrance and exit of the parking area. An RFID parking system would also allow the user to keep an account on which the system would keep track of financial transactions. This would reduce the amount of time the user must interact with the system and increase the security of the user. As an added security feature, an electronic keypad will be placed at the entrance of the parking garage. Once the user has swiped their RFID card they will enter their pin number. The pin number and the unique ID on each RFID card will be used to validate the user. 1.1 Goals and objectives  To provide individuals who require a parking area a system that is efficient and easy to use.  To provide individuals with a system that accounts for the length of each visit and provide them an account that will be used to pay for the visit.  To determine the adaptability of an RFID parking system in different situations

 To determine the feasibility and cost effectiveness of an RFID parking system that provides efficiency and ease of use.  Improve security over conventional RFID parking systems by adding a keypad for user authentication. 1.2 Statement of scope The user will be provided an RFID card and an online account which they will use to gain access to the parking area and pay for each visit. When the user is ready to enter the parking area, they will place the card within a close proximity to the RFID reader. The proximity will vary depending on the model of the RFID implementation. A unique ID is transmitted from the card to the reader. The reader then transmits the unique ID to the database. In addition to scanning their card, the user will also enter his pin number into the keypad. The system will validate the user and record the time of entry. A signal is then sent to the entrance by the system to allow the user to enter the parking garage. Upon leaving, the user will repeat the same process that he used to entering the garage. The system will record that the user is exiting the parking area and record the time of exiting. The user is then charged the appropriate amount for the visit and the amount is made visible on his account. The user can then login to his account and make a payment on his balance. 1.3 Software context In order to resolve the issue, we must change both the way that customers access the parking garage and how money is transferred between the building owner and the customer. A simple and accessible technology like Radio Frequency Identification (RFID) cards and readers could be employed in order to streamline the entry and exit process. The cards would be tied to customer accounts, to which money could be transferred using a web interface. This new process would grant users virtual immediate entry and exit from the parking structure because the

 The system should not interfere with the operation of the personal computer to which it is attached.  The system must comply with Part 15, entitled "Radio Frequency Devices" of Title 47 of the Code of Federal Regulations.  The system keypad should be ergonomic in design so that the occurrence of repetitive stress injuries is minimized.  The system must not expose the user to electrical shock.

2.0 Data design 2.1 Temporary data structure A temporary file is created when a user scans their RFID card at the garage will contain a hash of their RFID reference number, name, and password. A separate program will scan the database for the same information and verify the information. Once the information is verified the users are granted access into the garage. 2.2 Database description The database will store an account holder’s information. This information consists of their name, address, phone number, e-mail address, balance, account status, password, pin number, and RFID reference number. Most of this information can be updated at any time while on the user is logged in on the garage website.

parts of the architecture would be the user acting as the client, the broker acting as the RFID scanner, and the supplier as the parking garage. But this architecture would only fit for the parking garage aspect of the project and not encompass the website for the parking garage system. The user of the system would have direct access to the website and not have to go through a mediator for information regarding the parking garage systems because the information is provided from the database. 3.2 Description for Component Keypad Digit Entry 3.2.1 Processing narrative for component Keypad Digit Entry The keypad digit entry is done upon arrival at the parking garage gate following the RFID card scan. The digit entry is an added layer of security for access into the parking garage where the user will enter their 3-5 digit password. The information they enter is stored in a temporary file which is then compared to the database information. If the information is correct then the user is granted access into the parking garage. Otherwise they are denied access. 3.2.2 Component Keypad Digit Entry interface description. The input interface is the keypad device found at the entry gate of the garage. The user will enter their password and it is processed by the database for authorization. The output will come from the parking garage light which is represented by a green for access and red for denial. 3.2.3 Component Keypad Digit Entry processing detail 3.2.3.1 Interface description The interface will consist of the numbers 0 through 9 found on any keypad entry device.

3.2.3.2 Algorithmic model (e.g., PDL) Password Entry Grant Access to garage Correct Incorrect 3.2.3.3 Restrictions/limitations  The password is limited to a 3-5 digit password. This can be changed pending if the parking garage administrator wants a longer entry.  Access to the garage if the information is correct.  Denial to the garage if the information is incorrect. 3.2.3.4 Local data structures No data structure is needed for this device. 3.2.3.5 Performance issues  The database should provide the user with access/denial to the garage in a reasonable amount of time, no more then 5-10 seconds.

3.3.3.2 Algorithmic model (e.g., PDL) Card Scan Scan successful Scan failed / rescan 3.3.3.3 Restrictions/limitations  Card must be in close proximity for the RFID reader to pick up the signal. This will vary pending on the reader and card used.  The card must be kept in good condition otherwise it might not scan at the gate. 3.3.3.4 Local data structures No data structure is needed for this device. 3.3.3.5 Performance issues  The database should provide the user with access to the keypad in a reasonable amount of time. 3.3.3.6 Design constraints N/A

3.4 Description for Component Admin/User Login/Logoff 3.4.1 Processing narrative for component Admin/User Login/Logoff The Admin/User Login/Logoff is relevant for the website. Any registered user of the system may login to the system via the Internet. If a normal user of the system logs onto the system then they be able to view information that pertains to their account. This includes their account balance, garage parking history, and update account information. An administrator of the system will be capable of viewing anything about the parking garage system. This includes registered users, pricing, garage information, and garage statistics. The administrator will also be allowed to view account information of the users and update specific information that is allowed by the design of the system. Afterwards both the user and administrator will have the option to log out when they are finished on the website. 3.4.2 Component Admin/User Login/Logoff interface description. The input interface will include two fields, one for the username and one for the password. They will enter each into the appropriate box and press “Login” to continue. If they are a registered user of the system and the information entered is correct, they are granted access to the garage website. The left side of the screen will contain all the links the users and administrators will have and include a link to “Logout”. Pressing this link will log the user off the website.

No data structure is needed for this device. 3.4.3.5 Performance issues  The database should provide the user with access/denial to the garage website in a reasonable amount of time, no more then 5-10 seconds.  Logging onto the system may be slow if many users are trying to gain access to the website. 3.4.3.6 Design constraints  8-30 character password  Individuals are allowed five attempts before they must contact the garage administrator for troubleshooting. 3.5 Description for Component Modify Account Information 3.5.1 Processing narrative for component Modify Account Information Users of the system are allowed to modify account information. This includes their e-mail address, password, home address, phone number, and name. This is to ensure that users of the system can change information if the need arises. If users wish to update this information, a link on the left side of the screen is provided labeled as “Update Account Information”. If users wish to update their password or e-mail address, then they must enter the information twice to ensure the e-mail address and password are identical. Administrators will also be allowed to update this information but only if the user calls and requests the information change. 3.5.2 Component Modify Account Information interface description. The interface to update the account information will be a series of boxes that will ask the user to input the required information. A

series of checks is performed once the user clicks the “Update” button to ensure the information is in the right format, e.g. the password must be 8-30 characters, if the user does provides too few or too many characters an error message will display. 3.5.3 Component Modify Account Information processing detail 3.5.3.1 Interface description The interface will contain various boxes for the user to enter their information. As stated in 3.5.1, if a user wishes to change their e-mail address or password then they must verify them by entering the information twice. 3.5.3.2 Algorithmic model (e.g., PDL) Update Account Information Account Updated Error: Account Not Updated. (Erroneous information) 3.5.3.3 Restrictions/limitations  Users must provide correct information to update their account.  Faulty data is flagged by the administrator and they attempt to contact the individual to correct

their card and gain immediate access to the parking garage and go about their business. 3.6.2 Component Process Funds interface description. The input interface will include boxes for the user to enter their credit card information or add funds directly from their bank account (similar in nature of PayPal). If the information entered is correct, the funds are added otherwise an error message will display alerting the user of the mistake made. 3.6.3 Component Process Funds processing detail 3.6.3.1 Interface description The interface will contain boxes for the user to enter information regarding their credit card or add funds from their bank account. 3.6.3.2 Algorithmic model (e.g., PDL) Add Funds Funds Successfully Added Error: Invalid Account information 3.6.3.3 Restrictions/limitations  Must provide a valid account number.

 Must provide a valid dollar amount. 3.6.3.4 Local data structures No data structure is needed for this device. 3.6.3.5 Performance issues  Adding funds to the users account may be slow if many users are trying to gain access to the website. 3.6.3.6 Design constraints  Must enter an amount as xxx.xx format. 3.7 Software Interface Description. 3.7.1 External machine interfaces At this time, this system will not need to interface to other machines. 3.7.2 External system interfaces Users and Administrators of the system may connect to the website via an Internet connection at any time. The RFID scanner will connect to the database via USB cables and process the information through the database interface. 3.7.3 Human interface The human interface is described in further detail in section 4.0. Overall the design of the interface that users and administrators will see will be a very simple and easy to use interface. It will allow users and administrators of the system a way to view account information or garage information.