Presented by Michael Hale Nelson Lopez Malini Srinivasan Sai Prasanth Sridhar Wanjun Huang Limin Tang Rutvij Desai.

Slides:



Advertisements
Similar presentations
Synergy Distributed Meeting Scheduler(SDMS) TEAM:4 Rutvij Mehta Shruti Mehta Shveta Mupparapu Meghna Swetha Raguraman Rakesh Sanapala Venkata Jaganadh.
Advertisements

Synergy Distributed Meeting Scheduler High Fliers.
AmeriCorps is introducing a new online payment system for the processing of AmeriCorps forms
GALVESTON COUNTY, TX P-CARD TRAINING GALVESTON COUNTY.
Use Case & Use Case Diagram
SUBMITTED TO: DR. LAWRENCE CHUNG ASSOCIATE PROFESSOR, DEPARTMENT OF COMPUTER SCIENCE, THE UNIVERSITY OF TEXAS AT DALLAS, RICHARDSON, TX SUBMITTED.
Project Presentation-Phase 2 Requirements Elicitation Specification Validation T ERA S OFT D ISTRIBUTED M EETING S CHEDULER Team Blitzkrieg: ADITYA DHAMANKAR,
SOCIAL NETWORK INFORMATION CONSOLIDATION Developers:  Klasquin Tomer  Nisimov Yaron  Rabih Erez Advisors:  Academic: Prof. Elovici Yuval  Technical:
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
Identifying Needs and Establishing Requirements John Thiesfeld Jeff Morton Josh Edwards.
SwE 313 Case Study Registration System.
Task Management System Client xx Team Member 1 Member 2 Member 3 This is not a real project, but a student project carried out for a system requirements.
Academic Advisor: Prof. Ronen Brafman Team Members: Ran Isenberg Mirit Markovich Noa Aharon Alon Furman.
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
InceptionPhase Mesekach Kaleem Ullah, Melody Parsa, Charmie Dela Cruz, Setareh Vali S C K M MeSeKaCh.
Virtual EMS Step by Step Instructions to Submit Online Room Reservation Requests Events Management Office Rick McCluskey
Phase II Instructor: Dr. Lawrence Chung Rachel Bock, Ruben Cavazos, Chih-Lin Cheng, Victor Isbell, Swathi Kandimalla, Nikhil Mishra, Amy Polcari, Ramon.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 7 Requirements Engineering Software Engineering: A Practitioner’s Approach, 6/e Chapter.
M EETING S CHEDULER S YSTEM Team Members: Aaron Tull Rachel Weldon Derek Horner.
RUP Requirements RUP Artifacts and Deliverables
Project Analysis Course ( ) Week 2 Activities.
Dineshwari Byrappa Nagraj Rashi Gupta Shreya Modi Swati Satija Magesh Panchanathan.
Presented by Vinit Patwa Prasanna Kumar Thiagarajan Shiva Sangam Meghana Satpute Azharuddin Mohammed Ritesh Patel Tarun Chandra Samireddy Rutvij Desai.
Requirements 101 CS3300 Fall 2015.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
SDMS Project Phase Ⅰ Duk-Jin Kim Tu Peng Yan Shi.
Eric Anderson Liga (Li-Chia Kuo)‏ Elodie Mambounou José Perez Daniel Qi Le Qiao (Joe)‏ Arturo Saracho Russell Smith Josh Wu Tech-9 Members Advanced Requirements.
Software Requirements Presented By Dr. Shazzad Hosain.
Synergy Distributed Meeting Scheduler Phase I interim report.
Synergy Meeting Scheduler System GeetanjaliJeffYogita.
Meetings Lesson 6 Documentation The main documentation for meetings are an agenda and minutes.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 4: Developing Requirements.
Synergy™ Distributed Meeting Scheduler Organize meetings with SDMS SynergySoft, Inc. presents:
CS6361 Project, Part 1 Fall 2006 The Design Firm of Bouchier, Fischer, Herschbach, & Nina.
Synergy Meeting Scheduler System T-squared, S-cubed TJ Andrews Thriveni Movva Sadequa Azam Sama Malik Scott Denson.
Requirements Reference: Chapters 5, 6, & 8. CMSC 345, Fall Objectives To introduce the concepts of user and system requirements To explain functional.
User Management. Basics SDMS shall maintain a database of all users. SDMS shall maintain a database of all users. SDMS shall not limit the number of registered.
Phase 1 Interim Instructor: Dr. Lawrence Chung Rachel Bock, Ruben Cavazos, Chih-Lin Cheng, Victor Isbell, Swathi Kandimalla, Nikhil Mishra, Amy Polcari,
Lecture 2 Developing Requirements
Registration Solutions for your Event Management.
Presented by –Call of Duty School of Requirement Engineering University of Texas, Dallas Web Meeting Scheduler System System Requirement Specification.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
 SAP AG 2007, SAP CSUN 2007 Conference Presentation / 1 Presented by Team “Call of Duty” 29 th April 2010 CS 6361, University of Texas At Dallas.
