The Rosey Software company wishes to produce a simple calendar product to sell to office workers. The calendar product, hereafter referred to as "Rosey Calendar", would allow office workers to organize and schedule their time. The benefits of the tool should justify a hefty price tag.
| Term |
Definition |
| ASCII |
American Standard Code for Information Interchange |
Office workers currently use paper-based calendars to record their commitments, such as meetings.
Some of the intended users of Rosey Calendar are office workers with no previous experience with computer-based calendar systems. These users have personal computers that they use in their daily work, but they only use a few specific tools on those computers. Some of the intended users of Rosey Calendar are office workers with extensive experience with computer-based calendar systems, such as found in Microsoft Outlook. These users will be encouraged to use Rosey Calendar due to its simplicity, robustness, and commonality with other workers.
Each user has their own personal computer running Microsoft Windows XP Professional Edition. They will use Rosey Calendar throughout the day to schedule appointments and to check on upcoming meetings. Each evening their personal file space is automatically backed up by their computing center. Calendar information should be saved in files that are accessible to the users of the Rosey Calendar in their normal personal file space.
The initial user interface for Rosey Calendar shall be ASCII text based. Commands to insert, change, or delete appointments will be initiated by simple command-line invocations. Output of commands will be short messages or displays of current appointments.
4 commands will be supported:
ˇ insert: create a new appointment in the calendar
ˇ change: modify an existing appointment
ˇ delete: remove an appointment
ˇ print: display appointments within a specified date and time range.
ˇ quit: exit the application
Here are samples of possible implementations of these commands. The user's input is shown in bold italic. The notation "<CR>" indicates that the user typed only a carriage return.
% RC? i
Insert > New appointment name? Lunch
Insert> New appointment date? 12/2
Insert> New appointment start time? 12:00
Insert> New appointment stop time? 12:30
% RC? c
Change> Existing appointment date? 12/2
Change> Existing appointment start time? 12:00
Change> Existing appointment name? [Lunch] <CR>
Change> New appointment name? [Lunch] <CR>
Change> New appointment date? [12/2] <CR>
Change> New appointment start time? [12:00] <CR>
Change> New appointment stop time? [12:30] 1:00
% RC? p
Print> Starting date? 12/1
Print> Starting time? 8:00
Print> Ending date? 12/2
Print> Ending time? 12:00
12/1
8:00 Breakfast
10:00 CSSE 376
12:00 Lunch
12/2
8:00 Breakfast
10:00 CSSE 376
12:00 Lunch
% RC? q
Note that a more attractive user interface should be developed later. For example, it should be possible to view the current appointments in a separate window and select appointments by clicking on them.
It should be possible to enter appointments for any reasonable date in the future, up to 10 years from the current date.
It should not be possible to enter appointments for dates in the past.
It should be possible to enter more than one appointment for the same date and time. That is, Rosey Calendar should not do any checking for conflicts.
It should be possible to print all appointments for any reasonable range of dates and times, including the past.
Rosey Calendar should respond to user input within less than a second.
Each user's appointments should be kept in a simple ASCII file.
Rosey Calendar must be implemented in Java.
Rosey Calendar should have a mean-time to failure of 5 years.
Although the information stored in Rosey Calendar may be sensitive in nature, Rosey Calendar need provide no extra assurance of security than is already provided by the user's operating system.
Future versions of Rosey Calendar may improve the appearance of the user interface. The system should be designed so that new versions may reuse most of the core computation components of earlier versions.
(to be completed later)
All currently-described features should be available in the first release of the product.
| Item |
Due |
Media |
Description |
| Test plan |
12/9/2003 |
electronic |
Description of all testing activity |
| Source code |
12/19/2003 |
electronic |
All source code produced by the project team |
| Unit test results |
1/9/2004 |
electronic |
Results of all unit testing on version 1 |
| Integration and system test results |
1/16/2004 |
electronic |
Results of all system testing on version 1 |
| Usability test plan |
1/23/2004 |
electronic |
Description of usability testing plans |
| Usability test results |
2/3/2004 |
electronic |
Results of usability testing |
| Regression test results |
2/10/2004 |
electronic |
Results of regression testing |
| Acceptance test results |
2/13/2004 |
electronic |
Results of acceptance testing |
| # |
Who |
Due |
What |
| 1 |
Mark |
12/8/2003 |
Draft use cases |
| 2 |
Mark |
12/8/2003 |
Spell chek |
| Date |
Who |
Revision |
| 11/24/2003 |
Mark |
Created initial draft |