TERASOFT DISTRIBUTED
MEETING SCHEDULER SYSTEM
Project Phase 2.2
DR. LAWRENCE CHUNG
CS 6361 – ADVANCED REQUIREMENTS ENGINEERING
UNIVERSITY OF TEXAS AT DALLAS
FALL 2009
System Requirements Specification
Version 2.23
Requirements Engineering Team– The Pioneer
Vinit Patwa ([email protected])
Prasanna Kumar Kumar Thiagarajan ([email protected])
Shiva Sangam ([email protected])
Azharuddin Mohammed ([email protected])
Ritesh Patel ([email protected])
Tarun Chandra Samireddy ([email protected])
Rutvij Desai ([email protected])
Sirisha Balantrapu([email protected])
Shubhada Deshmukh ([email protected])
Preethi Varambally ([email protected])
Swaroop Govindappa ([email protected])
1
“The hardest single part of building a software system is deciding precisely what to
build. No other part of the conceptual work is as difficult as establishing the detail
technical requirements, including the entire interface to people, to machines, and to other
software systems. No part of
the work so cripples the resulting system if done wrong. No other part is more difficult to
rectify later.”
[Brooks, 1987]
Revision History
Version Date
Description
Author
1.00
09/21/09
Title page, Project overview, and
preliminary requirements added
Sirisha
1.01
09/24/09
Updated the previous version
and added all other subpoints
under Introduction
Shubhada
1.02
09/25/09
Updated Preliminary
Requirements – ER, FR, NFR.
Preethi / Swaroop
1.03
09/26/09
WRS (ER,FR,NFR)
Preethi, Swaroop, Ritesh,
Azhar,Shiva, Sirisha
1.04
09/27/09
Added the issues related to
preliminary requirements.
Shubhada, Prasanna Kumar,
1.05
09/28/09
Added problem, goals and
domain and functional
requirements after improved
understanding
shubhada
1.06
09/29/09
Done Proofreading and added
Traceability Matrix
Meghana
1.07
10/15/09
Updated preliminary
requirements, improved
understanding and project flow
diagram
Preethi, Swaroop
1.08
10/18/09
Updated prototype
Azhar, Vinit
1.09
10/20/09
RE process flow , Traceability
Prasanna Kumar, Tarun
2
1.10
10/21/09
Added meeting and
Responsibility Records
Shubhada,Preethi,Swaaroop,
Ritesh,Prasanna Kumar
2.00
10/23/09
Vision document, Glossary, use
case Specfication
Shirisha, Prasanna Kumar,
shiva, Ritesh
2.01
10/30/09
supplementary specification
Shubhada
2.02
11/05/09
stakeholder
Rutvij
2.0.3
11/05/09
Preliminary, Issues, Improved
Understanding
Preethi, Swaroop
2.04
11/05/09
Prototype
Vinit, azhar, tarun, ,shirisha,
Prasanna Kumar
2.1
11/11/09
Merge the Preliminary Doc
Ritesh
2.11
11/13/09
Dressed up use case,
Collaboration, Sequence
Diagram
Sirisha, shiva
2.12
11/17/09
SIG Diagram
Shubhada
2.13
11/19/09
New/Missing Requirements,
Issues
Preethi, Swaroop
2.14
11/20/09
SADT
Shirisha, Prasanna Kumar
2.15
11/25/09
IDEF diagrams
Tarun, Rutvij
2.16
11/25/09
KAOS diagram
Swaroop, Preethi
2.17
11/26/09
Implementation
Azhar, Vinit
2.18
11/26/09
Relationship between Use cases
and Requirements
Sirisha
2.19
11/26/09
Traceability between project 1
and 2
Prasanna Kumar,
Ritesh,Vinit, Azhar
2.20
11/27/09
Test Cases and Traceability
between Test cases and SFR and
SNFR
Prasanna Kumar, Ritesh,
Vinit, Azhar
2.21
11/28/09
Final Project Plan
Prasanna Kumar, Ritesh,
Shiva
2.22
11/30/09
User manual
Azhar , Tarun, Vinit
3
2.23
12/02/09
Final Report
Prasanna Kumar, Ritesh
Meeting Record
NO.
DATE
AGENDA
PARTICIPANTS
1
Aug 29, 2009
Preliminary plan discussed
Prasanna Kumar, Shiva, Tarun,
Azhar, Meghana
2
Sept 1, 2009
Preliminary plan finalised
Shubhada, Vinit, Shirisha, Shiva,
Ritesh, Azhar, Tarun, Meghana
3
Sept 5, 2009
Discussed project1.pdf
document
Ritesh, Shubhada, Meghana,
Prasanna Kumar
4
Sept 10, 2009
work discussed for Phase 1.1
5
Sept 15, 2009
work distributed for Phase 1.1
(issues and requirement teams)
6
Sept 19, 2009
issues discussed
Shubhada, Vinit, Meghana,
Prasanna Kumar
7
Sept 21,2009
Requirements Discussion
Ritesh, Azhar, Shirisha,
Swaroop, Preethi, Shiva
8
Sept 24, 2009
discussed problem, goal and
improved understanding
9
Sept 29, 2009
discussed Phase 1.1
documentation
10
Sept 30, 2009
Discussed presentation details
11
Oct 6, 2009
Discussed presentation details
and practiced presentation
Shubhada, Vinit, Shirisha, Shiva,
Ritesh, Azhar, Tarun,
Meghana, Prasanna Kumar
Shubhada, Vinit, Shirisha, Shiva,
Ritesh, Azhar, Tarun,
Meghana, Prasanna Kumar
Shubhada, Vinit, Shirisha, Shiva,
Ritesh, Azhar, Tarun,
Meghana, Prasanna Kumar,
Shubhada, Shirisha, Shiva,
Ritesh, Azhar, Tarun,
Meghana, Prasanna Kumar,
Rutvij
Swaroop, Preethi, Vinit, sirisha,
Shiva, Ritesh, Azhar,
Tarun, Meghana, Prasanna
Kumar, Rutvij
Swaroop, Preethi, Vinit, Sirisha,
Shiva, Ritesh, Azhar,
Tarun, Meghana, Prasanna
Kumar, Rutvij
4
12
Oct 20, 2009
Discussed about the things done,
and things needed to be done
before submission of phase 1.2
13
Oct 21, 2009
Merging and Reviewing Final
Documents
14
Oct 23,2009
RE process flow , Traceability
Oct 29,2009
Vision document,
Glossary,supplementary
specification
Nov 03,2009
use case, Collaboration,
Sequence Diagram,
stakeholder
17
Nov 10,2009
Prototype, Merge the
Preliminary Doc
18
Nov 13,2009
19
Nov 19,2009
15
16
20
Nov 25,2009
Shubhada, Sirisha, Shiva,
Prsanna, Azhar, Tarun, Preethi,
Swaroop, Ritesh, Rutvij,Vinit
Sirisha, Shiva, Prsanna, Azhar,
Tarun, Preethi, Swaroop, Ritesh,
Rutvij,Vinit
Prsanna, Azhar, Sirisha,Tarun,
Shubhada, Sirisha, Shiva,
Prsanna, Azhar, Tarun, Preethi,
Swaroop, Ritesh, Vinit
Prasanna, Vinit, Azhar, Sirisha,
Ritesh, Shiva
Sirisha, Shiva, Prsanna, Azhar,
Tarun, Preethi, Swaroop, Ritesh,
Vinit
KAOS diagram, SIG Diagram
Shubhada, Sirisha, Shiva,
Prsanna, Azhar, Tarun, Preethi,
Swaroop, Ritesh, Rutvij,Vinit
SADT, IDEF diagrams,
implementation.
Sirisha, Shiva, Prsanna, Azhar,
Tarun, Rutvij,Vinit
Traceability between project 1
and 2 and Test Cases and
Traceability between Test
cases and SFR and SNFR
Prasanna,Ritesh, Ahar, Vinit,
Sirisha, Shiva
Dressed up use case,
Relationship between Use
cases and Requirements
Sirisha, Shiva, Azhar, Prasanna,
Ritesh, Shiva
21
Nov 27,2009
22
Nov 30,2009
Final project plan, user manual
Sirisha, Shiva, Prsanna, Azhar,
Tarun, Preethi, Swaroop, Ritesh,
Vinit
Dec 02,2009
Final report, PPT, Merging of
documentation, testing project,
Editing the project process
specification and final meeting.
Sirisha, Shiva, Prsanna, Azhar,
Tarun, Preethi, Swaroop, Ritesh,
Rutvij,Vinit
22
5
1
Contents
System Requirements Specification ................................................................................................ 1
Requirements Engineering Team– The Pioneer ............................................................................. 1
Revision History ............................................................................................................................. 2
Meeting Record ............................................................................................................................... 4
2
INTRODUCTION.....................................................................................................................10
2.12 Project Overview ................................................................................................................10
2.2 Purpose...............................................................................................................................10
2.3 Scope .................................................................................................................................. 11
2.4 Usablity .............................................................................................................................. 11
2.5
Definitions .......................................................................................................................... 12
2.6 RE PRocess......................................................................................................................... 12
2.6.1 Iterative development ........................................................................................ 13
2.6.2 VAriation of evolutionary iterative model ......................................................... 13
2.7
Stakeholders ....................................................................................................................... 14
2.8 PROJECT FLOW Diagram ................................................................................................. 16
2.9 Roles and Responsiblities .................................................................................................. 17
2.10 Process specification ..........................................................................................................18
2.11 Process Model SADT:.......................................................................................................... 19
2.12 SADT (Actigram) ................................................................................................................ 28
2.13 Datagram ........................................................................................................................... 33
2.14 IDEF ................................................................................................................................... 35
2.15 Level 1 Diagram for Team Process (Phase-1) .................................................................... 36
2.16 Context Diagram for Team Process (Level 0) - Phase 2 .................................................... 37
2.17 Level 1 Diagram for Team Process– Phase 2 ..................................................................... 38
3
PRELIMINARY REQUIREMENTS ........................................................................................ 39
3.1
Preliminary Enterprise requirements: ............................................................................ 39
6
4 ISSUES WITH PRELIMINARY DEFINITION GIVEN (AMBIGUITIES,
INCOMPLETENESS, INCONSISTENCY, CONFLICTS) .............................................................. 46
4.1
Issues with II.1 The Domain, Stakeholders, Functional and Non-Functional
Objectives ................................................................................................................................... 46
4.1.1
Issue- 1 ............................................................................................................ 46
4.1.2
Issue- 2 ........................................................................................................ 46
4.1.3
Issue- 3 ........................................................................................................ 47
4.1.4
Issue- 4 ........................................................................................................ 47
4.1.5
Issue- 5 ........................................................................................................ 48
4.1.6
Issue- 6 ........................................................................................................ 48
4.1.7
Issue- 7 ........................................................................................................ 49
4.2 Issues with II.2 Software System Requirements: Functional Requirements ................... 49
4.2.1
Issue- 1 ........................................................................................................ 49
4.2.2 Issue- 2 ............................................................................................................. 50
4.2.3
Issue- 3 ........................................................................................................ 50
4.2.4
Issue- 4 ......................................................................................................... 51
4.2.5
Issue -5 ......................................................................................................... 51
4.3 Issues with II.3 Software System Non-Functional Requirements ....................................... 51
4.3.1 Issue- 1 ............................................................................................................... 51
4.3.2 ISSUE- 2 ........................................................................................................... 52
4.2.3 Issue- 3............................................................................................................. 52
4.2.4 Issue- 4 ............................................................................................................ 52
4.2.5
Issue- 5 ........................................................................................................ 53
4.2.6
Issue- 6 ........................................................................................................ 54
4.3 Missing and New Requirements: ...................................................................................... 54
5
4.3.1
ENTERPRISE REQUIREMENTS ................................................................. 54
4.3.2
System Functional requirements ................................................................. 54
WRS (World Requirements Specification) ............................................................................. 55
5.1 world/domain PROPERTIES (w)......................................................................................... 55
5.1.1
Problem..................................................................................................... 55
5.1.2
goals ............................................................................................................ 56
5.1.3
Enterprise Functional Requirements ..........................................................57
5.1.4
Enterprise Non-Functional Requirements ................................................. 59
5.2 Requirements and specifications(RS) ............................................................................... 60
7
5.2.1
Functional RS – Improved understanding of II.2 ...................................... 60
5.2.2
Non-functional RS -Improved understanding of II.2 Software System
Requirements: NFRs ................................................................................................. 63
6
NFR Formal specifications ..................................................................................................... 65
6.1
Softgoal Interdependency Graph (SIG) for Product NFR ................................................ 65
6.1.1
Security ........................................................................................................... 67
6.1.2
Performance ................................................................................................ 67
6.2 nfrs Softgoal Interdependency Graph (SIG) for Process NFR .......................................... 69
6.2.1
Usability ...................................................................................................... 69
6.2.2
Reliability .................................................................................................... 69
6.2.3
maintainablity ............................................................................................. 70
6.3 KAOS ................................................................................................................................. 72
7 MODELING ACTIVITIES ......................................................................................................... 73
7.1 System Use Case Diagram ................................................................................................. 73
7.2 Business Use Case Diagram ............................................................................................... 73
7.3 Fully Dressed UseCases: ......................................................................................................75
7.4 sequence diagrams ............................................................................................................... 83
7.5
ACTIVITY DIAGRAM: ...................................................................................................... 89
7.5.1 Schedule Meeting Activity Diagram .................................................................. 91
7.5.2
UML- Activity Diagram: ............................................................................. 92
7.5.3
Business Activity Diagram: ......................................................................... 93
7.6 DOMAIN CLASS DIAGRAM:.............................................................................................. 94
7.7 Fish Bone Diagram:.............................................................................................................. 95
8
TRACEABILITY ...................................................................................................................... 96
8.1
Forward traceability (domain requiRements to functional requirements and
non functional REQUIREMENTS) ............................................................................................ 96
8.2 BACKWaRD TRACEABILITY ........................................................................................... 97
8.3 Screen descriptions ......................................................................................................... 100
8.4 Traceability/dependency Mapping between project–1 & project-2 functional
requirement and implementation ........................................................................................... 100
8.5 Test Plan ...........................................................................................................................103
8
8.6 MAPPING FROM TESTCASES TO SFR AND NSFR .......................................................105
9
WHY OUR PROJECT IS BETTER THAN OTHERS.............................................................. 107
10
CHANGEABILITY ........................................................................................................... 108
11
REFERENCES ..................................................................................................................... 108
9
2 INTRODUCTION
2.12 PROJECT OVERVIEW
Scheduling Meetings was done manually once upon a time when offices were not
automated. This was a tough and time consuming job as everything was done
manually (e.g. typing agendas, writing meetings etc).
The project includes creating a TeraSoft Distributed Meeting scheduler, a facility
for scheduling meetings which has many potential applications, scheduling
courses and flights, room assignments at hospitals and hotels courses, flights,
scheduling national and international meetings as well as scheduling virtual
meetings. This particular type of system is intended for supporting people to
schedule their meetings.
Scheduling meetings is one of the most important tasks in the modern workplace.
Task of scheduling a meeting manually is definitely not easy. It takes lots of
efforts and planning to fix up a date which is convenient to most of the members
in the team if not all. With the advent of computer technologies the task of setting
up meetings has become a little easy than before. As companies continue to grow,
they tend to seek for better software that will help them improve their current
scheduling system and increase productivity within their organization.
Scheduling a meeting really is not as simple as it looks, even with scheduling
software. A lot of judgment is involved, and there's a real sense of propriety
required. In bringing any group of people together, there are so many factors to
take into account. It could be that there's a certain pecking order, and some
people have to work around more important people's schedules. Or, some people
can best be contacted by phone, some by e-mail, or some through a third party
such as a secretary or administrative assistant. Decisions about where the
meeting is held are important as well, and very political. For some meetings, a
simple announcement will do. For others, participants will need to be polled for
their availability and then confirmed later.
2.2
PURPOSE
The purpose of this document is to record the process of requirement elicitation
for TeraSoft distributed meeting scheduler. This document specifies the domain,
functional and nonfunctional requirements. It is intended to be used as reference
document in TeraSoft distributed meeting scheduler software lifecycle.
10
Requirement elicitation is a very important activity in a project’s life cycle. After
reviewing the preliminary requirements the problem is defined and multiple
solutions are proposed to solve the problem. The goals are set to resolve the
problem and according to set goals the solution is chosen.
2.3
SCOPE
The scope of the system will include

