1. 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, B RYAN P ARKER J ASSEM S HAKIL, J EEVAN K UMAR, M UHAMMAD A BDULLAH, P REETI G ANESHMOHAN, S EAN W ILSON, V INAY S AMPATH K UMAR Instructor: Dr. Lawrence Chung 1

2. A GENDA  System Overview  Requirement Engineering Process  Issues & Resolutions  Writing Specifications  Prototype  Future Work 2

3. System Overview 3

4. W HY ??? Some Common Problems:  Time Constraint  Unidentified Roles  Availability of attendees  Availability of meeting locations  Convenience and Efficiency 4

5. W HY ??? Solutions to all these problems: Automation!  Reduces time and effort  Identifies roles and customizes meeting scheduling process accordingly  Ensures availability of attendees as per their convenience  Ensures availability of most appropriate meeting location  Easy to use for naïve users 5

6. W HAT ???  Monitor Meetings  Plan Meeting  Re-plan Meeting  Resolve Conflicts  Manage Interactions  Manage Concurrent Meetings 6

7. H OW ???  Monitor Meetings -> Accurately control and manage the entire meeting scheduling process  Plan Meeting -> Select most convenient meeting date and time, and location  Re-plan Meeting -> Support variations and changes in the Schedule  Resolve Conflicts -> Perform negotiations  Manage Interactions-> Maintain necessary but minimal communication  Manage Concurrent Meetings-> Allow users to submit and manage multiple meeting requests 7

8. Requirement Engineering Process 8

9. P ROCESS M ODEL Evolutionary Spiral Model 9

10. P ROCESS  Analyzing and discussing requirements in team meetings  Constructing deliverables  Reviewing deliverables for amendments before submission  Making final changes 10

11. P ROJECT D ELIVERABLES S N O.D ELIVERABLE D EADLINE Phase 1 1 Software Project Management Plan September 3 rd, 2009 2 Software Requirements Specification September 18 th, 2009 3 Prototype September 24 th, 2009 4 User Manual September 27 th, 2009 The project is divided into two phases with each phase having two sub-phases. The following are the deliverables at the end of Interim-Phase I. 11

12. T EAM R OLES  Developer: A developer will be responsible to construct the deliverable and perform relevant software engineering practices.  Reviewer: A reviewer will be responsible to review the deliverables and suggest appropriate modifications when deemed necessary.  Team Lead: A team lead will facilitate communication between Developers and Reviewers and will act as an arbiter for conflict resolution between the two teams. The major responsibility of Team Lead is to ensure the production of high quality deliverables before the deadlines. Team Lead DevelopersReviewers 12

13. P ROJECT R ESPONSIBILITIES – P HASE 1 D ELIVERABLE D EVELOPERS R EVIEWERS T EAM L EAD ( S ) S OFTWARE P ROJECT M ANAGEMENT P LAN J ASSEM M UHAMMAD A DITYA A JAY B RYAN J EEVAN P REETI S EAN V INAY R EQUIREMENTS S PECIFICATIONS B RYAN J ASSEM J EEVAN M UHAMMAD P REETI S EAN V INAY A DITYA A JAY A DITYA P ROTOTYPE A DITYA A JAY M UHAMMAD B RYAN J ASSEM J EEVAN S EAN V INAY P REETI U SER M ANUAL A JAY B RYAN J ASSEM S EAN A JAY M UHAMMAD P REETI V INAY J EEVAN 13

14. Issues 14

15. D EFINITION I SSUES  Incompleteness  Undefined phrases  Incomplete list  Ambiguity  Imprecise wording  Unclear phrases  Inconsistency  Contradictory Statements  Unsoundness  Incorrect/Illogical requirements 15

16. I DENTIFYING I SSUES AND T HEIR S OLUTIONS  Identify the issue  Propose elements of the solution  Negotiate different approaches  Specify a preliminary set of solution requirements 16

17. T YPES OF REQUIREMENTS  Domain: How do people-ware, software and hardware interact within the domain?  Functional: What are the services, the system must provide?  Non-Functional: What are the constraints, how will the system provide services? 17

18. D OMAIN R EQUIREMENTS – I SSUES & S OLUTIONS  [DR1] In the application domain, meetings are typically arranged in the following manner.  [DR1] In the application domain, meetings are arranged in the following manner.  [DR5] meeting date shall be defined perhaps by a pair (calendar date, time period).  [DR5] A meeting date shall be defined by a calendar date, day of the week, and time. 18

