Summary/Outline Features

• Paul Tomochko
• Christopher Mohr

  Functional Requirements and User Interaction:

• Lin Chung
• Nils (Hal) Henningsmoen
• Lee Bin (Mabel) Khoo
• HIU (Roger) Lee
• Russell Magee
• Paul Sung

  Management Plan:

• Michael Cullingham
• Rosina Ye
• Danny Yerex

  Final Summary and editing final version:

• Tom Schulz

Executive Summary

The system will serve as a group time management system providing personal schedules for all employees and a meeting scheduler that employees can use to schedule meetings which will then appear on the schedules of invited employees.

TimeTracker will be divided conceptually into two sub-systems; the Meeting Scheduler and the Personal Daytimer. The Meeting Scheduler will use employee availability data and existing meeting times to determine optimal time for a meeting and then inform those involved of the meeting. The personal Daytimer will provide each employee with an `at a glance` view of their personal schedules.

Time Tracker will satisfy the need to schedule meetings with multiple co-workers in a fast, reliable, and efficient manner. An employee will be able to schedule meetings with other employees without having to make direct contact with each employee involved in the meeting or know the schedule of the employee. Time Tracker will enhance communication between employees enabling them to work together more efficiently and spend less time in non-productive activities such as 'phone tag'. An easy to use mouse driven interface will empower the customer to get maximum use of this application very quickly after it's deployment.

Meeting Scheduler Sub-System

1. Schedule meetings: Employees will be able to schedule a meeting or appointment on a daily, weekly, or monthly basis. As well, an employee may schedule single, "one-time-only" meetings.

   - On a daily, weekly, monthly or "one-time-only" meeting.

   When a meeting is scheduled, the system searches for the first time slot when all employees invited to the meeting are available. If the system cannot create an acceptable meeting time then it will find a time with the least conflicts between schedules. All employees who are invited to the meeting are then informed of the meeting and given a chance to respond.

   - 1) Respond only if person has conflict and can not attend.

   - 2) Everyone is informed of a scheduled meeting.

   - 3) If somebody invited to meeting later decided they can not attend, there must be part of the system that allows that person to cancel themselves from a meeting and inform the convenor of this.

   A meeting may also be scheduled 'manually' by simply choosing a time rather than having the Meeting Scheduler find a slot.

2. Cancel existing meetings: The employee who scheduled a meeting will be able to cancel it. Employees may also cancel their own attendance at a meeting from their personal Daytimer.

   - 1) No function in the personal Daytimer has been described that allows for a user to cancel themselves from a meeting.

   - 2) Consider putting this function as a clicking on the day on calendar and then clicking on cancel.

3. Change existing meetings: The employee who originally scheduled the meeting may alter any information corresponding to a meeting after it has been scheduled.

   - 1) Meeting times are not changed; a meeting is canceled and then re-scheduled. However incidental info about meeting can be changed.

   - 2) Also there must be a flag (i.e.: message) that will inform users that incidental info (e.g.: meeting place) has been changed.

   Invitees are informed of these changes and new invitees will be notified when they are added.

4. Create a group alias: The program will be able to address groups of employees as well as single employees. Aliases will be defined from a list of employees and enable employees to schedule meetings with working groups or departments very easily.

   - 1) Only individuals can create aliases -> i.e.: no public aliases.

Personal Daytimer Sub-System

1. Set hours of availability: Employees must make known to the system at which times they are available to attend meetings.
2. View schedule: Employees will be able to view their personal schedule for 1 day, 1 week, 1 month periods. Employees
3. Print out schedule: Employees will be able to print out a hard copy of their schedule (1 day, 1 week, 1 month).
4. Display meeting information: An employee may select a meeting from their schedule and have the system display all information pertaining to that meeting. Information regarding new meetings is presented to the user in the 'RSVP'

   - 1) Please consider re-naming RSVP to "Messages".

   portion of the program, providing details of the meeting and giving the employee response options.

The screen will be divided into two side-by-side halves. On the left, a calendar will be shown, displaying a month or a day. By clicking on individual days or weeks from the monthly display, users will be able to 'zoom in' on their schedules, and quickly 'zoom out' by pressing a button. On the right will be four pages stacked on top of each other like index cards with large, labeled tabs on top of them to quickly switch between the four other parts of the program. The different views on the left will show this information:

    MONTH VIEW: A window showing a calendar-style display of all days
                in the current month

    WEEK VIEW:  The month view will satisfy this need.

 - 1) We want a week view! E.g.: Week view will show more information that month view.

    DAY VIEW:   A window showing the hours of a day, in the style of a
                regular Daytimer (ruled lines divide 1/2 hour increments)

