Software Requirements

Specification

Co-op Evaluation System

1
Table of Contents

Table of Contents
Revision History
1 Introduction
1.1 Purpose
1.2 Problem
1.3 Document Conventions
1.4 Project Scope
1.5 Intended Audience
1.6 References
2 Overall Description
2.1 Product Perspective
2.2 User Classes and Characteristics
2.3 Evaluation Status States
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 Assumptions and Dependencies
3 System Features
3.1 System Requirements
3.1.1 Form Administration
3.1.2 Evaluations
3.1.3 Submissions
3.1.4 Reports
3.1.5 Email Notifications
3.1.6 Users
3.2 User Requirements
3.2.1 Administrator
3.2.2 Evaluator
3.2.3 Student
3.2.4 Employer
4 Use Cases
4.1 Administrator
4.1.1 Use Case Context
4.1.2 View Student Work Report
4.1.3 View Employer Evaluation
4.1.4 Check Status of Emails
4.1.5 Resend All Failed Emails
4.1.6 Add OCSCE User
4.1.7 Remove OCSCE User 4.1.8
Add Academic Department User
4.1.9 Delete Academic Department User

2
 4.1.10 Transfer Academic Department User
4.1.11 Add College
4.1.12 Remove College
4.1.13 Add Department
4.1.14 Remove Department
4.1.15 Create a New Employer Form
4.1.16 View Existing Employer Form
4.1.17 Delete Existing Employer Form
4.1.18 Edit Existing Employer Form
4.1.19 Create a New Student Form 4.1.20
View Existing Student Form 4.1.21
Delete Existing Student Form 4.1.22 Edit
Existing Student Form 4.1.23 Import
Evaluation
4.1.24 Set Default Evaluation Status
4.1.25 Update Evaluation Status 4.1.26
Initialize Next Term
4.2 Evaluator
4.2.1 Use Case Context
4.2.2 View Student Work Report
4.2.3 View Employer Evaluation
4.2.4 Reject Student Work Report
4.2.5 Accept Student Work Report
4.3 Employer
4.3.1 Use Case Context
4.3.2 Submit a Co•op Evaluation
4.3.2 Save a Co•op Evaluation
4.3.3 Edit & Submit a Co•op Evaluation
4.3.4 View a Submitted Co•op Evaluation
4.3.5 Authenticate Employer
4.4 Student
4.4.1 Use Case Context
4.4.2 Submit Work Report
4.4.3 Save Work Report
4.4.4 Update Work Report
4.4.5 View Work Report
4.4.6 View Employer Evaluation
5 External Interface Requirements
5.1 User Interfaces
5.2 Software Interfaces
5.3 Communications Interfaces
6 Non•functional Requirements
6.1 Performance Requirements

3
 6.2 Security Requirements
6.3 Safety Requirements
6.4 Usability Requirements
6.5 Availability Requirements
6.6 Modifiability Requirements
6.7 Documentation Requirements
6.8 Environment Requirements
Appendix A: Glossary

4
Revision History
Description of
Version Primary Author(s) Date Completed
Version

Emma Nelson,
Maddison Hickson,
v1.0 Initial revision October 6, 2014
Casey Klimkowsky,
Tyler Geery

Update after the

Requirements phase
v1.1 Maddison Hickson October 16, 2014
receiving more
information from Jim

Casey Klimkowsky, Update after receiving

v1.2 Tyler Geery, feedback from Jim on October 28, 2014
Maddison Hickson 10/23/14

Casey Klimkowsky, Update after receiving

v1.3 Tyler Geery, feedback from Jim on October 30, 2014
Maddison Hickson 10/28/14

Updated VM
v1.4 Emma Nelson October 30, 2014
Specification

Casey Klimkowsky, Update after receiving

v1.5 Tyler Geery, feedback from Kim on November 3, 2014
Maddison Hickson 10/28/14

Verified changes and

v1.6 Emma Nelson added priority November 5, 2014
description

Update to match
v1.7 Emma Nelson changes going into February 18, 2015
development

Removed redundant
requirements and
v1.8 Emma Nelson March 15, 2015
updated the priority of
a few requirements

Final version of the

v1.9 Emma Nelson artifact before May 16, 2015
release

5
6
1 Introduction
1.1 Purpose
The purpose of the Co•op Evaluation System (CES) is to allow students to provide feedback on their most
recent co•op, and for employers to provide feedback on a student’s performance during their most recent
co•op. Additionally, the system is used by faculty to approve or fail a student’s co•op, and is also used by
OCSCE to gather data on students’ co•ops.

This SRS describes the entire scope of the new Co•op Evaluation System, which is elaborated upon in
1.3.

1.2 Problem
RIT’s current Co•op Evaluation System, an application used by OCSCE, has a number of performance,
reliability, usability, and maintainability issues. Among others, session timeouts and submission timeouts are
inherit problems of the current Co•op Evaluation System. A new version started from scratch with up•to•date
technologies needs to be developed.

1.3 Document Conventions

Each requirement statement is to have its own priority, which is listed next to the requirement itself. A
priority of “High” indicates that the given requirement is top priority by the development team and is key
to having a functional system. “Medium” priority requirements will be secondary;however, the
development team still expects to complete as many of the associated features as time allows in order to
deliver a functionally equivalent system. Requirements labelled with a “Low” priority are stretch goals
and depend on the time available at the end of the development period. Most of these requirements are
additional features beyond the scope of the current feature set. They are documented for use in future
development either by ITS or another senior project team.

1.4 Project Scope

One of our primary goals is that by the conclusion of this project, we will supply OCSCE and ITS with a
product that is functionally equivalent to the existing system, with fewer performance, reliability, and
maintainability issues. Time permitting, we hope to implement a small number of enhancements, as defined
by our project sponsors, as well. If the scope ends up being too much, our primary focus will shift to
getting forms working end•to•end from creation and assignment all the way through to approval or
rejection. We plan to design and implement the system with extensibility in mind, so that in the future,
other developers may implement additional features that we were unable to implement during the duration
of this project.

Several features that exist in the current system, but need to be drastically improved, are report
generation, form generation, and error messages. Even though we are aiming for functional equivalence
for these features, we intend to greatly improve their usability. We plan to address other major pain
points, such as the ability to change a student’s supervisor at a later date, as well.

7
1.5 Intended Audience
This document is intended to help the development team to validate that they are building the right
application, and verify that the features they have built are built correctly. It is also intended for the
project sponsors to sign off on as a definitive list of requirements. Finally, the project coach can use this
document to validate the development team is meeting the agreed upon requirements during his evaluation
of the team’s efforts.

1.6 References
We were given the following materials to help us define the requirements of the system:

Reference Description

Created by the ITS team, and contains sample

ITS Wiki Page applications as well as guidelines we must abide
by

Written by the sponsors, and contains much of

Project Proposal the background and high•level goals of the
project.

This includes documentation and code from the

Collection of all previous work on the project previous senior project teams that worked on the
Co•op Evaluation System.

This document defines a set of standards that

create a framework for proper usage with regard to
RIT Web Standards language, graphics, and navigational architecture
on all RIT•related websites.

8
2 Overall Description
2.1 Product Perspective
The purpose of this project is to re•engineer the Co•op Evaluation System in order to leverage newer web
technologies while also improving performance and user interaction. The current system uses outdated,
under•documented technology, which makes it difficult to maintain.
Furthermore, the random errors that occur do not give users confidence that their information was
submitted properly. Significant improvements to the user interface will need to be made, but the existing
database structures can be used as a reference for modifications.

The above diagram outlines the major components of the overall system, subsystem interconnections, and
external interfaces, which are elaborated upon in Section 5.

9
The diagram above show a high•level view of the user interaction with the system as well as the interaction
between technologies involved.

