System Requirements Specification

for the
SynergySoft Distributed Meeting Scheduler
1. Introduction
This document describes the enterprise, software system functional and non-functional
requirements for the SynergySoft Distributed Meeting Scheduler product that is
planned for product development in the near future.
The purpose of this document is to define the requirements gathering process used to
elicit requirements from the product stakeholders, to define the overall vision and goals
of this new product, and to list those functional and non-functional requirements that are
essential to the success of this product.
This document was prepared with the understanding that establishing the proper vision
and business objectives of any new software product and the proper documentation of a
consistent, robust, well understood, and complete set of functional and non-functional
requirements is essential for product success.
2. References
IEEE Recommended Practice for Architectural Description of Software-Intensive
Systems, IEEE Std. 1471-2000.
IEEE Recommended Practice for Software Requirements Specifications, IEEE Std. 8301998.
IEEE Guide for Developing System Requirements Specifications, IEEE Std. 1233-1998.
3. Definitions
dashboard
form rawat
grafik kesehatan
inventaris
paket obat

Tampilan awal ketika membuka SiUKS setelah

admin login.
Form yang berisi data waktu siswa dirawat dan
waktu siswa pulang.
Grafik untuk menampilkan jumlah siswa yang
dirawat di UKS. Data ditampilkan perbulan.
Jumlah masing-masing obat yang tersedia dalam
penyimpanan UKS.
Beberapa obat yang sudah di-set menjadi satu
kesatuan untuk selanjutnya disewakan.

Pasien
penyewa obat
perawat UKS
profil
record kesehatan

Siswa yang sakit dan menjalani perawatan di UKS.

Perwakilan dari organisasi ekstrakuriler sekolah
yang menyewa obat dari UKS.
Perawat UKS adalah orang yang berjaga di UKS
sekaligus menjadi admin dari sistem yang akan
dibuat.
Halaman yang berisi data personal dari admin.
Kumpulan data berupa berat badan, tinggi badan,
dan riwayat kesehatan masing masing siswa.

4. Requirements Process
The requirements elicitation process is an engineering process that produces a consensus
document containing the enterprise, software system functional, and software system
non-functional requirements as developed through constructive interactions among the
various stakeholders of the planned product.
This engineering process consists of elicitation of requirements through technical
discussions, specification of requirements through textual and diagrammatic models,
and validation of those requirements through confirmation of the models through
discussions and presentations of those models.
Broadly speaking, these requirements answer the why, what, and how of the planned
product across the community of stakeholders of the planned product.
Representatives are selected from the various stakeholder organizations by their
respective management to participate in the requirements elicitation process and to
represent the organizational needs and wants of the organizations and groups they
represent.
These organizational stakeholders are broadly categorized into 4 worlds subject, user,
developer, and system representing 1) the subject matter or domain experts of the
scheduling and meeting organization, 2) the product customers and eventual users of the
meeting scheduling system, and 3) the software architects, designers, implementers,
testers, and maintainers of the planned software system, resulting in 4) the stated
requirements of the planned system.
4.1 Representatives
The representatives selected to participate in the requirements elicitation process are:
Yasaman Haghpanah
Ravindra Rudraraju
Sowjanya Sakruti

- System world
- Developer world
- User world

Jim Whitaker

- Subject world

4.2 Roles and Responsibilities

The role of the subject world representative is to provide meeting organization and
coordination expertise in addition to scheduling expertise for the planned product.
The role of the user world representative is to provide expertise pertaining to user
interface, intuitive operation, and overall usability of the planned product.
The role of the developer world representative is to provide expertise pertaining to the
feasibility and desirability of alternatives of proposed requirements and the inclusion of
industry standards and best practices for software development.
The role of the system world representative is to provide automation expertise and to
represent the requirements of the proposed software product the requirements engineer.
4.3 Process Requirements
The requirements elicitation process requirements are to produce a requirements
specification that documents the formal requirements of the planned product as specified
by the stakeholders of the product and provides adequate guidance to the development
organization to achieve a successful product in a time and resource effective manner.
Guidance for this process is provided in the IEEE standards listed in the References
section of this document.
Given the diversity of interests and approaches possible it is assumed that an adequate
consensus cannot be achieved for all aspects of any non-trivial engineering effort. It is
expected that due diligence be employed to investigate alternatives and to negotiate any
requirement or requirements in conflict.
Issues remaining unresolved at the end of the requirements elicitation process shall be
resolved by senior management in consultation with technical leadership prior to the
completion of the requirements elicitation phase.
4.4 Outstanding Issues
Outstanding issues are those requirements or aspects of the planned product which have
not been adequately resolved during the requirements elicitation process. Each issue is
uniquely numbered, contains a title, description, and contact information for the
representative sponsoring the issue.

