Degree Audit User Training | Coding For Efficiency

If the CR courses were excluded by one subset restriction (applying to major requirements as a group), then at most 48 hits would be needed to prohibit those courses from counting toward all major requirements (12 courses x 1 restriction x 4 course list filters). On other hand, if the restrictions were connected to 10 individual major requirements, the number of hits could add up to 480 or more (12 courses x 10 restrictions x 4 course list filters). In general, it is better to state restrictions separately whenever possible and attach them to specific requirements only when they apply to those requirements exclusively. More detailed recommendations are given immediately below.

Selecting the best restriction

When you are creating or revamping your degree plan, it is important to maximize your time and the audit's efficiency by selecting the most appropriate restriction type.

What does the restriction apply to and when to use:

Whole degree plan: Use a degree plan restriction.

One or more scopes: Use a scope restriction.

Some (but not all) requirements for a particular scope: Use a subset restriction.

One requirement: Use a requirement restriction.

One option of a requirement: Use an option restriction.

Ordering your restrictions this way will make the audit more efficient. You will only have the one restriction to override that controls how a course might count toward the degree.

What do you mean minimize branches?

While most requirements are single requirements where the whole requirement can be coded without a branch, there are those that will not fit the simple requirement structure. These more complex requirements are called “branched requirements", and should only be used as a last resort. If you must use a branched requirement, build as few branches as possible. One way to determine if you can code the requirement without a branch is to map it out and see what courses/section/options can be paired together.

The Foreign Language requirement for some degree plans in the College of Natural Sciences is a good example of a branched requirement. The requirement contains option A, the two-semester course requirement; and option B or C, the language/culture course combination with the 2 course culture combination. Option A will not show as met until the student has taken all the required courses. If option A is not satisfied, then it checks option B or C. If there is at least one course that satisfies option B or C, it will show as partially satisfied.

The fewer branches you, have the less time the system takes to process the connected requirements. Combining the branches in a requirement does not equate to limiting the options a student has to meet the requirement.

What do you mean course relations?

When you are building course lists and requirements, you should use the course relations system to guide you. For example, if there are two courses in an inventory-same-as relationship in your course list, IDA 2.0 processing will automatically accept the other as a match, such as in the example below.

Adding both HIS 350L.33 and R S 357.1 to the course list is redundant. Only one of the two is needed.

Conversely, if you need to create a sequence of courses, such as physics, you should rely on the duplicate relationship to your advantage. The degree plan statement for PHY 303K is (Only one of the following may be counted without prior approval of the department: Physics 301, 302K, 303K, 309K, 317K.) The degree plan statement for PHY 303 L is (Only one of the following may be counted without prior approval of the department: Physics 302L, 303L, 309L, 316, 317L.) Therefore, if you require 6 hours of physics you can place all of these courses into one course list with the assurance that if a student were to take, say, both PHY 302K and 303K, one of those courses would be removed as a duplicate. The only reason to break them into different course lists is to ensure that students take the proper sequence of physics courses (PHY 303K & PHY 303L...).

M 808A was retired and replaced with M 408C. Replacement relations are not time bound, so updating the course list with either one of these courses will allow the other course to be picked up as an alias. It is recommended that you use the most recently offered course for this purpose.

Scope Reuse

When the system starts to process a requirement, the first thing it pulls in are courses based on the reuse selection. If you have set your coursework reuse correctly and are sequenced to maximize the effect, then you do not need to restrict the courses that you are not allowing to count for a requirement. Below are two core requirements and one major requirement:

In this example, the major requirement's scope reuse does not allow core courses to count. RHE 306 and E 316K are core requirements that are processed before major rules based on how they are sequenced, but they will not count towards the major because core is not listed under major scope reuse. As a result, no restriction is needed to keep these core courses from counting toward this requirement.