2.2 User Classes and Characteristics

User Description of Use Frequency of Use

Uses application to fill out a

Student 1 time per co•op block
Work Report

Uses application to fill out an 1 time per student per co•op

Employer
Employer Evaluation block

Uses application to review the

student’s and employer’s survey
1 time per student being
Evaluator responses to determine the
evaluated
student’s grade (S or F)

As needed to generate
Uses application to gather
reports, create new forms,
Administrator statistical data from survey
and perform other
responses
administrative tasks

2.3 Evaluation Status States

Evaluations, both Employer and Student, will start out as Pending. In the pending state, the evaluation
appears in the system, but cannot be filled out yet.

10
Three weeks from the end of the term, all evaluations will be changed from Pending to Open. An evaluation
in the Open state can be filled out by an Employer or Student that it is assigned to. An open evaluation can
be changed to Saved, Submitted, Manually Completed, or Archived state.

If the user saved the evaluation, it is changed to the Saved state. In this state, the user can open the
evaluation and continue filling out answers. They can continue saving the evaluation until they are
finished. The Saved sate will be referred to as “In Progress” in the user interface. The evaluation can be
changed to Submitted, Manually Completed, or Archived state from the Saved state.

The Submitted state is reached by submitting the form from either the Open state or the Saved state. In this
state, the evaluation cannot be changed by any class of user. At this point, the only change that can be
made to the evaluation is by an evaluation approval change. If the evaluation is approved, nothing else will
happen. If the evaluation is rejected, the evaluation will go back to the Saved state.

There are two other states that an evaluation can end up in: Manually Completed and Archived. If the
evaluation is completed in some way other than the normal process, an evaluation can be changed to the
Manually Completed state. If the evaluation will never be completed, and the user does not want to receive
messages telling them to fill out the evaluation, the evaluation can be marked as Archived. The Archived
state was known as the Past Pending state in the previous version of the CES.

11
2.4 Operating Environment
Since the product will be a web•based application, the software is required to be accessible by numerous
browsers, and different versions of each browser. The browser in which the application is accessed may
be from a desktop computer, or a mobile device.

The required browsers and versions of each in which the system must be accessible from are as follows:

● Google Chrome, latest version

● Mozilla Firefox, latest version
● Safari, latest version
● Internet Explorer, 9+

The system itself shall be deployed and will operate on a VM provided by ITS. The system specifications of
this VM are as follows:
● The server is currently running Tomcat 7.0.55. The version will be upgraded to 7.0.56 in
January.
● The amount of memory will be adjusted to suit the needs of our application.
● The current configuration has both the minimum and maximum heap size is set to 512MB. If
more space is required, another Tomcat instance will be spun up to distribute the load across two
servers controlled by the same host.
● Hardware is shared between many applications and monitored by the ITS application support
team.
● Both TEST and PROD servers are within the RIT network and will require use of the RIT VPN
in order to conduct testing.

2.5 Design and Implementation Constraints

The system must comply with the development guidelines provided to us by ITS, as defined by the EWA
Student Development Guidelines wiki page. At a high level, these guidelines include approved application
frameworks, build tools, application server technologies, database standards, and several other technology
standards.

The system must also comply with the RIT Web standards document, which defines the standards for
RIT•related websites in regard to language, graphics, and navigational architecture.

2.6 Assumptions and Dependencies

Our biggest personal assumption is that our own experiences on co•op and with the old CES are
representative of every student. However, we know this is not the case, so we will do our best to talk to our
friends in other majors to glean their perspectives. We will use our experiences and those of other users as
examples of what can happen, not as hard facts.

JobZone may become a potential dependency. Right now employers can log in there without an RIT
computer account, and the hope is that the CES can get the authentication token from

12
JobZone to authenticate the user on the Co•op Evaluation System. However, this is still up in the air; there
may be some re•planning around finding an alternative solution for Employer Authentication.

SIS was another potential tie•in on the Evaluator side; however, this is out of scope for this project. The
sponsor was looking into finding out if the Evaluator role can be shifted to SIS for an easier interaction
experience for faculty and staff who use SIS on a daily basis. In this case, the system would need to
provide a portal for SIS to access information as needed, and to send messages of acceptance or rejection
for Student Evaluations.

3 System Features
3.1 System Requirements
3.1.1 Form Administration
Number Priority Requirement

Student and Employer evaluations shall have the following progress

F•01 High statuses: Submitted, Saved, Open, Pending, Manually Completed, and
Archived. Refer to Section 2.3 for more detail.

Student evaluations shall have the following evaluation approval

F•02 High
statuses: Submitted, Approved, and Rejected.

The system shall record an evaluation approval status change trail.

F•03 Medium

The system shall automatically change the progress status of all

F•04 Medium evaluations from Pending to Open after a configurable number of
weeks before the end of a Student’s co•op.

F•05 High The system shall store evaluations in a database.

3.1.2 Evaluations
Number Priority Requirement

The system shall be able to automatically save non•submitted evaluation

E•01 Low
forms.

The system shall be able to validate an evaluation for completeness.

E•02 High

The system shall be able to validate an evaluation for correctness (e.g.

E•03 Medium
email validation) the client side.

13
3.1.3 Submissions
Number Priority Requirement

The system shall display the submissions in a format that is printable.

S•01 Medium

The system shall be able to search forms based on student last name,
student first name, student ID, company name, term, department,
S•02 High advisor’s RIT Computer Account user name, student progress status,
evaluation progress status, and employer evaluation status.

3.1.4 Reports
Number Priority Requirement

Out of The system shall generate reports based on a user•defined selection of

R•01
Scope submissions and statistics.

Out of The system shall produce statistics on all questions that have numeric
R•02
Scope answers.

Out of The system shall produce statistics on all questions that have qualitative
R•03
Scope answers (“Comments Only”).

The system shall use an third•party service to generate reports that, at

Out of
R•04 a minimum, supports the reports generated by the current system.
Scope

The system shall be able to accommodate the addition of a more

Out of
R•05 reports as defined by the sponsor and other users of the CES.
Scope

Out of The system should provide an easy way to select items to be included or
R•06
Scope excluded from the report.

Out of The system should provide the ability to run reports across multiple
R•07
Scope year•levels (i.e. all undergraduate students).

Out of The system should be able to export the SQL view created for the
R•08
Scope report.

Out of The system shall be able to export the report data in CSV format for
R•09
Scope use in any spreadsheet application.

Out of
R•10 The system should be able to run reports on qualitative data.
Scope

14
 Out of The system should display the qualitative questions on forms as
R•11
Scope selectable options when choosing the report settings.

Out of The system shall take no longer than 3 minutes to generate a report.
R•12
Scope

Out of
R•13 The system shall have the ability run a report by academic year.
Scope

Out of
R•14 The system should have the ability to run a report by form.
Scope

3.1.5 Email Notifications

Number Priority Requirement

Out of The system shall be able to send generated email notifications to

N•01
Scope Students and Evaluators manually.

Out of The system shall be able to send generated email notifications to

N•02
Scope Students and Evaluators automatically.

The system shall be able to generate evaluation notifications to all

Out of
N•03 Employers and Students a configurable number of weeks before the
Scope
Student’s end date.

Out of The system shall be able to generate a student confirmation email to

N•04
Scope Students and Employers.

Out of The system shall be able to display notification statuses for Student and
N•05
Scope Employer notifications. (Use Case 4.1.4)

Out of The system shall be able to display failed emails and sent emails in
N•06
Scope the notifications statuses.

Out of The system shall send a notification email to a Student or Employer

N•07
Scope when their evaluation has been rejected.

Out of The system shall send an email notification to Students confirming

N•08
Scope their supervisor, start date, and end date.

