Experts in global web software development

Taskjitsu - Developer Documentation

Top-Level Use Cases

THE SYSTEM

The System integrates three different areas of functionality:

  1. Timesheet data
  2. Task Tracking
  3. Report and Billing Generation

ACTORS

Actor: everyone who has a user account in the system
Responsibilities:

Worker: everyone in the Enterprise who keeps a timesheet.
Extends: Actor
Responsibilities:

Task Worker
Extends: Actor
Responsibilities:

Project Coordinator
Extends: Task Worker
Responsibilities:

Project Manager
Extends: Project Coordinator
Responsibilities:

Data Administrator
Extends: Actor
Responsibilities:

Customer
Extends: Actor
Responsibilities:

Use Cases by Actor

Actor Login
Logout
Worker Actor Role
Update Timesheet
View Timesheet Summary
Task worker Actor Role
Search Tasks
Update Task
Update Task Status to an Open State
Add Task
Add Task Notes
Receive Email Notification
Project Coordinator Task Worker Role
Update State to a Closed State
Assign Task
Project Manager Project Coordinator Role
Approve Timesheet
Produce Billing
Analyze Metrics
Update Task
Update State
Data Administrator Actor Role
Maintain Projects
Maintain Activities
Maintain Users
Maintain Workers
Customer Actor Role
Review Tasks
Create Tasks

USE CASES

USE CASE: Login
USER GOAL: Enter the System

MAIN FLOW OF EVENTS:
The use case starts when the Actor provides a user name and password to a login screen accessible from a public web page. If the user name and password are correct, the Actor is taken to a protected web page where the other functions of the site are available.

The system recognizes the permissions that each Actor has within the system and presents each Worker with a screen of options leading to those sections of the web interface.
END

CURRENT IMPLEMENTATION:
Web interface is currently password-protected using standard J2EE methods in conjunction with Tomcat's database-driven auth module. SSH login to database server needed to access MS Access interface. Login is required to Intranet to access the web interface.

EXCEPTIONAL FLOW OF EVENTS:
If the Actor does not have a correct user name and password, the system denies access to the Actor to any further functions.
END

CURRENT IMPLEMENTATION:
Web interface is password Protected against a Database.

USE CASE: Logout
USER GOAL: Exit the System

MAIN FLOW OF EVENTS:
An Actor who has successfully logged in to the system may at any time choose the "Logout" option from the system menu to exit the system. When an Actor chooses the "Logout" option, the system will force another Login operation before any other functions will operate. The system will show the Login page.
END

CURRENT IMPLEMENTATION:
Web interface through "Logout"

USE CASE: Update Timesheet
USER GOAL: Add time and code data into the System

MAIN FLOW OF EVENTS:
The use case starts when the Worker selects an "Update Timesheet" option from a system menu. The system will present a grid showing this week's timesheet. For each row in the timesheet, the Worker will be able to select a contract code, an activity code, a task ID, a text description, and the number of hours worked for each day of the week, starting on Monday and ending on Sunday.

The system will keep a running total of hours in the grid that gets updated whenever the user updates the number of hours in each cell.

As an aid to data entry, the system will present both completely blank rows, and some rows that are pre-filled with information. Some pre-filled rows will have the project, activities, task codes, and descriptions from previous weeks filled in, so all the user has to do is fill in the number of hours, and maybe alter the description of the task. Other pre-filled rows will have standard codes and descriptions, like those for timesheet maintenance, professional development, vacation, and so on.

The Worker will update the number of hours in the grid to reflect the number of hours they have worked recently. The Worker commits the changes by hitting the "Update" button.
END

CURRENT IMPLEMENTATION:
Web interface has pop-up boxes for contact and activity codes. When a task code is entered, the project and activity codes are filled with the project and default activity for that task.

EXCEPTIONAL FLOW OF EVENTS:
The Worker can cancel any the changes by hitting a "Cancel Changes" button.
END

CURRENT IMPLEMENTATION:
Web interface allows user to exit by clicking 'Change User or Date', which cancels any changes.

