Synergy Distributed Meeting Scheduler System

Synergy Distributed Meeting Scheduler SystemPage 1 of 31

______

Synergy Distributed Meeting Scheduler System

Project Phase II

Team Members

Abhinav Reddy Tummalapally

Satyanarayana Karthik Upadrasta

Lavanya Devara

Swetha Vangala

Version:

1.4

Submitted to:

Dr Chung, Lawrence

Date Submitted:

November 18, 2006

Revision History
Date / Revision / Description / Author
Sep, 28 2006 / 0.1 / Initial Template / Team 6
Oct, 05 2006 / 1.0 / First Draft / Team 6
Oct, 28 2006 / 1.1 / Updated with comments by TA and the Professor / Team 6
Nov, 10 2006 / 1.2 / Added SADTs, SIGs, and other Diagrams / Team 6

Nov, 16 2006

1.3 Final Presentation

Team 6

i. Revision History

ii. Table of Contents

Abstract
Introduction
General Overview
Purpose
Scope
Definitions, Acronyms and Abbreviations
References
Process Description
Process Requirements
Process Goals
Process Model
Stakeholders
Roles Description
Project Roles
Process SADT Diagrams
Top Level Diagram
Detailed Top Level Diagram.
Issues Dealt
Security
Usability
Product Requirements
Enterprise Requirements
System Requirements
System Functional Requirements
System Non-Functional Requirements
Modeling using UML Diagrams
Use Case Diagram
System Sequence Diagram
Collaboration Diagram
Activity Diagram
SIGs for Non-Functional Requirements

Prototype Screenshots

6.1 User Authentication

6.2 User Registration

6.3 Meeting Locations and DateRange

6.4 Participants Details

6.5 Final Meeting Date and Location

Future Work

1. Abstract

“There are two sorts of education, and two sorts of

specification: ‘Math’, and ‘English’, and I don't like the

‘English’sort. “

[Anon, 1987]

"No part of the delivery process is as critical, nor as difficult- because requirements map the human world to the technological world."

[Jim Highsmith]

The success of any system depends upon how well the users’ needs are met. The first step of building a system is identifying what is expected out of it. The requirements Specification Document facilitates this process and helps the project stakeholders reach an agreement on the functionalities of the system and the conditions to which it must conform.

A Software Requirements Specification is an organization's understanding (in writing) of a customer or potential client's system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work. It's a two-way insurance policy that assures that both the client and the organization understand the other's requirements from that perspective at a given point in time.

2. Introduction

“Requirements engineering is the branch of software engineering concerned with the real world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families “

Thus the precise requirements specifications provide the basis for analyzing requirements, validating that they are indeed what stakeholders want, defining what designers have to build, and verifying that they have done so correctly upon delivery.

2.1 General Overview

The ‘Synergy Distributed Meeting Scheduler System’ is a simple web application which assists people in scheduling meetings. The SDMS system is intended to accelerate the meeting scheduling communication process, to provide support to the negotiation mechanisms involved, help the meeting initiator to resolve conflicts, and to reduce the overhead of scheduling meetings.

2.2 Purpose

The purpose of this document is to record the functional and non-functional requirements of the Synergy Distributed Meeting Scheduler System. This document also lists all the use-case models, and other diagrams such as the SADTs, SIGs etc to capture the requirements of the system. This software requirements specification communicates the customer requirements to the development team, who will derive the user interface specification, high-level design, and other deliverables.

2.3 Scope

This Requirements Specification applies to the Synergy Meeting Scheduler System. This specification defines the non-functional requirements of the system; such as reliability, usability, performance, and supportability as well as functional requirements that are common across a number of use cases. This document is intended to be a “contract” between the customer and the development team.

2.4 Definitions, Acronyms and Abbreviations

2.4.1 Definitions

Meeting Initiator/Scheduler: Person in charge of setting up the meeting
Active Participant: Any individual who gives presentations in the meeting
Potential Participant: Any individual invited to the meeting. In this sense, Potential Part
Important Participant : Any Individual whose presence is very crucial.
DateRange: Time interval set by meeting initiator under which meeting shall take place

