KS ENR Functional Training
Module 1:: Understanding KS Enrollment
Getting Started
Presenter: Carol Bershad
Welcome ….
... to the first of six (6) functional training modules on KS
Enrollment
#
Module
Orientation
Follow-up
1
Understanding KS Enrollment
10/19/11
10/27/11
2
Understanding the Enrollment Environment
11/2/11
11/10/11
3
Understanding Course and Course Offerings
11/30/11
12/8/11
4
Understanding Programs and Program Offerings
12/14/11
—
—
1/11/12
Modules 1 – 4 Recap
5
Understanding Cross-Cutting Concepts
1/25/12
2/2/12
6
Understanding Academic Planning
2/8/12
2/16/12
For the most current information and details, please visit KS ENR Functional Training
3
Objectives and Expectations

Overall Training Objective:: To equip participants with a
solid understanding of the functional framework of the KS
Enrollment Module and the associated business artifacts as
they currently exist.
Where we all
WANT TO BE
We are HERE
You are HERE

Module 1 Objectives:: To provide a high-level overview of
KS concepts and materials to facilitate self-study





“Pulling you up”
the KS Project and the associated modules
the functional framework and scope of KS Enrollment
key concepts associated with KS Enrollment
service-oriented architecture and KS Services
the structure and location of KS Enrollment business
artifacts
4
“Teaching you to fish”
Agenda and Presenters
Item
Duration
Presenter
Project Role
Getting Started
30 min
Carol Bershad
Analysis Team, Lead
Product Manager (Interim)
KS Project Overview
30 min
Dan McDevitt
Program Director
KS Enrollment Overview: Framework
30 min
Carol Bershad
KS Curriculum Management Overview
30 min
Dan Symonds
Analysis Team, SME
BREAK
15 min
KS Enrollment (ENR) Overview: Content
60 min
Steve Barnhart
Analysis Team, SME
KS Services Overview
25 min
Cathy Dew
Services Team, Lead
KS Enrollment Application Map Overview
25 min
Kristina Batiste
UX Team, Designer
Wrapping Up
Carol Bershad
Facilitator
Mike Huynh
Analysis Team, BA
Logistics Coordinator
Cheryl Medley
Project Management Coordinator
Critical Observer
Ruth Schleifer
Analysis Team, BA
For agenda details, presenter contact information and supporting materials, please visit
Understanding KS Enrollment
5
Logistics and Ground Rules

Given size of attendance and amount of material to cover,
there will be no interactive Q/A around content

Instead, please:
 Limit questions/comments to logistics
 Post questions/comments regarding content here; these will form
the basis for the Follow-up Session::
KS ENR Training, Module 1:: Questions/Issues




Remain on mute unless asking a question/making a comment
Remain connected during the break
Have patience with any technical issues we might experience!
Take a deep breath ….
6
KS Project Overview
Presenter: Dan McDevitt
What is Kuali?

What is Kuali?
 Community-driven
 Software development
projects
 Coordinated by the
Kuali Foundation
 Resulting in freelyavailable, open source
software products for
higher education
 What is Kuali not?
 Kuali is not a vendor
 Implications
 Community directed
and governed
 Greater control
 Support decoupled
from code
 Few dollars spent on
sales and marketing
 Requires
involvement
What is Kuali?
Open Source Software for Higher Education, by Higher
Education
 Financial System (KFS)
 Research Administration- COEUS (KC)
 Student (KS)
 Open Library Environment (OLE)
 Business Continuity Planning (Kuali Ready)
 People Management for Enterprise (KPME)
 Mobility
 Rice (infrastructure/development tools)
9
What is Kuali Student?
 A Next Generation Student
System which is:

Meeting requirements of the
community

Not just the requirements of
one institution

Being incrementally produced
through a dedicated community
of international higher
education partners