Outstanding issues are resolved by senior management in consultation with technical

leadership through an assessment of impact, analysis of alternatives, or other approach
deemed appropriate. The method of analysis, disposition, and contact information of the
person responsible for the decision is maintained as part of the requirements
specification.
Outstanding issues are listed in Appendix A of this document.
5. Product Requirements
5.1 Enterprise Requirements
5.1.1

Vision Statement

The SynergySoft Distributed Meeting Scheduler will provide convenient means of

scheduling (and rescheduling) physical and virtual meetings among members of the
organization regardless of their physical locations in an efficient and cost-effective
manner.
5.1.2

Goals & Objectives

Goals and objectives related to the vision statement listed above:

5.1.3

improved communication to meeting participants regarding aspects of the

meeting (agendas, equipment, etc.) and changes to the planned meeting,

optimized selection of location (meeting room) given the list of meeting

participants,

dynamic meeting rescheduling to offload the work required for

rescheduling a meeting from the meeting initiator to the meeting
scheduling system,

support for virtual meetings with optional recording of the meeting for
subsequent replay and archival storage,

support for user authentication and authorization of features such as

delegation to an administrative assistant or secretary,

optimized implementation in terms of computational and network

resources, human involvement and interaction, and rapid response times.

Operational Scenario

A meeting initiator would use the SynergySoft Distributed Meeting Scheduler to

propose a meeting by providing the meeting topic, date range, duration, and
location to a list of potential meeting participants.
The meeting initiator may designate one or more potential meeting participants as
important meaning that their attendance at the meeting is required in order to have the
meeting.
Potential meeting participants are identified by a unique identifier that relates to a profile
containing the persons name, address, telephone and fax numbers, other organizational
information, and may contain a delegation to another person who is empowered to act
on the persons behalf.
The profile shall contain an attribute indicating whether or not the person is able to attend
a virtual meeting a meeting facilitated through teleconferencing on a computer.
The meeting proposal may include an agenda or list of topics for discussion during
the meeting and may include a list of required equipment.
Upon entry of the meeting proposal to the scheduler, the scheduler will scan the list of
potential meeting participants to determine of a time slot of the required duration
exists among all potential meeting participants.
If no time slot exists, the scheduler will inform the meeting initiator that no time
slot exists for all potential meeting participants and may optionally suggest an
alternative date range, duration, and location which is available.
If the date range and duration is acceptable but no location for the meeting is
available or feasible, a virtual meeting may be suggested for the available time slot.
The meeting scheduler may provide the meeting initiator a summary of the scan of
potential meeting participants depicting available time slots and schedule conflicts as a
means of informing the meeting initiator of the overall results of the scan.
If a time slot exists, the scheduler will temporarily reserve the time slot for the
proposed meeting and inform the potential meeting participant of the meeting and
request input as to will attend or will not attend.
A potential meeting participant or their delegate may either 1) accept the meeting
(will attend) or 2) refuse the meeting (will not attend). When accepting a meeting,
the potential meeting participant becomes a confirmed meeting participant and may
request special equipment. When refusing a meeting, the potential meeting participant
may provide a reason for the refusal.

Once all potential meeting participants have responded to the meeting proposal, the
meeting initiator shall 1) confirm the meeting which will result in the time slots of
accepting participants to be changed from a temporary reservation to a scheduled
meeting, or 2) cancel the meeting which will result in the time slots being temporarily
reserved to be freed, or 3) to replan the meeting by releasing the temporary reservations
and selecting a different date range, duration or location and starting the process
over.
At any time prior to the start of the meeting, the meeting initiator may cancel the
meeting or replan the meeting. Similarly, a potential meeting participant or confirmed
meeting participant may confirm or cancel their attendance at the meeting subject to the
administrative rules and practices of the participants.

5.1.4. UML Diagrams

5.1.4.1.

Use Case Diagram

Figure 1 Use Case Diagram

The above use case diagram shows the functionality of the SDMS system. The
whole SDMS system can be viewed in two perspectives. As an administrator you have
the privilege to maintain profiles of the users. And as a user you can check your meeting
schedules, reply to meeting requests or propose a meeting.

5.1.4.2.

Sequence Diagram

