Software Requirements Specification For. Prepared by Group 04

Transcription

1 Software Requirements Specification For MobiTiki Version 1.0 Prepared by Group 04 Atukorala A.U.B. (040023H) Priyadasraha G.V.J. (040283D) Dissanayake C.P. (040080D) Kumara M.G.C.P. (040203K)

2 Table of Contents 1. Introduction The Purpose of this Document Document Conventions Intended Audience Overall Description Product Perspective Project Scope User Classes and Characteristics Train Passengers The System Administrator from the railway department Operating Environment Hardware requirements Software Requirements Design and Implementation Constraints Embedded System related constrains Mobile phone related constrains User Documentation Assumptions and Dependencies External Interface Requirements User Interfaces Hardware Interfaces Software Interfaces System Features New user Registration User Identification Ticket issue Account Reload Transaction Summery Value Added Services Other Nonfunctional Requirements Performance Requirements... 13

3 5.2 Safety Requirements Software Quality Attributes References... 15

4 Document History Date Author Description of Change Version July 2, 2007 Group 04 Initial Draft 1.0

5 1. Introduction 1.1 The Purpose of this Document The System Requirements Specification (SRS) consolidates, records, and formalizes all system requirements. It is intended to facilitate the establishment of a common understanding of the capabilities of the system amongst the various project stakeholders. The evolving SRS is the primary deliverable arising out of the Requirements Analysis Discipline. It is consumed by each of the downstream disciplines during each iteration of the project: Analysis and Design Implementation Testing The purpose of this document is to clearly state the functions and capabilities of the software system that is going to be developed. The software system which is to be developed is an Automated Train Ticket Issue system, which as the name suggests will automate the train ticket issuing process. The main objective of this system is to minimize the time delay in issuing tickets manually.

6 1.2 Document Conventions The conventions used to prepare the document is given bellow Font Times New Roman, size 12 Main headings, Bold size 18 Sub headings, Bold size 16 Sub-sub headings, Bold size Intended Audience This document is primarily intended for the evaluators of the system. Other than that the developers of the system can use this as a guideline. Any third party who needs a basic understanding of the system may find this document helpful.

7 2. Overall Description 2.1 Product Perspective This product is a combination of four main components, namely Image processing and embedded system, the web portal, web service and the J2ME application. The main objective of developing this product is to reduce the time & human resource taken for purchasing train tickets, by automating the process. 2.2 Project Scope A Passenger needs to register for the pre service via a Web Portal using a Prepaid card (Similar to SLT Prepaid Cards) which can be purchased from an authorized shop. After a successful creation of the account a specific code will be generated for each user and will be sent to him by a MMS. In the Railway stations users will be authenticated using the code provided to them by a smart device. Then the purchase of the ticket would be done in a similar way as in Bank ATM. Once the transaction is completed an amount equal to the price of the ticket will be deducted from the user s account and a ticket will be issued. 2.3 Product Features New User Registration This registers a new user via the web portal. User identification and issue of the ticket The user is identified via his mobile phone and relevant transactions will be carried out. Account Reload The user will be given the facility to reload his account via the web portal or the J2ME application. Other value added features This will include checking account summary and train time tables.

8 2.4 User Classes and Characteristics Train Passengers This is the main user group the product is aimed at. Normal train commuters will be the most regular users of the system The System Administrator from the railway department This person will mainly observe the day today proceedings of the system and makes sure the system is up and running. He/she will also carry out the price, time table updates to the system. 2.5 Operating Environment The ticket issuing part (the embedded part) will be operational from the railway station. The J2ME application will run on any Java enabled phone which meets the requirements specified. The web portal will be hosted in a public domain Hardware requirements Mobile phone : A GPRS enabled service provider, Ability to handle HTTPS connections Java Enabled Web Cam : A Megapixel range Web Cam Software Requirements Database Server: Microsoft SQL Server 2005 Web Server : IIS Web Server 6.0 or above Runtime for desktop application: Microsoft.NET Framework 2.0