Scheduling the meeting.

Gathering the responses from attendee.

Confirming the location and time of the meeting.

Canceling the meeting.

Changing the meeting schedule and/or location.

Scheduling concurrent meetings.

Conducting virtual meetings.
2.4
USABLITY

Automate the process of meeting scheduling to save the time and
efforts of meeting organizer.

Select a date and time such that all the active and important
participants can participate.

Allocate the convenient location to maximize attendance.

Send the reminders about the meeting to participants.

Change and reschedule meeting in a situation when it is needed to
do so.

Manage the virtual meetings. Provide audio video interface to
remote
attendees.
11
2.5
DEFINITIONS
Meeting organizer - A person who is responsible for managing meetings
Meeting Initiator -One who arranges the meeting
Exclusion Set - Set of dates on which participants can not attend meeting
Preference Set
-Set of dates on which participants prefer to attend
meeting
Date Conflict - It occurs when no date can be suitable for meeting.
Date Range -The time between start date and end date including start and end
date.
Duration -The meeting time period in hours and minutes.
Active Participants -Participants who are going to do the presentations in the
meeting
Important Participants – Must be there participants. Without them the meeting
can not be conducted.
Regular Participants- All the other participants who are not designated as Active or Important Partic
Location - Physical location of the meeting room.
Required equipment -Equipments such as microphone, projector, blackboard, and stationary neede
Virtual meeting -Meeting held by teleconferencing.
2.6
RE 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.
12
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.
2.6.1 ITERATIVE DEVELOPMENT
Iterative development slices the deliverable business value (system functionality)
into iterations. In each iteration a slice of functionality is delivered through crossdiscipline work, starting from the model/requirements through to the
testing/deployment. The unified process groups iterations into phases: inception,
elaboration, construction, and transition
2.6.2 VARIATION OF EVOLUTIONARY ITERATIVE MODEL
A requirement process may include the involvement of human, social, and
organizational factors. The Role Actor Diagram (RAD) illustrated in Figure 1 below was
used to identify the important stakeholders associated with the development of a
product, which include:
13
Evolutionary Iterative Model:
RE Process:
2.7
STAKEHOLDERS
In regard to our project we identified the following stakeholders:





User – Meeting Scheduler/Initiator, Participants
Customer –Terasoft Inc
Requirements Engineer
Development Team
Testing and Maintenance Team
Role Description

Initiator/Meeting Scheduler: Responsible for initiating the meeting,
setting the date range ,inviting participants and resolving conflicts among
various factors like time, space etc .

Participant: Responsible for giving the preference and exclusion date
ranges, location and resource requirements and attending the meeting

Requirements Engineer: Responsible for eliciting, specifying and
validating
requirements
and
also
developing
the
requirements
specification document

Developer: Responsible for making the design prototype operational.
14

Testing and Maintenance Team: Ensures that the developed
application always conforms to the requirements specified.
Requirement
Analysis
Requirements Engineer
Deal with
Requirements
Issues
Document
preparation
Team Leader
Manage
Lifecycle
Activities
End User
Software Engineer
Designer
Process/Product
Specification
Modeling
Diagrams
Programmer
Prototype
development
Performs Part of functions
Performed by
Involved in that activity
Performs the Activity
Activity
15
2.8
PROJECT FLOW DIAGRAM
16
2.9
ROLES AND RESPONSIBLITIES
Team Members
Rutvij , Preethi, Ritesh
Role
User World
Sirisha, Meghana, Shubhada
System World
Swaroop, Shiva, Prasanna Kumar
Subject World
Vinit, Tarun, Azharuddin
Developer World
17
2.10 PROCESS SPECIFICATION
Process Model:
18
SADT (Structured Analysis and Design Technique) is a Software Engineering technique
for describing systems as a hierarchy of functions. SADT uses arrows to build these
diagrams.
The SADT Diagrams or the Process are shown below:
2.11 PROCESS MODEL SADT:
Level- 0 :
19
Top Level Diagram
UML
Specification
s
SADT
Specification
s
Requiremen
ts validation
Software
Requirements
Specification
Preliminar
y
Document
Process
Requirements
Process
Specification
A0
Requirements Engineer
20
Detailed Top Level Diagram
Requirements
Validation
UML and SADT
specifications
SIG
specifications
Dependency
Preliminary
Document
Diagrams
Stage 1
1
Functional
Requirement
s
Stage 2
Specification
SRS
2
Stage 3
Process
Specifications
3
A0
Requirements Engineer
21
Level- 1 :
22
23
24
25
26
Existing Models
Refined and Other
Diagrams
Building The
prototype
Prototype
A061
Final Prototype
Evaluating the
Prototype
A062
A06
Requirement
Engineer
SW Engineer
Domain
Expert
End
User
27
2.12 SADT (ACTIGRAM)
The Semantics of Arrows
For Actigrams:




