Constraints control all degree requirements for the audits within Stellic - as a result, there are a robust number of constraints that exist. We have separated them into categories, with each category existing in its own article. You can navigate between all of the constraint pages using the table of contents below:
Course sets (we recommend starting here - these are the most commonly used!)
Before we dive into our lists of constraints, there are a few basic rules that need to be defined:
Levels of constraints - where and when can various constraints be applied
Constraint terminology definitions - there are a few constraint specific terms that we will define
Combining requirements in a constraint - when does it create an "and" vs an "or" relationship between constraints and requirements?
Levels of constraints
Primary constraints are constraints that can be used on their own - you will see these when you first start to build your audit and have no other constraints listed in the category. A primary constraint defines what can count for the specific requirement.
Secondary constraints are constraints that can only be found once you have a primary constraint listed. They cannot be used on their own. These constraints filter the requirements in some way once a primary constraint has been defined.
Program level constraints are constraints that only can be found at the program level of an audit. These constraints can be either primary or secondary, but can’t be placed in sub-requirements - only at the top program level.
Constraint terminology definitions
Course set - Found in several constraints, such as “at least [x] courses/units from a given course set”, this term acts as a flag to indicate that there are other options available within the constraint. Once you have added the constraint to a requirement, the course set can be expanded to be several options (some or all may be available within each constraint where you see this term):
Specific courses
A manually entered list of courses. Note that courses must be entered in the standard course format for your institution in order to be recognized by the requirement editor
Courses with attributes
Attributes are identifiers given to a course by the university. For example, the university can tag courses that should count for science electives. This is an easy shortcut to define requirements that have a long list of courses. Instead of listing 200 courses under the science elective requirement, simply tag all these courses with “science elective” and use the [attribute] constraint.
Tip: This constraint will only be helpful with universities that have chosen to add attributes to courses.
Course range
A course range where * are wildcards:
MATH-200 to MATH-999 means any 200-level MATH or above
****-200 to ****-299 means any 200-level course
**-000 to **-999 means any course (free elective)
Tip: Course Range can only accept ** in the department code area. **-3** will not work, but **-300 will.)
~ (tilde) can be used in patterns and ranges for the purpose of unlimited matching. ~ has the same functionality as * with the difference that * represents just 1 character whereas ~ represents any length of characters.
~ is only allowed at the end of the numeric part for ranges and at the end of patterns. No character after ~ is allowed.
Course pattern
A course pattern, where * are wildcards
MATH-*** means any MATH course
MATH-2** means any 2 level MATH course
MATH-2*2 means any 2 level MATH course that ends with 2
Note that there is a 1:1 relationship between * and course characters. ~ (tilde) can be used in patterns and ranges for the purpose of unlimited matching. ~ has the same functionality as * with the difference that * represents just 1 character whereas ~ represents any length of characters.
~ is only allowed at the end of the numeric part for ranges and at the end of patterns. No character after ~ is allowed.
Course with topics
For courses with one course number but multiple course topics/distinctive sections within the course, you can limit the requirement to a specific topic.
Course with tags
Tags are similar to attributes - which constraint you use depends on how the data is sent by your institution. Tags do tend to be less common than attributes - when in doubt, we recommend trying attributes first!
Specific departments
In order to identify a course's department, Stellic looks at the subject code of the course and identify which department that subject code belongs to based on the configuration set up by your institution.
Note: All subject codes belong to one department in Stellic - we do not currently support one subject code belonging to multiple departments, or having some courses of a subject code in one department and other courses in the same subject code in another department.
Specific schools
Similar to departments, Stellic will look at the subject code of the course and identify which school that subject code belongs to based on the configuration set up by your institution.
Like departments, subject codes can only belong to one school.
Specific levels
For institutions that use levels (such as undergraduate, graduate, etc.), this constraint will use the level data in courses to restrict courses of only that level to count toward the requirement.
Specific hidden courses/course ranges/course patterns
In an instance where you don't want courses to visibly display in the audit (for instance, courses that haven't been offered in some time but can still count toward a requirement), you can use the option to hide the following courses from displaying in the audit unless taken by the student. This allows the course to be added to the audit, but only display if the student has taken the course.
Constraint interactions - how to navigate "and/or"
Listing two rules together within the same constraint will create an "OR" relationship.
Example: This set up is one constraint within a requirement, and two attributes within that same constraint. This will create a requirement that looks for two total units of courses that have either a language requirement attribute, or fall within the course range of SP100 - SP199.
Listing constraints within the same requirement but in separate constraints will create an "AND" relationship.
Example: This set up has the same constraint specifications as above, but is listed in two separate constraints in the requirement. This will create a requirement that looks for two total units that are both a language requirement, and fall within the course range of SP100 - SP199.
Note: It is not necessary to specify units for both constraints - if we specify a unit or course total in the first constraint, setting the second constraint at 0 courses or units will still enforce the "and" requirement, but doesn't add to the total course number or units needed.
The constraint "take at least 0 units/courses", once saved, will display as below: "following courses may count".