Delivering a rich user experience
using a service-oriented
architecture
10
Who is involved? The Kuali Student Community
Founders
Partners
Naval Post Graduate School
Boston College
University of California, Berkeley
Indiana University
University of Maryland, College
Park
North-West University,
South Africa
University of Southern California
University of Cambridge,
United Kingdom
University of Toronto
University of Washington
Founders = $~1 M/per year for 5 years
How are we organized?
Current Structure
High Level
Kuali Student Board
Program Director
Dan McDevitt
Development Manager
Product Manager
Rajiv Kaushik
Carol Bershad
Services Team
Project
Advisory Group
Functional
Council
QA Manager
Vacant
Cathy Dew - Lead
Subject Matter Experts
Test Engineers
User Experience Team
Business Analysts
Configuration
Management Team
William Washington - Lead
Technical Architect
Larry Symms
Development Team
12
Kuali Student Board
 Set the vision & strategic direction for the project
 Hold regular (monthly) review meetings to monitor the
progress of the project

Champion the solution to be delivered by the project and
support the project objectives within their university and
across the community
13
Kuali Student Functional Council

Ensure that Kuali Student meets the needs of the institution
from a functional/ business requirements perspective

Act as a communicator/ motivator/ marketer,
communicating and promoting project objectives
throughout their founding institution
 Provides direction for scope, plans and key deliverables that
impact overall project direction
14
Kuali Student High-Level Timeline
Enrollment Development Strategy

Phase 1: “Core Slice”
 Lay service foundation: define and exercise most alpha services
 Provides technical/service platform that parallel teams can build


upon
Provides an assemblence of a demonstrable product across core
Enrollment functions
Enables platform for transitioning to contribution/development
model
Kuali Student Enrollment
Development Strategy
For illustration only
Breadth
Depth
PHASE 1 – Foundation (“core slice”)
Course/
Program
Offering
Course
Academic
People Course
Program
Program
Record
Permissions Registration Enrollment Assessment Assessment
Degree
Audit
Enrollment Development Strategy

Phase 2: Transition to Parallel Teams
 Provides opportunity for optimizing resources through proximity,


e.g., face to face, time zone, etc.
Shift some leadership and accountability to institutions responsible
for delivery
Provides potential opportunity/avenue to attract additional
Institutional investment/contributions
Kuali Student Enrollment
Development Strategy
For illustration only
Breadth
Team A
Team D
Team B
Depth
PHASE 1 – Foundation (“core slice”)
Team A
Course/
Program
Offering
Team B
Team C
Course
Academic
People Course
Program
Program
Record
Permissions Registration Enrollment Assessment Assessment
Degree
Audit
Organization Structure for Kuali Student Enrollment Parallel
Development
Kuali Student
Scope Coordination
Product
Management
User
Experience
Architects
Service Governance
Adherence to Infrastructure
Senior
Developers
Team Lead
Business Reqs
Cross Inst Requirements
KS Core Team
Adherence to Standards
Services
Architects
Adherence to UX Model
Code Reviews
QA
Meets Business Reqs
Meets Technical Reqs
Functional
Expert(s)
Multiple
Multiple
Multiple
Parallel
Parallel
Parallel
Teams
Teams
Teams
User
Experience
Designer
Development
Team
High-level Timeline
21
KS Enrollment Overview:
Process, Framework and Scope
Presenter: Carol Bershad
A Brief History of KS Requirements

The Big Bang
 In the beginning , there were five KS “Releases”
R1:
R2:
R3:
R4:
R5:
Curriculum Management
Enrollment and Program Audit
Admissions
Student Financials
Scheduling


And then we actually started releasing …. Release 1 of Release 1?

… however, on the wiki you may still see some dated references to R1 and
R2, particularly “R2 methodology”
“Releases” have been renamed to “Modules,” each of which will have
multiple releases …
 Delivered: Curriculum Management 1.1, 1.2
 Planned: Enrollment Management 1.0, 2.0
23
A Brief History of KS Requirements

The Uncertainty Principle
 “R1” requirements were a bit of a Black Hole
 Collective Use Cases with no institutional traceability

