= Functional and Non-Functional Requirements = (We will need to combine our brainstorming information in a clear and concise way into these functional and non-functional lists below)[[BR]] (We need to refine the list below as well as the requirements we add from our brainstorming)[[BR]] (We need to think of everything - we won't have to implement all of it)[[BR]] == Functional Requirements == (NOTE: Functional Requirements will begin with FR#:, these will need to be refined, broken down, and more added.) * FR1: The SDMS system shall allow user(s) to login. * FR1.1: system login shall be accomplished through a login screen * FR2: The SDMS system shall maintain user information security. * FR2.1: un-authorized user shall not be allowed into the system * FR2.2: authorized users shall not be allowed to access other user's information * FR3: The SDMS system shall maintain a user date exclusion set, those dates each user cannot attend a meeting. * FR3.1: adding of dates to the exclusion set * FR3.2: removal of dates from the exclusion set * modificcation of dates in the exclusion set * FR4: The SDMS system shall maintain a user date preference set, those dated each user prefers to attend a meeting. * FR4.1: adding of dates to the preference set * FR4.2: removal of dates from the preference set * FR4.3: modification of dates in the preference set * FR5: The SDMS system shall allow monitoring of the system. * FR6: The SDMS system shall plan meetings under the constraints expressed by participants (see domain theory). * FR7: The SDMS system shall allow replanning of meetings in support of changing user constraints * FR7.1: modification of exclusion set * FR7.2: modification of preference set * FR7.3: modification of preferred location before a meeting date/location is proposed * FR7.4: take into account constrainsts after a meeting date/location has been proposed * FR8: The SDMS shall allow the setting of bounds n replanning * FR9: The SDMS system shall allow client specified conflict resolution * according to policies entered by client(s) * FR10: The SDMS system shall allow the management of all interactions among participants required during the organization of the meeting: * FR10.1: to communicate requests * FR10.2: to get replies even from participants not reacting promptly * FR10.3: to support the negotiation and conflict resolution processes * FR10.4: to make participants aware of what's going on during the planning process * FR10.5: to keep participants informed about schedules and their changes * FR10.6: to make them confident about the reliability of the communications * FR11: The SDMS system shall allow cancelling the meeting * FR12: The SDMS system shall allow managing the info of all users such as passwords, email address and so forth * FR13: The SDMS system shall do handle the necessary house cleaning once meetings are over * FR13.1: make end marks * FR13.2: store meeting info or delete it == Non-Functional Requirements == (NOTE: Non-Functional Requirements will begin with NFR#:, these will need to be refined, broken down, and more added) * NFR1: The SDMS system shall be functionally intuitive * NFR2: The SDMS system shall be easily used by non-experts * NFR3: The SDMS system shall be accurately monitored (IE: held in virtual place, nomadicity) * NFR4: The SDMS system shall replan a meeting as dynamically and flexible as possible * NFR5: The SDMS system shall keep the amount of interaction among participants as minimal as possible (number and length of messages) * NFR6: The SDMS system shall considerably reduce the amount of overhead usually incurred in meeting organization (potential distributed attendees) * NFR7: The SDMS system shall reflect, as closely as possible, the way meetings re typically managed * NFR9: The SDMS system shall alert attendees as conviently and early as possible of the date and location of the meeting * NFR10: The SDMS system shall accomodate decentralized requests as far as possible (any authorized user can request a meeting independently of their whereabouts) * NFR11: The SDMS system shall not allow physical constraints to be broken, (a person cannot attend two or more different meetings at the same time, a meeting room cannot be scheduled for two or meetings at the same time, etc) * NFR12: The SDMS system shall provide an appropriate level of performance * * NFR12.1: elapsed time between submission of a meeting request and determination of corresponding date/location shall be minimal * * NFR12.2: elapsed time between determination of meeting date/location and communication of meeting information to all participants shall be minimal * * NFR12.3: a lower bound shall be fixed between the time at which the meeting date is determined and the time at which the meeting is actually taking place * NFR13: The SDMS system shall enforce all privacy rules * * NFR13.1: non-priviledged particiapnts shall not be allowed to know the constraints stated by other participants * NFR14: The SDMS system shall allow customization to professional and private meetings * * NFR14.1: different restrictions on the time periods that may be allocated (meeting hours during office hours, private activites during leisure time) * NFR15: The SDMS system shall be flexible enough to accomodate evolving data * * NFR15.1: varying sets of concerned participants * * NFR15.2: address to which participant may be reached may vary * NFR16: The SDMS system shall be easily extensible * * NFR16.1: handling of explicit priorities among dates in preference sets * * NFR16.2: handling of explicit dependencies between meeting date and meeting location * * NFR16.3: participation through delegation - a participant may ask another person to represent him/her at the meeting * * NFR16.4: variations in the date formats, address formats, interface language, etc * * NFR16.5: partial re-use in other contexts (to help establish course schedule)