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.

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

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

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

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

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

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

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

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

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

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

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

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

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