Out of The system shall send a notification email to Students when their
N•09
Scope work report was successfully persisted.

Out of The system shall send a notification email to Employers when their
N•10
Scope evaluation was successfully persisted.

15
 The system shall send an email notification to Students and
Out of
N•11 Employers when an evaluation has been Saved, but not submitted for
Scope
a period of two weeks.

Out of The system shall send an email notification to Evaluators when their
N•12
Scope students submit a work report.

3.1.6 Users
Number Priority Requirement

The system shall use the user information captured from existing
U•01 High OCSCE database to provide authorization for employers.

The system shall be able to automatically initialize the next term for
U•02 Medium Students and Employers based on the RIT academic calendar.

The system shall be able to update the status of submissions when

U•03 High
supplied with a new status (manually or automatically).

The system shall use Shibboleth to authorize students, faculty, and

U•04 High
OCSCE staff.

3.2 User Requirements

3.2.1 Administrator
Number Priority Requirement

An Administrator shall be able to search Student and Employer

AD•01 High
evaluations.

An Administrator shall be able to search Student and Employer

AD•02 High
submissions.

An Administrator shall be able to compare Student and Employer

AD•03 Medium
submissions, side•by•side.

An Administrator shall be able to create Student/Employer forms.

AD•04 High

AD•05 High An Administrator shall be able to view Student/Employer forms.

An Administrator shall be able to update Student/Employer forms.

AD•06 High

16
 An Administrator shall be able to archive Student/Employer forms.
AD•07 Low

An Administrator shall be able to delete forms that have no submissions

AD•08 Medium
associated with them.

AD•09 High An Administrator shall be able to assign forms to departments.

An Administrator shall be able to update the status of any groups of

AD•10 Low
evaluations.

An Administrator shall be able to view the status of any evaluation.

AD•11 High

Out of
AD•12 An Administrator shall be able to create and edit notifications.
Scope

Out of
AD•13 An Administrator shall be able to resend failed notifications.
Scope

Out of An Administrator shall be able to view the configurations of

AD•14
Scope notifications.

Out of An Administrator shall be able to update the configurations of

AD•15
Scope notifications.

Out of
AD•16 An Administrator shall be able to generate reports.
Scope

An Administrator shall be able to copy the contents of an existing

AD•17 Low
Student or Employer form to a new form.

An Administrator shall be able to add/remove OCSCE users to the

AD•28 High
system.

An Administrator shall be able to add/remove Academic Department

AD•19 High
(Evaluator) users from the system.

An Administrator shall be able to add/remove colleges and departments

AD•20 High
to the system.

An Administrator shall be able to transfer Academic Department user

AD•21 Low
privileges to another user.

An Administrator shall be able to import a file containing evaluations.

AD•22 High

17
3.2.2 Evaluator
Number Priority Requirement

The Evaluator shall be able to view Student submissions associated with

EV•01 High
their department.

The Evaluator shall be able to view Employer submissions associated

EV•02 High
with their department.

The Evaluator shall be able to view Student evaluations associated with

EV•03 Low
double majors in their department.

The Evaluator shall be able to view Employer evaluations associated

EV•04 Low
with double majors in their department.

The Evaluator shall be able to view Student submissions associated with

EV•05 Low
double majors in their department.

The Evaluator shall be able to view Employer submissions associated

EV•06 Low
with double majors in their department.

The Evaluator shall be able to compare current Student and Employer

EV•07 Medium
submissions.

EV•09 High The Evaluator shall be able to accept or reject a submission.

The Evaluator shall be able to view the status for all evaluations
EV•10 High
associated with their department.

Out of The Evaluator shall be able to create notifications for their department.
EV•11
Scope

Out of The Evaluator shall be able to view the configuration of the

EV•12
Scope notifications.

An Evaluator shall be able to change the status of a work report from

EV•13 Low
archived to open.

3.2.3 Student
Number Priority Requirement

ST•01 High A Student shall be able to view their own work reports.

A Student shall be able to update their own work reports before

ST•02 High
submission unless it has been rejected.

ST•03 High A Student shall be able to submit their own work reports.

18
 ST•04 High A Student shall be able to view their own submissions.

A Student shall be able to view the submissions of their Employers.

ST•05 High

A Student shall be able to view the status of their own work reports.
ST•06 High

A Student shall be able to view the status of their Employers’

ST•07 High
evaluations.

3.2.4 Employer
Number Priority Requirement

EM•01 High The Employer shall be able to view their evaluations.

EM•02 High The Employer shall be able to update their evaluations.

EM•04 High The Employer shall be able to submit an evaluation.

EM•05 High The Employer shall be able to view their submissions.

The Employer shall be able to view the status of their evaluations.

EM•06 High

4 Use Cases
Refer to the User Analysis and Workflows document for a complete description of the human actors
involved in the system.

19
4.1 Administrator
4.1.1 Use Case Context

4.1.2 View Student Work Report

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description
System to view a Student’s submitted work report.

Trigger Administrator desires to look over a student’s co•op evaluation.

20
 1. The Administrator has an Internet connection.
Pre•conditions
2. The Administrator is authenticated and signed into the system.

Post•conditions The desired student’s work report is displayed to the Administrator.

1. The Administrator selects “Evaluations”.

2. The Administrator selects “Search Submitted/Pending
Evaluations”
3. The Administrator inputs student information.
Normal Flow 4. The Administrator clicks “Search” button.
5. The Administrator selects desired student for the chosen co•op block.
6. The use case ends successfully.

Alternative Flows N/A

Student is Not in the System

If in step 4 of the normal flow the desired student does not exist in the system,
then
Exceptions 1. The system shall display a message stating that the student does
not exist.
2. The use case ends with a failure condition.

4.1.3 View Employer Evaluation

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description
System to view an Employer’s submitted evaluation.

Trigger Administrator desires to look over a student’s co•op evaluation.

1. The Administrator has an Internet connection.

Pre•conditions
2. The Administrator is authenticated and signed into the system.

The desired employer’s co•op evaluation of the student is displayed to the

Post•conditions
Administrator.

1. The Administrator selects “Evaluations”.

2. The Administrator selects “Search Submitted/Pending
Evaluations”
3. The Administrator clicks “Search” button.
Normal Flow 4. The Administrator selects desired employer evaluation link for the
chosen student and co•op block.
5. The Administrator selects the submission for the specific
semester.
6. The use case ends successfully.

21
 Alternative Flows N/A

Employer is Not in the System

If in step 4 of the normal flow the desired employer does not exist in the
Exceptions system, then
1. There is no action to be taken by the Administrator.
2. The use case ends with a failure condition.

4.1.4 Check Status of Emails

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description System to check the status of the reminder emails sent out to students and
employers.

Administrator desires to look over the status of emails sent to students and
Trigger
employers.

1. The Administrator has an Internet connection.

Pre•conditions
2. The Administrator is authenticated and signed into the system.

Administrator is viewing the given status of student and employer emails.

Post•conditions

1. The Administrator selects “Email” from the navbar.

2. The Administrator selects “Email Status” from the dropdown.
3. The Administrator selects either “Student” or “Employer” to
display the associated emails.
Normal Flow 4. The Administrator views scheduled emails as well as the date and
time for which the emails are scheduled.
5. The Administrator views failed emails and the reason for
failure.
6. The use case ends successfully.

Alternative Flows N/A

Exceptions N/A

4.1.5 Resend All Failed Emails

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description System to send out any email notifications that failed to send to students and
employers.

22
 Administrator desires to send out any email notifications that failed to send to
Trigger
students and employers.

1. The Administrator has an Internet connection.

Pre•conditions
2. The Administrator is authenticated and signed into the system.

Post•conditions The Administrator resent all “failed” emails.

1. The Administrator selects “Email” from the navbar.

