2010 Organizing a Better Future HighImpactSoft 2010 Organizing a Better Future

Changes to Presentation Scope has been added Problem statement has been added Why our team is the best has been added Creeping rate has been added

Agenda Specify Goals Problem Statement Scope Definitions Process Model Preliminary Requirements Issues and solutions Traceability Prototype Change Creeping rate

Goal The primary goal of this project is to provide a complete requirements description for the Distributed Meeting Scheduler(DMS) for HighImpactSoft, Inc. HighImpactSoft has provided an initial description of DMS and it is our task to refine, enhance, and develop this initial description into a complete requirements document.

Problem Statement Problem - This project is designed for a system where people currently schedule meetings manually or using software systems like Outlook, Notes or Calendar for scheduling their meeting. As the number to entities increase the complexity scheduling process increases exponentially. Issues with scheduling meetings manually include – No. of participants not precise Time Consumption More Conflicts Functionalities are limited Re-scheduling problem

Scope The project Distributed Meeting Scheduler automates the process of scheduling meetings. It is a type of resource allocation and collaboration system. The main function of this project is to schedule meetings based on the availability of resources and constraints put forward by the resources.

Definitions Meeting: scheduled gathering of two or more people. Meeting parameters include: date, time, initiator, participants, place (physical or virtual) Meeting initiator: A person who initiates a meeting, notifies possible participants, determines potential meeting dates/times/places; may also be a participant. Potential attendee: A person who provides a set of dates when they may or may not be able to attend a proposed meeting. Participant: A person who attends a meeting. Exclusion set: set of dates provided by potential attendees when they cannot attend a proposed meeting. Preference set: set of dates provided by potential attendees when they can attend a proposed meeting. Active participant- A meeting attendee who will do a presentation Important participant: A meeting attendee who must be in the meeting Regular participant: A meeting attendee who is not an active or important participant OO: Object-Oriented GUI: Graphical User Interface SE: Systems Engineering SRS: Software Requirements Specification

Why our team is the best Our system will remind participants of upcoming meetings which is an idea that we have incorporated from Rachel’s team. Furthermore, our system gives the initiator control over the final decision of when a meeting will take place and minimizes the problem of meeting location by accommodating locations on a first come first serve basis. For participants, DNS will only inquire them about their exclusion set and not the preference set or their preferred location. This will minimize the amount of information that a participant will need to enter when accepting an invitation. To make the system more secure, our system is designed to send an invite to a meeting participant only if his/her username or email id is known by the initiator.

Process Model

Preliminary Domain Specifications

The proposal should be made as early as possible. Issue: The term as early as possible needs to be defined. How much time is as early as possible? Option 1: The conflict must be resolved within one week or the meeting will be rescheduled. Option 2: The system automatically calculates a meeting date after a time specified by the initiator. Option 3: The system automatically calculates a meeting date within 30 minutes. Solution: option 1 and 2 (administrator gets help in resolving available times).

The proposal should be made as early as possible. Issue: The term as early as possible needs to be defined. How much time is as early as possible? Option 1: The conflict must be resolved within one week or the meeting will be rescheduled. Option 2: The system automatically calculates a meeting date after a time specified by the initiator. Option 3: The system automatically calculates a meeting date within 30 minutes. Solution: option 1 and 2 (administrator gets help in resolving available times).

Location should belong to one of the locations preferred by as many important participants as possible Issue: location availability and time preference can conflict and importance or precedence is an issue. Option 1: Define exclusion/preference sets as most critical and thus fully taken into account first. Location preference by important participants taken into account only after all time sets taken into account. Option 2: Create a point system defining the level of importance of meeting attendees. Let the program take into account the level of importance of attendee and define some algorithm that balances importance of an attendee and define some algorithm that balances importance versus location/exclusion/preference sets. Solution: option 1 (due to limited time and resources of implementation)

In application Domain, meetings are typically arranged in the following manner. Issue: Typically creates multiple ways to arrange a meeting. Option: Remove typically and choose one method of making meetings. Option 2: Describe all ways in which meeting will be made and incorporate them into program. Solution: option 1 (option 1 reduces complexity of problem)