Figure 2 Sequence Diagram

The above diagram shows us the sequence of messages exchanged among the roles in the
system. It shows the flow of control among administrator, users (meeting initiator,
meeting participants) and system that collaborate in the context of the scenario.

5.1.4.3.

Domain Model

Figure 3 Domain Model

The above domain model tells us about the various entities involved and their
relationships. The domain model is created to understand the key concept of the system
and to familiarize with the vocabulary of the system.

5.1.5. Enterprise Functional Requirements

EFR-1
EFR-2
EFR-3
EFR-4

EFR-5
EFR-6

EFR-7
EFR-8
EFR-9
EFR-10

EFR-11
EFR-12
EFR-13

EFR-14

A meeting initiator shall initiate a meeting by deciding on a meeting

topic, by selecting a list of potential meeting participants, and by
selecting a date range, duration, and location for the meeting.
A meeting initiator or potential meeting participant shall provide the
ability where a person may delegate the ability to initiate or accept (or
decline) a meeting to another system user.
A meeting initiator shall be one of the potential meeting participants
by default but may opt to remove himself as a potential meeting
participant.
A meeting initiator shall confirm the meeting and the system shall
change the time slots of accepting meeting participants from a
temporary reservation to a scheduled meeting, once all potential meeting
participants have responded to the meeting proposal.
A meeting initiator shall cancel the meeting and the system shall
change the time slots from being temporarily reserved to be freed once
the meeting is canceled.
A meeting initiator shall reschedule the meeting and the system
reschedule the meeting by releasing the temporary reservations and
selecting a different data range, duration, or location and starting
the process over.
A meeting initiator may send a meeting proposal for a virtual
meeting for the available time slot if the date range and duration
is acceptable but no location for the meeting is available.
A meeting initiator may cancel the meeting or reschedule the meeting
at any time prior to the start of the meeting.
A meeting scheduler may (optionally) automatically propose another
meeting if current meeting is canceled by an important participant.
A meeting scheduler may provide the meeting initiator a summary of
the scan of potential meeting participants showing available time
slots and schedule conflicts as a means of informing the meeting
initiator of the overall results of the system.
The meeting initiator may designate one or more potential meeting
participants as important meaning that their attendance at the meeting
is required in order to have the meeting.
The meeting proposal may include an agenda or list of topics for
discussion during the meeting and may include a list of required
equipments.
A meeting scheduler will scan all the list of potential meeting
participants to determine a time slot of the required duration exists
among all potential meeting participants once a meeting proposal is
entered to the system.
A meeting scheduler will inform the meeting initiator that no time
slot exists for all potential meeting participants and may optionally

EFR-15

EFR-16

EFR-17
EFR-18

suggest an alternative date range, duration, and location which is

available.
A meeting scheduler will temporarily reserve the time slots for the
proposed meeting and inform the potential meeting participant of the
meeting and request input as to will attend or will not attend, if a
time slot exists.
A potential meeting participant or their delegate may accept or refuse
the meeting. If accepting, the potential meeting participant becomes a
confirmed meeting participant. If refusing, the potential meeting
participant may provide a reason for his refusal.
A confirmed meeting participant may request special equipment.
A potential meeting participant or confirmed meeting participant
may confirm or cancel their attendance at the meeting subject to the
administrative rules and practices of the participants.

5.1.6. Enterprise Non-Functional Requirements

ENFR-1
ENFR-2

Any physical changes to the location and its required equipment

shall be kept up-to-date.
: If any physical changes to the location and its required
equipments shall occur after a meeting proposal and before the
meeting date, the meeting initiator shall be notified promptly.

5.2 Software System Functional Requirements

The purpose of the SDMSTM system is to support the organization of meetings. The
system shall analyze each meeting request to determine a meeting date and location so
that most of the intended participants will effectively participate.
SFR-1
SFR-2
SFR-3
SFR-4
SFR-5
SFR-6
SFR-7

The meeting scheduler system shall be able to schedule a meeting

with a meeting topic, date range, duration, and location for a list of
participants.
The meeting scheduler system shall monitor meetings, since some of
the meeting held as a virtual meeting.
The meeting scheduler system shall be able to select a participant as
an important participant.
The meeting scheduler system shall cancel a meeting due to canceling
of an important participant.
The meeting scheduler system shall reschedule a meeting to support
conflict resolutions.
The meeting scheduler shall be accessed from the Web.
The meeting scheduler system may (optionally) automatically
propose another meeting if current meeting is canceled by an
important participant.

