Modernizing Curriculum
Review Workflow
System Requirements Specification
Kristine Belknap
Bruce Han
Michael Hsu
Elvin Rey Magsino
Young Phan
Dr. Chengyu Sun
Table of Contents
1. Introduction
1.1. Vision Statement
1.1.2. Software Purpose
1.1.3. Software Scope
1.1.4. Software Perspective
1.2. Document Conventions and Definitions
1.3. Intended Audience and Reading Suggestions
1.4. References
2. Overall Description
3. External Interface Requirements
3.1 Software Interfaces
3.2 Communication Interfaces
4. System Features (Functional Requirements)
5. Use Case Model
5.1 Requester Use Case
5.3 Committee Use Case
5.4 External Department Use Case
5.6 EPC Use Case
5.7 GET/Registrars Use Case
5.9 Background Processes
6. Nonfunctional Requirements
7. Glossary
1. Introduction
1.1. Vision Statement
The vision of the Modernizing Curriculum Review Workflow project is a new and
improved Curriculum Review System for the digital age. This project is to create a more
streamlined, web-based system which is more efficient and more user-friendly than the current
paper-based system. Also, as a web-based system, many of the features will be available on
most major platforms since the users will be accessing much of the Curriculum Review System
though their browsers. The system can be further extended to implement other university
workflow processes in the future.
1.1.2. Software Purpose
The purpose of the Modernizing Curriculum Review Workflow project is to modernize
the workflow of the review process for the proposal of new and modified courses. This project,
based on SharePoint server 2010, will create a web-based system to replace the paper-based
system currently in use. Because of the vast quantity of printed documents and the large
number of individuals who have to handle these documents, the current paper-based system
is cumbersome, lengthy, and prone to errors due to issues with losing track of the document
version or even losing track of the whole document itself. The Modernizing Curriculum Review
Workflow project’s new Curriculum Review System will use SharePoint server 2010 to handle
the storage and versioning of the documents for the users, thus eliminating some of the
problems which exist in the current paper-based system.
1.1.3. Software Scope
The Modernizing Curriculum Review Workflow project’s new Curriculum Review
System is for use by all of the Faculty, Department Chairs, Deans, and Committee Members of
California State University, Los Angeles.
1.1.4. Software Perspective
The current Curriculum Review process is shown in Figure 1. In the current system, the
Requester of the new or modified course fills out the appropriate forms and turns them in at their
Department’s office. (Step 1) The Department Chair gives copies to all of the various members
of the Instructional Affairs Committee, abbreviated in Figure 1 as IAC, of the Requester’s
Department. (Step 2) The Instructional Affairs Committee of the Requester’s Department
decides on whether to reject or accept the proposed course and gives the Department Chair
the committee’s decision. (Step 3) If the new or modified course is accepted by the Department
level Instructional Affairs Committee, the Requester’s Department Chair then either rejects
or accepts the proposed course and in scenarios where the Requester’s Department Chair
approves the proposed course, the Department Chair then gives a copy to the Associate Dean
of the College to which the Department belongs. (Step 4)
The Associate Dean gives a copy to the Instructional Affairs Committee of the
Requester’s College. (Step 5) Similar to the process at the Department level, the Instructional
Affairs Committee of the Requester’s College decides on whether or not to accept the proposed
course and gives the Requester’s College Dean their decision. (Step 6) If the proposed course
is accepted by the College level Instructional Affairs Committee, the Requester’s Associate
Dean then either rejects or accepts the new or modified course and if the proposed course is
accepted, the Requester’s College Dean gives copies to each of the other College’s Associate
Deans. (Step 7) At this stage in the approval process, each of the Associate Deans of the
other Colleges decide on whether or not any of their College’s Departments might have an
issue with the proposed course and gives the Requester’s Associate Dean a list of all of their
Departments, if any, that could potentially have a complaint against the proposed course.
(Step 8) At this point, the Requester’s College Dean gives copies to each of the Department
Chairs listed by the other College’s Deans. (Step 9) Each of these other College’s Department
Chairs either reject or accept the proposed course and give the Requester’s College Dean their
decision. (Step 10)
At this stage, if the proposed course is still approved, the Requester’s Associate Dean
gives a copy to either the Office of Undergraduate Studies or the Office of Graduate Studies
depending on the level of the new or modified course. (Step 11) From the corresponding office,
based on the proposed course’s level, copies are given to all of the members of the Educational
Policy Committee, abbreviated in Figure 1 as EPC, of the University. (Step 12) The University
Educational Policy Committee then decides on whether or not to approve the new or modified
course and gives the committee’s decision to either the Office of Undergraduate Studies or the
Office of Graduate Studies depending on the level of the new or modified course. (Step 13)
Finally, the Office of Undergraduate Studies or the Office of Graduate Studies, depending on
the level of the new or modified course, either rejects or approves the proposed course and in
the scenario where the proposed course is approved, copies are given to the Registration Office
and the Office that maintains the GET system so that the new or modified course can be added
into the University’s system. (Step 14)
Figure 1. Curriculum Review Process.
With this project’s new Curriculum Review System, the Requester of the new or modified
course would fill out the appropriate forms, easily available to them on the Curriculum Review
System’s website, and simply click submit when ready. (Step 1) The Department Chair would
automatically receive a notification alerting them to the new or modified course awaiting their
attention. The Requester’s Department Chair would assign the proposed course approval
deadlines for the next stage and click forward to have the system send notifications to all of the
various members of the Instructional Affairs Committee of the Requester’s Department. (Step
2) The Instructional Affairs Committee of the Requester’s Department decides on whether to
reject or accept the proposed course and as they submit their decision to the Curriculum Review
System’s website, the website would alert the Department Chair of the committee’s decision.
(Step 3) If the new or modified course is accepted by the Department level Instructional Affairs
Committee, the Requester’s Department Chair then either rejects or accepts the proposed
course and in scenarios where the Requester’s Department Chair approves the proposed
course, the Curriculum Review System’s website automatically notifies the Associate Dean
of the College to which the Department belongs of the new or modified course awaiting their
attention. (Step 4)
Similar to the process at the Department level, the Associate Dean would assign
deadlines for the approval of the new or modified course at the next stage and click forward to
trigger the Curriculum Review System to send notifications to the members of the Instructional
Affairs Committee of the Requester’s College alerting each committee member to the new or
modified course awaiting their rejection or approval. (Step 5) The Instructional Affairs
Committee of the Requester’s College decides on whether or not to accept the proposed course
and as they give their decision to the Curriculum Review System’s website, the website would
inform the Requester’s College Dean of their decision. (Step 6) If the proposed course is
accepted by the College level Instructional Affairs Committee, the Requester’s Associate Dean
then either rejects or accepts the new or modified course and if the proposed course is
accepted, the Curriculum Review System sends notifications to each of the other College’s
Associate Deans. (Step 7) At this stage in the approval process, each of the Associate Deans of
the other Colleges decide on whether or not any of their College’s Departments might have an
issue with the proposed course and the Curriculum Review System alerts the Requester’s
Associate Dean to all of the Departments, if any, that could potentially have a complaint against
the proposed course. (Step 8) At this point, the Requester’s College Dean assigns these
Department Chairs deadlines for rejecting or approving the proposed course and clicks forward.
The Curriculum Review System then notifies each of the Department Chairs listed by the other
College’s Deans of the proposed course awaiting their decision. (Step 9) Each of these other
College’s Department Chairs either reject or accept the proposed course and the Curriculum
Review System alerts the Requester’s College Dean of the decision made by the Department
Chairs. (Step 10)
At this stage, if the proposed course is still approved, the Requester’s Associate Dean
clicks forward to trigger the Curriculum Review System to send a notification to either the
Office of Undergraduate Studies or the Office of Graduate Studies depending on the level of
the new or modified course. (Step 11) From the corresponding office, based on the proposed
course’s level, the Curriculum Review System sends notifications to all of the members of the
Educational Policy Committee of the University. (Step 12) The University Educational Policy
Committee then decides on whether or not to approve the new or modified course and submits
the committee’s decision on the Curriculum Review System’s website which automatically
notifies either the Office of Undergraduate Studies or the Office of Graduate Studies depending
on the level of the new or modified course. (Step 13) Finally, the Office of Undergraduate
Studies or the Office of Graduate Studies, depending on the level of the new or modified course,
either rejects or approves the proposed course and in the scenario where the proposed course
is approved, the Curriculum Review System automatically sends copies of the new or modified
course to the Registration Office and the Office that maintains the GET system so that the new
or modified course can be added into the University’s system. (Step 14)
1.2. Document Conventions and Definitions
1.3. Intended Audience and Reading Suggestions
The intended audience of this document, which specifies the system requirements of
the Modernizing Curriculum Review Workflow project, is the development team involved in
the creation of said project’s new Curriculum Review System and the Dean of Undergraduate
Studies at California State University, Los Angeles.
1.4. References
2. Overall Description
2.1 User Characteristics:
The user will not need to be an expert on how the system works. Little training
is required because SharePoint’s interface is similar to that of Microsoft office’s.
Requesters will need basic training on how to upload the course proposal document to
the Microsoft SharePoint site. All other users will need basic training on how to approve/
decline documents and send feedback using the Microsoft Sharepoint site.
2.2 Operating Environment:
All the components of MCRW will be based on Microsoft SharePoint Server 2010, which
will be run on an Windows 2008 server machine.
2.3 Design and Implementation Constraints
The user interface of MCRW must be user-friendly and easy-to-navigate. It should be
developed on top of Sharepoint server 2010, which is currently used by the client to
store documents. Any additional functions to be implemented that are not provided by
SharePoint server 2010 , Microsoft InfoPath, or Microsoft SharePoint Designer will be
developed in Microsoft Visual Studio 2010.
2.4 Database Considerations
MCRW will use a Microsoft SQL Server 2008 Database, as required by Microsoft
SharePoint server 2010.
2.5 Assumptions and Dependencies
All data in MCRW is user generated. MCRW relies on users besides the requester on
approving submissions using the automatic custom workflow.
3. External Interface Requirements
3.1 Software Interfaces
The web application will be accessed by users through Internet Explorer versions 8 or above.
Version 8 is required for full SharePoint 2010 experience.
3.2 Communication Interfaces
The web application will use HTTPS protocol to ensure sensitive data remains secure. TCP/IP
will be used in order to transmit data to and from the web application. Communication between
SharePoint server and the campus Active Directory server will provide user access control to
the web application.
4. System Features (Functional Requirements)
4.1 Department Level Requirements
1. MCRW shall allow user to upload Course Proposal documents (i.e., .doc, .txt, .pdf).
2. MCRW shall allow Faculty/Staff to add comments to any Course Proposal.
3. MCRW shall allow Requester to manually forward Course Proposals to specific Faculty/
Staff/Departments.
4. MCRW shall allow Requester to re-upload modified Course Proposals.
5. MCRW shall allow Requester to resend notification e-mails.
6. MCRW shall allow Faculty/Staff to approve requests.
7. MCRW shall allow Faculty/Staff to deny requests.
8. MCRW shall allow Requester's Course Proposal to 'Submit for Review'.
9. MCRW shall allow users to be designated as Faculty/Staff, Department Chair, and/or
Department IAC (Instructional Affairs Committee) Member.
10. MCRW shall forward Course Proposal to Department Chair upon Review Submission.
11. MCRW shall allow Department Chair to forward Course Proposals to Department IAC.
12. MCRW shall allow Department IAC to forward Course Proposal to Department Chair.
13. MCRW shall allow Department Chair to forward Course Proposal to present College
Associate Dean.
14. MCRW shall allow Department Chair to Approve/Deny Course Proposal.
15. MCRW shall allow Faculty/Staff to use Microsoft Outlook to e-mail and forward
notifications to other Faculty/Staff.
16. MCRW shall display current status of Course Proposal (i.e., Pending Approval,
Approved, Denied).
4.2 College Level Requirements
1. MCRW shall allow College Associate Dean to forward Course Proposal to College IAC.
2. MCRW shall allow College IAC to forward Course Proposal to College Associate Dean.
3. MCRW shall allow College IAC to request College Associate Dean to forward Course
Proposal to relevant Colleges (College of Arts and Letters, College of Business and
Economics, Charter College of Education, College of Engineering, Computer Science,
and Technology, College of Health and Human Services, College of Natural and
Social Sciences, College of Extended Studies and International Programs, and Honors
College).
4. MCRW shall allow College Associate Dean to forward Course Proposal to other College
Associate Deans.
5. MCRW shall allow College Associate Dean to forward Course Proposal to other
departments within other colleges (e.g Department of Civil Engineering through the
College of Engineering, Computer Science, and Technology).
6. MCRW shall allow College Associate Dean to forward Course Proposal to Office of
Undergraduate Studies and/or Office of Graduate Studies and Research.
7. MCRW shall allow Faculty/Staff to view a history of users that have viewed or edited the
Course Proposal.
8. MCRW shall allow Faculty/Staff to view all comments on the Course Proposal.
9. MCRW shall allow College Associate Dean to Approve/Deny Course Proposal request.
10. MCRW shall display current status of Course Proposal (i.e., Pending Approval,
Approved, Denied).
4.3 University Level Requirements
1. MCRW shall allow Office of Undergraduate Studies and/or Office of Graduate Studies
and Research to forward Course Proposal to University EPC (Educational Policy
Committee).
2. MCRW shall allow University EPC to forward Course Proposal to Office of
Undergraduate Studies and/or Office of Graduate Studies and Research.
3. MCRW shall allow Office of Undergraduate Studies and/or Office of Graduate Studies
and Research to forward Course Proposal to Registration Office.
4. MCRW shall allow Faculty/Staff to view all comments on the Course Proposal.
5. MCRW shall allow University Associate Dean to Approve/Deny Course Proposal
request.
6. MCRW shall display current status of Course Proposal (i.e., Pending Approval,
Approved, Denied).
7. MCRW shall forward finalized Course Proposal with Comments to originating Faculty/
Staff/Department upon confirmed Approval or Denial.
4.4 System Requirements
1.
2.
3.
4.
5.
MCRW shall be managed by the CSULA ITS.
MCRW shall store user accounts in an active directory.
MCRW shall require a log-in to access the workflow.
MCRW shall require separate log-in credentials per authorized user.
MCRW shall allow administrators to create groups/subgroups based on the following
categories: Faculty/Staff, Department Chair, Department IAC, College Associate Dean,
College IAC, University Associate Dean, University EPC, Registration Office.
6. MCRW shall allow administrators to manage security and permissions of groups.
7. MCRW shall allow administrators to manage security and permissions of individual
users.
8. MCRW shall create a website portal containing all Course Proposals and documents.
9. MCRW shall maintain group-specific websites containing relevant Course Proposals and
relevant documents.
10. MCRW shall be compatible with the existing Microsoft Office Suite (i.e. Word, Excel,
Outlook, Access).
11. MCRW shall allow administrators to publish workflow diagrams from Microsoft Visio
2010.
12. MCRW shall maintain an Address Book.
13. MCRW shall maintain a Calendar.
14. MCRW shall allow Faculty/Staff to edit personal info in the Address Book.
15. MCRW shall archive all documents (Course Proposals, Comments, Approved Course
Proposals, and Denied Course Proposals).
16. MCRW shall allow users to search data from documents.
17. MCRW shall allow users to download documents to storage media (i.e. HDD, USB
Drive, CD-Rom).
5. Use Case Model
5.1 Requester Use Case
Actors: requester, system
Preconditions: none
5.1.1 Shall allow users to upload course request document
Figure 5.1: Pop up dialog after “Upload New Request Button” user click
Requester: Viewing SharePoint home page on department subsite, customized for users.
Click “Upload New Request Button”
System: Pop up dialog appears, as shown in figure 5.1, with form for Requester to provide
comments.
Requester: Selects and uploads document, add comment if desired. Clicks “OK” button.
System: Executes validation procedure to ensure fields are filled contain correct data
System: Display “Saving...” dialog
System: Flags request as “Pending Department Chair Approval”
System: Starts automatic workflow process
System: Automatically notify respective department chair through email once document
successfully uploaded.
System: Close pop-up field
5.1.2 Shall allow requester to download request
Figure 5.1.2: user view after clicking “Course Proposals” document library button
Requester: clicks “Course Proposals”, then the view switches to figure 5.1.2. Clicks “Download
a Copy” button
System: Displays Download Dialog
Requester: Clicks “Save”
System: Starts document download
5.1.3 Shall allow requesters to edit pending requests
figure 5.1.3: edit dialog
System: Displays list of requests
Requester: Viewing request list, clicks link to request
System: Generates pop-up dialog, as seen in figure 5.1.3, to display request information
Requester: Clicks the edit button link and edits the request
System: Populates appropriate fields where applicable
Requester: Clicks save button
System: Executes validation procedure, displays “Saving...” dialog, and notifies the requester
of the changes, then closes the dialog
5.1.4 Shall allow requesters to delete pending requests
figure 5.1.4: delete dialog
System: Displays list of requests
Requester: Viewing request list, clicks link to request
System: Generates pop-up dialogue, as seen in figure 5.1.4, to display request information
Requester: Clicks the delete button link
System: Generates pop-up dialog to confirm the deletion of the pending request
Requester: Confirms the deletion by clicking the confirm button
System: Executes deletion procedure, displays “Deleting...” dialog, notifies the requester of the
changes, then closes the dialog
5.2 Department Use Case
Actors: Department Chair, System
Preconditions: Requester use case
5.2.1 Shall display list of pending requests
Figure 5.2.1: Document Library view for Department Chair
Department Chair: Viewing home page on department subsite with a customized view for
department chair. Clicks “Pending Requests”, view changes to Course Proposals document
library, as seen in figure 5.2.1
System: Generates list of requests pending Department Chair Approval.
5.2.2 Shall allow Department Chair to edit request
Figure 5.2.2: Department chair edit request dialog
System: Display list of requests
Department Chair: Viewing request list, Clicks link to request
System: Generates pop-up dialog, as seen in figure 5.2.2, to display request information
Department Chair: Edits request information
System: Automatically populate fields where applicable
Department Chair: Clicks “Save” button
System: Executes validation procedure.
System: Displays “Saving...” dialog.
System: Notifies request creator of changes.
System: Close pop-up field
5.2.3 Shall allow Department Chair to approve request.
Figure 5.2.3: Deparment chair approval dialog
System: Displays list of requests
Department Chair: Viewing request list, Clicks on link to request.
System: Generates pop up dialog, as seen in 5.2.3, with request information
Department Chair: Clicks “Approve” Button
System: Flags request as “Approved by Department Chair”
System: Checks to see if Request has been approved by Committee
System: Notifies Committee If not Approved by Committee
System: Notifies Associate Dean if request approved by Chair and Committe
System: Close pop-up dialog
5.2.4 Shall allow Department Chair to deny request
System: Display list of requests
Department Chair: Viewing request list, Clicks on link to request
System: Generates pop-up dialog to display request information
Department Chair: Clicks “Deny Button”
System: Flags request as “Denied by Department Chair”
System: Notifies Requester of denied request by Department Chair
System: Closes pop-up dialog
5.2.5 Shall allow Department Chair to post feedback on request
Department Chair: Viewing request form dialog, Clicks “Send Feedback” button
System: Displays Send Feedback dialog
Department Chair: Inputs Appropriate Feedback, Clicks Submit
System: Feedback is Sent to the Author of the Request, Confirms the Sending
Department Chair: Clicks OK to Confirm
System: Closes pop-up dialogue
5.2.6 Shall allow Department Chair to download request
Figure 5.2.6: Department Chair Request after clinking “pending proposal” button
Department Chair: Viewing request form dialog, as seen in figure 5.2.6, Clicks “Download a
Copy” button
System: Displays Download Dialog
Department Chair: Clicks “Save”
System: Starts download
5.3 Committee Use Case
Actors: Committee, System
Preconditions: Department Use Case(department chair approval)
5.3.1 Shall display list of pending requests
Figure 5.3.1 : Committee view of “course proposal” document library
Committee: Viewing home page, Clicks “Pending Requests”
System: Generates list of pending requests with Department Approval
5.3.2 Shall allow Committee to edit request
Figure 5.3.2: Committee edit dialog
System: Display list of requests
Committee: Viewing request list, Clicks link to request
System: Generates pop up dialog, as seen in figure 5.3.2, to display request information
Committee: Edits request information
System: Automatically populate fields where applicable
Committee: Clicks “Save” button
System: Executes validation procedure
System: Displays “Saving...” dialog
System: Notifies request creator of changes
System: Close pop-up field
5.3.3 Shall allow Committee to approve request.
Figure 5.3.3: Committee approval dialog
System: Displays list of requests
Committee: Viewing request list, Clicks on link to request.
System: Generates pop up dialog, as seen in figure 5.3.3, with request information
Committee: Clicks “Approve Button”
System: Flags request as “Approved by Committee”
System: Notifies Department Chair of approved request by Committee
System: Close pop-up dialog
5.3.4 Shall allow Committee to deny request
System: Display list of requests
Committee: Viewing request list, Clicks on link to request
System: Generates pop-up dialog to display request information
Committee: Clicks “Deny Button”
System: Flags request as ir”
System: Notifies Requester of denied request by Committee
System: Closes pop-up dialog
5.3.5 Shall allow Committee to post feedback on request
Committee: Viewing request form dialog, Clicks “Send Feedback” button
System: Displays Send Feedback dialog
Committee: Inputs Appropriate Feedback, Clicks Submit
System: Feedback is Sent to the Author of the Request, Confirms the Sending
Committee: Clicks OK to Confirm
System: Closes pop-up dialogue
5.3.6 Shall allow Committee to print request
Figure 5.3.6: Committe request library view
Committee: Viewing request after clicking on “documents”, as seen in 5.3.6, Clicks “Print” button
System: Displays Print Dialog
Committee: Clicks “Print”
System: Prints request form
5.4 External Department Use Case
Actors: External Department, System
Preconditions: Committee use case (Committee approval)
5.4.1 Shall display list of requests approved by Committee
Figure 5.4.1: External Department library view
External Department: Viewing home page, Clicks “Pending Requests”, view changes to figure
5.4.1
System: Generates list of requests approved by committee and original department
5.4.2 Shall allow External Department to view request
Figure 5.4.2:
External Department: Viewing request list, as seen in figure 5.4.2, Clicks “View Request”
System: Creates pop-up dialog in View only mode.
5.4.3 Shall allow external department to download request
Figure 5.4.3: External department document view
External Department: Viewing Request, as seen in figure 5.4.3. Clicks “Download a Copy”
System: Displays Download Dialog
User: Clicks Save
System: Starts download
5.4.4 Shall allow users to comment on Request
Figure 5.4.4: External department comment dialog
User: Viewing View Only Mode, Clicks “Comment”
System: Generates pop-up dialog, as seen in figure 5.4.4, for users to enter comment.
User: Types comment in comment field and clicks “Send”
System: Executes validation procedure
System: Sends email to Requester with comments attached
5.5 Associate Dean Use Case
Actors:Associate Dean, System
Preconditions: Department use case
5.5.1 Shall display list of pending requests
Figure 5.5.1: Associate Dean request library view
Associate Dean: Viewing home page on Undergraduate studies subsite with a customized view
for Associate Dean. Clicks “Pending Requests”
System: Generates list of requests pending Associate Dean Approval.
5.5.2 Shall allow Associate Dean to edit request
Figure 5.5.2: Associate Dean edit dialog
System: Display list of requests
Associate Dean: Viewing request list, Clicks link to request
System: Generates pop-up dialog, as seen in Figure 5.5.2, to display request information
Associate Dean: Edits request information
System: Automatically populate fields where applicable
Associate Dean: Clicks “Save” button
System: Executes validation procedure.
System: Displays “Saving...” dialog.
System: Notifies request creator of changes.
System: Close pop-up field
5.5.3 Shall allow Associate Dean to approve request.
Figure 5.5.3: Associate Dean approval dialog
System: Displays list of requests
Associate Dean: Viewing request list, Clicks on link to request.
System: Generates pop up dialog, as seen in figure 5.5.3, with request information
Associate Dean: Clicks “Approve Button”
System: Flags request as “Approved by Associate Dean”
System: Notifies External Departments.
System: Close pop-up dialog
5.5.4 Shall allow Associate Dean to deny request
System: Display list of requests
Associate Dean: Viewing request list, Clicks on link to request
System: Generates pop-up dialog to display request information
Associate Dean: Clicks “Deny Button”
System: Flags request as “Denied by Associate Dean”
System: Notifies Requester of denied request by Associate Dean
System: Closes pop-up dialog
5.5.5 Shall allow Associate Dean to post feedback on request
Associate Dean: Viewing request form dialog, Clicks “Send Feedback” button
System: Displays Send Feedback dialog
Associate Dean: Inputs Appropriate Feedback, Clicks Submit
System: Feedback is Sent to the Author of the Request, Confirms the Sending
Associate Dean: Clicks OK to Confirm
System: Closes pop-up dialogue
5.5.6 Shall allow Associate Dean to download request
Figure 5.5.6
Associate Dean: click documents, view switches to figure 5.5.6, Clicks “Download a copy”
button
System: Displays Download Dialog
Associate Dean: Clicks “Save”
System: Starts Download
5.6 EPC Use Case
Actors: EPC, System
Preconditions: Associate Dean Approval
5.6.1 Shall display list of pending requests
Figure 5.6.1: EPC Pending Requests library view
EPC: Viewing home page, Clicks “Pending Requests”
System: Generates list of pending requests with Department Approval
5.6.2 Shall allow EPC to edit request
Figure 5.6.2: EPC edit dialog
System: Display list of requests
EPC: Viewing request list, Clicks link to request
System: Generates pop up dialog, as seen in figure 5.6.2, to display request information
EPC: Edits request information
System: Automatically populate fields where applicable.
EPC: Clicks “Save” button
System: Executes validation procedure
System: Displays “Saving...” dialog
System: Notifies request creator of changes
System: Close pop-up dialog
5.6.3 Shall allow EPC to approve request.
Figure 5.6.3: EPC approval dialog
System: Displays list of requests
EPC: Viewing request list, Clicks on link to request.
System: Generates pop up dialog, as seen in figure 5.6.3, with request information
EPC: Clicks “Approve Button”
System: Flags request as “Approved by EPC”
System: Notifies GET/Registrars of approved request by EPC
System: Close pop-up dialog
5.6.4 Shall allow EPC to deny request
System: Display list of requests
EPC: Viewing request list, Clicks on link to request
System: Generates pop-up dialog to display request information
EPC: Clicks “Deny Button”
System: Flags request as died by EPC
System: Notifies Requester of denied request by EPC
System: Closes pop-up dialog
5.6.5 Shall allow EPC to download request
Figure 5.6.5: EPC document view
EPC: Viewing request, as seen in figure 5.6.5, Clicks “Download a copy” button
System: Displays Download Dialog
EPC: Clicks “Save”
System: Starts download
5.7 GET Use Case
Actors: GET, System
Preconditions: EPC approval
5.7.1 Shall display list of requests approved by EPC
Figure 5.7.1: GET Approved Requests library view
GET: Viewing home page, Clicks “Approved Requests”
System: Generates list of requests approved by EPC
5.4.2 Shall allow GET to view request
Figure 5.4.2: GET view dialog
GET: Viewing request list, Clicks “View Request”
System: Creates pop-up dialog, as seen in figure 5.4.2, in View only mode.
5.4.3 Shall allow GET to download request
Figure 5.4.3: GET document view
GET: Viewing Request, as seen in figure 5.4.3, Clicks “Download a copy”
System: Displays Download Dialog
GET: Clicks Save
System: Starts download
5.8 Site Administrator Use Case
5.8.1 Shall allow Site Administrator to Add Users to Their Site
Figure 5.8.1: Site Administrator Add User dialog
System: Displaying home page
Administrator: Clicks “Users” link
System: Displays a table of the current users in the site, and commands
Administrator: Clicks “Add user” link
System: Generates a pop-up dialog with a text box in order to determine which users or groups
are added to the site
Administrator: Inputs users and/or groups to add to the site
System: Executes user validation process and adds cleared users to the site, pop-up dialog
closes and user list is updated
5.8.2 Shall allow Site Administrator to Remove Users to Their Site
Figure 5.8.2: Site Administrator remove user dialog
System: Displaying home page
Administrator: Clicks “Users” link
System: Displays a table of the current users in the site, and commands
Administrator: Clicks “Remove user” link
System: Generates a pop-up dialog with checkboxes that allow for specific users or groups to
be removed from the site
Administrator: Inputs users and/or groups to be removed to the site
System: Executes user validation process and removes selected users to the site, pop-up dialog
closes and user list is updated
6. Nonfunctional Requirements
6.1 Performance Requirements
Processing times shall not exceed 5 minutes, and these processes that update the database
shall not exceed 1 minute.
6.2 Security Requirements
Users must be authorized to access SharePoint sites by being granted permission by the site’s
administrator.
6.3 Software Quality Attributes
6.3.1 Compatibility
SharePoint sites shall be compatible with Internet Explorer 9 and Firefox 16. These sites shall
also be accessible with all operating systems used to access them.
6.3.2 Reusability
SharePoint sites shall be reusable until deemed unnecessary by the administrator.
6.3.3 Securability
Each user shall be authenticated through the IIS Authentication System, and they shall have
their own set of permissions based on the group they are in.
6.4 Documentation
Any documentation in addition to this one shall be added as they become necessary.
7. Glossary
Department Chair: A subgroup of user, Department Chair for Requesters department.
External Department: Other departments besides Requester’s.
Main site: The SharePoint site that contains all the necessary subsites, only accessible to the
site administrator and also contains the workflow.
MCRW: Modernize Curriculum Review Workflow
Requester: Specific user who uploaded the course proposal.
Request: Internal name for Course Request Document, including data, such as comments,
added by various users throughout the workflow.
Site Administrator: A user with full administrative privileges on the main site.
Subsite: subsites of the main site
User: The user group the contains the subgroups Department Chair, EPC, Associate Dean, and
site administrator.