The Expanding Universe
 “R2 Methodology” had each institution providing their



individual requirements …
… for 30 different functional topics, aka “melanges”
The group responsible for this work was the KS Business
Requirements Team
The Unification
 The KS Analysis Team (SMEs, BAs) was formed to create
KS requirements from the institutional material
24
A Brief History of KS Requirements
Institutional Requirements
8 institutions x 30 “melanges”
compilation of material across
institutions and melanges into a
single, consolidated inventory
focused, in-depth interpretation of
the materials and the desired
functionality they represent
Synthesis
Analysis
Team
Cross-functional
Analysis and Design
Analysis
Team
Requirements
10 Functional Areas
Parallel
Delivery
+
Services
+
UX
KS System Requirements include:
• Terminology
• Requirement Statements
• User Stories
• BPMs
• Rules Examples
• Data
See for Appendix for Traceability
25
Institution Facing
Catalog
Student Facing
Set up Users
Manage Info and
Preferences
Holds
Explore
Programs
Offer
Programs
Offer
Courses
Academic
Record
Register for
Courses
Enroll in
Programs
Grade
Courses
Setup the
Environment
Exemptions
Plan
Programs
Assess
Progress in
Programs
KS ENR Functional Framework
Institution Facing
Curriculum
Management
Student Facing
2. People and
Permissions
2. People and
Permissions
X-cutting
9. Academic
Planning
6. Program
Offering
3. Course
Offering
KS
Financials
10. Academic
Record
4. Course
Registration
7. Program
Enrollment
UW My
Plan
5. Course
Assessment
1. Setup
X-cutting
9. Academic
Planning
8. Program
Assessment
KS ENR:: 10 Functional Areas
KS Enrollment Scope
E1 … Deliver the Basics
E2 and Beyond … Deliver the Vision
Institution Facing
Student Facing
1. Set Up
ENR 1.0
ENR 2.0 and beyond
2. People and Permissions
3. Course Offering
4. Course Registration
5. Course Assessment
6. Program Offering
KS ENR Scope (WIP)
7. Program Enrollment
8. Program Assessment
9. Academic Planning
10. Academic Record
28
Come meet Curriculum Management
Presenter: Dan Symonds
Institution Facing
Curriculum
Management
Student Facing
2. People and
Permissions
2. People and
Permissions
9. Academic
Planning
6. Program
Offering
3. Course
Offering
10. Academic
Record
4. Course
Registration
7. Program
Enrollment
5. Course
Assessment
9. Academic
Planning
1. Setup
8. Program
Assessment
Objectives

Provide a conceptual understanding of the Curriculum
Management module
 Focus on Course and Program

Focus on CM concepts important to understanding
Enrollment Functionality
31
What is a “Learning Unit”

Concept representing any component of learning completed
as part of the student learning experience


Represent the core products of the institution
Can be highly regimented and coordinated or flexible and
loosely coupled activities
 Flexible enough to support a wide diversity of learning
experiences
32
Types of Learning Units
 Courses
 Programs
 Projects

Thesis Research, Dissertation Research, Independent Projects,
Performance Projects
 Experiential Learning

Internships, Externships, Cooperative Work Study, Practica, Life
Experience
 Examinations and Competencies

Comprehensive or Qualifying Exams, Competency Exams, Music Juries,
Doctoral Dissertation Defense
33
Curriculum Management

Controls the creation and management of an institution’s
inventory of learning experiences (LUs)


Viewing, creating, modifying, retiring curricula
Development and approval of curricula through
collaboration and workflow
 Enables curriculum managers to understand the
relationships/dependencies between curricula
34
Key Concepts: Canonical vs. Instance LUs
 Canonical LU
 Catalog Course
 Learning Unit Instance (LUI)
 Course Offering
