Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

Cost-effective Real-time Transport Management System Software Requirements Specification

Version 1.0
1 Overview & Scope The purpose of the Software Requirements Specification is to fully describe the external behavior of the Transport Management System. It also describes nonfunctional requirements, design constraints, and other factors necessary to provide a complete and comprehensive description of the requirements for the Transport Management System. This document includes requirements specifications (Function and Non functional) for the entire Management System, including the presentation, business, data layers and voice layer. The system later can be integrated with other system like Student Information System. 2 Assumptions and Dependencies The System will run on Web Server with Internet Connectivity. The Vehicle should be equipped with GPS Receiver and helper should have a mobile phone or a laptop. The Administrator should have shape (GIS) file of the city in which the System operates. 3 Definitions, Acronyms and Abbreviations Following terms are used in this document which may have different meaning. Here is the meaning to be interpreted for these terms: TMS: Transport management system SRS: Software requirement specification Client: This stands for the user accessing the application through the web browser. Front End: This stands for the JSP pages that a user will see when (s) he will access the application through the web. Business Logic: This part contains all calculations and rules required for running the application. Faade: This is layer working as mediocre for accessing other layer. Vehicle: Transport entity used for transportation of students. Helper: Vehicle conductor which helps the driver & students in the vehicle. Operator: A user which is hired for data entry of this system. Management: The top management of the education institution.

IIITM, 2006

Page 1

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

Project Team & Work Role Team consists of four members. Here is the technical expertise for each:

S. No. 1. 2. 3.

Member Name Anuj Kumar Goyal Kunal Garg Mohit Garg

Arch. Layers to develop Data Access Layer, Voice Layer Business Layer, Presentation Layer Business Layer, Voice Layer

Technical Expertise Cloudscape, XML, Web Services, JSP, JSF, EJB Cloudscape, AJAX, Genetic Algorithm, EJB, JSP, JGAP, Openlayers Cloudscape, JavaScript, Genetic Algorithm, EJB, JSP, XML, Openlayers, Geotool API

Technologies to be used Technologies to be used are as follow: Java, Servlets, JSP, JSF (Java Server Faces), EJB, AJAX, XML Web services, Cloudscape, Voice XML, JChart, Geotool API, Openlayers, JGAP(Java API for Genetic Algorithm). Specific Hardware required: GPS receiver, Mobile phone, Bar-code scanner, Laptop or palmtop (Optional) Where these technologies fit into the architecture JSP / JSF: The presentation layer of the application will be developed using JSF technology. It will separate front end design code from java code so that we can more concentrate on our work according to our work role (For Example a developer can work on design without worry of backend integration). AJAX / Servlets: The application will be provided by a very interactive front end by using AJAX technology and according to front end different Servlets will be developed to sending response to the request made by java script working in clients browser. EJB: Entity beans will be used for interaction with DB and the business logic will be developed in session beans also working as session faade for entity beans. EJB Timer services will be used for automatic DB update like vehicle current location, Automatic SMS etc. Web Services: GPS web service exposed by a service provider will be consumed by the application for current location of the vehicles.
IIITM, 2006 Page 2

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

Voice XML : To provide Interactive voice response services (IVRS), Voice XML with JSP will be used which will run on IBM Websphere Voice Server. JChart: It will be used for displaying the comparison of performance of different Drivers & Vehicles in a graphical manner. Different graphs will be generated according to the parameters selected by the user. Geotool API: This API is used to read and extract ESRI Shapefile that store road network of the city. Openlayers: This is an Open service that provides free maps and a JavaScript tool for high interaction with user. JGAP: It is used to implement the Algorithm for finding optimal scheme of Routes taken by vehicles. 6 User Identification & Classification Users of the system mainly classified into following categories: 1. Administrator: Controller of the system 2. Management: The top management of the educational institute 3. Student / Parents: Students studying in the educational institute and their parents. 4. Operator: Data operator which will be hired for the data entry into the system 5. Helper: The bus conductor which will have a Mobile to communicate through IVRS and may have laptop or palmtop to communicate directly to web server. 7 Functional Requirements These are the important requirements of the users of the system. The significance of different field in each requirement is as follow: Actor: Originator of the requirement. Actor is the main cause or user of that requirement. Use Case: Tell the use case number of the requirement in the use case diagrams in next section. Description: Description of the requirement. Rationale: The use or benefit of the requirement. Source: Where to implement that requirement.

