REQUIREMENTS CAPTURE 1 ASU Course Registration System Use-case Model Actor

REQUIREMENTS CAPTURE 2 ASU — ACTORS At the beginning of each semester, students may request a course catalog containing a list of course offerings needed for the semester. Information about each course, such as instructor, department, and prerequisites are included to help students make informed decisions. The new system will allow students to select four course offerings for the coming semester. In addition, each student will indicate two alternative choices in case a course offering becomes filled or is canceled. No course offering will have more than ten students or fewer than three students. A course offering with fewer than three students will be canceled. Once the registration process is completed for a student, the registration system sends information to the billing system so the student can be billed for the semester. Professors must be able to access the online system to indicate which courses they will be teaching, and to see which students signed up for their course offerings. For each semester, there is a period of time that students can change their schedule. Students must be able to access the system during this time to add or drop courses.

REQUIREMENTS CAPTURE 3 ASU — ACTORS AND FUNCTIONAL REQUIREMENTS A person who is registered to take classes at the university.. An external system responsible for billing students. A person who is part of the teaching staff of the university.. Billing SystemStudentProfessor

REQUIREMENTS CAPTURE 4 ASU: USE-CASE MODEL SO FAR

REQUIREMENTS CAPTURE 5 ASU Course Registration System Use-case Model Use-case

REQUIREMENTS CAPTURE 6 ASU: USE CASES At the beginning of each semester, students may request a course catalogue containing a list of course offerings needed for the semester. functionality: Someone – prepare course catalogue Information about each course, such as instructor, department, and prerequisites are included to help students make informed decisions. functionality: Part of prepare course catalogue functionality. The new system will allow students to select four course offerings for the coming semester. functionality: Student – select course offering In addition, each student will indicate two alternative choices in case a course offering becomes filled or is canceled. functionality: Same as select course offering functionality.

REQUIREMENTS CAPTURE 7 ASU: USE CASES No course offering will have more than forty students or fewer than ten students. functionality: None (This is mainly a domain model requirement.) A course offering with fewer than ten students will be canceled functionality: Someone – cancel course offering Once the registration process is completed for a student, the registration system sends information to the billing system so the student can be billed for the semester. functionality: Someone – prepare billing information for Billing system Professors must be able to access the online system to indicate which courses they will be teaching, and to see which students signed up for their course offerings. functionality: Professor – select courses to teach Professor – request enrollment list

REQUIREMENTS CAPTURE 8 ASU: USE CASES For each semester, there is a period of time that students can change their schedule. functionality: Student – change course offering Students must be able to access the system during this time to add or drop courses. functionality: Student – add course offering Student – drop course offering

REQUIREMENTS CAPTURE 9 ASU — ACTORS AND FUNCTIONAL REQUIREMENTS A person who is responsible for maintaining the curriculum information inclusive of students, professors and courses. The Registrar uses the Registration System to prepare the course catalogue for the coming semester. A person who is registered to take classes at the university. A student uses the Registration System to register for courses in the current or a future semester. An external system responsible for billing students. Once a student successfully registers for a semester, the billing system is notified with billing information from the Registration System. A person who is part of the teaching staff of the university. A professor uses the Registration System to make choices on the courses to teach and to request course enrolment lists. Registrar Billing System Student Professor

REQUIREMENTS CAPTURE 10 ASU:USE CASES — FUNCTIONALIITY ANALYSIS & GROUPING

REQUIREMENTS CAPTURE 11 ASU — USE CASES Register for courses StudentBilling SystemProfessor Request enrollment listSelect courses to teach Registrar Maintain course informationPrepare course catalogueMaintain student informationMaintain professor informationPrepare billing information Time «communication» association (implicit)

REQUIREMENTS CAPTURE 12 ASU — USE-CASE SPECIFICATION Register for courses This use case describes the process of how a student registers for a course offering. It provides the capability to create and modify a student’s study schedule for the coming semester. Initial Flow of Events 1.The Student studies the course offerings for a semester to determine which courses to select. 2.The Student indicates her primary choice of courses, up to a maximum of four. 3.The Student indicates her alternate choice of courses, up to a maximum of two. 4.The student can add or drop courses from their schedule until the end of the add/drop period.

REQUIREMENTS CAPTURE 13 ASU — USE-CASE SPECIFICATION Select courses to teach This use case describes how a professor can select courses to teach for a desired semester that has not started yet. Initial Flow of Events 1.The Professor selects a course offering for a semester. 2.The Professor either adds or deletes himself as the instructor for the course offering.

REQUIREMENTS CAPTURE 14 ASU Course Registration System Use-case Detail Flow of Events Specification

REQUIREMENTS CAPTURE 15 ASU — USE-CASE DETAIL SPECIFICATIION (STYLE 1) Select courses to teach This use case describes how a professor can select courses to teach for a desired semester that has not yet started. Actors Invoked by: Professor Flow of Events Basic Path 1. The use case starts when the professor selects the option Select courses to teach. 2. The system displays the interface for selecting courses to teach. 3. The professor enters the semester and year in which he would like to teach courses. (E1: Invalid semester) 4. While the professor has an activity to perform 4.1. If the CREATE activity is selected (E2: Schedule exists) The system checks that the final date for changes has not passed. (E4: Change date passed) The system retrieves and displays the available course information for the given semester The professor selects the courses that he would like to teach The professor confirms the selection. (A1: Cancel activity)