2012-2013 Undergraduate Catalog
Spring 2012 Schedule of Classes
ENGL206: Shakespeare
ENGL206: Shakespeare
Shakespeare's poems, history plays,
comedies, and tragedies as
investigations into language use,
governance, sexuality, ethics, and
mortality
0101 G. Passannante
Lec TuTh 11:00am-11:50am (JMZ 0220)
Dis F 10:00am-10:50am (TWS 0234)
0102 G. Passanante
Lec MW 10:00am-10:50am (JMZ 0220)
Dis F 1:00pm-1:50pm (TWS 0234)
35
Types of Courses
 Credit Courses
 Non-Credit Courses
 Special Topics Courses
 Various Topics Courses
 Modular Courses
 Sequence Courses
36
Course Concepts

Cross Listing
 Same course published and offered using multiple course reference
numbers from different departments


SOCY325/WMST325 – Sociology of Gender
Joint Offering
 Two or more courses that may “meet with” one another with the


same meeting location, day/time, and instructor when deployed
Learning objectives for each course may differ
Generally occurs when the courses cover a common subject area


RUSS409V Russian Language Study: Verbal Aspects
RUSS618V Linguistic Analysis of Russian: Verbal Aspects
37
Course Activities and Formats

Activities
 Courses offerings consist of one or many activities
 Lecture, Lab, Discussion/Recitation, Seminar, etc

Formats
 Allowable combinations of activities
 Can support one or multiple combinations for a single course

Highly Configurable
 Constraints between activities and formats vary amongst institutions
38
Course Sets

One or more courses (or course sets) used in the creation of
a rule statement

Used in the context of LU rules
 Course Rules examples

Prerequisites, Corequisites, Student Eligibilities
 Program Rules



Completion, Satisfactory/Benchmark, Entrance
Dynamic Course Sets
Named Course Sets
 A set of courses which is reused across multiple rule statements
 Able to be managed outside of the individual rule statement for
which it is used
39
What is a program?

A prescribed group of learning units that lead to a
recognized body of knowledge

Can consist of courses, activities, competencies, learning
objectives, requirements, other programs

End result may be an acknowledged level of accomplishment
or a credential
Oh yes, the lower case “p” in program is quite intentional
40
Types of programs









Baccalaureate, Masters, Doctoral, Professional (J.D., M.D, etc)
General Education/Core
Major Discipline (Academic Programs)
Specializations/Concentrations
Minors
Variety of Certificates
Discipline-related honors programs
Living/Learning Programs
Module Courses/Course Clusters (crossover)
Is that lower case “p” still bothering you? Better not be…
41
Program Logical Model
42
Challenge: Canonical Program vs. Program Offering

Functionality well exposed in certain types of programs
 Entrepreneurial programs (Executive MBA Programs)
 Progress in program a factor of the program, not the student

Not exposed as well in traditional programs
 Traditional undergraduate programs (Sociology)
 Progress in program a factor of the student, not the program

More conceptual analysis
43
KS Enrollment Overview
Presenter: Steve Barnhart
KS Enrollment Overview - Introduction

Objectives
1. To provide a high-level
2.
3.
understanding of the functional
areas of the Kuali Student Enrollment
module
To provide an understanding of how
KS Enrollment builds off of KS
Curriculum Management
To lay the ground work for more
detailed discussions in future KS
training modules, deep dives
45
Institution Facing
Curriculum
Management
Student Facing
2. People and
Permissions
2. People and
Permissions
9. Academic
Planning
6. Program
Offering
3. Course
Offering
10. Academic
Record
4. Course
Registration
7. Program
Enrollment
5. Course
Assessment
9. Academic
Planning
1. Setup
8. Program
Assessment
1. Set Up (Time)

Academic Years and Terms
 Establish calendars


Holidays
Instructional days
 Establish academic year(s)
 Establish terms and sub-terms
 Define milestones






Registration periods
Add periods
Drop periods
Grade submission periods
Final examination schedule
Census date
47
1. Setup (Environment)

Course Registration Environment
 Global registration rules


Maximum/Minimum units/credits per term
Mandatory advisement requirements
 Establish registration appointment times for term
 Assign registration appointment times to populations of students

