Customer Group #8

Our Evaluation of Our Supplier's Demo/Product (10 Apr 96)
  • Group Members (11 Jan 95)
  • Assignment (11 Jan 95)
  • Our Supplier Group
  • Initial Program Requirements (14 Jan 95)
  • Our Reply and Assessment of Our Supplier's Functional Specs and Mgmt Plan (30 Jan 96)
  • Our Supplier's Overall Design Document
  • Our Reply and Assessment of Our Supplier's Initial Version of their Overall Design (14 Feb 96)
  • Our Supplier's Detailed Design Document
  • Our Comments About Our Supplier's User Manual (19 Mar 96)
  • Our Evaluation of Our Supplier's Demo/Product

    Group Members

    Coral Burns Dave Francis Deb Howland
    Joel Klammer Jamie Kromrey Ryan McKay
    Dave Neufeld Shawn O'Rourke Lyndon Parakin
    Colin PoonTip Chuck Pugh Douglas Robertson

    The Assignment

    This is what "we" want:

    Write a specification for a group diary and time management system to support the timetabling of meetings and appointments across a group of co-workers. When an appointment is to be made which involves a number of people, the system finds a common slot in each of their diaries and arranges the appointment for that time. If no common slots are available, it interacts with the user to rearrange their personal diary to make room for the appointment.

    Initial Program Requirements

    Informal Specification of Requirements from Customer Group 8

    January 16, 1996

    TimeManage, Inc.

    1234 Tower Place
    Calgary, Alberta
    T1T 3U3

    Supplier Design Team, Inc.

    5678 Skyscraper Square
    Calgary, Alberta
    T4T 5V5

    To the design team:

    Our company is interested in a group daytimer and time-management system to support the time-tabling of meetings and appointments across a group of co-workers.

    In consultation, our group has devised requirements for the system as follows:

    The proposed system would create and delete appointments and meetings, and in addition, display information (eg. level of importance) concerning existing meetings. Each co-worker should be able to interact with the system to rearrange their personal daytimer.

    The daytimer would have twenty-four hour capability for a seven day week. This would allow an employee to set their own hours of work/ availability for appointments. For example - employees in the sales division require to work evening hours and weekends on occasion, whereas the support staff work a regular nine to five day.

    Employees would be able to schedule a meeting or appointment on a daily, weekly, or monthly basis, and as well, arrange for single "one-time-only" meetings. We would like persons to be scheduled into meetings by full name to ensure no confusion.

    When an employee schedules a meeting they should have the option to provide details of the meeting. These details should include the meeting topic, place, agenda, priority, etc... This information should be accessible to any of the employees who are scheduled to attend the meeting from their own personal daytimer schedule.

    Employees using this system should be required to enter a password (that is uniquely defined by the employee) to access their personal daytimer schedule. An individual's daytimer schedule should only be accessible to the individual, to prevent other persons from changing or viewing another employees daytimer schedule without their knowledge.

    Any employee using the system may add a meeting to the schedule in one of two ways:

    1) An employee should be able to request the system to search for the first available time slot that all requested co-workers needed at the meeting are available, looking for places with no conflicts within certain limits (such as time range, date range, etc.). If the system schedules a new meeting, it should somehow inform anyone who has been "newly" scheduled. If the system cannot create an acceptable meeting time in which all co-workers required are able to attend, then it searches for a time with the least possible conflict for the greatest amount of co-workers. Using this "new" meeting time, the system will inform those who cannot make the meeting, so that these employees can possibly re-schedule their other activities, while those who can attend the meeting are informed of the newly scheduled meeting by the system.

    Once the system sets up a meeting, the employee who has proposed the meeting requires a list of all those who have conflicts in their daytimer schedule, thereby having the ability to propose a new meeting time where more employees can attend. When the employee decides upon a final meeting time - as stated before - the system informs all persons scheduled to attend the meeting and those with conflicts are informed of the meeting time so that they can possibly re-schedule.

    Say, for example, that an employee would like to schedule a meeting with the other twelve members of a sales group. This employee will be able to tell the system to find a time for a meeting on Monday, Wednesday, or Thursday of the next two weeks, between 1pm and 7pm. If there are no conflicts, the system will simply schedule the meeting at the first available time slot, informing all those in the sales group of the change in schedule. If there are conflicts, the system will inform the employee of this (along with a list of those who cannot attend the desired meeting time) and the employee and the system can then work together to try and find some time slot in which most of the co-workers can attend.

    2) The employee may manually schedule a meeting. This would allow for all employees to choose specific times for meetings, with the system supplying names of those unavailable for the requested time. Furthermore, the employee should be able to specify a list of employees to invite as a single group name.

    For example, if someone would like to have a meeting at 8am on Friday for the banana sales group, the employee would propose a meeting with the "Banana Group" at 8am. The system can check if this is a good time for all employees in this group (ie: create a list of those who can't attend). If it isn't an appropriate time, the employee can check, let's say 2pm on Monday...and so on.

    Employees must have a way to cancel a previously scheduled meeting. However, only the employee who originally scheduled the meeting should have the ability to cancel the entire meeting for all those invited. Although, all employees should be able to cancel any meeting or activity on their own daytimer schedule. When any meeting is canceled all other employees must be informed.

    For example, Bob 'x' has scheduled a meeting with the Banana Sales group at a specific time. Bob has also agreed to attend a meeting the same day with the Pineapple Conservation group. However, Bob's wife has just gone into labour. Naturally, Bob must have a way to cancel the entire meeting he has scheduled with the Banana Group, and his attendance with the Pineapple Conservation Group.

    Additional desires for the system include a graphical interface and the use of a mouse. Our daytimer system will be visually divided into daily, weekly and monthly segments, allowing an employee to easily view his/her daily, weekly, monthly appointment schedule. Visually, the daytimer would appear to the screen somewhat like a real calendar. The system should also allow the user to print out a daily, weekly, or monthly schedule.

    Further, the system will include a simple coloring scheme (no more than 3 colors) to denote the importance of meetings that are already logged on the system. For example, a raquetball game would be considered a "low" priority and colored differently from a meeting with the president of a company. Further, the importance of a meeting should be adjustable (or modifiable) -ie: an employee will be able to easily change the color associated with a meeting. Thus, an employee, at a glance, can evaluate his/her schedule (eg. how busy a day, week or month is) and also view the importance of a meeting.

    Our desired system should be easy to use, user friendly, fast, efficient, flexible, and most notably, easy to learn.

    Under no circumstances is the system to re-arrange a person's schedule without their full knowledge and cooperation.

    We believe these specifications to be a reasonable starting point, and extend our wish for success in this project.

    Yours Sincerely,

    TimeManage, Inc.


    Our Reply to Our Supplier's Proposal

    January 30, 1996

    TimeManage, Inc.

    1234 Tower Place
    Calgary, Alberta
    T1T 3U3

    Supplier Design Team, Inc.

    5678 Skyscraper Square
    Calgary, Alberta
    T4T 5V5

    Re: Diary/Daytimer System

    To the design team:

    Thank you for your prompt reply to our specifications for the daytimer system. In general, your designs for the system meet most of our requirements. However, there seems to be a few misunderstandings that need clearing up. Hopefully, some of the problems we may have had in communicating our desires for the system can be clarified in the list below:

    1. The term meeting can be used interchangeably with the term appointment.

    2. We would like keyboard shortcuts for all major functions.

    3. The calendar is the focus of the system. We would like the user to be able to click on a specific day within the month view and have the system display all appointments for that day; that is, bring up an enlarged view of the entire day. Within the day view, if the user clicks on a specific appointment, all the information about that appointment will be displayed (to the right of the day view or perhaps in a new window).

    4. Some functions are too complicated or require passing through too many levels to get to; such as adding a new meeting. Simplify wherever possible using menus and/or buttons.

    5. Poor grammar and techno-talk made parts of the document confusing and unclear.

    In addition, we have annotated your specification document with comments in italics. We decided that it would be easier to point out some problem areas this way rather than listing them all here.

    Our group would like to meet with representatives from your supplier group (no more than three) to clear up these misunderstandings. Please e-mail burnsc or howland for a meeting to occur no later than 02 Feb 96.

    We look forward to meeting with you.

    Yours sincerely,

    TimeManage, Inc.

    Actual Assessment of Our Supplier's

    Functional Specification and Management Plan

  • We have boldfaced all the original document that we wish to make comments on.
  • We have italicized all of our comments.

    Functional Requirements and Management Plan Proposal


    Submitted by:

    Axiom Enterprises
    Software Engineering Division
    777 6th Street S.W.
    Calgary, Alberta
    T5V 3W3

      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 following document presents a Functional Specification and Management Plan pertaining to the TimeTracker scheduling software to be provided by Axiom Enterprises (Software Engineering Division).

    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

    The Meeting Scheduler Sub-System will have the following capabilities:
    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

    The personal Daytimer subsystem will provide employees with a graphical view of their schedule. Each employee will have to log into the system with a password to view their schedule for privacy. The personal Daytimer subsystem will have the following capabilities:
    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.

    Time Tracker will be based on an intuitive graphical interface using a mouse to facilitate the main interaction between an employee and the system. The interface will enable a person to easily and quickly view their schedule in daily, weekly, and monthly segments making use of a calendar metaphor. Further, the interface will include a simple coloring scheme used to denote the importance of particular meetings.

    User Interface

    The user interface described by Time Management Inc. has the following general characteristics: a graphical user interface that is easy to learn and use; in particular, it minimizes typing. With this in mind we start this section with a preliminary sketch of how such an interface might look and how it might be organized. We offer this description as a concrete point of departure for further discussion and fully expect that the final interface will be quite different. In particular, this section describes a system that is considerably more complex than we will be able to complete given the resources currently allocated to this project. For a description of the minimal system we intend to deliver see the management plan. In the next section of this report we will specify the functions this system will perform. While we have made an effort to describe how these functions will be carried out within the current interface we have also described the essential characteristics of any implementation of this sys The following is a sample of the screen interface:

    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 right side of the screen will have four subscreens overlaid on top of each other. These pages may be easily switched back and forth by pushing labeled tabs on top of them with the mouse. The four subscreens will be `RSVP', `Availability`, `Employees` and `Meeting Manager`.

    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 following sections describe sections of the screen and the functions the user can access from that section.

    The Daytimer Display

    Located on the left side of the screen, a month, week or individual day is displayed in this window. The calendar will have clickable 'day' boxes and tabs on the left to select each week. The week display will have clickable days and the day display will show the employees day broken into half hour increments.

    - 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
    		-login name
    		-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

    Mary Hacker comes into work on Jan. 4th, back from Christmas holidays. Since she's been away from work for a few weeks during the holidays, she enters the Time Tracker to refresh her memory on what her department has been up to.

    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

    This screen shows a list of all meetings that the employee has been requested to attend that they have yet to decline or accept. Clicking on a meeting brings up a two-button dialog box with the buttons ACCEPT and DECLINE, as well as all the meeting information.

    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

    This tab will present users with a number of buttons like those shown below to provide a wide variety of scheduling options. Items shown with lines beneath them will be pop-up menus Mon will present a pulldown list of days of the week. Times can be specified as available or unavailable. For example, an employee may enter his weekly hours as available and then enter a specific time on a specific day when they are unavailable.

    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.
    		- weekly
    		- days range
    		- date range
    		- hour:minutes range
    		- availabilty
    		- confirmation message
    		- User uses the mouse pointer to check the
    		  appropiate choice of the date/day range:

    The Meeting Scheduler Subsystem

    This important subsystem is dealt with through the 'Meeting Manager' page on the right side of the screen. Users first select 'Attending Meetings` (all meetings the user is scheduled to attend) or 'My Meetings' (all meetings the user has scheduled). The Meeting Manager page then shows a chronological list of all applicable meetings within the time period selected on the left.

    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)
    Generally all input and output will be displayed in the appropriate field of the form. The exceptions are prompts, warnings and confirmations from the system.

    FUNCTION:  Display Meeting Information
    	1) Meeting manager file icon
    	2) Weekly mode icon
    	3) Daily mode icon
    	1) TOPIC - the topic of the meeting in a dialogue box
    	2) DATE - in the form of month/day/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)
    	Enter information into new meeting information form as described above.
    	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.
    Function Description:
    To schedule a meeting, user has to click on the Meeting Manager tab. User will see a list of "My Meetings", by selecting any of the listed meetings there, users can view the particulars of that meeting. To schedule a new meeting, user has to select "New" at the end of the We would prefer this to be at the top of the list or, better still, a separate button list. A "Meeting Series Title" will display the following information:
    	DATES (MM/DD/YY): dd/mm/yy
    	TIME (HH:MM): optional
    We don't want text format. We would prefer something like a radio button containing the options of day, week and month. As this is a new meeting, user are required to input a meeting title, there is no limit on length of title or format of title input. DATE is the next item to be input by user. Users can click on the calendar itself or simply type in the specific date they want the meeting on. The default on the system would be to schedule meetings automatically. However, if the user plan to schedule a meeting at a specific time, the user can fill in the TIME option.

    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

    John would like to schedule a meeting for February 2 1996 involving the group alias TACO. He would also like the system to automatically schedule the meeting for him. The first thing that John will do is select the month february so the meeting can be scheduled. From the displayed month he will choose the date of February 2, that will be hilighted. When the date has been choosen, John will select the Meeting Manager function. This function will produce a window that will have a listing including "Attending" meetings and "My Meetings". John will then select "My Meetings", producing a list of meetings he has scheduled previously. >From "My Meetings" John will select the icon "new", and a "Meeting Series Title" window will be displayed. At this stage, he will begin to fill in the following information. The TOPIC, DATE, TIME, LENGTH, ATTENDEES, AGENDA, and PRIORITY of the meeting. Since John would like the system to automatically schedule the meeting, he will leave the TIME section blank, otherwise the the system will be in manual mode. The ATTENDEES that John would like to include is the TACO group. If John has forgotten who the TACO group included, he would choose the arrow icon in the ATTENDEE section. A window will appear, displaying a list of group alias, and the people employed by the company. In this window, John would simply select the TACO group alias and all the people in this group will be hilighted in the people section. When John has completed the schedule he would select the icon ACCEPT. A dialogue box will tell John if the scheduled time was successful. If successful, meaning more than half the people in the group were available, the system will send memos to the TACO group for replies. The other half of the group will be sent memos or John may have to manually schedule the meeting.
    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.
    	- 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.
    	-confirmation the meeting(s) has (have) been canceled giving Title(s) and list
    	 of invitees.
    Function Description: Once the user has displayed the meetings information form (In Meeting scheduler tab) they enter enough information to bring up the meeting scheduler form for the required meeting (or meeting series.) When information about a meeting series but not a particular meeting is displayed pressing the cancel button will begin the cancellation process. When information about a specific meeting is displayed pressing the cancel button will begin the process of cancelling the meeting. Next the system will prompt for a reason for canceling the meeting. After the user enters this, system will ask for final confirmation of the cancelation. If the cancellation is confirmed, all attendees will be informed of this.

    Sample dialogue

    Jack wants to cancel a meeting scheduled for January 19, 1997 8-9 am . Meeting title is 'Sales strategy for 97' meeting series is 'Sales group meetings'. Attendees Sales group and Mr. Sales Guru. Jack clicks the Schedule Meeting button on the Meeting Manager window. A blank meeting information form is displayed. He enters enough information to identify the meeting i.e., "Sales Strategy for 97" in the TITLE field, and the system will fill in the remaining fields. He can now press the Cancel Meeting button. He will then be prompted as to whether this is the meeting he wants to cancel. With a push of the 'yes' button the cancellation is confirmed, the database is updated and invitees are informed of the changes.

    FUNCTION: Change a Meeting
     	- get meeting information form for the meeting(s)
     	- edited form
         	- changes meeting in database and informs invitees
    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

    The Accounts Manager decides to change the Topic of the meeting, postpone his meeting` (from 10am) to 11am, to include (in that meeting) the Production Manager and the Sales Manager, and add a new item on the agenda. He clicks the 'Meeting Manager' tab, selects 'My Meetings', brings up the meeting information form for that meeting, edits the meeting data and then saves. All invitees are informed of the changed plans.

    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

    This page shows a list of employees in a pop-up menu, a list of available aliases, and buttons marked 'New Alias' and 'New Employee'.
    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.
    	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

    John Huey has been promoted from the Apples Production Team to the Banana Research / Development Team, Three new members have been added to the Banana Sales Team, and a new Quality Control Unit has been set up for the organization.


    AGENDA			Characters	Agenda of the meeting - unrestricted
    - 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 
    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 
    					  * 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
    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
  • Preliminary Algorithms
  • Function Classes
  • Possible Implementations
  • Minimal System we intend to deliver
    Each of the following represents a table of data, to be used by our database system.
    • 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)

    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
    	      ( date,			// date to search
    		start_time,		// beginning of time to check
    		end_time,		// end of time to check
    		duration,		// in .5 hours
    		employee_ids[1 to num_people_invited],
    					// person 1 is the convenor
    		min_people_busy		// for return purposes
    	timetable[people_invited+1][48]	// position 0 in this array is
    					// for the overall availability
    	best time
    	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],
    	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
    			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

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

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


    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.
    Base on the discussion above, we decided to use an interface builder, Delphi, and this is designed to work seamlessly with the Borland Database Engine.

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


    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)
    If time permits, the enhancements will be added in Phase 2 (slated for mid-April).

    - Please state:

  • what you are willing and able to do; and
  • then, what you're not willing to do as your statements above are unclear.

    - The minimal system must definitely implement the following features:

  • the point-and-click features to work on the calendar
  • graphical on-line assistance

    Project Overseer:

  • Paul Tomochko

    Software Design and Implementation:

  • Danny Yerex
  • Tom Schulz
  • Michael Cullingham
  • Rosina Ye
  • Russell Magee

    User Documentation:

  • Lin Chung
  • Lee Bin (Mabel) Khoo
  • HIU (Roger) Lee
  • Paul Sung

    Quality Control and Testing:

  • Nils (Hal) Henningsmoen
  • Christopher Mohr


    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.

    Our Assessment of Our Supplier Initial Overal Design Document

    February 15, 1996

    TimeManage, Inc.

    1234 Tower Place
    Calgary, Alberta
    T1T 3U3

    Supplier Design Team, Inc.

    5678 Skyscraper Square
    Calgary, Alberta
    T4T 5V5

    Re: The Overall Design Document

    To the design team:

    We would like to congratulate all employees of the Supplier Design Team on a job well done. The overall design document submitted to our company on February 12, 1996 addressed many of our concerns. Furthermore, the proposed system meets or exceeds many of our design requirements. Your design team appears to have a much better understanding of our business environment.

    However, before negotiating a final contract for the delivery of a daytime scheduler, we would like your design team to address the following concerns:

    The proposed interface is quite eye pleasing, but a number of buttons, scroll bars, and list boxes need minor improvement. There does not seem to be a consistent method of exiting certain windows - such as the 'Time Tracker Login' window, the 'Scheduler' window, and the 'Employees' window. Other windows, such as the 'Time Tracker Interface Prototype' window, the 'Availability' window, and the 'Messages' window appear to have no exit at all.

    Our company is also somewhat confused with the The 'Time Tracker Interface Prototype' window and the fact that it contains numerous scroll bars with unknown functions. There are two scroll bars on the left and right hand side of the weekly view display - do these scroll bars serve the same purpose? If so, please eliminate one. Also, the scroll bar, which is below the column listing the hours of the day, does not seem to serve a useful purpose. Lastly, the function of the scroll bar at the bottom of the weekly view has not been explained.

    Buttons in certain windows need further explanation as well. In particular, the 'Employees' window contains four buttons centered between the two list boxes that have not been described in your document.

    The listbox in the 'Messages' window should have a better way of displaying messages so that one could conveniently scan the list. Exactly what fields are displayed for each item in the list? Perhaps each message in the list should include: a number just for reference, the person originating the message, the type of message (the five types listed in your document), and some type of indicator for read vs. unread messages.

    In the 'Scheduler' window, the auto-scheduling function should have limits to indicate between which days a meeting can be searched for. For example, a worker may want to search for a possible meeting between Jan. 14th and Jan. 31st, and the auto-scheduling function should be able to search between these two date delimiters. Just for the record, we did require this function to be implemented.

    Upon careful scrutiny of the Overall Design Document, we also have a number of concerns dealing with the functionality of the system.

    The system synopsis states that the system will inform an employee that there are new messages. Unfortunately, our analysis team has not found this feature on the proposed system. We suggest that there be a cue on the 'Time Tracker Interface Prototype' window. We like the idea of using a very visible icon to indicate new messages - perhaps an icon of a flag or mailbox? As indicated in our previous correspondence, this feature is fundamental.

    There does not appear to be a way to delete messages from the 'Messages' window, and it is unclear whether previously read messages can also be viewed. Since your proposed system allows the employee to mark a message as read, it would be useful to be able to delete these messages. Perhaps we do not understand the functionality of the button named 'mark as read' - please clarify this in your detailed design document.

    Although we are pleased that the proposed design displays the weekly view as requested, we are not sure that you have implemented a daily view. Your document refers to a daily view in the section 'Your Amendments'. Apparently double clicking a day on the month calendar will provide a daily view. Is this true? Or does the day that is clicked on in the month calendar just appear to be the first day listed on the weekly view? We would like to know exactly what the system does if one double clicks on a day in the month calendar. We are not adverse to a system whereby a user clicks on a day in the month view, this day appears as the first day in the weekview, and then to get more information about, let's say, a meeting on Monday from 8:00am to 8:30am, the user clicks on this time slot as indicated in the weekly view and is able to find out more details (ie: comments, invitees, date, time, place, etc.) about this meeting. If this idea is implemented there should be some kind of title on the time slot (eg. 8:00am to 8:30am in the weekly view) that gives the user some kind of idea of what the meeting entails - for example, a tag that says 'banana sales'. In this way, the user would know at a glance that he/she has a banana sales meeting at 8:00am, and if need be, to obtain more meeting information, could just click on the 8:00am to 8:30 time slot and this additional information would pop up.

    The 'Availability' window for the proposed system seems to be missing some features that our original requirements specified. Here at TimeManage Inc., our hours of availability vary from day to day. We have interpreted that your 'Availability' window allows us to choose only ONE start and ONE end time and the days that the selected start time and selected end time encompass. However, what if an employee works 9:00am to 2:00pm on Monday, Wednesday and Friday and 1:00pm to 4:00pm on Tuesday and Thursdays? Of course, it is obvious that we need a more flexible system whereby the start and end times can vary for each day. Furthermore, we have noticed that your document discusses time in both a 24 hour and 12 hour context. We prefer the use of a 12 hour am/pm clock, and ask that you please stick to this convention.

    In the specifications of the system there is a feature which allows us to schedule monthly meetings. We are not sure if this includes the ability to schedule by the day of the month (for example: the third Tuesday each month), or the date of the month (for example: the 15th day of each month), or both.

    A few simple clarifications are needed concerning how the system deals with employees. First, the 'Employees' window contains a listbox containing a list of all employees. We are uncertain how the employee list is maintained. Second, the document refers to an employee 'id number'. We do not know what purpose this number serves or how the number is generated - ie: does the system generate the number

    In addition to the above issues concerning the interface and functionality of the proposed system, we would like a few topics added to the Detailed Design Document. Due to our limited exposure to Data Flow Diagrams, we had difficulty reading and understanding the Data Flow Diagrams that are included in your document. We would greatly appreciate a set of short instructions explaining how these diagrams work. Also, a data dictionary would provide reference for terminology that is too technical.

    We ask that your company also include a summary of the specific functions the completed system will perform. This will assist in the contract negotiation by preventing any misunderstandings concerning the delivered product.

    Thank you for your immediate attention to the above concerns. In closing we would like to emphasize that we are confident that your design team have the necessary drive and capabilities to provide TimeManage Inc. with an acceptable product. Please provide our company with a Detailed Design Document on or before February 22, 1996. At that time negotiations for completing a contract will be arranged.

    We look forward to these contract negotiations.

    Yours sincerely,

    TimeManage, Inc.

    Demostration/Product Evaluation


    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.


    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!


    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.


    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.