CS 3610: Software Engineering. Summer Software Requirements Specification Document. Project Title: Road Repair Tracking System

Transcription

1 CS 3610: Software Engineering Summer 2013 Software Requirements Specification Document Project Title: Road Repair Tracking System Team 7 Ryan Wooten Chris Wyland Due Date Tuesday 06/04/2013

2 Table of Contents 1. Introduction Purpose Scope Definitions, Acronyms, and Abbreviations References Overview 1 2. Overall Description Use-Case Model Survey Assumptions and Dependencies Specific Requirements Classes/Objects Object Collaboration Diagrams Sequence Diagrams Object Behavior Diagrams Performance Requirements Other Requirements Supporting Information 22

3 Software Requirements Specification 1. Introduction 1.1 Purpose 1.2 Scope This Software Requirements Specification provides a complete description of all the functions and specifications of the Road Repair Tracking System. The intended audience of this document includes the development team, designers, coders, testers, as well as the SmallTown Department of Public Safety. The Software Requirements Specification will fully describe the behavior of the Road Repair Tracking System. It will examine the restrictions of the systems, the assumptions of the environment, and the design constraints to be considered. This document will describe complete functionality of the Road Repait 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. 1.3 Definitions, Acronyms and Abbreviations DoPS Inspector Pothole RRTS SRS X (value of) 1.4 References 1.5 Overview Department of Public Safety (of SmallTown) DoPS employee responsible for inspecting pothole sites Any damaged portion of the paved surface of a road that impedes driving Road Repair Tracking System Software Requirements Specification The number of reports required about a pothole before it will be inspected. To be determined by the DoPS. 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. CS 3610 Team 7 Page 1

4 2. Overall Project Description The Road Repair Tracking System is designed for the city of SmallTown. The budget and capabilities of the DoPS will determine the size and scope of the system. 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 Whitten, Bentley, and Dittman. Submit Pothole Report Upload Photo Report Damages <<extend>> View Pothole Report(s) <<extend>> Citizen Issue/Deny Work Order <<extend>> Inspector View Work Order <<extend>> <<extend>> Sign Off On Order / Re-assign Order <<extend>> Complete Work Order / Final Report Login/Logout View Statistics / Analytics Work Crew Maintain System (add work crew, etc.) System Administrator Figure 1 Use-Case Diagram CS 3610 Team 7 Page 2

5 Use 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 DoPS using the RRTS. Use case name: Enter Pothole Information ID: 1 Priority: Medium Primary actor: DoPS Source: Citizens Use case type: Technical Interested Stakeholders: SmallTown Citizens Will benefit from the repair of potholes in SmallTown Work Crews Will benefit from new jobs Brief description: The purpose of this use-case is to, as a citizen of SmallTown, report potholes encountered around SmallTown. Additionally, images and damages can be provided as well. Precondition: Trigger: A SmallTown citizen encounters a pothole and chooses to report it. Relationships: Include: Extend: Use-Case ID 2 Typical flow of events: 1. The citizen accesses the front end website by loading the address in an internet browser. 2. The citizen enters information into the porthole report fields in order to describe the encountered pothole. 2a. Optional The citizen may upload a photo of the pothole. 2b. Optional The citizen may fill in the damage report fields to report damages caused by the potholes. 3. The citizen submits the report. Assumptions Assume that the citizen reporting the pothole in fact came in contact with a valid pothole. Implementation Constraints and Specifications: -The pothole reported must be reported on a valid street within the city limits of SmallTown. -While a user/ip can report on as many potholes as he or she encounters, the user/ip can only report on any particular pothole once. Table 1 Use-Case 1 CS 3610 Team 7 Page 3

