Meeting Engagement and Tracking System (MEAT App) SRS Document

The provided document is a Software Requirements Specification (SRS) for the 'MEAT' application, an online meeting management system designed to enhance employee engagement and streamline meeting scheduling. The SRS outlines the application's purpose, scope, and benefits, including features like room booking, schedule management, and reminder functionalities. It details the product perspective, encompassing user interfaces, hardware and software interfaces, and memory constraints. Furthermore, the document specifies functional and performance requirements, design constraints, and other considerations such as security, maintainability, and portability. The SRS also includes use case diagrams and descriptions to illustrate the system's functionality, such as scheduling meetings, user login, and editing schedules. The document is intended to provide a comprehensive overview for developers to guide the design and implementation of the MEAT application.

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