2. The Administrator selects “Email Status” from the dropdown.
3. The Administrator selects either “Student” or “Employer” to
display the associated emails.
Normal Flow
4. The Administrator sees a list of all emails that failed to send.
5. The Administrator selects “Resend All Failed Emails” from
page.
6. The use case ends successfully.

Alternative Flows N/A

No Failed Emails in System

If in step 4 of the normal flow there are no emails that failed to send, then
Exceptions 1. The Administrator does nothing.
2. The use case ends with a failure condition.

4.1.6 Add and Administrator

Actors Administrator

This use case describes how an administrator uses the Co•op Evaluation
Description
System to add an administrator to the system.

Trigger Administrator desires to add an administrator to the system.

1. The Administrator has an Internet connection.

Pre•conditions
2. The Administrator is authenticated and signed into the system.

Post•conditions Administrator successfully added the administrator to the system.

1. The Administrator accesses “Users” in the navigation bar.

2. The Administrator chooses “Administrators” from the dropdown
menu.
3. The Administrator clicks the “Add new” button.
Normal Flow
4. The Administrator enters the user’s RIT account information.
5. The Administrator selects the “Add” button.
6. The Administrator verifies user has been added to the system.
7. The use case ends successfully.

23
 Alternative Flows N/A

User Already in the System

If in step 2 of the normal flow the user is already an administrator, then
Exceptions 1. There is no action to be taken by the Administrator.
2. The use case ends with a failure condition.

4.1.7 Remove an Administrator

Actors Administrator

This use case describes how an administrator uses the Co•op Evaluation
Description
System to remove an administrator from the system.

Trigger Administrator desires to remove an administrator to the system.

1. The Administrator has an Internet connection.

Pre•conditions
2. The Administrator is authenticated and signed into the system.

Post•conditions Administrator successfully removed the administrator from the system.

1. The Administrator accesses “Users” in the navigation bar.

2. The Administrator chooses “Administrators” from the dropdown
menu.
3. The Administrator searches for the user in the table listing all
Normal Flow current users.
4. The Administrator locates user to be removed from the system.
5. The Administrator clicks the “Remove” button in the row listing the
selected user.
6. The use case ends successfully.

Alternative Flows N/A

Exceptions N/A

4.1.8 Add Academic Department User

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description System to add an Academic Department User to the system.

Administrator desires to add an Academic Department User to the system.

Trigger

Pre•conditions 1. The Administrator has an Internet connection.

24
 2. The Administrator is authenticated and signed into the system.

Administrator successfully added an Academic Department User to the

Post•conditions
system.

1. The Administrator accesses “Users” in the navigation bar.

2. The Administrator chooses “Department Users” from the
dropdown menu.
3. The Administrator clicks the “Add new” button.
Normal Flow
4. The Administrator enters the user’s RIT account information.
5. The Administrator selects the “Add” button.
6. The Administrator verifies user has been added to the system.
7. The use case ends successfully.

Alternative Flows N/A

Department User Already in the System

If in step 5 of the normal flow the user is already an Academic Department
User, then
Exceptions 1. There is no action to be taken by the Administrator.
2. The use case ends with a failure condition. The system returns with
an error message.

4.1.9 Delete Academic Department User

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description System to remove an Academic Department User from the system.

Administrator desires to remove an Academic Department User from the

Trigger
system.

1. The Administrator has an Internet connection.

Pre•conditions
2. The Administrator is authenticated and signed into the system.

Administrator successfully deletes an Academic Department User from the

Post•conditions
system.

1. The Administrator accesses “Users” in the navigation bar.

2. The Administrator chooses “Department Users” from the
dropdown menu.
Normal Flow 3. The Administrator searches for the user in the table listing all
current users.
4. The Administrator locates user to be removed from the system.

25
 5. The Administrator clicks the “Remove” button in the row listing the
selected user.
6. The use case ends successfully.

Alternative Flows N/A

Exceptions N/A

4.1.10 Transfer Academic Department User

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description System to transfer an existing user’s privileges in the system to another user.

Administrator desires to transfer existing user in the system to another

Trigger
department.

1. The Administrator has an Internet connection.

Pre•conditions
2. The Administrator is authenticated and signed into the system.

Post•conditions Administrator successfully transferred user to another department.

1. The Administrator accesses “Users” in the navigation bar.

2. The Administrator chooses “Transfer Department Users” from the
dropdown menu.
3. The Administrator selects the source college the department is
currently under.
Normal Flow 4. The Administrator selects the department.
5. The Administrator chooses the destination college the
department users will be under.
6. The Administrator selects the new department.
7. The Administrator clicks the “Transfer” button.
8. The use case ends successfully.

Alternative Flows N/A

Exceptions N/A

4.1.11 Add College

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description
System to add a new college to the system.

26
 Trigger Administrator desires to add a new college to the system.

1. The Administrator has an Internet connection.

Pre•conditions
2. The Administrator is authenticated and signed into the system.

Post•conditions Administrator successfully added a new college to the system.

1. The Administrator accesses “Users” in the navigation bar.

2. The Administrator chooses “College Management” from the
dropdown menu.
Normal Flow 3. The Administrator clicks the “Add New” button.
4. The Administrator enters desired college name.
5. The Administrator selects the “Add” button.
6. The use case ends successfully.

Alternative Flows N/A

College Already in the System

If in step 5 of the normal flow the college is already in the system, then
Exceptions 1. There is no action to be taken by the Administrator.
2. The use case ends with a failure condition. The system will
return with an error message.

4.1.12 Remove College

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description
System to remove a college from the system.

Trigger Administrator desires to remove a college from the system.

1. The Administrator has an Internet connection.

Pre•conditions
2. The Administrator is authenticated and signed into the system.

Post•conditions Administrator successfully removed a college from the system.

1. The Administrator accesses “Users” in the navigation bar.

2. The Administrator chooses “College Management” from the
dropdown menu.
Normal Flow
3. The Administrator selects the college to be removed.
4. The Administrator selects the “Remove” button.
5. The use case ends successfully.

Alternative Flows N/A

Exceptions Form Submission for College

27
 If in step 3 of the normal flow the college to be deleted has an existing form
submission associated with it, then
1. The system displays a message saying that college cannot be deleted
because there is an existing form submission under that college.
2. The use case ends with a failure condition.

4.1.13 Add Department

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description
System to add a new department to the system.

Trigger Administrator desires to add a new department to the system.

1. The Administrator has an Internet connection.

Pre•conditions
2. The Administrator is authenticated and signed into the system.

Post•conditions Administrator successfully added a new department to the system.

1. The Administrator accesses “Users” in the navigation bar.

2. The Administrator chooses “Department Management” from the
dropdown menu.
3. The Administrator selects the college to which the new
department will belong.
Normal Flow 4. The Administrator clicks the “Add New” button.
5. The Administrator enters desired department name.
6. The Administrator enters desired department code.
7. The Administrator clicks the “Add” button.
8. The Administrator verifies department was added.
9. The use case ends successfully.

Alternative Flows N/A

Department Already in the System

If in step 7 of the normal flow the department is already in the system, then
1. There is no action to be taken by the Administrator.
Exceptions
2. The use case ends with a failure condition. The system will
return with an error message.

4.1.14 Remove Department

Actors Administrator

Description This use case describes how an Administrator uses the Co•op

28
 Evaluation System to remove a department from the system.

Trigger Administrator desires to remove a department from the system.

1. The Administrator has an Internet connection.

Pre•conditions
2. The Administrator is authenticated and signed into the system.

Post•conditions Administrator successfully removed a department from the system.

1. The Administrator accesses “Users” in the navigation bar.

