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

(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

(2)

1. Introduction

1 1.1 Purpose

1 1.2 Scope

1 1.3 Definitions, Acronyms, and Abbreviations

1 1.4 References

1 1.5 Overview

1 2. Overall Description

2 2. 1 Use-Case Model Survey

2 2.2 Assumptions and Dependencies

10 3. Specific Requirements

10 3.1 Classes/Objects

10 3.2 Object Collaboration Diagrams

14 3.3 Sequence Diagrams

15 3.4 Object Behavior Diagrams

22 3.5 Performance Requirements

22 3.6 Other Requirements

22

(3)

CS 3610 | Team 7 Page 1

Software Requirements Specification

1. Introduction

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.

1.1 Purpose

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.

1.2 Scope

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 Department of Public Safety (of SmallTown)

Inspector DoPS employee responsible for inspecting pothole sites

Pothole Any damaged portion of the paved surface of a road that impedes driving

RRTS Road Repair Tracking System

SRS Software Requirements Specification

X (value of) The number of reports required about a pothole before it will be inspected. To be determined by the DoPS.

1.4 References

None

1.5 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.

(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.

Citizen

Work Crew

System Administrator Login/Logout

View Pothole Report(s)

View Work Order

Issue/Deny Work Order <<extend>> Submit Pothole Report

Upload Photo Report Damages

<<extend>>

Complete Work Order / Final Report

<<extend>>

Sign Off On Order / Re-assign Order <<extend>>

<<extend>>

Maintain System (add work crew, etc.)

View Statistics / Analytics

Inspector

(5)

CS 3610 | Team 7 Page 3 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:

None

Trigger:

A SmallTown citizen encounters a pothole and chooses to report it.

Relationships:

Include:

None

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.

(6)

CS 3610 | Team 7 Page 4 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:

None

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

None

Implementation Constraints and Specifications:

None

(7)

CS 3610 | Team 7 Page 5 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:

None

Extend:

Use-Case 4

Typical flow of events:

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.

(8)

CS 3610 | Team 7 Page 6 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:

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:

None

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:

None

(9)

CS 3610 | Team 7 Page 7 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:

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:

None

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:

None

(10)

CS 3610 | Team 7 Page 8 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:

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:

None

Extend:

Use-Case ID 4

Typical flow of events:

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:

None

(11)

CS 3610 | Team 7 Page 9 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:

SystemAdministrator

Use case type:

Technical

Interested Stakeholders:

None

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:

None

Trigger:

None

Relationships:

Include:

None

Extend:

None

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

None

Implementation Constraints and Specifications:

None

(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 Report -Username -IP -Road -Cross Road -Damages -Damages Description -Image +Check User

+Check For Number Of Reports

Pothole -ID -Road -Cross Road -Damages -Damages Description -Pothole Is Inspected -Pothole Is Repaired -Pothole Is Re-Inspected Database

+Read from Database +Write to Database

DoPS Personnel

-Employee Name -Date of Hire -Is User Admin -Username -Password +Set User As Admin +Change Password Map -Roads +Check Road Work Order -ID -Crew

-Work Order Is Complete -Repair Is Inspected +Mark As Complete +Mark As Re-Inspected Login Protocol +Check User +Check Password Work Crew -ID -Crew

-Work Order Is Complete -Repair Is Inspected +Assign Order Submits Reads From Reads From Reads From Consists Of Reads From View Order / Submit Report View Report Logs In _{Logs In} Issue / View Work Order

(13)

Class name: Citizen

Brief description: This class establishes the object of a citizen of SmallTown

Attributes (fields) Attribute Description

Name The citizen’s name

IP The citizen’s IP

Methods (operations) 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.

… …

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.

Employee Name Employee’s name

Date of Hire Date the employee was hired

Is User Admin Is employee admin status

Username Employee’s login username

Password Employee’s login password

Set User As Admin This method grants the user admin privileges

Change Password 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.

. . . . . .

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

(14)

Class name: Map

Brief description: This class contains and establishes the boundaries of the city limits of

SmallTown.

Roads List of roads within SmallTown city limits

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.

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

. . . . . .

Table 13 – Class Pothole Class name: Pothole Report

Brief description: This class establishes the pothole report that citizens submit on potholes

throughout SmallTown.

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

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

(15)

Class name: Work Crew

Brief description: This class establishes the work crew object and holds the information concerning

each work crew.

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

Assign Order 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

ID The ID assigned to the work order

Crew The ID of the crew assigned to the work order

Work Order Is Complete The state of the order – complete or incomplete Repair Is Inspected The state of DoPS final inspection

Mark As Complete This method marks the work order as complete by the work crew Mark As Re-Inspected This method marks the work order as inspected by the inspector

(16)

3.2 Object Collaboration Diagrams

Citizen Pothole Report Pothole Database DoPS Personnel Map Work Order

Login Protocol Work Crew

Submits Reads From Reads From Reads From Consists Of Reads From View Order / Submit Report View Report Logs In _{Logs In} Issue / View Work Order 1:N M:N 1:N M:N 1:1 1:1 1:N N:1 M:N 1:N 1:N N:1 1:N N:1 1:N M:N 1:1 N:1 1:1 1:N 1:1 1:1

(17)

3.3 Sequence Diagrams

Citizen

Pothole Report

Database

Pothole

Submit Report

Check User User Has Submitted Report On This Pothole Error Message:

Already Reported

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

(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 Not Verified Login Failed Retry

(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 Not Verified Login Failed Retry

Issue Work Order

(20)

Work Crew

Login Protocol

Work Order

Database

Login

Verify User/Pass Verified Login Successful

View Work Order

Request Information Return Information

Not Verified Login Failed

Retry

(21)

Work Crew

Login Protocol

Work Order

Database

Login

View Work Order

Request Information Return Information

Not Verified Login Failed

Retry

Submit Final Report

(22)

Inspector

Login Protocol

Work Order

Database

Login

View Work Order

Request Information Return Information Not Verified Login Failed Retry Re-assign Order Submit Final Inspection

(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

(24)

3.4 Object Behavior Diagrams

Work Order Add / Remove Administrator Pothole Database Pothole Report Add / Remove Work Crew View Statistics / Analytics Login Screen Admin Screen Logout Home Screen Validate User and Pass Admin

Logout

Inspector / Work Crew Logout Inspector Login Info System Admin Login Info Work Crew Login Info If Admin: Login Valid

If Inspector / Work Crew: Login Valid Inspector / Crew View Order Final Report After Repair Compile Report Citizen Reports Pothole Inspector View Report Create Work Order Request / Retrieve Information Request / Retrieve Information Re-inspect After Repair

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.

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