9 2.6 Design and Implementation Constraints Embedded System related constrains Building a complete embedded system which is similar to a bank ATM with Image processing capability requires a considerable time and effort. So the embedded part is simulated using a USB number pad and a desktop application Mobile phone related constrains In order to facilitate the reloading feature in a secure manner the mobile phone should have the capacity to handle HTTPS connections. 2.7 User Documentation Both the J2ME application and the web portal will have their own inbuilt help. 2.8 Assumptions and Dependencies Overall speed of the system will depend on the speed of the network used to communicate between embedded system and the web service. The GPRS networks are fast enough to deal with HTTPS connections without the occurrences of time outs. The web cam will be powerful enough to capture a quality image.

10 3. External Interface Requirements 3.1 User Interfaces The normal passengers will use the system, so the User Interface will be critical. A Common keypad will be supplied to the user. The User Input should be displayed in the application. The user interface for ticket issuing will be a common interface like an ATM machine. 3.2 Hardware Interfaces The system should be extended to the many transport services if required. (Scalability) The user interface communicates with the USB keypad. The user recognition should be through a Webcam. 3.3 Software Interfaces The application should be pluggable with a web service. (Interoperability) The system should be handled via a web portal. J2ME application should be coupled with the system. The user-unique code should be identified using an image processing function.

11 4. System Features 4.1 New user Registration When new client coming into the system, a unique 2-D barcode will be created on his behalf. The barcode image will be send to the client as a MMS or it can be downloaded via GPRS. 4.2 User Identification At the ticket issuing system the user should display his unique barcode image which is on the mobile phone to the web cam. After authentication is completed user will be logged into the system. 4.3 Ticket issue The client enters his travelling details into the system. If the client has enough credit in his account, he will be permitted to carry out a valid transaction. The momentary value of the transaction will be deducted from his system. A valid ticket will be issued once the transaction is completed. 4.4 Account Reload The client can purchase a pre paid card through an authorized dealer. The account can be reloaded via the web portal or mobile application.

12 4.5 Transaction Summery After a complete transaction, the client will be entitled to a valid ticket. The client can request details about his last transaction and current balance in the account. 4.6 Value Added Services The updated time table will be displayed in the mobile application and the web application. News and announcements.

13 5. Other Nonfunctional Requirements 5.1 Performance Requirements Response time of the system should be minimized by minimizing the data transfer since it can directly affect the time required to obtain a valid ticket. Since the system intends to handle the train ticket issuing process it should be available and properly functioning at any time of the day. Down time should be minimized. In the system, a 2-D barcode (semacode) is used for user identification. Thus the algorithm that is used must be efficient. Then the system can decode the 2-D barcode very fast. So passenger doesn t need to wait a long time for their recognition. Because of the use of J2ME application it ll run on many mobile platforms. Due to this reason this system can optimize resources in an efficient manner. The web service will be deployed in a local web server (within Sri Lanka). Thus the delay time of passengers can be minimized. 5.2 Safety Requirements The user details should be encrypted by using RSA policies. Also the account details should be encrypted by using RSA policies. The authorization should be accurate, because of the use of the image recognition for user identification. Since this involves money transfers, user subscription and any other confidential data need to be secured. Also the communication needs to be carried out securely.

14 5.4 Software Quality Attributes Multi Language support Since the System mostly involves with the local population system should support both Sinhala and English languages. Usability - System should be simple and user friendly interfaces need to be provided. Adaptability The system should customizable with any other transportation system. Availability - Since the system intends to handle the train ticket issuing process it should be available and properly functioning at any time of the day. Down time should be minimized. Correctness - Because of the system uses a pre paid service, accuracy need s to be higher. Maintainability The cost of day-to-day maintenance needs to be lower.

15 6. References Semacode Technical Paper. Semacode Corporation. Available at Honours Project Report on CipherCode A Visual Tag SDK Tag Decoder Component by Ramone Karodia University of Cape Town