Preference Set: A set of dates on which a participant would prefer the meeting to take place
Exclusion Set: A set of dates on which a participant cannot attend the meeting
Location: Room where meeting shall take place or virtual place in case of teleconference meetings
Equipment: Any resource required as part of the meeting, i.e. projector, laptops, workstation, network connection, telephone, etc.

2.4.2 Acronyms and Abbreviations

SDMS: Synergy Meeting Scheduler System

SADT:Structured Analysis and Design Technique

SIG: Soft goal Interdependency Graphs

UML: Unified Modeling Language

IDEF0: Integration Definition for Function Modeling

2.5 References

Dr Chung’s Requirements Engineering Subject’s Lecture Notes
Sample Requirement Specifications available on the Internet
IEEE SRS Guidelines
Previous Semester SRS Documents
Another SRS document available at
G. Booch, J. Rumbaugh, I. Jacobson, Unified Modeling Language User Guide.
Wikipedia – The Online Encyclopedia

3. Process Description

Software process is defined as the set of activities, methods and practices that are used in the development and evolution of software.

3.1Process Requirements

The requirements elicitation process requirements are to produce a requirements specification that documents the formal requirements of the planned product as specified by the stakeholders of the product and provides adequate guidance to the development organization to achieve a successful product in a time and resource effective manner.

Guidance for this process is provided in the IEEE standards listed in the “References” section of this document.

Given the diversity of interests and approaches possible it is assumed that an adequate consensus cannot be achieved for all aspects of any non-trivial engineering effort. It is expected that due diligence be employed to investigate alternatives and to negotiate any requirement or requirements in conflict.

Issues remaining unresolved at the end of the requirements elicitation process shall be resolved by senior management in consultation with technical leadership prior to the completion of the requirements elicitation phase.

3.2 Process Goals

Figure 1 depicts the SIG for defining the Goals of the Process. As can be seen, there are three sub-goals: Process Quality, Defining the Process to be used, and the Economic factors to be considered in using the process. For the process to be of good quality, the desired requirements are that the process be flexible, reliable, usable, and extensible. To define the process, the Lifecycle to be used is to be defined and the activities with which the lifecycle is composed of are to be defined. The lifecycle can be of multiple cycles or a single cycle. The activities can be sequential, in which one activity follows the next, or they can be concurrent, in which multiple activities can happen concurrently.

Figure 1: Process Goals SIG

The various effects of the types of Activities and Lifecycles on the Qualities of the Process are depicted in Figure 2. + indicates that that type of Activity or Lifecycle adds to the quality of the process and – indicates that that type of Activity or Lifecycle dimishes that quality.

Figure 2: Effects of types of Activities and Lifecycles on Process Qualities

3.3 Process Model

The process used is the Waterfall model, but with Iteration. The development is seen as flowing steadily downwards (like a waterfall) through the phases and activities of requirements analysis, design, implementation, testing (validation), integration, and maintenance. Iteration is included to accommodate changes in the requirements. Thus, the green parts of the SIG in Figure 1 depict the parts used in developing the product. The red parts are just alternatives and are not considered. The activities of the Waterfall process can be depicted in Figure 3.

Figure 3: Waterfall Lifecycle

3.4 Stakeholders

The following stakeholders were identified in this project:

Meeting Scheduler / Initiator
Participants
Requirements Engineer
Team Leader
Designer
Prototype Developer

3.5 Roles Description

Team Leader: The person responsible for planning and controlling the engineering activities to meet project goals for cost, schedule and quality. The team leader is also responsible for co-ordinating and integrating activities across multiple functional lines.
Initiator:The person who is responsible for initiating the meeting, setting the date range , inviting participants, collecting data from the participants, feeding them into the Meeting Scheduler Software, and resolving conflicts

Participant:The person responsible for giving the preference and exclusion date ranges, location and resource requirements and attending the meeting
Requirements Engineer:Theperson responsible for eliciting, specifying and validating requirements and also developing the requirements specification document. Requirements Engineer is also the person responsible for talking with the client to accommodate any changing or new requirements of the project
Designer: The person responsible for coming up with the design models such as the SADT diagrams, and the UML diagrams
Prototype Developer:Theperson responsible for making the design prototype operational

