Slide #1.

Web Meeting Scheduler System University of Texas, Dallas System Requirement Specification PROJECT PHASE 1 (Final) Presented by –Call of Duty SPRING 2010, CS 6361 Requirements Engineering School of Requirement Engineering University of Texas, Dallas, March 25, 2010
More slides like this


Slide #2.

Outline Agenda Current System  Problem  Goal Proposed System Stake holders/interest Requirement Engineering process Prototype Traceability Changeability Conclusion Date March 25, 2010
More slides like this


Slide #3.

Current System Date March 25, 2010
More slides like this


Slide #4.

Problem Scheduling a meeting may take more time, energy and patience than a human can handle. Date March 25, 2010
More slides like this


Slide #5.

Problem Date March 25, 2010
More slides like this


Slide #6.

Outline Outline Current System Proposed System  Goal Stake Holders/Interest Requirement Engineering Process Prototype Traceability Changeability Conclusion Date March 25, 2010
More slides like this


Slide #7.

Goal Date March 25, 2010
More slides like this


Slide #8.

Goal Goal Schedule meetings anytime from anywhere with maximum efficiency and in minimum time!! Date March 25, 2010
More slides like this


Slide #9.

Outline Outline Current System Proposed System Stake Holders/Interest Requirement Engineering Process Prototype Traceability Changeability Conclusion Date March 25, 2010
More slides like this


Slide #10.

Stakeholders Stake Holders  Users • Meeting Scheduler /Initiator • Participants  Customer  Requirements Engineer  Project Manager  Development Team  Testing and Maintenance team Date March 25, 2010
More slides like this


Slide #11.

Outline Current System Proposed System Stake Holders/Interest  Requirement Engineering Process  Overview: RE Process  Process Model Proposed by Ross  Preliminary Requirements  Issues Prototype Traceability Changeability Conclusion Date March 25, 2010
More slides like this


Slide #12.

Overview: Overview:Software SoftwareLifecycle Lifecycle Date March 25, 2010
More slides like this


Slide #13.

Overview: Requirements Engineering Evolutionary Iterative model. Date March 25, 2010
More slides like this


Slide #14.

Why ? Domain Requirement Date March 25, 2010
More slides like this


Slide #15.

What ? Functional Requirements Date March 25, 2010
More slides like this


Slide #16.

How ? Non Functional Requirements Date March 25, 2010
More slides like this


Slide #17.

System Overview Date March 25, 2010
More slides like this


Slide #18.

Preliminary Requirements Preliminary Requirements Functional Requirements: In software engineering, a functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs Non Functional Requirements: In requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. Date March 25, 2010
More slides like this


Slide #19.

Preliminary Requirement: Functional requirements Preliminary Requirement: Functional requirements System shall provide functionality that enables initiator to send out the meeting information to all of the potential meeting attendees. The system should provide functionality for the meeting attendees to select their exclusion set and preference set. The initiator is going to decide on a date range considering the exclusion and preference sets. The system shall provide functionality for the active and important participants to notify the initiator of any special equipment requirements and preferences about the meeting location Date March 25, 2010
More slides like this


Slide #20.

Contd. The system shall provide functionality to check for a date conflict and notify all the participants. The system shall provide functionality for the initiator to extend the date range to facilitate conflict resolution The system shall provide functionality for the attendees to withdraw from the meeting to facilitate conflict resolution. The system shall provide functionality for the attendees to add new dates into their preference sets to facilitate conflict resolution. Date March 25, 2010
More slides like this


Slide #21.

Contd. Contd. The system shall provide functionality for the attendees to remove dates from their exclusion sets to facilitate conflict resolution. The system shall provide options for the meeting initiator to select a real or a virtual meeting location. The system shall provide functionality to re-plan a meeting. The system shall notify all participants after the meeting initiator inserts the final decision (about meeting date and location) in the system. Date March 25, 2010
More slides like this


Slide #22.

Preliminary Requirement: Non: Functional requirements . Preliminary Requirement Non Functional requirements A meeting should be accurately monitored, especially when it is held in a virtual place. Re-planning of a meeting should be done as dynamically and with as much flexibility as possible. The amount of interaction among should be kept minimal. The meeting date and location should be as convenient as possible, and available as early as possible, to all (potential) participants Date March 25, 2010
More slides like this


Slide #23.

Contd. Contd. Physical constraints shall be considered. The system shall handle appropriate number of concurrent users. The system shall have an appropriate level of performance. The system shall be easily usable by nonexperts Date March 25, 2010
More slides like this


Slide #24.

Issues and Solutions Issues and Solutions Incompleteness & Absence  Undefined phrases  Incomplete list Ambiguity & Vagueness  Imprecise wording  Unclear phrases Inconsistency  Conflicting/Contradictory Statements Unsoundness  Incorrect/Illogical requirements Date March 25, 2010
More slides like this


