Running head: Lab 2 – REMSY Product Specification
Lab 2 – REMSY Product Description
Team Blue
Eric Diep
CS 411W
Janet Brunelle & Hill Price
April 24, 2014
Version 3
1
Lab 2 – REMSY Production Specification
2
Table of Contents
1. INTRODUCTION .......................................................................................................................... 3
1.1 Purpose........................................................................................................................................ 3
1.2 Scope ........................................................................................................................................... 4
1.3 Definitions, Acronyms, and Abbreviations ................................................................................ 5
1.4 References ................................................................................................................................... 7
1.5 Overview ..................................................................................................................................... 8
2. GENERAL DESCRIPTION ........................................................................................................... 8
2.1 Prototype Architecture Description ............................................................................................ 8
2.2 Prototype Functional Description ............................................................................................. 10
2.3 External Interfaces .................................................................................................................... 11
2.3.1 Hardware Interfaces ........................................................................................................... 11
2.3.2 Software Interfaces ............................................................................................................ 11
2.3.3 User Interfaces ................................................................................................................... 11
2.3.4 Communications Protocols and Interfaces......................................................................... 14
3.3 Assumptions and Constraints .................................................................................................... 16
List of Figures
Figure 1. Prototype Major Functional Component Diagram................................................................ 9
Figure 2. Student Sitemap .................................................................................................................. 12
Figure 3. Tutor Sitemap ...................................................................................................................... 13
Figure 4. Administrator Sitemap ........................................................................................................ 14
List of Tables
Table 1. Effects of Assumptions, Dependencies, and Constraints on Requirements ......................... 16
Lab 2 – REMSY Production Specification
3
1. INTRODUCTION
According to the Federal Emergency Management Agency, resource management is a
critical area of how day-to-day business operation is handled in an organization (Federal
Emergency Management Agency, 2014). Adequate resource management will allow for tasks
to be done with ease. Without a resource management system, the operation of an
organization will be constrained thus affecting the success of the organization. A system that
is flexible and scalable is needed to allow for accommodating the expansion of an
organization beyond their current boundaries, all the while maintaining data integrity from
the various locations. Additionally, collecting data is vital to the improvement of an
organization.
1.1 Purpose
REsource Management SYstem (REMSY) is an application that will aid in resource
management of the day-to-day business operation of the tutoring organization at Old
Dominion University (ODU). REMSY will aid in the scheduling of tutoring and tracking
usage of tutoring resources. It will be accessible by students, tutors, and administrators with
accounts. With an account students will be able to search for tutoring sessions, signup for
tutoring sessions, and log-in and log-out of tutoring sessions. Tutors will be able to manage
scheduled tutoring sessions, create tutoring sessions, and send notifications. Administrators
will have the capability to modify courses available at a tutoring center, and manage
accounts.
Notifications will be delivered via e-mail, SMS, or pushed to the mobile home screen.
REMSY will be accessible through a web browser on a desktop or through an application on
Lab 2 – REMSY Production Specification
4
a mobile device. REMSY is a flexible and scalable system that will accommodate the various
located tutoring branches at ODU. Administrators will be able to generate reports to analyze
the use of resources for each tutoring organizations. To further streamline the process of login, REMSY will attain necessary log-in information from the user’s identification card via a
card reader device. Overall, REMSY will allow tutors to be mobile and for freelance tutoring
services to be offered.
1.2 Scope
The REMSY prototype will showcase the different capabilities that encompass the
management of a tutoring organization, searching for a tutoring sessions, scheduling a
tutoring session, and the completion of a tutoring session. The REMSY prototype
environment will include a web server, an optimized database, the application, and a test
harness to aid in creating simulated data and possible scenarios encountered during the
process of scheduling a tutoring session. The prototype will ensure that both the web and
mobile application are compliant with the Family Educational Rights and Privacy Act
(FERPA) and Section 508.
To aid in the demonstration of e-mail notifications, the Computer Science mail server
will be used. Also, since there is a limitation to accessing ODU’s existing resources, a
mockup of the Banner system will be created and authentication will be simulated by using a
Lightweight Directory Access Protocol (LDAP) domain. Most importantly, to ensure the
integrity of data, various located tutoring programs will be guaranteed to have access to a
centralized REMSY database containing all necessary information.
Since each tutoring program has different operational requirements, REMSY will be
customizable based on the program’s template. A tracking functionality and a report
Lab 2 – REMSY Production Specification
5
generation functionality will be implemented in REMSY, to aid in tracking necessary
information electronically, rather than keeping paper records. The user interface (UI) of the
web application and mobile application will be developed in parallel to ensure functionality
and aesthetics are similar.
1.3 Definitions, Acronyms, and Abbreviations
508 Compliance: Amendment of the Rehabilitation Act which requires Federal agencies to
make electronic and information technology accessible to people with and without
disabilities.
Administrator: The manager of a software tier. As a User, has all rights and privileges
concerning a program and how it operates.
Apache: Open source web server providing a full range of web server features distributed by
the Apache Software Foundation.
Banner: Centralized academic and administrative records system.
Blue team: The creators of REMSY. Zachary Regelski, Seth Hohensee, Denis Mileyko, Eric
Diep, Corey Campbell, and Matthew Letchworth
CS: Computer Science
DFWI: D grad, failure, withdraw, or incomplete in a given course
FERPA: Family Educational Rights and Privacy Act.
Human Interface Device (HID): A human interface device or HID is a type of computer
device that interacts with, and most often takes input from, humans and may deliver
output to humans. The term “HID” most commonly refers to the USB-HID
specification.
Lab 2 – REMSY Production Specification
6
Hypertext Transfer Protocol Secure (HTTPS): a communication protocol for secure
communication over a computer network.
Java: a computer programming language that is concurrent, class-based, object-oriented, and
specifically designed to have as few implementation dependencies as possible
Kerberos: computer network authentication protocol which works on the basis of ‘tickets’ to
allow nodes communicating over a non-secure network to prove their identity to one
another in a secure manner
Lightweight Directory Access Protocol (LDAP): an application protocol used for accessing
and maintaining distributed directory information services
MySQL: Open Source SQL database management system by Oracle Corporation.
Objective-C: a general-purpose, object-oriented programming language that adds Smalltalkstyle messaging to the C programming language
ODU: Old Dominion University.
PHP: General-purpose scripting language that is especially suited to web development.
Remote Desktop (RDP): an operating system feature or software that allows for a personal
computer to be access remotely on a separate machine.
REMSY: application to aid in scheduling and collecting information on tutoring at Old
Dominion University developed by the Spring 2014 CS411 Team Blue.
Secure Shell (SSH): a cryptographic network protocol for securing a data communication
line.
Shibboleth: Single sign-on process that authenticates and authorizes a user, and allows a user
to access secure sites by using university computing account username and password.
Lab 2 – REMSY Production Specification
Simple Mail Transfer Protocol (SMTP): an Internet standard for electronic mail
transmission.
SMS: Short Message Service. Another name for Text Messages.
Standard Query Language (SQL): a special-purpose programming language designed for
managing data held in a relational database management system
Student: A student who is not currently a Tutor. As a type of user, Students are seeking to
either find tutoring, or apply to be a tutor.
Transmission Control Protocol (TCP): Transport layer protocol used for reliable
communication between devices across a network part of TCP/IP
Tutor: A student who has applied to the institution and was granted tutor status. They teach
students for classes they need help in. As a type of user, can sign up to teach classes
and manage appointments.
TutorTrac: Completely web-based management software for learning, writing, reading,
tutoring departments, and academic skills centers developed by Redrock Software.
UI: User Interface.
UIN: University Identification Number.
1.4 References
CS 410 Documents (as applicable)
Diep, E. (2014). Lab 1 – REMSY Product Description. Norfolk, VA.
Federal Emergency Management Agency. 2014, February 11. Resource Management.
Retrieved from http://www.fema.gov/resource-management
Jimenez, M. (2013, October 9). Personal Interview.
7
Lab 2 – REMSY Production Specification
8
NITAAC. (n.d.). What is Section 508 Compliance?. Retrieved from
https://nitaac.nih.gov/nitaac/node/2281
U.S. Department of Education. (n.d.). Family Educational Rights and Privacy Act (FERPA).
Retrieved from http://www.ed.gov/policy/gen/guid/fpco/ferpa/index.html
1.5 Overview
This product specification provides the hardware and software configuration, external
interfaces, capabilities, and features of the REMSY prototype. The information provided in
the remaining sections of this document includes a detailed description of the hardware,
software, and external interface architecture of the REMSY prototype; the key features of the
prototype; the parameters that will be used to control, manage, or establish that feature; and
the performance characteristics of that feature in terms of outputs, displays, and user
interaction.
2. GENERAL DESCRIPTION
REMSY will have access to a virtual machine on the ODU Computer Science (CS)
Department’s network to facilitate testing. All necessary hardware and software will be
provided by the CS Department at ODU to aid in the development of the REMSY prototype.
A card-reader has been provided by mentor Jeffrey Turner.
2.1 Prototype Architecture Description
Figure 1 illustrates the prototype that will be developed for REMSY. The REMSY
prototype will be comprised of a web and mobile application, a REMSY database server,
REMSY web server, a mail server from the CS department at ODU, and a mocked Banner
Lab 2 – REMSY Production Specification
9
and Shibboleth model. The use of the CS mail server and a mocked Banner and Shibboleth
models will be used to aid in the demonstration of REMSY, because of restrictions enforced
by ODU on the access to existing databases. The CS mail server will be used to provide email notifications regarding a tutoring session. The Banner and Shibboleth models will
respectively provide a means for simulation of accessing the educational record of an
individual and authenticating a user to access REMSY.
Figure 1. Prototype Major Functional Component Diagram
The REMSY database server will be the internal interface that provides a means of
retrieving necessary information displayed to the user. Information stored in the database will
be courses, accounts, tutors, students, administrators, and schedules of tutoring sessions. The
Lab 2 – REMSY Production Specification
10
REMSY web server will provide an external interface between the web application, which
will be hosted on the REMSY web server, and the user. The mobile application will be
provided as an external interface for users to access the REMSY application on a mobile
device.
2.2 Prototype Functional Description
The functional part of the REMSY prototype will be comprised of a web application, a
mobile application, a test harness, report generation module, resource tracking module, and a
card-reader module. The web application will provide the user with the means to interact
with the REMSY system from an internet browser. The mobile application will provide a
means for the user to perform similar tasks made available through the web application and
receive notifications via SMS or pushed messages to the mobile’s home-screen. Both the web
and mobile application will demonstrate the capability for users to log-in and log-out,
schedule and manage tutoring appointments, and accounts.
A test harness will be developed to create simulated data and possible scenarios
encountered during the day-to-day business operation of a tutoring organization. With the
test harness will be the report generation module and resource tracking module. The report
generation module will run against the REMSY database server to generate reports
containing necessary levels of details. The resource tracking module will also run against the
REMSY database to track resource usage and student turn-away. A card-reader module will
be implemented to integrate the use of a third-party, card-reader device. The card-reader will
be used to pull necessary information from an identification card to streamline the process of
logging-in for a tutoring session.
Lab 2 – REMSY Production Specification
11
2.3External Interfaces
External interfaces will identify the physical and logical interface that will be between the
user and REMSY. They will include the webpages that makes up the REMSY web
application, the user interfaces that makes up the REMSY mobile application, a standard
Personal Computer (PC), a mobile device, a card-reader, and servers. The standard PC and
mobile device will display the REMSY pages. The card-reader will be used to swipe
identification to allow for a simple log-in.
2.3.1 Hardware Interfaces
For the REMSY prototype a card-reader interface will be in place which is a Human
Interface Device (HID). HID is a computer device that uses a Universal Serial Bus (USB)
connector to connect to a personal computer. Data will be exchanged between the REMSY
database server and a HID card-reader. Data exchanged on this interface includes the user’s
log-in information, such as their username and University Identification Number (UIN).
2.3.2 Software Interfaces
For REMSY to send notifications through e-mail, REMSY will interface with the CS
mail servers. To authenticate users, REMSY will interface with the model Shibboleth server.
The modeled Shibboleth server will host LDAP, which is used for authentication. To display
student records, REMSY will interface with the model Banner server.
2.3.3 User Interfaces
The user interfaces will encompass the web application and mobile application. Both will
be developed in parallel to have similar aesthetics. The REMSY application will be
Lab 2 – REMSY Production Specification
12
accessible by four types of users, generic users, student, tutor, and administrator. All user
interfaces for the four types will be similar, but access to pages will be limited according to
the user type. Figure 2 illustrates the interface that will be seen if the user is a student.
Figure 2. Student Sitemap
Figure 3 illustrate the user interface for a tutor. The interface for the student and tutor is
nearly identical. The difference between the two interface is in the ‘My Classes’ tab. The
student will be able to view past and present scheduled appointments, while the tutor has the
capability to cancel or rescheduled appointments.
(This space intentionally left blank)
Lab 2 – REMSY Production Specification
Figure 3. Tutor Sitemap
Figure 4 illustrates the user interfaces for an administrator. The administrator interface will
have more capabilities than the student and tutor interface. A key feature of the administrator
interface is the capability to generate reports.
(This space intentionally left blank)
13
Lab 2 – REMSY Production Specification
14
Figure 4. Administrator Sitemap
The mechanisms for users to interact with the REMSY application would be categorized
by either a desktop or a mobile device. The following mechanisms will be needed to access
the REMSY application on a desktop, a color display, a keyboard for data entry, and a
mouse. To access the REMSY application on a mobile device, the following mechanism will
be needed, a mobile device with a color display, QWERTY keyboard for data entry, and a
touchscreen display.
2.3.4 Communications Protocols and Interfaces
Communication between the REMSY application and servers will be handled by
Transmission Control Protocol/Internet Protocol (TCP/IP). In the case of mobile devices
being used to access the REMSY application, the wireless standard protocol will be used,
IEEE 802.11. For a secure connection to be established between the servers and access
Lab 2 – REMSY Production Specification
15
device, Hypertext Transfer Protocol Secure (HTTPS) will be used. The card-reader will be
connected to the host device through a Universal Serial Bus (USB). To ensure authentication
to accessing the REMSY application Lightweight Directory Access Protocol (LDAP) will be
used to administer authentication. To allow for sending of notifications, Simple Mail
Transfer Protocol (SMTP) will be used for e-mail and Short Message Service will be used for
text messages.
(This space intentionally left blank)
Lab 2 – REMSY Production Specification
16
3.3 Assumptions and Constraints
Table 1 lists all possible assumptions, constraints, and dependencies that would be
encountered during the development of REMSY. Encountering these possible assumptions,
constraints, and dependencies will have varying effect on the requirements. Alternatives to
the conditions have been listed in the column labeled “Effect on Requirements.”
Condition
A HID card-reader is
available for the prototype
A mobile device is available
for the prototype
Integration of REMSY with
legacy software
Use of University resources
is available for the prototype
User data from the
University will be available
to populate the Banner model
database
Only valid data entries will
be provided
Type
Dependency
Constraint
Effect on Requirements
The HID reader function must be simulated
if one is not available
The mobile application must be simulated if
one is not available
Modeled software will need to be created
Constraint
Resources will need to be modeled
Constraint
Simulated data will need to be created
Dependency
Assumption
Allow for minimal error checking for
purposes to developing and demonstrating
the prototype
Allow for minimal errors for purposes to
developing and demonstrating the prototype
Only valid data regarding
Assumption
courses, users, and tutoring
sessions are stored in
databases
All necessary data will be
Assumption Allows for development and demonstrating
simulated for the prototype
the prototype
All protocols of
Assumption Allow for all forms of required
communication for sending
communication to be developed and
notification will be available
demonstrated for the prototype
for the prototype
REMSY will be accessible
Assumption Allow for all browsers to be used for
on all popular browser
demonstrating the prototype
Reporting module and
Assumption Allow for generation of reports
Tracking module will be
available for prototype
Table 1. Effects of Assumptions, Dependencies, and Constraints on Requirements