The `RSVP` tab will have a list of meetings the user has been invited to. By clicking on an invitation they can get more information about the meeting, and accept or decline the invitation.

- 1) NO RSVP (or message) unless conflict.

- 2) We would prefer a system where a user clicks on a square on calendar Daytimer and info about meeting appears.

The `Availability' tab will show a worksheet with checkboxes and fields for users to set up their availability for meetings. In general, the user will be able to set up their usual availability over a period of time and exceptions.

The `Employees' tab will display a list of employees and their contact information such as phone number and email address. It will also show all currently defined aliases.

- Only want personally owned aliases, not public aliases.

>From this screen new employees are entered into the employee database and new aliases may be defined.

The 'Meeting Manager` tab allows the user to access information about meetings they are attending or have scheduled for a selected time period. For example, if you had the day March 5, 1996 selected on the calendar the Meeting Manager

- We would prefer to click directly on the Daytimer i.e.: a square of time on the Daytimer.

would display your schedule for that day. If the user clicks on a specific meeting all information about that meeting would be displayed as a meeting information form . If it was a meeting they had convened, they could edit this form including canceling or rescheduling the meeting. They could also get a blank version of this form to use for scheduling a meeting.

To simplify data entry by reducing typing and memory load, some input fields will be dynamically linked to the database in two ways. To begin with, double clicking an icon at the end of a field will pull up either an icon so input can be entered by mouse clicking (e.g., to select days of the week 7 boxes labeled Sunday - Saturday would be displayed clicking a box would select it), or a pull down menu from which input could be selected (e.g., names of people or group aliases currently scheduled by the system). In addition for some fields on the meeting information form the user can instruct the system to search for a match and if a unique one is found, fill in the rest of the information form (For example if a user wants to cancel a meeting but cannot remember the date and time they can enter the title to call it up and cancel it).

- Simplify Please - hard to understand

The Daytimer Display

- Unclear

Above the month/week/day display will be one or two large buttons. If a Month View is displayed, 'Next Month` and 'Previous Month` buttons will be displayed. From weekly view, the 'Month View'

- We want a week view display button.

button will be visible on the upper left. Two buttons will be displayed above a day view, `Month View' and `Week View'.

FUNCTION: Login To System

	INPUTS:
		-login name
		-password
		
	OUTPUTS:
		-welcome message or

 - Do not want welcome message.

		-warning messages

 - Specify.

	DESCRIPTION OF OPERATION:
	
		- system requests the login name
		- enter the login name
		- verify the login name
		- if the login is valid then go to next step;
		  otherwise show warning message 1 and request
		  the login again
		- requests the password
		- enter the password (the characters won't be
		  shown on the screen for security reason)
		- verify the password
		- if the password is valid then show welcome
		  message and access is granted; otherwise
		  show warning message 2 and request the login 
		  again

 - 1) How do we "set" or "add" a password?
 - 2) How do we change passwords?
 - 3) How many tries before we are kicked out?

  FUNCTION: Select DAY VIEW from MONTH VIEW

      INPUTS:
        User left double-clicks on a day in monthly calendar.

 - Just to be clear: Which day is displayed when clicked on?

      OUTPUTS:
        MONTH VIEW calendar is replaced by DAY VIEW display.

      DESCRIPTION OF OPERATION:
        Move mouse to desired day -  left double-click

  FUNCTION: Select WEEK VIEW from WEEK VIEW

 - 1) Just a typo of course but should say "month" view.
 - 2) Also, there is a disparity here, previously you said there would be no "week view" but now you say there will be a week view -> Please be consistent! For the record: we want a separate "week view"

      INPUTS:
        User left double-clicks on WEEK button at left edge of desired
          week.

      OUTPUTS:
        MONTH VIEW display is replaced by WEEK VIEW display.

      DESCRIPTION OF OPERATION:
        Move mouse to left edge of week in calendar ->.  left double-click

  FUNCTION: Change to previous month

 - We also want a "previous" and "next" button for day and week.

      INPUTS:
        User left clicks on PREVIOUS MONTH icon at upper left corner of MONTH
          VIEW display.

      OUTPUTS:
        Current MONTH VIEW is replaced with previous MONTH VIEW.

      DESCRIPTION OF OPERATION:
        Move mouse to PREVIOUS MONTH icon -> left click

  FUNCTION: Change to next month

 - We also want a "previous" and "next" button for day and week.

      INPUTS:
        User left clicks on NEXT MONTH icon at upper left corner of MONTH
          VIEW display.

      OUTPUTS:
        Current MONTH VIEW is replaced with next MONTH VIEW.

      DESCRIPTION OF OPERATION:
        Move mouse to NEXT MONTH icon -> left click

  FUNCTION: Select MONTH VIEW from WEEK VIEW

      INPUTS:
        User left clicks on MONTH icon at upper left corner of WEEK VIEW
          Display.

      OUTPUTS:
        WEEK VIEW display is replaced by MONTH VIEW; month is the one
          containing the current week.

      DESCRIPTION OF OPERATION:
        Move mouse to MONTH VIEW icon -> left click

  FUNCTION: Select DAY VIEW from WEEK VIEW

      INPUTS:
        User left double-clicks on desired day in WEEK VIEW display.

      OUTPUTS:
        WEEK VIEW display is replaced by DAY VIEW.

      DESCRIPTION OF OPERATION:
        Move mouse pointer to desired day -> left double-click

  FUNCTION: Select MONTH VIEW from DAY VIEW

      INPUTS:
        User left clicks on MONTH VIEW icon at upper left corner of display.

      OUTPUTS:
        DAY VIEW display is replaced by MONTH VIEW display; month displayed is
          the one containing the current day.

      DESCRIPTION OF OPERATION:
        Move mouse pointer to MONTH VIEW icon -> left click

  FUNCTION: Select WEEK VIEW from DAY VIEW

      INPUTS:
        User left clicks on WEEK VIEW icon at upper left corner of display.

      OUTPUTS:
        DAY VIEW is replaced by WEEK VIEW display; week displayed is the one
          containing the current day.

      DESCRIPTION OF OPERATION:
        Move mouse pointer to WEEK VIEW icon -> left click


  FUNCTION: Print Out Currently Displayed Schedule

	INPUTS: From the Month, Week or Day view, the user clicks the large and obvious
        'print' button on the bottom left of the screen.