IIITM, 2006

Page 3

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

Fit Criterion: How the requirement will be fulfilled. Dependencies: Requirements number on which current requirement depends. Dependencies mean it is necessary to fulfill all dependent requirements before implementing that requirement. Functional requirements are as follow: 1 Admin shall be able to control access of other users over different features/services available in the system Use Case #: 1 Requirement: 1 Actor: Admin Description: Admin shall be able to control access of other users over different features/service in the system Rationale: Admin may wants some specific user or a class of users to be restricted to some particular service Source: Presentation Layer Fit Criterion: Dependencies: Independent 2 There shall be a separate login account for each Actor. Actor: Admin, Operator, Student, Use Case #: 2 Requirement #: 2 Management, Helper Description: There should be a separate login account for each Actor. Rationale: When Actor login to his account, this will allow him to access the feature for which he has permissions granted by Admin. Source: Presentation Layer Fit Criterion: The web page presented to the user ask for the user name/Id and password, then on clicking Submit button he will be redirected to his account. Hitting the enter key should also login him. Dependencies: 1 The interface shall be available in many languages according to users need. Actor: Admin, Operator, Student, Use Case #: 3 Requirement #: 3 Management Description: The interface shall be available in English, Hindi and regional languages. Rationale: There may be some user of the system comfortable in .some specific language. Source: Presentation Layer Fit Criterion: At the time of login the actor will be asked for the language choice through a select box. Dependencies: Independent

IIITM, 2006

Page 4

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

The system shall be configurable according to the City/Region of the Institute. Use Case #: 4 Requirement #: 4 Actor: Admin Description: The labeled Map of city in which the school is located will be uploaded. Rationale: The system could be used by different institutes located at different cities. Source: Presentation Layer, Business Layer Fit Criterion: Upon pressing Upload button Actor will upload shape file. This map will be shape file of the city (standard GIS file), this file can be easily map with the latitude and longitude and is easily available on internet. Dependencies: Independent Administrator shall be able to identify/Mark Bus Stops in a city. Use Case #: 5 Requirement #: 5 Actor: Admin Description: Bus Stop from where Vehicle will wait for student. Rationale: This Bus Stop will help System to identify route for the Vehicle. Source: Presentation Layer Fit Criterion: Actor will mark Bus Stop with the help of mouse cursor on the map of city generated from shape file. An alternate text based method is also provided in addition to the graphical one. Dependencies: 4 Administrator shall be able to identify/Mark Roads which are not suitable. Use Case #: 6 Requirement #: 6 Actor: Admin Description: Administrator shall be able to identify/Mark Roads which are not suitable. Rationale: There may be some roads which are either unhealthy or over bridges that require expensive taxes that Admin dont want to consider for transport. Source: Presentation Layer Fit Criterion: Dependencies: 4 Administrator shall be able to identify Students on a Stop Requirement #: 7 Actor: Admin, Student Use Case #: 7 Description: What will be the stop of each student will be identified in this Step. Rationale: This will help to know which student will board from the Stop Source: Presentation Layer Fit Criterion: Admin can enter the station id with student id and then press submit button. From an alternate page, actor can select a bus stop and add students to it. Dependencies: 4,5 A student shall be able to request to Administrator for Bus Stop Change Use Case #: 8 Requirement #: 8 Actor: Admin, Student Description: Student will request Admin to change his Bus Stop through web site.
IIITM, 2006 Page 5

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

