Lab II - Product Specification Outline
CS 411W Lab II
Prototype Product Specification
For
REMSY
Prepared by: Corey Campbell, Denis Mileyko, Eric Diep,
Matthew Letcworth, Seth Hohensee, Zachary Regelski,
CS411 Blue Team
Date: 02/03/14
Table of Contents
Example:
1
Introduction ................................................................................................................. 1
1.1
Purpose................................................................................................................ 1
1.2
Scope ................................................................................................................... 1
1.3
Definitions, Acronyms, and Abbreviations ........................................................ 2
1.4
References ........................................................................................................... 4
1.5
Overview ............................................................................................................. 5
2 General Description .................................................................................................... 5
2.1
Prototype Architecture Description .................................................................... 5
2.2
Prototype Functional Description ....................................................................... 5
2.3
External Interfaces .............................................................................................. 6
3 Specific Requirements ................................................................................................ 6
3.1
Functional Requirements .................................................................................... 7
3.2
Performance Requirements ................................................................................. 8
3.3
Assumptions and Constraints .............................................................................. 9
3.4
Non-Functional Requirements .......................................................................... 10
Appendix ........................................................................................................................... 11
List of Figures
Example:
Figure 1 Product xyz Prototype Architecture Diagram .....Error! Bookmark not defined.
Figure 2 Product xyz Command and Propulsion Diagram Error! Bookmark not defined.
Figure 3 Type A USB Connector.......................................Error! Bookmark not defined.
Figure 4 User Command Entry and Status Display Format ............................................... 7
List of Tables
Example:
Table 1 Steering Control Functional Requirements............................................................ 8
Table 2 Effects of Assumptions, Dependencies, and Constraints on Requirements ........ 10
ii
1 Introduction
REMSY is a web and mobile application designed to facilitate the management of
tutoring resources at Old Dominion University.
1.1 Purpose









REMSY
Allow scheduling of tutoring and track use of resources
Students and tutors via mobile/web, professors, and tutoring program
administrators via web
Allow students to sign up for/withdraw from tutoring sessions, receive
notifications of any schedule changes, and request tutoring that is not offered
Allow administrators to advertise available tutoring and generate reports
regarding attendance
Allow tutors to check sign-ups, cancel sessions, and be notified when enrollment
changes.
Allow professors to check which of their students have attended tutoring for their
class.
Allow verification via mobile app and card swiping.
Allow students to organize volunteer tutoring.
1.2 Scope









Report generation to enhance understanding of tutoring benefits and needs
Allow for separate programs within one system, data can be shared
Separate programs can customize their tutoring requirements/employee
permissions
Reduce manual data entry
Reduce dependence on fixed lab locations by allowing mobile sign-up and
verification
FERPA Compliance
Test harness designed to allow for rapid alterations of database for test cases
Simulated connections to university database (Banner) and authentication
(Shibboleth)
Connection to CS mail server (simulating connection to ODU mail server)
<Note: This should be an encapsulation of the Prototype Description from Lab I>
1
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: a D grad, failure, withdraw, or incomplete in a given course
FERPA: Family Educational Rights and Privacy Act.
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.
Hypertext Transfer Protocol Secure: a communication protocol for secure
communication over a computer network.
HTTPS: Hypertext Transfer Protocol Secure
2
Java: a computer programming language that is concurrent, class-based, objectoriented, and specifically designed to have as few implementation
dependencies as possible
LDAP: Lightweight Directory Access Protocol
Lightweight Directory Access Protocol: 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
Smalltalk-style messaging to the C programming language
ODU: Old Dominion University.
PHP: General-purpose scripting language that is especially suited to web
development.
RDP: Remote Desktop
Remote Desktop: an operating system feature or software that allows for a personal
computer to be access remotely on a separate machine.
REMSY: Resource Management System to aid in scheduling and collecting
information on tutoring at Old Dominion University developed by the Spring
2014 CS411 Team Blue.
Secure Shell: 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.
3
Simple Mail Transfer Protocol: an Internet standard for electronic mail
transmission.
SMTP: Simple Mail Transfer Protocol
SSH: Secure Shell
SMS: Short Message Service. Another name for Text Messages.
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.
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)
Lab I
FERPA - http://www.ed.gov/policy/gen/guid/fpco/ferpa/index.html
ODU Tutoring - http://uc.odu.edu/taa/
4
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
2.1 Prototype Architecture Description
REMSY is comprised of the following major components:






Web and mobile application: means of accessing the REMSY application by
either a desktop or mobile application
Test harness: provides the mechanism by which REMSY is able to simulate the
creating of an account, scheduling and managing appointments, general
procedures while attending a tutoring session, and generation of statistical reports
REMSY database: provides an internal interface for available courses, necessary
tutors, and schedules
Modeled Shibboleth and Banner: provides a means for simulating authentication
and gathering student details such as classes
CS Mail Server: provides the e-mail notification service for alerting of upcoming
appointments or exceeding allotted time limit
REMSY Web Server: provides the external interface for logging in and out of
accounts, scheduling and managing appointments, and managing accounts
2.2 Prototype Functional Description
The major functional components of the REMSY prototype include the following:




Web Portal: this function provides users with the means to interact with the
REMSY system from an internet browser
Mobile Application: this function provides a means for students and tutors to
perform common tasks associated with the REMSY system and receive
notifications
Test harness: used to create simulated data and create possible scenarios
Reporting module: this function generates statistics and filtering functionality
based on data collected on REMSY users
5


Resource tracking module: used for tracking resource usage and turn-away
Card-reader integration: pull necessary information from a card to streamline
process of logging-in
2.3 External Interfaces
2.3.1 Hardware Interfaces

HID Card reader: this will be a USB interface which establishes data exchange
between a personal computer and identifier card. Information such as student ID
and name will be stored.
2.3.2 Software Interfaces



CS mail server: this is a university asset that will assist in e-mailing notifications
regarding scheduled appointments or missed appointments, and exceeded time
limit appointments
Model Banner
Model Shibboleth
2.3.3 User Interfaces



Desktop: keyboard for data entry, mouse for maneuvering, flat-screen color
display
Mobile Devices: qwerty keyboard, finger for maneuvering
Web application: used by the three types of users (student, tutor, and
administrator). Interfaces will be differentiated according to user type
2.3.4 Communications Protocols and Interfaces







Transmission Control Protocol/Internet Protocol (TCP/IP)
IEEE 802.11
Universal Serial Bus (USB)
Lightweight Directory Access Protocol (LDAP)
Hypertext Transfer Protocol Secure (HTTPS)
Secure Shell (SSH)
Remote Desktop (RDP)
3 Specific Requirements

This section contains the detailed requirements. Each requirement should be a
single statement that describes a key attribute of the product.

Requirements under each subsection should be grouped into functional areas. A
functional area is a grouping of related requirements that provide related
6
functionality. For example, in a word processor, the requirements for the grammar
checker may be grouped under the functional area grammar checker.
3.1 Functional Requirements



State each functional requirement in a concise and complete format.
Illustrations, such as display formats, data entry fields, etc. can be used to expand
concepts or requirements.
Action/response matrices are useful tools for articulating sequences of events in a
functional context
3.1.1 Functional Requirement 1
Example: 3.1.1 User Command Entry and Status Display. This function shall provide
entry of user commands and display of status from the prototype system. The following
functional requirements shall be provided:
1. An Operator Input Display which provides data entry fields for the following in
the format illustrated in Figure 4:
a. Speed
b. Steering direction
2. A Status Display which provides the following as illustrated in Figure 4:
a. Bluetooth communication status (enabled/disabled)
b. Ordered Speed
c. Ordered Steer Direction
d. Motion Status (moving, stopped)
Figure 1. User Command Entry and Status Display Format.
CONSOLE MODE SELECT
COMMAND
SADM
TRACK SUP
INFORMATION
MANAGEMENT
AIR D/T
SURF D/T
SONAR
COMMS CONTROL
WEAPONS CONTROL
RESOURCE
MANAGEMENT
HELO CONTROL
PREPROGRAMMED:
1 TRACK SUP/AIR
2 WCO/FCS
USER-DEFINED MODE
COMBINATIONS
7
3.1.2 Functional Requirement 2
Example: 3.1.x Exhaust Distribution Simulation: This function provides for simulation
of distributing exhaust gasses from the propulsion system. The following functional
capabilities shall be provided/simulated:
1. Calculation of amount of exhaust gas being produced. This calculation will be
performed based on the ordered speed and motion status using the following
equation: Exhaust Volume=(Ordered Speed * PI)/some-constant
2. Exhaust gas display showing the calculated Exhaust Volume distributed in a
cylinder measuring 5 inches in diameter by 36 inches in length and discharging at
a rate of 25% of the calculated Exhaust Volume per second.
Example: 3.1.x Steering Control: This function accepts steering commands issued from
the Cockpit and controls the servo that drives the steering mechanism. The function
manages the action/response sequences presented in Table 1.
Table 1. Steering Control Functional Requirements.
Command/Condition
Steering Control Message Received
Direction and amount of steer
established
Required servo movement
calculated
Response
Decode message to determine direction and amount
to steer
Determine how much to move the steering servo to
meet steering order requirement
Move servo required amount
3.2 Performance Requirements
8

Describe any performance requirements in this section. Performance requirements
should possess numeric boundaries, etc. They should be stated in measurable
terms. Each requirement should be stated as an individual statement with a unique
identifier.
3.2.1 Performance Requirement 1
Example: 3.2.1 Rubber band Propulsion System (RPS): The RPS shall meet the following
performance requirements:
1. Capable of being wound 365 turns
2. Capable of surviving 500 winding events without breaking
Example: 3.2.2 Bluetooth Communications> the Bluetooth Communications link shall
meet the following performance requirements:
1. maintain connectivity from 5 to 25 feet in an unobstructed line-of-site
environment
2. support information transfer at a rate of 5 messages/second
Example: 3.2.3 Steering Control: the prototype shall be able to control steering in
accordance with the following:
1. steering angles range from 0 (centerline) to 45 degrees left or right of
centerline
2. movement rate of the steering mechanism cannot exceed 15 degrees per
second while the prototype is in motion.
3.2.2 Performance Requirement 2
3.3 Assumptions and Constraints

Describe any assumptions that have been made and that would affect the
requirements if they turned out to be false. An example assumption is that a
specific piece of hardware will be available before the product goes into testing.

Describe any dependencies or constraints that exist. A dependency may be that a
specific subsystem, hardware, or software component exists. A constraint may be
that data transfer that would normally be performed via a secure network is
conducted by simulating the exchange for purposes of demonstrating the
prototype.
9
Table 2. Effects of Assumptions, Dependencies, and Constraints on Requirements.
Condition
Vehicles cannot occupy
more than one space
Only valid data entries
will be provided
A RFID reader is
available for the
prototype
Type
Constraint
Effect on Requirements
Bounds the problem of matching vehicle
entries and exits to available spaces
Assumption Allows for minimal error checking for the
purposes to developing and demonstrating the
prototype
Dependency The RFID reader function must be simulated if
one is not available
3.4 Non-Functional Requirements

Describe the non-functional requirements that characterize the performance of the
product. Examples of these are security, maintainability, and reliability. Place
those that are pertinent to your product in this section.
3.4.1 Security

Identify security requirements. I.e. encrypted data transfer, database access
control, multi-level password protection, physical security, etc.
Example: Product xyz provides multi-level password control for cockpit
access. Two levels are provided. The initial access level allows issue of speed
and steering controls. The second level allows authorization of system
updates as well as access to specific parameters controlling rate of steering
adjustments and acceleration to the ordered speed.
3.4.2 Maintainability

Identify what components of the system are “maintainable”. Indicate
responsibility for maintenance.
Example: Product xyz provides a low-maintenance configuration for
accomplishing field-plowing. The Cockpit System is updated on a quarterly
basis via Bluetooth download to provide the very latest updates for exhaust
Volume monitoring and distribution. Maintenance procedures for all other
components are conducted semiannually and can be performed by personnel
appropriately skilled in farm equipment maintenance and repair.
10
3.4.3 Reliability

Describe how reliable the end-product needs to be. Is access needed 24/7? What
might an “availability budget” be (i.e. the product needs to complete 96% of it’s
transactions without error or kickback).

Are there critical items that must be available all of the time and non-critical
functions that can be non-functional without effecting critical performance?

State rational supporting the reliability statements.
Appendix

Put items that provide additional information, but do not belong in the body into
appendixes. Examples might be supporting materials, diagrams, etc.

The list of equipment, software, and other materials required for the prototype
should be included in the appendix.
11