Hold and Exemption Types
48
2. People and Permissions

People as actors
 Associate people with






organizations
Defining role-based authorizations
Delegate authorizations
Interface with HR systems
Interface with other external
systems
Third party access and
permissions
People as objects
 Interfaces with internal and

external systems
PESC alignment
49
Institution Facing
Curriculum
Management
Student Facing
2. People and
Permissions
2. People and
Permissions
X-cutting
9. Academic
Planning
6. Program
Offering
3. Course
Offering
KS
Financials
10. Academic
Record
4. Course
Registration
7. Program
Enrollment
5. Course
Assessment
1. Setup
X-cutting
8. Program
Assessment
9. Academic
Planning
UW My
Plan
3. Course Offering

Canonical Course
 Approved at the curriculum level
 One or more formats, each with one or
more activities (lecture, lab, etc.)

Course Offering
 Specific instance of a canonical course



within a valid term
Scheduled at the activity level (lecture,
lab, discussion, etc.)
Creation can occur through rollover or
one-off
Instructor assignment
51
3. Course Offerings

Course Offerings (cont.)
 Room and time assignments via interface with institutional



scheduling systems (R25, Ad Astra, etc.)
Additional registration eligibility restrictions, beyond canonical
definitions
Seat pool definitions to further restrict registration by population
Waitlist definitions

Course or section-level
 Refine course or activity specific fees
52
4. Course Registration

Registration eligibility validation
 Term specific requirements
 Annual and term-based acknowledgements
 Appointment times
 Holds
 Schedule builder
 Integration with learning plan
 Integration with degree audit

Registration cart
 Groups of drop and add
transactions
53
4. Course Registration (cont.)

Course-specific registration eligibility validation




Class/Year levels
Majors
Minors
Requisites (pre-, co- and anti-)
 Waitlists
 Student schedule validation for
special populations




Student athletes
International students
Veterans
Tuition and fee calculation*
*Sigma Student Financials Project
54
5. Course Assessment
 Midterm and final grade submission
 Change of grade processing
 GPA calculation rules
 Term GPA
 Cumulative GPA
 Program GPA

Grade distribution reporting
(mean, median, mode)
55
Institution Facing
Curriculum
Management
Student Facing
2. People and
Permissions
2. People and
Permissions
9. Academic
Planning
6. Program
Offering
3. Course
Offering
10. Academic
Record
4. Course
Registration
7. Program
Enrollment
5. Course
Assessment
9. Academic
Planning
1. Setup
8. Program
Assessment
6. Program Offerings

Canonical Programs
 Approved at curriculum level
 Never directly associated to

students
For all types of programs
(credential, major, minor)
 Program Offering
 Specific instance of a



canonical program for a term period
Multiple program offerings for each canonical program
Most undergraduate programs will be on-going
Lock-step programs may have a program offering for each cohort
57
7. Program Enrollment

Open/unrestricted programs
 No admissions criteria
 No capacity limitations

1st-come, 1st-served programs
 No admissions criteria
 Capacity limitations

Restrictive programs
 Admissions Criteria
 No capacity limitations

Selective/competitive programs
 Admissions Criteria
 Capacity limitations
58
7. Program Enrollment (cont.)

Application process
 Review eligibility
 Complete application
 Attach any required documents
 Route through any approval process
 Notify applicant

Termination
 Program withdrawal
 Stop-outs
 Disqualifications
59
8. Program Assessment

Assessment of Satisfactory Progress Requirements
 Learning results calculated/consumed





Term GPA’s
Cumulative GPA’s
Units/Credits completed
Terms/Years completed
Milestone achievement
 Potential actions


Probation
Dismissal
 Applied at various levels



Institutional
College
Program
60
8. Program Assessment (cont.)

Assessment of Completion Requirements
 Short Term :: integrate with 3rd party
 Long Term :: build KS module

