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.