Harvey Mudd College
CS 121 Project, Spring 2000
1. Introduction
This document is to serve as a Software Requirements Specification
for the eForms project to be completed for CS121 during the spring
semester of 2000 at Harvey Mudd College.
1.1 Purpose
This SRS is a formalization of the specifications of the eForms
system. It presents function and non-functional requirements, use
cases, and general overview of the project and its structure. It
also discusses issues of security, maintainability and
reliability as they pertain to the completed project.
This document is intended to be of use to the development team as
a reference, Professor Keller as an indication of our progress and
a tool for use in our evaluation, and the directors of the Harvey
Mudd Orientation 2000 program (Greg Prier and Angie Kurle), who
were initially responsible for the project.
1.2 Scope
The eForms product will be a combination of several different
subsystems, which will allow a page of HTML forms to be generated,
placed on the web, with the results stored in a database which can
then be queried by an administrator. The administrator can also
edit the forms as they appear online, which may or may not alter
the database itself, add new forms pages to be filled out (several
can be active concurrently, so the database must be capable of
handling this), or remove pages. All of this will be done via the
web, allowing for maximum flexibility and modularity, as well as
minimizing the amount of technical knowledge required of the
administrators.
1.3 Definitions, Acronyms, and Abbreviations
Front-end client - The HTML forms page that is filled out by the
user, which submits to a CGI script that checks the input for
validity and enters it into the database.
Back-end client - The Tk plugin applet that is used by the
administrator to add forms, change forms, view information and
generally administer the system.
Administrator - The privileged user that is allowed to make
changes and use the back-end client.
Database - The SQL database used to store the information gathered
by the front-end forms.
User - A user of the front-end client that fills in their
information and submits a form.
System - The software, not the hardware on which it runs, unless
otherwise specified.
1.4 References
No references to date
2. General Description
2.1 Product Perspective
This product will be entirely stand-alone given a server with the
following installed software:
1. Perl 5.003 or higher
2. Apache
3. SQL
4. php
2.2 Product Functions
1. HTML Forms
2. Form creation / generation
3. Form administration
4. Database Queries
5. Security
2.3 User Characteristics
This system is being designed to be usable on both the front-end
and back-end clients by users with as little technical knowledge
as possible. eForms is designed to be installed on a system by a
sysadmin with a good knowledge of how the system works, but
shouldn't be a complicated installation, since it uses only
standard functionality in Apache and SQL. It is intended to be as
easily maintained as possible, working solely from the back-end
client and with little knowledge of the computer system that the
program actually resides on. Additionally, the system will allow
for checking of validity on the input sent to it by the user of
the front-end client, thus preventing obviously improper data from
being entered into the system. (For example, blank input, letters
for numeric fields, etc.)
2.4 Assumptions and Dependencies
The current planning state for the eForms project makes the
following assumptions:
1. The Tk plugin for Netscape functions properly and is
obtainable for the current versions of that browser.
2. Apache security will be enough to verify the administrative
users of the back-end client.
3. Specific Requirements
3.1 Functional Requirements
3.1.1 Functional Requirement 1
HTML Forms
Dynamically loaded from CGI
Multiple concurrent users up to the allowable limit by the
Apache setup
User authentication
Input verification / validity checking
3.1.2 Functional Requirement 2
Backend
Form Generation
Create new forms
Modify existing forms
Delete forms
Form Administration
Enable / Disable exisiting forms
Database Queries
Add/remove users
Generate hard copies of completed forms
Generate blank forms
Correlation queries (allow the administrator to fill
out a version of the form specifying ranges of data
the return.)
SQL interface
3.1.3 Functional Requirement 3
Database
Store users
Store form data
Interpret queries
3.1.4 Functional Requirement 4
Security
Apache
Protection / Concurrency
3.2 Performance Requirements
3.2.1 Performance Requirement 1
Back-end queries must have a maximum 10 second response time.
3.2.2 Performance Requirement 2
System must support 250+ users in the database.
3.2.3 Performance Caveats
Space is not an issue. The system will not be designed with
regard to excessive space use.
Web server issues, such as concurrent users, some security, and
serving time are not our concern.
3.3 Non-Functional Requirements
3.3.1 Time
The project must be completed entirely by 5/11/00.
3.4.1 Security
Users in the system must be authenticated by standard security
systems already enabled on the web server.
Software security will be maintained through standard Unix
security measures.
3.4.2 Maintainability
The system should not require any maintenance beyond what is
implemented in the back-end.
3.4.3 Reliability
The system should be as reliable as the web server.
4 Use Cases
4.1 Front-end use cases
4.1.1 FE-SF: Select Form
User selects a form to fill out.
4.1.2 FE-LI: Log In
User supplies identification, probably in the form of name and
password. System checks to see if user is authorized to complete
form.
4.1.3 FE-FOF: Fill Out Form
User supplies information in the form where required. This is
accomplished in a typical manner for HTML forms.
4.1.4 FE-S: Submit Form
User presses submit button. Form is submitted to the database.
If the user has already completed a form, then the system will ask
the user whether they wish to replace the form with the new copy.
4.1.5 FE-V: Verify form, modify information
In the event that the form was not completed in a satisfactory
manner (data incomplete, missing, or incorrect format) the user
will be requested to modify the contents.
4.1.6 FE-LO: Log out
User logs out of the system.
4.2 Back-end use cases
4.2.1 BE-LI: Log In
Administrator supplies identification in the form of name and
password. System checks to see if administrator is authorized to
continue.
4.2.2 BE-MF: Modify Form
Administrator uses form generation tool to modify an existing
form.
4.2.3 BE-CF: Create Form
Administrator uses form generation tool to create new form.
4.2.4 BE-DF: Delete Form
Administrator deletes a form. If the form is in use, the
administrator will be strenuously warned.
4.2.5 BE-E: Enable Form
Administrator enables a form, allowing it to be filled out by
users, and the data to be stored in the database.
4.2.6 BE-D: Disable Form
Administrator disables a form, so that users can not fill out the
form anymore. Data stored in the database is not removed.
4.2.7 BE-AU: Add User
Administrator adds a user.
4.2.8 BE-RU: Remove User
Administrator removes a user from the database, with all filled
out information thus far.
4.2.9 BE-GCF: Generate Completed Forms
Output to the screen the completed version of the forms. That
way, the forms are available on hardcopy and at least resemble the
snail mailed ones.
4.2.10 BE-GBF: Generate Blank Forms
Output the blank version of a form, for example use or for use in
hardcopy format by those not using the system.
4.2.11 BE-Q: Run a Query
Administrator fills out a form with patterns instead of actual
entries. Database returns all matches to the patterns entered.
4.2.12 BE-SQL: Run an SQL statement
Provides administrator with a way to run an SQL statement directly
from the back-end.
5 Scenarios
5.1 Front-end client submission
Alfred, a user, bring up the URL for the front-end client CGI. After
logging on using his username and password, Alfred
fills out the form with his information, hits submit, and the
information is sent to the CGI for processing. It turns out that he
accidentally filled in his date of birth incorrectly (he had "Feb"
rather than a numeric answer of "02"), so he needs to
fill out the form again. The system tells him this, and lets him make
the necessary changes. He does this, resubmits, and it is accepted.
The CGI enters his information in the database, and Alfred is now done.
Alfred logs out.
5.2 Back-end client form creation
Bonnie, an administrator, finds that ABC Forms needs a new form to
gather information on the habits of household animals. She logs on as
an administrator and goes to the Create New Form option. She fills in
the information she thinks she wants, creates the form and goes to
check it on the web. After a while she realizes that they didn't
include options for finding out the habits of household fish, so she
goes back to edit the form using the Modify Form option. That done,
she republishes it, and goes on about her business.
5.3 Back-end client database query
Clyde, another administrator (and Bonnie's partner incidentally),
needs to find information on the users of ABC Forms. He opens up
Bonnie's new form that gathers information on the habits of household
animals and fills out only a few bits of information, those
representing cats that sleep all day, and that for dogs that sleep all
day. When he hits submit, the program queries the database, it
returns all information that has dogs or cats that sleep all day and
returns that information to him.