Sample Dialog

After entering her password to log into the application the main application screen appears, with a calendar view of January. Mary wants to see what went on last month, so she moves the mouse to the PREVIOUS MONTH button and clicks on it. The calendar view redraws, to display December.

Mary sees that Dec. 15,16, and 18 all have meetings. She doesn't remember what the meeting on the 18th was about, so she double-clicks the left mouse button on the 18th to bring up the DAY VIEW. The monthly calender for December is replaced by a notepad-style display of the hourly activities for Dec. 18th. Mary sees that there were two meetings on the 18th that she supposedly attended, because there are two short entries entitled "Sales Meeting" and "Project Wrapup". "Project Wrapup" is displayed in red, meaning it was high priority; Mary is pretty sure this was the final status meeting she remembers, but to make sure she clicks on the meeting title to bring up more information. To the right of the DAY VIEW window, the detailed information for the meeting is displayed.

RSVP Tab

Include all system messages here.

FUNCTION: Accept or Decline Meetings

	INPUT: User clicks on a meeting then clicks ACCEPT or DECLINE

	OUTPUT: Message stating 'meeting accepted' or `meeting declined`.

Availability Tab

We want to point and click; don't want text format (or we could have both, i.e. the option to point and click).

			o weekly (Mon - Fri)
			o Every Mon To Wed
				===    ===
			o Every Mon
				===
			o From dd/mm/yy to dd/mm/yy
			Again, we prefer dd/mm/yy.
				o Every Mon to Fri
					===    ===
				o Everyday
				o Except dd/mm/yy

			From HH:MM to HH:MM

		        o Available
			o Not Available

FUNCTION: Set hours of availability
		- allow user to set up his/her availability for
		  the appointment/meeting.

	INPUTS:
		- weekly
		- days range
		- date range
		- hour:minutes range
		- availabilty

	OUTPUTS:
		- confirmation message

	DESCRIPTION OF OPERATION:

		- User uses the mouse pointer to check the
		  appropiate choice of the date/day range:

The Meeting Scheduler Subsystem

We don't like this. We want to be able to click on a day and stuff pops up somewhere (e.g. to the right). We don't need a listing feature. All functions in this subsection use the meeting information form accessed by clicking the Meeting Manager tab then clicking on a meeting listed on the tab or clicking the Schedule Meeting button to get a blank meeting information form. The Meeting information form has the following fields that can be edited as described:

1. Meeting Series: A dialogue box for user to input the title of a series of meetings. It can be any length or left blank if the meeting is not part of a series. User can click the field to display a pull-down menu listing all meeting series they have scheduled. They can select the meeting series from the pull-down menu.
2. Meeting Series Frequency>: Radio buttons for selecting daily, weekly or monthly
3. >Meeting Series Time: Time or range of times. (Attached to Meeting Series Days)
4. Meeting Series Days>: Day or days when meeting can be scheduled We want #1,2,3 and 4 of this to be in "availability tab" format.
5. Regular Attendees: List of people who will normally attend meetings We want either Regular Attendees or Attendess, not both (no need for repeating information).
6. Title: A dialogue box for user to input the topic, no limit on how many lines to input. Can select title of existing meeting from pull-down menu. (If no title entered the system will call the meeting "Untitled1 etc.)
7. Date(MM/DD/YY): by clicking on the calendar itself to select a date, or typed in. (Not optional although when scheduling this might be a range)
8. Time (HH:MM): by typing in the required time or range of times for meeting, if this is omitted, system will schedule meeting automatically.
9. Length (30 minutes time slots): by clicking on a scale to increase or decrease the time range.(Required input)
10. Attendees (names of people to attend meeting or group alias): by clicking on an group/employees list provided by system, or type in whoever (for example, guest speaker) that is not in the list..
11. Agenda: A dialogue box for user to input agenda, no limit on how many lines to input.
12. Priority(of the meeting being scheduled): by clicking on the color codes to indicate importance of meeting. User will set personal priority. There should be a default low priority when a meeting is set up.
13. Room Number (not connected to database - just a text field)

FUNCTION:  Display Meeting Information

INPUTS: 
	1) Meeting manager file icon

	2) Weekly mode icon
	
	3) Daily mode icon
 
OUTPUTS:
	1) TOPIC - the topic of the meeting in a dialogue box

	2) DATE - in the form of month/day/year
	Day/month/year
	3) TIME - in hours and minutes
 
	4) LENGTH - displayed in 30 minute intervals

	5) ATTENDEES - includes the people who will attend the meeting

	6) AGENDA - an outline of what will be discussed in the meeting
	Don't need this -- have a comments section instead.

	7) PRIORITY - a color code to indicate the importance of the meeting

	8) Who scheduled the meeting

	9) Room number of meeting 

FUNCTION:   Schedule meeting 
This is what we want:
	1) Propose meeting
	2) System gives best time and list of people who can't
	attend, and asks: "Do you want this meeting?"
	3) Confirm or cancel.
	4) If Cancel, keep re-proposing (or view alternate times)

INPUT:
	Enter information into new meeting information form as described above.
OUTPUT:

	System message that meeting is scheduled successfully or if unsuccessful best
        time and list of those who cannot attend (Can choose to schedule now or browse
        through alternative times.) Form will display information about the meeting
        once it is officially scheduled.

	TITLE: 
	DATES (MM/DD/YY): dd/mm/yy
	TIME (HH:MM): optional
	LENGTH (30 MINUTES TIME SLOTS):
	ATTENDEES:
	AGENDA:
	PRIORITY:

The user then inputs the ATTENDEES (people and/or group/s) invited to the meeting. Selection of people or group is provided by clicking on the list of employees icon. Additional people (not in employees list) who are required to attend the meetings can be typed in via the guest option. An AGENDA with no limits on the number of lines can then be typed in Don't need an agenda - we would prefer a "comments" section. by the user. The PRIORITY follows after this. User can specify the priority of the meeting by clicking on the color code provided. and received messages default to lowest priority

After the information is entered, the system will search for a time slot that will fit the requirements of this schedule. When the system finds an We would also like a "limits" function (e.g. limit to search to Jan 5- Jan 16). This is to your benefit, because it will shorten the search. available time slot that does not have conflict with anyone, the system will proceed to inform the user as well as the people or group scheduled to the meeting of the change in their schedules. If system is unable to find a time slot that will fit everyone's schedule, system will attempt to find the time slot that fit the user's schedule and the schedules of more than half of the people invited to attend this meeting. People who are unavailable at the chosen time slot will be listed for the user, and user can decide whether to accept this schedule or reject it. If user decides to accept it, the people who are unavailable to attend the scheduled meeting are informed about it so that they can try to change their own schedules to attend the meeting if possible. System will also inform the rest of the people who are able to make it about the change in their own schedules too.

Note: Places to hold meeting are always available to hold any number of people. Places are selected by the system. Places should not be selected by the system; it should be a text field. You can think of this feature as a "future employment" (i.e. you don't have to implement it now).

Sample interaction dialogue

FUNCTION: Cancel Meeting
          - cancel a meeting scheduled by the user
We would like:
	1) Convener to be able to cancel a meeting.  Thus, the meeting
	is cancelled for everyone.
	2) User to be able to cancel themselves, with a message somehow
	sent to the convener.


