Requirements Document for UniCal

Introduction

Since the opening of the campus, the University of California, Irvine (UCI) has held many academic and non-academic events for its many students, faculty, staff, and visitors. Until now, UCI has informed people of these events using a haphazard collection of e-mails, web pages, flyers, and word of mouth. However, as the campus grows, it becomes increasingly more difficult to inform people of the many different UCI events. UCI now wishes to supplement this process by creating a university calendar system, called UniCal, to inform interested parties of campus events.

Because UCI is a research oriented institution, it does not want to burden its professors or students with production oriented software engineering projects. Consequently, it has hired Retro Software Inc. to develop this requirements specification for UniCal, as well as its subsequent design and implementation. The information in this requirements specification is based on interviews conducted with the relevant parties at UCI, by the requirements engineers at Retro Software Inc. All information in this document was determined to be accurate at the time of this writing.

This document contains the detailed requirements specification for UniCal that Retro Software Inc. is developing for UCI. The document should serve as the official basis for any further development of UniCal.

This document contains the following sections:

Executive Summary

UniCal aims to provide a solution for scheduling campus events and publicizing their information to UCI faculty, staff, students, and visitors. The application allows customers to schedule, share, and view events via any computer running UniCal. UniCal facilitates communication by unifying and providing easy access to event information. Changes in events will be updated to users' schedules so that everybody is well informed. By maintaining consistent and reliable event information, UniCal enables effective event arrangement and collaboration among users. Retro Software anticipates that the overall effect of adopting UniCal will result in more accurate, efficient and convenient schedule coordinating among UCI personnel.

UniCal provides the following key features:

Scheduling and sharing events
A user can schedule events and group them into specific categories using UniCal. These events can be seen by other users of the system.
Viewing events
A user can view all of the events in their calendar in either a weekly or monthly view.
Event reminders
UniCal will provide reminders for a user by playing a sound and displaying a pop-up window with details of the event at a customizable time interval before each event.
Task list
Users can also create a task list with deadlines and reminders to help them meet goals.

Some of the most important risks posed by the development of UniCal are the following:

Lack of adoption
Because there are many other calendaring systems currently on the market, it is possible that students, faculty, and staff will not adopt UniCal into their normal routine. This would effectively render the system as no more useful than current approaches to informing people of events.
Usability
help encourage adoption of the system, UniCal must be extremely intuitive and easy to use.
Rapid development
The schedule according to which UniCal will be developed is extremely aggressive to ensure that another company will not develop a similar product first and claim the market. Other qualities cannot be sacrificed as a result of this rapid development.

Application Context

UniCal will be used in the institutional environment, UC, Irvine, where scheduling and coordinating events can be difficult because of the large numbers of people involved. The introduction of UniCal should reduce the effort required to coordinate schedules among multiple people by automating much of the effort of keeping everyone's schedule up to date. Adopting UniCal will result in substantial change for UCI. It will require that the application be installed on each person's computer, and that the application be used as the primary means of scheduling and coordinating events on campus.

Users of UniCal fall into two different roles: administrators, and users: Administrators of UniCal have all of the same functionality as a user, but in addition are responsible for managing the different accounts of the system. They may create, delete, and edit user accounts, as well as other administrator accounts. Should users forget their password, it is the responsibility of an administrator to reset their password so that they may once again gain access to the system. Should an administrator forget their password, they may have the password e-mailed to the e-mail address associated with their account.

Users of the UniCal system use the system to schedule and share events. Users may be faculty, staff, students, or even offices who wish to publicize office events. Users may create events, schedule reminders for events, specify recurrences for events, and group events together into categories. The categories that users create may be shared with other users of the system and included on their calendars. Users may also maintain a private task list of tasks that need to be completed.

It is the hope of UCI that UniCal will eventually be used by other campuses. Such a change would require the application to be highly scalable and likely require instances of the UniCal system to interoperate since, due to political issues, it is unlikely that all campuses will share one instance.

