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.

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.
Lecture 5: Requirements Engineering
Project Presentation-Phase 2 Requirements Elicitation Specification Validation T ERA S OFT D ISTRIBUTED M EETING S CHEDULER Team Blitzkrieg: ADITYA DHAMANKAR,
May 14, May 14, 2015May 14, 2015May 14, 2015 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific University, Azusa,
7.1 A Bridge to Design & Construction
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
Requirements Analysis CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 7, 2003.
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
Project Management and Communication Represented by: Latifa Jaber Al-Ghafran.
Requirement Engineering – A Roadmap
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
Phase II Instructor: Dr. Lawrence Chung Rachel Bock, Ruben Cavazos, Chih-Lin Cheng, Victor Isbell, Swathi Kandimalla, Nikhil Mishra, Amy Polcari, Ramon.
Chapter 4 Requirements Engineering
M EETING S CHEDULER S YSTEM Team Members: Aaron Tull Rachel Weldon Derek Horner.
S/W Project Management
PROJECT PHASE 1 System Requirement Specification T ERA S OFT D ISTRIBUTED M EETING S CHEDULER Team Blitzkrieg: A DITYA D HAMANKAR, A JAY N ARASIMMAMOORTHY,
Dineshwari Byrappa Nagraj Rashi Gupta Shreya Modi Swati Satija Magesh Panchanathan.
Chapter 4 – Requirements Engineering
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Presented by Vinit Patwa Prasanna Kumar Thiagarajan Shiva Sangam Meghana Satpute Azharuddin Mohammed Ritesh Patel Tarun Chandra Samireddy Rutvij Desai.
©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.
Synergy Distributed Meeting Scheduler Phase I interim report.
1 CS 426 Senior Projects Chapter 3: The Requirements Workflow [Arlow & Neustadt, 2005] January 31, 2012.
Synergy Meeting Scheduler System GeetanjaliJeffYogita.
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.
Presented by Michael Hale Nelson Lopez Malini Srinivasan Sai Prasanth Sridhar Wanjun Huang Limin Tang Rutvij Desai.
Requirements Reference: Chapters 5, 6, & 8. CMSC 345, Fall Objectives To introduce the concepts of user and system requirements To explain functional.
Requirement Elicitation Process Lesson 3. Requirements Elicitation  Is the process to find out the requirements for an intended software system by communicating.
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.
Requirements Engineering Overview Senior Design Don Evans.
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
Meeting Scheduler Carl Fernandes Mahbubur Rahman Haque Muaz Jamshed Rahul Kotian Ramakrishnan Jayavelu Sujith John Zachariah Interim Presentation -2 on.
Requirements Engineering Lesson 2. Terminologies:  Software Acquisition is where requirement engineering significantly meets business strategy.  Software.
Systems Development Life Cycle
By Germaine Cheung Hong Kong Computer Institute
CSC480 Software Engineering Lecture 8-9 September 20, 2002.
Requirements Validation
Presented by –Call of Duty School of Requirement Engineering University of Texas, Dallas Web Meeting Scheduler System System Requirement Specification.
 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.
Lecture 4: Requirements Engineering COSI 120b, Principles of Software Engineering.
Requirements Engineering Processes. Syllabus l Definition of Requirement engineering process (REP) l Phases of Requirements Engineering Process: Requirements.
Requirement Engineering
Requirements Analysis
Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates.
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
SynergySoft™ Distributed Meeting Scheduler Requirements Review Yasaman Haghpanah Ravindra Rudraraju Sowjanya Sakruti Jim Whitaker.
Presented by –Call of Duty School of Requirement Engineering University of Texas, Dallas Web Meeting Scheduler System System Requirement Specification.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
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.
Introduction to Software Requirement Engineering Nisa’ul Hafidhoh Teknik Informatika
Presented by Michael Hale Nelson Lopez Malini Srinivasan Sai Prasanth Sridhar Wanjun Huang Limin Tang Rutvij Desai.
 System Requirement Specification and System Planning.
Requirement Engineering for Web Applications Introduction -play important role in WA deve. Why there is need of RE? -Because requirements are not properly.
Synergy Distributed Meeting Scheduling System Francisco Puente Arundhati Solapurkar Jung-Chi Lin.
Classifications of Software Requirements
Web Meeting Scheduler System
2010 Organizing a Better Future
UNIT II.
Requirements Analysis
Presented by Arnena Shekih-houssein Yiying Lee Chen Hui
Enterprise Requirements Literal
Duk-Jin Kim Tu Peng Yan Shi
Presentation transcript:

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 Engineering FALL 2007 Dr. Chung Synergy Distributed Meeting Scheduler Interim Project I Presentation

Outline the process of gathering requirements for the SDMS Address the scheduling of meetings Monitoring of meetings in an efficient as possible wayPurpose

Provide an abstract overview of the SDMS software system proposed by the Tech-9 software development team. SDMS is a web-based software application accessed via a web-browser SDMS proposes a more efficient and reliable means of not only scheduling meetings but monitoring meetings as well The Enterprise Functional and Non-Functional requirements, Stake Holders, Team Architecture and System Functional and Non-Functional Requirements are the scope of this documentScope