Assessment of Graduation
Clearance Requirements
 Identifying candidates
 Accepting applications
 Clearing required steps
 Posting degree
 Notifying candidates
61
Institution Facing
Curriculum
Management
Student Facing
2. People and
Permissions
2. People and
Permissions
9. Academic
Planning
6. Program
Offering
3. Course
Offering
10. Academic
Record
4. Course
Registration
7. Program
Enrollment
5. Course
Assessment
9. Academic
Planning
1. Setup
8. Program
Assessment
UW My
Plan
9. Academic Planning

Learning Plans
 Development of sample learning plans for specific programs
 Coordination of LP between student and academic advisor
 Integration of LP with ::




Term schedule of classes
Registration Schedule Builder
Academic record (grades)
Degree audit system
(program requirements)
63
9. Academic Planning

UW MyPlan
 Funded by student technology fee to improve student academic



planning and advisement
Learning Plan “Lite”
Allows students to identify and
select courses to meet their
program goals
Learning Plans will integrate
with UW’s existing systems


Schedule of classes
Degree audit system
 Based on KS technology stack (as possible)
 To be contributed back to KS
64
Institution Facing
Curriculum
Management
Student Facing
2. People and
Permissions
2. People and
Permissions
X-cutting:
Holds
9. Academic
Planning
6. Program
Offering
3. Course
Offering
10. Academic
Record
4. Course
Registration
7. Program
Enrollment
5. Course
Assessment
1. Setup
X-cutting:
Exemptions
8. Program
Assessment
9. Academic
Planning
UW My
Plan
10. Academic Record

A virtual collection of “things” related to a student’s learning
experience at an institution


At a minimum, it is the data needed to produce a transcript
Data includes
 Program information
 Graded courses by term
 Grades received
 Unit/credit totals
 GPA calculations
 PESC aligned
66
10. Academic Record (cont.)

Data (continued)
 Degrees awarded
 Transfer course work and evaluation
 Term and graduation honors
67
Cross-cutting Concepts

Holds
 Associated to a student


For a given time period
May be a date range, or term specific
 Usually originates from another system

Housing, health services, parking, etc.
 May prevent a variety of activities

Registration, dropping classes, adding
classes, obtaining a transcript, etc.
 Must be removed or overridden
68
Cross-cutting Concepts (cont.)

Blocks
 Real-time evaluations of student attributes which determine
limitations on actions

Requisite checking, course registration restrictions, etc.
 Change if the student’s attributes change
 May be exempted
69
Cross-cutting Concepts (cont.)

Exemptions
 Persisting, time-based grant of an exemption to a given policy which



usually invalidates some form of block
May be initiated by students, instructors or advisors
Request process with workflow dependent on specific type of
exemption requested
Examples




Prerequisite
Program level restrictions
Year/Class level restrictions
Degree audit requirements
70
KS Services Overview
Presenter: Cathy Dew
Service Oriented Architecture

What is SOA?
 Set of principles and methodologies for designing


and developing software in the form of
interoperable services
Well-defined business functionalities that are built
as software components (discrete pieces of code
and/or data structures) that can be reused for
different purposes
Why SOA?
 Development advantages :: software reuse,

productivity increases, increased agility
Strategy advantages :: better alignment with the
business
What are Service Contracts?

Contract Definition
 Operations (functions)
 Message Structures (data objects and
parameters)

Contract Implementation
 Code to implement the contract that can then
be used by the Application Layer to deliver
features

Advantages
 Provide a stable but abstract layer between the Application (screen
flow and UI) and Data Persistence (underlying database)


Contracts should change much less than the impl or the UI
Allow the implementations and UI to evolve independently
Service Classification


R1.1 had concept of "Entity" services and "Business" services


Class I




With ENR, we have implemented a “classification” system
Supports striated governance to support various development and
delivery efforts
Single focus, self-contained = atomic
May or may not be "business-speak,“ e.g., LU, LO, LRC, Comment and
Document
Tightly governed by Service Team
Class II



