KS ENR Functional Training Module 1:: Understanding KS
Enrollment
Slide 2
Getting Started Presenter: Carol Bershad
Slide 3
... to the first of six (6) functional training modules on KS
Enrollment For the most current information and details, please
visit KS ENR Functional TrainingKS ENR Functional Training 3
Welcome . #ModuleOrientationFollow-up 1Understanding KS
Enrollment10/19/1110/27/11 2Understanding the Enrollment
Environment11/2/1111/10/11 3Understanding Course and Course
Offerings11/30/1112/8/11 4Understanding Programs and Program
Offerings12/14/11 Modules 1 4 Recap1/11/12 5Understanding
Cross-Cutting Concepts1/25/122/2/12 6Understanding Academic
Planning2/8/122/16/12
Slide 4
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. Module 1 Objectives:: To provide a high-level overview of KS
concepts and materials to facilitate self-study 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 Objectives and
Expectations You are HERE We are HERE Where we all WANT TO BE
Teaching you to fish Pulling you up
Slide 5
For agenda details, presenter contact information and
supporting materials, please visit Understanding KS Enrollment
Understanding KS Enrollment 5 Agenda and Presenters
ItemDurationPresenterProject Role Getting Started30 minCarol
BershadAnalysis Team, Lead Product Manager (Interim) KS Project
Overview30 minDan McDevittProgram Director KS Enrollment Overview:
Framework30 minCarol Bershad KS Curriculum Management Overview30
minDan SymondsAnalysis Team, SME BREAK15 min KS Enrollment (ENR)
Overview: Content60 minSteve BarnhartAnalysis Team, SME KS Services
Overview25 minCathy DewServices Team, Lead KS Enrollment
Application Map Overview25 minKristina BatisteUX Team, Designer
Wrapping UpCarol Bershad FacilitatorMike HuynhAnalysis Team, BA
Logistics CoordinatorCheryl MedleyProject Management Coordinator
Critical ObserverRuth SchleiferAnalysis Team, BA
Slide 6
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 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 Logistics and Ground Rules
Slide 7
KS Project Overview Presenter: Dan McDevitt
Slide 8
What is Kuali? Community-driven Software development projects
Coordinated by the Kuali Foundation Resulting in freely- available,
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?
Slide 9
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?
Slide 10
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 What is Kuali
Student?
Slide 11
Who is involved? The Kuali Student Community Founders = $~1
M/per year for 5 years Founders Naval Post Graduate School
University of California, Berkeley University of Maryland, College
Park University of Southern California University of Toronto
University of Washington Partners Boston College Indiana University
North-West University, South Africa University of Cambridge, United
Kingdom
Slide 12
12 How are we organized? Current Structure High Level Program
Director Dan McDevitt Kuali Student Board QA Manager Vacant Product
Manager Carol Bershad Development Manager Rajiv Kaushik Services
Team Cathy Dew - Lead Development Team Technical Architect Larry
Symms Subject Matter Experts Business Analysts Test Engineers
Configuration Management Team User Experience Team William
Washington - Lead Functional Council Project Advisory Group
Slide 13
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 Board
Slide 14
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 Functional Council
Slide 15
Kuali Student High-Level Timeline
Slide 16
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
Slide 17
Kuali Student Enrollment Development Strategy Course/ Program
Offering People - Permissions Program Enrollment Course Assessment
Course Registration Program Assessment Academic Record Degree Audit
Breadth Depth PHASE 1 Foundation (core slice) For illustration
only
Slide 18
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
Slide 19
Kuali Student Enrollment Development Strategy Course/ Program
Offering People - Permissions Program Enrollment Course Assessment
Course Registration Program Assessment Academic Record Degree Audit
Breadth Depth PHASE 1 Foundation (core slice) Team A Team B Team C
Team D For illustration only
Slide 20
Organization Structure for Kuali Student Enrollment Parallel
Development Kuali Student Senior Developers User Experience
Architects Services Architects Scope Coordination Business Reqs
Cross Inst Requirements Service Governance Adherence to
Infrastructure Adherence to UX Model Code Reviews Adherence to
Standards Meets Business Reqs Meets Technical Reqs Product
Management KS Core Team QA Multiple Parallel Teams Multiple
Parallel Teams Development Team User Experience Designer Team Lead
Functional Expert(s) Multiple Parallel Teams Multiple Parallel
Teams Multiple Parallel Teams Multiple Parallel Teams
Slide 21
21 High-level Timeline
Slide 22
KS Enrollment Overview: Process, Framework and Scope Presenter:
Carol Bershad
Slide 23
The Big Bang In the beginning, there were five KS Releases R1:
Curriculum Management R2: Enrollment and Program Audit R3:
Admissions R4: Student Financials R5: Scheduling And then we
actually started releasing . Release 1 of Release 1? 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 however, on the wiki you may still see some
dated references to R1 and R2, particularly R2 methodology 23 A
Brief History of KS Requirements
Slide 24
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
Slide 25
25 A Brief History of KS Requirements Synthesis
Cross-functional Analysis and Design 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 Requirements Parallel Delivery 10
Functional Areas Analysis Team UXServices + + KS System
RequirementsKS System Requirements include: Terminology Requirement
Statements User Stories BPMs Rules Examples Data See for Appendix
for TraceabilityAppendix
Slide 26
Offer Courses Register for Courses Grade Courses Enroll in
Programs Assess Progress in Programs Explore Programs Plan Programs
Offer Programs Setup the Environment Set up Users Student
FacingInstitution Facing Manage Info and Preferences Holds
Exemptions Academic Record Catalog KS ENR Functional Framework
Slide 27
3. Course Offering 4. Course Registration 5. Course Assessment
7. Program Enrollment 9. Academic Planning 6. Program Offering 1.
Setup 2. People and Permissions Student FacingInstitution Facing 2.
People and Permissions X-cutting 10. Academic Record Curriculum
Management 8. Program Assessment UW My Plan KS Financials KS ENR::
10 Functional Areas
Slide 28
28 KS Enrollment Scope 2. People and Permissions 1. Set Up 3.
Course Offering 4. Course Registration 5. Course Assessment 6.
Program Offering 7. Program Enrollment 8. Program Assessment 9.
Academic Planning 10. Academic Record Institution FacingStudent
Facing ENR 1.0 ENR 2.0 and beyond KS ENR Scope (WIP) E1 Deliver the
Basics E2 and Beyond Deliver the Vision
Slide 29
Come meet Curriculum Management Presenter: Dan Symonds
Slide 30
3. Course Offering 4. Course Registration 5. Course Assessment
7. Program Enrollment 9. Academic Planning 6. Program Offering 1.
Setup 2. People and Permissions Student FacingInstitution Facing 2.
People and Permissions 10. Academic Record Curriculum Management 8.
Program Assessment
Slide 31
Provide a conceptual understanding of the Curriculum Management
module Focus on Course and Program Focus on CM concepts important
to understanding Enrollment Functionality 31 Objectives
Slide 32
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 What is a Learning
Unit
Slide 33
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 Types of Learning Units
Slide 34
Controls the creation and management of an institutions
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
Curriculum Management
Slide 35
Canonical LU Catalog Course 2012-2013 Undergraduate Catalog
ENGL206: Shakespeare Shakespeare's poems, history plays, comedies,
and tragedies as investigations into language use, governance,
sexuality, ethics, and mortality Learning Unit Instance (LUI)
Course Offering Spring 2012 Schedule of Classes ENGL206:
Shakespeare 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 Key
Concepts: Canonical vs. Instance LUs
Slide 36
Credit Courses Non-Credit Courses Special Topics Courses
Various Topics Courses Modular Courses Sequence Courses 36 Types of
Courses
Slide 37
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
Concepts
Slide 38
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
Activities and Formats
Slide 39
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 Course Sets
Slide 40
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 40 What is
a program? Oh yes, the lower case p in program is quite
intentional
Slide 41
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) 41 Types of programs Is that
lower case p still bothering you? Better not be
Slide 42
42 Program Logical Model
Slide 43
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 Challenge: Canonical Program
vs. Program Offering
Slide 44
KS Enrollment Overview Presenter: Steve Barnhart
Slide 45
Objectives 1. To provide a high-level understanding of the
functional areas of the Kuali Student Enrollment module 2. To
provide an understanding of how KS Enrollment builds off of KS
Curriculum Management 3. To lay the ground work for more detailed
discussions in future KS training modules, deep dives 45 KS
Enrollment Overview - Introduction
Slide 46
3. Course Offering 4. Course Registration 5. Course Assessment
7. Program Enrollment 9. Academic Planning 6. Program Offering 1.
Setup 2. People and Permissions Student FacingInstitution Facing 2.
People and Permissions 10. Academic Record Curriculum Management 8.
Program Assessment
Slide 47
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. Set Up (Time)
Slide 48
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 1. Setup (Environment)
Slide 49
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 2. People and Permissions
Slide 50
3. Course Offering 4. Course Registration 5. Course Assessment
7. Program Enrollment 9. Academic Planning 6. Program Offering 1.
Setup 2. People and Permissions Student FacingInstitution Facing 2.
People and Permissions X-cutting 10. Academic Record Curriculum
Management 8. Program Assessment UW My Plan KS Financials
Slide 51
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 Offering
Slide 52
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 3. Course
Offerings
Slide 53
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
Slide 54
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 4. Course
Registration (cont.)
Slide 55
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 5. Course
Assessment
Slide 56
3. Course Offering 4. Course Registration 5. Course Assessment
7. Program Enrollment 9. Academic Planning 6. Program Offering 1.
Setup 2. People and Permissions Student FacingInstitution Facing 2.
People and Permissions 10. Academic Record Curriculum Management 8.
Program Assessment
Slide 57
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
6. Program Offerings
Slide 58
Open/unrestricted programs No admissions criteria No capacity
limitations 1 st -come, 1 st -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
Slide 59
Application process Review eligibility Complete application
Attach any required documents Route through any approval process
Notify applicant Termination Program withdrawal Stop-outs
Disqualifications 59 7. Program Enrollment (cont.)
Slide 60
Assessment of Satisfactory Progress Requirements Learning
results calculated/consumed Term GPAs Cumulative GPAs Units/Credits
completed Terms/Years completed Milestone achievement Potential
actions Probation Dismissal Applied at various levels Institutional
College Program 60 8. Program Assessment
Slide 61
Assessment of Completion Requirements Short Term :: integrate
with 3 rd party Long Term :: build KS module Assessment of
Graduation Clearance Requirements Identifying candidates Accepting
applications Clearing required steps Posting degree Notifying
candidates 61 8. Program Assessment (cont.)
Slide 62
3. Course Offering 4. Course Registration 5. Course Assessment
7. Program Enrollment 9. Academic Planning 6. Program Offering 1.
Setup 2. People and Permissions Student FacingInstitution Facing 2.
People and Permissions 10. Academic Record Curriculum Management 8.
Program Assessment UW My Plan
Slide 63
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
Slide 64
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 UWs existing systems Schedule of classes
Degree audit system Based on KS technology stack (as possible) To
be contributed back to KS 64 9. Academic Planning
Slide 65
3. Course Offering 4. Course Registration 5. Course Assessment
7. Program Enrollment 9. Academic Planning 6. Program Offering 1.
Setup 2. People and Permissions Student FacingInstitution Facing 2.
People and Permissions X-cutting: Holds X-cutting: Exemptions 10.
Academic Record Curriculum Management 8. Program Assessment UW My
Plan
Slide 66
A virtual collection of things related to a students 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
Slide 67
Data (continued) Degrees awarded Transfer course work and
evaluation Term and graduation honors 67 10. Academic Record
(cont.)
Slide 68
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
Slide 69
Blocks Real-time evaluations of student attributes which
determine limitations on actions Requisite checking, course
registration restrictions, etc. Change if the students attributes
change May be exempted 69 Cross-cutting Concepts (cont.)
Slide 70
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 Cross-cutting Concepts
(cont.)
Slide 71
KS Services Overview Presenter: Cathy Dew
Slide 72
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
Service Oriented Architecture
Slide 73
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 What are Service Contracts?
Slide 74
R1.1 had concept of "Entity" services and "Business" services
With ENR, we have implemented a classification system Supports
striated governance to support various development and delivery
efforts Class I 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
Slide 75
Class III KS Contributions Not part of KS proper but may become
so Current projects include UW MyPlan and Sigmas 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 Service Classification (cont.)
Slide 76
Services Design Process INPUTPROCESSOUTPUT Candidate Services
(See Service Index)Service Index Review high-level business
artifacts Group into areas for use cases BUSINESS ANALYSIS
High-level Features Business Requirements Terminology User Stories
BPM Rule Candidates Data WIKI Artifacts (See Service Description
Repository)Service Description Repository For each Service (Class I
and II) Diagram logical entities Explore service layering Define
functions & data bits Develop Formal Contracts Code Artifacts
(See KS 1.3 Branch)KS 1.3 Branch Refine Formal Contracts ALL
Artifacts (release process) DEVELOPMENT Application Analysis &
Design Core Slice Released Service Contracts
Slide 77
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) Service
Contract Artifacts
Slide 78
From Curriculum Management Example :: Class II and Class I
Slide 79
As we move into Enrollment Example :: Class II and Class I
Academic Calendar (ACAL) Academic Time Period (ATP)
Slide 80
You are here: KS Enrollment Application Map Overview Presenter:
Kristina Batiste
Slide 81
What is the application map? Why do we need one? How can we use
it? Where can we find it? 81 Answers to all your questions.
Slide 82
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 What is it?
Slide 83
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
HouseWinchester Mystery House 83 How to use it:
Slide 84
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 didnt think it was done, did you?) 84 Why do
we need it? Because UX designers pictures.
Slide 85
Here. 85 Where to find it:
Slide 86
Wrapping Up Presenter: Carol Bershad
Slide 87
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 KS ENR Training, Module 1:: Questions/Issues
Module 1:: Evaluation Please complete short survey:: KS ENR
Training - Module 1 EvaluationKS 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. Set Up
2. People and Permissions 87 Next Steps
Slide 88
Appendix: Traceability
Slide 89
89 Requirement Statement Traceability Example: KS System
Requirements - Course OfferingKS System Requirements - Course
Offering