MEETING ENGAGEMENT AND TRACKING SYSTEM

Question: MEETING ENGAGEMENT AND TRACKING SYSTEM

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. 
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. 
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 the head of departments. 
3. Screen to display schedules will be provided.
4. A 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 a 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 the 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.
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.
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
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.
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. 
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.
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
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.
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. 
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: 
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.
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

Place Order For A Top Grade Assignment Now

We have some amazing discount offers running for the students

Place Your Order

Get Quality Assignment Without Paying Upfront

Hire World's #1 Assignment Help Company

Place Your Order