Slide #25.

Domain DomainAnalysis Analysis [DR_008] – “She may also ask important participants to state preferences about the meeting location.” Issue – The statement assumes that the initiator is of a particular gender. The preference of the location is broad and important participants are not defined. Option1: Define important participants as people who are deemed important by the initiator and are allowed to state a meeting location preference to be anywhere, and replace the word she with meeting initiator.. Option2: Replace “she” with “initiator” and define important participants as people with a higher priority over other participants, whom can also be an active participant. They also have the option to state a preferred meeting location from a list of locations set by the meeting initiator. Decision and rationale: Replacing “she” will tell us that the initiator can be of any gender. The initiators role is to decide which participants are considered important and also, System allows the important participant to set a meeting preference to be anywhere(Option 1). Date March 25, 2010
More slides like this


Slide #26.

Contd. Contd…. [DR_010] –”The proposal should be made as early as possible.” Issue – The statement is not accurate and the word “early” is not defined Option1: Remove the statement. Option2: Define “early” with respect to the rate at which the potential meeting attendees respond with their preference/exclusion sets or the percentage of responses received from each type of potential attendee (active/important). Option3: Replace should with must Decision and rationale: The option 2 is suitable because replacing “should” with “must” elevates the priority that a feature needs to be implemented. If the statement was removed there is possibility that a proposal shall take a long amount of time. When the definition of early is stated, the possibility of we getting the proposal at the earliest is high. Date March 25, 2010
More slides like this


Slide #27.

Functional Analysis (Issues and solutions) Functional analysis [FR_002] - “Monitor meetings, especially when they are held in a distributed manner or periodically;” Issue - Ambiguous . Who can monitor the meetings ? Option1: “A distributed manner” means, the meeting that involves participants in different geographical locations of the world will be monitored by the meting initiator in terms of how many people are participating and their time/location preferences. Option2: “A distributed manner” means, the meeting that involves participants in different geographical locations of the world will be monitored by the important and active participants in terms of how many people are participating. Decision and rationale Option 1 is chosen as the system shall allow monitoring meetings involving participants from different geographical locations. It provides control to the meeting initiator in terms of ensuring that only invited attendees are attending the meeting also considering the location/time preference, enabling smooth conduction of the meeting. Option2 would not be feasible as a meeting could have more than one important and active participants. Date March 25, 2010
More slides like this


Slide #28.

Contd. Contd.. [FR_004] -Re-plan a meeting to support the changing user constraints, that include modification to the exclusion set, preference set and/or preferred location before a meeting date/location is proposed; Issues – Incomplete. Does not indicate if all users or only certain set of users can modify the exclusion set, preference set in addition to location/time before a meeting/date location is proposed. Option1: The system shall allow re-planning of the meeting by providing privilege to all active, important and regular, to make modification to exclusion set, preference set and/or preferred location before a meeting date/location is proposed but before the deadline specified by the meeting initiator. Option2: The system shall allow re-planning of the meeting by permitting participants: active, important and regular to provide and modify the exclusion set, preference set but before a meeting deadline. The system shall allow only the important participants to state preferences about the meeting location and allow the active participants to request special equipments on the meeting location. Decision and rationale Option 2 is chosen as the system shall allow meetings to be re-planned based on user constraint changes of important and active participants only in terms of location and equipment providing an ordered execution and monitoring of the system. Option1 could increase the rounds of negotiations to schedule a meeting. Date March 25, 2010
More slides like this


Slide #29.

Contd. Contd.. [FR_011] – “Meeting requests can be competing when they overlap in time or space.” Issues: Incomplete. Does not describe how the system should behave when there is an overlap of time and space. Option 1: If meetings overlap in time and space, meeting with higher priority should take place. If the priorities are same then the meeting that was booked first shall take precedence. Option 2: Based on the decision of meeting initiator the meeting shall be cancelled, postponed, changed. Decision and Rationale: Option1 is chosen as this allows a meeting that was scheduled first to take precedence thus supporting the first come first served policy. Date March 25, 2010
More slides like this


Slide #30.

Non Functional Analysis (ISSUES & SOLUTIONS) [NFR_002] – “A meeting should be accurately monitored, especially when it is held in a virtual place. Here, nomadicity will then be important to consider; “ Issues – Incomplete and ambiguous. It does not specify what the measure of accuracy is. It does not indicate if the system should be monitored in terms of proceedings, participation of attendees, interaction of the participants or the working of the equipment if any. Also, the definition for “nomadicity” in context to the project is missing. Option 1: The word “accurately” only provides emphasis on the functional requirement of selecting time/date within the time frame and not belonging to any of the exclusion set, and deciding on a voted and available location with requested resources. The entire sentence “Here, nomadicity will then be important to consider” is eliminated as well as the word “especially”. Option 2: The word “accurately” refers to the availability of valid and updated information about exclusion and preferred sets, locations and resource requests. “Nomadicity” refers to the availability of precise abovementioned information to the meeting initiator regardless of his/her geographic location. Accurately also refers to the genuine information on proceedings, participation of attendees, interaction of the participants or the working of the equipment if any used for the meeting especially in a virtual environment. Decision and rationale – Since this requirement emphasizes on the meeting held in virtual place, Option 2 provides more precise requirement highlighting the accuracy of valid and updated user preferences in addition to the participation of attendees. Date March 25, 2010
More slides like this