Inputs are data that are consumed by the activity.
Outputs are produced by the activity.
Controls influence the execution of an activity but are not consumed.
Mechanism actual make the activity happen.
Exsiting systems
Inputs to SDMS
Modeling the
product of SDMS
A0
Final Schedule or
decision
Software system
participants
Initiator
28
Admin
Inputs
Data Range
Meeting Initiation
Participants list
Location
Preferences
A1
Date Range,
Location
Final Proposed
or Discussion
ES, PS,
Location
Preferences
Scheduling
A2
No Proposed
Date
Conflict
Resolution
A3
A0
Initiator
Software
System
Participants
29
Date Range
Decide on date Range,
Participants and Location,
by Initiator
Available Locations
Participants
Participants List
A11
Send invites to participants
Date range location
A12
A12
A1
Initiator
Software System
30
Receive Responses
Date Range
Location
A21
ES, PS, Location,
Equipement
Proposed Schedule
Calculate
Schedule
ES, PS , Location
Equipement
A22
No Proposed
Date
A2
Participants
Software System
31
Inform about Conflicts
and Get User Response
No Proposed
Date
A31
Update ES and PS
A32
Final
Proposal
Calculate Schedule
A33
Resolve Manualy
Not Resolved
A34
A3
A3
Software
System
Participants
Admin
32
2.13 DATAGRAM
The Semantics of Arrows
For Datagrams:




Inputs are activities that produce the data.
Outputs consume the data.
Controls influence the internal state of the data.
Mechanism is the Storage Device.
SYSTEM
Initiation
PARTICIPANTS
ADMIN
INFORMING USERS
SCHEDULE
D0
33
Participants
Initiator
Date Range,
Participants,
Location
Preferences
Initiation
Admin
System
Taking
Responses
D1
ES, PS,
Location
Preferences,
Equipment
D2
Scheduling
Process
Proposed
Date/ Conflict
Inform
participants
D3
Resolve Conflict
New ES, PS,
Location
Prefernces,
Equipment,
Date Range
D4
Scheduling
Process
Final Date or
Result of
Conflict
D5
D0
Repository Disk
34
2.14 IDEF
Context diagram for Team Process (level 0) – Phase -1
35
2.15 LEVEL 1 DIAGRAM FOR TEAM PROCESS (PHASE-1)
Customer
Expectations
Customer
Requirements
Documentation
Understanding
customer
requirements
Needs
Establish
Requirements
A1
Requirements
Contract for Trade-off decisions
Alternate
Technologies
Design System
Knowledge of previous design
as in OOAD UML
A2
Design
Product
Build System
Mock-up
Template patterns of previous design
A3
UC-Spec
36
2.16 CONTEXT DIAGRAM FOR TEAM PROCESS (LEVEL 0) - PHASE 2
37
2.17 LEVEL 1 DIAGRAM FOR TEAM PROCESS– PHASE 2
38
3 PRELIMINARY REQUIREMENTS
3.1
PRELIMINARY ENTERPRISE REQUIREMENTS:
EFR-1
A “meeting initiator” shall initiate a meeting.
EFR-2
The meeting initiator is one of the participants and it means that any participants
can be a meeting initiator.
EFR-3
The Proposed meeting date should belong to the stated date range and not to any
of the exclusion sets.
EFR-4
Proposed meeting date should fall in as many preference set as possible.
EFR-4
Meeting initiator will ask all potential meeting attendees for set of dates they
cannot attend the meeting (exclusion sets) and the set of dates they would prefer
the meeting to
take place.(preference sets)
EFR-5
The exclusion and preferences sets should be contained in some time interval
prescribed by the meeting initiator.
EFR-6
A meeting room should be available at the selected meeting date.
EFR-7
The initiator must ask all the attendees to provide any special equipment
requirements.
EFR-8
A meeting room should meet the equipment requirement
EFR-9
A new round of negotiations may be required when no room can be found. The
number of negotiations should be kept minimal.
Initiator may ask the attendees to state preferences about the meeting location
EFR-10
EFR-11
Meeting location should ideally belong to one of the locations preferred by as
many important participants as possible.
EFR-12
Meeting place can be virtual through Teleconferencing, Video conferencing
using laptop computers, or can be Real locations.
EFR-13
A virtual Meeting location is chosen when none of the real locations are
convenient to all the attendees.
39
EFR-14
Meeting date shall be defined by a pair (Calendar date , time and period)
EFR-15
Every meeting has its own priority in terms of internal company’s standard.
EFR-16
Several meetings might be initiated concurrently. If the conflicts (time and
location) take place, it should be resolved based on the meeting priority. If the
two conflicting meetings’ priorities are the same, the meeting that is initiated
later should be canceled
EFR-17
A date conflict occurs when no meeting date belonging to the preference sets of
the attendees can be found within the date range.
EFR -18
Date conflict should be resolved with least possible interactions.
EFR-18
Date conflict is strong when it is not in date range and outside exclusion sets
EFR-19
A date conflict is weak when it is in date range and outside exclusion sets
EFR-20
The Initiator extends the data range to resolve conflict.
EFR-21
EFR-22
Some participants remove some dates from their exclusion set to resolve
conflicts.
Some participants’ withdraw from meeting to resolve conflicts.
EFR-23
Some participants add new dates to their preference sets.
EFR-24
If the meeting is canceled, it could be re-scheduled later.
40
Resolve a Date Conflict
EFR-16
Meeting priority
Meeting date shall be a pair
<<extend>>
EFR-20
EFR-15
Extends the Date range
Reschedule the meeting on cancellation
EFR-14
Set up a meeting date
Initiate a meeting
EFR-24
EFR-1
EFR-20
Negotiations when no room is found
EFR-9
Initiator can be a participant too
EFR-2
Meeting Initiator
EFR-6
EFR-3
EFR-18 EFR-19
Set up a date range
EFR-12
Meeting location can be virtual or real
<<include>> EFR-5
EFR-18 EFR-19
Provide Exclusion sets and Preference sets
<<extend>>
EFR-21
<<include>>
EFR-11
EFR-8
State preferences for the meeting location
EFR-10
Remove dates from Exclusion sets
Meeting room should be available
Set up a meeting location
Provide special equipment requirements
EFR-7
EFR-4
EFR-21
<<extend>>
EFR-23
Add new dates to the preference sets
<<extend>>
EFR-22
EFR-23
Meeting Attendees
EFR-22
Withdraw from meetings
Figure 3.1 : Enterprise Functional Requirements
41
3.2 PRILIMINARY FUNCTIONAL REQUIREMENTS
SFR-1
The system should monitor meetings especially when they are held in a
distributed manner.
SFR-2
System shall provide function that enables initiator to send out the meeting
information to all of the potential meeting attendees.
SFR-3
The system should provide functionality for the meeting attendees to select their
exclusion set.
SFR-4
The system should provide functionality for the meeting attendees to select their
preference set.
SFR-5
The system shall make the exclusion and preference sets contained in some time
interval prescribed by the meeting initiator (hereafter referred to as date range)
SFR-6
The system shall provide functionality for the attendees to notify the initiator of
any special equipment requirements (e.g., overhead projector, workstation,
network connection, telephone, etc.)
SFR-7
The system shall provide functionality for the attendees to state their preferences
about the meeting location to the initiator.
SFR-8
The system shall make the proposed meeting date belong to the preference set
and the final decision is based on the meeting initiator.
SFR-9
The system shall make the proposed meeting date ideally belong to as many
preference sets as possible.
SFR-10
The system shall provide functionality to check for a date conflict.
SFR-11
The system shall notify all participants of a strong conflict when no date can be
found within the date range and outside all exclusion sets.
SFR-12
The system shall notify all participants of a weak conflict when date can be
found within the date range and outside all exclusion sets, but no date can be
found at the intersection of all preference sets.
SFR-13
The system shall provide functionality for the initiator to extend the date range to
facilitate conflict resolution.
42
SFR-14
The system shall provide functionality for the attendees to remove some dates
from their exclusion sets to facilitate conflict resolution.
SFR-15
The system shall provide functionality for the attendees to withdraw from the
meeting to facilitate conflict resolution.
SFR-16
The system shall provide functionality for the attendees to add new dates into
their preference sets to facilitate conflict resolution.
SFR-17
The system shall provide functionality to check the availability of a meeting
location.
SFR-18
The system shall provide options for the meeting initiator to select a real or a
virtual meeting location.
SFR-19
The system shall handle the negotiation to decide the meeting location.
SFR-20
The system shall provide functionality to hold meetings according to the
constraints expressed by participants.
SFR-21
The system shall provide functionality to re-plan a meeting if the exclusion set,
preference set and/or preferred location is modified before a meeting
date/location is proposed.
The system shall provide functionality to re-plan a meeting if some external
constraints need to be taken into account after a date and location have been
proposed.
The system shall notify all participants after the meeting initiator inserts the final
decision (about meeting date and location) in the system.
The system shall manage all the interactions among participants required during
the organization of the meeting
SFR-22
SFR-23
SFR-24
43
System
Schedule and plan meetings
Monitor meetings
Conflict resolution
SFR-2
SFR-1
SFR-10
SFR-3
SFR-11
SFR-4
SFR-12
SFR-5
SFR-13
SFR-6
SFR-14
SFR-7
SFR-8
Re-plan meetings
SFR-21
Manage interactions
SFR-24
SFR-22
SFR-23
SFR-15
SFR-16
SFR-9
SFR-17
SFR-18
SFR-19
SFR-20
Figure 3.2 : System Functional Requirements
3.3 PRILIMINARY NON-FUNCTIONAL REQIREMENTS
SNFR1
A meeting should be accurately monitored, especially when it is held in a virtual
place.
SNFR2
Re-planning of a meeting should be done as dynamically and with as much
flexibility as possible.
SNFR3
The amount of interaction among participants(e.g., number and length of
messages, amount of negotiation required) should be kept minimal.
44
SNFR4
The intended system should considerably reduce the amount of overhead usually
incurred in organizing meetings where potential attendees are distributed over
many different places and communicate with each other, for example, via
Internet.
SNFR5
The system should reflect as closely as possible the way meetings are typically
managed (see the domain theory above).
SNFR6
The meeting date and location should be as convenient as possible, and available
as early as possible, to all (potential) participants
SNFR7
The system should accommodate as much decentralized requests as possible; any
authorized user should be able to request a meeting independently of her
whereabouts
SNFR8
Physical constraints shall be maintained Eg., 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.
SNFR9
The system shall handle appropriate number of concurrent users.
SNFR10
The system shall have an appropriate level of performance.
SNFR11
The system shall be easily usable by non-experts.
SNFR12
The system shall be configurable. E.g.: The rules for conflict resolution may
change and the system should be able to handle this change.
SNFR13
The system should be scalable. i.e it should be able to accommodate additional
functionalities.
SNFR14
The system shall be customizable to professional as well as private meetings
SNFR15
The system should be easily extensible to accommodate variations.
SNFR16
The system should be accessible only by authorized users only.
SNFR17
The system should be easily maintainable
SNFR18
The attendees should be able to use the system regardless their location.
SNFR19
The system should have a good user interface.
SNFR20
The system should be reliable.
45
4 ISSUES WITH PRELIMINARY DEFINITION GIVEN
(AMBIGUITIES, INCOMPLETENESS, INCONSISTENCY,
CONFLICTS)
4.1
ISSUES WITH II.1 THE DOMAIN, STAKEHOLDERS, FUNCTIONAL
AND NON-FUNCTIONAL OBJECTIVES
4.1.1
ISSUE- 1
Requirement – “The initiator could also ask, in a friendly manner, active
participants to provide any special equipment requirements on the meeting location”
Description – The requirement is ambiguous. There is no assertive proposal
made by the initiator so this could also mean that the initiator will ask about the
equipment requirements at the meeting location instead of asking about the
requirements at the time of sending out the request.
Option1:
Rephrase the sentence such that it clearly conveys what it is exactly supposed to
mean.
Decision and rationale :
The initiator shall ask active participants to provide any special equipment
requirements on the meeting location prior to the meeting date.
4.1.2 ISSUE- 2
Requirement – The initiator may ask important participants to state preference
about the meeting location
Description - The requirement is ambiguous. The requirement doesn’t specify
the case of preference confliction among important participants.
Option 1: The system shall give more priority to the important participants who
submit the location preference earlier.
Option 2: The decision is solely based on the meeting initiator.
Decision and Rationale: The solution would be option 2 because it specifies the
case of preference confliction among important participants in more detail.
46
4.1.3 ISSUE- 3
Requirement – The meaning of the terms ” potential attendees”, “active
participants”, “important participants” is not specified
Description - The requirement is ambiguous. The potential attendees can be
important or active participants for other meeting. Similarly they can be active and
important participants.
Decision and Rationale: The meeting initiator should have the responsibility of
specifying the role for each of the participants (potential, active and important) for
the meeting.
4.1.4 ISSUE- 4
Requirement – “Conflicts can be resolved in several ways”
Description: This requirement is unclear or ambiguous in the context “several”.
It doesn’t define the regular or the necessary ways in which the conflicts could be
resolved.
The requirement doesn’t specify which method should be given more preference in
resolving the conflict.
Option 1: This conflict can be solved when the initiator extends the date range in
case of a date conflict
Option 2: Some participants remove dates from the exclusion sets
Option 3: Some participants withdraw from the meeting
Option 4: New dates are added to the preference set
Option 5: Meetings are prioritized according to their importance
Option 6: Preference is given to ‘important’ participants
Option 7: In an urgent situation, a meeting is postponed to accommodate a high
priority meeting
Decision and Rationale: WE think that option 1 to be more appropriate because
the context in which “conflicts “ is used is the DATE conflict. Extending the date
range minimizes the date conflicts (by minimizing the exclusion sets) .
47
4.1.5 ISSUE- 5
Requirement – “It should ideally belong to one of the locations preferred by as
many important participants as possible”
Description: The requirement is ambiguous in the context “ideal”. It does not
mention or hint the exact idea or the context in which this used.
Options 1: The meeting location here can be ideal in the sense that the place of
meeting is commutable or easy to reach or a virtual place (in case) by all or most of
the important participants.
Options 2: The meeting location here can be ideal in the sense that the location is a
place of interest to most of the important participants.
Options 3: The meeting location here can be ideal in the context that the meeting
location satisfies all the meeting equipment requirements i.e, the conference rooms ,
the technical support , the boarding.
Decision and Rationale: We choose option 1 to be more appropriate because it
will provide the option of holding the meeting at a location feasible or reachable by
all or most of the important participants. This option also supports time constraints
that may hinder the participation of most of the important members.( In case where
there has to be an agreement made and all the members need to be present
physically).
4.1.6 ISSUE- 6
Requirement – Some participants withdraw from the meeting.
Description - The requirement is incomplete or does not specify whether the
participants are potential, active or important participants. It could specify the case
that active or important participants withdraw from the meeting.
Option1: If this is the case, the meeting is cancelled.
Option2: If this is the case, the meeting date is rescheduled to the next available
preference date on which every participant is available. And all participants receive
e-mails about the reschedule via e-mail.
Option 3: If this is the case, the system shall give the initiator a choice if he/she
wants to cancel or continue to have the meeting.
Decision and Rationale: The solution would be Option2 because it’s more
specific how participants withdraw and what its result is.
48
4.1.7 ISSUE- 7
Requirement – The SDMS system needs to include cancellation process.
Who will be given the permission to cancel the meeting?
Description: The requirement is incomplete as it states the need to include the
cancellation process. It is ambiguous because the phrase “needs to” doesn’t clearly
states the necessity of cancellation process in the Initial requirement plan. The
authorization of the person who cancels the meeting is not mentioned . The
cancellation process is not included in the initial requirement plan but this feature
can be included in the system .
Case-I:
The meeting initiator(important or active only) can cancel the meeting
Options 1: The scheduled meeting leads to cancellation when most of the
important members fail to attend the meeting on the scheduled date and update the
details before the scheduled time and date. There should be constraint on the time
before which final updates need to be sent by all the important members or active
members. Based on the final updates the meeting initiator can cancel the meeting
depending on the number of attendees and the priority of the attendees.
Option 2: The meeting leads to cancellation when most of the important members
fail to attend the meeting and inform the changes to the directory.
Case II:
An active participant cancels the meeting .
Option 1:An active participant is both active and important . Therefore, the active
participants reserve the power to cancel the scheduled meeting.
4.2
ISSUES WITH II.2 SOFTWARE SYSTEM REQUIREMENTS:
FUNCTIONAL REQUIREMENTS
4.2.1
ISSUE- 1
Requirement – Meeting requests can be competing when they overlap in time or
space.
Description - This requirement is incomplete. It does not specify what the
system should do when two different meetings are initiated by different initiators
at the same time and/or at same location.
49
Option 1 - The meeting which is initiated first by the initiator will be held
Option 2 - Depending upon the rank or position of initiator preference will be
given
Option 3 - System will select the meeting to be held by random selection.
Decision and rationale – We think option 1 is more appropriate because it will
be conflicting if the rank is same. Also if system randomly selects the meeting then
it might result in to cancellation of previously well planned meeting so option 1 will
schedule meeting on First Come First Serve basis which will result in to least
modifications regarding scheduling meeting.
4.2.2 ISSUE- 2
Requirement – In all cases some bound on re-planning should be set up.
Description - This requirement is incomplete. It does not specify what the
system should do when it needs to re-plan the meeting.
Option 1 – Send a message to initiator to re initialize meeting with new dates.
Option 2 – Send the other acceptable dates for meeting to initiator depending on
the already done voting. If no such date is available then send a message to
initiator to re initialize the meeting.
Option 3 - System will select the meeting to be held by random selection.
Decision and rationale – We think option 2 to be more appropriate because it
will make rescheduling process faster if there are any acceptable meeting dates
available. Also it will start the process of scheduling immediately after cancellation.
4.2.3 ISSUE- 3
Requirement – the original meeting date or location may need to be changed;
sometimes the meeting may even be cancelled.
Description - This requirement is incomplete. It does not specify who is going
to cancel or reschedule the meeting.
Option 1 – The initiator or active participant can reschedule or cancel the
meeting.
Option 2 – The TeraSoft Meeting scheduling system can cancel or reschedule the
meeting depending on participant response changes or conflicts with other more
important meeting.
Decision and rationale – We think option 1 and 2 both are appropriate.
Giving authority of cancellation or rescheduling to initiator or active participants
makes system more flexible. It also prevents any unauthorized changes to meeting
schedule by anybody else.
Allowing system to cancel and reschedule meeting saves time overhead needed for
manual
rescheduling
of
meeting.
50
4.2.4 ISSUE- 4
Requirement - The meeting location should be as convenient as possible for attendees
who are involved in more than one meeting.
Description – This requirement is incomplete. It does not specify what convenient
location means.
Option 1: Location at which maximum number of participants of meetings that are held as
chunk can attend.
Option 2: Location at which 100% of participants who are attending more than one
meeting of a chunk can attend.
Option 3: Location at which 100% of the participants who are attending more than one
meeting of a chunk can attend and 70% of regular participants can attend.
Decision and rationale:- Options 3 is a better one cause people who are attending more
the none meeting in a chunk can benefit. More over if a participant is attending more than
one meeting he can be considered as a important attendee.
4.2.5 ISSUE -5
Requirement - Attendees of chunk meetings qualify for partial attendance.
Description- This requirement is incomplete. There may be a situation where person who
has partial attendance may be needed at two meetings at the same time.
Option 1: This requirement can be extended to mention which part of the meeting the
partial attendee is going to attend.
Decision and rationale: - When accepting the meeting request the attendee with partial
attendance has to mention when part of the meeting he/she is going to attend.
4.3 ISSUES WITH II.3 SOFTWARE SYSTEM NON-FUNCTIONAL
REQUIREMENTS
4.3.1 ISSUE- 1
Requirement – Meeting date should be as convenient as possible.
Description - This requirement is incomplete. It does not specify what the
“convenient date” means.
Option 1 - Date on which maximum number of participants can attend.
Option 2 - Date on which 100% of important members can attend.
Option 3 - Date on which 100% of important members and 70% of regular
members can attend
Decision and rationale – We think option 3 to be more appropriate because it
will ensure that all the important participants and active participants will be
attending the meeting. Also if system selects one of remaining two options then
51
there is a chance that important participants will not be there for the meeting or
nobody other than important participants will be attending the meeting.
4.3.2 ISSUE- 2
Requirement – Meeting should be accurately monitored.
Description - This requirement is incomplete. It does not specify what the
system should monitor and how should it monitor exactly. Is it the proceedings of
the meeting or the presence of participants or anything else?
Option 1 – Interaction among the initiator and participants is taken care of.
Option 2 - The presence of important participants is taken care of.
Option 3 – Remove the requirement..
Decision and rationale – We think option 2 is more appropriate because it
will be important characteristics of meeting to be made sure because as per our
assumption the meeting will get cancelled if important participants can not attend
or cancel the meeting.
4.2.3 ISSUE- 3
Requirement – The system should accommodate as much decentralized requests
as possible. In other words user should be able to initiate the meeting independent
of his/her whereabouts.
Description - This requirement is ambiguous. It does not exactly specify what
kinds of requests system should handle.
Option 1 – Requests to initiate the meeting can be sent by email, IM, SMS, or
phone.
Option 2 – Initiator can login to the website and initiate the meeting.
Decision and rationale – We think option 2 to be more appropriate because it
will provide an option of initiating meeting from any palace where user has access
to the web. The growing number of web enabled devices will make this option real
location independent.
4.2.4 ISSUE- 4
Requirement – The system should be flexible enough to accommodate evolving
data
- e.g., the sets of concerned participants may be varying; the address at which a
participant can be reached may be varying, etc.
Description - This requirement is incomplete. It does not specify in what
manner the sets of concerned participants may vary. It can mean several different
situations.
52
Case I
1- contact information of participant changes 2 – Ranking of participant changes
regular participant can become important participant.
Option 1 – The contact information – phone, email and ranking of participant is
saved in a database and used for all meeting scheduling related activities. The
participant or administrator can change this information.
Option 2 – The participant sends the request to initiator to use new contact
information for further communication.
Decision and rationale – We think option 1 to be more appropriate because it
allows changes in participant’s information and it satisfies previously stated
requirement of minimization of interaction.
Case II
More participants are needed to be added or removed from participant sets after
the meeting is initialized.
Option 1 – Initiator can add or remove more participants any time.
Option 2 – Initiator and important participants can add more participants but
only initiator can remove the participants.
Option 3 – Cannot change the participant set once meeting is initialized.
Decision and rationale – We think option 2 is more appropriate as it provides
flexibility of managing set of participants. It also satisfies the previously stated
requirement of minimization of interaction.
4.2.5
ISSUE- 5
Requirement – Amount of interaction among participants should be kept
minimal.
Description - This requirement is ambiguous. It does not specify what type of
interaction is reduced. It can be number of times interaction between initiator and
participants occur or length of e-mail messages or number of minutes they talk
over phone. Also ‘minimal’ word is vague as it does not set any upper bound on the
interaction.
Option 1 – Phone interaction among the initiator and participants is maximum 10
minutes.
Option 2 – Length of email messages exchanged will be less than 50 words.
Option 3 – Remove the requirement.
Decision and rationale – We think option 3 is more appropriate because
option 1 and 2 are out of the scope of our project and here we will prefer to use
software system to schedule the meeting rather than e-mail and phone
conversations.
53
4.2.6
ISSUE- 6
Requirement – The system should considerably reduce the amount of overhead.
Description - This requirement is ambiguous. It does not specify what overhead
is reduced. It can be in terms of cost or time the participant need to spend to reach
at meeting location. Also ‘considerably’ word does not give much information.
Option 1 – The meeting will be held at location which is preferred by most of the
participants that will reduce the time they need to reach the meeting location.
Option 2 – Initiator decides location by his preference
Decision and rationale – We think option 1 is more appropriate because it will
reduce the transportation time. The initiator can select the location which is
preferred by most of the participants.
4.3
MISSING AND NEW REQUIREMENTS:
4.3.1
ENTERPRISE REQUIREMENTS
1. Meetings can belong to a special category that can be held in chunks.
2. These meetings can be scheduled at the same time.
3. Attendees of chunk meetings qualify for partial attendance. (i.e. they can
participate in multiple meetings in the chunk partially).
4. The meeting locations for the meetings that are held in chunks should be as
convenient as possible for attendees who are involved in more than one meeting.
5. When the probable attendees receive the meeting request they have the following
choices to make Accept, accept as tentative, or decline the meeting request. Some
participants can propose a new meeting timing
6. The meeting initiator can send a meeting request update after he has made
changes to the meeting he is initiating.
7. The initiator can cancel a meeting request and delete it form the calendar. Then
notify all the participants about the cancellation.
8. Some meetings can be recurring in nature. Which are held periodically.
9. Cancelling a recurring meeting request must be done in such a way that past
meetings should remain in the calendar only the future meetings should be deleted.
This can be done by sending a meeting update with a new end date.
4.3.2
SYSTEM FUNCTIONAL REQUIREMENTS
1. System should provide functionality to organize meetings that are held at the same
time as chunks.
2. Meeting that belong to a chunk can be held at the same time
54
3. System should provide functionality that will allow partial attendance.
4. The system should provide functionality to suggest convenient location for meetings
that are held in chunk.
5. On receiving meeting request the probable participants can opt to Accept, accept as
tentative, or decline the meeting request.
6. System should provide functionality to update a meeting.
7. System should provide functionality to schedule recurring meetings.
5
WRS (World Requirements Specification)
Requirement Specification is a document which describes the Enterprise, functional,
nonfunctional requirements for the TeraSoft Distributed Meeting Scheduler system
that is planned for product development in the near future. It tells what is expected
from the system and how the system should behave under certain conditions. The
Requirement Specification Document is not just a list of requirements; moreover, it
helps the project stakeholders reach an agreement on the functionalities of the
system and the conditions to which it must conform.
5.1 WORLD/DOMAIN PROPERTIES (W)
5.1.1
PROBLEM
Scheduling a meeting is an intractable task. As the number to entities increase the
complexity scheduling process increases exponentially. If a meeting is needed to be
scheduled then someone has to send the invitation by physical mail, email, phone etc
to expected participants. After that they have to keep track of who is coming, who is
not coming. What are the convenient days, times, locations for the participants?
Someone has to manually schedule a meeting and monitor it. The organizer has to
collect the responses from participants, and analyze those responses depending on
that analysis he has to make choices regarding several things. Consider these
scenarioso If the meeting gets scheduled on a day when the active participant cannot
join. All the other participants will show up but meeting will get canceled.
o The meeting needed to be rescheduled then organizer has to get in touch with
all the participants and collect the information again.
o The reminder of meeting is needed to be sent, then the meeting organizer has
to keep the contact information of all the participants on file. He has to take
efforts to contact them
55
TeraSoft Distributed Meeting Scheduler system wants to schedule meeting for its
users. It shall allow any user who can login into the system to initiate a meeting and
invite anyone who has an email id. It should make sure that all the active and
important participants will be able to attend the meeting and the location of the
meeting is convenient for them. The system shall handle scheduling meetings
concurrently with respect to time and location. It will manage the remote meeting
held by teleconferencing.
5.1.2
GOALS
GO-1.
The user should be able to initiate a new meeting and invite the
participants to join the meeting.
GO-2.
The location should be convenient to active and important participants.
GO-3.
The needed equipments for meeting should be available at meeting place.
GO-4.
The meeting should be rescheduled if the participation of active or
important participants is not 100%.
GO-5.
The initiator should be able to cancel meeting.
GO-6.
The initiator should be able to reschedule a meeting.
GO-7.
The initiator, active participants and important participants should be
able to invite more participants.
GO-8.
Two or more meeting requests for same location or same timeslot should
be handled by system
GO-9.
The participants should be able to attend meeting remotely.
56
GO-10. The important meeting should be given preference while scheduling
meetings.
5.1.3
EFR-1
ENTERPRISE FUNCTIONAL REQUIREMENTS
A “meeting initiator” shall initiate a meeting by selecting a “date
range” and “location” for the meeting.(traces to preliminary requirement
EFR-7 and 3.1.2 issue 2)
EFR-2
The Proposed meeting date should belong to the stated date range and to
none of the exclusion sets
EFR-3
A meeting room must be available at the selected meeting date and time.
(traces to SFR-6)
EFR-4
A meeting room should meet the equipment requirement.
(traces to SFR-7)
EFR-5
Meeting place will be virtual or Real location.
EFR-6
Meeting date should be defined by Calendar date , time and period.
57
EFR-7
All the important participants should be able to attend the meeting.
EFR-8
The participants should be able to change their responses at any time
before the meeting date.
EFR-9
The time confusion due to different time zones shall be solved by the
system.
EFR-10
The meeting initiator can be one of the participants or some
representative.
EFR-12
A date conflict occurs when no date can be found that belongs to all the
preference sets.
EFR-13
A date conflict is strong when no date can be found within the date range
and outside all exclusion sets.
EFR-14
A date conflict is weak when dates can be found within the date range and
outside all exclusion sets, but no date can be found at the intersection of
all preference sets.
EFR-15
The date conflict should be solved by extending the date range by the
initiator. (traces to preliminary EFR-8)
EFR-16
The date conflict should be solved by some attendees adding some new
dates into their preference sets.
EFR-17
The date conflict should be solved by some attendees removing some
dates from their exclusion sets.
58
EFR-18
The date conflict should be solved by some attendees withdrawing from
the meeting.
EFR-19
The number of negotiations shall be within the maximum number of
negotiations needed to resolve a conflict.
EFR-20
Meetings can be scheduled and held at same time in chunk.
The system should allow partial attendance.
EFR 21
EFR22
When the probable attendees receive the meeting request they have the
following choices to make Accept, accept as tentative, or decline the meeting
request. Some participants can propose a new meeting timing
EFR 23
The meeting initiator can send a meeting request update after he has made
changes to the meeting he is initiating.
EFR 24
Initiator can cancel a meeting , delete the entry from calendar and send
notification to the attendees.
EFR 25
Initiator can schedule a recurring meeting
5.1.4
ENTERPRISE NON-FUNCTIONAL REQUIREMENTS
ENFR-1
The physical meeting location should be commutable, easy to reach.
ENFR-2
Initiator shall be updated regarding any changes in location status by
facility manager.
59
ENFR-3
Initiator shall be updated regarding any changes in equipment status
by facility manager.
ENFR-4
The system shall not reveal the information of it’s users.
5.2
REQUIREMENTS AND SPECIFICATIONS(RS)
Requirement Things, events or phenomenon in application domain or environment
which we want to make true with the software system to be built. Requirements are about
the environment.
Specification specification.
What the system does to fulfill the user requirements is a
Separating software requirements from specification is difficult task. We are stating software
requirements and specifications together in this section.
5.2.1
FUNCTIONAL RS – IMPROVED UNDERSTANDING OF II.2
SFR-1
The user who has login privileges can initiate a meeting.
SFR-2
The meeting scheduler should request the meeting date range, meeting
name, important and active participants, regular participants, location
and equipment needed to the initiator.
SFR-3
The meeting scheduler system should request the ‘importance level’ of the
meeting to initiator when he initiates the meeting.
SFR-4
The meeting scheduler system should allow initiator to cancel the
meeting.
SFR-5
The meeting scheduler system should allow the initiator to reschedule the
meeting.
SFR-6
The meeting scheduler system should cancel the meeting to resolve the
conflict with more important meeting.
60
SFR-7
If the meeting is canceled by meeting scheduler then it should send the
other acceptable schedules to initiator depending on already done voting.
SFR-8
If the acceptable schedules cannot be found to reschedule the meeting an
email shall be sent to initiator to reschedule the meeting with new date
range.
SFR-9
Participant shall be able to communicate by email with other participants
from meeting scheduler web site.
SFR-10
An initiator should select the ‘room location’ from given list. The
availability of room should be checked and if it is not available then
initiator has to choose other meeting room.
SFR-11
The initiator should select the ‘equipments’ needed for the meeting from
the equipments list plus active participants should have the option of
selecting the equipments when they confirm their attendance to meeting.
SFR-12
The meeting initiator may designate one or more meeting participants as
“important” meaning that their attendance at the meeting is required in
order to have the meeting.
SFR-13
The system should send the reminder 4 days before the meeting date to
participants who did not respond to invitation.
SFR-14
As soon as the active or important member declines the meeting
invitation the system shall send an email to initiator regarding
rescheduling a meeting.
SFR-15
At least 100% of active and important participants, and 70% of regular
participants should agree on the schedule( i.e. time, date, duration,
location) of the meeting.
SFR-16
The meeting must be confirmed as soon as the SFR-11 is satisfied.
SFR-17
As soon as meeting is confirmed, the confirmation should be sent to
participants by email.
SFR-18
Meeting scheduler shall provide audio visual aid to conduct meeting
remotely.
61
SFR-19
The scheduler should send the reminder 15 minutes before the meeting
time to all the participants.
SFR-20
The participants should be able to change their response at any time
before the meeting.
SFR-21
The meeting scheduler shall send a cancellation email to all the
participants in case the meeting gets canceled.
SFR-22
According to actual location of meeting the time zone information shall be
added to meeting information.
SFR-23
The system shall provide functionality to schedule meetings at the same time as
chunk.
SFR-24
System should provide functionality that will allow partial attendance
SFR-25
System should provide functionality where partial attendees can mention which
part of the meeting they are attending.
SFR-26
The system should provide functionality to suggest a convenient location for
meetings that are held in chunk
SFR-27
On receiving meeting request the probable participants can opt to Accept, accept
as tentative, or decline the meeting request.
SFR-28
System should provide functionality to update a meeting.
SFR-29
System should provide functionality to schedule recurring meetings
SFR-30
The initiator of a meeting can cancel a meeting delete it form the calendar and
then send notification to the participants.
SFR-31
System should provide functionality to organize meetings that are held at the
same time as chunks
62
SFR-32
Meeting that belong to a chunk can be held at the same time
SFR-33
System should provide functionality that will allow partial attendance
SFR-34
The system should provide functionality to suggest convenient location for
meetings that are held in chunk.
SFR-35
On receiving meeting request the probable participants can opt to Accept, accept
as tentative, or decline the meeting request.
SFR-36
System should provide functionality to update a meeting.
SFR-37
System should provide functionality to schedule recurring meetings
5.2.2 NON-FUNCTIONAL RS -IMPROVED UNDERSTANDING OF II.2 SOFTWARE
SYSTEM REQUIREMENTS: NFRS
SNFR1
A meeting should be accurately monitored, especially when it is held in a
virtual place. Here, nomadicity will then be important to consider
SNFR2
A meeting shall take care of most recent information such as exclusion
sets, preference sets, locations and equipment requests.
SNFR3
Re-planning of a meeting should be done as dynamically and with as
much flexibility as possible
SNFR4
The amount of interaction among participants(e.g., number and length of
messages, amount of negotiation required) should be kept minimal
SNFR5
The intended system should considerably reduce the amount of overhead
usually incurred in organizing meetings where potential attendees are
distributed over many different places and communicate with each other,
for example, via Internet
63
SNFR6
The system should reflect as closely as possible the way meetings are
typically managed (see the domain theory above)
SNFR7
The meeting date and location should be as convenient as possible, and
available as early as possible, to all (potential) participants
SNFR8
The system shall take care of concurrent meeting requests by giving
priority to important meetings.
SNFR9
The system shall take care to see that each attendee participates in just
one meeting.
SNFR10
The system shall decide upon a time deadline after which changes to the
preference sets, exclusion sets, location preferences cannot be made.
SNFR11
The system should accommodate as much decentralized requests as
possible; any authorized user should be able to request a meeting
independently of her whereabouts
SNFR12
The system shall be user friendly.
SNFR13
The system shall add participants at any point (before or during the
meeting). However the participants added during the meeting shall not
state their preferences.
SNFR14
The system shall use standard formats for date and time and also allow
users to select their preferred language.
SNFR15
The system shall be easily extensible to accommodate variations.
SNFR16
The system shall be customizable to formal as well as informal meetings.
64
6
NFR Formal specifications
Supplementary requirements are the requirements those cannot be captured in the use
cases. These are the non functional requirements related to the project. Project
supplementary requirements include product non functional requirements and
process nonfunctional requirements. Supplementary specification defines these
requirements.
The product nonfunctional requirements are the requirements like performance, security
which define the features of the TeraSoft meeting scheduling system. The process non
functional requirements are the requirements like reliability, usability, maintainability etc.
6.1
SOFTGOAL INTERDEPENDENCY GRAPH (SIG) FOR PRODUCT
NFR
NFR framework is a goal oriented approach for modeling nonfunctional requirements. UML
diagrams capture the functional requirements and SIG and KAOS diagrams capture the
nonfunctional requirements. First the high level goals are identified and they are further
decomposed into multiple levels until they are satisficed by operational soft goals. This
whole process is captured in soft goal interdependency graph
65
66
6.1.1
SECURITY
Confidentiality
The user should not be able to view other user’s information. This is done by providing
restricted access to users.
Authentication
Authentication shall be done by login. User should be authenticated as user or administrator
depending on the login information.
Integrity
The database integrity should be preserved.
Security [Meeting Info]
+
+
+
security [Institution Data]
Security [Participent Info]
+
Security [Meeting Data]
+
_
Authentication [DB user (NSG2)]
"Password can be stollen"
Login [NSG2, NSG2]
+
+
+
User Login
Administrator Login
Database access Roles [data]
6.1.2 PERFORMANCE
Capacity - System should be able to handle multiple scheduling requests at a time.
Responsiveness – System should confirm the participants and meeting times a day before meeting
time.
Minimum overhead – System should reduce the time and cost overhead by reducing interactions
and
67
automating the tasks.
Performance
+
+
+
Minimum overhead
Capacity
Responsiveness
+
++
+
+
minimize interactions
+
++
manages Cocurrency
Confirm meeting
+
+
confirm participants
auto rescheduling
Reschedule meeting
Send reminder before meeting
+
responding through website
confirm loction
68
6.2
NFRS SOFTGOAL INTERDEPENDENCY GRAPH (SIG) FOR
PROCESS NFR
6.2.1 USABILITY
Convenience Convenient to use due to some convenience features
Understandability Learning to use the system takes few hours. It is very easy to use as
the system as the interface is user friendly.
Usability
+
+
Convenience
++
Understandability
++
++
++
auto rescheduling
++
email reminders
User friendly interface
WebApplication
Quick to learn
6.2.2 RELIABILITY
Accuracy – System should monitor the status of the meeting accurately by monitoring
location, participants and time schedule of meeting.
Availability – System shold be available from anywhere in the world on web. It should be
available 24 hours a day 7 days a week.
Consistency - System should not schedule avoid the conflict of scheduling multiple
meetings on one schedule and location.
69
Reliability
+
+
+
++ Accuracy
Accurate monitoring of
Availability
Consistency
++
++
+
+
+
Location
++
All over the world
Schedule
Participants
Any time 24/7
Avoid multiple meeting on same
schedule
6.2.3 MAINTAINABLITY
Extensible - The system should be built in such a way that new functionalities can be
added easily in future. It should be compatible OS updates.
Evolvable – It should be able to evolve to support new functionality like hospital, hotel
room scheduling.
Modifiable – It should be able to customizable according to customers/users needs.
Flexible - It should be flexible and accept date, time formats in different countries. It
should work with different browsers and operating systems.
70
Maintainablity
+
+
Flexible
Extensible
+
++
+
Accept Variations
Evolvable
Modifiable
++
++
++
++
++
Add new functionality
Date and Time format
Browsers
Location virtual/actual
Customizable to schedule formal
or nonformal meetings
71
6.3
KAOS
72
7 MODELING ACTIVITIES
7.1
SYSTEM USE CASE DIAGRAM
7.2 BUSINESS USE CASE DIAGRAM
A business use case diagram consists of business use cases and business actor associated
with those use cases a business use case is a sequence of action s business performs that
yields as observable result of value to a particular business actor.
73
TDMS and Participants Interaction-A Business Use Case Diagram
Initiator
Request
Equipment
Initiate Meeting
Cancel Meeting
Active Participant
Respond to
meeting request
Location
Conflict
Resolutio
ns
Important
Participant
Participant
Withdraw meeting
74
7.3 FULLY DRESSED USECASES:
Initiate Meeting
UC Name
Initiate Meeting
Description
Allows anyone using the system to initiate new meetings
Primary Actor
Meeting Initiator
Meeting initiator wants to initiate a new meeting
stakeholders and
Interest
precondition
postcondition
Main Success Scenario
User is logged in as a meeting initiator
Meeting Initiator sends new meeting request to all
participants
1. The meeting initiator enters the meeting agenda, meeting
duration and the proposed meeting date range with a start
date and an end date.
2. The meeting initiator also fixes a freeze date.
3. The meeting initiator also marks participant as important or
active
Extension
None
Special Requirements
None
Technology and Data
variation list
The use case will occur through the use of standard
computer, keyboard and mouse.
-
Frequency of
Occurrence
Miscellaneous
Cancel Meeting
UC Name
Email address access is required
Once
None
Cancel Meeting
Description
Allows meeting initiator using the system to cancel meetings
when the conflicts could not be resolved.
Primary Actor
Meeting Initiator
Meeting initiator wants to cancel a new meeting
stakeholders and
Interest
precondition
postcondition
User is logged in as a meeting initiator
Meeting Initiator notifies cancelled meeting to all participants
75
Main Success Scenario
1. The meeting initiator enters the why the meeting has to be
cancelled.
2. The meeting initiator cancels the meeting and records it in
log.
Extension
None
Special Requirements
None
Technology and Data
variation list
The use case will occur through the use of standard
computer, keyboard and mouse.
-
Frequency of
Occurrence
Miscellaneous
Request Equipment
UC Name
Email address access is required
Once
None
RequestEquipment
Description
Initiator ask Participant what equipment(s) they need for the
given meeting via the meeting scheduler form
Primary Actor
Meeting Initiator
stakeholders and
Interest
Initiator: Wants to be able to access the application and
request a meeting easily. He/she also wants to get response
from Participants in an orderly and timely manner so that
he/she can prepare any equipment.
Participants: Wants to make sure all correct and working
equipment are present when the meeting starts.
precondition
Initiator needs to know what equipment is required
postcondition
Initiator knows what equipment is needed
Main Success Scenario
1. Initiator enters login information to system.
2. System validates initiator’s login and displays home page
3. Initiator clicks Initiate Meeting
4. System displays the Meeting Details Screen
5. Initiator enters the name of participant
6. Initiator enters Add
7. System populates Participant field with name
8. Repeat Step 6 till 11
9. Initiator enters the subject of the meeting
10. Initiator clicks submit button.
11. System acknowledge the form submission and sends the
request to the email addresses
76
Extension
Initiator has an option of suggesting some equipment by
entering them on the form for the Participants.
Special Requirements
The email address of the participants must be accessible to the
initiator, whether the emails are directly stored in the system
or requires system’s accesses to an active email server.
Technology and Data
variation list
The use case will occur through the use of standard
computer, keyboard and mouse.
-
Frequency of
Occurrence
Miscellaneous
View Scheduled
Meetings
UC Name
Email address access is required
Once
None
View Scheduled Meetings
Description
Allows both meeting initiator and the participants to view
upcoming meetings
Primary Actor
Meeting Initiator, Participant
Meeting initiator wants to view upcoming meetings and decide
to initiate a meeting
stakeholders and
Interest
Participant wants to view upcoming meetings and decide to
accept or decline a meeting request
precondition
User is logged in as a initiator or participant
postcondition
The user is able to view upcoming and already scheduled
meetings
The user is able to view upcoming and already scheduled
meetings and all the related information viz:
Agenda, Duration ,Date range-Start Date, Date range-End
Date ,Participant Status, Preference Set, Exclusion Set
Equipment, Scheduled Date, Time and Location
Main Success Scenario
Extension
None
Special Requirements
None
Technology and Data
variation list
The use case will occur through the use of standard
computer, keyboard and mouse.
-
Frequency of
Occurrence
Miscellaneous
Email address access is required
Once
None
77
Set Duration
UC Name
Set Duration
Description
Meeting initiator sets the meeting time duration to at least 30
minutes
Primary Actor
Meeting Initiator
stakeholders and
Interest
Initiator: Wants to be able to initiate a meeting for a minimum
of 30 minutes via the application
precondition
Initiator already has proposed date set
postcondition
Initiator has set the time to at least 30 minutes
Main Success Scenario
1. Initiator enters login information to system
2. System validates initiator and directs to home page
3. Initiator clicks Initiate Meeting
4. System displays the Meeting Details Screen
5. Initiator enters time.
6. System checks the time difference between start time and
end time is at least 30 minutes
7. System stores time.
Special Requirements
The meeting setup form must be intuitive to user
Technology and Data
variation list
The use case will occur through the use of standard computer,
keyboard and mouse.
Frequency of
Occurrence
Miscellaneous
Once
View Scheduled
Meetings
UC Name
None
View Scheduled Meetings
Description
Allows both meeting initiator and the participants to view
upcoming meetings
Primary Actor
Meeting Initiator, Participant
78
stakeholders and
Interest
Meeting initiator wants to view upcoming meetings and decide
to initiate a meeting
Participant wants to view upcoming meetings and decide to
accept or decline a meeting request
precondition
User is logged in as a initiator or participant
postcondition
The user is able to view upcoming and already scheduled
meetings
The user is able to view upcoming and already scheduled
meetings and all the related information viz:
Agenda, Duration ,Date range-Start Date, Date range-End
Date ,Participant Status, Preference Set, Exclusion Set
Equipment, Scheduled Date, Time and Location
Main Success Scenario
Extension
None
Special Requirements
None
Technology and Data
variation list
The use case will occur through the use of standard
computer, keyboard and mouse.
-
Frequency of
Occurrence
Miscellaneous
Respond to Meeting
Requests
UC Name
Email address access is required
Once
None
Respond to Meeting Requests
Description
Allows participants to state their choice to meeting dates and
also state the dates in which they are unavailable
Primary Actor
Meeting Initiator, Participant
The participant conveys his convenience in all aspects to the
meeting initiator
stakeholders and
Interest
precondition
postcondition
User is logged in as a meeting initiator
All the requested information is submitted to the initiator
Main Success Scenario
1. The meeting initiator enters the why the meeting has to be
cancelled.
2. The meeting initiator cancels the meeting and records it in
log.
Extension
None
Special Requirements
None
Technology and Data
variation list
The use case will occur through the use of standard
computer, keyboard and mouse.
79
Frequency of
Occurrence
Miscellaneous
Withdraw Meeting
UC Name
Description
Primary Actor
Email address access is required
Once
None
Withdraw Meeting
Meeting Participant resolve conflict by withdrawing from
meeting
Meeting Participant
Stakeholders and
Interest
precondition
Initiator: Wants to be able to view withdrawals
postcondition
Participant has withdrawn from the meeting
Main Success Scenario
1.
The Participant received there is a conflict in date time and
that they need to resolve conflict
The Participant enters their login information
2. System validates Participant’s login and directs to home
page
3. Participant Opens Existing Meeting
4. System displays a List of assigned meetings
5.
Participant selects the meeting of interest
6.
Participant selects Withdraw
7. System displays a Withdrawal Message
8. System removes the prior’s Participant information from
the meeting details
9. System sends the meeting initiator a message notifying him
of the withdrawal
Extension
None
Special Requirements
The meeting setup form must be intuitive to user
Technology and Data
variation list
The use case will occur through the use of standard computer,
keyboard and mouse.
Frequency of
Occurrence
Miscellaneous
Once
None
Conflict Resolutions
UC Name
Conflict Resolutions
Description
Initiator extends the date range
Primary Actor
Meeting Initiator
80
stakeholders and
Interest
Initiator: Wants to be able to access the application and
resolve the date conflict easily.
Participants: Wants to make sure any date conflicts are
resolved before they set it in the calendar and/or move other
priorities (task, another conflicting meeting) around.
precondition
There is a conflict in date. The address of Participants field
have already been populated.
postcondition
Date range is extended
Main Success Scenario
1. The Participant enters their login information
2. System validates Participant’s login an diirects to home
page
3. System displays a List with the participant's assigned
meetings
4. Initiator selects the meeting of interest
5. Initiator enters date and system stores date
6. Initiator notifies the Change
7. System acknowledges the change and sends the form to the
email addresses.
Extension
Initiator is already logged in for some other activity when
he/she decides to update date range for a particular meeting.
Special Requirements
The meeting must not have occurred
Technology and Data
variation list
The use case will occur through the use of standard computer,
keyboard and mouse.
Frequency of
Occurrence
Miscellaneous
Once
Propose Date and
Location
UC Name
None
Propose Date and Locations
Description
Meeting Participant provide preference set of date/time and
Location
Primary Actor
Meeting Participant
stakeholders and
Interest
Initiator: He/she also wants to get response from Participants
in an orderly and timely manner so that he/she can prepare
set the final date time and location for a meeting.
Participant: Wants to be able to access the application and
enter the date time and location request easily.
81
precondition
Participant received request for preference set
postcondition
Participant has provided preference set
Main Success Scenario
1.
The Participant enters their login information
2. System validates Participant’s login an diirects to home
page
3. Participant Opens Existing Meeting
4. System displays a List Window with the Participant’s
assigned meetings
5. Participant selects the meeting of interest
6. System displays Meeting Details Screen
7. Participant selects Propose Preference Set
8. Participant enters date
9. Participant enters time
10. Participant enters Location
11. System stores preference set in the database and displays
the preference set in the Preference Set Field
Extension
The Participant can specified the time range for each date
specified. There is a sub section under the section Participant
Preference Date Time that enables an Participant to enter that
information
Special Requirements
Participant must know how to use the system to specify date
time and particularly, how to specify time frame for each date
Technology and Data
variation list
The use case will occur through the use of standard computer,
keyboard and mouse.
Frequency of
Occurrence
Miscellaneous
Once
None
82
7.4 SEQUENCE DIAGRAMS
83
84
85
86
87
88
7.5
ACTIVITY DIAGRAM:
The Activity diagram is a specialized type of state chart diagram that depicts flow
from one activity to another activity within a system.
The activity diagram presented below is an extended version of UML incorporating
the concepts of input, output, control, and mechanism from the Structured Analysis
and Design Technique (SADT).
The UML+ specification for Enterprise Functional Requirements includes an
extension to the UML Use Case diagram. SADT modeling features are used to define
the scenarios of the main Use Cases.
The diagrams have the following features:
89
1. A starting point marked “Start” depicts the entry point into the enterprise
domain.
2. Steps in the main Use Cases are taken from the events in the main Use Case
diagram. The steps are modeled as Use Cases. These steps can be furthered
decomposed using the same notation.
3. Inputs, outputs, controls, and mechanisms are modeled in the following
manner:
Control
Input
Activity
Output
Mechanism
4. Inputs, outputs, and controls are participatory objects in the application
domain. Mechanisms are actors from the Use Case diagram.
5. Conditions are stated under the input, output, control or mechanism as
[condition]