INPUT:

	- enough information into form that system can locate it or click on meeting
	 to pull it up. 
        - reason for cancelation (When prompted) We don't need this.
OUTPUT:

	-confirmation the meeting(s) has (have) been canceled giving Title(s) and list
	 of invitees.

Sample dialogue

FUNCTION: Change a Meeting

INPUT:   
 	- get meeting information form for the meeting(s)

OUTPUT:
 	- edited form
     	- changes meeting in database and informs invitees

FUNCTION DESCRIPTION:

To edit a scheduled meeting, 
     type over existing field text.

To save the changes,
     click on SAVE button

To cancel / abort changes,
     click on the CANCEL button

To add new aliases,
     click on the ALIASE button (see Add Aliases)

Sample Interaction Dialogue

There is no need for this. If a meeting is going to be changed, just cancel the meeting by cancelling everyone to attend, and then the user schedule another meeting.

Employee List Tab

FUNCTION: Add Employee

	INPUT: User CLicks on 'New Employee Button' and then types name and information
	       of new employee into a text box

	OUTPUT: List of employees is changed


FUNCTION: Add/Delete/Change Aliases:

	INPUT: If existing alias is to be modified it is double-clicked
		names of group members
		name of alias

	OUTPUT: Displays changed alias and/or alias list.

FUNCTION DESCRIPTION:

	Using the available list of employees, new aliases can be created or old ones
	added to by entering their names or dragging them in with the mouse.

Sample Dialogue

GLOSSARY OF INPUTS AND OUTPUTS

TERMS			FORMAT		VALUE
-----------------------------------------------------------------------------

AGENDA			Characters	Agenda of the meeting - unrestricted
					format

- We don't need this as part of the system.



ATTENDEES		Characters	Names of individual(s) invited to
					attend the meeting.

- There is no need to have attendees as well as regular attendees
as defined further below; simply have ATTENDEES.



AVAILABILITY				Hours that user is available or 
					unavailable


CONFIRMATION	



DAY VIEW		Current view of	  
			selected day


DATE 		MM/DD/YY	date of meeting to be scheduled. 
					date may be entered by
					  * clicking on the date on the 
					    calendar 
					  * typing in the value
					- Possible typos
					  * invalid format
					  * illogical date


- change the date format to dd/mm/yy, perhaps even something
  like 16 Jan 96



LENGTH 			1/2 hour frame	Duration of Meeting ??
					System detects for logical errors
					 if duration is more than **** hours

LOGIN NAME		characters      User's account name 

MEETING SERIES:                  	 A dialogue box for user to input the
                                         title of a series of meetings it can
					 be any length or left blank if the
					 meeting is not part of a series.
					 Users can click the field to display
                                         a pull-down menu listing all meeting
       					 series  they have scheduled. They can
     					 select the meeting series from the
					 pull-down menu.

MEETING SERIES DAY(S):			 Day or days when meeting can be
					 scheduled


MEETING SERIES FREQUENCY:  		Radio buttons for selecting daily,
					 weekly or monthly


MEETING SERIES TIME:  Time or range of times
                      (Attached to MEETING SERIES DAY(S))
 


PASSWORD   		6 - 8 length		digits / & characters 

MONTH VIEW		Current	view of
			calendar month
                

PRIORITY 		Buttons		Labelled HIGH / NORMAL	
					rank of meeting : HIGH - important
							  NORMAL - usual

REGULAR ATTENDEES:  	Employees		List of people who will
						normally attend meetings



TIME  			HH:MM		Numeric
					HH - hours, range 00-23
					MM - minutes, range 00-59
 					system assigned value, if not entered


- we don't the user to see and use a 24-clock. We would prefer AM
  and PM as it is easier for the user to work with.


TITLE:			Characters	topic of meeting
					- typo errors, not detected by system


WARNING MESSAGE1			Invalid login name!


WARNING MESSAGE 2			Invalid password!


WEEK VIEW                  		Current view of 	   
		                  	selected week
             
WELCOME MESSAGE				Access is granted.

The following plan outlines some of the prelimary work done on this project. We will discuss:

PRELIMINARY DATA STRUCTURES

• Employee
  • login
  • password
  • first name
  • last name
  • working hours begin
  • working hours duration
• Group (Each employee has his own group aliases)
  • group name
  • employee logins
• Meeting Place
  • place name
  • place address
  • maximum capacity (in humans)
• Meeting Info
  • topic (or meeting title)
  • place name
  • convenor login
  • attending employee logins
  • a priority for each employee, all set by convenor, may be altered individually
  • date
  • start time
  • duration
  • agenda (or meeting description)