19. D OMAIN R EQUIREMENTS – I SSUES & S OLUTIONS  [DR7] The initiator could also ask, in a friendly manner, active participants to provide any special equipment requirements on the meeting location.  [DR7] The initiator asks active participants, people who are going to actively participant in a meeting, for any special equipment they might need at the meeting location (e.g., overhead projector, workstation, network connection, telephone, etc.)..  [DR19] Furthermore it should ideally belong to one of the locations preferred by as many important participants as possible.  [DR19] Furthermore it [the meeting room] shall belong to one of the locations preferred by the majority of important participants. 19

20. F UNCTIONAL R EQUIREMENTS – I SSUES & S OLUTIONS  [FR3] Monitor meetings, especially when they are held in a distributed manner;  [FR3] Monitor meetings which include arranging the meeting location and date, after consensus from the participants and getting the resources for the meeting, especially when they are held in a distributed Manner.  [FR5] Re-plan a meeting to support the changing user constraints;  [FR5] Only the meeting initiator is allowed to Re-plan or make changes to a meeting to support the changing user constraints. 20

21. F UNCTIONAL R EQUIREMENTS – I SSUES & S OLUTIONS  [FR8] Manage all the interactions among participants required during the organization of the meeting, for instance: to make participants aware of what's going on during the planning process;  [FR8] Everybody who received the meeting request are updated (includes important, active participants and also participants who declined the meeting request.) to make participants aware of what's going on during the planning process;  [FR10] Meeting requests can be competing when they overlap in time or space. Concurrency must thus be managed.  [FR10] Meeting requests can be competing when they overlap in time or space and in such cases ties are broken by the meeting initiator who decides if the meeting needs to be cancelled/postponed/changed. 21

22. N ON -F UNCTIONAL R EQUIREMENTS – I SSUES & S OLUTIONS  [NFR2] A meeting should be accurately monitored, especially when it is held in a virtual place. Here, nomadicity will then be important to consider;  [NFR2] A meeting shall be monitored, using valid and updated information including exclusion and preferred sets, locations and resource requests. Here, availability of precise aforementioned information to the meeting initiator regardless of his/her geographic location shall then be important to consider.  [NFR6] The system should reflect as closely as possible the way meetings are typically managed (see the domain theory above);  [NFR6] The system shall exactly reflect the way meetings are managed (see the domain theory above); 22

23. N ON -F UNCTIONAL R EQUIREMENTS – I SSUES & S OLUTIONS  [NFR9] 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.;  [NFR9] The system shall not: 1) allow a person to attend more than one meetings at the same time 2) allocate a meeting room to more than one meetings at the same time.  [NFR12] The system should be customizable to professional as well as private meetings -...;  [NFR12] The system shall allow a meeting initiator to term a meeting as professional or private at the time of initiating a meeting. The system functionality will remain unaffected in professional as well as private meeting 23

24. I MPROVED U NDERSTANDING  Lack of ambiguity – There is only one possible interpretation for each requirement statement  Conciseness – Represented in minimal number of words  Completeness – The specification contains all requirements known to date  Consistency – There are no conflicting requirements  Traces to origins – The source/origin of each requirement is identified. It may have evolved from a more general requirement  Organized into logical meaningful groups 24

25. W RITING S PECIFICATIONS  Uniquely identify each specific requirement to make referencing them easier (e.g. DFR1, FR 5, NFR10)  Establish a single source for requirement storage (SRS Document)  Follow a standard or recommended guide for adopting a structure for the document. (WRS Template)  Adhere to standard rules for writing good requirements statements (atomic requirements, appropriate use of shall/should/will)  Assess and improve document quality (traceability matrix, percentage of possible change) 25

26. F UNCTIONAL & N ONFUNCTIONAL T RACEABILITY NFR1NFR2NFR3NFR4NFR5NFR6NFR7NFR8NFR9 NFR10NFR11NFR12NFR13NFR14 FR1xxxxxxxxxxxx FR2xxx FR3xxx FR4xxx FR5xxxxx FR6xxxxxx FR7xxxx FR8xxxxx FR9xxx FR10xxxxx FR11xxx FR12xxxx FR13xxxx FR14xxxx FR15xxxxxxxx Functional vs Nonfunctional 26

27. P ROTOTYPE  Blitzkrieg Distributed Meeting Scheduler 27

28. L OG -I N 28

29. H OME P AGE 29

30. I NITIATE M EETING 30

31. A CTIVE A TTENDEES 31

32. I MPORTANT A TTENDEES 32

33. R EGULAR A TTENDEES 33

34. F INALIZE M EETING 34

35. P ERCENTAGE OF C HANGE  25% of Change  Rationale  Weighted each requirement based on the level of implementation difficulty.  Selected the requirement that are the least difficult to change.  Calculated percentage: Requirement Changes/Total Requirements 35

36. F UTURE W ORK  Process Specification  Issue Analysis Revisited  Product Requirement Models  Prototype 36

37. T HANK Y OU ! Any Questions? 37