The exclusion and preference set should be contained in some interval prescribed by the meeting initiator (which will be referred to date range) Issue: interval is incompletely described and identified. Option 1: Time interval defined to start calendar date (12:00 am) – end calendar date (12:00am) Option 2: Time interval defined to consist of start calendar date and start time – end calendar time and end time. Solution: option 1 (reduces variables

The number of negotiations should be kept minimal, but a new round of negotiations may be required when no such room can be found. Issue: The terms minimal and negotiations need to be defined. Option 1: The term negotiation is an attempt between two or more important participants to reach a compromise on where a meeting should be held. Option 2: When setting up a meeting, the initiator can set a maximum amount of negotiations. When the maximum number is reached, the initiator will choose the final location him/her self. Option 3: The maximum number of negotiations is 10. When the maximum number is reached, the initiator will choose the final location him/her self. Solution: Option 1 + Option 2

Option 2: Reserve rooms based on a first-come-first-serve basis. Meeting requests can be competing when they overlap in time or space. Concurrency must thus be managed. Problem: This requirement seems to make an allowance for an overlap in space. Option 1: Allow the same location to be requested by multiple initiators and resolve the conflict. Option 2: Reserve rooms based on a first-come-first-serve basis. Solution: 2 Reason: Reserving rooms based on a first-come-first-serve basis eliminates any overlap in meeting space and is easy to implement.

Preliminary Functional Requirements Specifications

“The purpose of DMS is to support the organization of meetings – that is, to determine, for each meeting request, a meeting date and location so that most of the intended participants will effectively participate.” Problem: The meeting time is not specified. Option 1: Include time in addition to the meeting date. Option 2: Leave the requirement as is. Solution: 1 Reason: A meeting scheduler by its very name requires that not only the date a meeting convenes but the time at which it convenes should be specified

“to keep participants informed about schedules and their changes.” Problem: This statement doesn’t say how to keep participants informed. Option 1: Send emails to alert prospective attendees of schedule invitations, rescheduled times/dates, and cancellations. Option 2: Remind the meeting initiator to alert prospective attendees of schedule invitations, rescheduled times/dates, and cancellations. Solution: 1 Reason: Emailing prospective attendees of schedule invitations, rescheduled times/dates, and cancellations can be done automatically by the program, eliminating human error.

“it should ideally belong to as many preference sets as possible.”   Problem: This leaves it open whether the program should automatically select a date that is in the largest set of intersecting preference sets or whether the date should be selected by the initiator. Option 1: The system automatically selects the meeting date. Option 2: The initiator selects the meeting date. Option 3: The system suggests the meeting date and asks for the initiator to either confirm the suggested date or select an alternate date. Solution 3: Option 3 allows is an ideal solution because it offers a high degree of control and flexibility. Having the initiator confirm the meeting date also provides an active reminder of the selected date.

“Meeting requests can be competing when they overlap in time or space “Meeting requests can be competing when they overlap in time or space. Concurrency must thus be managed.” Problem: This requirement seems to make an allowance for an overlap in space.   Option 1: Allow the same location to be requested by multiple initiators and resolve the conflict. Option 2: Reserve rooms based on a first-come-first-serve basis. Solution: 2 Reason: Reserving rooms based on a first-come-first-serve basis eliminates any overlap in meeting space and is easy to implement.

“The initiator could also ask, in a friendly manner, active participants to provide any special equipment requirements on the meeting location (e.g., overhead projector, workstation, network connection, telephone, etc.).”   Problem: Besides the ambiguity over “active” and “important” participants, the requirements are presented clearly regarding the equipment requirements. Solution: Options for any special equipment requirements need to be included along with the meeting time, date, and location preference options.

Preliminary Non functional Requirements

Solution - Option 1 + Option 2 + Option 3 ISSUE 1 [NFR – 1] Requirement - A meeting should be accurately monitored, especially when it is held in a virtual place. Here, nomadicity will then be important to consider; Description – The requirement here is incomplete & unsound. The word accurately is not defined and cannot be measured. It does not specify what the system should monitor and how should it be monitored exactly. Is it the proceedings of the meeting or the presence of participants or anything else? Option 1 - Attendees of the meeting are monitored. The presence of important and active participants is taken care of. Option 2 - The process of the meeting is taken care of. The attendees of every period of the meeting are taken care of. It can be achieved by someone (initiator can appoint one (secretary) of more participants) records the meeting note/log. Option 3 - The content discussed in the meeting shall be recorded by slides or audio files Option 4 - The behavior and interaction of attendees shall be monitored Solution - Option 1 + Option 2 + Option 3

1.12.2 ISSUE 2 [NFR – 2] Requirement - Re-planning a meeting should be done dynamically and with much flexibility as possible. Description – The requirement here is ambiguous & incomplete. As who will re-plan the meeting and when should a meeting be re-scheduled are not specified. The words dynamically and flexibility are not defined and hence cannot be quantified and measured. Option 1 - Meeting initiator shall re-plan the meeting, when a meeting which has already been scheduled, however need to be re-scheduled for some reason. (With unlimited opportunities) Option 2 - Active/important participants can change their preference or exclusion set (with limited opportunities) or withdraws the meeting Option 3 - lower bound (defined at another requirement) affects at this point. After the lower bound, no one can re-plan the meeting, but the initiator. Solution - Option 1 + Option 2 + Option 3

Traceability

Prototype

Change Creeping rate Because we are using a spiral process model, our project can sustain a 2% changeability. At each round of the spiral model, we can both revise existing requirements as well as introducing new requirements if needed. The requirements and specifications can be changed up to 12% with a variance of +/-.2%. This value is not accurate and is based on the following criterions The intensity of change on prototype The Time and Resource required to implement the change in the provided limited resources How deviated is the new requirement from the old requirement The New changes should support validation and traceability factors The impact of new changes onto other existing modules