2. The Administrator chooses “Department Management” from the
dropdown menu.
3. The Administrator selects the college to which the new
Normal Flow department will belong.
4. The Administrator locates the department name/code desired to be
removed.
5. The Administrator selects the “Remove” button.
6. The use case ends successfully.

Alternative Flows N/A

Form Submission for Department

If in step 5 of the normal flow the department to be deleted has an existing
form submission associated with it, then
Exceptions 1. The system displays a message saying that department cannot
be deleted because there is an existing form submission under
that department.
2. The use case ends with a failure condition.

4.1.15 Create a New Employer Form

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description
System to create a new Employer form.

Trigger Administrator desires to create a new Employer form.

1. The Administrator has an Internet connection.

Pre•conditions
2. The Administrator is authenticated and signed into the system.

Post•conditions Administrator successfully created a new Employer form.

1. The Administrator selects “Forms” from the navigation menu.

2. The Administrator selects “Employer Forms” under the Forms
Normal Flow
dropdown.
3. The Administrator clicks the “Add New” button.

29
 4. The Administrator types in the name for the new form.
5. The Administrator creates the new blank form.
6. The use case ends successfully.

Alternative Flows N/A

Form Failed to Submit

If in step 5 of the normal flow an error occurs when the Administrator attempts
to submit the form, then
Exceptions 1. The system displays an error message stating what went
wrong.
2. The use case ends with a failure condition.

4.1.16 View Existing Employer Form

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description
System to view an existing form for a given department.

Trigger Administrator desires to view existing form for given department.

1. The Administrator has an Internet connection.

Pre•conditions
2. The Administrator is authenticated and signed into the system.

Post•conditions Administrator successfully viewed an existing employer form.

1. The Administrator selects “Forms” from the navigation menu.

2. The Administrator selects “Employer Forms” under the Forms
dropdown.
Normal Flow
3. The Administrator clicks the name of an existing employer
form.
4. The use case ends successfully.

Alternative Flows N/A

Exceptions N/A

4.1.17 Delete Existing Employer Form

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description
System to delete an existing form for a given department.

Trigger Administrator desires to delete Existing form for given department

Pre•conditions 1. The Administrator has an Internet connection.

30
 2. The Administrator is authenticated and signed into the system.

Post•conditions Administrator successfully deleted an existing employer form.

1. The Administrator selects “Forms” from the navigation menu.

2. The Administrator selects “Employer Forms” under the Forms
dropdown.
Normal Flow
3. The Administrator locates the form.
4. The Administrator clicks the “Delete” button.
5. The use case ends successfully.

Alternative Flows N/A

Employer Submission for Selected Form

If in step 3 of the normal flow the form to be deleted has an existing employer
submission, then
Exceptions 1. The system displays a message saying that form cannot be deleted
because there is an existing submission for that form.
2. The use case ends with a failure condition.

4.1.18 Edit Existing Employer Form

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description
System to edit an existing form for a given department.

Trigger Administrator desires to edit existing form for given department.

1. The Administrator has an Internet connection.

Pre•conditions
2. The Administrator is authenticated and signed into the system.

Post•conditions Administrator successfully edited an existing employer form.

1. The Administrator selects “Forms” from the navigation menu.

2. The Administrator selects “Employer Forms” under the Forms
dropdown.
3. The Administrator selects the desired form.
Normal Flow 4. The Administrator clicks the “Edit” button.
5. The Administrator makes desired changes to the form.
6. The Administrator scrolls to the bottom of the form, and clicks the
“Save Changes” button.
7. The use case ends successfully.

Cancel Changes
Alternative Flows If in step 5 of the normal flow the Administrator desires to cancel their
changes, then

31
 1. The Administrator scrolls to the bottom of the form, and clicks the
“Cancel” button.
2. The use case ends successfully.

Exceptions N/A

4.1.19 Create a New Student Form

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description
System to create a new Student form.

Trigger Administrator desires to create a new Student form.

1. The Administrator has an Internet connection.

Pre•conditions
2. The Administrator is authenticated and signed into the system.

Post•conditions Administrator successfully created a new Student form.

1. The Administrator selects “Forms” from the navigation menu.

2. The Administrator selects “Student Forms” under the Forms
dropdown.
Normal Flow 3. The Administrator clicks the “Add New” button.
4. The Administrator adds a name to the form.
5. The Administrator creates the blank form.
6. The use case ends successfully.

Alternative Flows N/A

Form Failed to Submit

If in step 5 of the normal flow an error occurs when the Administrator attempts
to submit the form, then
Exceptions 1. The system displays an error message stating what went
wrong.
2. The use case ends with a failure condition.

4.1.20 View Existing Student Form

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description
System to view an existing form for a given department.

Trigger Administrator desires to view existing form for given department.

1. The Administrator has an Internet connection.

Pre•conditions
2. The Administrator is authenticated and signed into the system.

32
 Post•conditions Administrator successfully viewed an existing student form.

1. The Administrator selects “Forms” from the navigation menu.

2. The Administrator selects “Student Forms” under the Forms
dropdown.
Normal Flow
3. The Administrator selects the form.
4. The Administrator clicks the “View” button.
5. The use case ends successfully.

Alternative Flows N/A

Exceptions N/A

4.1.21 Delete Existing Student Form

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description
System to delete an existing form for a given department.

Trigger Administrator desires to delete existing form for given department.

1. The Administrator has an Internet connection

Pre•conditions
2. The Administrator is authenticated and signed into the system.

Post•conditions Administrator successfully deleted an existing student form.

1. The Administrator selects “Forms” from the navigation menu.

2. The Administrator selects “Student Forms” under the Forms
dropdown.
Normal Flow
3. The Administrator selects the form.
4. The Administrator clicks the “Delete” button.
5. The use case ends successfully.

Alternative Flows N/A

Student Submission for Selected Form

If in step 4 of the normal flow the form to be deleted has an existing student
submission, then
Exceptions 3. The system displays a message saying that form cannot be deleted
because there is an existing submission for that form.
4. The use case ends with a failure condition.

4.1.22 Edit Existing Student Form

Actors Administrator

33
 This use case describes how an Administrator uses the Co•op Evaluation
Description
System to edit an existing form for a given department.

Trigger Administrator desires to edit existing form for given department.

1. The Administrator has an Internet connection.

Pre•conditions
2. The Administrator is authenticated and signed into the system.

Post•conditions Administrator successfully edited an existing student form.

1. The Administrator selects “Forms” from the navigation menu.

2. The Administrator selects “Student Forms” under the Forms
dropdown.
3. The Administrator selects the desired form.
Normal Flow
4. The Administrator clicks the “Edit” button.
5. The Administrator makes desired changes to the form.
6. The Administrator clicks the “Save Changes” button.
7. The use case ends successfully.

Cancel Changes
If in step 6 of the normal flow the Administrator desires to cancel their
changes, then
Alternative Flows
1. The Administrator scrolls to the bottom of the form, and clicks the
“Cancel” button.
2. The use case ends successfully.

Exceptions N/A

4.1.23 Import Evaluation

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description
System to import evaluation information for students.

Trigger Administrator desires import a newly registered co•ops .

1. The Administrator has an Internet connection.

Pre•conditions 2. The Administrator is authenticated and signed into the system.
3. The Administrator has an import file.

Post•conditions Administrator successfully imported evaluations into the system.

1. The Administrator selects “Evaluations” from the navigation

menu.
Normal Flow
2. The Administrator selects “Evaluation Management” under the
Evaluations dropdown.

34
 3. Under “Import Evaluations”, the Administrator chooses a file to
import.
4. The Administrator clicks the “Upload” button.
5. The use case ends successfully.

Alternative Flows N/A

File is Not Properly Formatted

If in step 3 of the normal flow the file uploaded is not in the correct format,
then
Exceptions 1. The system displays a message saying that the file is in an
invalid format.
2. The use case ends with a failure condition.

4.1.24 Set Default Evaluation Status

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description
System to set a default evaluation status for a college.

Administrator desires needs to change the default status for a specific college.
Trigger

1. The Administrator has an Internet connection.

2. The Administrator is authenticated and signed into the system.
Pre•conditions
3. The college and department already exists in the system.
4. The evaluation status already exists.

Administrator successfully changed the default evaluation status for a specific

Post•conditions
college or department.

1. The Administrator selects “Evaluations” from the navigation

menu.
2. The Administrator selects “Evaluation Management” under the
Evaluations dropdown.
3. Under “Default Evaluation Status”, the Administrator chooses a
Normal Flow
college from the drop•down menu.
4. The Administrator chooses a department from the dropdown.
5. The Administrator chooses the new default evaluation status.
6. The Administrator clicks the “Set Status” button.
7. The use case ends successfully.

Alternative Flows N/A

Exceptions N/A

35
4.1.25 Update Evaluation Status
Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description
System to update the evaluation status for a college.

Trigger Administrator desires to update the evaluation status for a college.

1. The Administrator has an Internet connection.

2. The Administrator is authenticated and signed into the system.
Pre•conditions
3. The college and department already exists in the system.
4. The evaluation status already exists.

Post•conditions Administrator successfully updated the evaluation status for a college.

1. The Administrator selects “Utilities” from navigation bar.

2. The Administrator selects “Update States” from the dropdown
menu.
3. The Administrator chooses the current evaluation status.
4. The Administrator chooses the new evaluation status.
Normal Flow 5. The Administrator chooses the evaluation type.
6. The Administrator enters the semester id number.
7. The Administrator chooses any number of departments from the
multi•select box.
8. The Administrator clicks the “Update” button.
9. The use case ends successfully.

Alternative Flows N/A

Exceptions N/A

4.1.26 Initialize Next Term

Actors Administrator

This use case describes how an Administrator uses the Co•op Evaluation
Description System to initialize the next term in which students will be on co•op.

Administrator desires to initialize the next term that students will be on co•op.
Trigger

1. The Administrator has an Internet connection.

Pre•conditions 2. The Administrator is authenticated and signed into the system.
3. The term has not already been initialized.

36
 Post•conditions Administrator successfully initialized the next term.

1. The Administrator selects “Utilities” from navigation bar.

2. The Administrator selects “Initialize Next Term” from the
dropdown menu.
Normal Flow 3. The Administrator selects whether to initialize the term for
students and/or employers.
4. The Administrator clicks the “Initialize Term” button.
5. The use case ends successfully.

Alternative Flows N/A

Exceptions N/A

4.2 Evaluator
4.2.1 Use Case Context

4.2.2 View Student Work Report

Actors Evaluator

This use case describes how an Evaluator uses the Co•op Evaluation System to
Description
view a Student’s submitted work report.

37
 Evaluator has received a notification about the students completion and
Trigger
desires to look over a student’s co•op evaluation.

1. Evaluator has an Internet connection.

Pre•conditions 2. Evaluator is authenticated and signed into the system.
3. The student has already finished their work report.

Post•conditions Evaluator is viewing the given student’s work report evaluation.

1. The Evaluator accesses “Evaluations” from the nav bar.

2. The Evaluator inputs student information.
3. The Evaluator clicks the “Search” button.
Normal Flow
4. The Evaluator selects the student work report for the specific
semester.
5. The use case ends successfully.

Alternative Flows N/A

Student is Not in the System

If in step 3 of the normal flow the desired student does not exist in the system,
then
Exceptions 1. The system shall display a message stating that the student does
not exist.
2. The use case ends with a failure condition.

4.2.3 View Employer Evaluation

Actors Evaluator

This use case describes how an Evaluator uses the Co•op Evaluation System to
Description
view an Employer’s submitted evaluation.

Evaluator has received a notification that the Employer has completed their
Trigger
evaluation and desires to look it over.

1. Evaluator has an Internet connection.

2. Evaluator is authenticated and signed into the system.
Pre•conditions
3. Employer has already completed their evaluation of the
student.

Post•conditions Evaluator is viewing the given employer’s evaluation.

1. The Evaluator accesses “Evaluations” from the nav bar.

2. The Evaluator inputs desired search criteria.
3. The Evaluator clicks the “Search” button.
Normal Flow
4. The Evaluator selects the employer evaluation for the specific
semester.
5. The use case ends successfully.

38
 Alternative Flows N/A

Employer is Not in the System

If in step 4 of the normal flow the desired employer does not exist in the
system, then
Exceptions 1. The system shall display a message stating that the employer does
not exist.
2. The use case ends with a failure condition.

4.2.4 Reject Student Work Report

Actors Evaluator

This use case describes how an Evaluator uses the Co•op Evaluation System
Description to reject the student’s work report and have it sent back to the student to redo.

Evaluator is not satisfied with the student’s work report, and there is a desire
Trigger
for the student to re•do their submission.

1. Evaluator has an Internet connection.

Pre•conditions 2. Evaluator is authenticated and signed into the system.
3. Student has already submitted their work report.

Evaluator has changed the status of the work report from Pending Approval to
Post•conditions
Rejected.

1. The Evaluator accesses “Evaluations” from the nav bar.

2. The Evaluator inputs student information.
3. The Evaluator clicks the “Search” button.
Normal Flow 4. The Evaluator selects the desired student.
5. The Evaluator selects “Reject” for the work report for the
specific semester.
6. The use case ends successfully.

Alternative Flows N/A

Student is Not in the System

If in step 3 of the normal flow the desired student does not exist in the system,
then
Exceptions 1. The system shall display a message stating that the student does
not exist.
2. The use case ends with a failure condition.

4.2.5 Accept Student Work Report

Actors Evaluator

39
 This use case describes how an Evaluator uses the Co•op Evaluation System to
Description
accept the student’s work report.

Evaluator is satisfied with the student’s work report after reviewing it, and
Trigger
wants to accept it.

1. Evaluator has an Internet connection.

Pre•conditions 2. Evaluator is authenticated and signed into the system.
3. Student has already submitted their work report.

Evaluator has changed the status of the work report from Pending Approval to
Post•conditions
Approved.

1. The Evaluator accesses “Evaluations” from the nav bar.

2. The Evaluator inputs student information
3. The Evaluator clicks the “Search” button
Normal Flow 4. The Evaluator selects for the desired student.
5. The Evaluator selects “Accept” for the work report for the
specific semester.
6. The use case ends successfully.

Alternative Flows N/A

Student is Not in the System

If in step 3 of the normal flow the desired student does not exist in the system,
then
Exceptions 1. The system shall display a message stating that the student does
not exist.
2. The use case ends with a failure condition.

40
4.3 Employer
4.3.1 Use Case Context

4.3.2 Submit a Co-op Evaluation

Actors Employer

This use case describes how the Employer uses the Co•op Evaluation System
Description
to submit a new Co•op Evaluation.

Employer has a Co•op Student for which an Evaluation needs to be submitted

Trigger
and has received an email telling them the form is available.

1. The Employer has an active Internet connection.

Pre•conditions
2. The Employer has a registered Co•op Student.

Post•conditions The Co•op Evaluation has been submitted for the Co•op Student.

1. The Employer locates the panel for the student in question under
Normal Flow
“Current Co•op Students”.

41
 2. The Employer selects the “Open” link next “Employer Eval” in the
given student co•op panel.
3. The Employer completes the Co•op Evaluation.
4. The Employer submits the Co•op Evaluation.
5. The system displays a message saying that the Co•op
Evaluation has been submitted successfully.
6. The use case ends successfully.

All Required Fields Have Not Been Completed