PRELIMINARY ALGORITHM

Since this is the most complicated algorithm, and least dependent on implementation and language, our company has provided some pseudo-code. However, if we decide to implement the SQL structure for our database, we will not use this function.

The system will go through each day specified to check, and search from the start_time to the end_time for the best possible time when the most people can attend. When it gets to a new day, it calls the following function:

function GET_BEST_TIME_IN_DAY

parameters:
	      ( date,			// date to search
		start_time,		// beginning of time to check
		end_time,		// end of time to check
		duration,		// in .5 hours
		num_people_invited,	
		employee_ids[1 to num_people_invited],
					// person 1 is the convenor
		min_people_busy		// for return purposes
	      )

variables:
	i
	j
	k
	people_busy
	timetable[people_invited+1][48]	// position 0 in this array is
					// for the overall availability
	best time

algorithm:	

	min_people_busy = num_people_invited + 1
	best_time = -1

	for i = 1 to people_invited
	{
	// fills the timetable array with the schedules of people
	//  invited to the meeting.  A 1 in a position indicates
	//  that the person is busy for that 1/2 hr of the day. 
	//  A 0 indicates they are free.
		GET_EMPLOYEE_DAY_SCHEDULE (date, employee_id[i],
			 timetable[i])
	}

	for j = start_time to (end_time + 1 - duration)
	{
	   for i = 1 to num_people_invited
	   {
	      for k = 1 to duration
	      {
		 if timetable[i][j] = 1 then
		 {
		    if i = 1 then
			people_busy = people_busy + num_people_invited
			// if the convenor can't make it, nobody can
		    else
			people_busy = people_busy + 1
		    end if
		    exit for	// exit the for loop and check the
				// next person.  This one is
				// already unable to attend.
		  }
	      }  // end for k = 1 to duration
	   }  // end for i = 1 to num_people_invited

	   if people_busy = 0 then
		// this is a time when everyone is free.
		best_time = j
		min_people_busy = 0
		return best_time
	   else if people_busy < min_people_busy then
		// at least one person is busy.  Check next 
		// time slot, just in case
		best_time = j
		min_people_busy = people_busy
	}  // end for j = start_time ...

	return best_time

FUNCTION CLASSES

The functions are described in the Functional Specification area of this document. However, the following should highlight the relationships:

		Login
		  |
		  |
      -------------------------------------------------
      |            |      	  |		      |
Availability   Calendar         RSVP		Meeting Manager
	 	   |      (message system)            |
	           |      -------------------------------------              
		   \	  |		      |               |
 		    ------------------- Daily Schedule   Convened Mtgs    
		          |
		          |
		   Arrange Meetings

POSSIBLE IMPLEMENTATIONS

The implementations depend on what kind of platform and language we are going to use.

• Platform
  • Work Station - UNIX: There are some limitations on the systems.
  • PC - DOS based system: User friendly, less cost.
• Store the information
  • Using only file structure to store the information. If the information is not big, probobly we can store all the information into files, and using C or other programing language to program. but it may require lot of programming. Since we have limited time for this project, we may not using this option
  • Using database management system to store the information. If we have lot of information to store and lot of users, it is better to use database system. But it will require more database software package.

We will build the databases in Paradox, and use SQL for the maintaining of the database (adding, updating, deleting).

THE MINIMAL SYSTEM

The minimal system (Phase 1, slated for mid-February) will include all the features outlines in the functional specifications with the following exceptions:

• The system will not check holidays or long weekends and other special days that may not be regular workdays.
• The system will implement only a simple text based viewing of messages in strict format.
• Employees are booked for meetings without their consent. If the employee decides he cannot make it, he must cancel his appointment for that meeting
• One cannot point-and-click from RSVP to access the information for the said meeting
• On the calendar display, days with meetings scheduled will be highlighted as such. No extra information.
• The calendar and the Meeting Manager will not be connected in any way. No point-and-click to the calendar and automatically getting that day.
• When scheduling meetings, there will be no graphical assistance.
• The system will not notify a user of any new messages upon logging onto the system. It will be up to the user to check his "message area" for any messages he may have.
• Everyone in the company will have the availibility to book a meeting in any listed room, without regard to their position in the company.
• No meeting will span two days (e.g. 11:30pm - 1:00am)

- Please state:

OUR PROJECT TEAM

Project Overseer:

Software Design and Implementation:

User Documentation:

Quality Control and Testing:

This system is meant as a tool to assist a company in planning meetings, but as such, it is also designed to be useful for the employee as a daily planner.

