Skip to end of metadata
Go to start of metadata


Training HomeOnboarding SequenceFunctional Roles HomeTechnical Roles HomeTraining Events


About the Functional Team Roles

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: 

Functional Curriculum - A deep dive into learning objectives for your functional onboarding.

Key Documents and Artifacts Diagram

  Gliffy Zoom Zoom Key Documents and Artifacts

Key Artifacts and Documents

Numbers in the first column align with the artifacts in the diagram above.


Business Requirements Repositories  

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.  


BRT Melange Repository  

These processes and sub-processes were compiled using “card sort” to group similar areas of functionality across the different institutions and placed into categories.   


R2 Analysis - Requirements Workspace  

We did a Synthesis of all requirements. Coded synthesised requirements traced back to institutional requirements


KS System Requirements - ENR  

What are we building in KS


Feature Lists:

Academic Planning

Curriculum Management


High-level statements of functionality envisioned in the KS scope, by module

KS ENR High-Level Design Specifications (HLDS)  

Analysis of all artifacts done to create HLDS with contributions from Services and UX.  These were not actually High Level.


Epic Repository  

Current Streams of Work for Core Analysis


Service Description Repository  


Type/State Change Process


R2 Setup - F2F Work Products





Analysis Lifecycle Diagram

Core A&D Tasks and Timeline 

The envelope icon indicates where JIRAs would be created to document this body of work 

Gliffy Zoom Zoom Analysis Lifecycle Diagram







Learning Units Conceptual Model

Gliffy Zoom Zoom LUI conceptual model

 Click here for definitions of each level...
  • 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)



Return to the General Knowledge Page

  • No labels