1. A partially automated class scheduling system
4/15/2019
S P Pal, Jan 2002
A partially automated class scheduling system
This case study is adapted from Prof. Pankaj Jalote’s 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 . Options data will be put into a file. Other constraints’ data will also be available in files for the scheduling software.
4/15/2019
S P Pal, Jan 2002

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/15/2019
S P Pal, Jan 2002

4. DFD for the schedule process
UG courses
Separate
Schedule UG
PG courses
Courses
without
schedule
Schedule PG
Schedule
rest
Collected forms
4/15/2019
S P Pal, Jan 2002

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
4/15/2019
S P Pal, Jan 2002

6. DFD for the automated system
preferences_file
Conflict
Report
Instructors,
Secretary,
Chairman
Schedule
Send
Combine
Into
File
Schedule
Department_database
4/15/2019
S P Pal, Jan 2002

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
4/15/2019
S P Pal, Jan 2002

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:
4/15/2019
S P Pal, Jan 2002

9. SRS document (contd.)
1.5 Developer’s 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:
4/15/2019
S P Pal, Jan 2002

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.
4/15/2019
S P Pal, Jan 2002

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
4/15/2019
S P Pal, Jan 2002

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 !!!
4/15/2019
S P Pal, Jan 2002

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.
4/15/2019
S P Pal, Jan 2002

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
4/15/2019
S P Pal, Jan 2002