Degree Audit User Training | Requirements

Building Requirements

Before building a requirement for your degree plan, you will need to determine the appropriate requirement type. IDA currently supports four different requirement types, each with varying sets of metadata and course list flexibility. You are required to save the metadata for a new requirement before it can be inserted and manipulated within the degree plan. All requirements carry some kind of metadata. Certain requirements do not become valid until at least one section and option have been added. Please see Requirement Types for more information on the different types of requirements.

Jump to >> Copying Requirements |Course Requirements | Totals Requirements | GPA Requirements | Proficiency/Portfolio Requirements

Copying Requirements

The copy function allows you to copy coursework requirements, restrictions, totals, and GPA requirements from one catalog and degree plan to another in Prod Setup.

Users can copy any requirement type from:

1. Major degree plan to another major degree plan
2. Minor/certificate to another minor/certificate
3. Major degree plan to minor/certificate (Scope will automatically be set to minor/certificate, no matter what scope type the major has)

Users can copy any restriction type from major degree plan to major degree plan. Minors and certificates don’t have independent restrictions and therefore cannot receive them.

Access: To access the copy function, click on any requirement or restriction and go to the top of the metadata page:

Select a catalog and degree plan, then click on copy (Note that a catalog must always be selected). A successful copy will take users to the requirements/restrictions listing page for the new rule. The new rule may need to be re-sequenced and then migrated to Live.

Users will receive an error message that the copy was unsuccessful if no coursework requirement was found for the requirements being copied.

Limitations:

1. You cannot copy subset restrictions.
2. When copying branched requirements, only the parent requirement can be copied. The branches will have to be created manually.

Course Requirements

Course requirements typically seek specific coursework. The metadata is used to form the basis and parameters of the requirement. Below is the available metadata.

Scope:

Scope carries two major functions: it determines where in the audit the requirement appears, and it identifies the requirement's availability for later reuse. If you are assigning Core scope to a requirement, a core code must be provided. See the Scope page for more information on how scope functions in IDA.

Credential Type:

This field is automatically populated based on the degree plan code and may not be changed. Valid types include Major, Minor, and Certificate.

Description:

On a completed audit, this describes the requirement for students and advisers. It is typically closely related to statements from the degree plan. You are allowed 250 characters in this space to describe the requirement.

Administrative Notes:

This field allows for administrative notes to be kept and read if a requirement needs further clarification for an adviser. Administrative notes only appear on the requirement's page; they are not displayed on the completed audit and thus are not available to students.

Prohibit Trumping:

Checking this box will not allow any requirements existing at a lower level to trump this requirement.

Scope Reuse:

This defines which courses used for previous scopes will be allowed to count for this requirement. It does not determine what scopes the courses used in this requirement can also count in. You can select any scope or no scopes to allow for reuse. See the Scope page for more information on how scope functions in IDA.

Coursework Use/Reuse:

This defines which courses used for previous requirements will be allowed to count (or be prevented from counting) for this requirement. This is useful if you do not want to allow reuse for all requirements with a given scope. The fields are populated with requirement IDs.

Exclude unused coursework:

Checking this box will prohibit all unused courses from being allowed to count for this requirement. Keep in mind that if exclude unused course work is checked "yes", then the course must have been previously used for the scope listed under scope reuse in the requirement. If exclude unused course work is checked "no", then the course is not reusable if any scope has applied that is not listed in scope reuse.

Exclude partially used courses:

Checking this box will prohibit left over hours from previous requirements from filtering into this requirement.

Setting satisfaction requirements:

This option enforces when the requirement must be satisfied. By selecting an option other than "Any," you mandate a time when the student must take the course. For example, if you select "Summer," and the student takes the course during the fall semester, that course will not count for this requirement.

Related by Field of Study:

These options manage student's coursework across requirements by forcing them to be either the same or different fields of study from other requirements. This could be useful if you have a two part foreign language requirement that requires two different languages. You can require one requirement to have a different field of study from the other.

Related by Course list:

These options manage students' coursework across requirements by forcing them to use either the same or different course lists from other requirements.

Proficiency Override:

This check box is used for course seeking proficiency. If the degree plan requires a student to take a course (or series of courses) until a faculty member says the student is “proficient,” having this check box selected will make the requirement show as “not complete” until an override is performed on the requirement and the box is unchecked. If you are building a requirement that does not seek specific courses for proficiency, you are encouraged to use the proficiency requirement type instead of this check box. A proficiency note may also be included.

Section Relationships:

When building your requirement, you have the option of defining across the sections how the courses are being used.

Section Field of Study:

If you would like for the same or a different field of study to be used across the sections of the same requirement, you will want to select one of these radio buttons. This is most commonly used when building foreign language requirements.

Section Course List Relationships:

Just like the field of study relationship, you can elect to have the student use either the same course list or a different course list across all sections in your requirement.

Display missing courses:

NOTE: **This option is not currently active.** If a student does not meet a requirement and this box is checked, the system will display courses that are in the course list that could meet this requirement.

Sections required:

Use this option for your requirement if you have a multi-section requirement and the student is not required to satisfy all sections. By default, all sections will be required.

The non-obligatory sections option is commonly used when dealing with foreign language proficiency where one course will meet the proficiency of the requirement. This is not to be confused with either the proficiency override option or the proficiency requirement type. To create this requirement, sequence the sections so the one that will meet the proficiency is the first section in the requirement. The non-obligatory sections may follow.

Estimated Hours Required:

The number provided here determines how many hours from this requirement are added to calculate Progress Toward Degree. This should not be confused with the number of hours or courses required to satisfy the requirement.

Once you are finished with all the metadata required for this requirement, clicking the add button will generate a new requirement ID and place it at the top of the course requirements page. You are now ready to start defining the sections, options, and requirement restrictions for this requirement.

Once the metadata is complete and the requirement is created, you can begin defining the courses that are required to meet this requirement. Each section can typically be considered an AND logical statement if you have not defined a specific number of sections that are required to meet the requirement. Therefore, if you have three sections coded, each section must be met before the total requirement is finished and complete.

Within each section you can define options that can be used to meet the section requirement. Each option can be set to require:

• All
• Hours
• Courses

It is suggested that you set either hours or courses when defining the requirement based on your course list. The reason for this is the display of what is required is independent of the listing in the course list and will show under required “unknown”.

Within each option, you are allowed to have fifty course lists defined that the system will chose from when comparing the course filters against the student's record to determine if the courses will count towards the requirement parameters. In terms of processing, the first course list in the option will be processed first and then through each one in order until either the requirement is met, or all course lists are processed.

If there are multiple options and the first option is not met, then the system will go back through the same process for each option until either the requirement is met or all options have been processed.

If there are multiple sections, then the above process is repeated until all sections are complete or all have been processed.

Within each option you have the option to restrict courses for one specific option with up to fifty course lists limiting courses for one specific option, and also define ten course lists that are exceptions to the option restriction. There is a more detailed discussion of restrictions in the restrictions module.

Finally you can set requirement restrictions to further restrict courses before processing of the requirement. In terms of processing the restrictions for a requirement, the first things processed are the requirement restrictions, and then option restrictions.

Totals Requirements

A total requirement should be used to count up courses in batches that are required for your degree plan. Some examples are: total number of hours required for the degree, the number of upper division hours required for a degree, last hour limits, or anything else where you would like to total up the courses the student has taken.

When creating a totals requirement, you are presented with almost the same metadata as a course seeking requirement with the exception of required sections, etc. A couple of things to note about these types of requirements if you are looking to total the courses used for a specific scope, then you will always want to exclude unused and partially used courses. This will force the system to only pull in the courses for the scope that you choose for reuse.

You can either leave it at that or use a course list to count or restrict courses from counting toward this requirement.

GPA Requirements

GPA requirements function just like total requirements, except they are going to calculate a grade point average of either the scope reuse set or from the course list that is present on the requirement.  The courses are processed through the official gpa calculation module.

Proficiency/Portfolio Requirements

Unlike a course seeking proficiency/portfolio requirement, you should use this requirement type when setting up a requirement that cannot be met through any course seeking means. Once the requirement is created when a student fulfills the requirement, you will waive the requirement to show it as complete.