Josh's Brainstorming

Why? There are many aspects in our lives that we need to deal with, scheduling classes and flights, room assignments at hospitals, scheduling domestic and international meetings and etc... Many softwares are provided for support, and yet, clarity in customer needs is a problem. As long as requirements are lucid, the cost of application and production will be held to a minimum.

What do we need?

1. A scheduler, which deals with all scheduling information.
   • Goal: is to reduce communication costs and time costs
2. Database: which saves the information of all possible users available.
   • Data included: calendar, physical rooms data, virtual room data, user information, user preferences (dates they can and can’t attend meetings), scheduled meetings,
3. GUI, the interface that the user will interact with.

How everything works

All the requirements and specifics will be manually inputted by the client and sent to the server side. The server will then deal with all the scheduling information.

What the client needs to know:

1. hardware requirements (i.e. explore 6.0, XP…)
2. Information requirements (what information is needed to schedule a meeting)
3. Our system is user-friend
4. Please respond to the server messages of scheduled meeting ASAP

Client side

Register New user:

1. Login to www.oursystem.com the system website
2. Create user, by adding all data stated above
3. Wait a few days for the registration to be authorized by us.
4. Registration granted/denied

Reschedule/Schedule a meeting:

1. Login to website
2. Replan/Request for a meeting (must be requested 7 days before the actual meeting time)
3. Identify the preferred date/time/location/monitoring user.
4. Scheduled meeting status
   • Granted (all set)
   • pending (still scheduling)
   • modification (modification of meeting data required)
   • rejected (can’t schedule meeting)

Server side

(assuming all information is inputted and updated)

Assumptions

1. Our server is secure, privacy is guaranteed, so I think we should run this under https???
2. Our database information will not have any flaw.
3. We assume that all users will respond ASAP (within 24 hours) to the meeting request

Technical issues

1. Concurrency issues, this is an implementation part, so I think we can deal with this later on. (meeting requests and in-meeting communication)

Preprocess the information sent by the client (to rectify the information before the scheduler actually schedules the meeting)

1. Receives the data from the client
2. Checks if there are any conflicts in the information
3. If there is, respond to the client for rectification, else, send information to the scheduler.

Meeting setups