EXCEPTIONAL FLOW OF EVENTS:
The Worker can alter the date range shown by following one of several buttons: one for "Previous Week", one for "Next Week", and one that allows them to choose a week that contains an arbitrary date. When this happens, the Worker's changes to the timesheet should be saved.
END

CURRENT IMPLEMENTATION:
In the web interface, there is an option to Change Date or User, which allows Worker to select another timesheet date range. However, it does not save changes.

EXCEPTIONAL FLOW OF EVENTS:
A Project Manager can switch which Worker's timesheet the system displays, and edit the timesheets belonging from other workers.
END

CURRENT IMPLEMENTATION:
In the web interface a Project Manager has this ability.

EXCEPTIONAL FLOW OF EVENTS:
If the Worker has entered part of a week's timesheet data and saved it, then next time the Worker enters the system, it will take the Worker to the first date in the week for which no data has been previously entered. (Or, alternatively, an option is offered on the front page to go to the part of the week for which time data is not entered.)
END

CURRENT IMPLEMENTATION:
Web interface defaults to the current week, with the start day of week configurable by the Data Administrator in the System Preferences editor.

EXCEPTIONAL FLOW OF EVENTS:
In the event that a server is about to go down, the Worker can use a 'Save' option to preserve entered data until such time as the Worker can return to the interface.

CURRENT IMPLEMENTATION:
None.

USE CASE: View Timesheet Summary
USER GOAL: Verify that entered timesheets are accurate

MAIN FLOW OF EVENTS:
This use case starts when Worker selects a "View Timesheet Summary" option from a system menu. The system will ask the user what time period to report on, and then show a summary of the user's time during that period. It should include at least the following:

  • A view of the hours worked in each day during the time period selected
  • A summary of the variance in hours worked versus hours required to be accounted for
  • A view showing each of the sick days, vacation days, holidays, approved personal leave, and armed forces duty days that each person has taken

CURRENT IMPLEMENTATION:
Available in web interface, within a payperiod. Worker can select a payperiod. The hours required to be accounted for are currently not stored in the system.

USE CASE: Receive Email Notification
USER GOAL: Receive informational updates

MAIN FLOW OF EVENTS:
This use case begins when any Worker needs to be notified of changes to information relating to pending tasks or timesheet data.

The system will generate and send an email notification to the Task Worker assigned to a given task when the Project Coordinator or Project Manager changes the status, priority, or Task Worker assignment relating to that task.

The system will generate and send an email notification to a given Worker upon approval of timesheet data by a Project Manager.

CURRENT IMPLEMENTATION:
Web interface sends email to Task Workers assigned to a task, the Task Owner and the Project Manager when a Task is updated. If the task is in a State that is in the QASTATES table, then the Project QA is emailed as well.

USE CASE: Search Tasks
USER GOAL: Find tasks based on a set of criteria

MAIN FLOW OF EVENTS:
The use case starts when a Task Worker selects one of the search links from the system menu. The Task Worker can discover tasks based on several criteria: keyword, task ID, user, project, task status, or relationship to estimates.

The Task Worker may need to refine this choice by picking a project, user, or task status in an intermediate screen.

The system will then produce a list of tasks restricted by the Task Worker's choices. For each task, it will show the task ID, task title, project code, release code, priority, complexity, task status, and possibly other relevant information. The Task Worker can choose to view a task by following the link enclosing the task title.

When the Task Worker views a task, a link will show that will allow the Task Worker to update the task, taking them into the Update Task use case.
END

CURRENT IMPLEMENTATION:
A search box is available in the web interface that lets a Task Worker or Customer search by task ID or assignee user name. The Open Tasks screen lets users restrict what is shown by clicking on several of the columns in the list (project, task owner, etc).

EXCEPTIONAL FLOW OF EVENTS:
The system remembers what user and project the Task Worker last looked at, and provides shortcut links that allow the user to view tasks restricted by those criteria without going through intermediate screens.
END

CURRENT IMPLEMENTATION:
The web interface does not implement this quite the way originally envisioned, but it does remember how you like the portal and task list screens sorted, and what customer, project, and activity you last used when adding a task.