6 Use 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. Use case name: Verify Pothole Information ID: 2 Priority: High Primary actor: DoPS Source: Pothole Report Use case type: Technical Interested Stakeholders: SmallTown Citizens Will benefit from the repair of potholes in SmallTown Brief description: The purpose of this use case is to supply the DoPS inspector with information pertaining to a particular pothole ID so that the inspector can visit the pothole site in order to verify the accuracy of the reported information and determine if a work order should be issued. Precondition: Use-Case ID 1 must have been executed X number of times about a particular pothole, where the value of X is to be determined by the DoPS. Trigger: When the precondition is met, the system will automatically notify the inspector that a pothole needs to be inspected. Relationships: Include: Extend: Use-Case ID 3 Typical flow of events: 1. The inspector accesses the back end website by loading the address in an internet browser. 2. The inspector enters his login credentials and logs in. 2a. The username and/or password do not match the system information. Login is rejected. 3. The inspector chooses to view the compiled report about the pothole needing inspection. 3a. Optional The inspector may view the individual reports submitted about the pothole. 4. The inspector prints the compiled pothole report in order to visit the pothole site. 5. The inspector logs out. Assumptions Implementation Constraints and Specifications: Table 2 Use-Case 2 CS 3610 Team 7 Page 4

7 Use 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. Use case name: Authorize Pothole Information ID: 3 Priority: Medium Primary actor: Work Crew Source: Inspector Use case type: Business Interested Stakeholders: SmallTown Citizens Will benefit from the repair of potholes in SmallTown DoPS Work orders are being created to repair the potholes Brief description: 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. Precondition: Use-Case ID 2 must have occurred. There must be a pothole that needs to be inspected. Trigger: The inspector visits the site to verify the accuracy of the pothole report. Relationships: Include: Extend: Use-Case 4 Typical flow of events: 1. The inspector accesses the back end website by loading the address in an internet browser. 2. The inspector enters his login credentials and logs in. 2a. The username and/or password do not match the system information. Login is rejected. 3. The inspector chooses to view the compiled report about the pothole needing inspection. 3a. Optional The inspector may view the individual reports submitted about the pothole. 4. The inspector authorizes a work order to be issued to repair the pothole. 4a. The inspector may alternatively choose to deny a work order for the pothole repair. 5. The inspector logs out. Assumptions Assume that the inspector has actually visited the site of the pothole to verify the accuracy of the report. Implementation Constraints and Specifications: The budget of the DoPS will dictate whether or not many potholes will be repaired. Assuming a relatively unlimited DoPS budget, any and all potholes can be repaired, however with a limited budget, only a certain number of potholes will be able to be repaired, therefore constraining how many and which potholes a work order can be issued for. Table 3 Use-Case 3 CS 3610 Team 7 Page 5

8 Use 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. Use case name: Retrieve Work Order ID: 4 Priority: Medium Primary actor: Work Crew Source: Work Order Use case type: Technical Interested Stakeholders: SmallTown Citizens Will benefit from the repair of potholes in SmallTown DoPS Work orders are being retrieved so that potholes can be repaired Brief description: The purpose of this use-case is to supply the work crew with the information pertaining to their work order. Precondition: Use-Case ID 3 must have occurred. A work order must have been issued to a work crew. Alternatively, Use- Case 6 may have occurred where the inspector has chosen to re-assign a poorly repaired pothole. Trigger: 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. Relationships: Include: Extend: Use-Case ID 5 Typical flow of events: 1. The work crew accesses the back end website by loading the address in an internet browser. 2. The work crew enters its login credentials and logs in. 2a. The username and/or password do not match the system information. Login is rejected. 3. The work crew chooses to view the work order. 4. The work crew prints the work order in order to begin work on the repairs. 5. The work crew logs out. Assumptions Assume that all crews in the system available for work have the personnel and equipment capable of repairing potholes. Implementation Constraints and Specifications: Table 4 Use-Case 4 CS 3610 Team 7 Page 6

9 Use 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. Use case name: Finalize Work Order ID: 5 Priority: Medium Primary actor: DoPS Source: Work Crew Use case type: Technical Interested Stakeholders: SmallTown Citizens Will benefit from the repair of potholes in SmallTown Brief description: 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. Precondition: Use-Case ID 4 must have occurred. Trigger: The work crew has complete the repair. Relationships: Include: Extend: Use-Case ID 6 Typical flow of events: 1. The work crew accesses the back end website by loading the address in an internet browser. 2. The work crew enters its login credentials and logs in. 2a. The username and/or password do not match the system information. Login is rejected. 3. The work crew chooses to view the work order. 4. The work crew fills in a final report regarding the completion of work order, including items such as cost of repair and any outstanding issues. 5. The work crew submits the final report. 6. The work crew logs out. Assumptions Assume that the work crew has actually repaired the pothole. Implementation Constraints and Specifications: Table 5 Use-Case 5 CS 3610 Team 7 Page 7

10 Use Case 6 Re-inspect Pothole After Repair: After the work order has been completed and the work crew has submitted its final report, the inspector must re-inspect the site to verify the quality of repair. Use case name: Re-inspect Pothole After Repair ID: 6 Priority: Medium Primary actor: DoPS Source: Work Order Use case type: Business Interested Stakeholders: SmallTown Citizens Will benefit from the repair of potholes in SmallTown Work Crew Will benefit from knowing whether or not their repair is satisfactory to the DoPS or whether or not it will require further work. Brief description: After inspecting the pothole site, the inspector will submit a report verifying the repair and commenting on the quality of work. If the repair is not satisfactory, the work order will be resubmitted for further repair. Precondition: Use-Case ID 5 must have occurred. Trigger: The work crew of a work order has submitted its final report declaring the pothole repaired. Relationships: Include: Extend: Use-Case ID 4 Typical flow of events: 1. The inspector accesses the back end website by loading the address in an internet browser. 2. The inspector enters his login credentials and logs in. 2a. The username and/or password do not match the system information. Login is rejected. 3. The inspector chooses to view the work order marked as complete. 4. The inspector marks the order as officially complete as per the DoPS. 4a. The inspector may mark the work order as incomplete, resubmitting the order to the system to be re-assigned to a work crew. 5. The inspector logs out. Assumptions Assume that the inspector has in fact visited the site of the repaired pothole and completed his inspection. Implementation Constraints and Specifications: Table 6 Use-Case 6 CS 3610 Team 7 Page 8

11 Use Case 7 Access System Information: The system administrator will have complete access to all information within the system database. Will full access, the system admin can retrieve various statistics, analytics, and other aggregated data as well as perform any necessary maintenance. Use case name: Access System Information ID: 7 Priority: Low Primary actor: DoPS Source: System Administrator Use case type: Technical Interested Stakeholders: Brief description: The purpose of this use-case is for the system administrator to access any information or perform any system maintenance as is necessary. Precondition: Trigger: Relationships: Include: Extend: Typical flow of events: 1. The system administrator accesses the back end website by loading the address in an internet browser. 2. The inspector enters his login credentials and logs in. 2a. The username and/or password do not match the system information. Login is rejected. 3. The system administrator can access, view, and maintain any and all information in the system. 3a. The system administrator can view individual and compiles pothole reports. 3b. The system administrator can view open and close work orders. 3c. The system administrator can add, remove, or maintain work crews. 3d. The system administrator can view statistics and analytics (repairs, costs, damages, etc.). 4. The system administrator logs out. Assumptions Implementation Constraints and Specifications: Table 7 Use-Case 7 CS 3610 Team 7 Page 9

12 2.2 Assumptions and Dependencies -Potholes reported must be compared to a map or list of roads in SmallTown. Only potholes within the city limits of SmallTown can be reported. -At least X number of reports must be filed about a single pothole before the inspector is notified. This will allow for a more accurate average size and severity. -A single user/ip may only report on a particular pothole once, but can report on multiple, distinct potholes. -Assume that the DoPS budget is infinite as constraints were not supplied. Therefore, any and all potholes can be repaired instead of only those that fit within a budget. -Assume that all citizens have or can obtain access to the internet in order to submit a report. -Assume that all on-site activities are in fact attended to and completed. [i.e. pothole inspection, pothole repair, pothole re-inspection] 3. Specific Requirements 3.1 Classes/Objects Citizen -Name -IP Pothole Map Submits Consists Of -ID -Road -Cross Road -Damages -Damages Description -Pothole Is Inspected -Pothole Is Repaired -Pothole Is Re-Inspected Reads From -Roads +Check Road Database Reads From Pothole Report -Username -IP -Road -Cross Road -Damages -Damages Description -Image +Check User +Check For Number Of Reports Reads From +Read from Database +Write to Database Reads From Work Order -ID -Crew -Work Order Is Complete -Repair Is Inspected +Mark As Complete +Mark As Re-Inspected View Report Issue / View Work Order View Order / Submit Report DoPS Personnel -Employee Name -Date of Hire -Is User Admin -Username -Password +Set User As Admin +Change Password Logs In Login Protocol +Check User +Check Password Figure 2 Class Diagram Logs In Work Crew -ID -Crew -Work Order Is Complete -Repair Is Inspected +Assign Order CS 3610 Team 7 Page 10