If in step 5 of the normal flow the Employer submits the Co•op
Evaluation without having completed all required fields, then
Alternative Flows 1. The system shall display an error message, and ask the
Employer to fill out all required fields that have not been
completed.
2. The use case resumes at step 4.

Invalid User
If the use case Authenticate Employer does not complete successfully, then
1. The use case ends with a failure condition.

Error Submitting Work Report

Exceptions If in step 4 of the normal flow there was an error with the submission of the
Co•op Evaluation, then
1. The system shall display an error message, saying there was a
problem with Co•op Evaluation submission.
2. The use case ends with a failure condition.

4.3.2 Save a Co-op Evaluation

Actors Employer

This use case describes how the Employer uses the Co•op Evaluation System
Description
to save a Co•op Evaluation to be completed at a later date.

Employer has a Co•op Student for which a Co•op Evaluation needs to be

Trigger submitted, and they wish to finish the Co•op Evaluation at a later date.

1. The Employer has an active Internet connection.

Pre•conditions
2. The Employer has a registered Co•op Student.

Post•conditions A Co•op Evaluation has been saved for the respective Co•op Student.

1. The Employer locates the panel for the student in question under
“Current Co•op Students”.
Normal Flow
2. The Employer selects the “Open” link next “Employer Eval” in the
given student co•op panel.

42
 3. The Employer partially completes the Co•op Evaluation.
4. The Employer saves the Co•op Evaluation.
5. The system displays a message saying that the Co•op
Evaluation has been saved successfully.
6. The use case ends successfully.

Alternative Flows N/A

Invalid User
If the use case Authenticate Employer does not complete successfully, then
1. The use case ends with a failure condition.

Error Saving Work Report

Exceptions If in step 4 of the normal flow there was an error with the saving of the Co•op
Evaluation, then
1. The system shall display an error message, saying there was a
problem with saving the Co•op Evaluation.
2. The use case ends with a failure condition.

4.3.3 Edit & Submit a Co-op Evaluation

Actors Employer

This use case describes how the Employer uses the Co•op Evaluation System
Description
to update a Co•op Evaluation that was previously saved.

Employer has a co•op for which a Co•op Evaluation has been started, and they
Trigger
wish to finish the Co•op Evaluation and submit it.

1. The Employer has an active Internet connection.

Pre•conditions 2. The Employer has previously registered a co•op.
3. The Employer has a previously saved a Co•op Evaluation.

Post•conditions A Co•op Evaluation has been saved for the respective Co•op Student.

1. The Employer locates the panel for the student in question under
“Current Co•op Students”.
2. The Employer selects the “Open” link next “Employer Eval” in the
given student co•op panel.
Normal Flow 3. The Employer completes the Co•op Evaluation, if unfinished.
4. The Employer submits the Co•op Evaluation.
5. The system displays a message saying that the Co•op
Evaluation has been submitted successfully.
6. The use case ends successfully.

Save Work Report

Alternative Flows If in step 4 of the normal flow the Employer chooses to save the Co•op
Evaluation again instead of submitting it, then

43
 1. The Employer partially completes the Co•op Evaluation.
2. The Employer saves the Co•op Evaluation.
3. The system displays a message saying that the Co•op
Evaluation has been saved successfully.
4. The use case ends successfully.

All Required Fields Have Not Been Completed

If in step 5 of the normal flow the Employer submits the Co•op Evaluation
without having completed all required fields, then
1. The system shall display an error message, and ask the Employer to
fill out all required fields that were not completed.
2. The use case resumes at step 4.

Invalid User
If the use case Authenticate Employer does not complete successfully, then
1. The use case ends with a failure condition.

Error Submitting Co•op Evaluation

Exceptions If in step 4 of the normal flow there was an error with the submitting of the
Co•op Evaluation, then
1. The system shall display an error message, saying there was a
problem with submitting the Co•op Evaluation.
2. The use case ends with a failure condition.

4.3.4 View a Submitted Co-op Evaluation

Actors Employer

This use case describes how the Employer uses the Co•op Evaluation System
Description
to view a Co•op Evaluation that was previously submitted.

Employer has a Co•op Evaluation that has been submitted, and they want to
Trigger
view.

1. The Employer has an active Internet connection.

Pre•conditions 2. The Employer has a previously submitted Co•op Evaluation for a
given student.

Post•conditions The desired Co•op Evaluation is displayed to the Employer.

1. The Employer locates the panel for the student in question under
“Current Co•op Students”.
2. The Employer selects the “Open” link next “Employer Eval” in the
Normal Flow given student co•op panel.
3. The Employer selects a previously submitted Co•op Evaluation for
the student.
4. The system displays the Co•op Evaluation to the Employer.

44
 5. The use case ends successfully.

Alternative Flows N/A

Invalid User
If the use case Authenticate Employer does not complete successfully, then
1. The use case ends with a failure condition.

Error Displaying Work Report

Exceptions If in step 4 of the normal flow there was an error displaying the Co•op
Evaluation, then
1. The system shall display an error message, saying there was a
problem with displaying the Co•op Evaluation.
2. The use case ends with a failure condition.

4.3.5 Authenticate Employer

This use case is meant to demonstrate what will happen if the employers cannot authenticate through
Simplicity. It may or may not be the case in the final system, but it is important to plan for possibility at this
stage in the process.
Actors Employer

This use case describes how the Employer authenticates with the Co•op
Description
Evaluation System.

Trigger Employer has a action to complete on the Co•op Evaluation System.

1. The Employer has an active Internet connection.

Pre•conditions
2. The Employer has hired at least one student to work a co•op.

The Employer is successfully logged into the Co•op Evaluation System.

Post•conditions

1. The Employer opens the website on a supported browser.

2. The Employer selects “Employer Login”.
3. The Employer types in their user name.
4. The Employer types in their password.
Normal Flow
5. The Employer submits their credentials.
6. The system authenticates the user.
7. The system displays the Employer’s homepage.
8. The use case ends successfully.

Alternative Flows N/A

Invalid User
Exceptions If in step 7 of the normal flow does not complete successfully, then
1. The use case ends with a failure condition.

45
4.4 Student
4.4.1 Use Case Context

4.4.2 Submit Work Report

Actors Student

This use case describes how the Student uses the Co•op Evaluation System to
Description
submit a new Work Report.

Trigger Student has a co•op for which a Work Report needs to be submitted.

1. The Student has an active Internet connection.

Pre•conditions
2. The Student has previously registered a co•op.

Post•conditions A Work Report has been submitted for the respective Student’s co•op.

Normal Flow 1. The Student locates the panel for the co•op in question.

46
 2. The Student selects the “Open” link next “Work Report” in the
given co•op panel.
3. The Student completes the Work Report.
4. The Student submits the Work Report.
5. The system displays a message saying that the Work Report has
been submitted successfully.
6. The use case ends successfully.

All Required Fields Have Not Been Completed

If in step 4 of the normal flow the Student submits the Work Report without
having completed all required fields, then
Alternative Flows 1. The system shall display an error message, and ask the
Student to fill out all required fields that have not been
completed.
2. The use case resumes at step 3.

Error Submitting Work Report

If in step 4 of the normal flow there was an error with the submission of the
Exceptions Work Report, then
1. The system shall display an error message, saying there was a
problem with Work Report submission.
2. The use case ends with a failure condition.

4.4.3 Save Work Report

Actors Student

This use case describes how the Student uses the Co•op Evaluation System to
Description
save a Work Report to be completed at a later date.

Student has a co•op for which a Work Report needs to be submitted, and they
Trigger
wish to finish the Work Report at a later date.

1. The Student has an active Internet connection.

Pre•conditions
2. The Student has previously registered a co•op.

Post•conditions A Work Report has been saved for the respective Student’s co•op.