EXCEPTIONAL FLOW OF EVENTS:
There should be a "View Task ID" entry box that is on every screen in the application that should allow a Task Worker to enter a task number to edit. If a Task Worker puts in a task number in the box and presses the submit button, any unsaved information on the screen they were on will be lost, and the system will immediately present a view of that task ID.
END

CURRENT IMPLEMENTATION:
Available in the web interface.

USE CASE: Update Task
USER GOAL: Add or edit information on a specific task

MAIN FLOW OF EVENTS:
The use case starts when a Task Worker has selected an individual task, either by entering the task ID into the search box, by picking the task from a list of tasks, or by adding a new task.

(start new task).

The system will present the Task Worker with a form that contains information about the task, including:

  • Task ID {frozen} - A numerical ID identifying the task.
  • Customer - The customer name associated with this task
  • Project - The project name associated with this task
  • Task State - Whether the task is open, assigned, closed, etc.
    • This information is read-only on the main screen
  • Priority - A number from 1 to 9, where 9 is the highest priority.
  • Complexity - A number from 1 to 9, where 9 is the highest complexity.
  • Percent Complete - An estimate of how much of this task is finished
  • Title - A short text description of this task
  • Description - a detailed description of the task, including requirements.
  • Strategy - an optional description of strategies to use tackle this task.
  • Task Notes - Notes made by Task Users tracking progress or completion
    • This information is read-only on the main screen
  • Assigned Users - A list of users assigned to this task
  • This information is read-only on the main screen
  • Completion Windows - A list of estimated dates for completion
    • This information is read-only on the main screen

The Task Worker will update some of the fields associated with this task. Then, the Task Worker will hit the "Update" button to submit the changes.

(completed)

The system will validate the information and ensure that the updates made pass the business rules associated with that Task Worker - for example, only a Project Coordinator can close a task.

The system will then show a read-only view of the task, and offer the opportunity to make more changes, edit another task, or discover more tasks.
END

CURRENT IMPLEMENTATION:
Available in the web interface through Add Task and Edit Task. Completion Windows are unsupported in the current web interface.

EXCEPTIONAL FLOW OF EVENTS:
If the Task Worker omits required information, the system will represent the form, with a red asterisk flagging the fields with missing information. For each field that needs attention, the system will provide a textual description of the changes that must be made at the top of the screen.
END

CURRENT IMPLEMENTATION:
Available in the web interface.

EXCEPTIONAL FLOW OF EVENTS:
If a Task Worker chooses to add a Task Note or a Completion Window, the system will display an additional form that asks Task Worker for the note.
END

CURRENT IMPLEMENTATION:
Available in the web interface through Edit Task Notes and Edit Task Status.

EXCEPTIONAL FLOW OF EVENTS:
If a Project Coordinator chooses to assign users or change the state of the task, the system will display an additional form that asks the user for the updated information. When a task state changes, the user will be asked if they want to add a Task Note about the state change.
END

CURRENT IMPLEMENTATION:
Web interface through Edit Task Assignments and Edit Task Status

USE CASE: Update State
USER GOAL: Change the state of a task

MAIN FLOW OF EVENTS
This use case begins when a Project Coordinator starts to update a task. The system will present a Project Coordinator with a special button by the project status field that will allow them to change a task state.

The Project Coordinator selects a task state from a dropdown list. The system logs the date and time of the change of task state, entering it into a running log.
END

CURRENT IMPLEMENTATION:
Web interface through Edit Task Status

EXCEPTIONAL FLOW OF EVENTS:
When a Project Coordinator closes a task, the system will set the state to "Closed", set the "Percent Complete" field to 100%, and add an additional note to the task showing who closed the task and when.
END

CURRENT IMPLEMENTATION:
Web interface through Edit Task Status

USE CASE: Add Task
USER GOAL: Set up a new task

MAIN FLOW OF EVENTS:
This use case begins when the Project Coordinator or Task Worker chooses the "Add Task" option from the system menu. The system will ask the user for details related to the task, including customer, project, title, and so forth. The system will also guess the customer and project by using the last customer and project the user chose. When the user submits the new task, the system will show a read-only summary of the new task.
END

CURRENT IMPLEMENTATION:
Available in web interface through "Add a Task". Prior information is saved in the database on a per-user basis to pre-fill data on Customer, Project, and Task Type.

USE CASE: Analyze Metrics
USER GOAL: review and analyze task and timesheet data

MAIN FLOW OF EVENTS:
This use case begins when Project Manager needs to review how Workers have been spending their time. The Project Manager chooses the "Analyze Metrics" option from the system menu. The system then asks for a date range for reporting. The system then provides tables cross referencing users, tasks, customers, projects, activities, and hours worked.
END

CURRENT IMPLEMENTATION:
This is partially implemented in the web interface through both the Payroll Report and Productivity Report. There are also some PostgreSQL scripts in tasktracker/database that have some ad-hoc queries in them that show some of the useful data.

EXCEPTIONAL FLOW OF EVENTS:
If there is an inconsistency in the data (e.g., unassigned users billing to a task), the system flags that information in red or boldface for further review by a Project Manager.
END

CURRENT IMPLEMENTATION:
Not implemented.

USE CASE: Approve Timesheet
USER GOAL: Approve timesheet data entered by Worker

MAIN FLOW OF EVENTS:
This use case begins when a Project Manager needs to review timesheet data and approve it. The system provides a Project Manager with a view of all timesheet data. The Project Manager can select a date range and set of users to view. The system shows the Project Manager a table that has users as the rows and days as the columns, with the number of hours logged in the cells, hyperlinked to the timesheet view.

After determining that the timesheet data is correct, the Project Manager clicks on 'Timesheet Approved' button. The system marks the timesheets as Approved by that Project Manager and sends an e-mail notification to the Workers. The system notifies the Project Manager that once a timesheet has been approved, no further entries or modifications can be made to the hours that have been approved. If any changes are made to days that have hours that have been approved, the Project Manager is notified.
END

CURRENT IMPLEMENTATION:
This is implemented in the web interface through the Timesheet Review.

EXCEPTIONAL FLOW OF EVENTS:
If a user tries to add hours to a day that has approved hours after it, this is allowed, but email notifications get sent out.

CURRENT IMPLEMENTATION:
This is implemented in the web interface.

USE CASE: Produce Billing
USER GOAL: Generate billing invoices based on time and task data

MAIN FLOW OF EVENTS:
This use case begins when a Project Manager decides to generate a billing invoice for a client. The Project Manager goes to the Produce Billing report, selects a customer, and a date range. The system presents a table containing a summary of hourly billing, first broken down by project, then by Worker, then by project and Worker, then by project and task.
END

CURRENT IMPLEMENTATION:
This is partially implemented in the web interface through the Productivity Report.

There are some PostgreSQL scripts in tasktracker/database that can summarize time by user and project for a given time period.

USE CASE: Maintain Projects
USER GOAL: Relate time and task data to pending projects

MAIN FLOW OF EVENTS:
This use case begins when Data Administrator selects 'Maintain Projects' from a system menu. The system offers a list of the current projects, with the option to edit the existing projects, or to add a new project. If a Data Administrator edits a project, its name, and its list of releases, and contract codes will also be editable.
END

CURRENT IMPLEMENTATION:
Web interface through Category Maintenance.

USE CASE: Maintain Activities
USER GOAL: Add, edit or delete activity codes

MAIN FLOW OF EVENTS:
This use case begins when Data Administrator needs to add, edit or delete an activity code or activity group. The system offers a list of the current activity codes or groups, with the option to edit the existing codes or groups, or to add new codes or groups.
END

CURRENT IMPLEMENTATION:
Web interface through Category Maintenance.

USE CASE: Maintain Workers
USER GOAL: Add, edit or delete worker ids

MAIN FLOW OF EVENTS:
This use case begins when a Data Administrator needs to change the roster of Workers in the System. The system offers a list of the current workers, with the option to edit existing workers, or to add new workers. The system presents the roles each user has upon creation or editing.
END

CURRENT IMPLEMENTATION:
Web interface through Category Maintenance.

Valid HTML 4.01!