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

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

Our Process 1. Understanding the problem 2. Determining our specific roles 3. Outlining a process 4. Mapping deadlines 5. Sketching a scenario 6. Determining the stakeholders 7. Specifying Enterprise FR and NFR, System FR and NFR 8. Illustrating through use case and dependency diagrams 9. Identifying issues 10. Resolving issues to come to an improved understanding 11. Creating a prototype 12. Compiling a presentation

Our roles RoleTeam MemberResponsibilities Team LeadSama Malik Map out the process, determine deadlines, coordinate meetings, and compile documentation Domain ExpertSadequa Azam Determine the scope of the problem, identify stakeholders, and analyze the existing system to compile Enterprise Requirements Requirements Engineers TJ Andrews, Thriveni Movva Determine the system functional and system non-functional requirements from the thin specifications, elaborate and expand on them to allow improved understanding DesignerScott Denson Translate requirements into product by designing the layout and functionality of the tool being developed

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

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

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

Use Case and Dependency Graph

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

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

SFR Dependency diagram

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

SNFR Dependency graph

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?

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.

Prototype – Login

Prototype – Home

Prototype – Calendar

Prototype – Create Meeting

Questions?