REQUIREMENTS CAPTURE The system creates the professors teaching schedule in the database The system notifies the professor that the request has been processed If the REVIEW activity is selected (E3: No section selected) The system retrieves and displays the professors teaching schedule If the MODIFY activity is selected (E3: No section selected) The system checks that the final date for changes has not passed. (E4: Change date passed) The system retrieves and displays the professors teaching schedule and the available course information for the given semester While the professor wants to add a course The professor indicates which further section to teach The system displays the updated teaching schedule for the given semester While the professor wants to delete a course The professor indicates which section not to teach The system displays the updated teaching schedule for the given semester The professor confirms the changes. (A1: Cancel activity) The system updates the professor’s teaching schedule in the database The system notifies the professor that the request has been processed. 5. The use case ends.

REQUIREMENTS CAPTURE 17 Exceptional Paths E1: Invalid semester If the semester or year that is entered is invalid, no desired activity will be performed and the system will prompt the professor to re-enter a valid semester or year or terminate the use case. E2: Schedule exists If an attempt is made to create a teaching schedule for a semester where a schedule already exists, the system will prompt for another choice to be made. E3: No section selected If the professor has not selected any sections of courses to teach in the given semester, the system will notify him that this function is not available to him currently and prompt him to re-enter a valid semester and year or terminate the use case. E4: Change date passed If the final date for changes has passed, the system will reject the request and the use case ends. Alternate Paths A1: Cancel activity The professor can cancel the process at any time before the confirmation.

REQUIREMENTS CAPTURE 18 ASU — USE-CASE DETAIL SPECIFICATIION (STYLE II) Select courses to teach This use case describes how a professor can select courses to teach for a desired semester that has not yet started. Actors Invoked by: Professor Flow of Events Basic Path 1. The use case starts when the professor selects the option Select courses to teach. 2. The system displays the interface for selecting courses to teach. 3. The professor enters the semester and year in which he would like to teach courses. (E1: Invalid semester) 4. While the professor has an activity to perform 4.1. If the CREATE activity is selected (E2: Schedule exists) The S1: Create a schedule subflow is performed If the REVIEW activity is selected (E3: No section selected) The system retrieves and displays the professors teaching schedule If the MODIFY activity is selected (E3: No section selected) The S2: Modify a schedule subflow is performed. 5. The use case ends.

REQUIREMENTS CAPTURE 19 Subflows S1: Create a schedule 1. The system checks that the final date for changes has not passed. (E4: Change date passed) 2. The system retrieves and displays the available course information for the given semester. 3. The professor selects the courses that he would like to teach. 4. The professor confirms the selection. (A1: Cancel activity) 5. The system creates the professors teaching schedule in the database. 6. The system notifies the professor that the request has been processed.

REQUIREMENTS CAPTURE 20 S2: Modify a schedule 1. The system checks that the final date for changes has not passed. (E4: Change date passed) 2. The system retrieves and displays the professors teaching schedule and the available course information for the given semester. 3. While the professor wants to add a course 3.1. The professor indicates which further section to teach The system displays the updated teaching schedule for the given semester. 4. While the professor wants to delete a course 4.1. The professor indicates which section not to teach The system displays the updated teaching schedule for the given semester. 5. The professor confirms the changes. (A1: Cancel activity) 6. The system updates the professors teaching schedule in the database. 7. The system notifies the professor that the request has been processed.

REQUIREMENTS CAPTURE 21 Exceptional Paths E1: Invalid semester If the semester or year that is entered is invalid, no desired activity will be performed and the system will prompt the professor to re-enter a valid semester or year or terminate the use case. E2: Schedule exists If an attempt is made to create a teaching schedule for a semester where a schedule already exists, the system will prompt for another choice to be made. E3: No section selected If the professor has not selected any sections of courses to teach in the given semester, the system will notify him that this function is not available to him currently and prompt him to re-enter a valid semester and year or terminate the use case. E4: Change date passed If the final date for changes has passed, the system will reject the request and the use case ends. Alternate Paths A1: Cancel activity The professor can cancel the process at any time before the confirmation.

REQUIREMENTS CAPTURE 22 ASU Course Registration System Use-case Detail Include Relationship

REQUIREMENTS CAPTURE 23 Validate person information Basic Path 1.The use case starts when the flow of control is passed from the Maintain professor information or Maintain student information use cases. 2.The surname of the person is validated to be non-null and to contain ASCII characters only.. 4.The system checks the correctness of the entered information. 5. The system … ASU — USE-CASE DETAIL: INCLUDE Add a new student subflow of Maintain student information Basic Path 1.The system loads a blank student information form onto the screen. 2.The user fills in the student information inclusive of student ID. 3.The user confirms the entered information. 4.Include(Validate person information). 5.The system checks the correctness of the entered student-specific information. 6.The system...

REQUIREMENTS CAPTURE 24 ASU Course Registration System Use-case Detail Extend Relationship

REQUIREMENTS CAPTURE 25 Select courses to teach Basic Path 1.The use case starts when the professor selects the option Select courses to teach. 2.The system prompts the professor to enter the semester in which he would like to teach courses. (A1) 3.The system... ASU — USE-CASE DETAIL: EXTEND Invalid semester Basic Path 1.This use case is initiated when an invalid semester is entered. 2.The system will prompt the professor to re-enter a valid semester or terminate the use case.  an extension requires a condition to be evaluated to determine whether to execute it Select courses to teach Basic Path 1.The use case starts when the professor selects the option Select courses to teach. 2.The system prompts the professor to enter the semester in which he would like to teach courses. 3.The system... This is the condition that is tested.