System Specification Report for Timetable Scheduler.

1. 1
1. Introduction
1.1 Purpose
The purpose of this document is to present a detailed description of our Scheduler
Application. It will explain the purpose and features of the system, the interfaces of the
system, what the system will do, the constraints under which it must operate and how the
system will react to external stimuli. This document is intended for both the clientele and
the developers of the system and will be proposed to the SDMCET CSE Mini Project
Review Committee for its approval.
Term Definition
Use Case List of steps defining interactions between
actor and system
Actor ( Administrator, Faculty, Student) Role that interacts with the system to
achieve a goal
Use Case Diagram Graphic of the interactions among the
elements of a system
User Someone who interacts with the application
1.1.1 Conventions used in Use Case Diagram
Symbol Meaning
Use Case
Actor

2. 2
1.2 Project Scope
This software system is an automated system which generates time-table according to the data
given by the user. The main requirement of the application is to provide the details to the
students about their branch, subjects, number of labs, total number of periods and details about
any changes made in the routine. The web end allows the user to input data and the application
end along with the web end allows the people to access their time table and get the notification if
any changes made. Scheduler will help the teachers to change the routine and update the notice
board according to their convenience, and students to get the notification of the same. This
project will provide a better platform for students-teachers interaction.
1.3 References
1. Elmasari and Navathe, “Fundamentals of Database Systems”, Fifth Edition, Pearson, 2007.
2. Reto Meier, “Android 4 Application Development”, 1st Edition, John Wiley & Sons, 2014.
2. System Description
This section will give an overview of the whole project. The system will be explained in its
context to show how the system reacts with other external stimuli and introduce the basic
functionality of it. The system consists of three parts: Website, Database and Android app. In
this system, Administrator can create and maintain a time-table which can be later on, modified
by faculty and the changes are notified to the students through the Android app.
3. Functional Requirements
The functional requirements describe the core functionality of the application. This section
includes the functional process requirements, which are the basic requirements of the
application and a brief explanation of the specifics of those requirements.
3.1 System Features
The following are the features of the Scheduler Application

3. 3
3.1.1 Timetable Creation
Administrator can create and maintain the timetable, which is accessible to faculty and student.
3.1.2 Timetable modification
Faculty can modify the working schedule according to available free timeslots or while not free
on the mention timeslots according to timetable.
3.1.3 Viewing timetable
Student can view timetable and get notified on any changes on the present schedule, modified by
faculty according to his ease of engaging the class.
3.2 Use Cases
3.2.1 Use Case Diagrams

4. 4
3.2.2 Use Case
Description Administrator can create timetable, that
can be modified by faculty which can be
notified to student by an Android app
Actors Administrator, Student, Faculty
Basic Steps 1. Admin will login to their account,
and input data.
2. Faculty can modify the present
timetable.
3. Student can view the updated
timetable.
3.2.3 Use-Case Description:
 Log-in ->Students need to log in using the username and password they have. This is registered
when they use the system for the first time.
 Add Subject ->Students can add subjects with regards to the subject suggestion by the Dean.
 Drop Subject -> Students can also drop the subjects, if unnecessary.
 View Timetable -> Students can view the timetable for the entire semester.
 Change Password ->Faculty also can change password, if necessary.

5. 5
4. PROJECT IMPLEMENTATION IN TERMS OF MODULES
1.
2.

6. 6
3.
4.
Fig. 2.3: Diagram of Project Implementation in terms of modules

7. 7
5. External Interface Requirements
 Android device with android o.s version 4.1 or higher.
 Webserver with proper domain.
6. Technical Requirements (Non-functional)
Non-functional requirements specify criteria that can be used to judge the operation of a
system, rather than specific behaviours .
a. Scalability
Since the application just demonstrates our proposed algorithm, this application can be used
on a much larger scale after developing the application further. The algorithm can also be
used on its own to develop other applications that can function on a much larger scale.
b. Supportability
The application shall require the installation of Java Runtime Environment on the user’s
system. The application shall allow additional tools to be added on the completion of the
minimum requirements.
c. Reliability
In a case of the application malfunctioning the user need not have to worry about the data
being lost or corrupted as it is always stored in a text document.
d. Availability
The basic version of the application shall be ready for use without any downtime, but the
algorithm can be used later on for more useful applications and therefore some downtime
can be expected for it.

8. 8
7. Open Issues
 This application is more suitable to input data into a timetable.
 This application is more suitable to modify or update a timetable.
 This application is more suitable to view an updated data or timetable changes.