Hierarchy Functional Requirements - Part 2

Owned by Former user (Deleted)
Last updated: Jun 04, 2007Version comment
4 min read

Hierarchy Notes
5/31/07
UM Attendees: Dick Ellis, Lisa Emery, John Leasia
UMD Attendees: Ellen Borkowski, Rick Moyer
Cambridge Attendees: Aaron Zeckoski

For the basic hierarchy, Aaron will be working on five main pieces:

  1. Interface to create hierarchies
    1. The "super eval admin" would use this page (https://courseware.vt.edu/users/aaronz/CourseEval/Redesign/Wireframe/HierarchyControl.html)
    2. The University level could probably be defaulted in (unless we can think of another use for the hierarchy that is not related to universities)
    3. The interface should allow the user to add new entries for the School level and Department level values (these will be defined differently by each university)
    4. At the Department level, the interface should also allow the user to attach "prefix" codes - these codes would need to map exactly to the code of the course being brought into the system.  For example, if courses are brought into the system as BIOANTHRO 115 001, the Department level for Biology would set up a code of BIOANTHRO.  (more on why we want this in part 3)  The 'Add/Modify' page from the wireframes (https://courseware.vt.edu/users/aaronz/CourseEval/Redesign/Wireframe/ModifyHItem.html)should be modified so that more than one prefix could be added for a Title.  Note:  currently, the 'Prefix' field is labeled as 'Abbreviation'.  
  2. Interface to assign Eval Admins to levels (https://courseware.vt.edu/users/aaronz/CourseEval/Redesign/Wireframe/ModifyUser.html)
    1. Option 1 is to go through the hierarchy and attach users to each level
    2. Option 2 is to look up a user and assign all the appropriate permissions to that user
    3. There isn't a strong preference for one or the other option
    4. There needs to be two options for permission settings.  One is for update access, and the other is for view only access (this is intended for users who need to see reports, but won't be setting up evals)
  3. A way to map courses to the appropriate hierarchy
    1. The preference is to have an automated mapping based on "prefix" codes.  This way, users don't have to map each course to the hierarchy.  The tool could take a course, such as BIOANTRHRO 115 001 and traverse the hierarchy by first matching BIOANTRHRO to the Department level prefix code to determine that this course is part of the BIOLOGY department, which is part of the College of Literature, Science, & Arts, which is part of the University of Michigan.  
    2. There also needs to be a way to override the automated mapping for the case of cross-listed courses.  We are considering this out of scope for the initial implementation of hierarchies.  
  4. A way to flag certain templates as default templates
    1. See accompanying wireframe for potential design ideas (Heirarchy design ideas)
    2. Do we need a warning or error handling if more than one template is assigned at the University or School/College level?  Since access will be limited in terms of who has access to do these, maybe it is not necessary.  This implies that the ability to assign hierarchies would need to be based on permission settings.
  5. A way to flag certain evaluations as 'official' so that they traverse the hierarchy and pick up all the appropriate templates at each level
    1. This would probably just be an additional field to select when setting up the evaluation
    2. When a user takes an official evaluation, it would pick up all the hierarchy items as well as the instructor added questions

Additional issues and points of discussion

  • What happens if the sum of the hierarchy questions is more than the maximum number of questions allowed for the evaluation?
    • UMD thought it would be appropriate to drop off questions at the lowest level (so the eval should include the university questions, then if there is availability add the School questions, and then if there is still room for more questions, add the Department questions.  
    • What about instructor added questions?  Would those take precedence over the University level questions?  Or are they the lowest level in terms of precedence?  
  • UM and UMD agreed that there should not be a case where there would be two parents at a node.  
  • There must be a maximum of one template defined for each node.  Should this be enforced by the system?  (for example, if a user tries to assign a template as a university template, but one already exists, should it issue an error message and prevent the user from saving?)
  • Is it necessary to put start and stop dates for template setup at each of the hierarchies?  UMD thought this was a requirement, but they are hoping to handle it procedurally
  • When should the evaluation build from the hierarchy occur?  If it builds when the eval is created, then it will give a more accurate preview of the eval to the instructor.  However, if an admin changes a template after the evals have been built, then they would have to manually fix all those evals.  The other option is to wait and build the entire eval when it is released to the students.  The problem here is if questions have changed after the instructor added questions, there could be duplicate questions.  One solution is to automatically generate emails to everyone assigned to levels below when the eval template changes, so they are aware of the change.  UMD prefers the second option.