Use Case Statement
By
Manuel Dennis III
Name |
Manage Request Status Section |
Description |
Display a panel of status information related to a Request |
Dependencies |
A Request must exist |
Scope |
Display a panel which contains the current Request status Also display a grid of previous Request states |
Primary Actors |
|
Secondary Actors |
|
Pre Conditions |
|
Success End Conditions |
|
Failure End Conditions |
Document Revision # |
Action Taken, Notes |
When? |
By Whom? |
0.1 |
|
|
|
Use Case
# |
Action / Stimulus |
Reaction |
1 |
The user navigates to the Request |
The system displays a panel specifically for Tracked Request Status |
2 |
The current state should be displayed predominately, previous states should be displayed in a grid |
|
3 |
A grid of previous Request states should be displayed in most recent date order. The grid should have the following fields: Status, Who (Person who created the Status), When (Date the status was changed), and a comment about the change if one is necessary |
|
4 |
User can change the Request state by pressing a particular button |
The system reacts to these button presses to add the appropriate Request status and any supporting information related to the state change |
Alternative / Additional Scenario: Status Buttons
# |
Action / Stimulus |
Reaction |
A1 |
User presses Approve button |
An approver can press the Approve button A means of entering a comment. Simple grid edit may suffice. The date should not be editable since the Approval is taking place at the time the Approve button is pressed. |
A2 |
Approver or Assigner presses Wish List button |
This puts the request in a temporary state that means it isn’t cancelled, but it doesn’t need to be assigned at this point in time. |
A3 |
Assigner or Approver presses Cancel button |
Only an assigner or approver should cancel a task. Cancel doesn’t delete the task; it simply places the request into a Cancelled state. Other users may need to be notified, especially the requester and assigned worker. |
A4 |
Assigner presses the Complete button |
An assigner should press the complete button to indicate that they believe the assignments to be completed by the workers. The Assigner should be notified when all assignments reach a completed state, so she may assert that the Request has been completed. |
Alternative / Additional Scenario:
# |
Action / Stimulus |
Reaction |
B1 |
User Presses the Status History button |
This can toggle the visibility of the buttons related to the status history including the grid. This can allow someone to print an Request from the browser with just including the current status. |
B2 |
||
B3 |
Alternative / Additional Scenario: Cancel
# |
Action / Stimulus |
Reaction |
C1 |
||
Notes:
Issues: