User Requirements

Requirement #1

Requirement Type: Functional

Description: The program must allow new appointments to be easily created, moved and deleted.

Details: The creation of a new event must be as simple as possible – indicating the day and time should be done with natural, accurate and intuitive inputs. Entering the details of the activity should be quick and easy – reasonable defaults should be provided for input fields where appropriate, and the software should remember previous input patterns when generating these defaults. Clearly erroneous input should not be allowed, such as trying to input a time into an address field. Input options should be memorable and quickly identifiable – for example, if all academic activities are colour-coded blue throughout the application, the option to categorize a new activity should also be blue. The number of input fields confronting the user at any one time should be minimized on the mobile app, but can be larger on the desktop given larger screen sizes. If the user is interrupted in the course of entering a new event, the option should be available to save it in incomplete form, or back out of the new event entry, returning the schedule to its pre-event-creation state.

Editing current events should be as simple as selecting an existing event, selecting the data to be edited, and replacing old values with new. In the case of an edit to a recurring event, the user should be prompted to choose between updating only this instance of the event, or all corresponding instances. There must be an option to stop editing an event halfway through, reverting to the pre-editing state of that scheduled activity.

Deleting events should be possible, perhaps from the event editing screen, or perhaps in some other manner. The deletion of events by accident should never occur.

Rationale: The creation and deletion of activities are the minimal features expected of any scheduling software. Moving appointments is required, since the alternative (deleting the appointment and recreating it) is error-prone and tedious. The process of event creation must be easy, otherwise users will skip creating events, resulting in inaccurate scheduling, poor optimization and useless reflective data.

Fit Criterion: The user is able to create a schedule entry. They are then able to edit it. Finally they are able to delete it. They must not be confused or surprised by program behaviour through this process, and must not experience errors in data input due to ambiguity or incorrect program behaviour.

Requirement #2

Requirement Type: Functional

Description: The program must correctly import and integrate the user’s external academic schedule.

Details: The program must correctly and securely present user credentials to UVic’s scheduling backend system, and must remember those credentials between uses. The program must respond properly to changes in the schedule caused by registration activities and semester completion, and must account for reading breaks and statutory holidays. If an imported activity conflicts with an appointment already present on the system, this conflict should be brought to the user’s attention for immediate rectification, or flagged as a conflict for later editing. It should be possible to delete all academic schedule events at once, if the user leaves or changes schools, but it should not be possible to do so accidently. If the UVic scheduling system is unavailable, this error should be communicated clearly to the user, as should errors related to failure to parse external data caused by changes in UVic’s system. A progress display widget is presented to the user indicating estimated time remaining for this operation, and cancelling this operation is permitted with no corruption of the Timetracker schedule.

Rationale: Accurate importation of pre-existing schedules allows the program to be immediately useful to the user, even before they have entered custom activities.

Fit Criterion: The user is able to trigger the importation of their UVic schedule, which is transferred to their Timetracker schedule without error. This process takes less than 15 seconds.

Requirement #3

Requirement Type: Functional

Description: The program must display past activity category data correctly.

Details: Both manually-created and imported scheduled events must continue to be viewable once their date has passed. Program behaviour should be consistent for past dates – past appointments can be created, moved, edited and deleted in the same manner as future events. The program must allow the user to select a single day or series of days for analysis, and the program will then display a breakdown by category of the activities performed during that period. This display is in a user-selected format – options should include (but are not limited to) bar chart, pie chart and tabular text. The colour scheme for this display should reflect colours that are by now familiar to the user from consistent use elsewhere in the program. The display of this information must be appropriately sized for the platform in use, and it should be possible to copy tabular text information to the system clipboard on desktop using familiar menu commands and keyboard shortcuts.

Rationale: Learning from past behaviour patterns is a core user goal for the software. Inaccurate or incomplete displays of activity will reduce the incentive to enter future event information, further reducing the effectiveness of the reflective features of the software.

Fit Criterion: The user is able to invoke the analysis function, and the information displayed is accurate and complete. The process of analyzing this information and presenting the resulting report should not take more than 5 seconds except for multi-year analysis. A progress indicator must be displayed if analysis takes more than 1 second.

Requirement #4

Requirement Type: Usability

Description: The program must provide reasonable defaults where applicable, and sanity-check inputs.

Details: Where appropriate, categories and text input fields should be populated with reasonable default values. Optimally, the program will learn from and then anticipate user behaviour, detecting patterns in appointment creation to provide helpful defaults. However, this process must be gradual and clearly indicated to the user; once they get used to a certain set of defaults, altering them without notice will create input errors or undesired behaviour. Inputs should also be sanity-checked where appropriate; if an address is entered where a date or time is required, this error should be brought to the user’s attention immediately.

Rationale: The effectiveness and appeal of the program are enhanced if the appointment creation process is quick and error-resistant.

Fit Criterion: The user is able to approve of default values by leaving fields in their default state. After entering 100 appointments, the user reports that they ‘rarely’ or ‘never’ have to subsequently change defaults. The user reports that the provision of default values in the program is ‘almost always’ or ‘always’ a welcome convenience. Attempts to enter inappropriately-typed data into input fields are unsuccessful.

Requirement #5

Requirement Type: User

Description: The program must be usable with no training by a novice computer user.

Details: The software must be designed in such a way that untrained users, including those who have never used scheduling software before, can successfully operate its basic functions with very little time investment. Clear error messages and a generally responsive UI must be provided so that user frustration is kept to a minimum. Users should never experience an unnecessarily cluttered interface, and input fields should follow one another in a reasonable order. The user’s ‘location’ within the application should always be clear, and it should always be obvious how to return to the ‘home screen’. Use of the program should not interfere with the general use of the device on which it runs. Specifically, it should always be possible to switch from any point within Timetracker to other programs running on the device, without losing any user information or progress.

Rationale: The target market for the software includes (but is not limited to) novice computer users, who may not read documentation and may have no training.

Fit Criterion: A user who self-describes as a novice computer user, and is unfamiliar with the software is able to successfully create and delete a future appointment, and successfully view a past activity analysis without program-caused error.

Requirement #6

Requirement Type: Data

Description: Program must remain responsive and usable during periods of network unavailability.

Details: Many of the program’s features do not require access to network resources, and the unavailability of the network must not interfere with their function. For those features that do benefit from or rely entirely on network availability, the lack of such availability must not prevent the application from smoothly recovering from this problem. An informative message must be displayed to the user if the network is unavailable for one of these activities, or if it becomes unavailable during the execution of these activities. The user must be able to cancel or back out of any data-aware functionality without loss previously-entered user data.

Rationale: Inconsistent access to network resources is a common problem.

Fit Criterion: The non-network-aware features of the software must continue to function with network access disabled. The software must gracefully handle interruption of network access in the midst of operations such as the importation of academic information or scheduling optimization.