Kuali Student is driven by the business requirements of the functional members of our team. Without the hard work of our functional members, the project would have no idea what features the product needs to have. There would also be no one to actually use the product!
To find out more information about a Functional role, click on their name in the list below:
Along with each set of requirements, institutions may have also included Process Diagrams or Flow Charts and examples of data. In some cases, they are broken into sub-processes. Requirements are coded.
Course (Canonical Learning Unit)- This is the level you'd find in your system of record, like an approved course in Curriculum Management
Course Offering - The Course is then offered during a specific term (such as Autumn 2012 in the example above)
Format Offering - Some Course Offerings require multiple pieces to be completed in order for a student to receive credit. This level outlines what combination of formats are permissible. For example, a science course may be equally valid as a Lecture+Lab combination, or as just a Lecture without the lab.
Activity Offering - This creates an object for every iteration of the possible format offering as well as a date and time. Ex. this is where you designate Tuesdays and Thursdays from 8-10am. So, if you have a Lecture+Lab format offering and want to offer one lecture
Registration Group - What a Student would click on to register for a specific combination of Activity Offerings. Now that the system knows what format combinations are permissible, you can decide which specific instances of the course during that term can be combined together to make a complete experience. This is also where you would designate if certain lectures and labs should be taken in combination (for example, if Prof A's TA teaches Lab A, you might want to say that students in Lecture A can only take Lab A. If that's the case, you'd make a Registration Group for Lecture A + Lab A and not one for Lecture A + Lab B)