Road Repair Tracking System
It is the project name Road Repair Tracking System. It automates the complaint booking Records, their preparing and Maintenance, Balance evaluation, due to calculation other Functions. In other words you can say it a complete Road Repair Tracking System. In this project we can easily maintain Road repairing details. It gives information’s of Annual Reports of road , its services, daily working, daily Receipt & Balance. The Road repair tracking system provides ability to search any records available in the System. It maintains all the records of road work and its availability and information of all types of construction. . 2 Scope This document will describe complete functionality of the Road Repair Racking System. It will cover the assumptions, dependencies and constraints of the system. It will include use-case models, class and object tables, as well as sequence diagrams. Residents raise repair requests for different roads of the city and it will be recorded in computer system by a clerk. Soon after a repair request raised, a supervisor visit the site and remark the road condition. The supervisor also estimates he raw materials, workers, the types and numbers of machine required.
Based on this data computer system should schedule the repair of the road repair work priority and subject to availability of raw materials , machines and personnel. The manpower and machines that available are entered by the city corporation administrator. He can change these data any time. If any changes to available manpower and machine would require a reschedule of projects. A authorization person can request for various road repair statistics such as number and type of repairs carried out over a period of time and utilization statistics of the repair manpower and machine over period of time. . 3 Definitions, Acronyms and Abbreviations Dopes Department of Public Safety (of large Town) Dopes employee responsible for inspecting pothole sites Pothole Any damaged portion of the paved surface of a road that impedes driving ARTS Road Repair Tracking System SIRS Software Requirements Specification X (value of) the number of reports required about a pothole before it will be inspected. To be determined by the Dopes. 1. 4 Overview The remainder of this document contains two chapters. The first lists the functions and constraints of the system including use-case models.
It will describe the user interactions with the system. The second chapter specifies, in detail, the specification requirements. It also elaborates the design structure using class tables and sequence diagrams. 2. Overall Description The Road Repair and Tracking System is the new, self-contained product. The ‘Road Repair and Tracking System’ is using v. Net. All components follow Model-View- Centralization. The clerk can retrieve information of their Complain progress. All pages of the system are following a consistent theme and clear structure.
The occurrence of errors should be minimized through the use of checkbooks and crackdown in order to reduce the amount of text input from user. Error message should bloated beside the error input which clearly highlight and tell user how to solve it. If system error, it should provide the contact methods. The page should display the project process in different color to clearly reflect the various states. Each level of user will have its own interface and privilege to manage and modify the project information. User interface elements are easy to understand.
Part of user interface is well organized screen and the parts are concatenated right. When seers look at ethnocentric, they understand which pane is used for which purpose. Each task of interface is specified clearly and users use them correctly. When users use the user interface, they cannot which element is used to which operations. The interface actions and elements are consistent. The screen layout and color of the user interface is appealing. Since the application must run on the PC, all the hardware shall require disconnect the PC will be hardware interface for the system.
The main interface would be the monitor, Keyboard and mouse. 2. 2 Product Features This technology includes more advantages over manual work. Here this system measure the work of a day, month or yearly. The Roan Repair Tracking system provide following facilities and services. 1)Monitoring all records 2) Searching of records by name, phone number or by specific id 3)Updating records 4) Records of all transaction 5) Customer records 6)User records 7) Maintenance records 8) Saving the records The proposed software is intended to run on client/server model network.
A Client/ server can deliver the better performance than the file server system because a client application and database server work together to split processing load of applications (thus the term distributed processing). The server manages the database among the number of clients, while the client send, request, and analyses the data entry form with small specific data set, such as rows in a table not file as in the file server system. 2. 4 User Documentation List the user documentation components (such as user manuals, on-line help, and Tutorials) that will be delivered along with the software.
Identify any known user documentation delivery formats or standards. 2. 5 Assumptions and Dependencies While cost estimation of the proposed system it has been assumed that the cost Hardware and for license of Operating System and back end will be met by client (The organization). Hence only the cost incurred for the proposed software is Included therein. The followings are identified as some of the potential risk factors or dependencies: (1) Non-availability of required resources. (2) Power cuts. (3) Slippage of schedule due to unpredictable holidays, etc.
Life Cycle Model – I am using OSDL model that begin at system level and progresses through analysis, design, coding, testing, implementation and maintenance. 3. System Features The following features were required by the client: ) The system should be secured enough to rely upon. 2) Users should not be allowed to delete/modify patient records. 3) Every report should keep the tracks of user inputting the record. 4) System should provide facility of exporting its data in text format. 5) System should provide facility of uploading the information. . 1. 1 Description and Priority: Provide a short description of the feature and indicate whether it is of High, Medium, or Low priority. You could also include specific preconceptions ratings, such as benefit, penalty, cost, and risk (each rated on a relative scale from a low of 1 too high f 9). 3. 1. 2 Stimulus/Response Sequences: behavior defined for this feature. These will correspond to the dialog elements associated with use cases. 3. 2 Functional Requirements Itemize the detailed functional requirements associated with this feature.
These are the software capabilities that must be present in order for the user to carry out the services provided by the feature, or to execute the use case. Include how the product should respond to anticipated error conditions or invalid inputs. Requirements should be concise, complete, unambiguous, verifiable, and necessary. Each requirement should be uniquely. . 2. 1 Use-Case Model Survey The following use-case models demonstrate the various interactions of users with the system. The table is adopted from “Systems Analysis and Design”, by Whiten, Bentley, and Dominant.
A) Case 1 – Enter Pothole Information: When a citizen of Small town encounters a pothole during their daily travels, he or she may choose to report that pothole to the Dopes using the ARTS. Input: Assume that the citizen reporting the pothole in fact came in contact with a valid pothole. Output: The pothole reported must be reported on a valid street within the city limits of large Town. While a user/alp can report on as many potholes as he or she encounters, the user/alp can only report on any particular pothole once.
B) Case 2 – Verify Pothole Information: When the inspector is notified automatically that the pothole needs to be inspected and verified, requiring that the inspector access the system in order to retrieve the information regarding the pothole, the inspector logs into the system and views the pothole report. Input: The purpose of this use case is to supply the Dopes inspector with information pertaining to a particular pothole ID so that the inspector can visit he pothole site in order to verify the accuracy of the reported information and determine if a work order should be issued.
Output: When the precondition is met, the system will automatically notify the inspector that a pothole needs to be inspected. C) Case 3 – Authorize Pothole Information: After the inspector has verified the accuracy of a pothole report, he will access the system in order to authorize or deny a work order to be assigned to the pothole for repair. Input: The purpose of this use-case is to authorize or deny a work order to repair a pothole after the inspector has inspected and verified the accuracy of a pothole report.
If the pothole repair is authorized, a work order is created and the work crew is notified. Output: The inspector visits the site to verify the accuracy of the pothole report. D) Case 4 – Retrieve Work Order: When a work crew receives notice that it has been assigned a work order, they can log into the system in order to retrieve the information regarding their work order. Input: The purpose of this use-case is to supply the work crew with the information pertaining to their work order.
Output:The inspector has authorized the repair of a pothole and the system has automatically issued a work order to a work crew. Alternatively, if the inspector, after re-inspection, has chosen to reassign the work order, the system has automatically re-issued the work order to a work crew. E) Case 5 – Finalize Work Order: After a pothole has been repaired, the work crew submits a final report to the system, including any relevant information. Input: The purpose of this use-case is for the work crew to submit a final report regarding the repair of the pothole from its work order.
Output: The work crew has F) Case 6 – Re-inspect Pothole after Repair: After the work order has been completed ND the work crew has submitted its final report, the inspector must re-inspect the site to verify the quality of repair. Input:Will benefit from the repair of potholes in large Town Work Crew – Will benefit from knowing whether or not their repair is satisfactory to the Dopes or whether or not it will require further work. Output:The work crew of a work order has submitted its final report declaring the pothole repaired.
G) Case 7 – Access System Information: The system administrator will have complete access to all information within the system database. Will full access, the yester adman can retrieve various statistics, analytics, and other aggregated data as well as perform any necessary maintenance. Input:The purpose of this use-case is for the system administrator to access any information or perform any system maintenance as is necessary. Output: display its information. 3. 2. 2 Interface Requirements 3. 2. 1. 1 User Interface: The user interface should be easy to complaint.
When users use the user interface, they should know which element is used to which operations. We should teach using of the user interface to users simply. 4. Non-functional Requirement 4. 1 User Interfaces User interface is used to provide communication between users and system. Our product should have communication between them. Firstly the system should ask to its users about where they will go, when they will go, which option they will use (least money or least time). Users will enter their desired place, date period and they will select an option (least time or least money) for finding the optimized path.
The system gets these inputs by using user interface. Then, the system will study to find an optimized path for users according to least time constraint which is selected by users. The user interface should be easy to learn. When users use the user interface, of the user interface to users simply. If it is hard to learn, then teaching will take long time and there will be an extra cost for teaching of product. 4. 2 Hardware Interfaces The hardware interface for the user would be any PC having a configuration of P-l and above 1. KGB HAD for loading any SO for operating the browser shall be able to interact with the system without any problem. The main interface would be the monitor, Keyboard and mouse. The bar code scanner is required for scanning the assets during the yearly verification of the assets. The requirements can be unmarried as below: Memory : BIB Keyboard: 2 no’s. Mouse :1 no’s. Cable Power connector Backup battery Windows XP or more version Oracle ii Hypertext Transfer Protocol (HTTP) shall be used to provide a communication between system and users.
Because, ARTS is a web-based system which should be reached on World Wide Web by users. Hypertext Transfer Protocol (HTTP) is a communications protocol which is used to transfer or convey information on intranets And the World Wide Web. The client making an HTTP request, such as a web browser, is referred to as the user agent. The responding server, which stores or rates resources such as HTML files and images, is called the origin server. In between the user agent and origin server may be several intermediaries, such as proxies, gateways, and tunnels.