Cs 3610 Software Engineering Summer Software Requirements Specification Document Project Title Road Repair Tracking System

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
Table of Contents
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
4. Supporting Information 22
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.
CS 3610 | Team 7 Page 1

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 <<extend>> View Pothole Report(s)
Report Damages
<<extend>>
Issue/Deny Work Order

Citizen
Inspector
<<extend>>
View Work Order

<<extend>>
Sign Off On Order /

Re-assign Order
<<extend>>
<<extend>>
Complete Work Order /

Final Report
Login/Logout
View
Statistics / Analytics
Maintain System System Administrator

Work Crew (add work crew, etc.)
Figure 1 – Use-Case Diagram

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.
Table 1 – Use-Case 1

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
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
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
None

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
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
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.
Assumptions
Assume that the inspector has actually visited the site of the pothole to verify the accuracy of the report.
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.

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
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: None
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.
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.
None

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

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
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
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.
Assumptions
Assume that the inspector has in fact visited the site of the repaired pothole and completed his inspection.
None

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
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
1. The system administrator accesses the back end website by loading the address in an internet browser.
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
None

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 Pothole
-IP Map
-ID -Roads
Reads From
-Road
+Check Road
-Cross Road
-Damages
Consists Of
-Damages Description
-Pothole Is Inspected
Submits
-Pothole Is Repaired
-Pothole Is Re-Inspected
Database
Reads From
Reads From
Pothole Report +Read from Database
+Write to Database
-Username
-IP
-Road Work Order
-Cross Road
-Damages Reads From -ID
-Damages Description -Crew
-Image -Work Order Is Complete
-Repair Is Inspected
+Check User
+Check For Number Of Reports +Mark As Complete
+Mark As Re-Inspected
View Order /
Issue / View
Submit Report
Work Order
View Report
Work Crew
DoPS Personnel Logs In
Login Protocol
Logs In -ID
-Employee Name -Crew
-Date of Hire +Check User -Work Order Is Complete
-Is User Admin +Check Password -Repair Is Inspected
-Username +Assign Order
-Password
+Set User As Admin
+Change Password
Figure 2 – Class Diagram

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
Table 11 – Class Login Protocol

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
Table 14 – Class Pothole Report

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
Table 16 – Class Work Order

3.2 Object Collaboration Diagrams
Citizen
1:N
Map
1:1
Reads From
Pothole
1:N
Submits
Consists Of
1:1
M:N
1:1
Pothole Report 1:1 Database

M:N 1:N Reads From
N:1 Reads From 1:N
1:1
M:N
N:1
Reads From
Work Order
Issue / View
Work Order
View Report
M:N
View Order /
Submit Report
1:1
1:N
DoPS Personnel Logs In Login Protocol Work Crew

Logs In
1:N N:1 1:N 1:N N:1
Figure 3 –Collaboration Diagram

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
Figure 4 – Sequence Diagram 1

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

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

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

Work Crew Login Protocol Work Order Database
Login
Verify User/Pass
Verified
Login Successful
View Work Order
Request Information
Return Information
Submit Final Report
Not Verified
Login Failed
Retry

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

System
Login Protocol System Information Database
Administrator
Login
Verify User/Pass
Verified
Login Successful
View Any
System Information
Request Information
Return Information
Update DB Information
Not Verified
Login Failed
Retry

3.4 Object Behavior Diagrams
Add / Remove
Work Crew
Add / Remove
Administrator
View
Admin
Admin Screen Statistics /
Logout
Analytics
If Admin:
Work Crew
Login Valid
Login Info
Request / Retrieve Request / Retrieve

Inspector Validate Information Information
Logout Login Screen Database
Login Info User and Pass
System Admin
Login Info If Inspector / Work Crew:
Login Valid
Inspector / Work Crew Inspector

Home Screen Pothole
Logout View Report
Compile
Pothole Report
Report
Inspector / Crew Create
View Order Work Order
Work Order
Citizen
Final Report Re-inspect Reports Pothole
After Repair 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.
4. Supporting Information
None

Cs 3610 Software Engineering Summer Software Requirements Specification Document Project Title Road Repair Tracking System

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cs 3610 Software Engineering Summer Software Requirements Specification Document Project Title Road Repair Tracking System

Uploaded by

Copyright:

Available Formats

CS 3610: Software Engineering

Software Requirements Specification Document

Road Repair Tracking System

CS 3610 | Team 7 Page 1

Submit Pothole Report

Issue/Deny Work Order

View Work Order

Sign Off On Order /

Complete Work Order /

Maintain System System Administrator

Figure 1 – Use-Case Diagram

CS 3610 | Team 7 Page 2

Use case name: Enter Pothole Information ID: 1 Priority: Medium

CS 3610 | Team 7 Page 3

Use case name: Verify Pothole Information ID: 2 Priority: High

CS 3610 | Team 7 Page 4

Use case name: Authorize Pothole Information ID: 3 Priority: Medium

CS 3610 | Team 7 Page 5

Use case name: Retrieve Work Order ID: 4 Priority: Medium

CS 3610 | Team 7 Page 6

Use case name: Finalize Work Order ID: 5 Priority: Medium

CS 3610 | Team 7 Page 7

CS 3610 | Team 7 Page 8

Use case name: Access System Information ID: 7 Priority: Low

CS 3610 | Team 7 Page 9

Figure 2 – Class Diagram

CS 3610 | Team 7 Page 10

Class name: Database

Class name: DoPS Personnel

Class name: Login Protocol

CS 3610 | Team 7 Page 11

Class name: Pothole

Class name: Pothole Report

CS 3610 | Team 7 Page 12

Class name: Work Order

Methods (operations) Method Description

CS 3610 | Team 7 Page 13

Pothole Report 1:1 Database

N:1 Reads From 1:N

DoPS Personnel Logs In Login Protocol Work Crew

Figure 3 –Collaboration Diagram

CS 3610 | Team 7 Page 14

Citizen Pothole Report Database Pothole

Check For Pothole

Add Report To Pohtole

Pothole Does Not Exist

Create Pothole And Add Report

Figure 4 – Sequence Diagram 1

CS 3610 | Team 7 Page 15

Figure 5 – Sequence Diagram 2

CS 3610 | Team 7 Page 16

Issue Work Order

Figure 6 – Sequence Diagram 3

CS 3610 | Team 7 Page 17

View Work Order

Figure 7 – Sequence Diagram 4

CS 3610 | Team 7 Page 18

View Work Order

Submit Final Report

Figure 8 – Sequence Diagram 5

CS 3610 | Team 7 Page 19

View Work Order

Submit Final Inspection

Figure 9 – Sequence Diagram 6