Develop a Meeting Scheduling and Management Application using ASP.NET

The provided content is about creating a meeting scheduling application that allows employees and heads of departments to schedule meetings, view calendars, add/remove members, check available rooms, and book vacation periods. The application should be menu-based with basic functions and have features like validation, data sequence management, error handling, and security. The performance requirements include supporting up to 50 requests simultaneously, updating information in real-time, and validating multiple logins quickly. The design constraints are that the application must use basic functions rather than complex ones.

Meeting Engagement and Tracking System
SRS DOCUMENT AND USECASE
SEPTEMBER 5, 2016
STUDENT

Contents
1. INTRODUCTION............................................................................................................................2
1.1 PURPOSE............................................................................................................................2
1.2 SCOPE.................................................................................................................................2
1.3 BENEFITS............................................................................................................................3
1.4 ABBREVIATIONS...............................................................................................................3
1.5 REFERENCES....................................................................................................................3
1.6 OVERVIEW..........................................................................................................................3
2. OVERALL DESCRIPTION.........................................................................................................3
2.1 PRODUCT PERSPECTIVE...............................................................................................4
2.1.1 User interfaces.............................................................................................................4
2.1.2 Hardware interfaces....................................................................................................4
2.1.3 Software interfaces.....................................................................................................4
2.1.4 Communications interfaces........................................................................................5
2.1.5 Memory Constraints....................................................................................................5
2.2 PRODUCT FUNCTIONS...................................................................................................5
2.3 USER CHARACTERISTICS..............................................................................................5
2.4 CONSTRAINTS...................................................................................................................6
2.5 ASSUMPTIONS..................................................................................................................6
3. REQUIREMENTS.......................................................................................................................6
3.1 EXTERNAL INTERFACE REQUIREMENTS..................................................................6
3.1.1 User Interfaces............................................................................................................6
3.1.2 Hardware interfaces....................................................................................................7
3.1.3 Software interfaces.....................................................................................................8
3.1.4 Communications interfaces........................................................................................8
3.2 FUNCTIONAL REQUIREMENTS.....................................................................................8
3.3 PERFORMANCE REQUIREMENTS................................................................................8
3.4 DESIGN CONSTRAINTS..................................................................................................9
3.5 OTHER REQUIREMENTS................................................................................................9
3.5.1 Security.........................................................................................................................9
3.5.2 Maintainability..............................................................................................................9
3.5.3 Portability......................................................................................................................9
USECASE DIAGRAM......................................................................................................................10
USECASE DESCRIPTION..............................................................................................................11
1 | P a g e

2 | P a g e

1. INTRODUCTION
The SRS is about an online meeting management system. The application will track and
engage employees as well as manage other schedules of the meetings and will be called
‘MEAT’ app. It will an online portal where employees can book rooms for meetings, search
rooms for meetings, send emails to associated employees about meetings and much more.
In the following sub-sections of the SRS document there will be an overview about the
requirements provided by the user for the development of the system before we create a
hard coded design and implement it on user machines. This document will act as an
overview for the developers to provide insights about what to build.
1.1 PURPOSE
The purpose of the project is to provide an online facility to the employees to manage and
track the meetings. The system will avoid last minute changes or miscommunications.
Everybody can be alerted about the schedules, pre-plans can be made and there will be no
clashes. Empty meeting rooms can be booked and reminders can be sent before the
meeting starts.
1.2 SCOPE
Since the organization is large enough so at times there can be clashes related to rooms or
timing of work. Thus this meeting manager will handle everything, providing convenience in
return. The web application that will be used to process meeting requests online is “MEAT”.
The app will reduce the overall scheduling time as well as make it an easier task for
employees to handle. The employees can login and look for calendars and schedules. They
can even edit info add members or remove them from the meeting schedule. There will be
universal calendars to manage everything and process every request.
3 | P a g e

1.3 BENEFITS
This portal will help in reducing the carbon footprint and also will help in providing varied
exams on a single platform. Multiple students can take exams and test masters can upload
tests. Thus there will be efficiency of the tests, variety, reliability and maintenance of bulk
data. Every time a new website will not have to be referred for different tests. The test
masters also need not to create any website, rather they can just register and upload tests.
1.4 ABBREVIATIONS
None.
1.5 REFERENCES
IEEE Recommended Practice for Software Requirements Specification- IEEE Std 830-1993.
1.6 OVERVIEW
The SRS document hence developed also contains description about various software and
hardware requirements, system requirements, and user interfaces etc. functions in detail
apart from the general user requirements related to functionality.
2. OVERALL DESCRIPTION
In Online meeting management system, if a meeting has to be booked an employee will
have to login first with his credentials. If he or she logs in successfully he or she can look for
current and future booked meetings, available rooms, calendars, vacations etc. They can
even edit the schedules, But only if they are the head of the department. There will be
certain restrictions in updating or deleting the data. If the meeting schedule has been set, it
will have to be approved by the head of the department. In this way, data security and
consistency will also be maintained.
4 | P a g e

