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

· Assigner, Worker, Approver

Secondary Actors

· Administrator, Requester

Pre Conditions

· A Request must exist

Success End Conditions

· A Request must have a state and the proper state must be coming from the Tracked Request Status table

Failure End Conditions

· The information related to the Request state is inaccurate or incorrect

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: