COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF SOFTWARE ENGINEERING

Software requirements specification for

Scheduling System

Version 1.0
Prepared by
Yohannes Lemma 0661/09
Abselam Nigatu 501/08
Haimanot Getu 0647/09
Abenezer Alemu 0637/09
Dawit Zenebe 0657/09
Abera Germama 0665/09
 Scheduling System

Contents
1. Introduction .............................................................................................................................................. 1
1.1 Purpose ............................................................................................................................................... 1
1.2 Scope................................................................................................................................................... 1
1.3 Overview............................................................................................................................................. 2
1.4 Reference Material............................................................................................................................. 3
1.5 Definitions and Acronyms .................................................................................................................. 3
2. SYSTEM OVERVIEW .................................................................................................................................. 4
3. SYSTEM ARCHITECTURE ........................................................................................................................... 7
3.1 Architectural Design ........................................................................................................................... 7
3.1.1 Component Description ...................................................................................................... 7
3.1.2 Logical View ........................................................................................................................ 8
3.1.3 Process view ......................................................................................................................... 9
3.1.4 Deployment view ............................................................................................................... 10
3.1.5 Development view ............................................................................................................. 10
3.1.6 Scenario .............................................................................................................................. 10
3.2 Decomposition Description ............................................................................................................. 11
3.1.7 Account Manager .............................................................................................................. 11
3.1.8 Create Department ........................................................................................................... 13
3.1.9 Registration Manager ....................................................................................................... 13
3.1.10 Schedule Generator........................................................................................................... 15
3.1.11 Control Schedule ............................................................................................................... 16
3.2 Design Rationale............................................................................................................................... 17
4.DATA DESIGN........................................................................................................................................... 18
4.1 Data Description ............................................................................................................................... 18
4.2 Data Dictionary................................................................................................................................. 18
5.COMPONENT DESIGN.............................................................................................................................. 21
5.1 Class Diagram ................................................................................................................................... 21
5.2 Object Diagram................................................................................................................................. 22
5.3 Activity Diagram ............................................................................................................................... 23
5.4 Sequence Diagram............................................................................................................................ 26
6. HUMAN INTERFACE DESIGN .................................................................................................................. 31
6.1 Overview of User Interface ............................................................................................................ 31
 Scheduling System

6.2 Screen Images................................................................................................................................... 32

List of Figures

Figure 2 1 Client Server Architecture ............................................................................................. 5

Figure 2 2 spiral model for the SDLC ............................................................................................... 5
Figure 2 3Architecture of Spiral model .......................................................................................... 6
figure 3. 1 process view Diagram .................................................................................................... 9
figure 3. 2 Deployment view Diagram .......................................................................................... 10
Figure 5. 1 Class diagram for Scheduling System ......................................................................... 21
Figure 5. 2 Object diagram for Scheduling System ....................................................................... 22
Figure 5. 3 Activity Diagram for Admin ......................................................................................... 23
Figure 5. 4 Activity Diagram for Batch Management ................................................................... 25
Figure 5. 5 Sequence Diagram for Admin ..................................................................................... 26
Figure 5. 6 Sequence Diagram for Department Head Instructor Management ........................... 27
Figure 5. 7 Sequence Diagram for Department Head Room Management ................................. 28
Figure 5. 8 Sequence Diagram for Department Head Batch Management ................................. 29
Figure 5. 9 Sequence Diagram for Instructor................................................................................ 30
 Scheduling System

1. Introduction
1.1 Purpose
This document is provided to explain about software requirements specification of scheduling
system and is the first version. The document describes about overview of the system being
developed, scope of the project, objectives and goals of the project, functional and non-
functional requirements of the system, references used in this document and other necessary
things are included.

For system developers there is use case diagram that help them to understand the system
functionality using standard UML diagram. The sections are divided based on the IEEE template
and there is a table that use to illustrate the meaning of the use case so, you can see that for better
understanding of the use case or about the system functionality. Because there is information in
the document that are relevant for validation and verification of the system, which is the job of
tester, so the testers can also be benefited from this document.

1.2 Scope
Haramaya University has more than nine colleges and under these colleges there are many
departments. All departments have their own class schedule based on the resource they have like
classrooms and human power. The scope of our project to automate the scheduling system for all
colleges in Haramaya University.

Our project scope is further limited to:

➢ Accept courses information (course name, credit hours, instructor name, etc.)
➢ Record all available resources like buildings, rooms, labs, instructors, sections, etc.
➢ Update the prepared schedule without overlapping.
➢ Make class scheduling within algorithm.
➢ Easily search and print the information.

Goal
For an organization to be successful in its activities the need for well-structured system and placing
the right schedule in the right time is necessary. So, doing this manually, it makes difficult to
accomplish tasks easily and effectively. So, we have identified the existing system and got the
main problems which exist in the colleges. The main problem of this college is lack of an
automated scheduling system. Our main goal is to make an automated scheduling system and to
overcome this problem.

1|Page
 Scheduling System

Objectives
General Objective
The general objective of our project is to develop an automated scheduling system for all
Departments in Haramaya University.

Specific objective
➢ To generate class schedule: - specifically our system develops automated schedule.
➢ To update and delete course, instructor, information: - this done by Department Head.
➢ To secure data of the Department: -this system gives some privileges for authorized users to get it.
➢ To manage the information in database: -all information like admin, available room and time table
in database can be added, updated, deleted and printed.

Benefits
- It will minimize the time wasted on scheduling.
- There wouldn’t be any overlapping schedules.
- all users of the program can participate and interact with the system.
- The users can also get the information simply.

The project has many Benefits for us and for the users of the systems. The team members will get
the knowledge and experience on how to develop and design a new system. The students will get
automate scheduling system online and others can use the new system for future automation of
other colleges of the university.

1.3 Overview
The remaining of this document is organized as follows;

The remaining chapters and their contents are listed below.

Section 2 deals about the software architecture where the architecture of the software under
discussion will be presented using diagrams that illustrates what architecture we use and SDLC.
Section 3 gives detail information about the architecture and architecture design of the system.
Section 4 gives detail information on how our data is designed and organized.
Section 5 specification for an Adaptable Component that can be used to construct a draft
application work product.
Section 6 Describe the functionality of the system from the user’s perspective.
Section 7 Provide a cross reference that traces components and data structures to the
requirements in your SRS document.

2|Page
 Scheduling System

Section 8 : Add any important document in your design which you feel the design template has
not allowed you to put it in place.

1.4 Reference Material

http://www.ieee.org
http://www.lucidchart.com
Boehm, B, "Spiral Development: Experience, Principles, and Refinements", Special Report CMU/SEI-2000-
SR-008, July 2000

1.5 Definitions and Acronyms

We use some abbreviation and acronyms to simplify the process of reading and writing this
document and they are listed below:

Acronyms Definition
HTTP Hypertext Transfer Protocol
HU Haramaya University
IEEE Institute of Electrical and Electronics
Engineering
RESTful Representational State Transfer
SDLC Software Development Life Cycle
SRS Software Requirements Specification
UC Use Case
UML Unified Modelling Language

3|Page
 Scheduling System

2. SYSTEM OVERVIEW

For an organization to be successful in its activities the need for well-structured system and placing
the right schedule in the right time is necessary. So doing this manually, it makes difficult to
accomplish tasks easily and effectively. So, we have identified the existing system and got the
main problems which exist in the college of computing and informatics.
The main problem of this college is lack of an automated scheduling system. This leads to the
following problems:

- Time consuming: - wasting time occurs when scheduler arrange timetable using manual
system. They be careful in arrange the time table to decrease the mistake probability, so
they need a lot of time to arrange the time table.
- Lack of Information distribution method: - The information distribution method is very
slow. Since information transformation is paper based. The prepared schedule didn’t reach
at right time to the student as well as to the Instructor, also they didn’t gate everywhere
they want. Also, the distributed information is inefficient.
- It is difficult to update: -to update only one entry of the table you must change schedule
that you print before. This needs to replace the original paper by the new updated one this
consume additional resource and assign additional work for the person who post the
schedule on the board and give for the instructors.
- There are clash of class schedule: - there are class overlapping problem.

We are building a system that can automate the manual way of arranging schedules here in
Haramaya university. The system will have input from the college dean and department head and
will take care of all the arranging of the schedules by itself.
Functionality of the system: -
• 1. All text contained in this document is 12pt Times New Roman font.
• The system provides scheduling system to all Colleges in HU.
• The system shows the schedule for all students and Staffs (Collage Dean, Registrar
Officer, Department Head etc.)
• The system provides scheduling for class .