2.1 PRODUCT PERSPECTIVE
2.1.1 User interfaces
The application system to be designed will be easy to use. The interface will be simple and
easy to learn and handle and will be a menu based one.
The Following screens will be present:
1. A login screen to enter the username and password will be provided.
2. Different login access will be provided to employees and head of departments.
3. Screen to display schedules will be provided.
4. List of all the available and booked rooms will be present.
5. Screen to schedule a meeting will be present.
6. Send reminder function will be present.
7. There will be screen to remove or add people to existing meetings.
8. The employees will be able to book vacation time by filling a form and seeking head
of department’s approval.
2.1.2 Hardware interfaces
1. Local server to store the data and provide access to the meeting schedules.
2. Network devices like switch establish the connection on the LAN to connect all the
local systems so that all employees can be informed.
2.1.3 Software interfaces
1. A windows based operating system.
2. MySQL database management system to manage the schedule and other tables
which will hold data
3. ASP.net for developing code.
5 | P a g e

2.1.4 Communications interfaces
None
2.1.5 Memory Constraints
1. 4 GB RAM to run the application on the local systems and process the requests
made by employees.
2. 50 GB hard disk to store the data and schedules etc. We will be taking a higher
amount of space so as to meet the growing needs of the future.
2.2 PRODUCT FUNCTIONS
The MEAT application will allow only authorised users to access the application functions
and retrieve the data from the database. These users will be employees – who create
requests, the admin- who monitors application regularly and the head of department – who
approve requests or edit the schedules. The major functions that will be performed are:
1. Facility to request vacations
2. Facility to book rooms for meetings
3. Facility to send reminders
4. Facility to check or update meeting schedules.
5. Facility to manage calendars.
6. Facility to add members to the meeting.
2.3 USER CHARACTERISTICS
1. Educational level and Skills: the Users should have knowledge about the basic
operations related to computer and should be aware of English language.
2. Experience: the Users must have prior experience of using computer applications
specially menu based.
6 | P a g e

2.4 CONSTRAINTS
1. The MySQL database is a good yet complex DBMS to start the application with. So
the admin should be well aware with its handling so as to tackle as issues that arise
in future.
2. Since it will be a general application, security may be less and thus it may pose
threat login credentials of the employees or any other critical data.
2.5 ASSUMPTIONS
1. The meeting schedule management is the main objective of the application to be
developed.
2. Employees will have to wait for approvals on the requests generated.
3. Login credentials will be necessary in order to access any feature of the application.
4. All the information related to meetings will be already present that is gathered and
constructed into a database.
3. REQUIREMENTS
Here we will discuss the software requirements in a detailed level so that this document will
contain sufficient information for the designers to design the system and testers to test the
system as per the requirements provided by the user and also to gather the hidden
requirements as well.
3.1 EXTERNAL INTERFACE REQUIREMENTS
3.1.1 User Interfaces
1. Schedule meeting interface: it will have the following fields:
a. Schedule id
b. Department Id
7 | P a g e

c. Agenda
d. Date
e. Time
f. Room no.
g. Add members
2. Login Screen: Fields that will be available are:
a. Login ID
b. Password
3. Check room screen: the Fields are:
a. Room no.
b. Floor
c. Availability status
4. Edit meeting schedule Screen: the Fields are:
a. Schedule id
b. Buttons to edit date, time, room etc.
5. View universal calendar Screen
a. Calendar of the company.
6. Book vacation Screen
a. Employee id
b. Vacation period
c. Department
d. Reason
3.1.2 Hardware interfaces
1. Switches and other network devices to make up the LAN.
2. Screen resolution of at least 800X600 is required for proper and complete viewing of
screens. Higher resolution will be accepted.
8 | P a g e

3.1.3 Software interfaces
1. Any windows based operating system.
2. MySQL as the DBMS-for database.
3. ASP.net for developing code.
3.1.4 Communications interfaces
Web browser to run the application on the localhost and access the local database server to
schedule or manage meetings.
3.2 FUNCTIONAL REQUIREMENTS
1. Validation: this will be handled by the ASP script. It will provide on the form the
required validation and verify data from the server.
2. Data sequence: The information about the meeting schedules, room bookings,
available rooms, vacations will be handled in a manner so that no clash occurs
between the data. After all this the main purpose of creating the application.
3. Error and exception handling: If the credential validation fail at any point or any
requests are not approved by the heads, then this will not lead to abrupt termination.
Rather error messages should be prompted on the user screen providing the further
steps or the exit steps, leaving the application in a consistent state. Any unauthorized
requests will be recorded to keep check on malicious users.
3.3 PERFORMANCE REQUIREMENTS
Although this application doesn’t require high performance outputs, yet the basic
requirements that will be supported are:
1. Max 50 requests will be supported at maximum, keeping in mind the future
requirements.
9 | P a g e