3.6 Project Roles

Figure 4 is a kind of Use Case diagram according to the organization’s own notations which specify the roles and activities of each role. The following table summarizes the team structure:

Team Members / RolesPlayed / Primary Concern
Abhinav Reddy
Karthik Upadrasta
Lavanya Devara / System & Subject World:
End-user/Buyer
Team Leader
Requirements Engineer / Requirement Analysis
Document preparation
Abhinav Reddy
Karthik Upadrasta / Management World:
Team Leader / Process/Product Specification
Requirement Analysis
Swetha Vangala
Karthik Upadrasta
Lavanya Devara / Developer World
Designer
Prototype Developer / Prototype development
Abhinav Reddy
Swetha Vangala / User World
Requirements Engineer / Requirements Analysis
Deal with Requirements Issues

Figure 4: Kind of Use Case Diagram Specifying Project Roles

3.7 Process SADT Diagrams

SADT (Structured Analysis and Design Technique) is a Software Engineering technique for describing systems as a hierarchy of functions. SADT uses two types of diagrams: Actigrams and Datagrams. SADT uses arrows to build these diagrams.

The Semantics of Arrows

For Actigrams:

Inputs are data that are consumed by the activity.
Outputs are produced by the activity.
Controls influence the execution of an activity but are not consumed.
Mechanism actual make the activity happen.

For Datagrams:

Inputs are activities that produce the data.
Outputs consume the data.
Controls influence the internal state of the data.
Mechanism is the Storage Device.

3.7.1Top Level Diagrams

3.7.2Detailed Level Diagrams

4. Issues Dealt

4.1Security

The user has to login into the system in atmost three trials.After the three trials, If the username and password does not match, then the username is disabled and it has to be enabled by the System Administrator on the request made by the user. In this way security can be enforced on the system to some extent as even many password breaking algorithms have a hit and trial process which can be blocked by SDMS.The security can be enhanced by adding the fingerprint recognition feature. This feature is not added to the current system due to many other priorities that had to be met in the given short span of time.

4.2. Usability

We have made tremendous effort in designing and implementing the SDMS prototype in order to make it as user friendly as possible. Many key features include

Selection of location by state.
Selection of dates using a calendar.
Simple login
Simple registration for the 1st time login
Fast Scheduling of the meeting date and Location.

5.1 Enterprise Requirements

