Requirements Statement and Use Case Summary for StressFree
(version 1.3  10/24/05)

Stressfree is a system that can support on-line course registration.  Twice each year, Students register in courses for the following semester.  This registration period lasts a week, at the end of which each Student becomes enrolled in up to four courses.  Each Student may enroll in courses independently, and at any time of the week that the system is open for enrolling.  

A Student may enroll in five or fewer courses and labs during that week, as long as the course/lab is not filled to capacity and the Student’s transcript has met all the prerequisites for that course.  Once enrolled in a course, a Student may drop that course and add another one in its place.  By the end of the week, the Student must obtain advisor approval for his/her final course selections. 

The system has two groups of databases that can be accessed during this process:

Group I: Student Databases

StudentsDB – basic information for every Student, including:
		id, name, and year

TranscriptsDB – transcript information for all Students, including:
id, majors, minor, and id’s and grades for all courses currently completed or in progress

Group II: Course Databases

CoursesDB – basic information on all courses in the catalog, including:
		id, title, distribution, sameAs, and prerequisites

OfferingsDB –information for all courses offered, including:
id, semYear, section, labsection, Instructor, time slot, capacity, enrollment, waitcount, distribution, and the id’s of all Students currently enrolled.

SchedulesDB – Schedules of all Students currently enrolled, including:
id and id’s of all offerings currently on the Student’s Schedule.

InstructorsDB – information for all Instructors teaching the courses, including:
		name, the id’s of all course offerings taught by the Instructor, and the id’s of all 
Student advisees.

TimeSlotsDB – a list of the valid TimeSlots into which a course can be Scheduled.
 
Use Case postOfferings
Actors – the Registrar
Goals – to put the CoursesDB, OfferingsDB, SchedulesDB, InstructorsDB ,and TiemSlotsDB databases on-
line and accessible for viewing or updating.

Preconditions –
1.	These databases exist.
2.	These databases contain current information for all Students who have already enrolled in some courses.
3.	These databases are not currently available for on-line enrolling.
Postconditions – 
1.	These databases become available for on-line enrolling.
2.	Any Student logging in will be notified that she can view information in these databases and/or enroll in courses.
3.	Any Instructor logging in will be notified that she can view information in these databases and/or approve a Student’s Schedule.
	
Description – the Registrar may perform this use case at any time.  Other use cases can be 
initiated only if these databases are available for on-line enrolling.

Sequence Diagram:

User (Registrar)	System	
		
1. Log onto Website	2. Verify access;
     deny access if User is not Registrar	
3. If the CoursesDB, OfferingsDB, SchedulesDB, and InstructorsDB databases are not on-line, put them on-line
	4. Confirm that databases are on-line and
set :System status to “OfferingsPosted”	
5. If these databases are on-line,	6.  send error message “offerings already posted” to Registrar	
7. Log off website.	8. Terminate Session.	

Use Case unPostOfferings
Actors – the Registrar
Goals – to remove the CoursesDB, OfferingsDB, SchedulesDB, InstructorsDB, and TimeSlotsDB databases 
from on-line access.

Preconditions –
These databases are currently available for on-line access.
Postconditions – 
1.	These databases are retained as a permanent file.
2.	Any Student logging in is notified that she cannot view or enroll in courses.
3.	Any Instructor logging in is notified that she cannot view course information.
	
Description – the Registrar may post or unpost these databases at any time. Other use cases can 
be initiated only if these databases are available for on-line enrolling.

Sequence Diagram:

User (Registrar)	System	
1. Log onto Website	2. Verify access;
    deny Access if User is not Registrar	
3. If the CoursesDB, OfferingsDB, SchedulesDB, and InstructorsDB databases are on-line, take them off-line	4. Confirm that databases are off-line and
set :System status to “OfferingsNotPosted”	
5. If these databases are not on-line,	6.  send error message “offerings not posted” to Registrar	
7. Log off website.	8. Terminate Session.	

Use Case postTranscripts
Actors - the Registrar
Goals - to put the StudentsDB and TranscriptsDB databases on-line and accessible for viewing.

Preconditions - 
1.	These databases are not currently available on-line.
2.	These databases exist and contains current information for all Students enrolling.

Postconditions - 
	These databases become available on-line.

Related Use Cases - registerInCourses, viewTranscript 

Description - the Registrar may post Student Transcript information for viewing at any 
time, but at least at the beginning of enrolment week.  Other use cases can be 
initiated only if this use case has been completed.

