Skip to main content

Constraints

  • Updated

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:

Before we dive into our lists of constraints, there are a few basic rules that need to be defined:

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):
  • Courses
    • A manually entered list of courses
  • Courses with attributes
    • Attributes are tags 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.

  • Hide courses
    • 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.

hidden_courses.png

 

Combining requirements in a constraint

  • Listing requirements together within the same constraint will create an "OR" relationship. 
    • Example: This set up is within the same requirement and two attributes within 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 requirements 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".

Was this article helpful?
0 out of 0 found this helpful
Return to top

Related articles