Rationale: Student may change their house, therefore require to change their Bus Stop Source: Presentation Layer Fit Criterion: In the first step student will fill his new Option and on pressing Submit button, his request will be Submitted to Admin. In the Second Step Admin will check which request is to be fulfilled and according to available seat will fulfill them. Administrator will also be given a warning message if the request results in overloading of any vehicle. Dependencies: 4,5,7 9 Administrator shall be able to Enter/Edit/View Vehicle Details Use Case #: 9 Requirement #: 9 Actor: Admin Description: Actor will enter/edit Vehicle Details Rationale: This Step is required when new Vehicle is purchased or leased. Source: Presentation Layer Fit Criterion: In the Entering Phase Admin will enter Vehicle details using web form and in the edit phase Admin will select Vehicle no and then edit information using web form. Dependencies: Independent Admin shall get an Interrupt Message on expiry of Insurance Policy Actor: Admin, Use Case #: 10 Requirement #: 10 Management Description: There will be an interrupt in case of expiry of insurance of a vehicle. Based on that s/he can take appropriate action. Rationale: Vehicle Insurance Premium has to be paid after a fixed time, there shall be an interrupt before its timeline expire. Source: Business Layer, Presentation Layer Fit Criterion: An ajax based polling method will keep checking server for any expiry case, in case of which it will throw a popup message on the Actors screen giving up the details. Now its on him weather to take action or to ignore the message. Old messages will be saved in Message section. Dependencies: 9

10

11 System shall suggest to Administrator an Algorithmic Efficient Way for Route Definition for Vehicles Use Case #: 11 Requirement #: 11 Actor: Admin Description: Route for each Vehicle will be efficiently defined, specifying Vehicle should go to which Stops and in which order. Rationale: This step is requiring so that all Bus stops will be covered in the most optimal way, i.e. to minimize the distance traveled by vehicles and thus fuel costs. Source: Business Layer, Presentation Layer Fit Criterion: A page will show admin the report of number of students at all stops and capacities of all vehicles, and give a warning in case total number of students exceeds total
IIITM, 2006 Page 6

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

capacity. Administrator can then ask for the suggested routes which will be the output of a Genetic based Algorithm for Multi-Vehicle TSP for minimizing total path length and will be displayed as a trail of stops for each vehicle and the seats occupied after each stop, and total length of the routes(in KM) in tabular format. There will be 10 best solutions displayed. Its on Admin weather to accept or reject the suggested solution. Dependencies: 4,5,6,7 12 Administrator shall be able to Set Route Definition for vehicles in own way Use Case #: 12 Requirement #: 12 Actor: Admin Description: Admin can customize the route of the vehicle in his/her own way. Rationale: Solution generated by Algorithmic Way may not sound appropriate to Admin, so s/he can customize in his own way. Source: Presentation Layer Fit Criterion: A webpage with city map will be shown, where admin will select a vehicle and define its route by serially clicking on bus stops marked on the map. Beside this, there could be an alternative way in which he can select the bus stops through a series of select boxes. Dependencies: 4,5,6,7 There shall be a provision by which one can identify which student boards which Vehicle Use Case #: 13 Requirement #: 13 Actor: Admin Description: There should be a provision by which one can identify which student boards which Vehicle. Rationale: In case Admin wants to know about a particular student. Source: Presentation Layer, Business Layer Fit Criterion: Actor will be asked the student ID and the Vehicle will be displayed. Dependencies: 4,5,6,7,9,11 Administrator shall be able to Enter/Edit/View Drivers and Helpers Details Use Case #: 14 Requirement #: 14 Actor: Admin Description: Actor will enter/edit Drivers and Helpers Details Rationale: This Step is require when new Driver or Helper is hired. Source: Presentation Layer Fit Criterion: In the Entering Phase Admin will enter their details using web form and in the edit phase Admin will select Vehicle no and then edit information using web form. Dependencies: Independent