Slide #31.

Contd. Contd.. [NFR_003]- “Re-planning of a meeting should be done as dynamically and with as much flexibility as possible;” Issue– Incomplete and ambiguous. The words “dynamically” and “flexibility” cannot be quantified or measured as no clear definition is provided for them. It does not indicate who can/or has the authority to re-plan the meeting. Option 1 –The system shall allow the meeting initiator to re-plan the meeting. The word “dynamically” indicates that the system shall find a suitable meeting time and date based on the information available including preferred and exclusion sets, locations and resource requests. The word “flexibility” refers to provision available to the important and active participants to change their feedback whenever necessary but before the meeting deadline. Option 2 – The system shall re-plan the meeting in-case of a conflict. The word “dynamically” indicates that the system shall find a suitable meeting time and date based on the information available including preferred and exclusion sets, locations and resource requests. The word “flexibility” refers to allowing the important and active participants to change the date range and providing their exclusion and preferred sets from the new range before the meeting deadline. Decision and rationale – Option 1 is more flexible as it offers control for the meeting initiator to decide on the date and time providing a simple and feasible solution. Date March 25, 2010
More slides like this


Slide #32.

Contd. Cont … [NFR_007] – “Physical constraints should not be broken --- e.g., a person may not be at two different places at the same time; a meeting room may not be allocated to more than one meeting at the same time; etc.; “ Description – This requirement is incomplete. The word “etc” does not provide a complete list of all possible options for the physical constraints. It indicates that there are many possible physical constraints in the system of which only two are mentioned. Option 1- The system shall not allow a person to attend more than one meetings at the same time. The system shall ensure that the same meeting room is not allocated to more than one meeting at the same time. Option 2- Due to incompleteness the requirement is ignored. Decision and Rationale- Option 1 is the ideal solution as the system complies with the indicated physical constraints. Date March 25, 2010
More slides like this


Slide #33.

Contd. Cont … [NFR_009] –” The system should be customizable to professional as well as private meetings - ...; “ Issue –Incomplete. The word “customizable” does not provide the details on how the system should be customized. It does not define the terms private or professional meetings. Option 1- The system shall allow the meeting initiator to indicate if the meeting is private in which case the meeting information shall not be made available or accessible to any other user in the system apart from the participants. Option 2 - There is no distinction between private and professional meetings. The type of meeting depends on the purpose of meeting. The system can be used for any type of meetings. The same user interface will be provided for all the meeting initiations Decision and Rationale- Option 2 is more appropriate solution as it provides more generic behaviour to the system. Since the meetings requests can only be viewed by the invited participant’s privacy is still maintained. Date March 25, 2010
More slides like this


Slide #34.

Outline Outline Current System Proposed System Stake Holders/Interest Requirement Engineering Process Prototype Traceability Changeability Conclusion Date March 25, 2010
More slides like this


Slide #35.

Register Screen Date March 25, 2010
More slides like this


Slide #36.

Login Screen Date March 25, 2010
More slides like this


Slide #37.

Home page Screen Date March 25, 2010
More slides like this


Slide #38.

Initiate Meeting Request Screen Date March 25, 2010
More slides like this


Slide #39.

Meeting Confirmation Request Screen Date March 25, 2010
More slides like this


Slide #40.

Other User Home Page Screen Date March 25, 2010
More slides like this


Slide #41.

Meeting Status Screen Date March 25, 2010
More slides like this


Slide #42.

User UserResponse ResponseScreen Screen Date March 25, 2010
More slides like this


Slide #43.

Respond to Request Screen- meeting initiator view Date March 25, 2010
More slides like this


Slide #44.

Logout Screen Date March 25, 2010
More slides like this


Slide #45.

Outline Outline Current System Proposed System Stake Holders/Interest Requirement Engineering Process Prototype Traceability Changeability Conclusion Date March 25, 2010
More slides like this


Slide #46.