ER-1 / A “meeting initiator” shall initiate a meeting by deciding on a “meeting topic”, by selecting a list of “potential meeting participants”, and by selecting a “date range”, “duration”, and “location” for the meeting.
ER-2 / A “meeting initiator” or “potential meeting participant” shall provide the ability where a person may “delegate” the ability to initiate or accept (or decline) a meeting to another system user.
ER-3 / A “meeting initiator” shall be one of the “potential meeting participants” by default but may opt to remove himself as a “potential meeting participant”.
ER-4 / A “meeting initiator” shall confirm the meeting and the system shall change the “time slots” of accepting “meeting participants” from a temporary reservation to a scheduled meeting, once all “potential meeting participants” have responded to the “meeting proposal.
ER-5 / A “meeting initiator” shall cancel the meeting and the system shall change the “time slots” from being temporarily reserved to be freed once the meeting is canceled.
ER-6 / A “meeting initiator” shall reschedule the meeting and the system reschedule the meeting by releasing the temporary reservations and selecting a different “data range”, “duration”, or “location” and starting the process over.
ER-7 / A “meeting initiator” may send a “meeting proposal” for a “virtual meeting” for the available “time slot” if the “date range” and “duration” is acceptable but no location for the meeting is available.
ER-8 / A “meeting initiator” may cancel the meeting or reschedule the meeting at any time prior to the start of the meeting.
ER-9 / A meeting scheduler may (optionally) automatically propose another meeting if current meeting is canceled by an important participant.
ER-10 / A meeting scheduler may provide the “meeting initiator” a summary of the scan of “potential meeting participants” showing available “time slots” and schedule conflicts as a means of informing the “meeting initiator” of the overall results of the system.
ER-11 / The “meeting initiator” may designate one or more “potential meeting participants” as “important” meaning that their attendance at the meeting is required in order to have the meeting.
ER-12 / The “meeting proposal” may include an “agenda” or list of topics for discussion during the meeting and may include a list of “required equipments”.
ER-13 / A meeting scheduler will scan all the list of “potential meeting participants” to determine a “time slot” of the required “duration” exists among all “potential meeting participants” once a “meeting proposal” is entered to the system.
ER-14 / A meeting scheduler will inform the “meeting initiator” that no “time slot” exists for all “potential meeting participants” and may optionally suggest an alternative “date range”, “duration”, and “location” which is available.
ER-15 / A meeting scheduler will temporarily reserve the “time slots” for the proposed meeting and inform the “potential meeting participant” of the meeting and request input as to “will attend” or “will not attend”, if a “time slot” exists.
ER-16 / A “potential meeting participant” or their “delegate” may accept or refuse the meeting. If accepting, the “potential meeting participant” becomes a “confirmed meeting participant”. If refusing, the “potential meeting participant” may provide a reason for his refusal.
ER-17 / A “confirmed meeting participant” may request special equipment.
ER-18 / A “potential meeting participant” or “confirmed meeting participant” may confirm or cancel their attendance at the meeting subject to the administrative rules and practices of the participant’s.
ER-19 / Any physical changes to the “location” and its “required equipment” shall be kept up-to-date.
ER-20 / : If any physical changes to the “location” and its “required equipments” shall occur after a “meeting proposal” and before the meeting date, the “meeting initiator” shall be notified promptly.

5.2 System Requirements

5.2.1 System Functional Requirements

SFR-1 / The meeting scheduler system shall be able to schedule a meeting with a meeting topic, date range, duration, and location for a list of participants.
SFR-2 / The meeting scheduler system shall monitor meetings, since some of the meeting held as a “virtual meeting”.
SFR-3 / The meeting scheduler system shall be able to select a participant as an important participant.
SFR-4 / The meeting scheduler system shall cancel a meeting due to canceling of an important participant.
SFR-5 / The meeting scheduler system shall reschedule a meeting to support conflict resolutions.
SFR-6 / The meeting scheduler shall be accessed from the Web.
SFR-7 / The meeting scheduler system may (optionally) automatically propose another meeting if current meeting is canceled by an important participant.
SFR-8 / The meeting scheduler system may provide the “meeting initiator” a summary of the scan of “potential meeting participants” showing available “time slots” and schedule conflicts as a means of informing the “meeting initiator” of the overall results of the system.
SFR-9 / The meeting scheduler system may be able to include an agenda for a meeting proposal.
SFR-10 / The meeting scheduler system may suggest a “virtual meeting” for available “time slots” if no location is available or feasible for the meeting.
SFR-11 / The meeting scheduler system may be able to include a list of required equipment for a meeting proposal.
SFR-12 / A meeting scheduler system will temporarily reserve the “time slots” for the proposed meeting.
SFR-13 / A meeting scheduler system will inform the “potential meeting participant” of the meeting.

5.2.2 System Non-functional Requirements

A good Meeting Scheduler system should meet the powerful functional requirement. It should also pay attention to its non-fictional requirements. This section describes the quality attributes that the Meeting Scheduler software should have.

Reliability

The SDMS system should emulate or imitate the manner in which human without automation schedules meetings.

Performance

The elapsed time between the submission of a meeting request and the determination of the corresponding date or location should be upon the “meeting participants” count. If they are less than 20 people the elapsed time shall be less than 4 seconds, If the count is between 20 and 50, the elapsed time shall be less than 10 seconds. If the count is more than 50 the elapse time can vary from 10 seconds to 40 seconds.

User friendliness

The user interface of the system should be easily usable by non-experts. It means that the SDMSTM system should reflect as closely as possible to the way non-automatic meetings are typically managed