Requirements are the building blocks of the audit. Our system will use these to evaluate classes towards a degree. Requirements can be categories, sub-categories, or courses.
Within Stellic, categories have a ‘tree’ structure, so you’ll see sub-categories branching off of main categories. Each sub-category can have its own rules on top of the rules for the main category.
When coding requirements, we recommend keeping the readability from students’ perspective in mind. If possible, try to make the requirement easy to understand and refrain from writing jargon.
Stellic uses an algorithm that prioritizes requirements based on their order in the audit. Electives or broader requirements should be placed at the bottom of the audit. Core courses or requirements that should be filled first should be placed higher in the audit.
There are four types of requirements:
Course: a single course (e.g.: MATH-101)
Milestone/Other: Milestones are a way to track non-course requirements in the audit. See our article on "Introduction to Milestones" for more information.
New Category: a new ‘branch’ or bucket with specific rules (constraints) and courses (e.g.: “Core Courses”, “Science Elective-Category A”)
Shared Category: a link to an existing requirement defined as ‘shared’ (e.g.: General Education Requirement). Shared requirements are great ways to shorten the audit building process, as they can be built once and used in many audits.
Constraints are the rules that determine if a course fulfills a requirement, like “Take all of the following courses” or “Take at least two courses from the same sub-requirement”. Each Category must have at least one constraint (primary constraint), so that the system can tell which courses can be used to fulfill the requirement.
A course must meet all constraints in order to count for a requirement. If a Category has the two constraints: “Take 1 course from CS Department” and “Minimum Grade of C or above”, a course will only fulfill the Category if it is offered by CS department and the student has achieved a C or above.) If you’d rather create an OR relationship between two constraints, you’ll need to create two separate sub-requirements and use the ‘fulfill any’ constraint on the parent requirement.
In order to see the constraints for a requirement, click the box next to the requirements title with the number of constraints showing.