SynergySoft™ Distributed Meeting Scheduler Requirements Review Yasaman Haghpanah Ravindra Rudraraju Sowjanya Sakruti Jim Whitaker.
Design Review Presentation. Project Plan Problem Statement As of now, no available social network will allow a user to create it’s own sub social network.
Presented by –Call of Duty School of Requirement Engineering University of Texas, Dallas Web Meeting Scheduler System System Requirement Specification.
HighImpact Soft Final Presentation Dare Famodimu Eric Deshazer Sergio Loza Scott Willock.
HighImpactSoft 2010 Organizing a Better Future. Agenda Specify Goals ScopeDefinitions Process Model Preliminary Requirements Issues and solutions TraceabilityPrototype.
Synergy Meeting Scheduler System Abhinav Reddy Tummalapally Lavanya Devara Swetha Vangala Satyanarayana Karthik Upadrasta.
COMM 3050 – Online Project Update. Project Roles  Organizer Responsible for creating Zoom account technical aspects and posting recorded meeting to S:
1 A Look at the Application Authorized users can access Communicator! NXT from any Internet-capable computer via the Web.
Presented by Michael Hale Nelson Lopez Malini Srinivasan Sai Prasanth Sridhar Wanjun Huang Limin Tang Rutvij Desai.
Synergy Distributed Meeting Scheduling System Francisco Puente Arundhati Solapurkar Jung-Chi Lin.
OPS Requirements Specification and Analysis Dustin Larson Bryan Campbell Charles Sears.
Switchvox SMB 4.6 for your peace of mind
CMPE 280 Web UI Design and Development August 29 Class Meeting
Lecture 2 Developing Requirements
Web Meeting Scheduler System
Use Case Model.
2010 Organizing a Better Future
System Requirements Specification
Using Groove Philip S. Vavalides Professor - IT/Networking Guilford Technical Community College Jamestown, NC.
Google Classroom Setting Up Your Class
Skype for Business Webinar Meeting
Enterprise Requirements Literal
Using Use Case Diagrams
Customising Your Club Meeting
Use Case Modeling Part of the unified modeling language (U M L)
Use cases Dr. X.
Duk-Jin Kim Tu Peng Yan Shi
Presentation transcript:

Presented by Michael Hale Nelson Lopez Malini Srinivasan Sai Prasanth Sridhar Wanjun Huang Limin Tang Rutvij Desai

 Simple web based system  Easy to handle  Interactive  No downloads required  Precise system, eliminates hassle

 Targets to achieve  Stake Holders  New Updated Requirements and Issues  Process Specification  Product Specification  SIG  Vision  Fishbone Analysis  Updated Traceability  Changeability

 Initiate a new meeting.  Choose location and equipments for meeting  summarizes their responses  updates initiator on the results  sends confirmations  sends optional reminders prior to meeting  cancel/reschedule meetings  minimizes rounds of negotiations  categorize participants if necessary  conduct virtual meetings  schedule meetings in parallel

 Meeting Initiator  Participants  Requirement Engineer  Project Manager  Domain Expert

 Domain Assumption  Functional Requirement  Non-Functional Requirement

 Ambiguous  Incomplete  Inconsistent  Unsound

 Issue –  Requirement -Some meetings are organized and scheduled at the same time, where partial attendance can be allowed.  Description – The requirement is inconsistent with the former description and it is ambiguous. One attendance cannot attend multi-meetings at the same time.  Possible Solutions -

 Option 1 - ignore this specification.  Option 2 - change the former description.  Option 3 - some meetings can be organized and scheduled at the same time at different places. However, same person can only attend one meeting at one time.  Optimal Solution - Option 3 + Option 4  Rationale - some meetings can be organized and scheduled at the same time at the same building. So that same person can attend multiple meetings which are scheduled at the same time and same building, i.e. the person can attend each meeting partially as long as these meetings are scheduled in the same building.

 Requirement - For helping with conflict resolution and negotiation support, video conferencing (e.g., through Skype) should be available on the system and each video conferencing session should be recorded and analyzed for the purpose of monitoring. [IFR – 23].  Description – The requirement is ambiguous. The terms conflict and analyze can have different meanings.  Possible Solutions -

 Option 1 – The definition of conflict shall be the same as the former requirement, so that the definition of the term can be consistent. When there are conflicts between participants, for example, meeting time or meeting location, video conferencing can be one solution.  Option 2 – We can have many different kind of analyze methods; however this is out of the range of the meeting scheduler system. The system shall only keep the record of the video conference.  Optimal Solution - Option 1 + Option 2  Rationale – Video conferencing is a good solution when conflict happens. It is easy for the system to record video clips of the conference.

 Requirement - Meeting locations should be convenient, and information about meetings should be secure. [INFR-13]  Description – convenient is already defined in the phase-1 requirement.  Possible Solutions -

 Option 1 - each user is assigned one unique user id and password. The password must be at least 8 characters long and contain at least one uppercase letter, one lowercase letter and one number.  Option 2 - each user is assigned one unique user id and password. The password must be at least 8 characters long and contain at least one uppercase letter, one lowercase letter and one number.  Optimal Solution - Option 1 + Option 2  Rationale - the system is still simple to run, and also guarantee some kind of the security.

