Synergy Meeting Scheduler System

T-squared, S-cubedTJ 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 problem2. Determining our specific roles3. Outlining a process4. Mapping deadlines5. Sketching a scenario6. Determining the stakeholders7. Specifying Enterprise FR and NFR, System FR and NFR8. Illustrating through use case and dependency diagrams9. Identifying issues10. Resolving issues to come to an improved understanding11. Creating a prototype12. Compiling a presentation

Our roles

Role Team Member Responsibilities

Team Lead Sama MalikMap out the process, determine

deadlines, coordinate meetings, and compile documentation

Domain Expert Sadequa 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

Designer Scott 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 RequirementsExisting 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

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?