Example Requirements Document
[Sections 1, 2 and 5 are customer-oriented. Sections 3 and 4 are developer-oriented]
IMS: Invisible Meeting Scheduler
Requirements Document
1 System Objectives
1.1 The Invisible Meeting Scheduler (IMS) is a software application to assist in the scheduling of meetings among individuals whose schedules are available in an online calendar.
1.2 Focus groups conducted by our marketing department show that users of time management packages would respond favorably to an IMS that satisfied or helped them satisfy the following objectives:
2 System Context
2.1 IMS will provide an easy-to-use graphical user interface (GUI) as part of the average user’s working desktop environment, which will be used for calling meetings and notifications.
2.2. Regular schedule information will continue to be serviced using the online calendar (OLC).
2.2.1 Several unconnected OLC systems may be accessible from IMS through a standard calendar interface protocol (SCIP) for the purposes of querying any person’s or room’s schedule and making reservations.
2.3 Changes in the user population or configuration of rooms are made by administrators. (In most user organizations these will be HR or Facilities staff.)
2.4 The administrator is also responsible for entering customization information into IMS, such as the standard working day for the user organization.
3 Functional Requirements
3.1 Scheduling a meeting
3.1.1 A person calling a meeting (henceforth called the Initiator) will enter information into IMS about the desired meeting, such as but not limited to its proposed purpose, earliest and latest times at which it can usefully be held, the names of desired attendees, and an anticipated duration. IMS shall provide defaults for missing elements.
3.1.2 When the Initiator instructs IMS to schedule the meeting for which this information has been entered, IMS shall obtain from those OLCs that contain schedule data for the desired attendees those attendees’ free times during the interval between the earliest and latest times stipulated by the Initiator. IMS shall choose the earliest feasible time for the meeting that meets the constraints specified by the Initiator and the free times returned by the OLCs.
3.1.3 When IMS chooses a time for a meeting, it shall send queries to the OLCs for all the rooms in which the meeting could be held to ascertain which rooms are vacant during the selected time.
3.1.3.1 If no rooms are vacant during the selected time, IMS shall choose the next feasible time.
3.1.3.2 IMS shall choose which room should be the venue for the meeting from the set of rooms free at the selected time by a room-choice algorithm that shall take account of the size of the room given the number of invitees to the meeting, and the convenience of the room for the invitees.
3.1.4 If no feasible time exists for the meeting that meets the Initiator’s constraints and the OLC schedule data for the attendees, or no room is free during any of the feasible times, IMS shall present the Initiator with a selection of choices including the following:
(a) Schedule the meeting based on a subset of the originally named attendees.
(b) Put the latest time for the meeting back further into the future.
(c) Abandon the scheduling of this meeting.
3.1.5 If either 3.1.4 (a) or (b) is chosen, IMS shall obtain from the OLC’s in question further schedule data and choose the best feasible time as described above. If no feasible time is found again, IMS shall present the Initiator with the same choices again.
3.1.6 If there is at least one feasible time and IMS chooses a time for the meeting, IMS shall display appropriate notification messages to the Initiator and all the invited attendees.
3.1.6.1The wording of the message shall depend on whether the recipient is
(a) the Initiator (who knows about the meeting and is being informed that it has been scheduled)
(b) an invited participant (who is learning about the meeting for the first time and who is being "strongly" invited to attend)
(c) an invited participant who was not in the subset of people whose schedules were checked when the Initiator chose option (a) above (such invitees being "weakly" invited, as they are known to be busy at the chosen time).
3.1.7 In addition to notifying the Initiator and invited attendees, IMS shall send update messages to the OLC’s of the invited attendees and the room chosen as the venue, these updates representing the reservation of the chosen time period for the meeting.
3.2 Canceling a meeting
3.2.1 Only the Initiator of a meeting may normally cancel it (but see 3.4).
3.2.2 When the Initiator instructs IMS to cancel a meeting that has not yet been scheduled, IMS shall abort any scheduling actions that it has started (e.g. querying OLCs), shall delete all references to the meeting, and shall display a confirmation message to the Initiator.
3.2.3 If the meeting to be canceled has already been scheduled, IMS shall behave as specified in 3.2.2 and shall additionally do the following:
3.2.3.1 Display notification messages to the invited attendees informing them of the cancelation.
3.2.3.2 Send update messages to the OLCs for the attendees and the room chosen as the venue, these update message representing the freeing of the time previously reserved for the meeting.
3.3 Rescheduling a meeting
3.3.1 An attendee may request that a scheduled meeting be rescheduled at another time. The attendee will enter the reschedule request into IMS. IMS shall then display a notification message to the Initiator containing the attendee’s request.
3.3.2 When an Initiator has received a notification message as in 3.3.1, IMS shall provide options for the Initiator to continue the meeting as planned with or without the attendee, to reschedule, or to cancel the meeting.
3.3.2.1 If the Initiator decides to contine the meeting as planned and the attendee is dropped from the invitation list, IMS shall record the changed attendance at the meeting and send an update message to the OLC for the attendee to free the time.
3.3.2.2 If the Initiator decides to continue the meeting as planned with the attendee still attending, IMS shall take no action. (The Initiator and the attendee are assumed to work out the schedule conflict in person.)
3.3.2.3 If the Initiator decides to reschedule the meeting, IMS shall schedule the meeting as described in 3.1, but taking account that the earliest time as originally stipulated by the Initiator may now have passed, in which case the earliest time should now default to the present time plus a default period to allow for notification and preparation.
3.3.2.3.1 Notification messages sent to attendees regarding the rescheduling of a meeting shall be worded in such a way to refer clearly to the changed schedule.
3.3.2.4 For cancelation, see 3.2.
3.4 Adding or removing a person
3.4.1 Only an administrator may add or remove a person from a system (e.g. in the case when an employee leaves the company or is transferred to a site that is not an IMS user organization).
3.4.2 When an administrator adds a person to the system, IMS shall record the information about that person (including name, access information, regular work hours, work location etc.) for future use in scheduling decisions.
3.4.3 Removal of a person from the system takes place at a time either specified by the administrator (the "effective time" of the removal) or, by default, immediately.
3.4.4 When an administrator removes a person from the system, IMS shall, at or after the effective time, remove records about that person and the person’s attendance at previous meetings.
3.4.5 IMS shall cancel any previously scheduled meeting that was called by the person being removed if the meeting has been scheduled to take place after the time of the person’s removal.
3.4.5.1 Any such cancelation of a meeting in the case of the Initiator being removed from the system shall follow the description in 3.2 with the exception that IMS shall generate appropriate notification messages to explain the cancelation.
3.4.6 IMS shall notify the Initiator of any meeting that a person who is being removed from the system was to attend if that meeting had been scheduled to take place after the effective time of the removal. IMS shall provide the Initiator with the options to cancel the meeting or to continue with it as planned. If the Initiator elects to continue the meeting as planned, IMS shall take no further action. If the Initiator elects to cancel the meeting, IMS shall cancel the meeting as in 3.2.
3.5 Adding or removing a room
3.5.1 Only administrators may add or remove rooms (e.g. in the case of building work).
3.5.2 When an administrator adds a room to the system, IMS shall record the information about that room (including name, location etc.) for future use in scheduling decisions.
3.5.3 Removal of a room from the system takes place at a time either specified by the administrator or, by default, immediately.
3.5.4 Removal of a room may be temporary with a specified end time (e.g. removal for the purpose of decoration) or, by default, permanent.
3.5.5 When an administrator removes a room permanently from the system, IMS shall, at or after the effective time, remove records about that room.
3.5.6 When a room is removed temporarily, IMS shall retain information about the room but shall not consider it as a venue for a meeting (i.e. IMS shall not query the room’s OLC) until the room is available again.
3.5.7 If a meeting had been previously been scheduled to take place at a time after the permanent removal of the room or during the temporary removal of the room, IMS shall attempt to re-locate the room by sending queries to the OLCs of all the other convenient rooms to ascertain which if any are vacant during the scheduled time.
3.5.7.1 If other rooms are vacant during the scheduled time, IMS shall choose a new room (see 3.5.1) and shall notify the Initiator and attendees of the changed venue. IMS shall also send update messages to the OLCs of the old and new venues to free and reserve the time, respectively.
3.5.7.2 If there is no other room vacant during the scheduled time for the meeting, IMS shall notify the Initiator of the need to reschedule the meeting and shall provide the Initiator with the options to cancel the meeting or to reschedule it.
3.5.7.2.1 If the Initiator elects to cancel the meeting, IMS shall cancel the meeting as in 3.2.
3.5.7.2.2 If the Initiator elects to reschedule the meeting, IMS shall reschedule the meeting as in 3.1 with the following differences:
(a) Notification messages shall be worded in such a way to refer clearly to the changed schedule and location.
(b) The earliest time for the meeting previously stipulated by the Initiator may now have passed, in which case the earliest time should now default to the present time plus a default period to allow for notification and preparation.
4 Quality Requirements
4.1 Performance
4.1.1 If a feasible time and venue exists for a meeting, IMS shall choose a time and venue and display a notification to the Initiator in less than half the time it would take for the Initiator to call one attendee.
4.1.2 IMS shall show no visible deterioration in response time as the number of persons and rooms in the system increases.
4.1.3 IMS shall require a reasonably small amount of memory so that enough of it is permanently resident to provide an Initiator and notification interface.
4.1.4 IMS shall load as quickly as comparable productivity tools on whatever environment it is running in.
4.2 Reliability
4.2.1 IMS shall be available for use as much as comparable productivity tools.
4.3 Usability
4.3.1 IMS shall provide a user interface comparable to the UI of the OLC so that users do not have to learn a new style of interaction.
4.3.2 Users will be able to understand the layout and options of the IMS UI.
4.3.3 Notification messages generated by IMS shall be clear, succinct, and polite and free of jargon and TLAs.
4.4 Portability
4.4.1 IMS will be implemented on a platform that allows easy re-hosting on different hardware and OS.
4.5 Modifiability
4.5.1 IMS will be implemented using modern programming practices that maximize the maintainability and reusability of designs and code.
4.5.2 IMS will be implemented in such a way that alternative SCIPs to the OLCs could be added easily without affecting the logic of the design.
5 Future Requirements
5.1 Support for virtual meetings (involving videoconferencing and teleconferencing technology, multiple time zones, and resources that go beyond traditional A/V equipment).
5.2 Support for types of attendees at meetings, so that some attendees are more important than others for that meeting and their schedules therefore take priority.
5.3 Support for scheduling meetings involving people who do not have an accessible OLC (e.g. client meetings). Information about such "external" invitees’ schedules will be provided by the Initiator, although not necessarily immediately at the time of calling the meeting.