1. collects all the information being sent from the client
2. identify all users that are requested to be involved in the meeting
3. we run the programs to determine if the meeting can be scheduled (I propose that we use the priority algorithms in operating systems. (I believe the rest of the information is implementation issues, so I’m not stating anything about it as of right now)
4. if meeting is not scheduled, send the unscheduled meeting results to the user, if needed for further assistance, repeat from step 1. Else, send out an invitation to all users about the scheduled meeting. We are assuming that they will follow their preferences as given in the database.
5. We book the meeting when finalized.

The Database

Components

1. Information for all users
   • Preferences for meeting time
   • Current location (real-time update?)
   • Personal information
2. Physical rooms available
3. Virtual rooms available
4. Scheduled meeting information (there might be cases where rescheduling is being requested even before the server responds to the client, so we need to have information about this)

This is it folks, feel free to critique.

---

Russell's Brainstorming

1. Go to the office where the sign up sheet is located.
2. Pick several dates and times for a meeting.
   • Room size
   • Teleconference availability
3. Email meeting participants to see who is available when, based on chosen dates and times.
4. If all participants available at same date and time, go to step 5, if not repeat from step 1.
5. Go back to sign up sheet, if chosen time and date is still available, then sign up and go to step 6, else go to step 1.
6. Email all participants the date, time and location of meeting.
7. If not using email then visit/call each participant or send memo to tell each participant the date, time and location of meeting.

---

José's Brainstorming

Requirement-Prioritize meetings

0. Continue from Russell's step 6-7 but with a added funtion.
1. Create meeting with either low, medium, high priorty.
2. Priority meanings:
   • Low-Meeting is considered not urgent at all but required
   • Medium-Meeting is consider semi-urgent and has higher precendence then Low prioirty meetings
   • High-Meeting is consider of the highest urgency and has precedence over all others(such as Low and Medium)
   • Note: Meetings encountered with the same priority have the same precedence
3. Then meeting will be then set up according to date, time and location of meeting and then if all else fails and there is two meetings at the same date,time and location then this is where the meetings priority comes into play.
4. Meeting priorty is checked with the other meeting(s) priority. If conflicting meeting has different has different priority then continue to step 5 and if the have the same continue to step 6.
5. If created meeting has higher priorty then prompt user whether it is ok to overwrite current meeting or ask user whether to change the meeting date,time or location depending on the conflicting attribute.If meeting is overwrite then notify the participants of that meeting that the meeting has been changed due to a meeting of higher importance. If meeting being created is lower priority then inform user that meeting cannot be created.
6. If the same then meeting will not be created.
7. Email all participants the date, time and location of meeting.(Russell's step)
8. If not using email then visit/call each participant or send memo to tell each participant the date, time and location of meeting.(Russell's step)

Constraints:

1. Only allow certain number of users to have the ability to select meetings of high importance such as a CEO.
2. Only allow overwriting of meeting(s) over a certain period of time:
   • Low- Never since low priority meetings can't get precedence over any other priority including itself
   • Medium- Created within 5 days or more before actual meeting is going to be held (Note only applicable to Low priority)
   • High- Created within 1 or 2(Not sure yet) days or more before actual meeting is going to be held (Note only applicable to Medium and Low priorities)

---

Elodie's Brainstorming

1. Login in case you're in the system. Otherwise create a username and password
2. Reserve a date to schedule a meeting.
3. Make sure that the meeting room, the time and all people that will attend the meeting are available
   • if conflicts occur, extend the date range or have some participants remove/add some dates or withdraw from the meeting
   • if conflicts do not occur, then reserve the room and pick the participants
4. Specify the room requirements (telephone, projectors, etc.)
5. Specify the objective of the meeting
6. Contact participants
7. Confirm your reservation
8. Notify the participants
9. Send Reminders

---

Daniel's Brainstorming

1. Login the system in case you have username and password, if not, create one. Details: when create an account, please provide some concrete info such as *username, *password, *Email(for the notification of future meetings)，phone number,address, title and so forth.
2. System manager authorizes the registration.
3. Initiator creates a meeting. Details: a. *provide the subject, *date range(including time), *candidate location,descriptions.
   2. pick up potential attendees(first name, last name) and mark up the feature of participants such as important(in my mind, this time initiator can not make decision on whether the participants are active or not).
   3. submit to the database, at the same time notify the attendees by email and via this meeting system.(In the notification, initiators can ask whether the attendees would like to provide equipment).
4. The candidate attendees feedback information Details: a. whether they would like to attend the meeting.
   2. whether they would like to provide equipment. If yes, what kinds of?
5. The initiator deletes the people who do not attend the meetings and mark up the people who provide equipment with the mark “Active”.
6. The potential attendees choose their preference set and exclusion set. Important attendees also provide the preferred meeting location.
7. If there is no confliction on time, location, meeting room and equipment is available,Initiator send memo to all attendees. If confliction occurs, initiator extends the date range, or some participants remove some dates from exclusive set, or some participants withdraw from the meeting, or some participants add some new dates to their preference set. After the solution on confliction, sends memo to all attendees.

---

Eric's Brainstorming

We will likely want to use fuzzy logic for determining ideal meeting times.

All requests from users are notified using standard email - a link is provided for actual input.

In real practice, we would not have the setup like y'all are describing. We would use LDAP to get information about users. There may be a minimal setup, but it would not be to decide username and passwords.

We should probably have support for optional attendees.

Primary Use Case: Schedule a Meeting

I would like to incorporate meeting priorities. I like the idea of user definable priorities.

1. A meeting initiator (MI) creates a potential meeting (PM). It has a duration and schedule date-time range.
2. The MI adds important participants (IP), active participants (AP), and other potential meeting attendees (OPMA) to their respective lists. IP+AP+OPMA are the potential meeting attendees (PMA).
3. The MI sets who to allow giving preferred times: PMA, IP+AP, IP, or none. If not none, then MI sets timeout.
4. The MI sets who to allow giving preferred locations: IP or none. If not none, then MI sets timeout.
5. The MI sets the timeout for AP to submit equipment requests.
6. The system looks at calendars of PMA and generates a view of the given date-time range with scores of possible meeting times. This would be a nice place to use fuzzy logic. A score would be the number of PMA able to attend a certain meeting time (it could be fuzzy by saying that a member is able attend .95 of the meeting) divided by number of PMA. Meeting times would be sorted based on score. If all scores are < 1, then a conflict has occurred. It is neither a weak nor strong conflict because the preference set has not been consulted.
7. The system requests preferred times from attendees based on 3. The attendees select from list generated during 6 with a score of 1. When a sufficient number of meeting times do not score a 1, then the top meeting times are provided. For each meeting less than 1 provided, then a list of attendees who did not score a 1 for the meeting is also provided.
8. The system requests needed equipment from AP.
9. When all AP provide (possibly empty) equipment requests, or the timeout occurs, the system computes available rooms based on number of PMA and equipment requests. The system requests room preference of IP from this list.
10. Room and meeting time preferences are used to compute the final meeting time. Highest preference score wins, but may want the ability to give favor to sooner meeting times.
11. System notifies PMA.