Functional Requirements

  1. Data Entities
    1. Accounts
      1. each user of the UniCal system should have an account
      2. accounts may be either user or administrator accounts
      3. each account is identified by a unique username
        1. usernames must consist of 5-20 uppercase, lowercase, and numeric characters
        2. all usernames remain unique at all times
      4. each account will also have an associated password and full name
        1. passwords must consist of 5-20 upper,lowercase, numeric, and punctuation characters
        2. full names must consist of 1-100 Unicode characters
        3. once entered into the system, passwords should not be viewable by anyone
      5. administrator accounts will also have an associated email address
        1. email addresses must conform to section 3.4 of RFC 2822
      6. initially, there should be a default administrative user with a username "admin" and password "admin"
    2. Events
      1. each event has a name
        1. this is a single-line 1-50 Unicode character description used to identify the event
      2. each event has start and end times
        1. these should have a granularity of 1 minute
        2. these should be allowed to range over at least the period from 12:00am 1/1/2000 to 11:59pm 12/31/9999 in local time
        3. times should be convertible to Pacific Standard Time or Pacific Daylight Time as appropriate for the date
      3. each event has a location
        1. the location should specify the room, building, street address, or other description of the location for the event (*)
        2. the locations maximum size should limited to 10 lines of 80 characters (*)
      4. each event has a description
        1. this is a multi-line textual description of the event
        2. descriptions should be allowed to consist of at least 10,000 Unicode characters (*)
      5. each event has a recurrence setting
        1. the recurrence setting may have the values "No recurrence", "Weekly recurrence", "Monthly recurrence", or "Yearly recurrence"
          1. events with "No recurrence" occur only once at the specified start and ending times
          2. events with "Weekly recurrence" recur on particular days one or more times each week
            1. a specific days of the week, on which the event is to recur, will be associated with the event
            2. an end date, after which the event will not occur, will be associated with the event
          3. events with "Monthly recurrence" recur once each month
            1. a specific day of the month, on which the event is to recur, will be associated with the event
            2. an end date, after which the event will not occur, will be associated with the event
          4. events with a "Yearly recurrence" recur once each year
            1. a specific day of the year, on which the event is to recur, will be associated with the event
            2. an end date, after which the event will not occur, will be associated with the event
          5. recurring events will start on or after the event's start time
          6. the time of day of the event's start and end times will be used as the time of day for each occurrence of the event (*)
          7. the date of the end time will be ignored (*)
        2. each user may have a reminder scheduled to occur at some interval before an event
          1. reminders should be able to be set for the following intervals before an event:
          2. at an interval of 0, 5, 10, 15, or 30 minutes,
          3. at an interval of 1-12, or 18 hours,
          4. at an interval of 1-6 days, or
          5. at an interval of 1-2 weeks
        3. if the reminder is set for something that has a recurrence, then the reminder will occur for each instance of the recurrence
    3. Categories
      1. categories consists of a name, color, description, a set of events associated with the category, and export flag
        1. each category's name is a single line description of that category
          1. it should consist of a maximum of 50 Unicode characters
          2. each category must have a unique name
          3. all names must remain unique at all times
        2. each category's color will be used to color the events belonging to that category
        3. each category's description is a multi-line textual description
          1. descriptions should be allowed to consist of at least 10,000 Unicode characters (*)
        4. each category contains a set of events associated with it
          1. each event must be associate with exactly one category
        5. each category can be private or it can be exported so that it is available to other users
    4. Tasks
      1. tasks consist of a name, description, due date, and reminder
        1. each task's name is a single line description of that category
          1. it should consist of a maximum of 50 Unicode characters
        2. each task has a multi-line textual description
          1. this description should be allowed to consist of at least 10,000 Unicode characters (*)
        3. each task's due date is the time at which the task must be completed
        4. the user may have a reminder set to occur at the following intervals before the due date of the task:
          1. at an interval of 0, 5, 10, 15, or 30 minutes,
          2. at an interval of 1-12, or 18 hours,
          3. at an interval of 1-6 days, or
          4. at an interval of 1-2 weeks
  2. User Interface
    1. Login
      1. a user logs in to UniCal using a username and password
      2. the user password must be changed the first time a user logs in
      3. users should have the same categories, tasks, reminders, and other settings at any machine on which they log in (*)
    2. Main Window
      1. appropriate menus and toolbars should be available to access all functionality using the mouse and keyboard
      2. the main window should consist of three frames, arranged from left to right: the category list, the calendar view, and the task view
        1. the category list frame should initially take up 10% of the main window
        2. the calendar view frame should initially take up 80% of the main window
        3. the task list frame should initially take up 10% of the main window
        4. the user should be able to resize the portion of the screen that each frame occupies
      3. Category List
        1. this contains a list of categories sorted alphabetically by name
          1. all categories created by a user should be included
          2. users may also add to the list by importing categories
            1. categories are imported by selection a category from a global list of all categories available
            2. when importing, a user may choose a local name for the category
          3. there should be checkbox to the left of each category
            1. when checked the events of that category will be visible in the calendar view
          4. the area behind each category name should be colored according to the category color
          5. the user should be able to edit category properties (i.e., name, color, description, and export flag) via a context menu for each category in the list
      4. Calendar View
        1. the Calendar view should consist of a tabbed pane
          1. it should include tabs for a monthly calendar and a tab for a weekly calendar
          2. the tabs should be located at the top left of the view
          3. all calendar views should start on the same day of the week, either Sunday or Monday
            1. the user should be able to set this in system preferences
        2. Monthly Calendar View
          1. this view should display consist of a grid of 35 equally sized boxes containing the events for each day
            1. there should be seven columns of boxes, one for each day of the week
            2. there should be five rows, one for each week of the month
            3. the day of the month should be displayed in the top right corner of each box
            4. the box representing the first of any month should contain:
              1. the name of the month in the top left corner, and
              2. the four digit year between the month name and the day of the month
            5. the box for the current day (according to the system clock, in local time) should be highlighted with a red border at the edge of the box
          2. for each day, the name of the events for that day in local time should be listed in that days box
            1. events should be listed in order of starting time
            2. events that span multiple days should be included in each day that they occur
            3. the background of each event should be colored according to the color of its respective category
            4. if all of the information cannot fit within the box, scrollbars should be used to make it accessible
          3. one day on the calendar is considered to be selected
            1. by default, the current day is selected
            2. a different day may be selected using the mouse or arrow keys
            3. page-up will select the date that is one month prior to the currently selected day
              1. similarly, page-down will select the date that is one month after the currently selected day
            4. the selected day is highlighted with a black border
              1. when the current day is selected, the black border should be drawn within the red border
          4. adding an event to the calendar when in this view should us the currently selected date as the default starting and ending date
          5. double clicking on the number of any day should change the current view to the weekly calendar
            1. the weekly calendar should be for the week containing the day that was double clicked
        3. Weekly Calendar View
          1. this view should display a grid
            1. each day of the week is represented by one of 7 columns
              1. the date for each day should be displayed at the top of each column formatted as: <week day>, <month>/<day>/<year>
              2. using the full week day name
              3. using a one or two digit number for the month
              4. using a one or two digit number for the day
              5. using a four digit number for the year
            2. the time of the day is indicated along the left hand side
              1. time increments for the left hand side should be selected from 5, 10, 15, 30 minutes, and 1 hour
                1. the default should be 30 minutes
            3. page-up will display the previous week, page-down will display the next week
            4. each event should be displayed as follows:
              1. a 25% rectangle should cover the area indicated by the start time and end time of the event
              2. the rectangle should be the event's category's color
              3. the rectangle should span multiple days for the multi-day events
              4. the name of the even should appear at the top left corner of the translucent rectangle
              5. conflicting events should simply overlap
            5. an event or time range may be selected using the mouse or keyboard
              1. the selected event or time range should be highlighted with a black border
              2. adding an event to the calendar, in the view, should use the currently selected time range as the default starting and ending times
      5. Task List
        1. the tasks should display each task in descending order of due date
        2. a user should be able to mark tasks as completed
        3. tasks that are marked as completed should disappear in 24 hours
    3. Reminders
      1. when the system's time and date become greater than the reminders scheduled time, it will be triggered...
        1. playing a sound, and
        2. displaying a popup window with all the events details
          1. the popup should contain a "dismiss" button which closes window, stops the sound, and dismisses the reminder for that occurrence
            1. closing the popup through the operating system should have the same effect as a dismissal (*)
          2. the popup should contain a "snooze" button which closes the popup, stops the sound and reschedules the reminder
            1. the reminder will be rescheduled for five minutes after the snooze button was pressed
    4. Create/Edit Event
      1. an interface must be provided to create events and modify information about events
        1. new events must be given names, categories, start and end time
        2. users should be able to modify the name, category, start and end times, location, description, and recurrence information for events they create
          1. start and end times should be formatted as <hours>/<minutes> <am/pm> <month>/<day>/<year>
            1. the times should be displayed and edited in local time
            2. months should be displayed numerically
            3. minutes should be displayed as a two digit number
            4. years should be displayed as a four digit years
          2. hours, months, days can be displayed as 1 or two digit numbers, as appropriate
      2. users should be able to add reminders to any event and view modify the reminders they've created
      3. users should be able to add and modify events while disconnected from the Internet
  3. Create/Edit Categories
    1. an interface must be provided to manage categories
      1. users can create new categories
        1. the name, color, and description must be specified for new categories
        2. the system should ensure that the name is unique, prompting the user to change it if necessary
      2. users can modify the name, color, and description for existing categories
        1. the system should ensure that any modified names is unique, prompting the user to change it if necessary
      3. users can export categories so that its events are available to other users
        1. when attached to the network, events contained in exported categories will automatically propagate to other users who have imported those categories
  4. Create/Edit Tasks
    1. an interface must be provided to manage tasks
      1. users can create new tasks
        1. the name, description, and due date must be specified for new tasks
      2. users can modify the name, description, and due date
      3. due dates should be formatted as <hours>/<minutes> <am/pm> <month>/<day>/<year>
        1. the times should be displayed and edited in local time as appropriate for the date
        2. months should be displayed numerically
        3. minutes should be displayed as a two digit number
        4. years should be displayed as a four digit years
        5. hours, months, days can be displayed as 1 or two digit numbers, as appropriate
      4. users should be able to create a reminder for any task
      5. users should be able to add and modify tasks while disconnected from the Internet
  5. Administrator Interface
    1. administrators should be able to create new accounts
      1. new administrative account must have a username, password, full-name, and e-mail
      2. new user accounts must have a username, password, and full-name
      3. the system should ensure that the username for each account is unique, prompting the user to modify it if necessary
    2. administrators should be able to change their own password, full name, and e-mail address
    3. administrators should be able to reset the password of...
      1. user accounts,
      2. administrative accounts that they created, or
      3. administrative accounts that were directly or indirectly created by accounts that they created
    4. administrators should be able to only delete...
      1. user accounts,
      2. administrative accounts that they created, or
      3. administrative accounts that were directly or indirectly created by accounts that they created
    5. UCI has few other restrictions on the user interface to administrative functionality