13 Class name: Citizen Brief description: This class establishes the object of a citizen of SmallTown Attributes (fields) Name IP Methods (operations) Attribute Description The citizen s name The citizen s IP Method Description Table 8 Class Citizen Class name: Database Brief description: This class establishes a connection to the database and reads and writes to and from the database. Attributes (fields) Attribute Description Methods (operations) Method Description Read from Database This method executes a query to read information from the database Write to Database This method executes a query to write information to the database Table 9 Class Database Class name: DoPS Personnel Brief description: This class establishes the object of a DoPS employee. Attributes (fields) Employee Name Date of Hire Is User Admin Username Password Methods (operations) Set User As Admin Change Password Attribute Description Employee s name Date the employee was hired Is employee admin status Employee s login username Employee s login password Method Description This method grants the user admin privileges This method changes the user s password Table 10 Class DoPS Persoel Class name: Login Protocol Brief description: This class authenticates a user s login. Attributes (fields) Attribute Description Methods (operations) Method Description Check User This method checks if the supplied username is a valid username Check Password This method verifies if the password corresponding to the supplied username is valid Table 11 Class Login Protocol CS 3610 Team 7 Page 11

14 Class name: Map Brief description: This class contains and establishes the boundaries of the city limits of SmallTown. Attributes (fields) Attribute Description Roads List of roads within SmallTown city limits Methods (operations) Method Description Check Road This method checks if the road of a reported pothole is within SmallTown city limits Table 12 Class Map Class name: Pothole Brief description: This class establishes the object pothole containing all related properties. Attributes (fields) Attribute Description ID The ID number assigned to the pothole Road The road that the pothole is located on Cross Road The nearest intersection/cross road to the pothole Damages The array of monetary damages reported on the pothole Damages Description The array of damages descriptions reported on the pothole Pothole Is Inspected Whether or not the pothole has had its initial inspection Pothole Is Repaired Whether or not the pothole has been repaired by a work crew Pothole Is Re-Inspected Whether or not the pothole has been re-inspected Methods (operations) Method Description Table 13 Class Pothole Class name: Pothole Report Brief description: This class establishes the pothole report that citizens submit on potholes throughout SmallTown. Attributes (fields) Attribute Description Username The name of the citizen submitting the report IP The IP address of the citizen submitting the report Road The road that the pothole is located on Cross Road The nearest intersection/cross road to the pothole Damages The monetary value in damages reported by the citizen Damages Description The description of reported damages Image The location of an option image, if uploaded Methods (operations) Method Description Check User This method determines if the user/ip has previously submitted a report on the particular pothole Check For Number Of Reports This method checks if the report reaches the number of reports on a pothole need to meet the required value for inspection Table 14 Class Pothole Report CS 3610 Team 7 Page 12

15 Class name: Work Crew Brief description: This class establishes the work crew object and holds the information concerning each work crew. Attributes (fields) Attribute Description ID The ID assigned to the work crew Total Jobs The total number of jobs assigned to the work crew Positive Jobs The number of completed jobs approved by DoPS Negative Jobs The number of completed jobs disapproved by DoPS Rating The overall approval rating of the work crew Current Work Order The current work order, if any, assigned to the work crew Methods (operations) Assign Order Method Description This method assigns a work order to the work crew Table 15 Class Work Crew Class name: Work Order Brief description: This class establishes the work order about repairing a pothole by a work crew Attributes (fields) ID Crew Work Order Is Complete Repair Is Inspected Attribute Description The ID assigned to the work order The ID of the crew assigned to the work order The state of the order complete or incomplete The state of DoPS final inspection Methods (operations) Mark As Complete Mark As Re-Inspected Method Description This method marks the work order as complete by the work crew This method marks the work order as inspected by the inspector Table 16 Class Work Order CS 3610 Team 7 Page 13