13

14

15 Admin should be able to choose current service through any combination of a Route, its Vehicle and its Driver and Helper and keep its records. Use Case #: 15 Requirement #: 15 Actor: Admin Description: Admin can assign/change any vehicle, Driver or Helper on a Route.
IIITM, 2006 Page 7

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

Rationale: Actor may have to change the Vehicle, Driver or Helper in case one is out of service. Source: Presentation Layer Fit Criterion: All the current combinations of Route, Vehicle, Driver and Helper will be presented to the actor through a webpage which s/he can edit accordingly. Dependencies: 4,5,6,7,8,11 16 Admin shall be able to declare/Update Time tables for Vehicles and they shall be open to all. 16 Requirement #: 16 Actor: Admin, Student Use Case #: Description: Administrator can set the list of Vehicles arrival/departure on stop in 2 different ways. First by setting start time of the vehicle trip from institute and average speed of the vehicle. Secondly, time table could be extracted from the past 30 day records of vehicles arrival times at different stops. This updated time table shall be open for all members. Rationale: During initialization of the system, Admin could use first method to define the time table, but days pass, there should be a new time table giving more accurate timings based on past 30 days. Source: Presentation Layer, Business Layer Fit Criterion: Admin will be given 2 different pages to update/set time table for a particular vehicle. Dependencies: 4,5,6,7,8,11,15

17 Admin & students shall be able to locate Current location of a vehicle and maintain its record for future reference. 17 Requirement #: 17 Actor: student Use Case #: Description: Admin & Student can see the current status of his/her vehicle. Rationale: Admin should have a real time monitor over the vehicles for constant support and security purpose Source: Presentation Layer, Business Layer, Web Service Layer Fit Criterion: Admin will be given an interface where the labeled city road network will be shown with stops marked. S/he can select the Vehicles from a multiple selection menu for which s/he want location to know. The vehicles with their icons will be seen moving accordingly on the map along the roads on the map. This will make use of constantly fetched web service that provide the exact longitudes and latitudes of the vehicles from a GPS service provider. Dependencies: Independent 18 There shall be a provision for sending SMS regarding accidents or Vehicles changed timings or Vehicle getting late to students parents. 18 Requirement #: 18 Actor: Admin, student Use Case #: Description: There shall be a interface where admin can post SMS to students/Parents
IIITM, 2006 Page 8

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

regarding bus accident, traffic jam or new timings of the vehicles to their respective students. Rationale: Students should be informed that the bus would get late because of the particular reason. Source: Presentation Layer Fit Criterion: The SMS will be generated either by the System by sensing the motion of the Vehicle using GPS data, or through massages sent by Helper to the Admin. Based on those Admin can choose any particular message to be broadcasted to relevant person. Dependencies: 4,5,6,7,8,11,15,16,17

19

An actor shall be able to Edit SMS settings Requirement #: 19 Actor: student

Use Case #:

19

Description: Student can switch on/off and set minimum latency time in which he will get SMS. Rationale: Student may want to customize SMS which s/he receives from Admin. Source: Presentation Layer Fit Criterion: Actor will be provided with a radio button by which s/he can enable or disable the service. If enable s/he will be asked the minimum time latency only after which SMS will be sent. Dependencies: 1,2

20 System shall automatically provide an alternate Route to a vehicle in case its not able to proceed on its usual route (in case of traffic jams) Use Case #: 20 Requirement #: 20 Actor: Admin Description: There should be a alternate Route for a vehicle in case Vehicle gets stuck in some traffic jam and cannot move ahead. Rationale: In case of traffic jam or some accident or some VIP passing by can make vehicle wait a long. Source: Presentation Layer, Business Layer Fit Criterion: Helper of the vehicle can send a message through his mobile phone on IVRS or via laptop or PDA to the system. In response to that alternate route will be generated by the system will be send back to the Helper by any of the above mention medium. Dependencies: 4,5,6,7,8,11,15,16

