Synergy Meeting Scheduler System

1. Synergy Meeting Scheduler System T-squared, S-cubed TJ Andrews Thriveni Movva Sadequa Azam Sama Malik Scott Denson

2. Purpose • Develop a software that would help users schedule meetings more easily and intelligently • The software should outperform any such system that is currently available in the highly competitive market • The software should be adaptable to any application, such as scheduling courses, flights, room assignments at hospitals and hotels, and much more

3. Our Process • Understanding the problem • Determining our specific roles • Outlining a process • Mapping deadlines • Sketching a scenario • Determining the stakeholders • Specifying Enterprise FR and NFR, System FR and NFR • Illustrating through use case and dependency diagrams • Identifying issues • Resolving issues to come to an improved understanding • Creating a prototype • Compiling a presentation

4. Our roles

5. Stakeholders • Users: meeting initiators, important participants, active participants, potential participants, administrators • Customer: Synergy Soft, Inc • Subjectworld: Domain experts • Developersworld: • Business Analyst—gather requirements • Systems Analyst—design the system • Developers—Implement and maintain the system • Management team—forecasting, planning, marketing, budgeting

6. Enterprise Requirements Existing process: • Send meeting invite with anticipated date, location, and time to list of unranked users • Receive responses sporadically throughout the day requesting time change, location change, date change, cancellations, etc • Accommodate changes and send invite again. Vicious cycle repeats… Existing problems (in various existing software): • Attendees cannot specify preference or exclusion ranges for meeting date • Initiator cannot specify multiple ways or locations to have meeting • No option to select location and view availability of rooms and the equipment offered • Meeting initiator cannot track status of invite—what step comes next? • Only 2 ways to receive e-mail updates: as attendees respond or end of day • Attendees cannot suggest alternate dates except in the comments box Good functionality user wishes to retain: • Previewing the invitation at the end • Initiator can designate up to 10 dates for preliminary selection

7. Enterprise Requirements Mandatory requirements: • Allow all participants to specify preference and exclusion sets for dates • Allow active participants to request special equipment • Allow important participants to request meeting location preferences Input to the system: • Exclusion set—set of dates on which participants cannot attend meeting • Preference set—set of dates participants prefer meeting to take place • Date is a pair of calendar date and time period • Exclusion and Preference set together = Date Range • Proposed meeting date = Date Range - Exclusion set while covering as many dates from the Preference set as possible

8. Use Case and Dependency Graph

9. System Functional Requirements • Secure login — username and password • Online system accessed from a web based interface • Enable scheduling meeting between initiator and all participants. • Invite should include: meeting subject, proposed date/time range, location, and any additional details or attachments • Allow participant to choose whether can or cannot attend • Allow users to change preferences, including preferred date set, exclusion set (exclusion set, for example, might be vacation time, sick time, etc) • Assist initiators by making available all participants’ schedules, and their preferred date set and exclusion set • Manage all interactions that all participants might participate in, such as • Communication requests • Responses to a meeting • Negotiations and conflicts between participants • Alert participants of current status of the meeting

10. System Functional Requirements • Support conflict resolution — stated by client (feature that has a list of pre-made options for client to pick from) • Support a rescheduling feature • Initiator might reschedule based on what he sees in attendance • System might warn initiator that not enough attendees based on a threshold set. • If a constraint changes, such as a meeting place must be used by a more important meeting, then a reschedule must occur • Support a level of importance on each participant, allow initiator to designate important, and if they are a mandatory participant • If a mandatory participant cannot make it, system alerts the initiator and suggests a time that is better suited for all mandatory participants • Manage concurrency—handle several meetings occurring in parallel • Must have a repository for available locations, size they can accommodate, and equipment they offer

11. SFR Dependency diagram

12. System non-functional requirements • Usability/User-Friendliness • Robustness • Extensibility • Privacy/Security • Reliability • Customizability • Flexibility • Performance

13. SNFR Dependency graph

14. Issues • ISSUE 1: Who are the non-privileged participants? • ISSUE 2: What does “accurately monitored” mean in the SNFR? • ISSUE 3: How is the system setup and maintained, such as available locations and equipment, etc? • ISSUE 4: How to determine who is an active participant and who is an important participant? • ISSUE 5: What is nomadicity? • ISSUE 6: When and how often will the system decide to schedule or reschedule the meetings? • ISSUE 7: How do we know who the user is that is using the system?

15. Improved Understanding • RESOLUTION 1: Non-privileged participant attends a meeting but cannot see certain privileged information such as meetings responses • RESOLUTION 2: “Accurately Monitored” needs further clarification from stakeholders. Possibilities: Logistics are monitored, or reflects the status of the virtual meeting • RESOLUTION 3: An administrator would setup and maintain the system, including list of equipment and locations • RESOLUTION 4: Initiator of meeting determines who is an active participant and who is an important participant for that meeting • RESOLUTION 5: Nomadicity could mean portability or mobility of the system, the user, or the location. Needs further clarification from stakeholders • RESOLUTION 6: System will initially schedule a meeting when a predetermined threshold has been met of important participants, or the meeting initiator decides to schedule it. It might be rescheduled when a predetermined threshold of participants cannot attend, or another conflict occurs • RESOLUTION 7: The administrator will setup all accounts for users, including login name and password. The users will use this to validate who they are.

16. Prototype – Login

17. Prototype – Home

18. Prototype – Calendar

19. Prototype – Create Meeting

20. Questions?