SDMS Project Phase Ⅰ Duk-Jin Kim Tu Peng Yan Shi

Agenda  Introduction  Why?-Enterprise Requirements  What?-System Functional Requirements  How?-System Non-Functional Requirements  Prototype  Next step

Introduction Process for prototyping for prototyping [Kotonya&Sommerville98]

 All three members in our team play the following roles: Requirement Engineers Project Managers Software Engineers Domain Experts End Users Introduction Roles

Enterprise Req. Real World Problems  Communication Complexity  Schedule Meeting Date Complexity  Schedule Meeting Location Complexity  Time Consuming Job  Conflict Between Date and Location

Enterprise Req. Existing System  Communication Overhead No Automation in Scheduling Date Internet-Dependent System

Enterprise Req. System Goal  Provide Communication Solution  Provide Automated Scheduling

Enterprise Req. Preliminary Understanding

 Any related system?  User roles? e.g. Active, important,..  Location and date conflict?  Any unstated problem? e.g Cancellation,..  Development cost? Enterprise Req. Issues

Enterprise Req. Improved Understanding  Stakeholders

Enterprise Req. Improved Understanding  FRs & NFRs - Setting Date

Enterprise Req. Improved Understanding  FRs & NFRs - Setting Location

Enterprise Req. Improved Understanding  FRs & NFRs - Canceling Meeting

 Date conflict Opt1: extends the date range Opt2: remove some dates from the exclusion set Opt3: remove some participants Opt4: add new date to the preference set. Enterprise Req. Conflict

Location conflict Opt1: Preferred by many participants. e.g over 70% of participants.. Opt2: Preferred by many important participants. Opt3: Initiator ’ s choice Enterprise Req. Conflict(cont.)

Location and Date conflict Opt1: Initiator ’ s choice Enterprise Req. Conflict(cont.)

System Functional Req. Preliminary Understanding

 Is the system available to everyone? Does every user play the same role? Solution: Add a Login/Logoff module to set the users ’ authorization level. Users with different authorization level have different constraints to using the system. How to monitor meetings ? System Functional Req. Issues

 How to monitor meetings is not mentioned in the functional requirement. Option 1: When having a virtual meeting in a distributed manner, every participant should have his/her status, for example, giving presentation, online/offline, etc, displayed publicly so that every participant can see it. Option 2: Since this requirement is ambiguous, we can just consider it as not part of the system ’ s core functions and dispose it. Solution: Option 1 Reason: Enhance the functionality of the system. System Functional Req. Issues

 What kind of constraints expressed by participants should the meeting initiator consider? How to derive these constraints? Option 1: Design a sub-module within the meeting plan module to derive all kinds of constraints from participants. Option 2: Get the exclusion set and preference set from the interaction management module and use them as constraints. Solution: Option 2. Reason: Decrease the redundancy of the system, and exclusion set and preference set are enough for the initial planning of a meeting. System Functional Req. Issues

 What does the “ Client ” refer to in the statement “ Support conflict resolution according to resolution policies stated by the client. ” ? Option 1: system administrator Option 2: meeting initiator Solution: Both Option 1 and Option 2 Reason: System administrator should have the predominate decisions on resolution policies. In the meantime, meeting initiator ’ s opinion also weighs.

System Functional Req. Improved Understanding

System Non-Functional Req. Preliminary and Improved

System Non-Functional Req. Issues  ambiguity What is typical ways of managing meeting is very unclear. What does “ monitor meeting ” mean is unclear. Dynamically and flexibilities also are unclear.  omission Can ’ t understand “ explicit ”  other accurately and nomadcity are controversial.

System Non-Functional Req. Priority of the NFRs  1 Manage  1 Replanning  1 Reuse  2 Variation  2 Requesting  2 Determinate  2 Communication  2 Communicate via Internet  2 Privacy  3 Monitor  3 Handle

Demo Mock Up. Login

Demo Mock Up. New Meeting

Demo Mock Up. Propose Date

Demo Mock Up. Important Notice  All examples come from  Actually system may be different.

Next Step  Further improvement of ER & SR  Developing the prototype

Thank You! Duck-Jin Kim Tu Peng Yan Shi Sep 2006