21 In case of any vehicle failure or accident, system should suggest provision by diverting other Vehicles so as to cover the stops left by the victim vehicle. Use Case #: 21 Requirement #: 21 Actor: Admin Description: There should be a alternate Routes for some vehicles in case a particular Vehicle gets into accident or technical failure and unable to move at all. In this case system is required to come up with a solution so that other vehicles can collect the victims
IIITM, 2006 Page 9

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

students and cover the stops that are left. Rationale: In case of accident a backup route can be assigned to the Vehicle. Source: Presentation Layer, Business Layer Fit Criterion: Helper can send a message via mobile/PDA/laptop, whichever is easily accessible to him. All the Helpers of the vehicles whose Routes has been diverted will get the new Route to be followed by them. Dependencies: 4,5,6,7,8,11,15,16 22 Student shall be able to View messages Use Case #: 22 Requirement #: 22 Actor: student Description: Student can view messages(new/old) Rationale: Student would like to know all the Messages which s/he received from admin. Source: Presentation Layer Fit Criterion: All the messages that a student will get will be shown in tabular form. Dependencies: 4,5,6,7,8,11,15,16 There shall be a provision of handling Queries through IVRS Use Case #: 23 Requirement #: 23 Actor: student Description: How much is the bus late, current location of vehicle, time table for vehicle the student can get information about it using IVRS Rationale: A student/parent with no web access can use this service. Source: Business Layer, IVRS Layer Fit Criterion: This will be a self explanatory and interactive service. Dependencies: 4,5,6,7,8,11,15,16

23

24 There shall be a provision to keep Record of expenses incurred through Fuel, Maintenance, Penalty, Taxes etc and their receipts. Use Case #: 24 Requirement #: 24 Actor: Admin, Operator Description: Actor can insert a record of different type of expenses incurred. Besides, s/he can also add a new category/type of expense. Rationale: These details will be very useful in monitoring and evaluating the performance of the Vehicles and Drivers. Source: Presentation Layer, Business Layer Fit Criterion: Actor will select the combination of Vehicle, Route, Driver and Helper corresponding to whom the particular expense occurred. All relevant details in context will be taken through a web form. Dependencies: 4,5,6,7,8,11,15

25

There should be provision to see Expenses Incurred and Efficiency between a time period Use Case #: 25 Requirement #: 25 Actor: Admin, Management Description: There should be a way through which one can know expense incurred for fuel/maintenance/penalty/tax etc within a time period. One can also see the efficiency
IIITM, 2006 Page 10

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

which is based on parameters like Expenses made, Average speed, Maximum Speed, Accidents, Latency etc. Rationale: This provides a way to monitor performance of Vehicles, Drivers and Helpers. Since we assume that an expense made on Vehicle also has a role of Driver/Helper and the Route on which the Vehicle was assigned. This assumption will also help in finding out Association rules between the Drivers/Helpers with Vehicles and Routes. Source: Presentation Layer, Business Layer Fit Criterion: This will give Actor one page where s/he can view aggregate expenses incurred on all vehicles for a time period. On a different page, s/he can also view the sources of expenses, for example, if s/he wants to see the expenses made by a specific Driver, so s/he can also choose either Vehicle or Route or Helper through a Select box, and the expenses details will be categorized according to the choice selected through Select box. So, if Vehicle is selected, the expenses will be shown categorized by Vehicles. Dependencies: 4,5,6,7,8,11,15,24 26 There shall be a way for Comparison of Vehicles or Drivers or Helpers 26 Requirement #: 26 Actor: Admin, Management Use Case #: Description: Actor can compare efficiency of vehicles on the bases of parameters that define efficiency (Req. 11) Rationale: This will give Actor a comparative study of different entities. Source: Business Layer, Presentation Layer Fit Criterion: The comparative study of different members will be displayed in a tabular form with members as rows and parameters of comparison as columns. Dependencies: 4,5,6,7,8,11,15,24 Way to identify a student has boarded on the bus or not Requirement #: Actor: Admin, Management, Use Case #: 27 27 student(parent) Description: There should be a method by which actor can identify whether student has boarded on the bus or not. Rationale: In case a student do not reach the school or home, using this technique we can identify whether he board to the bus or not. Source: Presentation Layer, Business Layer Fit Criterion: Each Helper will be provided with a laptop or a Handheld device attached through a Bar-code scanner. Every time a student enters the vehicle, bar-code on their ID-card will be scanned and transmitted back to the server. Thus any query from parents through website could be handled using this information. Dependencies: 4,5,6,7,8,11,15