The employee is considered available at all times for a meeting, unless he/she has made themsleves unavailable. This is as an added incentive for the employee to keep their planner up-to-date, and thus make the system as reliable and effective as possible.

- The system itself should be insentive enough for the users to keep their timetables up-to-date. This means the users will have to not hate the system.

What we have given you is a proposal for a daily planner system. Consider this our interpretation of your requirements for the system. If this interpretation does not correlate with your idea of a employee scheduling system, please understand that Axiom Enterprises is dedicated to the customer and what the customer demands.

TimeManage, Inc.

TimeManage, Inc.

---

---

Demostration/Product Evaluation

Introduction

We would like to re-iterate that it was a pleasure to work with Axiom enterprises. Your demonstrated product was, overall, better than we expected. It implemented and even expanded upon many of our specifications, and we will certainly keep Axiom in mind for our future software needs.
Axiom proved to be dedicated to customer satisfaction. In the inital stages of the design process, they seemed to have a different understanding of the desired product than we did, but from that point forward they went out of their way to understand and address our concerns. At the end of the project, they even went above and beyond the call of duty by modifying the user manual. Good job!

Design Goals That Were Met

The following expectations were fully met. First, the login process performed as requested. The basic functionality of the daytimer was also good, with the implementation of color coding to indicate priority of meetings, keyboard shortcuts for commonly used functions, scroll bars for viewing the images and listboxes, and overall ease of use. These were all requested, and all fully delivered.
Expectations were also met in the following specific areas. First, the range function for automatic scheduling was outstanding (though we still have some concerns about it, mentioned below). Also, the manual scheduling was perfect. It allowed the option of daily, monthly and weekly scheduling as requested. In addition, the alias function performed perfectly; it was smart enough to disallow double invitations. Finally, the system permitted different availability times for each day of the week -- just what we wanted for Christmas!

Expectations That Were Not Met

Later in the design process, were were told that the system would not give us a monthly view. This was one of our first requirements, and initially we were quite disappointed. However, after seeing the product evolve, we became convinced that the monthly view was not necessary.

Expectations Partially Met or Which We Aren't Sure Were Met

The first expectation that was only partially met was blocking availability for a split shift. Our initial specifications provided an example that suggested that sales persons may work some evenings and weekends. It seems that the only way of representing this is to set the whole day as available, and then schedule a personal activity for the middle of the day, when the sales person is not at work. While this seems to solve the problem, we feel it is a somewhat inelegant solution.
An uncertainty about the handling of time conflicts arose from the fact that their demo example had no time conflicts -- all attendees were available during the very first time slot. Thus, we have not had complete assurance that the system will be able to find an available time if the attendees have conflicting schedules. In a similar vein, we do not know what the system will do if there is no time in which all attendees can attend. These concerns were important to us during the design process, and we hope to get them cleared up.

Promises Over Which We Still Have Concerns

During the demonstration we did not see any reference to the confirmation window that would appear when a person was invited to attend a meeting. This feature was promised in the Detailed Design Document. During the demonstration, we saw an example of the auto scheduler, and the invited attendees did, indeed, seem to receive messages. However, we did not see a box asking the attendee to confirm or reject the invitation, as was specified in the Detailed Design Document.
In addition, we did not see a demonstration that all five types of system message were implemented. These messages were of utmost importance to us. Even though we have an image of the events on our daytimer, the system messages are an essential reminder of changes in events. For example, when a convenor schedules a meeting it is was essential that he or she receives a message about any invitees that could not attend.

Conclusion

Our only criticism about the demonstration itself is that it was too fast. Many of our aforementioned concerns would likely have been addressed in a longer demonstration. Also, a longer demonstration would have allowed some of the more important specifications to be addressed in greater detail. However, we are well aware of the time constraints and pressures we have placed on the suppliers of this product.
Overall, we must repeat that the delivered TimeTracker system was far better than we expected. We are certain that we have gotten our money's worth. Based on this good service, we will be more than willing to provide a reference for your company. Kudos for a job well done!

---

HOW USEFUL WAS THE DESIGN PROCESS

The design process of the TimeTracker daytimer system, created by our suppliers, contained many iterations. We, the customers, were able to assess the system step by step, as our suppliers designed and redesigned the system, and put their ideas on the web for us to view. >From the web, our customer group was able to get together and discuss whether TimeTracker met our needs. Any comments that we had were likewise put onto the web for our suppliers to view, allowing them to have an idea of what we liked about the system and what we wanted to have re-designed. Gradually, there was a progression from a daytimer that was not intuitive or easy to use to a sophisticated system that matched most of our demands. There were, however, both positive and negative aspects about the design process that we witnessed.

