Software Requirements Specification
TA1 Version 1.0
3 New Guys
Michael Ha - Doug Goldstein - Barry Haimo
March 24, 2004
1. Introduction
1.
Purpose
This software is being developed to for customer Xuan Gu, an employee for the CISE
Department at the University of Florida. TA1 is part of a four-part project consisting of
a Faculty, Admin, TA1 and TA2. The TA1 interface will allow the user to edit the
number of TA slots for a particular course as well as assign/update TA applicant
categories. There will also be a secure login before any of these interfaces are
accessible.
2.
Document Conventions
The format of this SRS is simple. Bold face and indentation is used on general topics
and or specific points of interest. The remainder of the document will be written using
the standard font, New Times Roman.
3.
Intended Audience and Reading Suggestions
This document is intended to be read by the customer Xuan Gu. This is a technical
document and the terms should be understood by the customer.
4.
Project Scope
The scope of this project includes our group of developers assisted by our customer,
Xuan. The scope thus far has been the completion of the basic interfaces that will be
used to build the system. The database used, has been set up and given the necessary
permissions. The constraints felt thus far by the group have only been our weekly story
cards, the end-to-end side of the interface, and our first release, scheduled for February
11, 2004.
5.
References
Resources have been used from Dr. Cubert’s website, www.cise.ufl.edu/~rmc/se/, and
this SRS was modeled after one found online at
http://www.processimpact.com/process_assets/srs_template.doc.
2. Overall Description
1. Product Perspective
The TA1 Project is a new product that is part of a larger, more complete product for our
customer. It will provide the faculty a way of viewing all of the TA’s information that
is necessary in order to make a decision on every TA’s status.
2. Product Features
This project has three pages that are part of TA1, which is part of the larger product.
The first page is a login interface that will only allow access from the proper users. The
second page displays the available classes based on a certain semester and the course
enrollment for a particular class. The third and final page displays information about
TA’s, their status, and any special notes that might’ve been posted about them.
3. User Classes and Characteristics
The user classes will be TA1, TA2, Administration, and Faculty.
4. Operating Environment
This product is web-based and will be hosted by a web server on the CISE website
(www.cise.ufl.edu). This product can be viewed by any web browser, and has been
tested for compliance with Mozilla, Internet Explorer, Netscape Navigator, and Opera.
5. Design and Implementation Constraints
There are no constraints at this point in time.
6. User Documentation
The user documentation can be found in this SRS.
7. Assumptions and Dependencies
We assume that extra documentation beyond this SRS would not be necessary in order
for the user to utilize this product.
3. System Features
1. Secure Login to interface
3.1.1 Description and Priority
This feature will give the user a secure and simple login screen. It is based on professor
Cubert’s exclusionary principle. This means rather than creating try catches for a
handful of error types, it just has only a handful of available and possible inputs, to
prevent any improper logging in, which might cause unexpected errors, and therefore
limiting the system’s capabilities.
3.1.2 Stimulus/Responses Sequences
It will consist of two basic fields, Username and Password. There are two buttons:
Login and Lost or Forgot Password. Login will submit the entered data for approval
followed by access, and the forgot password will direct the user to access his/her
password which has been forgotten.
3.1.3 Functional Requirements
The most important function is to only grant access to users that are listed in the
database. The customer will provide the information on who will be allowed access.
To implement the security, the web page must check the database to see if the
Username and Password are valid. If they are not, the user will receive an “Invalid
login. Please try again.” response.
2. Web-based interface for editing TA slots
3.2.1 Description and Priority
This feature will allow the user to edit the number of TA slots for a specific course.
The user will be given a list of course numbers and names for a given semester. They
will also be provided with the number of students enrolled in each specific class.
3.2.2 Stimulus/Responses Sequences
This interface will consist of basic fields for the user to enter information. Also,
information about each person in the database that is listed will be shown if the mouse
is highlighting a name for one second. This helps alleviate some time when the user is
searching for data because it lessens the usage of the submit button because the data has
already been found.
Additionally, once logged in, upon hitting the back button and reentering the site will
not call for another log in screen. It will therefore take you to the following page of
options.
3.2.3 Functional Requirements
To use this interface there will be many functional requirements. The main function
will use PHP to pull the course information off of the database.
3. Web-based interface to assign/update TA info
3.2.1 Description and Priority
This feature will not only provide the user with the general information on all the
applicants, but also allow them to assign and update the TA categories. The user will
be given a list of names and UFID’s of all the applicants to their courses. They will
also be given the ability to sort the applicants in order of UFID or alphabetically by
their last names.
3.2.2 Stimulus/Responses Sequences
The user will be able to change the status of the applicants as needed.
3.2.3 Functional Requirements
This interface will depend mostly on retrieving information from the database. PHP
will be integrated into the HTML and will retrieve needed information for the interface.
The site will be xhtml1.1 and css compliant.
4. External Interface Requirements
1. User Interfaces
The first interface is the log-in screen. This is where the user has a specific Username
and Password so that they can gain access to the database. Next is the TASlots
interface. You can choose which semester’s classes you would like to view and are
able to update any of the categories displayed in the columns. The next and final
interface is the “assign/update” page.
2. Hardware Interface
Though not necessarily interfacing with the hardware, the system must make use with
an internet connection.
3. Communications Interface
The system uses an internet connection to connect to the database. The code itself
though, does not specifically direct the network controllers to do any work.
4. Software Interface
Along with the internet connection, the system makes indirect use of an internet
browser. Outside of the HTML code and PHP, the code doesn’t tell any software,
including the browser, what to do.
5. Other Nonfunctional Requirements
Security Requirements
Access to the database should be restricted to people that are required to view
information about TA’s. Passwords and ID’s should be regulated to be at least a certain
length and must contain non-alphanumeric characters in both the password and ID.
Appendix A: Glossary
HTML: Hypertext Markup Language
CISE: Computer and Information Sciences Engineering
SRS: Software Requirements Specification
Story Cards: Each is a 3 x 5 card on which the customer describes a deliverable.
TA: Teaching Assistant
UFID: ID number assigned to every student at the University of Florida.
PHP: PHP Hypertext Preprocessor