27

28

Other Students shall be able to see road network covered by Transport Facility --Requirement #: 28 Actor: Others Use Case #: Description: Other Students can see the extent of the road network covered by TMS
IIITM, 2006 Page 11

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

Rationale: The student who are not availing the facility of transport facility may see whether the vehicle reach near to their house, so that they also can apply for it. Source: Business Layer, Presentation Layer Fit Criterion: This feature will be given as a network of roads and regions marked on the city map that are being covered by current TMS. Dependencies: 4,5,6,7,8,11,15 29 Admin & Management shall be able to get printable reports. Use Case #: 29 Requirement #: 29 Actor: Admin Description: Report on List of Students traveling through a particular Vehicle, Stop covered by a Vehicle on a Route, Student strength on Stops, Students list on a particular Stop, Vehicles details, Drivers/Helpers details, Vehicle/Route/Driver/Helper sessions list etc. Rationale: Actor may have to change the Vehicle, Driver or Helper in case one is out of service. Source: Presentation Layer, Business Layer Fit Criterion: All the current combinations of Route, Vehicle, Driver and Helper will be presented to the actor through a webpage which s/he can edit accordingly. Dependencies: All Dependent

30 Admin shall be able to see the location in the city where maximum number of times diversions were made in cases mentioned in requirements 20 & 21. 30 Requirement #: 30 Actor: Admin, Management Use Case #: Description: System shall be able to identify the trouble areas in the city where traffic jams and vehicle redirections occur frequently. Rationale: This information could be useful to Admin using which he can restrict those areas to be used in routes. Source: Presentation Layer, Business Layer Fit Criterion: This will be shown as dots on the city map. Dependencies: 18, 20,21

8 1

Non Functional Requirement TMS shall be usable by any web browser supporting HTML 4.0 and ActiveX object(for AJAX) Requirement #: 31 Requirement Type: Usability Description: User shall be able to use the TMS with any web browser that supports HTML 4.0 and ActiveX object without additional software. IE v5.0 or higher, Mozilla Firefox 1.0 or higher Rationale: The web browser should be able to be used without configuration interaction from the user. This will eliminate the possibility of configuration errors by an end-user,
IIITM, 2006 Page 12

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

resulting in possible dissatisfaction with the web browser itself. It will also allow users with mobile devices and PDAs to access the TMS. Source: Presentation Layer Fit Criterion: The TMS shall operate successfully in any web browser that supports HTML 4.0 and ActiveX object without the user having to install any additional software. 2 The initial page shall have a link to a help document Requirement #: 32 Requirement Type: Usability Description: The initial page presented to the user shall contain a link to a help document explaining options available. Rationale: Users need to be able to have a point of reference from which to determine how this module works and the functionalities and capabilities that it has. Source: Presentation Layer Fit Criterion: The initial web page presented to the user shall have a link to a document that will explain in detail the options available, how to use those options. 3 During operation, the web server shall crash no more than 2% of the time Requirement #: 33 Requirement Type: Reliability Description: The web server will crash no more than 2% of the time during operation. Rationale: Users need to be able to use the system as needed, and excessive crashes are not advisable. Source: Presentation Layer, Business Layer, Data Layer