Product Description Tech-9 Team members Client Users

Process Flow

Client(s)‏ –Meeting Participants –Meeting Initiators –Domain Expert –System Administrators Requirements Engineer(s)‏ Software Engineer(s)‏ Test Engineer(s)‏ Design Engineer(s)‏ Process Engineer(s)‏ Team Leader(s)‏ Project Manager Product Manager Project Stakeholders

Arturo SarachoProject Plan and Traceability – Lead Daniel QiInterim Project I – Lead Le Qiao (Joe)Interim Project I – Lead Jose PerezFinal Project I – Lead Eric AndersonFinal Project I – Lead Joshua WuInterim Project II – Lead Elodie MambounouInterim Project II – Lead Russell SmithFinal Project II – Lead Liga (Li-Chia Kuo)Final Project II – Lead Members / Responsibilities

Objective Stakeholders Most Important Requirements –Functional –Non Functional Issues & Solutions –Ambiguity –Incompleteness Dependency graph Enterprise Requirements

Get location, date & time from attendees Provide equipment (projector, telephone, etc.)‏ Send invitation Receive invitation Avoid time/date/location conflict Objectives

Meeting initiator Important participant Potential participant Active participant Stakeholders

Functional –A meeting room should be available at the selected meeting date –A meeting room should meet all required equipment sets –Date exclusion sets and date preference sets should be contained in some time interval Non-Functional –The number of negotiations should be kept minimal –Each date conflict resolution should be done as quickly as possible and with no more interactions than needed Most Important Requirements

Ambiguity - The number of negotiations should be kept minimal but a new round of negotiations may be required when no such room can be found (II.1 req 13) “A round of negotiations is not defined.” Solution: Omit the idea of negotiation rounds. This does not imply removal of “the number of negotiations should be kept minimal.” Issues & Solutions

Incompleteness -Each conflict resolution should de done as quickly as possible (II.1 req 7)‏ This sentence does not say how fast a conflict should be solved Solution: Conflict resolutions should be allowed as soon as conflicts arise. Issues & Solutions (Cont.)‏

I’m non- functional requirement I’m functional requirement I’m the Initiator I’m the participants I’m the dependency relation

Potential Meeting attendees Important participant Active participant Date Range Exclusion set Preference set equipment Meeting date Date conflict Conflict solution Virtual place Meeting room As many preferences as possible Flexibility As many participants as possible No interaction fast Minimal Initiator

Functional Requirements The system shall: –monitor meetings (II.2 req 1). –plan meetings based on participant-given constraints (II.2 req 2). –allow changing participant-given constraints before the meeting is scheduled. This includes modified exclusion set, date preference set, and location preference set (II.2 req 3). –...

Functional Requirements

Ambiguity to keep participants informed about schedules and their changes; and (II.2 req 5)‏ Schedules is not defined. Who's schedules? Solution: Omit the requirement because interpreting it to be all participant's schedules conflicts with II.3 req 3.

Functional Requirements Incompleteness to get replies even from participants not reacting promptly; (II.2 req 5)‏ – It is unknown how this requirement may be met. – Solution: Omit the requirement.

Dependency Graph on Non-functional Rep. Create Meeting Accurately and nomadicity Plan Meeting Manage Interaction Replan Meeting Inform Attendees Get replies Cancel Meeting Re-schedule Monitor Meeting Proceed concurrency Dynamicall y and flexibility Minimize the amount of interaction As closely as the way meetings Typically Managed Convenient and available as early as possible User Friendliness? Physical constraints Minimize the elapsed time and fix a bound time Is the system extensible enough? What is flexible enough? privacy? Reduce overhead Customizable Capacity of requests

Issues & Solutions Ambiguity - Ambiguity is the property of word, terms, notations and concepts (within a particular context) as being undefined, or without an obvious definition and thus having an unclear meaning Ambiguities in non-functional requirement - A meeting should be accurately monitored “Who is going to monitor the meeting?” Solution: The meeting organizer will monitor the meeting

Issues & Solutions (Cont.)‏ - The system should reflect as closely as possible the way meetings are typically managed. - The meeting date and location should be as convenient as possible, and available as early as possible, to all participants. “As closely as possible, as convenient as possible, and available as early as possible” are unclear. Solution: Specify the possibility.

Issues & Solutions (Cont.)‏ - The system should be flexible enough to accommodate evolving data. “Flexible enough” is unclear. Solution: Whenever the data of the participant are changing, the system can update the corresponding data.

Inconsistency -Replanning of a meeting should be done as dynamically and with as much flexibility as possible; (II.3 req 2) -The amount of interaction among participants (e.g., number and length of messages, amount of negotiation required) should be kept minimal; (II.3 req 3) “These two requirements are conflict.” Solution: Reduce the flexibility of replaning meeting to kept minimal amount of interaction. Issues & Solutions (Cont.)‏

Incompleteness -A meeting should be accurately monitored, especially when it is held in a virtual place. Here, nomadicity will then be important to consider; (II.3 req 1)‏ “ Nomadicity” is not defined”. Solution: “Nomadicity” should be defined. Issues & Solutions (Cont.)‏

Mock-up