Composed services, refer to more than one
Class I service
Business speak, understood (and validated) by
BAs and SMEs, e.g., Course, Program, Course
Offering and Course Registration
Expect changes by Parallel Teams, with rigorous review
Service Classification (cont.)
 Class III



KS Contributions
Not part of KS proper but may become so
Current projects include UW MyPlan
and Sigma’s Student Financials
 Class IV

RICE services, not part of KS but part of
Kuali, e.g., KEW interfaces, KIM interfaces,
KRMS, KRAD

Governance controlled by Kuali Working
Groups

Expect to augment RICE development with
KS resources
Services Design Process
INPUT
PROCESS
OUTPUT
BUSINESS ANALYSIS
Review high-level business artifacts
Candidate Services
•
High-level Features
Group into areas for use cases
•
Business
Requirements
For each Service (Class I and II)
•
Terminology
•
User Stories
•
BPM
•
Rule Candidates
•
Application
•
Diagram “logical” entities
•
Explore service layering
•
Define functions & data bits
Develop Formal Contracts
Data
DEVELOPMENT
•
Analysis
& Design
Core Slice
Refine Formal Contracts – ALL
Artifacts (release process)
(See Service Index)
WIKI Artifacts
(See Service Description
Repository)
Code Artifacts
(See KS 1.3 Branch)
Released Service
Contracts
Service Contract Artifacts

Wiki Artifacts




Narrative description and assumptions
highlighting key concepts
Entity diagram and service layering (Class I to
Class II)
Type / State configuration
Code Artifacts






Interface(s) for service contract and message
structures
DTO beans for message structures
implementing their interfaces
Generated WSDL, JAXWS package (if required)
Constants file for our types and states
Dictionary XML (stub to start with)
Mock impl(s)
Example :: Class II and Class I

From Curriculum Management
Example :: Class II and Class I

As we move into Enrollment
Academic Calendar (ACAL)
Academic Time Period (ATP)
You are here:
KS Enrollment Application Map Overview
Presenter: Kristina Batiste
Answers to all your questions.
 What is the application map?
 Why do we need one?
 How can we use it?
 Where can we find it?
81
What is it?
 Story Arc Swimlanes
beginning-to-end ‘stories’ that combine high level
features/functional areas into UX-friendly
groupings
 Skeleton Sitemap
interactive, early stage sitemap for ENR.
See what you can do, where you can do it
 Functionality Table
Collected functionality (found on map) made
scan-able
82
How to use it:
Orientation when approaching design:
 Guide thinking about where features live
 Help build screenflows
 Suggest ways of accessing functionality in more than one
location
By keeping the big picture in mind, we can avoid:
 designing bits and pieces of KS in isolation
 proliferation of hub screens that could be effectively

combined or eliminated
building the online equivalent of the Winchester Mystery
House
83
Why do we need it?
Because
UX designers
pictures.
♥
It was developed both as a means of thinking about and processing the ENR space,
and of helping UX quickly pick up and understand ENR functionality and features.
 Gives an overview of how features interact/intersect
 Illustrates who does what, how often
 Shows where users go to start tasks.
(Note that this is a 'skeleton map' and will be fleshed out and likely change during
parallel development. What, you didn’t think it was done, did you?)
84
Where to find it:
Here.
85
Wrapping Up
Presenter: Carol Bershad
Next Steps
 Module 1:: Follow-up



Date: October 27, 2011
Time: 12pm – 2pm ET | 9am – 11am PT
Post questions/issues: KS ENR Training, Module 1:: Questions/Issues
 Module 1:: Evaluation

Please complete short survey:: KS ENR Training - Module 1 Evaluation
 Module 2:: Understanding the Enrollment Environment



Date: October 27, 2011
Time: 12pm – 4pm ET | 9am – 1pm PT
Functional Areas
1.
2.
Set Up
People and Permissions
87
Appendix: Traceability
Requirement Statement Traceability
Example: KS System Requirements - Course Offering
89
Requirement Statement Traceability
90