1. The Student locates the panel for the co•op in question.

2. The Student selects the “Open” link next “Work Report” in the
given co•op panel.
3. The Student partially completes the Work Report.
Normal Flow 4. The Student saves the Work Report.
5. The system displays a message saying that the Work Report has
been saved successfully.
6. The use case ends successfully.

Alternative Flows N/A

47
 Error Saving Work Report
If in step 4 of the normal flow there was an error with the saving of the Work
Exceptions Report, then
1. The system shall display an error message, saying there was a
problem with saving the Work Report.
2. The use case ends with a failure condition.

4.4.4 Update Work Report

Actors Student

This use case describes how the Student uses the Co•op Evaluation System to
Description
update a Work Report that was previously saved.

Student has a co•op for which a Work Report has been started, and they wish
Trigger
to finish the Work Report and submit it.

1. The Student has an active Internet connection.

Pre•conditions 2. The Student has previously registered a co•op.
3. The Student has a previously saved a Work Report.

Post•conditions A Work Report has been saved for the respective Student’s co•op.

1. The Student locates the panel for the co•op in question.

2. The Student selects the “Save MM/DD/YYYY” link next “Work
Report” in the given co•op panel.
3. The Student completes the Work Report.
Normal Flow 4. The Student submits the Work Report.
5. The system displays a message saying that the Work Report has
been submitted successfully.
6. The use case ends successfully.

Save Work Report

If in step 3 of the normal flow the Student chooses to save the Work Report
again instead of submitting it, then
1. The Student partially completes the Work Report.
2. The Student saves the work report.
3. The system displays a message saying that the Work Report has
been saved successfully.
Alternative Flows 4. The use case ends successfully.

All Required Fields Have Not Been Completed

If in step 4 of the normal flow the Student submits the Work Report without
having completed all required fields, then
1. The system shall display an error message, and ask the Student to fill
out all required fields that have not been completed.

48
 2. The use case resumes at step 3.

Error Submitting Work Report

If in step 6 of the normal flow there was an error with the submitting of the
Exceptions Work Report, then
1. The system shall display an error message, saying there was a
problem with submitting the Work Report.
2. The use case ends with a failure condition.

4.4.5 View Work Report

Actors Student

This use case describes how the Student uses the Co•op Evaluation System to
Description
view a Work Report that was previously submitted.

Student has a Work Report that has been submitted, and they want to view.
Trigger

1. The Student has an active Internet connection.

Pre•conditions
2. The Student has previously submitted a Work Report.

Post•conditions The desired Work Report is displayed to the Student.

1. The Student locates the panel for the co•op in question.

2. The Student selects the “Submitted MM/DD/YYYY” link next
Normal Flow “Work Report” in the given co•op panel.
3. The system displays the Work Report to the Student.
4. The use case ends successfully.

Alternative Flows N/A

Error Displaying Work Report

If in step 3 of the normal flow there was an error displaying the Work Report,
Exceptions then
1. The system shall display an error message, saying there was a
problem with displaying the Work Report.
2. The use case ends with a failure condition.

4.4.6 View Employer Evaluation

Actors Student

This use case describes how the Student uses the Co•op Evaluation System
Description to view an Employer Evaluation that was previously submitted.

49
 Student has an Employer Evaluation that has been submitted, and they want
Trigger
to view.

1. The Student has an active Internet connection.

Pre•conditions
2. The Student has a previously submitted Employer Evaluation.

Post•conditions The desired Employer Evaluation is displayed to the Student.

1. The Student locates the panel for the co•op in question.

2. The Student selects the “Submitted MM/DD/YYYY” link next
Normal Flow “Employer Eval” in the given co•op panel.
3. The system displays the Employer Evaluation to the Student.
4. The use case ends successfully.

Alternative Flows N/A

Error Displaying Work Report

If in step 3 of the normal flow there was an error displaying the Employer
Exceptions Evaluation, then
1. The system shall display an error message, saying there was a
problem with displaying the Employer Evaluation.
2. The use case ends with a failure condition.

5 External Interface Requirements

5.1 User Interfaces
The system’s user interfaces will need to look and feel like they belong to RIT. This means that they should
have a similar layout, color scheme, and other visual aspects as other school sites. However, the system
should also utilize modern web design standards of layout and interaction.

Since the system is a web application, the user interface must be consistent across all modern desktop
browsers, specifically Chrome, Firefox, Safari, and Internet Explorer 9+. Additionally, the system will take
advantage of Twitter Bootstrap to create a responsive user interface, thus allowing users to access the
system on a variety of devices. This in•turn requires that the system be accessible and usable on mobile
platforms (e.g. smart phones and tablets). If a feature is not accessible from a mobile device the user
interface must display an error message that clearly explains what cannot be done and why.

5.2 Software Interfaces

The product will interact with Shibboleth in order to authenticate users. Our system will take in log•in
credentials from the user, and send those credentials to Shibboleth to verify. Shibboleth will then return
the type of user, which will be used by our program to give the user specific permissions.

50
5.3 Communications Interfaces
Submission of form data must persist to the database. The website must inform the the user that their data
was not properly stored in the database, and allow for resubmission. Hibernate and JPA will be used for
database access from our system.

The system must interface with ITS mail servers in order to send out notification emails to students and
employers.

The system will communicate over the standard protocols of HTTP and TCP/IDP. For accessing secure
sections of the system, HTTPS will be used. Shibboleth will be used to authenticate users.

51
6 Non-functional Requirements
6.1 Performance Requirements
Number Priority Requirement

PR•01 High The system shall respond to requests within 3 seconds.

PR•02 Medium The system shall be able to handle up to 6,000 users at a time.

The system shall load all web pages in less than 30 seconds, with the
PR•03 Medium
exception of reports.

6.2 Security Requirements

Number Priority Requirement

The system shall require users to authenticate against Shibboleth with

SE•01 High their RIT user IDs in order to access the system.

The system shall not allow employers to view evaluations for a student
SE•02 High
that is not currently working for him/her.

6.3 Safety Requirements

Number Priority Requirement

The system shall ensure integrity of its data upon database failure.
SA•01 High

SA•02 High Inputted user data shall not be lost.

6.4 Usability Requirements

Number Priority Requirement

The system shall be usable from all major up•to•date web browsers
UR•01 Medium (latest version of Chrome, latest version of Firefox, latest version of
Safari, and IE 9+).

UR•02 Low The system shall be accessible from mobile devices.

6.5 Availability Requirements

Number Priority Requirement

AR•01 High The system shall be available 95% of the time.

52
 The system shall not time out during the evaluation submission more
AR•02 High
than 5% of the time.

6.6 Modifiability Requirements

Number Priority Requirement

MR•01 High The system shall be modifiable for future updates.

MR•02 High The system shall allow new colleges to be added to the system.

The system shall allow new departments to be added to the system.

MR•03 High

6.7 Documentation Requirements

Number Priority Requirement

The system shall include a test plan, including up to 95% code

DR•01 Medium
coverage.

The system shall include a user manual that describes to users how to
DR•02 High
use the system.

6.8 Environment Requirements

Number Priority Requirement

EN•01 High The system shall run on the ITS•provided VM at final release.

53
Appendix A: Glossary
Term Definition

CES Co•op Evaluation System

Evaluation A form that is currently being filled out by a student or by an employer

EWA Enterprise Web Applications, a division of ITS

Form A template that is used to generate an evaluation for a department

ITS Information and Technology Services

An email message that will be generated and sent to students and/or

Notification
employees.

OCSCE Office of Cooperative Education and Career Services

Report An aggregation of submissions used to display statistics

RIT Rochester Institute of Technology

SRS Software Requirements Specification

Submission A form that has been completed and submitted to the evaluator

Status The current state of the evaluation

54