A partially automated class scheduling system

1
A partially automated class scheduling system

• This case study is adapted from Prof. Pankaj
  Jalotes book.

2
The overall objective

• Collect options from instructors
• Schedule as per constraints and options
• The manual process conducted by a secretary is to
  be partially automated. The acquisition of
  options will be done by email. Options data will
  be put into a file. Other constraints data will
  also be available in files for the scheduling
  software.

3
The scheduling software

• Scheduling satisfying class capacities and rooms
  allotments not clashing in time.
• Preferences must be scheduled by software in the
  order or submission by instructors.
• PG courses are scheduled before UG courses.
• Courses without preferences to be scheduled at
  the end.
• Output schedule must be stored in a file.
• Errors in preferences must be reported and no
  optimization of schedule is needed.

4
DFD for the schedule process
UG courses
Separate
Schedule UG
PG courses
Courses without schedule
Schedule PG
Schedule rest
Collected forms
5
Data dictionary

• collected_forms instructor_name course_name
  preferences
• schedule course_number class_room
  lecture_time
• in the new automated system, we call the
  collected_forms as preferences_file
• we also need a database of departmental
  information, called department_database
• the new data dictionary will be as follows

6
DFD for the automated system
preferences_file
Conflict Report
Instructors, Secretary, Chairman
Schedule
Send E-mail
Combine Into File
Schedule
Department_database
7
Data dictionary for automated system

• preferences_file preference
• preference course_number enrollment
  preferences
• department_database class_rooms
  dept_course_list valid_lecture_time
• class_rooms room_no capacity

8
The requirements specification document

• Abstract Scheduling courses given lecture
  times, classrooms, preferences and constraints of
  departmental resources.
• 1. Introduction
• 1.1 Purpose Describe all external requirements
  and interfaces for a course scheduling system.
• 1.2 Scope Agreement, validation of final system
  delivered, changes to be made with permission of
  client/customer/user.
• 1.3 Definitions Acronyms, Abbreviations.
• 1.4 References

9
SRS document (contd.)

• 1.5 Developers responsibilities overview
  developing, installing, user training,
  maintenance.
• 2. General description
• 2.1 Product function overview
• 2.2 User characteristics
• 2.3 General characteristics
• 2.4 General assumptions and dependencies

10
3. Functional requirements

• 3.1 General description of inputs and outputs
  Two files for input and two file for output.
• Input_file_1 List of room numbers with
  capacity List of all courses List of valid
  lecture times.
• Input_file_2 Information about courses being
  offered, specifying course number, expected
  enrollment and number of lecture time
  preferences.

11
Functional requirements (contd.)

• Output_1 Class numbers and time of all
  schedulable courses.
• Output_2 List of courses that could not be
  scheduled with reasons.
• 3.2 Functional requirements (detail)
• 1. Determine time and room number for courses
  such that
• 1.1 Only one course in one room at any time
• 1.2 Class capacity more than expected
  enrollment

12
Functional (contd.)

• 1.3 PG courses preferred over UG courses
• 1.4 Process courses in the order as in input and
  try all preferences in order. Erroneous
  priorities must be discarded and absence of
  priorities would allow freedom of choice.
• 1.5 No two PG courses must be scheduled at the
  same time !!!

13
Functional (contd.)

• 2. Courses with no preferences must be scheduled
  in any way, not contradicting above requirements.
• 3. Produce list of courses which could not be
  scheduled due to constraints, giving reasons
• 4. Check data in second input file against data
  in first input file. Messages for improper input
  data. Ignore invalid data items.

14
Functional (contd.)

• 3.3 Detailed input file format
• 3.4 Detailed output file format
• 4. External interface requirements
• 5. Performance constraints
• 6. Design constraints
• 7. Acceptance criteria