We are using the client/server architecture for implementing the system.

Client Server Architecture is a computing model in which the server hosts, delivers and
manages most of the resources and services to be consumed by the client. This type of
architecture has one or more client computers connected to a central server over a network or
internet connection. This system shares computing resources. Client/server architecture is also

4|Page
 Scheduling System

known as a networking computing model or client/server network because all the requests and
services are delivered over a network.

Figure 2 1 Client Server Architecture

Three-tier Client Server Architecture

The traditional client/server architecture involves two levels, a client level and a server level.
Another common design of client/server system uses three tiers:

- A client that interacts with the user

- An application server that contains the business logic of the application
- A resource manager that stores data

Figure 2 2 spiral model for the SDLC

5|Page
 Scheduling System

The spiral model is a risk-driven software development process model. Based on the unique risk
patterns of a given project, the spiral model guides a team to adopt elements of one or more
process models, such as incremental, waterfall, or evolutionary prototyping.
These early papers use the term "process model" to refer to the spiral model as well as to
incremental, waterfall, prototyping, and other approaches. However, the spiral model's
characteristic risk-driven blending of other process models' features is already present:
Risk-driven sub setting of the spiral model steps allows the model to accommodate any
appropriate mixture of a specification-oriented, prototype-oriented, simulation-oriented,
automatic transformation-oriented, or other approach to software development.
Advantages of Spiral model:
- High amount of risk analysis hence, avoidance of Risk is enhanced.
- Good for large and mission-critical projects.
- Strong approval and documentation control.
- Additional Functionality can be added at a later date.
- Software is produced early in the software life cycle.

.
Figure 2 3Architecture of Spiral model

6|Page
 Scheduling System

3. SYSTEM ARCHITECTURE
In this section the brief explanation of Scheduling System is described and presented within the
architectural diagram and brief explanation of design rationale.

3.1 Architectural Design

As the main objective of this system is giving it’s a clear and concise schedule by avoiding overlaps
between schedules. And it automates the manual way of scheduling by using a scheduling
algorithm which we’ll build from scratch.

The following components are the main building blocks of the system.

• Account Manager
• Create Department
• Registration Manager
• Schedule Generator
• Control Schedule

3.1.1 Component Description

• Account Manager: - this component is responsible for creating account for the
Department Head and for the Instructors and manages their profiles.
• Create Department: - this component is responsible for creating department by explicitly
defining the name of the Department and the ID of the Head.
• Registration Manager: - this component is responsible for registering all the necessary
data for the scheduling algorithm in order to generate the schedule. (i.e. Room, Batch,
Instructor and Course).
• Schedule Generator: - this component is responsible for generating the schedule by
requesting all the necessary data from the database which is added through the
registration manager.
• Control Schedule: - this component is responsible for editing the generated schedule
through the algorithm incase there is TBA and if there is reported issue from the
instructors.

7|Page
 Scheduling System

Figure 3.1 The Architectural designs.

The above diagram represents the overall diagram of the proposed system. Furthermore, the
architecture of the proposed system will be broken down using the 4+1Architectural Model.

3.1.2 Logical View

The User of this system will have the following functionalities from the system as described by
the following logical view diagram which will be implemented in the system.

Functionalities that the system will provides are: -

• The admin creates account for the Department Head.

• The admin can perform create, read, update, delete Departments.
• The Department Head creates Instructor accounts.
• The Department Head can perform create, read, update, delete Rooms.
• The Department Head can perform create, read, update, delete Batches.
• The Department Head can perform create, read, update, delete Courses.
• The Department Head can edit the generated schedule if necessary.
• The System generates schedule.

8|Page
 Scheduling System

• Anybody can see the generated schedule.

• Anybody who have an account have the permission to edit his/her profile.
• Instructors can report issues with the schedule.

Figure 3.2 logical view Diagram

3.1.3 Process view

In this view we try to describe the flow of activities which are mainly can be done by this
application.

figure 3. 1 process view Diagram

9|Page
 Scheduling System

3.1.4 Deployment view

The deployment view of Scheduling system is used to describe which components are deployed
on which device or hardware while deployment of the software is taken places.The components
of Scheduling system placed on the different device that request one to another.

figure 3. 2 Deployment view Diagram

3.1.5 Development view

This is a view of a system’s architecture that encompasses the components used to assemble
and release a physical system. This view focuses on configuration management and actual
software module organization in the development environment. The software is actually
packaged into components that can be developed and tested by the development team.

3.1.6 Scenario
We try to take as scenario registration manager component from the components. When the
Admin want to create account for the Department Head and create the department or when
Department Head wants to manage registration of information’s needed for the schedule
activity like Room information, Instructor information, Course Information and Batch
information the registration manager component displays automatically the action that has
been performed.

10 | P a g e
 Scheduling System

3.2 Decomposition Description

3.2.1 Account Manager

Identification Account Manager

Type Module

Purpose Manage accounts for every user.

Function This component is responsible for creating account for the

Department Head and for the Instructors and manages their
profiles.
Subordinates This component is mainly composed of:-

- Edit Account: - this will allow different roles to

change their account info.
- Change Password: - this will different roles to
change their password.

Dependencies - If the account that is being managed is the admins

their wouldn’t be any dependencies.
- But if the account being managed is the department
heads, it would have the dependency from the admin.
- And also if the account being managed is the
teachers, it would have the dependency from the
Department Head.

Interfaces The Account Manager component has main interfaces such

as:-

• User Controller: - for adding, editing, deleting user

accounts.

Resources Express Framework, MongoDB,

11 | P a g e
 Scheduling System

Processing This component manages like creating, editing, deleting the

accounts for different roles
Data This component records all data related to account of roles
like username, password, email, full name, and role.
Identification Create Department

Type Module

Purpose To add Department data to the system.

Function This component is responsible for creating department by

explicitly defining the name of the Department and the ID
of the Head.
Subordinates This component is mainly composed of:-
- It lets the admin to select only filtered department
heads from the users list

Dependencies - Before creating department, Department Head should

be added to the users as head role.

Interfaces Create Department component has interface like :-

• Department Controller: - for adding, editing,
deleting departments.

Resources Express Framework, MongoDB,

Processing This component manages like creating, editing, deleting

department.
Data This component records all data related to creating and
managing department data.

12 | P a g e
 Scheduling System

3.2.2 Create Department

Identification Create Department

Type Module

Purpose To create Department by defining their name and using ID

of the Department Head
Function This component is responsible for registering all the
necessary data for the Department itself.
Subordinates This component is mainly composed of:-
- Create Department:- create Department by defining
their name and using ID of the Department Head.

Dependencies - There should be pre-added Department Head.

Interfaces Registration Manager component has interface like :-

• Create department: - for adding new department.

Resources Express Framework, MongoDB,

Processing This component is used to create the departments found in

the university.
Data This component records all data related to creating
department data.

3.2.3 Registration Manager

Identification Registration Manager

Type Module

Purpose To manage resources like (i.e. Room, Batch, Instructor and

Course)

13 | P a g e
 Scheduling System

Function This component is responsible for registering all the

necessary data for the scheduling algorithm in order to
generate the schedule. (I.e. Room, Batch, Instructor and
Course).
Subordinates This component is mainly composed of:-
- Manage Room:- adding, updating and deleting of
rooms
- Manage Batch:- adding, updating and deleting of
batches
- Manage Course:- adding, updating and deleting of
courses

Dependencies - For adding room, batch, course the department needs

to be created first because they are assigned to a
particular department.
- For adding a batch there should be pre added room
because a batch needs a couple of rooms.

Interfaces Register Manager component has interface like :-

• Room Controller: - for adding, editing, deleting
rooms.
• Batch Controller: - for adding, editing, deleting
batches.
• Course Controller: - for adding, editing, deleting
courses.

Resources Express Framework, MongoDB,

Processing This component manages like creating, editing, deleting of

room, batch and course resources.

14 | P a g e
 Scheduling System

3.2.4 Schedule Generator

Identification Schedule Generator

Type Module

Purpose To generate schedule based on the data specified.

Function This component is responsible for generating schedule for

every department and every batch by considering room and
instructor overlaps. It creates a schedule without overlaps.
Subordinates This component is mainly composed of:-
- Scheduler: - by requesting necessary data from the
database it generates schedule.

Dependencies In order to start generating the schedule all the necessary data
should be stored on the database. This means that is the
should be the last thing to do after inserting a lot of data.

Interfaces Schedule Generator component has interface like :-

• Schedule Generator : - this is the gateway for
starting the schedule

Resources Express Framework, MongoDB,

Processing This component will fetch all the data from the database
and generates schedule
Data This component will use all the necessary data from the DB
like rooms, instructors, batches and courses.

15 | P a g e
 Scheduling System

3.2.5 Control Schedule

Identification Control Schedule

Type Module

Purpose To edit and view the generated schedule

Function This component is responsible for editing the generated

schedule through the algorithm in case there is TBA and if
there is reported issue from the instructors.
Subordinates This component is mainly composed of:-
- View Schedule: - for viewing the generated
schedules
- Edit Schedule: - for editing the generated schedule
in case something needs to be changed.

Dependencies In order to control the schedule the schedule should be

generated first.

Interfaces Schedule Generator component has interface like :-

• Schedule Controller: - this is the controller that
retrieves the schedule and makes it ready for editing.

Resources Express Framework, MongoDB,

Processing This component is for processing retrieving and editing the

generated schedule.
Data The data if fetched from the generated schedule.

16 | P a g e
 Scheduling System

3.3 Design Rationale

The fact that our system is not that much complex it doesn’t force us a lot of architecture. All
we’ve used is layered architecture and MVC Architectural Pattern. But the way the code
organized will be always open for easily modification.
Some used architectures and architectural patterns are:-
MVC (Model View Controller): this is an architectural pattern that makes the righting code is as
it separates different parts of the application which is responsible for one thing. So this
way codes won’t mix up.
Layered architecture: this is architecture that separates the client from the server. These
architectures separates four different part of the application which are User Interface Layer,
Application Layer, Data Layer and Core (infrastructure) Layer.
- User Interface Layer: this layer is for building the UI components that the user sees.
- Application Layer: - this layer is for building the CRUD operations which are create, read,
update and delete of resources in the application.
- Data Layer: - this layer is for building the database and data related tasks.
- Core Layer: - this layer if for the scheduling algorithm
Some proposed but not implemented architectures are: -
Micro service architecture
- The reason we consider using this architecture is that it makes testing, maintaining and
building services easy.
- The reason we haven’t implemented the system using micro service architecture is that
introducing such complex architecture to small application will overusing it and the use
wouldn’t be that visible.

17 | P a g e
 Scheduling System

4.DATA DESIGN
In this section we are going to describe Data Design, Data design is the first design activity,
which results in less complex, modular and efficient program structure.
The information domain model developed during analysis phase is transformed into data
structures needed for implementing the software.
During the data design process, data types are specified along with the integrity rules required for
the data. For specifying and designing efficient data structures, some principles should be
followed.

4.1 Data Description

Our system follows component-based architecture, we select MongoDB to store data. In this
architecture you can use one or more than one database but we select one database it controls all
the system components.

4.2 Data Dictionary

Our database contains 8 table

1. User
2. Batch
3. Course
4. Department
5. Room
6. Teacher
7. Semester
8. Schedule

Table for User

Database Table Attributes Type Description

Scheduling-app User ID ObjectID This table is
username String responsible for
password String storing Admin,
email String Head and Teacher
fullName String data.
role String

18 | P a g e
 Scheduling System

Table for Department

Database Table Attributes Type Description

Scheduling-app Department ID ObjectID This table is
name String responsible for
head ObjectID storing Departments
teachers [ObjectID] data
rooms [ObjectID]
batches [ObjectID]

Table for Teacher

Database Table Attributes Type Description

Scheduling-app Teacher ID ObjectID This table is
name String responsible for
department ObjectID storing teachers data

Table for Rooms

Database Table Attributes Type Description

Scheduling-app Room ID ObjectID This table is
name String responsible for
isLab Boolean storing rooms data
department ObjectID

Table for Batch

Database Table Attributes Type Description

Scheduling-app Batch ID ObjectID
department String

19 | P a g e
 Scheduling System

classRoom ObjectID This table is

labRoom ObjectID responsible for
semesters [ObjectID] storing batches data

Table for Semester

Database Table Attributes Type Description

Scheduling-app Semester ID ObjectID This table is
name String responsible for
batch ObjectID storing semesters
courses [ObjectID] data

Table for Course

Database Table Attributes Type Description

Scheduling-app Course ID ObjectID This table is
name String responsible for
code String storing Courses data
totalCreditHours Number
labCreditHours Number
semesters [ObjectID]
teacher ObjectID

20 | P a g e
 Scheduling System

5.COMPONENT DESIGN
5.1 Class Diagram

Figure 5. 1 Class diagram for Scheduling System

21 | P a g e
 Scheduling System

5.2 Object Diagram

Figure 5. 2 Object diagram for Scheduling System

22 | P a g e
 Scheduling System

5.3 Activity Diagram

Admin

Figure 5. 3 Activity Diagram for Admin

23 | P a g e
 Scheduling System

Room management

Figure 5.2 Activity Diagram for Room Management

24 | P a g e
 Scheduling System

Batch management

Figure 5. 4 Activity Diagram for Batch Management

25 | P a g e
 Scheduling System

5.4 Sequence Diagram

Admin

Figure 5. 5 Sequence Diagram for Admin

26 | P a g e
 Scheduling System

Department Head Instructor management

Figure 5. 6 Sequence Diagram for Department Head Instructor Management

27 | P a g e
 Scheduling System

Department Head Room management

Figure 5. 7 Sequence Diagram for Department Head Room Management

28 | P a g e
 Scheduling System

Department Head Batch management

Figure 5. 8 Sequence Diagram for Department Head Batch Management

29 | P a g e
 Scheduling System

Instructor

Figure 5. 9 Sequence Diagram for Instructor

30 | P a g e
 Scheduling System

6. HUMAN INTERFACE DESIGN

6.1 Overview of User Interface
User first get into the website or gets in to the landing page of the website, from that page
the user can see some options. If the user has already been registered, he/she can login by
using his/her user name and password from the landing page to his account, or the user can
directly see the generated schedule according to department and batch without needing an
account.

To view the generated schedule the user clicks on view schedule button presented on the
home page, then he/she will be provided to chose department, which will lead us to the last
step choosing batch, then the system will automatically display the schedule requested.

User can login according to his specific rolls. An Admin, Department Head or Instructor.
After logging in to his account, an admin can add users by creating accounts for department
heads and can edit profiles and add departments by using the form provided. The
Department heads added by the admin perform most of the tasks. Department Heads
perform CRUD operations creating and managing account for instructors, adding and
managing rooms, courses, and batches. Department Heads can edit the generated schedule
when necessary. Instructor accounts can report when they encounter a problem by clicking
the report problem button.

31 | P a g e
 Scheduling System

6.2 Screen Images

LogIn Page

Admin Page

32 | P a g e
 Scheduling System

Admin Head Controller

Admin Department Controller

33 | P a g e
 Scheduling System

Department Head Home Page

Department Head Teacher Manager Page

34 | P a g e
 Scheduling System

Department Head Room Manager Page

Department Head Batch Manager Page

35 | P a g e
 Scheduling System

Department Head Profile Edit Page

6.3 Screen Objects and Actions

• Buttons - Clickable boxes that allow data manipulation and screen changes.
• Text Boxes - Allows user to input any Alphas-numeric characters in order to search for
items and change information.
• Radio Buttons - Circular buttons that allow a single item in a group to be selected.
• Spinner - Generated drop down list of defined items that allow one to be selected.

36 | P a g e
 Scheduling System

7 REQUIREMENTS MATRIX
This provides short descriptions about system components and their functional requirements.
The following components are the main building blocks of our system.

• Account Manager
• Create Department
• Registration Manager
• Schedule Generator
• Control Schedule

System Components Functional Requirements Identifier

- This component is responsible - SCSAM08
Account Manager for creating account for the
Department Head and for the
Instructors and manages their
profiles.
- This component is responsible - SCSCD016
for registering all the
Create Department
necessary data for the
Department itself.
- This component is - SCSRM30
responsible for registering all
the necessary data for the
Registration Manager
scheduling algorithm in order
to generate the schedule. (I.e.
Room, Batch, Instructor and
Course).
Schedule Generator This component is responsible for - SCSSG02
generating schedule for every
department and every batch by

37 | P a g e
 Scheduling System

considering room and instructor

overlaps. It creates a schedule
without overlaps.
This component is responsible for - SCSCS26
editing the generated schedule
through the algorithm in case
there is TBA and if there is
reported issue from the
Control Schedule
instructors.

38 | P a g e