Environmental Requirements

Since most people on the UCI campus use either Microsoft Windows or the Macintosh OS, UCI has decided that UniCal should be able to run on both platforms.

UCI has also hired a consultant regarding programming languages, and, based on her report recommends that UniCal be implemented in Java, to ensure portability across platforms as well as easy maintainability. Use of the JDK 1.4 is expected.

Other Requirements

Users should interface with UniCal through a stand alone application on their machines.

The cost of development for the UniCal system must not exceed $399,999.98. UCI has consulted with financial analysts to determine that this is the maximum amount the system can cost without becoming unprofitable.

Retro Software Inc. should carefully document all decisions made, especially decisions pertaining to changes in this document (and subsequent documents; always per agreement with UCI).

Retro Software Inc. will deliver detailed user manuals for the UniCal system.

Software Qualities

User-friendliness
Because many of UniCal's users are expected to be people with minimal to no time to learn a complicated new system, it is imperative that the system be as user-friendly as possible.
Correctness
Because UCI wants the system to be widely used, it is important that UniCal perform all of its requirements correctly and does not result in the proliferation of inaccurate or incomplete information.
Reliability
Reliability of UniCal is not essential, but nonetheless important. The accepted rate of failure is one crash per month. Any failure rate above this will create an unfavorable impression of UCI towards Retro Software.
Performance
Performance is crucial to UniCal---if the system is too slow, customers may revert to sending e-mails and using word of mouth. Synchronizing events with UniCal should take no more than one second for every fifty events. All other operations must be performed nearly instantaneously.
Reusability
Reusability is important because it is hoped that UniCal will eventually be adopted at all other UC campuses.
Extensibility
Several future enhancements for UniCal have already been proposed, and there will undoubtedly be more forthcoming. Therefore, it is critical that UniCal can be extended with relative ease.
Evolvability
UniCal is expected to undergo significant changes as UCI determines which features are most important to its population. Evolvability is central to this goal.
Robustness
UniCal must not crash if a user enters incorrect or invalid data, or performs some otherwise unexpected action. A reasonable response that allows the application to resume normal operation must be given.
Verifiability
Although it is preferable that the system undergo formal, thorough verification and testing before deployment, this is not feasible with the rigorous time schedule desired by UCI. However, extensive testing of the accuracy of the system's functionality should be performed before release.
Maintainability
UCI anticipates that UniCal will be used over long periods of time, eventually by large numbers of users. Due to this fact, the likelihood of several future enhancements, and the high probability of an equally tight time schedule for their development, it is imperative that UniCal be easily maintainable.
Reparability
Because UniCal is being developed under such a tight time schedule, it is likely that testing will not be done as thoroughly as desired, and some faults will make it into the product. Therefore, the system must be easily repairable in order to fix these defects in a timely manner so as not to disrupt the business of UCI.
Safety
Since UniCal is not a safety-critical application, there are no safety concerns.
Portability
Even though UniCal will be implemented entirely in Java, a highly portable language, portability will still need to be considered in the design and implementation of the system. It is UCI's desire that no features of UniCal will violate commonly accepted standards for each platform.
Understandability
To support evolvability, reparability, and maintainability, it is imperative that all aspects of UniCal be easily understood, even to future developers who are not currently involved in the creation of the system.
Interoperability
For this current set of requirements, the interoperability of UniCal with any other application is not needed. However, it is of prime importance that UniCal interoperate with other calendaring systems in future versions.
Productivity
Because UCI would like to release the UniCal application as quickly as possible, it is desirable that the productivity of all involved in the development of UniCal be supported and facilitated with quality processes and tools as much as possible. However, limited funding is available for this requirement, so it must be foregone.
Size
Hard drive space and memory are abundant nowadays---size is not an issue.
Scalability
It is important that UniCal be able to scale to support the entire population of UCI, and perhaps, the UC system. Therefore, scalability is an important issue to consider in the development of UniCal.
Timeliness
It is imperative that all artifacts of the UniCal system be delivered on time.
Visibility
Due to the rigorous time schedule, extra time and effort to make the project status visible should be forfeited.

