Constraints

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!)
• Course grade related
• Double counting
• Manually satisfy
• Program GPA
• Restricting criteria
• Repeating courses
• Units/Credits
• Hiding courses or criteria
• Tags/Attributes
• Program related

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

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

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.