2. The information will be updated in real time avoiding any deadlocks.
3. All the validation will be done in minimum time despite multiple logins.
3.4 DESIGN CONSTRAINTS
There is just one basic requirement that is the application must be use basic function, rather
than complex functions and should be menu based.
3.5 OTHER REQUIREMENTS
3.5.1 Security
This requirement states that only authorized users will be able to access the application and
the data from the database by entering the login id and corresponding password which will
have to be validated. Unauthorized access will be restricted by the server. Moreover there
will be firewalls to protect the server data and intrusions.
3.5.2 Maintainability
The application will be easily maintained by the admin. Apart from that there will be regular
maintenances carried out in future. For developers, it will be simple to add the changing
needs or requirements of the modules when needed.
3.5.3 Portability
As the application will run on the browser as localhost, thus, it will be easier to port it to other
platform if the company requires so. If the OS changes from the windows OS to any other, it
will yet work with the corresponding browsers.
10 | P a g e

USECASE DIAGRAM
The Usecase diagram of the application is as follows:
11 | P a g e

USECASE DESCRIPTION
Use Case Name: schedule meeting
Iteration: Filled.
Summary: The employee or head of department wants to schedule a meeting for the
employees.
Basic Course of Events:
1. The employee logs in.
2. Enter the details related to meeting schedule.
3. The schedule is created and head of department is notified.
Alternative Paths: none
Exception Paths: none
Extension Points: edit schedule, add/remove members.
Trigger: The employee or head of department wants to schedule a meeting
Assumptions: The person is an employee of the company has a valid login id and
password.
Precondition: The employee is logged in
Post-condition: The meeting schedule is created.
Author:
Date: 8 September, 2016
Use Case Name: login
Iteration: Filled.
Summary: The employee or head of department enters his or her login id and password.
Basic Course of Events:
1. The employee enters id and password
12 | P a g e

2. Details are validated
3. User is logged in.
Alternative Paths: none
Exception Paths: In step 2, if the details are not validated, the user is asked again to
enter the correct details.
Extension Points: None
Trigger: The employee wants to login
Assumptions: The person is an employee of the company has a valid login id and
password.
Precondition: The id and password are valid
Post-condition: The employee is logged in.
Author:
Date: 8 September, 2016
Use Case Name: edit schedule
Iteration: Filled.
Summary: The head of department logs in into the system and wants to edit the
schedule.
Basic Course of Events:
1. The head of department logs in.
2. Enter the schedule no.
3. Edits the schedule details.
Alternative Paths: none
Exception Paths: In step 2, if the schedule number not validated, the user is asked
again to enter the correct details.
Extension Points: None
Trigger: The head of department wants to edit the meeting schedule.
Assumptions: The employee is head of department of the company.
13 | P a g e

Precondition: The employee has correct schedule number.
Post-condition: The schedule is edited and saved.
Author:
Date: 8 September, 2016
Use Case Name: reminders
Iteration: Filled.
Summary: The employees who will have to attend the meeting are notified.
Basic Course of Events:
1. The employee logs in
2. Send the reminders to added members.
Alternative Paths: none
Exception Paths: none
Extension Points: None
Trigger: The reminders are to be sent
Assumptions: The schedule has been created and members have been added.
Precondition: The members have been added already.
Post-condition: The employees are notified.
Author:
Date: 8 September, 2016
Use Case Name: view calendar
Iteration: Filled.
Summary: The employee or head of department wants to view the calendar.
Basic Course of Events:
1. The employee enters id and password
2. User is logged in.
3. Calendar is viewed.
14 | P a g e

Alternative Paths: none
Exception Paths: none
Extension Points: None
Trigger: The employee wants to view the calendar.
Assumptions: The person is an employee of the company has a valid login id and
password.
Precondition: The employee is logged in.
Post-condition: The calendar is viewed.
Author:
Date: 8 September, 2016
Use Case Name: add or remove members
Iteration: Filled.
Summary: The head of department wants to add or remove members from the meeting
schedule.
Basic Course of Events:
1. The head of the department logs in
2. Enters a valid schedule no.
3. Edits members
Alternative Paths: none
Exception Paths: In step 2, if the schedule number not validated, the user is asked
again to enter the correct details.
Extension Points: None
Trigger: The head of department wants to edit the members in the meeting schedule.
Assumptions: The employee is head of department of the company.
Precondition: The employee has correct schedule number.
Post-condition: The schedule is edited and saved.
Author:
15 | P a g e

Date: 8 September, 2016
Use Case Name: check room
Iteration: Filled.
Summary: The employee or head of department checks the available rooms to set a
meeting schedule.
Basic Course of Events:
1. The employee logs in.
2. User is logged in.
3. Available room list is displayed.
Alternative Paths: none
Exception Paths: none
Extension Points: None
Trigger: The employee wants to view the details about the available rooms.
Assumptions: The room available list or status is present on the server.
Precondition: The user is logged in.
Post-condition: The list is viewed.
Author:
Date: 8 September, 2016
Use Case Name: book vacation.
Iteration: Filled.
Summary: The employee or head of department wants to book a vacation period.
Basic Course of Events:
1. The employee or head of department logs in
2. Fill the vacation form.
16 | P a g e

3. Request is sent to the head of department for approval.
Alternative Paths: none
Exception Paths: none
Extension Points: None
Trigger: The employee wants to login
Assumptions: The person is an employee of the company has a valid login id and
password.
Precondition: The user is logged in.
Post-condition: The vacation is either accepted or rejected.
Author:
Date: 8 September, 2016
17 | P a g e