Degree Audit User Training | Requirements

Need More Information?

Then see how to create a:

• High School Deficiency requirement;
• Course requirement with metadata & course lists;
• Total requirement with metadata & course lists;
• GPA requirement with metadata & course lists;
• Proficiency/Portfolio requirement.

What are requirements?

These are the requirements that make up the audit that the student will see on the results page. These are all counting courses or groups of courses against courses lists or through the metadata regarding scope reuse. We will go into more detail on how to generate and code requirements in the next section.

What are the different requirement types?

You have five types of requirements to use when coding your requirements. The five types are:

• High School Deficiency Requirements
• Course Requirements
• Total Requirements
• GPA requirements
• Proficiency/Portfolio Requirements

Depending on the requirements for your degree plan, you will want to pick the appropriate requirement type to code against it.

High School Deficiency Requirements:

Students are not admitted to the University if they have high school deficiencies. Effective fall 2014, the Office of Admissions will require transfer students to submit their high school transcripts to determine if they are deficient in a foreign language. Students who are deficient in a foreign language will have to make up the deficiency before enrolling at the University of Texas and will be treated the same as incoming freshmen.

With this requirement, first check to see if a deficiency exists. If so, code two types of requirements against it. The first step is to identify if a deficiency exists, and then add a requirement if the deficiency is found (this is the most common) and/or if one is not found. ( Example: Degree plan SWS WSW, 2010)

Course Requirements:

Course requirements are the requirements that are looking for specific courses or groups of courses and make up the bulk of a student’s audit.

Total Requirements:

Total requirements are requirements that are looking for large sets of courses, degree totals, 60 hours in residence, last hours, hours in major courses etc…

GPA Requirements:

GPA Requirements will calculate through the official GPA calculation module whatever is defined in the course list.

Proficiency/Portfolio Requirements:

This requirement type is the only one that a course list is not allowed to be used in because it is a type of requirement that cannot be met via courses. Use it for those types of requirements that cannot be met via coursework.

What is scope?

Scope is the classification of a requirement based on where it exists in the cumulative degree plan. Scope is how IDA differentiates between sets of rules that are enforced by different academic units. It also partially determines how coursework can be reused to count for multiple requirements. Scope is a required metadata field for every requirement.

The current scopes, in order of appearance in the metadata, are:

Administrative

Typically used for GPA and Totals requirements at the University and school/college levels. Also used primarily for independent restrictions, such as duplicate checking. Administrative rules display differently from other scopes on audit results (see scope and display below).

Core

Used for requirements needed to fulfill the core curriculum. Each core rule requires a valid core code. Core rules are maintained exclusively by UGS; do NOT use this scope for non-core rules.

General Education

Typically used for requirements that apply to every degree plan within a given school/college.

Major

Used for any rule enforced by the major, including all requirement and restriction types.

Attribute Flag

Used for flag requirements. Used in conjunction with a course list that seeks a specific flag (WR, GC, etc.).

Track

Typically used for degree plans that have two or more distinct tracks or specializations within a single major. May be considered a more granular subset of major rules.

Minor (prior to 2016-18 only)

Used for degree plans that require a minor. Used in conjunction with special course lists that seek the minor FOS (or FOSes) submitted with the audit.

Minor/Certificate (starting in 2016-18 only)

Used for a single, specialized "trigger" requirement within each degree plan. Can have its description and estimated hours updated to reflect whether it's required for a degree or not. The trigger will retrieve the rules associated with the minor/certificate submitted with the major. Rules within each minor/certificate sequence record also receive this scope. For more information, read the minors/certificates module.

Custom

May be used for requirements that don't fit one of the other scopes. Carries no special processing.

Elective

Typically used for requirements that seek free electives.

Scope reuse

Scope reuse is one way that IDA handles coursework that may be counted in more than one place (known as "double-dipping"). Scope reuse is retrospective. When you enable scope reuse within a requirement, you permit the second "dip" for that requirement. Enabling scope reuse in a requirement does NOT mean that a course used to fulfill that requirement can be "double-dipped" in a later requirement.

Scope reuse may only be set for requirements that permit the use of coursework that was used for other scopes. One example pertains to core rules. An individual course cannot be used to fulfill more than one core rule. Core rules therefore cannot enable "Core" for scope reuse. On the other hand, any course used to fulfill a core rule may be used to fulfill rules with a different scope, such as major rules. If a major rule permits reuse of core coursework, then scope reuse for "Core" can be enabled on the major rule to allow core coursework to count for that major rule.

The sequence record can help you determine how and where scope reuse is needed. For example, the first requirement listed within a sequence is the first one evaluated, and is the first opportunity for coursework to be applied to a requirement. In theory, scope reuse is not needed here. If the second requirement allows coursework from the first requirement to be used, then scope reuse can be enabled on the second requirement to allow the coursework to count for both requirements. (Note: in practice it is common to enable scope reuse for all requirements regardless of sequence position.)

Another example involves minor/certificate rules and free electives (in the 16-18 catalog only). The trigger requirement should always be sequenced second-to-last, ahead of electives (if your degree plan has no electives, the trigger will come last). The minor/certificate rules will need to have their scope reuse updated from their own sequence record to allow reuse from parts of the degree plan. Since electives are sequenced (and evaluated) last, the college must decide if coursework used to fulfill minor/certificate rules can also be used to satisfy free electives. If so, then you need to enable "Minor/Certificate" scope reuse on the electives requirement.

If “exclude unused coursework” is checked yes in a requirement, then the course will be reusable if it was used for at least one of the scopes listed under scope reuse in the requirement. If “exclude unused coursework” is checked no, then the course is NOT reusable if any scope has applied that is not listed in scope reuse.

Scope restrictions

Scope restrictions are dependent restrictions that can be used to restrict courses from counting toward specific scopes. One example is a grade requirement. If your degree plan does not allow grades below a certain threshold to count for your major rules, you can use a scope restriction on the major rules to exclude any course that doesn't meet the threshold. For more information, see the restrictions module.

Because scope restrictions are dependent restrictions, they do not display on the audit results (even if they exclude a course) and their effects may not be obvious. A dependent restriction with an Administrative scope can have effects that are especially hard to detect. For this reason, you are strongly encouraged to remove Administrative from the list of scopes to which the restriction applies.

Scope and display

Each scope carries a header that has a predetermined position within the audit results. Each requirement with a given scope will appear on the audit results under that scope's header. From top to bottom, the order of headers is:

• Core
• Attribute Flag
• General Education
• Major
• Track
• Minor/Certificate
• Elective
• Custom

Note: Administrative requirements do not have a unique header, but are displayed using the requirement type. For example, an Administrative GPA requirement will appear under the "GPA Totals" header, while an Administrative totals requirement will appear under "Credit Hour Totals."

Scope display and sequence processing

The organization of scope headers on the audit results does not influence processing order. Rules are processed in order based on their position in the sequence record, regardless of where they display on the audit results.

Requirement Reuse

There are times when you may find scope reuse to be too broad and you can instead use requirement IDs to either include a specific requirement for reuse or to exclude a specific requirement from reuse. Allowing or denying reuse through requirement IDs takes precedence over scope reuse.

What is sequencing?

Sequencing refers to multiple components in IDA related to processing order. This module will discuss concepts and definitions to assist you in understanding sequences.

Degree Plan Sequence:

The requirements page for a given degree plan will display the sequences for the entire degree plan. When an audit is submitted for a given degree plan, IDA first processes the degree plan restrictions (starting with sequence record #1) to eliminate any coursework that doesn't count uniformly. IDA then processes the requirements, starting with sequence record #1.

A quick view of how coursework is processed:

1. Degree plan restrictions
2. High School Deficiency Requirements
3. Course Requirements
   1. Sequence 1
   2. Sequence 2
   3. ...
4. Total requirements
   1. Sequence 1
   2. Sequence 2
   3. ...
5. GPA requirements
   1. Sequence 1
   2. Sequence 2
   3. ...
6. Proficiency/Portfolio Requirements
   1. Sequence 1
   2. Sequence 2
   3. ...

(NOTE: The sequence of the degree plan does not reflect the order in which the requirements appear on the completed audit.).

Requirement Sequence:

Within a requirement, the core processor follows the same guidelines for removing restricted courses before evaluating for applicability. All associated scope restrictions and subset restrictions are processed first. After that, restrictions built into the requirement are processed. The core processor then moves to the option(s). It will first process any option restrictions, and then evaluate the option's coursework for applicability.

A quick view of course work sequence:

1. Scope Restriction
2. Subset Restriction
3. Requirement Restriction
   1. Section 001
      1. Option 1 restriction (if one is present)
      2. Option 1 course work
      3. Option 2
   2. Section 002
      1. Option 1 restriction (if one is present)
      2. Option 1 course work
      3. Option 2

Course List sequence:

Course lists carry their own sequence of courses that will meet the requirement. These are lined up in the order they exist in the course list.

Sequence 1 = First course checked

Sequence 2 = second course checked

…

Why does sequencing matter?

Sequence matters because this is the order that the system will process coursework. If you remember from the Mode Discussion, it is also one of the things that you can change, but you will have to request a sequencing migration from the Office of the Registrar. Sequencing coursework can also improve the overall processing time of the audits.

Sequencing your restrictions properly can also remove courses from counting toward other restrictions.

In the example listed above the Liberal Arts is removing 36 hours of economics preferencing ECO 304K & ECO 304L as exceptions to the rule before the courses are even removed from the restriction below it.

What constitutes a sequence change?

A sequence change is anything (other than changing the course list sequence, or adding sections or options) that modifies how the courses are processed. This can be done by adding a new requirement or restriction, deleting a requirement or restriction, and/or moving a requirement or restriction into a new sequence location.

Moving a requirement/restriction:

You can move and change the sequence of any requirement/restriction that exists at the level of the degree plan you are at. For example, if you are working on degree plan CSRTFBS, you can only move requirements and restrictions that are coded at CSRTFBS. These will appear white on the screen and all other requirements that you cannot move will be grey.

To move the requirement, simply click on the sequence number and drag it to the location within the requirements page you would like this requirement to process.

What is trumping?

Trumping is the ability to overwrite a requirement that exists at a higher level in the degree plan hierarchy with a new requirement at a lower level in the degree plan hierarchy. This requirement does not have to be similar to the trumped requirement. It can be its own unique requirement that is independent of the trumped requirement.

How do I trump?

To trump a requirement you first need to know which requirement you would like to trump and the level that it exists at. You should then navigate to a lower level of the degree plan and click on the “trump” link and that will bring up the correct metadata screen for the requirement type you are trumping. You will fill out the metadata for the requirement as though it was a standalone requirement. Once the requirement is fully completed for that level it will supersede the base requirement that you trumped and any audits run against that degree plan will use this new requirement.

When should I trump?

You should trump when you have a requirement that is required for everyone except a few differences based on degree plan. It is also a good way to manage tracks, honors requirements, or any situation where you would like to write one requirement differently from the rest of the overall degree plan. A good example of this would be if you have a foreign language requirement for all students in the college, except one degree plan has a different foreign language. You can write the requirement at the highest level (L) and then trump that requirement with a new one at the level you would like for the requirement to exist at (LAHIS).

Things to keep in mind:

• When a requirement is trumped, you cannot sequence the trump. All sequence changes must be performed at the base level requirement and the sequence changes will move the trump.
• If you delete the base requirement, the trump is orphaned and will be disconnected from the degree plan.
• The trump does not have to match the base requirement in anyway; it can have its own scope, reuse, course lists, etc.
• The only limit to the number of trumps is the characters allowed in a degree plan. Trumping the same requirement at every level is allowed.
• There is no limit to the number of degree plans that can trump a requirement. You can trump a requirement from any number of levels underneath it.