The user must first login and be validated as a member of the system. The
system checks to see if the user is a member and if he is already logged in. If
he is a member and is already logged in, his current session is resumed. If he
is not logged in, a new session is created for him.
After the user logs into the system, the user can decide to view their scheduled
meetings, or add a new meeting request. A new meeting request is first
initiated by inviting participants, selecting a meeting date, and a location. If
any request has a meeting conflict, then the user is prompted to reschedule
the meeting.
90
7.5.1 SCHEDULE MEETING ACTIVITY DIAGRAM
Attendee
Initiate
Meeting
Meeting Initiator
Yes
Checks availability
Accept Meeting
Administrat
or
No
yes
Reschedules Meeting
Request Equipment
Attendee
No
Meeting Initiator
Confirm Meeting
Meeting Date/ Location
91
7.5.2 UML- ACTIVITY DIAGRAM:
Start RE
Process
Review Similar
Software
Review Preliminary
Requirement Document
Identify
Stakeholder
Interview
Users
Model Enterprise, Functional,
Non-Functional Requirements
Create initial
dependency graph
Identify
Conflicts
Propose
Solution
Validate Solution
with user
Create improved
Dependency graph
Convert Functional
Dependency to UML
Convert NonFunctional
dependency to SIG
Refine functional Requirements
and identify Domain Class
Specify
SRS
92
7.5.3 BUSINESS ACTIVITY DIAGRAM:
93
7.6 DOMAIN CLASS DIAGRAM:
94
7.7 FISH BONE DIAGRAM:
Unexpected change in
meeting schedules /
cancelation by
attendees
Attendees
Location
Date
Attendees are in different
places/ Geometric locations
have different holidays
Attendees not
available at a given
date
Attendees are in
different time zones
Attendees are in different
places/ Geometric locations
Scheduling meetings is
Difficult and Time
Consuming
Equipment
taken by other
meetings
Equipment
malfunction
Availability of
Free Timeslots
Availability of
Equipment
Attendees have
already committed
to other meetings
Attendees have work
or assignments on a
given meeting date
Availability of
Attendees
95
8
TRACEABILITY
This section provide traceability matrix for better understanding in case of
inconsistency occurring. If this happens, the stakeholders easily trace back from the
problem to the root that causes the problem. Traceability refers to the completeness
of the information about every step in a development process. A traceability matrix is
created by associating requirements with the work products that satisfy them.
Traceability is very important because requirements are volatile and as the project
enhances, developer needs to trace back to original requirements.
8.1
FORWARD TRACEABILITY (DOMAIN REQUIREMENTS TO
FUNCTIONAL REQUIREMENTS AND NON FUNCTIONAL
REQUIREMENTS)
The forward traceability shows the mapping only between the requirements. Here we are
mapping the Enterprise Requirements with the functional and non functional requirements.
EFR-1
EFR-2
EFR-3
A “meeting initiator” shall initiate a meeting by selecting a
“date range” and “location” for the meeting.
The Proposed meeting date should belong to the stated date
range and not to none of the exclusion sets
SFR-1, SFR-2,
SFR-3
SFR-14
SFR-20
A meeting room must be available at the selected meeting date.
SFR-10
EFR-4
A meeting room should meet the equipment requirement.
EFR-5
Meeting place will be virtual or Real location.
SFR-11
SNFR-8
96
EFR-6
EFR-7
EFR-8
EFR-9
Meeting date should be defined by Calendar date , time and
period.
SFR-2
The date conflict should be solved by extending the date range
by the initiator.
SFR-5, SFR-7
All the important participants should be able to attend the
meeting.
SFR-14
SNFR-6
SFR-8
SFR-15
The participants should be able to change their responses at
any time before the meeting date.
SNFR-9
EFR-10
EFR-12
8.2
The time confusion due to different time zones shall be solved
by the system.
The meeting initiator can be one of the participants or some
representative.
SFR-20
SFR-21
SFR-1
BACKWARD TRACEABILITY
Our forward traceability showed the mapping between the requirements, precisely the
enterprise and Functional, Non functional requirements. Now, in the backward traceability,
we are actually showing the mapping between the Functional and the Non functional
requirements which could also be considered in the previous section(forward traceability).
But the mapping between the Functional and Enterprise requirements clearly depicts the
backward traceability. Though according to the definition, as explained in the class , the
forward and backward traceability is done between the Requirements and the System
design, we are showing the traceability only between the requirements.
SFR-1
The user who has login privileges can initiate a meeting.
ER-5,ER-1,ER-12
97
SFR-2
The meeting scheduler should request the meeting date range, ER-1,
meeting name, important and active participants, regular
ER-6,SNFR-6
participants, location and equipment needed to the initiator.
SFR-3
The meeting scheduler system should request the ‘importance ER-1
level’ of the meeting to initiator when he initiates the meeting.
SFR-5
The meeting scheduler system should allow the initiator to
reschedule the meeting.
ER-7
SFR-6
The meeting scheduler system should cancel the meeting to
resolve the conflict with more important meeting.
ER-6,SNFR-6
SFR-7
If the meeting is canceled by meeting scheduler then it should ER-7
send the other acceptable schedules to initiator depending on
already done voting.
SFR-8
If the acceptable schedules can not be found to reschedule the ER-7
meeting an email shall be sent to initiator to reschedule the
meeting with new date range.
SFR-9
Participant shall be able to communicate by email with other
participants from meeting scheduler web site.
ER-7,SNFR-9
SFR-10
An initiator should select the ‘room location’ from given list.
The availability of room should be checked and if it is not
available then initiator has to choose other meeting room.
ER-3,SNFR-2,SNFR-3
SFR-11
The initiator should select the ‘equipments’ needed for the
meeting from the equipments list plus active participants
should have the option of selecting the equipments when they
confirm their attendance to meeting.
ER-4,SNFR-4
SFR-12
The meeting initiator may designate one or more meeting
participants as “important” meaning that their attendance at
the meeting is required in order to have the meeting.
SNFR-1,SNFR-3
SFR-13
The system should send the reminder 4 days before the
ER-3,SNFR-8
meeting date to participants who did not respond to invitation.
SFR-14
As soon as the active or important member declines the
meeting invitation the system shall send an email to initiator
regarding rescheduling a meeting.
SNFR-6
ER-2,ER-8
98
SFR-15
At least 100% of active and important participants, and 70% of ER-8
regular participants should agree on the schedule( i.e. time,
date, duration, location) of the meeting.
SFR-17
As soon as meeting is confirmed, the confirmation should be
sent to participants by email.
ER-7,SNFR-3,SNFR-9
SFR-18
Meeting scheduler shall provide audio visual aid to conduct
meeting remotely.
ER-7,SNFR-6
SFR-19
The scheduler should send the reminder 15 minutes before the ER-9
meeting time to all the participants.
SFR-20
The participants should be able to change their response at any ER-2
time before the meeting.
SFR-21
The meeting scheduler shall send a cancellation email to all the ER-10
participants in case the meeting gets canceled.
SFR-22
According to actual location of meeting the time zone
information shall be added to meeting information.
ER-10
99
8.3
SCREEN DESCRIPTIONS
SCREEN – 1
SCREEN –2
SCREEN –3
SCREEN –4
SCREEN –5
SCREEN –6
SCREEN –7
SCREEN –8
SCREEN –9
SCREEN –10
8.4
TRACEABILITY/DEPENDENCY MAPPING BETWEEN PROJECT–1
& PROJECT-2 FUNCTIONAL REQUIREMENT AND
IMPLEMENTATION
SFR 1
SCREEN -
SFR 2
SCREEN -
SFR 3
SCREEN -
SFR 4
SCREEN -
SFR 5
SCREEN -
SFR 10
SCREEN -
SFR 11
SCREEN -
100
SFR 12
SCREEN -
SFR 14
SCREEN -
SFR 15
SCREEN -
SFR 16
SCREEN -
SFR 17
SCREEN -
SFR 21
SCREEN -
SFR 23
SCREEN -
SFR 24
SCREEN -
SFR 25
SCREEN -
SFR 26
SCREEN -
SFR 27
SCREEN -
SFR 28
SCREEN -
SFR 30
SCREEN -
SFR 31
SCREEN -
SFR 32
SCREEN -
SFR 33
SCREEN -
101
102
8.5
TEST PLAN
Meeting Scheduler System Test Plan:
Software testing is a software verification and validation method conducted to detect
software failures and to assure the quality of the software. The Meeting scheduler system is
tested with the below test cases to ensure high quality and accuracy in the system
functionality.
Environment needs: Visual Studio.Net, MS SQL Server, Web browser, IIS Server.
Test Cases for Meeting Scheduler system:
Test Case
ID
Test Case Title
Test Case Description
TC_001
Login
The login functionality of the system with given correct
username and password.
TC_002
New user
registration
Test to check whether new user can be added to the system
given name, password and email address.
TC_003
Email to
participants
Test to check whether all the participants receive email of
appropriate information when meeting initiated.
TC_004
Special
Equipment
Preference
Test to check whether active participants can add their
equipment preferences.
TC_005
Location
Preference
Test to check whether important participants can add their
location preference in the system.
TC_006
Teleconferencing
Test to see whether the system provides an option for
teleconferencing as meeting location.
TC_007
View Meeting
Test to see whether all the meeting the participant initiated
and has been requested to participate is included in the view
meeting screen.
TC_008
Initiate Meeting
Test to check whether new meeting can be initiated from the
“Initiate Meeting” link.
TC_009
Change Meeting
Initiator
Test to check whether the initiator of the meeting can be
changed by system administrator.
TC_010
Cancel Meeting
Test to check whether the meeting can be cancelled
recurring and non recurring meetings.
103
TC_011
Recurring
Meeting
Test to check whether initiator can assign a meeting as
recurring.
TC_012
Withdraw from
Meeting
Test to check whether participants can withdraw from the
meeting.
TC_013
Modify
Preference and
Exclusion set
Test to check whether the participants can add and modify
their preference and exclusion set.
TC_014
Conflict
Test whether system gives a conflict message when there is
a conflict in meeting participants meeting date and the
preference and exclusion set of the participants.
TC_015
Proposed
Meeting Date
Test whether the proposed meeting date belong to
preference set and in decision of the meeting initiator.
TC_016
Preference Set
Test to check whether meeting participants can enter
multiple preference sets.
TC_017
Priority
Test whether meeting priority options from the view
meeting screen.
TC_018
Email for changes
to preference or
exclusion set
Test whether email is sent for changes made by participant
in exclusion or preference set.
TC_019
Participants
Notes
Test to check whether the participants can add/update
notes.
TC_020
Performance
Test to check whether the performance of the meeting
scheduler system is appropriate.
TC_021
Security
Test the security of the system to check unauthorized users
are not allowed.
TC_022
Usability
Test to check whether system is usable by people with
minimal computer knowledge.
TC_023
Flexibility
Test to check whether the system is flexible with evolving
system data.
104
8.6
MAPPING FROM TESTCASES TO SFR AND NSFR
Test Case
Functional and Non-Functional Requirement
TC_001
SFR_036
TC_002
SFR_036
TC_003
SFR_002,SFR_024, SFR_028
TC_004
SFR_006
TC_005
SFR_007, SFR_018
TC_006
SFR_019
TC_007
SFR_010,SFR_013,SFR_014,SFR_016
TC_008
SFR_029
TC_009
SFR_036, SFR_040
TC_010
SFR_034, SFR_037
TC_011
SFR_033
TC_012
SFR_015
TC_013
SFR_003, SFR_004, SFR_021,
TC_014
SFR_010,SFR_013,SFR_014,SFR_016
TC_015
SFR_008
TC_016
SFR_009
TC_017
SFR_022, SFR_030
TC_018
SFR_025
TC_019
SFR_035
TC_020
SNFR_010
105
TC_021
SNFR_015
TC_022
SNFR_011
TC_023
SNFR_003
106
9 WHY OUR PROJECT IS BETTER THAN OTHERS
Instead of approaching our friendly computer salesperson and say, show me what your
system can do, what we say is, this is what I need: show me that your system can do!!!!!!
The truth is that all the systems are probably very good. Each has features that its proponents
claim to make it immeasurably better than the others. The only thing is one of them will be
better than others, and one will suit us best of all.
And, we are proud to claim that we are better!!
We have done a sample project that represents the typical situation that our system will have
to handle. We also made up some input data in exactly the form in which we would normally
receive them and design some management reports that show exactly what we would like the
system to produce.
Firstly, We used incremental model unlike other groups who used spiral model. In our
model cycles are divided up into smaller, more easily managed iterations
A working version of software is produced during the first iteration, so we have working
software early on during the software life cycle. Subsequent iterations build on the initial
software produced during the first iteration.
Our model is easier to test and debug during a smaller iteration. It is easier to manage risk
because risky pieces are identified and handled during its iteration and each iteration is an
easily managed milestone which is a complete contradiction to the spiral in which risk
analysis requires highly specific expertise. So, Project’s success is highly dependent on the
risk analysis phase and it does not work well with small projects.
Moreover, we covered more stake holders and took domain experts into consideration which
other groups did not. We provided solid precise definition to active and important
participants and also reflected that in their roles.
Secondly, we have come up with improved understandings after integrating the issues and
initial requirements. For this to happen, both the requirements team and development team
sat together. We could not see this any other teams.
Thirdly, we divided ourselves into four categories along with some exclusive roles assigned
to those set of people in that category. After the sub group work is done, the teams sat
together to avoid interactional and integral problems. We exactly replicated how a
corporate project is managed unlike some groups in which everybody worked on
everything.
107
10 CHANGEABILITY
The requirements and specifications can be changed up to 20% with a variance of +/-5%. This value
is not accurate and is based on the following criterions





The intensity of change on prototype
The Time and Resource required to implement the change in the provided limited resources
How deviated is the new requirement from the old requirement
The New changes should support validation and traceability factors
The impact of new changes onto other existing modules
An accurate value can be inferred by assigning weight-age to the requirements by using the matrix
method and calculating the threshold value and determining the impact of change. If the calculated
value exceeds this threshold value then we shall not modify the requirements or else modify the
requirement.
11 REFERENCES
1.
http://www.utdallas.edu/~chung/RE/syllabus.htm
2.
http://en.wikipedia.org/wiki/Traceability
3.
http://www.jiludwig.com/Traceability_Matrix_Structure.html
4.
http://www.utdallas.edu/~chung/RE/Presentations09S/
5.
http://www.utdallas.edu/~chung/RE/Presentations08F/
108