Stanford Use Cases

Use Cases
Skeleton B

Canonical Course Assets

Use Case CCA.1) Actor creates a canonical course (CC)
Goal: a canonical course is created
Scope: Course Management Service
Preconditions: Actor is authenticated and authorized. we know
course name, catalog number, a short description, dept.
Success End Condition: Actor has a Canonical Course ready
for further definition.
Failed End Condition: No canonical course is created
Primay Actor: user or computer agent
Trigger: Course is to be added to CMS

Main success scenario
.1) Actor indicates name, catalog number, department, short description
.2) system creates new CC
.3) system provides reference to new CC to Actor

Extensions
.1.a) Actor fails to provide necessary information
.2.a) system fails to provide reference

.2.b) system cannot create a new CC due to duplicate catalog number
.2.b1) system returns error: CC already exists.

.2.c) system cannot create new CC due to system error
.2.c1) system returns error: system failure.

=================================================================

Use Case CCA.2) Actor defines core content for CC
Goal: a CC is fleshed out to be used as a template for new
courses
Scope: Course Management Service
Preconditions: Actor is authenticated and authorized. Actor
has a reference to a CC.
Actor has more information to stuff into the
template; a syllabus, some materials, a
schedule, some common assignments, a list of tools
often used in the delivery of course.
Success End Contition: a template exists allowing for the
rapid creation of course offerings with
associated assets.
Failed End Condition: No template exists. Offerings must be
reconfigured from scratch w/every
instantiation.

Primary Actor: person or computer specifying course content
Trigger: Content is available.

Main success scenario:
.1) Actor defines Syllabus for CC. The Syllabus
for the CC does not often change.
.2) Actor defines Materials for CC.
.3) Actor defines Materials reference mode (copy, reference)
.4) Actor defines Schedule for CC.
.5) Actor defines Assignments for CC
.6) Actor defines commonly used Tools.

Related information:
CCA.1

Note: most of the above are current CW capabilities,
implemented as peer-course copy
Stock tool subset.
Emerging usage show folks creating 'fake courses'
and copying those.
Same with our use of PHPBB in Course Discussion
context. In that usage default topics are created,
parallelling the default 'tools' useage. Granted much
easier in that context.

=================================================================

Use Case CCA.3 ) Actor copies a CC to make a new CC
Goal: a new CC is created based on an existing CC. This situation
occurs when there is re-use of CC definition across
dept. (ie: common schedule, bootstrapping a dept... )
Scope: Course Management Service
Preconditions: Actor is authenticated and authorized. Actor
has reference to CC.
Success End Condition: Actor has a CC ready for further
definition.
Failed End Condition: no copy is produced.
Primary Actor: user or computer agent
Trigger: "largely simular" Course is to be added to CMS

Main success scenario
.1) Actor selects CC as copy candidate
.2) Actor indicate "reference or copy" for file assets
.3) system creates CC-new, returning CC-new reference to Actor

Extensions
.3a) system adds references to CC file based assets to CC-new

.3b) system duplicates file based assets, provides new
references to CC-new

Related information:
CCA.1
CCA.2

Use Case CCA.4) Actor creates new course offering (CO) for term
Goal: We need to create a course offering in a term. This may be
done 'automagically' upon occurance of course in SIS feed
or manually.
Scope: Course Management Service
Preconditions: Actor is authenticated and authorized. Actor has
reference to the CC.
Success End Condition: A Course Offering is created, with various
course assets pre-populated.
Failed End Condition: A Course Offering is not created. A course offering
is created without defaults.
Primary Actor: user or computer agent
Trigger: Time for a course to be realized in CMS.

Main success scenario:
.1) Actor indicates CC, term
.2) Actor receives new CO w/defaults
.3) Actor modifies CO as needed
.3.1) add Staffing specifics
.3.2) modify Syllabus
.3.3) modify Tool set
.3.4) modify Material set
.3.5) modify Registration model (sync SIS, no-sync SIS)
.3.6) modify Cross Listing(s)
.3.7) modify Schedule

Extensions:
.3.8) Actor specify student enrollment

Related Information:
CCA.1
CCA.2
CCA.3

the orgz goal is to reduce busywork.

======== odd bits 'n' gravy, written down while
thinking fo the above.
========
sure to be more, but this is not asset related.

) Actor cross-lists two COs
Goal:
Scope:
Preconditions:
Success End Condition:
Failed End Condition:
Primary Actor:
Trigger:
.1) Actor indicates CO-A
.2) Actor indicates CO-B
.3) system provides new CO-A.B
.4) system demotes CO-A and CO-B
.5) system markes CO-A.B as 'working' CO

Note: huh.

Note: what CW currently does is create a 'supercourse' which
in turn references the children courses for the term. SIS
sync is only against 1st child of supercourse (bug)

) Actor reconciles CO
Goal:
Scope:
Preconditions:
Success End Condition:
Failed End Condition:
Primary Actor:
Trigger:
.1) Actor indicates CO to reconcile
.2) system accesses SIS for this CO
.3) system finds corresponding membership info in CO (may
be in section of SIS result) makes update.
.4) ... tb continued

Note: we just want to reconcile the offerings. SIS reconcilation
is against the 'supercourse' in CW, but drills down.

) Actor searches for an instructors courses in term
) Actor searches for an instructors courses
) Actor searches for courses taught in a term
) Actor searches for departments canonical courses
) Actor searches for departments course offerings in a term
) Actor searches for assets used in a course
) Actor searches for assets used in a course offering
) Actor searches for member in a course offering
) Actor searches for member in a course section
) Actor searches for member's membership set in a term

) Actor CRUD