R-PMS System Use Cases : Model . R-PMS System - Q4 : System
Use Case - T10-04 Prepare for Alignment changes/Distance changes link
Properties |
Name | Value | ||||||||
Description |
Determine if there are any changes to the District Alignments due to ongoing projects and GIS changes and record them in the PMS geometry data as well as the KHUB geometry data. |
||||||||
Transit From |
|
||||||||
Id | UC88 | ||||||||
Abstract | false | ||||||||
Leaf | false | ||||||||
Root | false | ||||||||
Stereotypes | PMS Activity | ||||||||
Business Model | false | ||||||||
Status | Identify | ||||||||
Rank | Unspecified |
Relationships Summary |
Name | Begin | End | |||
|
|
|
Use Case Note |
■ Workflow | |||
• // Write down briefly how user perform the work | |||
• Talk with Planning to determine alignment changes | |||
• Routes that are on or off the system | |||
• Anything that would cause a network change | |||
• This is based upon a Resolution that is derived from the Secretary at the top | |||
• Specifics of the changes are captured in the Resolution and provided to PMS via Planning | |||
■ Business Logic | |||
• // Write down what user expect the system to react upon certain condition (e.g. low inventory alert level) | |||
• | |||
■ Decisions | |||
• // Write down the decisions made during the meeting (e.g. Must allow accessing from mobile devices) | |||
• Ideally Planning would capture the details of the Resolution into a dataset which would then be "triggered" and implemented in the Planning Network as Resolution Routes | |||
• Current process | |||
♦ If the route is early enough in the year such that Scanning can collect the data on the new route then this activity should be done in January prior to collection but if the route is unknown and/or not ready then this is captured at this time in the year | |||
♦ Estimated lengths are based upon last years driving or based upon estimated lengths from plans | |||
• Desired process | |||
♦ Lengths would then be known | |||
♦ Routes would be known as open or closed for collection via the completed Rehab form | |||
■ Follow-up | |||
• // Write down the items that should follow-up in the coming meeting | |||
• |
PMS Current |
Steps | |||
1. ![]() ![]() |
|||
1.1. Routes that are on or off the system | |||
1.2. Anything that would cause a network change | |||
1.3. This is based upon a Resolution that is technically derived from the Secretary at the top | |||
1.4. Specifics of the changes are captured in the Resolution and provided to PMS via Planning | |||
1.5. if route is early enough in the year | |||
1.5.1. ![]() |
|||
1.5.2. ![]() |
|||
1.5.3. Estimated lengths are then based upon last years driving | |||
1.6. else | |||
1.6.1. The route is otherwise uncollected then reconciliation between networks occurs in this Use Case | |||
1.6.2. Estimated Lengths are then based upon estimated lengths from plans | |||
end if | |||
1.7. |
R-PMS Desired |
Steps | |||
1. ![]() |
|||
1.1. The Resolution triggers implementation of the Resolution Data describing the Planning Changes as Resolution Routes | |||
2. SYSTEM Automatically captures Resolution Route modifications as part of KHUB-PMS reconciliation in January | |||
2.1. Estimated Lengths are NOT calculated as Actual Lengths are known | |||
2.2. Routes are defined as Open or Closed for collection via the completed Rehab form |
Tagged Values |
Name | Type | Value | |||
Level | Ad Hoc Enumeration | User | |||
Complexity | Ad Hoc Enumeration | High | |||
Use Case Status | Ad Hoc Enumeration | Initial | |||
Preconditions | Multi-line Text | ||||
Post-conditions | Multi-line Text | ||||
Author | Text | Kristy Rizek and Jerry W. Manweiler, Ph.D. | |||
Assumptions | Multi-line Text |
References |
File Name | Description | ||
|
|||
|
|||
|
|||
|
Relationships Detail |
Name | Value | ||
Name | |||
From |
|
||
To |
|
||
Visibility | Unspecified | ||
Stereotypes | Include |
Appears In |
Diagram | |||
|