1. Dineshwari Byrappa Nagraj Rashi Gupta Shreya Modi Swati Satija Magesh Panchanathan

2. INDEX SYSTEM GOALS OUR GOALS TEAM ROLES SDMS OVERVIEW SOURCES WHY SCHEDULING SYSTEM? DEPENDENCY GRAPHS ISSUES PROTOTYPE

3. SYSTEM GOALS To decide upon the meeting date, time and location efficiently. To come up with an organized meeting where all the specialized equipments are available for the convenience of the attendees. The meeting scheduler should be able to mediate the conflicts in setting up the meeting, rescheduling meeting and re- planning the meeting. The meeting scheduler must provide the support for virtual place. The system should be simple and user-friendly. The scheduler must keep its potential attendees updated about the upcoming meetings.

4. OUR GOALS To learn how to read and analyze a requirement specification. To comprehend the domain requirements of any system under development. To match the requirement specification with the enterprise (domain) requirements and to extract ambiguities from the requirement specification document. To learn how to resolve the persistent ambiguities and thereby develop clear and concise requirement specification document. To understand the group dynamics in requirements engineering team. To learn how to identify the stakeholders of the system.

5. Team Roles Team memberRoleFunction Rashi GuptaUser World: End-User Meeting Participant Project Manager Meeting Initiator Describe functions from the enterprise perspective.  Describe constraints from the enterprise perspective.  Describe user interface. Make project plan. Swati Satija Dinikeshwari Nagraj Subject World: Domain Expert Customer  Describe functions from the enterprise and system perspective  Describe constraints from the enterprise and system perspective  Describe the market position of the system Shreya Modi System World: Requirements Engineer Software Engineer  Specify requirements and dependency graphs  Validate requirements with customers and users, talk about open issues and improve understanding Dinikeshwari Nagraj Swati Satija System World: Product Manager Developer  Review Product Development Process.  Build prototype

6. SOURCES Documents from Fall 2005 and Summer 2006 projects which include presentation documents and specification documents. Project 1: First Iteration –Requirements Elicitation: Initial Understanding document. It helped in understanding and tracing the solution for the problem. Lotus notes and SAP applications with similar requirement. Team discussions and brainstorming. Relevant websites like www.meetingwizard.com, www.meetingsnet.com, etc.

7. SDMS OVERVIEW Imagine !!!!!!!!!!!!!!!!!!!!! Your boss pointing in your direction, says “schedule a meeting, and make sure everyone can make it and make sure that the conference room isn't already booked when we get there!" So What do you do?

8. OUTLINE

9. WHY SCHEDULING SYSTEM? Problems Interactions Complex multi stakeholder interactions leads to conflicts. Time consuming Initiator has to perform many activities: -To invite the participants. -To resolve conflicts. Traveling costs Participants from different locations.

10. WHY SCHEDULING SYSTEM? Resolutions Email Integration :Saves time Provides the ability to contact attendees and send them attachments using your own email client. Group Views: Avoids conflicts View the availability and schedules of teams or groups of people from a single window. Real-time Meeting Invitations Schedule meetings in real-time - you request a meeting and the attendees are notified immediately.

11. WHY SCHEDULING SYSTEM? Resolutions Share Availability Share your free and busy time with others, vastly simplifying the group scheduling process. Resource Scheduling Reserve conference rooms, A/V equipment or other shared resources for your meeting. Simplified Scheduling Eliminates the complex hassle of scheduling meetings –no more juggling other people’s schedules, telephone tag or email delays and subsequent rescheduling

12. ENTERPRISE FUNCTIONAL REQUIREMENTS - LITERAL

13. ENTERPRISE FUNCTIONAL REQUIREMENTS - RESOLVED

14. MEETING ROOM

15. CONFLICT RESOLUTION - LITERAL

16. CONFLICT RESOLUTION - RESOLVED

17. ENTERPRISE NONFUNCTIONAL REQUIREMENTS

18. SYSTEM FUNCTIONAL REQUIREMENTS - LITERAL

19. SYSTEM FUNCTIONAL REQUIREMENTS - RESOLVED

20. SYSTEM NONFUNCTIONAL REQUIREMENTS

21. ISSUES - AMBIGUIOUS ISSUE: The initiator could also ask, in a friendly manner, active participants to provide any special equipment requirements on the meeting location. Issue Description: What if the initiator does not ask active participants about the special equipments? Will those special equipments be available at the time of the meeting? Issue Resolution: Instead of using ‘could’ SRS should have ‘must’ or ‘shall’.

22. ISSUES - AMBIGUIOUS ISSUE: The proposed meeting date should belong to the stated date range and to none of the exclusion sets, furthermore it should ideally belong to as many preference sets as possible. Issue Description: What does ‘ideally’ mean? What should be considered as ideal? What does as many as possible mean? The system cannot decide itself these issues. Issue Resolution: Ideal situation should be defined by the end user in terms of the attributes. Depending on the number of participants, there should be a lower limit on the minimum number of participants required for the meeting to take place.

23. ISSUES - AMBIGUIOUS ISSUE: Each conflict resolution should be done as quickly as possible. Issue description: What does as quickly as possible mean? How does the system know the definition of this term? Issue Resolved: Some upper time limit should be provided to the system. Within this time limit the conflict must be resolved. Otherwise, the system may take a long time to resolve issues. Everyone has its own definition of the terms.

24. ISSUES - AMBIGUIOUS ISSUE: A non-privileged participant should not be aware of constraints stated by other participants. Issue description: What does non-privileged participants mean here? Issue resolved: The roles and functions of the non- privileged participant must be defined in the SRS.

25. ISSUES - AMBIGUIOUS ISSUE: The meeting date and location should be as convenient as possible. Issue Description: How can the scheduler decide what is ‘as convenient as possible’ ? Issue Resolved: The term should be concrete in meaning. ISSUE: Variations in date formats, address formats, interface, language, etc. Issue description: what does ‘etc’ mean here. The system should be precisely told what it has to do. Issue Resolution: Words like ‘etc’ should be excluded from the SRS.

26. ISSUES - AMBIGUIOUS ISSUE: It is absolutely necessary, however, to allow each meeting to take place in the virtual place Issue Description: Nothing is absolute in life. Issue Resolved: The term ‘Absolute’ should not be used here. ISSUE: The number of interactions should be kept minimal Issue description: what does the term ‘minimal’ mean here. Issue Resolved: The scheduler needs to be provided crisp and unambiguous definitions. The term minimal must be defined concisely in terms of number of transactions relating to the attributes.

27. ISSUES - MISSING ISSUE: Conflicts can be resolved in several ways. Issue description: How does the scheduler decide which conflict resolution should be opted out of the several resolutions ? Issue Resolution: The conditions must be provided by the initiator to the system so that the system can easily decide which resolution to follow at what time.

28. ISSUES - MISSING ISSUE: The initiator can extend the date range. Issue description: By how much can the meeting date range be extended? And on what basis? Issue resolved: Some method to extend the date range should be provided to the scheduler. Or some upper limit should be provided on the extended date range.

29. PROTOTYPE

30. LOGIN SCREEN

31. This screen displays the upcoming Meetings for the user, the user can either Schedule new meeting or View details of his meetings or Check the meeting outcome or Print the meeting report.

32. This is the Schedule New Meeting screen; here the initiator creates a new meeting by giving the meeting title, time duration, start time, end time, date and meeting agenda.

33. This is the View Meeting screen; here the user can view the details of his new meeting. The user confirms his meeting, if there is a conflict in timing he can change the time by clicking the ‘Conflict in Time??’.

34. THANK YOU