Sequence Diagram:

Registrar	Server	
1. Log onto Website	2. Verify access;
    deny access if User is not Registrar	
3. If the StudentsDB and TranscriptsDB databases are not on-line, put them on-line	4. Confirm that databases are put on-line and set :System status to “TranscriptsPosted”	
5. If these databases are already on-line,	6.  send error message “transcripts already posted” to Registrar	
7. Log off website.	8. Terminate session.	

StressFree System states during registration week:

Transcripts
Posted

Offerings Posted

postTranscripts

unPostOfferings

postOfferings

Use Case viewInformation
Actors – a Student, an Instructor, or the Registrar
Goals – to view the courses already completed or in progress by an individual Student.

Preconditions –
1.	The system is in state TranscriptsPosted or OfferingsPosted
2.	A valid id and name are entered.

Postconditions - 
	The requested informaiton is displayed for viewing.

Description - a Student, Instructor or the Registrar has logged into the registration server.  If the preconditions are met, the system satisfies the postcondition.  If not, the system notifies the user about which preconditions were not satified.

Sequence Diagram:

Actor	System	
1. Log on to website	2.  Ask for id and name	
3. Enter id and name	4. Verify	
	a. Allow	
	b. Deny (indicate why they were denied)	
5. Select an action – viewTranscript, 
viewClassList, viewOfferings, or viewSchedule	
6. Ask for confirmation	
7. Confirm action	8. a.  Execute the action (use case)
    b.  Inform the Student about the 
           outcome of the action.	
9. Log off website	10, Terminate session.	

 Use Case viewTranscript
Actors – a Student, an Instructor, or the Registrar
Goals – to view the courses already completed or in progress by an individual Student.

Preconditions –
1.  If an Instructor, the transcript must be for an advisee.  
2.  If the Registrar, the transcript must be for a valid Student.

Postconditions - 
	The transcript for that Student is displayed for viewing.

Description - a Student, Instructor or the Registrar has logged into the registration server.  If the preconditions are met, the system satisfies the postcondition.  If not, the system notifies the user about which preconditions were not satified.

Sequence Diagram:

Actor	System	
1. Request transcript	2. Ask for Student id.	
3. If the actor is an Instructor or the Registrar, enter a Student id.  (If a Student, the id is the same as the login id.)	4. If the actor is an Instructor, check that the id is one of the Instructor’s advisees.
If the actor is the Registrar, check that the id is a valid Student id.
a. Allow – display the requested transcript.
b. Deny – send a message to the actor.	

Use Case  viewClassList
Actors – a Student, an Instructor, or the Registrar 
Goals - to display a class list for a particular CourseOffering

Preconditions - 
The requested CourseOffering exists in the database

Postconditions - 
The id and title of the CourseOffering, along with the id’s, names, and graduating years of all Students enrolled in the CourseOffering are displayed in alphabetical order.

Description – The actor selects a CourseOffering to view.  The system displays a class list for the CourseOffering.  If the preconditions are not met, the system notifies the actor about the cause for the error.

Sequence Diagram:

User (Student or Instructor)	System	
1. Activate the viewOfferings use case	2. Display courses.	
3. Select a CourseOffering from this list	4. For an Instructor:
    a. Access granted (if course is taught by  
        Instructor)
    b. Access denied (if course not taught by 
        Instructor)
For a Student:
    a. Access granted (if Student is enrolled 
        in course)
    b. Access denied (if Student is not 
        enrolled in course)	
7. Request Class List.	8. Using CourseRecords, display ids and names of all Students enrolled in this CourseOffering. 	

Use Case  viewOfferings
Actors – a Student, an Instructor, or the Registrar 
Goals - to display a series of CourseOfferings

Preconditions - 
The requested CourseOfferings exist in the database

Postconditions - 
A series of CourseOfferings, including id, title, time slot, prerequisites, distribution, capacity, and enrollment are displayed.  Associated lab CourseOfferings are also displayed.

Description – the actor selects a series of course offerings to view and the system checks to be sure that the preconditions are met.  If so, the system satisfies the postcondition by displaying all the information for an individual course (and its lab section).  If not, the system notifies the actor about the error.

Sequence Diagram:

Actor	System	
1a. enter search criteria: course id
  b. Instructor
  c. time slot
  d. distribution code
  e. department	2a. Display a list of courses that match the 
      entered search criteria, or
  b. notify user that the system is not in 
      state OfferingsPosted, or
  c. notify user that the information 
      entered does not match any offered 
      courses	

Use Case  viewSchedule
Actors - a Student, Instructor, or the Registrar
Goals - to display a Student’s Schedule

Preconditions - 
1.	A valid Student id and name are provided by the actor.
2.	If the actor is an Instructor, the Student id must be that of an advisee.

Postconditions - 
For each course on the Schedule, its id, title, Instructor, and time slot is displayed.  For courses with an associated lab section, that lab section and time slot are also displayed.

Description – an actor requests to view a schedule and the system checks to be sure that the preconditions are met.  If so, the system satisfies the postconditions by displaying all the required information for each course (and lab section) on the Student’s Schedule.  If not, the system notifies the actor which of the preconditions is not satisfied.

Sequence Diagram:

Actor	System	
1. request to view Schedule	2. Ask for Student id.	
3. If the actor is an Instructor or the Registrar, enter a Student id.  (If a Student, the id is the same as the login id.)	4. If the actor is an Instructor, check that the id is one of the Instructor’s advisees.
If the actor is the Registrar, check that the id is a valid Student id.
a. Allow – display the requested Schedule.
b. Deny – send a message to the actor.	

Use Case  approveSchedule
Actors –an Instructor 
Goals – to approve the courses on a Student’s Schedule

Preconditions - 
1.	System is in state OfferingsPosted.
2.	A valid Student id and name are provided by the Instructor.
3.	A valid Student id is provided by the Instructor
4.	The Instructor is that Student’s advisor.
5.	The Schedule shows progress toward degree completion

Postconditions - 
The Student’s Schedule is approved or not approved. 

Description - an Instructor has logged into the system and the Student requests that the Instructor approve the Schedule of classes.  The system checks to be sure that the preconditions are met.  
	If so, the advisor may have a discussion with the Student about distribution requirements, major requirements, and other factors affecting “progress toward degree completion.”  The Instructor may or may not approve the Schedule.

Sequence Diagram:

Actor	System	
1. Log on to website	2.  Ask for id and name	
3. Enter id and name	4. Verify
  a.  Allow
  b.  Deny (indicate reason)	
5. request to view Schedule	6. Ask for Student id.	
7. Enter a Student id.  	8. If the actor is an Instructor, check that the id is one of the Instructor’s advisees.
a. Allow.
b. Deny.	
9.  Select “Approve” or “Not Approve”	10. Update Schedule accordingly.	
11. Log off website	12, Terminate session.	

Use Case  enrollInCourses
Actors - a Student 
Goals - to begin, continue, or finish enrolling in courses.

Preconditions - 
1.  System is in state OfferingsPosted.
2.  A valid Student id and name are provided.
	3.  Student’s Schedule is not yet approved.

Postconditions - 
1.	If the Student’s Schedule does not already exist (she hasn’t previously logged in to register), then a Schedule is created.  Otherwise, the Student’s current Schedule is retrieved.
2.	The Student may add and delete courses from this Schedule.
3.	The Student may request advisor approval of this Schedule.

Description - a Student may add or delete courses from her Schedule.  During
this process, the system notifies the Student of changes as they occur, and updates the Schedule for each addition or deletion.  During this process, the Student may need to view the details of other CourseOfferings or her current Schedule.  During this process, the Schedule is updated accordingly.  

Sequence Diagram:

Actor:	System:	
1. Log on to website	2.  Ask for id and name	
3. Enter id and name	4. Verify
  a.  Allow
  b.  Deny (indicate reason)	
5.  Request to view Schedule	6. a. If Schedule does not exist, create a new  
   (empty) Schedule.  
  b.  Execute the viewSchedule use case.	
Repeat steps 7-10:
7. Select an action – addACourse, 
deleteACourse, or viewInformation	
8. Ask for confirmation	
9. Confirm action	10. a.  Execute the action (use case)
      b.  Inform the Student about the 
           outcome of the action.	
11.  (Optional) request advisor approval of schedule	12.  Mark Schedule “finished”.	
13. Request to log out	14. log Student out	

Use Case  addACourse
Actors – a Student 
Goals - to add a course to a Student’s Schedule and add that Student to that course’s class list.

Preconditions 
1.  System is in state OfferingsPosted.
2.  A valid Student id and name are provided.
3.  A CourseOffering is provided.
4.  Transcript satisfies course’s prerequisites.
5.  Student’s Schedule is not already full.
6.	Student’s Schedule does not already contain the desired CourseOffering
7.   CourseOffering is not already full.
8.	CourseOffering’s time slot does not conflict with any other CourseOfferings 
on the Schedule.

Postconditions 
If  1-8 are satisfied, and the course does not have an associated lab course, then:
a.  the course is added to the Student’s Schedule and 
b.  the Student is added to  the course’s class list.
If 1-8 are satisfied and the course has an associated lab course, then:
if addALab is successful for that lab course, then 
a.  the course is added to the Student’s Schedule and 
b.  the Student is added to  the course’s class list.
	In any case, the Student is notified about the outcome.

Description - a Student logs into the system and selects a CourseOffering to add.  The system checks that the preconditions are met.  The system adds the Student’s id to the class list and the CourseOffering to the Student’s Schedule, notifying the Student about the outcome.

Sequence Diagram:

Actor:	System:	
1. Request a list of CourseOfferings	2. Execute viewOfferings use case	
3. Select a course to add	4.  Check preconditions 
     a.  If preconditions are satisfied, 
         ask user to confirm this selection
b.	Otherwise, reject the request and 
     notify actor of the reason.	
 5. Confirm selection	6   a. If the course has a lab, execute  
         addALab use case for this course. If 
         this fails, notify the Student that the 
         course can’t be added.  
b.	Otherwise, add the course to the Student’s Schedule, add the Student to the ClassList, and notify the Student of the outcome.	

Use Case  addALab
Actors – A Student 
Goals - to add a lab CourseOffering to his/her Schedule and add the Student to its ClassList

Preconditions - 
1.	Student’s Schedule does not already contain the lab CourseOffering to be added.
2.	lab CourseOffering’s time slot does not conflict with any other CourseOffering on the Schedule
3.	lab CourseOffering is not already full.

Postconditions - 
1.  The lab CourseOffering is added to the Student’s Schedule
2.  The Student is added to the lab CourseOffering’s class list.
3.  addACourse is notified of the success of this use case.

Description - a Student has selected a course to add to her Schedule, but the course has an associated lab course.   The system checks to be sure that the preconditions for adding this lab course are met.  If so, the system satisfies the postcondition and notifies the Student that the lab CourseOffering has been added.  Otherwise, the system notifies the Student that the lab CourseOffering was not added, along with a reason.

Sequence Diagram:

Actor:	System:	
1. Select a lab to add	2. Check preconditions.
     a. If not met, notify Student that 
         addALab fails.
     b. Ask for confirmation to add the lab.	
3. Confirm	4. Add the lab to the Student’s Schedule and the Student to the lab’s class list.
Notify Student that the lab has successfully been added.	

Use Case  deleteACourse
Actors – a Student 
Goals - to remove a CourseOffering (and its associated lab, if present) from a Student’s Schedule, and remove that Student from the class list.

Preconditions - 
1.  System is in state OfferingsPosted.
2.  A valid Student id and name are provided.
3.  A CourseOffering is provided.
4.  CourseOffering’s id appears on the Student’s Schedule. 

Postconditions - 
If 1-4 are satisfied and the course does not have an associated lab CourseOffering, 
a.	the CourseOffering is removed from the Student’s Schedule, 
b.	the Student is removed from the CourseOffering’s class list, and 
If 1-3 are satisfied and course has an associated lab CourseOffering, 
a.	the Student is removed from the CourseOffering and lab Course Offering, and
b.	the CourseOffering and lab course are removed from the Student’s Schedule.
	In any case, the Student is notified about the outcome.

Description - a Student has logged into the registration server and has obtained her Schedule.  The Student has selected a CourseOffering to remove from her Schedule and the system checks to be sure that the preconditions are met.  The system satisfies the postconditions, notifying the Student about the outcome.  If no action is taken, the system provides a reason.

Sequence Diagram:

Actor:	System:	
1. Request a list of CourseOfferings	2. Execute viewOfferings use case	
3. Select a course to delete	4.  Check preconditions 
     a.  If preconditions are satisfied, 
         ask user to confirm this selection
c.	Otherwise, reject the request and 
     notify actor of the reason.	
 5. Confirm selection	6   a. If the course has a lab, remove the lab 
         CourseOffering from the Student’s 
         Schedule and the Student from the lab 
         CourseOffering’s ClassList.  
b. Remove the courseOffering from the 
    Student’s Schedule, and remove the   
         Student from the ClassList. 
     c.  Notify the Student of the outcome.