Functional Requirements

Definitions:

• In these requirements, the organization using Gradebook may be referred to as “educational institution” or just “institution”.

• “Optionally” refers to a choice that the end user has, not an optionally implemented requirement or portion of a requirement.

• “The project” refers to a subset of Gradebook’s product requirements that are being implemented by Team Alpha as a part of our CS305 term project. Frequently used to denote when a certain feature or concern is outside the current scope of the project (and thus are not a part of this document) but may still be a part of Gradebook’s complete product requirements.

• Acronyms: API (Application Programming Interface), UI (User Interface), CLI (Command Line Interface)

Important notes:

• Except where noted, owners and certain maintainers of a Gradebook instance or a database where gradebook is installed on (colloquially referred to as “superusers”) have full access to all data, bypassing the privacy quality attributes of requirements. Auditing of these bypasses are outside the scope of the product (and therefore, the project).

• If not explicitly noted in a quality attribute, the implementation of each requirements does not run the risk of personally identifiable information or other confidential information being inappropriately accessed.

• All reports will offer two formats of returning data: a database table, and a CSV representation of the table.

• DB API will be interfaced through SQL, and middleware API through REST APIs, promoting portability and reusability.

FP3: Authenticate user

Description:

Require all users to log in with a username and password. System functionality should be restricted to only allow interaction at a level appropriate to the current user’s access level, which depends on their role within the system (for example, “student”, “instructor”, “department chair”), as well as their specific role (for example, student A can only see grades belonging to student A).

Priority: High

Stability: Firm

Status: Pending

Quality attributes:

Security: Only individuals with a username and password may have access to create, change, or view data. Credentials must be kept secure. Incorrect username and password combinations must be denied access. Access controls should be assigned on each database object to ensure only authorized users create, change, or view confidential data.

Privacy: Credentials must be maintained in a manner such that no one (including “superusers”) can see their original representations (often referred to as “plaintext”). These plaintext representations may not need to be stored at all.

Portability: The authentication method should be able to be interfaced by a wide variety of clients (examples: desktop, mobile, web, CLI/SSH)

Depends on: 2

FP5: Manage Terms

Description:

Terms comprise of years and seasons during which classes are held. They include start and end dates, and enrolment deadline, and due dates for midterm and final grades. More specific requirements are listed below.

FP5.1: Manage years

Description:

Allow appropriate user roles to manage information relating to the years that the institution has been open/offering courses. For the scope of the project, only the database design for leaf nodes needs to be fully implemented. The database API, middleware, and UI for managing years only needs to implement read/selection, and not additions, modifications, or deletions of information. Therefore, only the FP5.1.3 requirement is fully detailed below.

Priority: High

Stability: Firm

Status: Pending

Quality attributes:

Usability: A “read only” UI will be implemented to view and select DB information.

Depends on: 5

FP5.1.3: List years

Description:

Allow authorized users to view available term years. These term years generally represent years that the educational institution has been operating, however, in practice, these will be defined as years in which there have been or will be courses available. When appropriate, these should be allowed to be limited to the courses in the current context. For example, only list the years that the current instructor has taught, likewise, students can filter to years for which they have been a student.

Priority: High

Stability: Firm

Status: Pending

Quality attributes:

Privacy: All authenticated users may view term years for the whole institution and for instructors. Student privacy is of concern: each student can see what years they have been a student; no other student or instructor can see a summary of this information.

Performance: This functionality is expected to be used frequently and involves referring to a potentially large listing of courses and sections. Extra care is needed to ensure a reasonably optimal implementation is used.

Usability: A “read only” UI will be implemented to view and select DB information.

Depends on: 5

FP5.2: Manage seasons

Description:

Allow appropriate user roles to manage information relating to the seasons that the institution splits their course offerings into. For the scope of the project, only the database design for leaf nodes needs to be fully implemented. The database API, middleware, and UI for managing users only needs to implement read/selection, and not additions, modifications, or deletions of information. Therefore, only the FP5.2.4 requirement is fully detailed below.

Priority: High

Stability: Firm

Status: Pending

Quality attributes:

Usability: A “read only” UI will be implemented to view and select DB information.

Depends on: 5

FP5.2.4: List seasons

Description:

Allow authorized users to view available term seasons. Seasons represent the timeframe in a year during which classes are held, such as Fall, Spring, or Intersession (Summer or Winter). When appropriate, the list should be limited to seasons in which the current user is involved (for example, only list seasons during which a student currently has, has had, or is scheduled for a section, depending on the selected year). A similar filter should exist for instructors and courses they teach.

Priority: High

Stability: Firm

Status: Pending

Quality attributes:

Privacy: All authenticated users may view available term seasons for current, past, and future terms. Student privacy is of concern: each student can see what seasons they have been a student; no other student or instructor can see a summary of this information.

Performance: This functionality is expected to be used frequently and involves referring to a potentially large listing of courses and sections. Extra care is needed to ensure a reasonably optimal implementation is used.

Usability: A “read only” UI will be implemented to view and select DB information.

Depends on: 5

FP5.7: Assign holidays and closures

Description:

Allow registrar admin users to add holidays and closures to the schedule. “Holidays” represent all federal, state, local, and/or institutional holidays recognized by the institution. The institution does not necessarily need to close and/or abstain from holding classes on a holiday. A “closure” represents days on which the university is closed, and no classes are held, which includes, but is not limited to, federally recognized holidays and weather-related closures. A day can be both a closure and a holiday.

A holiday is required to have a name and associated date. A closure must have an associated date and registrar-provided name. It also needs a reason, which can be either:

• Holiday

• Weather

• Other (If chosen, the closure’s name should be sufficiently descriptive)

Other functionality of Gradebook may use this requirement to determine business rules. (For example, attendance and/or course meeting dates may take into account closures.)

Priority: High

Stability: Firm

Status: Pending

Quality attributes:

Security: Only users with the registrar admin role may modify the closure and holiday schedule.

Depends on: 5

FP5.8: Report on terms - show aggregate information on terms

Description:

Allow users to view aggregate information on terms. This information can be accessed either for an individual year or a range of years and optionally includes any combination of:

• Course count

• Section count

• # of unique instructors (no distinction made between kinds of instructors, for example, adjunct, assistant, so on)

• # of unique students (no distinction made between kinds of students, for example, part-time, full-time)

• A full listing of sections offered in that term

Priority: High

Stability: Firm

Status: Pending

Quality attributes:

Security: Only authorized users may view course reports/aggregate course information.

Performance: Reporting on terms involves working with potentially large data sets. Implementation should be optimized based on anticipated needs, including only accessing the minimum required information for a query.

Depends on: 2, 5, 8, 9, 11

FP5.9: Show term schedule

Description:

Allow users to view term schedule. The term schedule will show the days in a term, including special designations for holidays and closures.

Priority: High

Stability: Firm

Status: Pending

Quality attributes:

Usability: When implemented in a user interface, the information should be presented in an easy-to-use view (for example, a calendar).

Depends on: 5

Special Note:

This is a new requirement that was not listed in Gradebook’s original functional requirements. To maintain the original numbering of requirements, this requirement was added after FP5.8 as opposed to the somewhat more logical ordering of placing it between FP5.7 and FP5.8.

FP8: Manage courses

Description:

Courses will have a name and number, title, number of credits, and offering departments. Complete DB design and implementation of DB API. The implementation middleware or UI will be deferred. More specific requirements are listed below.

FP8.1: Add a course

Description:

Allow registrar admins and registrar staff to create a course that is offered by educational institution. Each course then has corresponding sections that are specific instances of course offerings that students may register for (noted in requirements outside the scope of the project). Every course has a course name/number, title, number of credits, and department that is offering the course, and are distinguished (made unique) by course name/number.

Priority: High

Stability: Firm

Status: Pending

Quality attributes:

Security: Only registrar staff and admins may add a course.

Depends on: 6, 8

FP8.2: Remove a course

Description:

Allow registrar admin users to remove a course by entering course name/number. Only a course with no sections associated with it (past, present, or future) may be removed. (Courses that are no longer offered should be maintained for record-keeping purposes).

Priority: High

Stability: Firm

Status: Pending

Quality attributes:

Security: Only registrar admins may remove a course.

Depends on: 6, 8

FP8.3: View and modify a course

Description:

Allow admin user to view and make changes to all details on a course: course name/number, title, number of credits, and department.

Priority: High

Stability: Firm

Status: Pending

Quality attributes:

Security: Only registrar admins can modify course. Registrar staff can update the title of a course.

Depends on: 6, 8

FP8.4: Report on courses

Description:

Allow users to view a report on courses, which comprises a list of available courses (all, or for a specified year or term)

Priority: High

Stability: Firm

Status: Pending

Quality attributes:

Performance: The listing of courses can be potentially large, so care is need to not perform redundant or unnecessary operations, or store unnecessary information.

Depends on: 6, 8

FP9: Manage students

Description:

A student has a unique ID and a unique email address, and may have zero or more majors, in addition to other information stored for every Gradebook user. Complete DB design and implementation of DB API. The implementation middleware or UI will be deferred. More specific requirements are listed below.

Quality Attributes:

Performance: Implementation should consider a reasonably optimal solution since student information will be frequently accessed in bulk and an educational institution may have a large number of students, including graduated students.

FP9.1: Add student

Description:

Allow admission staff to add a student. Refer to parent node for information needed for each student.

Priority: High

Stability: Firm

Status: Pending

Quality Attributes:

Security: Only admissions staff may add a student.

Depends on: 2, 9

FP9.2: Assign major (zero or more)

Description:

Allow registrar users to assign a student a major. Students are not required to have an assigned major.

Priority: High

Stability: Firm

Status: Pending

Quality Attributes:

Security: Only registrar staff or admins may assign a major to a student.

Depends on: 2, 9

FP9.3: Remove a major

Description:

Allow a registrar user to remove a major from a student.

Priority: High

Stability: Firm

Status: Pending

Quality Attributes:

Security: Only a registrar user may remove a major from a student.

Depends on: 2, 9

FP9.4: View and modify student

Description:

Allow appropriate users to view student information. Allow appropriate users to modify student information.

Priority: High

Stability: Firm

Status: Pending

Quality Attributes:

Security: Only registrar may modify student information.

Privacy: Student may view their own information. Instructors of students may view student information for students they teach.

Depends on: 2

FP9.5: Report on students

Description:

Allow a user to view a student’s name, ID, Email, major, and activity.

Priority: High

Stability: Firm

Status: Pending

Quality Attributes:

Privacy: Only Instructors and above may have view reports on students which they teach. Students may view reports on themselves.

Depends on: 2, 9

FP11: Manage Sections

Description:

Sections have a term, course, number, capacity, schedule, and letter grade. While some of this is determined by faculty, only a registrar admin user may actually make changes to the DB. More specific requirements are listed below.

FP11.6: Assign term grade to students (including withdraws)

Description:

Allow instructors to assign a term grade to their students. Create SQL write query to assign term grade to a given student. Provide API for middleware and UI. Implement middleware and UI.

Priority: High

Stability: Firm

Status: Pending

Quality attributes:

Security: Only instructors may assign term grades to students in the sections which they teach, for the sections they teach.

Depends on: 9, 11, 12

FP11.7: Report on sections

Description:

Allow users to view section information, such as the course name/number, section title, term, and capacity. This includes reports showing general information about sections and a section schedule. More specific requirements are listed below.

FP11.7.1: General reports on sections

Description:

Allow users to view section information, such as the course name and number, term, capacity. Reports can be for an individual section, or for all sections within a range of terms. Create SQL read queries to view section information. Sections can also be filtered to the current context, such as all sections that a student is registered for, or all sections assigned to an instructor. Provide API for middleware and UI. Implement middleware and UI.

Priority: High

Stability: Firm

Status: Pending

Quality attributes:

Privacy: A student may filter sections to sections they are enrolled in. Instructors may view reports on sections they teach, which include student enrollment for those sections. Administrative users can see reports that include student enrollment of all sections listed.

Depends on: 8, 11

FP11.7.2: Show section schedule

Description:

Allow users to view section schedules. Schedules will show when a given section is held, accounting for closures. Create SQL read query to view a section schedule. Provide API for middleware and UI. Implement middleware and UI.

Priority: High

Stability: Firm

Status: Pending

Quality attributes:

Privacy: Any authorized user may view any section schedule.

Usability: UI should present information in an easy-to-use format, such as a calendar view.

Depends on: 8, 11