Traceability Forward Traceability (Domain requirement to Work Product) FR_001 All the important participants and active participants could be optionally S1, present in the meeting. More than a certain threshold (say 60%) of the S7 important participant’s preferences on the date and location need to be satisfied. A meeting shall be held when the total number of active and important participants is more than threshold value (say 50%) in which more than 70% of important participants participate. FR_002 “A distributed manner” means, the meeting that involves participants in S4 different geographical locations of the world will be monitored by the meting initiator in terms of how many people are participating and their time/location preferences. FR_003 The system shall plan meetings under the constraints expressed by S7 participants The system shall allow rep-planning of the meeting by permitting participants: S6 active, important and regular to provide and modify the exclusion set, preference set but before a meeting deadline. The system shall allow only the important participants to state preferences about the meeting location and allow the active participants to request special equipments on the meeting location but before a meeting deadline. FR_004 FR_005 Re-plan a meeting to support external constraints like two meeting held at S7 same time or at same location, that meeting take place which is of higher priority Date March 25, 2010
More slides like this


Slide #47.

Traceability (Contd.) Forward Traceability (Domain requirement to Work Product) FR_006 FR_007 The system shall support conflict resolution according S7 to given 4 resolution policies; The system shall manage all the interactions among S7 participants required during the organization of the meeting FR_008 FR_009 The system shall support the negotiation and conflict S7 resolution processes; The system shall keep participants informed about S5 schedules and their changes FR_010 The meeting scheduler system must in general handle S7 several meeting requests in parallel. FR_011 The meeting scheduler system should cancel or reschedule the meeting S7 with lower priority to resolve the conflict with a meeting with higher priority level when they overlap in time or space. If two equally important meeting overlaps then we choose first come first served. FR_012 The user who can login into the system/ or a new user who is successfully S2 able to register can initiate a meeting FR_013 The meeting scheduler system shall allow the initiator to set ‘priority level’ S4 of the meeting in order to avoid conflict in scheduling two or more meetings. Date March 25, 2010
More slides like this


Slide #48.

Traceability (Contd.) Forward Traceability (Domain requirement to Work Product) FR_014 An initiator should select the ‘room/location’ from the list of available locations. S4 The system should indicate the availability or unavailability of the room, in case of unavailability initiator has to choose other meeting room. FR_015 The initiator should select the ‘equipments’ needed for the meeting from the S4 equipments list; also active participants should have the option of selecting the equipments when the confirm their attendance to meeting FR_016 The system should send the reminder one day before the final meeting date FR_017 The initiator shall have a privilege to make any participant to active, important or S4 regular participant. If the meeting is cancelled by meeting scheduler then it should send the other S7 acceptable schedules to initiator depending on preference set entered. FR_018 S4 FR_019 If the acceptable schedules cannot be found to reschedule the meeting an email S7 shall be sent to initiator to reschedule the meeting with new date range. FR_020 As soon as the all important participants reject the meeting invitation the system S5 shall send an email to initiator regarding rescheduling a meeting. FR_021 The participants should be able to change their response at any time before the S5,S6 deadline FR_022 As soon as meeting is confirmed, the confirmation should be sent to participants S5 via email Date March 25, 2010
More slides like this


Slide #49.

Traceability (Contd.) Backward Traceability Screen ID Screen Description Backward Traceability S1 Login Screen NFR_001 FR_012 S2 Register Page NFR_010 S3 Homepage S4 Initiate Meeting Request Page DFR_005, DFR_007,FR_002 FR_013, FR_014, FR_015 FR_016, FR_017 , NFR_006 S5 Meeting Status Page FR_020 , FR_022, NFR_007 S6 Pending Request Page DFR_006, FR_004, FR_019 FR_021, NFR_011 S7 User Responses FR_012 FR_001, FR_003, FR_005 FR_006, FR_007 , FR_008 FR_010, FR_011, FR_018 NFR_007, NFR_003 NFR_006, NFR_005, NFR_011 Date March 25, 2010
More slides like this


Slide #50.

Outline Outline Current System Proposed System Stake Holders/Interest Requirement Engineering Process Prototype Traceability Changeability Conclusion Date March 25, 2010
More slides like this


Slide #51.

Changeability WMS which our requirement engineering team developed can accommodate 18.18% of changes. This is because, we presume that, modification in 4 Functional Requirements, namely, FR4, FR5, FR11, and FR15, can be easily incorporated into the system. There are totally 22 Functional Requirements and thus this gives us 18.18% of change accommodation into our system. Date March 25, 2010
More slides like this


Slide #52.

Outline Outline Current System Proposed System Stake Holders/Interest Requirement Engineering Process Prototype Traceability Changeability Conclusion Date March 25, 2010
More slides like this


Slide #53.

What Next? Date March 25, 2010
More slides like this


Slide #54.

Outline Outline Current System Proposed System Stake Holders/Interest Requirement Engineering Process Prototype Traceability Changeability Conclusion Date March 25, 2010
More slides like this


Slide #55.

Conclusions Conclusion Date March 25, 2010
More slides like this


Slide #56.

Questions ? Any question Date March 25, 2010
More slides like this


Slide #57.

Thank You Date March 25, 2010
More slides like this