Time Schedule

The development schedule for UniCal is as follows:

Potential Risks

Difficult to use
UniCal has a lot of features and addresses every kind of user. Furthermore, a significant portion of its expected user base is not computer literate. Hence, it is possible that some users might find it too difficult to use UniCal.
Limited schedule
The schedule according to which UniCal is being developed is extremely aggressive and may result in a product that does not adequately satisfy the needs of UCI.
Lack of adequate support processes and tools
A project of this size would ideally be supported by a number of quality software engineering processes and tools. Unfortunately, UCI lacks the funds necessary to obtain these tools.
Privacy issues
As all categories will be viewable by every user, some users may feel uncomfortable letting other people see their (private) events. This could cause users to refrain from using UniCal.

Future Changes

Programmatic API for administrator functionality
In future versions, UCI may want to be able to programmatically access administrator functionality so that the creation and removal of user accounts can be done automatically by computers processing incoming and outgoing students, staff, and faculty.
Web & PDA interface
In future versions, UCI may want to create Web interfaces and PDA interfaces to supplement UniCal.
Permissions
In future versions, UCI may want to introduce permissions to allow users of UniCal to keep certain events private.
Interface with other calendaring applications
In future versions, UCI may want UniCal to interface with other calendaring applications. Minimally this will involve sharing event information such as through importing and exporting .vcal files (see http://www.imc.org/pdi/vcal-10.txt). However, support of more automated techniques such as scheduling meetings may also be desired.