The algorithm shall return best optimized results within a certain time period Requirement #: 34 Requirement Type: Performance Description: The algorithm results shall be returned within a time period equaling three times that amount of time required to return all static documents on the server Rationale: Excessive delay in returning results could cause the user to abandon the site and no longer use the TMS. Response time, however, is based on hardware and network factors as well. Source: Presentation Layer, Business Layer, Data Layer Fit Criterion: The amount of time required to return all static documents on a site shall be discovered. Note that this means simply transferring the files, not rendering them in a web browser. The results from the algorithm for any valid road network shall be returned within a time period equal to three times that time period.

Requirement Dependency and Use Case Diagrams The Requirement dependency diagram tells the order in which requirements depends on
IIITM, 2006 Page 13

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

each other. The dependency diagram for this system is as follow:

Use Case diagrams of the system is categorized according to user type. Each use case has a reference number which will refer to a requirement in last section.

IIITM, 2006

Page 14

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

IIITM, 2006

Page 15

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

IIITM, 2006

Page 16

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

IIITM, 2006

Page 17

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

IIITM, 2006

Page 18

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

10

Architecture diagram & database design Architecture: This project will follow layered architecture. Application can be partitioned mainly into following layers. 1. 2. 3. 4. Data Access Layer Business Layer Voice Layer Presentation Layer

1. Data Access Layer: Every need of the data by other layers will be full filled by this layer. This layer will interact with CLOUDSCAPE database which will also use transactions and appropriate security. This layer will be developed by using Entity beans. Most of the Entity beans will use Container managed persistence. 2. Business Layer: Business logic of the application will be incorporated in this layer. This layer will be developed using Session beans. Stateless or Stateful session bean will be used according to the requirement of the presentation layer. EJB Timer services will be used for live working of the application like vehicle current location updation, automatic SMS to appropriate users on Vehicle Accident, Vehicle Late etc. 3. Voice Layer: IVRS services will be provided by this layer. Voice XML with JSP will run on WS Voice server which will be connected through telephony provider. It will interact with business layer for getting latest data and also for updating the data in DB. 4. Presentation Layer: Presentation layer will be developed using JSF technology so this layer can also be sub divided into two layers: a. Design Layer: Will contain HTML and JSF tags and work as the design of the front end. b. Code Layer: It will contain the java code for evens defined in the design layer and will interact with business layer for display of latest data and updating the data. The architecture diagram of the application can be shown as follow:

IIITM, 2006

Page 19

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

Database Design: Following E-R (Entity Relationship) diagram is developed as DB design. In this diagram only ID attribute of an entity is shown for clarity. All attributes can be seen in following DB schema diagram.

IIITM, 2006

Page 20

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

IIITM, 2006

Page 21

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

The database schema diagram is as

follow:
IIITM, 2006 Page 22

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

Description of each table is as follow:

IIITM, 2006 Page 23

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

1. POINTS: Contains all points that form structure of the road network of the city. 2. EDGES: Edges is an object type in shape file which represent a partition of a road. 3. ROADS: Logical representation of the roads of the city.. 4. DIJKSTRASOLUTION: It keeps the minimum distance between each pair of Stops.

5. DIJKSTRAROUTE: It keeps the shortest path between a pair of stops. 6. BUSSTOPS: Stops defined by administrator on which vehicle will receive students. 7. ROUTES: Route details 8. ROUTESWITHBUSSTOP: Set and sequence of Bus Stops in a route. 9. VEHICLES: All vehicles details. 10. DRIVER: Vehicle driver details 11. HELPER: Vehicle helper details. 12. VHONROUTE: Which vehicle will go on which route 13. DRIVERONVEHICLE: Which driver will work on which vehicle 14. HELPERONVEHICLE: Which helper will work on which vehicle 15. LIVEVEHICLEDETAILS: Contains latest location of the vehicle come from GPS service 16. STUDENTS: Student details and settings. 17. STUDENTINBUS: Daily record of whether student is in bus or not. 18. VEHICLEEXPENSES: For all expenses on vehicles 19. EMERGENCIES: Accident / Traffic jam information record for getting diversion points of the city in future. 20. STUDENTATBUSSTOP: Which student on which stop and new request for changing the bus stop. 21. USERPERMISSION: Permission settings for all users. 22. ADMINSETTINGS: Administrator settings 23. LOGIN: Login details of the user 24. MESSAGES: All messages to the user from the system. 11 Time Plan The project scheduling is very important for successful completion of the project. We followed the Waterfall Software Development Model for developing the application. So we have scheduled the project plan as follows:
IIITM, 2006 Page 24

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