SFR-8

SFR-9
SFR-10
SFR-11
SFR-12
SFR-13

The meeting scheduler system may provide the meeting initiator a

summary of the scan of potential meeting participants showing
available time slots and schedule conflicts as a means of informing
the meeting initiator of the overall results of the system.
The meeting scheduler system may be able to include an agenda for a
meeting proposal.
The meeting scheduler system may suggest a virtual meeting for
available time slots if no location is available or feasible for the
meeting.
The meeting scheduler system may be able to include a list of
required equipment for a meeting proposal.
A meeting scheduler system will temporarily reserve the time slots
for the proposed meeting.
A meeting scheduler system will inform the potential meeting
participant of the meeting.

5.3 Software System Non-Functional Requirements

A good Meeting Scheduler system should meet the powerful functional requirement. It
should also pay attention to its non-fictional requirements. This section describes the
quality attributes that the Meeting Scheduler software should have.
5.3.1. Reliability
The SDMSTM system should emulate or imitate the manner in which human without
automation schedules meetings.
5.3.2. Performance
The elapsed time between the submission of a meeting request and the
determination of the corresponding date or location should be upon the meeting
participants count. If they are less than 20 people the elapsed time shall be less than
4 seconds, If the count is between 20 and 50, the elapsed time shall be less than 10
seconds. If the count is more than 50 the elapse time can vary from 10 seconds to 40
seconds.
5.3.3. User friendliness
The user interface of the system should be easily usable by non-experts. It means
that the SDMSTM system should reflect as closely as possible to the way nonautomatic meetings are typically managed
5.3.4. Flexibility
Rescheduling of a meeting should be done dynamically.

5.3.5. Extensibility

The meeting scheduler system has the ability to handle explicit dependencies
between meeting date and meeting location. Then again, it manages participation
through delegation.
5.3.6. Security
Privacy rules should be enforced a meeting participant should not be aware of
constraints stated by other meeting participants
5.4 Requirements Traceability

APPENDIX A Outstanding Issues

Issue #
Title
Description

ISSUE-1
Conflicting and Confusing Initial Requirements
The initial requirements specification contains conflicting
requirements, confusing statements, is unorganized, and is
generally unusable as an initial requirements specification.
Contact
Yasaman Haghpanah (system world representative)
Analysis/Alternatives 1) request updated/improved initial requirements
specification, 2) restate the understood requirements into an
operational scenario and improve the scenario as
requirements are found and issues resolved
Disposition
2) Decided to develop an operational scenario as a consensus
document based on the information gleaned from the initial
requirements specification
Contact
The 4 representatives team decision
Issue #
Title
Description

ISSUE-2
Meeting Initiator a Potential Meeting Participant
Is the meeting initiator treated like any other potential
meeting participant or should the meeting initiator be a
confirmed participant when proposing a meeting?
Contact
Sowjanya Sakruti (user world representative)
Analysis/Alternatives Default is yes or no or requires a selection
Disposition
Meeting initiator is a pre-confirmed participant of any
meeting initiated by the meeting initiator
Contact
Jim Whitaker (subject world representative)
Issue #
Title
Description

ISSUE-3
Definition of an important person
What is an important person how is this determined

what effect does it have on the system?

Contact
Ravindra Rudraraju (developer world representative)
Analysis/Alternatives An important person is determined by the meeting initiator
as a person required to be present at the meeting otherwise
the can/should not be held.
Disposition
A meeting shall only be scheduled if all important
participants are available and are willing to attend the
meeting otherwise the meeting should not be held.
Contact
Sowjanya Sakruti (user world representative)
APPENDIX B Preliminary Design (Mockup)

Figure 4 Login Screen

The purpose of this web page is to authenticate the user.

Figure 5 Administrators Page

The purpose of this web page is for maintaining the user profiles by the administrator.

Figure 6 Propose a meeting

When the user wants to propose a meeting he uses the above page. He provides the topic,
agenda, data range and duration of the meeting along with the meeting proposal to
potential meeting participants.

Figure 7 View Schedule

The user can view his schedule for a day or week or month depending on his necessity
using the above page. The priorities of the meetings are shown by color. The user
responds by clicking on particular meeting.

Figure 8 Reply to meeting

This page is displayed when the user clicks on meeting. The user responds either by
clicking will attend button or will not attend button. If the user is attending the
meeting he may request for equipment. If the user is not willing to attend the meeting he
may give a reason for his absence.