Difference between revisions of "BBB BUC SAdmin MngProf"

From CDOT Wiki
Jump to: navigation, search
(Scenario 5: Delete professor's.)
 
(11 intermediate revisions by 2 users not shown)
Line 2: Line 2:
  
  
'''Scenario 1:''' Add subject to professor
+
=='''Scenario 1:''' Add subject to professor.==
  
  
Line 21: Line 21:
  
 
'''Postconditions:''' Manage professors page.
 
'''Postconditions:''' Manage professors page.
 
  
 
'''Comments'''<br />
 
'''Comments'''<br />
 +
For data used:<br />
 +
* In step 1, ff username not in DB but in LDAP, simply add user id (bu_id) to bbb_user, professor table unaffected at this point.
 +
* In step 3, professor table is affected.
  
* If user (soon-to-be professor) does not exist in our database, system should prompt actor to add user, which is in the "Manage Users" Use Case -Bo Li
+
=='''Scenario 2:''' Edit professor's subject.==
* No LDAP search for this Use Case -Bo Li
 
 
 
'''Scenario 2:''' Edit professor's subject
 
  
  
Line 48: Line 47:
 
'''Postconditions:''' Manage professors page.
 
'''Postconditions:''' Manage professors page.
  
 +
'''Comments:'''<br />
 +
* For edit professor's subject, the target's bu_id must be in professor table, no LDAP search is done.
  
'''Comments'''<br />
+
=='''Scenario 3:''' Delete professor's subject.==
* No LDAP search for this Use Case -Bo Li
 
 
 
 
 
'''Scenario 3:''' Delete professor's subject
 
  
  
Line 73: Line 70:
 
'''Postconditions:''' Manage professors page.
 
'''Postconditions:''' Manage professors page.
  
 +
Comments:
 +
 +
For delete professor's subject, the target's bu_id must be in professor table, no LDAP search is done.
  
'''Scenario 4:''' Add section to professor's subject
+
=='''Scenario 4:''' Add section to professor's subject.==
  
  
Line 86: Line 86:
 
|Actor chooses to add a section to the subject. ||System returns a field for entering section letter. || Section letter
 
|Actor chooses to add a section to the subject. ||System returns a field for entering section letter. || Section letter
 
|-
 
|-
|Actor chooses to save section ||System returns visual notification indicating a new section has been added. ||
+
|Actor chooses to save section. ||System validates field, persists data to db, and returns visual notification indicating that a new section has been added.|| Section letter
|-
 
|Actor chooses to save changes. ||System validates field and creates new section for professor. ||
 
 
|}
 
|}
  
Line 94: Line 92:
 
'''Postconditions:''' Manage professors page.
 
'''Postconditions:''' Manage professors page.
  
 +
'''Comments:'''<br />
 +
 +
* section id (sc_id) cannot be entered separately from course id (c_id), since the professor table use a 4-part primary key (bu_id, c_id, sc_id, sc_semesterid)
  
'''Scenario 5:''' Delete professor's
+
=='''Scenario 5:''' Delete professor's.==
  
  
Line 113: Line 114:
 
'''Postconditions:''' Manage professors page.
 
'''Postconditions:''' Manage professors page.
  
 +
'''Comments:'''<br />
 +
* section can exists (at least temporarily) without a prof, there may be instance where prof will change, no need to delete section before prof
  
'''Scenario 6:''' Upload subject list
+
=='''Scenario 6:''' Upload subject list.==
  
  

Latest revision as of 14:55, 18 June 2013

Brief Description: The process by which an actor manages a professors subjects and sections.


Scenario 1: Add subject to professor.

Preconditions: Manage professors page.


Actor System Data Used
Actor types professor username into search box and chooses to search. System searches db for username and returns professor's subjects (if found). Otherwise, searches LDAP for username and creates null records in db for professor (if found). Professor username
Actor chooses to add a subject. System returns page with editable fields. Course Code, Course Name
Actor chooses to save changes. System validates fields and persists changes to db.


Postconditions: Manage professors page.

Comments
For data used:

  • In step 1, ff username not in DB but in LDAP, simply add user id (bu_id) to bbb_user, professor table unaffected at this point.
  • In step 3, professor table is affected.

Scenario 2: Edit professor's subject.

Preconditions: Manage professors page.


Actor System Data Used
Actor types professor username into search box and chooses to search. System searches db and LDAP for username and returns professor's subjects (if found). Professor username
Actor chooses to edit a subject. System returns page with editable fields populated with chosen subject's details. Course Code, Course Name
Actor edits fields and chooses to save changes. System validates fields and persists changes to db.


Postconditions: Manage professors page.

Comments:

  • For edit professor's subject, the target's bu_id must be in professor table, no LDAP search is done.

Scenario 3: Delete professor's subject.

Preconditions: Manage professors page.


Actor System Data Used
Actor types professor username into search box and chooses to search. System searches db and LDAP for username and returns professor's subjects (if found). Professor username
Actor chooses to delete a subject. System returns prompt asking for confirmation.
Actor accepts (chooses to delete). System deletes subject record from db.


Postconditions: Manage professors page.

Comments:

For delete professor's subject, the target's bu_id must be in professor table, no LDAP search is done.

Scenario 4: Add section to professor's subject.

Preconditions: Actor is editing a professor's subject. Edit subject page.


Actor System Data Used
Actor chooses to add a section to the subject. System returns a field for entering section letter. Section letter
Actor chooses to save section. System validates field, persists data to db, and returns visual notification indicating that a new section has been added. Section letter


Postconditions: Manage professors page.

Comments:

  • section id (sc_id) cannot be entered separately from course id (c_id), since the professor table use a 4-part primary key (bu_id, c_id, sc_id, sc_semesterid)

Scenario 5: Delete professor's.

Preconditions: Actor is editing a professor's subject. Edit subject page.


Actor System Data Used
Actor chooses to delete a section. System returns prompt asking for confirmation.
Actor accepts (chooses to delete). System delete section record from db.


Postconditions: Manage professors page.

Comments:

  • section can exists (at least temporarily) without a prof, there may be instance where prof will change, no need to delete section before prof

Scenario 6: Upload subject list.

Preconditions: Manage professors page.


Actor System Data Used
Actor chooses to upload list of subjects. System returns prompt for uploading list.
Actor chooses file and accepts. System parses file and updates db with subjects information.


Postconditions: Manage professors page.