Positive Aspects of the Design Process:

1. Positive Feedback There was a sense of feedback and communication between ourselves and our supplier group. We met a couple of times with representatives of the suppliers to discuss what changes should be made to the TimeTracker system, and the reasons why we wanted to make them. These "face-to-face" meetings were valuable because we could discuss with them the weak and strong areas of TimeTracker. Feedback was also implemented through the web. We were able to assess our suppliers' system documentation and create inline comments (with links) to areas that we felt needed to be addressed. The web was a particularly easy way to link the supplier documentation and our evaluations together.

2. Dynamic Process: We feel that there was positive progress in the implementation of TimeTracker - ie: TimeTracker eventually evolved into the system that we envisioned. We were quite a demanding group and initially found fault with many of the specifications and design ideas that our suppliers created. However, as time passed (and lots of documentation changed hands), our suppliers worked and reworked their design ideas and came up with a good system.

Negative Aspects of the Design Process:

1. No Data Gathering Methods Used
Common methods for data gathering are interviewing, questionnaires and observation. Overall, our suppliers did not follow any of these methods in the design process. If, for example, our suppliers had interviewed us as to what we wanted or didn't want for the system, they could have avoided many design pitfalls. The only instances of contact with our suppliers were when WE had real problems with some aspect of the design and wanted to meet with them to voice our concerns.

2. No Testing
Our Supplier group did not thoroughly test TimeTracker design ideas using prototypes, with us as the testers, to determine the appeal of the interface. Designs were sometimes based on what suppliers thought would be a good interface, rather than what in reality was a good interface. The only working system we were able to actually see was during the final demo at the end of the course. It would have been a much better idea if our suppliers had created several system prototypes and tested the systems with us (the users) and then made further design decisions based upon testing observations.

3. Not Enough Feedback
We feel that time would have been much better spent if we had met face to face with our customers after we had read over what they planned to implement, rather than communicating our concerns through the web. In this way, we would have cut our a "middle-man" - THE WEB - and could have resolved many issues quickly and easily in meetings rather than waiting days and sometimes weeks to have our requests taken into consideration.

4. Didn't Know The Supplier Group
Our entire customer group met with the entire supplier group only once in the design process, and that was at the very beginning of the project. The fact that we were essentially dealing with face-less people had to hinder the design process somewhat. When we did meet with our suppliers, we interacted with only a couple of representatives of that group, and not the entire team. Perhaps those of the supplier group best equipped to address our concerns were never at these couple of meetings.

5. Problems With The Web
We spent much too much time writing and reading documentation from the web, rather than consulting with our supplier group. A better idea would have been for our suppliers to interview and regularly question us about what we wanted for the system, and then create a series of prototypes for us to evaluate and test. Further, we were often hindered by the fact that we couldn't get printouts of the screen snapshots - thus during system evaluations (ie: reading what they had documented), we usually had to follow what they had written rather than what the screen snapshots displayed. If our suppliers had at least supplied us with hardcopy printouts of the screen snap shots, our evaluation process would have been much easier. Lastly, we often had problems finding our suppliers' websights, as the sights sometimes changed between documentation submissions.

6. Negative Relationship
Our job as the customer group was to find fault with our suppliers' documentation. This led to a somewhat "negative" atmosphere between the two groups; basically, the only contact that we had was through their documentation and our responding comments (which were full of "We don't like this", and "Change that"). To our suppliers, we must have appeared overly demanding and whining. This is not a positive stance to have in a customer/supplier relationship.

---

FOR THE FUTURE, WE PROPOSE THESE CHANGES, SO THE DESIGN PROCESS IS IMPROVED:

There should be more face to face meetings between the two groups. Suppliers should be in more contact with customers so they can determine what customers like or don't like about a system, rather than waiting for huge documents to be read on the web, and after screen mockups have already been made. Supplier groups should interview the customers initially, and then continue to interview regularly to see if attitudes change about what the customers want. Further, prototypes should be created and tested with customers so that bad design features are quickly removed. There should be a positive relationship between the two groups rather than a negative connection. In this project, we were often arguing and competing, rather than cooperating and working together towards a common goal. Due to the fact that we communicated mostly by paper, both groups were dealing with faceless people - thus it was easy for an adversarial relationship to develop. Lastly, All the paper work created during the project should be used as a guideline for the next project, so mistakes can be avoided the next time around.

---

---

Last updated 10 Apr 96

by Douglas Robertson, Web Page coordinator for Customer Group #8.