Course Management Software System: Requirements

This document outlines some high-level requirements for a generic course management software system that could be deployed for use within the Computer Science department at Cornell University. The requirements outlined in this document have been collected from a variety of sources, including:

• Instructors: Greg Morrisett, David Schwartz, Jayavel Shanmugasundaram,
• Teaching Assistants: Kiri Wagstaff
• Administrative Staff: Laurie Buck, Kathy Carpenter
• ADM Staff: Dora Abdullah

Please note that this document is only a first draft, and that the requirements could change once we get feedback from additional sources.

The rest of this document is organized as follows. In Section 1, we outline the high-level architectural requirements, and in Section 2, we describe other functionality requirements. Finally, in Section 3, we present some thoughts on the development and maintenance of the system.

1. High-level Architectural Requirements

We outline three architectural requirements, namely security, reliability, and scalability. We now discuss each in more detail.

1.1 Security

• Firewall protection: The course management software system should run inside a firewall. It is an open question as to whether this should be the within the CUCS firewall, or a separate firewall (for better security).
• Kerberos authentication: All users of the system should be authenticated using the Kerberos authentication mechanism provided by CIT.
• Support for different roles: The system should support different roles for users, such as Instructors, Teaching Assistants, Students, and Administrative Staff. A user logged in with a given role should only be allowed access consistent with that role. For example, a student should only be allowed to see his or her grades, and not the grades of others.

1.2 Reliability

• Reliability of data: Since all course-critical data (such as grades) will be stored in the course management system, the reliability of the system is of paramount importance. A simple way to meet this requirement is to use a commercial database system (such as Microsoft SQL Server, Oracle or DB2) for all data management tasks. Note that periodic backup of text files is not sufficient to guarantee reliability of the data. Backups of text files are not sufficient to guarantee reliability because (a) the course management software system could crash in the middle of updating the text file leaving the data in an inconsistent state, and (b) there could be race conditions when updates are done concurrently with backups.
• Reliability in the face of concurrent access: If the course management system is to be used for large courses, concurrent access to data becomes an important issue. For example, the system should continue to work correctly when students and TAs are concurrently accessing and manipulating grades. Again, using a commercial database for all data management tasks will solve this problem.

1.3 Scalability

• Scaling to a large number of users: Large courses such as CS100 and CS432 have hundreds of students. The system should be able to handle the load for such courses, especially near assignment deadlines when many students can be expected to access the course management system.
• Scaling to a large number of courses: If the course management system is successful, it is conceivable that a large number of CS courses will end up using the system. The system should thus be able to scale to a large number of courses, while at the same time scaling to a large number of users for each course.

One simple way to meet the above requirements is to dedicate a separate machine and an application server for every large course. All the courses could share the same database backend so that management overhead for the system maintenance staff is minimized.

2. Functional Requirements

We now describe some functional requirements for the course management software system.

2.1 Grade Management

The system should be capable of managing student grades. Specifically, it should support the following features:

• Allow grades to be entered online: The system should allow TAs and instructors to enter and modify grades online.
• Allow students to access their grades online: The system should allow students to log in and check their grades at any time. In addition, it would be nice if the system also provides statistical information such as averages, standard deviation, median, etc.
• Track and Handle Re-grade Requests: The system should be able to track and handle requests for re-grades. All information about re-grades should be available to the student, the associated TAs, and the course instructor.
• Export grades in standard formats: The system should be capable of exporting the grades in CSV format so that the grades can be sent to the registrar electronically (without having to fill in bubble sheets). Also, exporting grades in CSV format allows grades to be imported by software packages like Microsoft Excel, in case sophisticated statistical analysis is desired.

2.2 Homework Submissions

The system should be capable of automatically accepting homework submissions. Specifically, it should support the following features:

• Accept submissions in multiple formats: The system should accept submissions in multiple formats, including .zip, .cpp, .txt, .doc, etc.
• Automatically validate submissions: The system should be able to automatically validate submission using a script so that students can get immediate feedback on faulty submissions.
• Support for late submissions: The system should provide information about late submissions, and also disallow submissions after a certain period of time.
• Provide online access to submissions for TAs: The system should allow TAs to download assignment submissions online.
• Support for online grading: The system should provide the ability to grade submitted code (and other assignments) online and provide good student feedback, without requiring massive printouts. Some ways of achieving this are: (a) providing online grading templates that can be filled out, and (b) automatically annotating code with line numbers. [Note: The Cucoon system may already support this feature.]
• Integration with grade management: The homework submission system should be integrated with the grade management system so that (a) assignment grades can be automatically posted, and (b) grader comments can be sent along with the grades.

2.3 Group Management

The system should support group management features. Such features are especially important for courses with group projects.

• Ability to create groups: The system should allow students to automatically create groups, and enforce certain conditions such as each student should be a member of exactly one group for a given project. The TA and/or course instructor should not be forced to create groups; this is especially important for large classes.
• Integration with homework submissions: The system should be able to accept group homework submissions.
• Integration with grade management: The system should support grade management for groups, and track how the group grade translates into individual student grades.
• Group Maintenance: Invariably, students either switch groups, or drop out from a group altogether. The system should support such transitions and keep track of them.

2.4 Miscellaneous

The system should support the following miscellaneous requirements.

• Course web page management: The system should allow for easy course web page management by supporting bulk-uploads of web pages/other files.
• Integration with Registrar’s class lists: The system should periodically upload the latest registrar’s class list to determine the current set of students enrolled in the course.
• Integration with newsgroups: The system should allow for easy integration with course news groups (currently supported by CIT).

3. Concluding thoughts

Since we are not aware of any existing software system that supports all of the above features, it seems inevitable that we develop and maintain our own “home-grown” system. While developing such a system has many advantages, it also comes with the following additional responsibilities.

• Commitment towards system development and maintenance: Once the system is in operation, bugs and missing features will inevitably crop up. We need to have a strong commitment within the Computer Science department to support the course management software system so that bugs, missing features and personnel changes do not affect the usability of the system.
• Commitment towards course set-up: Once the course management system is available, there has to be a commitment to setting up the system for every CS course at the beginning of the semester. This way, there will be very little overhead in adopting the system for use in a course. If the system is going to be difficult to set up and configure, then many courses that could potentially use the system may never do so. Training for all users involved (Prof’s, TA’s, Admin Asst’s, etc) is also a necessary component to ensure success of this endeavor.