Level 0

Level 1/A0

A 01

A 02

A 06

Level 0

Level 1

Level 2

Level 3

 Few fully dressed format for your view Initiate Meeting UC NameInitiate Meeting DescriptionAny individual having an account, can be the Meeting Initiator Primary Actor Meeting Initiator stakeholders and Interest Meeting Initiator: Wants to initiate a meeting. Participants: Meeting attendees who participate in a meeting. precondition User will login as Meeting Initiator post condition Meeting initiator successfully initiates a meeting, by sending invite to all participants who are invited to the meeting. Main Success Scenario Meeting initiator will login with user credentials. Meeting initiator shall enter a meeting topic, duration and a date range. Meeting initiator shall also specify a time i.e. Due, within which all participants shall send in their responses. Meeting initiator shall then send an invite to participants by entering their Username/ id, and choose participants as active, important and regular. ExtensionNone Special RequirementsWeb Access Technology and Data variation list Computer, mouse, keyboard, Laptop, Mysql database Frequency of OccurrenceOnce MiscellaneousNone

Withdraw Meeting UC NameWithdraw from a meeting Description Participants withdraw from meeting, to resolve conflict or due to external constraints. Primary Actor Participants stakeholders and InterestMeeting Initiator: View participants who withdraw from meeting. precondition If the participant has conflict in date, time or location post conditionParticipant has withdrawn from meeting. Main Success Scenario Success depends on the participant, if he/she withdraws from a meeting to solve conflict If the participant withdraws from a meeting due to external constraints. If the participant displays a message, why he/she withdraws and selects withdraw option When the withdraw message is notified to initiator When the system removes the participant information from that meeting list When the system sends a notification to the initiator that he/she has been removed from the meeting list ExtensionNone Special RequirementsWeb Access Technology and Data variation list Computer, mouse, keyboard, Laptop, Mysql database Frequency of OccurrenceFrequent MiscellaneousNone

 Few sequence diagrams for your view Re-plan/Reschedule Meeting

Removing Users

 Product NFR –  Security  Performance  Process NFR -  Usability  Reliability

The problem ofScheduling meetings manually AffectsMeeting Initiator and attendees Impact is Time Consumption More Conflicts Unconstrained delays Successful solution would be Distributed Meeting Scheduler System with - precise system - feasible conflict resolutions - simple to use

Manually Schedule Meetings Miscommunication between attendees More Conflicts Changing minds of people Time Consumption Limited resources, Less functionalities OmniSoft DMS

 Forward Traceability  Backward Traceability

S.NoRequirement Specifications Backward Traceability IDR-1 A meeting initiator will ask all potential meeting attendees for the following information based on their personal agenda: a set of dates on which they cannot attend the meeting (hereafter, referred to as exclusion set); and a set of dates on which they would prefer the meeting to take place (hereafter referred to as preference set ). DR-1 IDR-2 A meeting date shall be defined by a pair (calendar date and range of minutes) DR-2 IDR-3 The exclusion and preference sets should be contained in a series of dates and times prescribed by the meeting initiator (hereafter referred to as date range). DR-3 IDR-4 The initiator can ask active participants to provide any special equipment requirements on the meeting location (e.g., overhead projector, network connection, telephone, etc.). DR-4 IDR-5 There are three types of participants: active, regular, and important. DR-4 IDR-6 An active participant is someone who will be involved in giving the presentation. DR-4 IDR-7 A regular participant is someone who simply attends the meeting. DR-4 IDR-8 An important participant is a special guest or a member of upper level management. DR-5 IDR-9The initiator will decide which role a participant will have.DR-4,DR-5 IDR-10She may also ask important participants to state preferences about the meeting location. DR-5

 Changes in requirement specification are certain.  % of change – 15 Variance - +/- 5  Reason –  Prototype – The amount of change in the prototype model  The change from Old requirements to New modified requirements  The screenshots & requirement traceability factors.

  