16 3.2 Object Collaboration Diagrams 1:N Citizen 1:1 Map Submits Consists Of 1:N Pothole Reads From 1:1 M:N 1:1 M:N Pothole Report N:1 1:N 1:1 Reads From Database 1:N Reads From M:N 1:1 Reads From Work Order N:1 Issue / View Work Order View Report M:N View Order / Submit Report 1:1 1:N DoPS Personnel Logs In Login Protocol Logs In Work Crew 1:N N:1 1:N 1:N N:1 Figure 3 Collaboration Diagram CS 3610 Team 7 Page 14

17 3.3 Sequence Diagrams Citizen Pothole Report Database Pothole Submit Report Error Message: Already Reported Check User User Has Submitted Report On This Pothole User Has Not Submitted Report On This Pothole Check For Pothole Pothole Exists Add Report To Pohtole Pothole Does Not Exist Create Pothole And Add Report Figure 4 Sequence Diagram 1 CS 3610 Team 7 Page 15

18 Inspector Login Protocol Pothole Report Pothole Database Login Verify User/Pass Verified Login Successful View Report Compile Statistics Request Information Retrieve Information Display Statistics Login Failed Not Verified Retry Figure 5 Sequence Diagram 2 CS 3610 Team 7 Page 16

19 Inspector Login Protocol Pothole Report Pothole Database Login Verify User/Pass Verified Login Successful View Report Compile Statistics Request Information Retrieve Information Display Statistics Issue Work Order Login Failed Not Verified Retry Figure 6 Sequence Diagram 3 CS 3610 Team 7 Page 17

20 Work Crew Login Protocol Work Order Database Login Verify User/Pass Verified Login Successful View Work Order Request Information Return Information Login Failed Not Verified Retry Figure 7 Sequence Diagram 4 CS 3610 Team 7 Page 18

21 Work Crew Login Protocol Work Order Database Login Verify User/Pass Verified Login Successful View Work Order Request Information Return Information Submit Final Report Login Failed Not Verified Retry Figure 8 Sequence Diagram 5 CS 3610 Team 7 Page 19

22 Inspector Login Protocol Work Order Database Login Verify User/Pass Verified Login Successful View Work Order Request Information Return Information Re-assign Order Submit Final Inspection Login Failed Not Verified Retry Figure 9 Sequence Diagram 6 CS 3610 Team 7 Page 20

23 System Administrator Login Protocol System Information Database Login Verify User/Pass Verified Login Successful View Any System Information Request Information Return Information Update DB Information Not Verified Login Failed Retry Figure 10 Sequence Diagram 7 CS 3610 Team 7 Page 21

24 3.4 Object Behavior Diagrams Add / Remove Work Crew Add / Remove Administrator Admin Logout Admin Screen View Statistics / Analytics Work Crew Login Info If Admin: Login Valid Logout Inspector Login Info Login Screen Validate User and Pass Request / Retrieve Information Database Request / Retrieve Information System Admin Login Info If Inspector / Work Crew: Login Valid Inspector / Work Crew Logout Home Screen Inspector View Report Pothole Inspector / Crew View Order Create Work Order Pothole Report Compile Report Work Order Final Report After Repair Re-inspect After Repair Citizen Reports Pothole Figure 11 Object Behavior Diagram 3.5 Performance Requirements 1. Capacity The system must be capable of supporting simultaneous connections without supporting performance loss. The system must be capable of supporting a minimum of 100 simultaneous connections. 2. Response Time The system must retrieve data and load pages within a reasonable amount of time. The load time must be within 20 seconds. 3.6 Other Requirements 1. Information Security When citizens report a pothole, information on the citizen is saved in the database including first and last name as well as the IP address. Additionally, if the citizen chooses to report damages, additional information such as address, phone number, damages, as well as make and model of car will also be stored in the database. This information must be kept secure from outside intrusion. 2. Data Backup The database contains not only the history of pothole repairs but also existing reports and open work orders that represent contracts with contracted work crews. Consequently, backing up the database on a regular basis (daily), is necessary. 4. Supporting Information CS 3610 Team 7 Page 22