I.

Functional Requirements (What the system should DO):

A. Student-Related Functions:

1. Student Registration:
o The system should allow new students to register by providing necessary personal
details (e.g., name, address, contact information, date of birth, program of study).
o The system should validate the entered information to ensure accuracy and
completeness.
o The system should generate a unique student ID for each registered student.
o The system should securely store student information.
2. Student Login:
o The system should allow registered students to log in securely using their student
ID and password.
o The system should provide a "forgot password" mechanism.
3. Course Catalog Browsing:
o The system should display a comprehensive and up-to-date list of available
courses.
o Students should be able to filter and search courses based on various criteria (e.g.,
department, course code, course name, instructor, semester, availability).
o The system should display detailed information for each course (e.g., description,
prerequisites, credit hours, schedule, instructor, available seats).
4. Course Selection & Registration:
o The system should allow students to select courses they wish to register for.
o The system should check for prerequisites and co-requisites before allowing
registration.
o The system should check for time conflicts with already registered courses.
o The system should check if the student has met the maximum allowed credit
hours.
o The system should display the total credit hours and any associated fees for the
selected courses.
o The system should allow students to confirm their course registration.
5. Waitlisting:
o If a course is full, the system should allow students to add themselves to a waitlist
(if enabled for that course).
o The system should manage the waitlist and automatically enroll students if seats
become available based on a defined priority (e.g., first-come, first-served).
o Students on the waitlist should receive notifications about their status.
6. Dropping Courses:
o The system should allow students to drop courses within a specified timeframe.
o The system should handle any associated fee adjustments or refunds based on the
drop policy.
o The system should update the course enrollment and potentially notify students on
the waitlist.
7. Viewing Registered Courses:
 o Students should be able to view a list of the courses they are currently registered
for, including schedule and instructor information.
8. Viewing Academic History (Optional):
o The system might allow students to view their past course history and grades
(depending on the project scope).
9. Profile Management:
o Students should be able to update their personal information (e.g., address,
contact details).
o Students should be able to change their password.

B. Administrator-Related Functions:

1. Admin Login:
o The system should provide a secure login interface for administrators.
o Different levels of administrative access might be required (e.g., super admin,
department admin).
2. Course Management:
o Administrators should be able to add, edit, and delete course information (e.g.,
course code, name, description, credit hours, prerequisites, co-requisites,
capacity).
o Administrators should be able to assign instructors to courses.
o Administrators should be able to define course schedules (e.g., days, times,
location).
o Administrators should be able to set enrollment limits for courses.
o Administrators should be able to enable or disable waitlisting for specific courses.
3. Student Management:
o Administrators should be able to view, add, edit, and deactivate student records.
o Administrators might need to manually enroll or unenroll students in courses in
specific cases.
4. Instructor Management:
o Administrators should be able to add, edit, and delete instructor information.
o Administrators should be able to assign courses to instructors.
5. Semester/Academic Year Management:
o Administrators should be able to define and manage academic semesters or terms
(e.g., start and end dates, registration periods, drop deadlines).
6. Fee Management (Optional):
o Administrators might be able to define course fees and manage payment
information (depending on the scope).
7. Report Generation:
o The system should be able to generate various reports, such as:
▪ Course enrollment lists.
▪ Waitlists for specific courses.
▪ Student course schedules.
▪ Course capacity reports.
▪ Potentially, financial reports (if fees are managed).
8. User Role and Permission Management:
 o Administrators should be able to manage user roles and assign specific
permissions to different administrator accounts.
9. System Configuration:
o Administrators should be able to configure system-wide settings (e.g., maximum
credit hours, registration deadlines, notification settings).

C. Instructor-Related Functions (Optional, depending on scope):

1. Instructor Login:
o The system should allow instructors to log in securely.
2. Viewing Assigned Courses:
o Instructors should be able to view the courses they are assigned to teach.
3. Viewing Class Rosters:
o Instructors should be able to view the list of students enrolled in their courses.
4. Potentially, Grade Submission (If integrated with a grading system):
o The system might allow instructors to submit grades for their students.

II. Non-Functional Requirements (How well the system should perform):

A. Performance:

1. Responsiveness: The system should respond to user actions (e.g., page loads, form
submissions) within an acceptable timeframe (e.g., within a few seconds).
2. Scalability: The system should be able to handle a growing number of users and data
without significant performance degradation.
3. Efficiency: The system should utilize resources (e.g., server processing power, database
storage) efficiently.

B. Security:

1. Data Confidentiality: Sensitive student and system data should be protected from
unauthorized access.
2. Data Integrity: The system should ensure the accuracy and consistency of data.
3. Authentication: User logins (student and admin) should be secure.
4. Authorization: Users should only be able to access features and data relevant to their
roles.
5. Protection against common web vulnerabilities: The system should be protected
against SQL injection, cross-site scripting (XSS), and other common security threats.

C. Usability:

1. User-Friendliness: The system should have an intuitive and easy-to-navigate interface

for both students and administrators.
2. Accessibility: The system should strive to be accessible to users with disabilities
(following accessibility guidelines like WCAG).
 3. Clear Instructions and Feedback: The system should provide clear instructions and
informative feedback to users.
4. Error Handling: The system should handle errors gracefully and provide helpful error
messages.

D. Reliability:

1. Availability: The system should be available to users for a high percentage of the time.
2. Fault Tolerance: The system should be able to recover from failures without significant
data loss or downtime.
3. Data Backup and Recovery: Mechanisms should be in place for regular data backups
and efficient recovery in case of data loss.

E. Maintainability:

1. Code Quality: The system should be developed with well-structured, documented, and
maintainable code.
2. Modularity: The system should be designed in a modular way to facilitate easier updates
and modifications.

F. Portability (Optional):

1. The system might need to be portable across different operating systems or database
systems (depending on the project goals).

III. Data Requirements (What data needs to be stored and managed):

1. Student Data: Student ID, name, address, contact information, date of birth, program of
study, login credentials, academic history (optional).
2. Course Data: Course code, course name, description, credit hours, prerequisites, co-
requisites, capacity, schedule (days, times, location), instructor ID.
3. Instructor Data: Instructor ID, name, contact information, department.
4. Enrollment Data: Student ID, course code, semester, enrollment date, drop date (if
applicable), grade (optional).
5. Waitlist Data: Course code, student ID, timestamp of adding to waitlist.
6. Semester/Academic Year Data: Semester ID, name, start date, end date, registration
start date, registration end date, drop deadline.
7. User Account Data: User ID, username, password (hashed), role (student, admin,
instructor).
8. Fee Data (Optional): Course code, fee amount, payment status, transaction details.

IV. Reporting Requirements (What information the system needs to generate):

(Covered under Administrator Functional Requirements - Report Generation)

V. User Interface (UI) and User Experience (UX) Requirements:

1. Consistent Design: The system should have a consistent look and feel across all pages.
2. Intuitive Navigation: Users should be able to easily navigate through the system's
features.
3. Clear Information Presentation: Information should be presented in a clear, concise,
and organized manner.
4. Mobile Responsiveness (Optional): The system might need to be accessible and
functional on different screen sizes (desktops, tablets, mobile devices).