S. No. 1. 2. 3. 4. 5.

Phase Name Analysis Design Code Test Deploy / Deployment Script

Approx. Days 10 25 30 30 5

Actual Days 8 30 Working ---------------------

Calendar Schedule Sep 25 Oct 06 Oct 08 Nov 10 Dec 15 Dec 20 Dec 22 Jan 25 Jan 26 Jan 30

We have successfully completed starting three phases. As the test phase is going on and we have generated various test case, which cover all the different cases possible . We have developed all front ends (names give below) of the project, the development plan for different modules with different teams (group of 2-2) is as follow: S.No Module Name . 1. 2. 3. Requirement Front Ends Name s Covered (*.jsp) (ref. by req. no. ) 1,2,3 UserPermission, Login, AddUser UploadFile, VhStopEdit, RoadBlock StudentAtStop, RouteSelection, VhDetailsEdit, DriverDetails, HlprDetails, VhRouteHelperDriver , GenerateTimings VhCurrentLocation, AlternateRouteForVh, CoverRouteByOther Vh, IsStudentOnVehicle EpensesBwTimePerio d, Expenses, Comparison, DiversionPoints StudentOnVehicle, CityCovered, Reports ViewMessage IVRS
IIITM, 2006

Team Members Anuj , Kunal Anuj, Mohit Kunal, Mohit

Sche duled Days 5 10 15

Tech. Skills Required JSF, EJB JSF, EJB, AJAX, GIS API JSF, EJB, Genetic Algorith ms,

Users & Permission , Lang Road Network 4,5,6 Initialization Deploy of details

7,9,11,14,15 ,16

4.

Live Scenario

17, 20, 21, 27

Anuj, Kunal

15

JSF, EJB, Web Service, AJAX JSF, EJB, JChart, Data Mining JSF, EJB, JChart JSF, EJB Voice
Page 25

5.

Outlays & Performance analysis Reports Messages IVRS

24, 25, 26, 30 13, 28, 29 22 23

Mohit, Kunal Mohit, Anuj Mohit, Kunal Anuj,

6. 7. 8.

5 3 10

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

Kunal

XML, JSP, EJB

12

User Interface Few Screen Shots:

In this Web Page we can view the map of the city and mark new Bus Stop or can delete the existing Bus stop. In Case Administrator want to Block any road from the network for safety
IIITM, 2006 Page 26

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

purpose such that he do not want Bus to go there e can block that route directly from Map. This Web Page tells the current location of each Vehicle in Real time by fetching its information from GPS Receiver.

IIITM, 2006

Page 27

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

The Administrator want to search fro a Driver, he can search on the basis of following fields.

IIITM, 2006

Page 28

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

Edit the Details of the Driver

IIITM, 2006

Page 29

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

Add new Vehicle Detail

IIITM, 2006

Page 30

Transport Management System Software Requirements Specification

Version: 1.0 Date: 10/1/2007

In this Web Page Student can set their setting for receiving SMS. 13 References Writing Software requirement specification by Donn Le Vie, Jr.
http://www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html

Engineering and Managing Software Requirements By Claes. Wohlin, Aybke Software Engineering by Ian Sommerville

IIITM, 2006

Page 31