Requirements Specifications
Web-based Calculus Review
Courtland Caldwell
Zach Lute
Chris Scribner
Matt Stupca
Table of Contents
Use cases, which are an integral part of requirements, are covered in a separate document.
The purpose of our project is to build a website where students who have already taken calculus can review concepts through a collection of lecture notes, example problems, and an example problem generator. The website must track student usage in a semi-transparent fashion so that teachers can review who has been using the site. The site will consist of a front end website which will support mathematical notation. The backend of the site is made up of a SQL server and content management software.
The following document outlines the specifications placed on the product by Dr. Finn, our client. The document is composed of the work of four individuals and provides very specific information for our designers.
User Environment Characteristics
Types of Users:
Students:
A Rose-Hulman student looking for a refresher on calculus material he/she hopefully has seen already but has forgotten over time. It is expected that senior engineering majors will be taking a standardized test that involves calculus, so these seniors will be the primary users of the system.
Faculty:
A Rose-Hulman math faculty member, most likely Dr. Finn, is responsible for adding and maintaining the informational content of the system. Members of the faculty are also responsible for responding to questions students ask using the help forum on the system.
Skills:
1. Basic computer skills.
2. Familiarity with internet navigation.
Environment:
1. Any PC able to connect to the internet.
2. System will only be guaranteed to work with Internet Explorer, as it is the official campus browser.
Basics:
Wants:
-24/7 uptime
-no corruption of data
-code runs completely clean
Needs:
- work week (Sunday night – Friday afternoon) long uptime
- corruption handled
- working backup system
Elaboration:
Uptime: Since this is a web server, it would be ideal to have the program run all the time and be able to clean up after itself. However, the failure of major businesses to achieve this ideal makes the likelihood of achieving such a goal a pipedream. Instead, the aim is to be able to handle our low traffic during the work week without crashing or hanging the system if minor disturbances are experienced. Disturbances include but are not limited to power surges, large numbers of users, and large uploads.
Corruption: The main worry with corruption is material being damaged beyond repair. The backup copy of the database makes many of these problems less dangerous, but the system should be able to deal with most material that a professor would upload in an intelligent way. To do this intelligently would be to preserve the file structure, data already entered, and data being entered. Long term problems will be near impossible to test for which could prove to be a difficult hurdle later in validation.
Backup System:
· Checkpoint
o Created every Friday night at midnight
o Stores user profiles, forum data, and subject tree (whole database)
· Recovery
o Method to reload data
o Faculty will be doing this task, so it should be relatively easy
· Restart
o Monthly backup of subject tree
o Reload this data with original program to completely restart program.
Basics:
- integrated problem adder
- integrated subject updater
- moderator controls
- restore points
Elaboration:
Integrated problem adder:
The problem adder is an integral to the maintainability of the system. With this tool, the system can evolve into the type of system that the professors envision. The trickiest part of designing this system will be the mathematical notation. The system should display problems like they would appear in a math textbook, but entering this information into the system is a considerable design challenge. Devising a method that is both easy to use and powerful enough for our uses is a requirement.
Integrated subject updater:
With the ability to completely alter the subjects and material within any subject the professors can also flesh out our skeleton of information. Without this tool, the system will remain static as we have created it, and new subjects the professors cover would not be available for students to review. Since we are tracking usernames already, it would preferable to limit access to edit and delete an item to only the creator and moderator.
Moderator controls:
A control panel for the moderator or the administrator of the system should exist. This control panel would be able to restore the database back to a critical point and offer full access to the subject tree. Making these tools easy to use is preferable so that a new professor can take over for Dr. Finn if he ever decides to leave.
Restore Points:
This issue is tied up availability, but the system needs to have a method of backing up all the data. This is discussed in length in availability.
Basics:
Static requirements:
- Few simultaneous users
Dynamic requirements:
- varies depending on how many users
- varies on what they are doing
- downloading/uploading material
Elaboration:
Static Requirements:
Since we are serving web content, the only concern in static requirements is the ability to handle a set number of simultaneous users. Although the number of actual users will vary depending on time period, the system should be able to handle at least 10 simultaneous users. This number might seem low, but the additional information in the dynamic section will explain why this number is justifiably low.
An important fact to remember is that this project is largely a prototype in itself. If it is successful and the math department loves it, they may turn it into a more complicated system. It is likely that the number of users would increase at this point, but we should not be overly concerned about this fact.
Dynamic Requirements:
Really there are two distinct actions that users will be taking repeatedly with the system. One is read thread – to either explore a subject or peruse the forums. The other is do problems – which allows users to get a list of problems and gradually reveal the answers.
Reading a thread. When first loading this page, there will be a decent amount of overhead, but no extra work after the page is loaded. The user who is reading this page probably will take at least a minute or two to get through this information. Therefore, as long as the page is loaded in an amount of time that is reasonable for your average webpage, the user will be content. That obviously varies with the speed of their machine and connection, but a second per page of information seems right.
Doing problems. Loading the page with the problems shouldn’t take that long, comparable to that of reading a thread. The difficult part here is displaying the answers in a timely fashion. If the system takes an inordinate amount of time to display this answer, the students will quit. A reasonable amount of time here would be under half a second, while it would be preferable that the answer appear near instantaneously (under a tenth of a second).
Both of these problems are directly proportional to the number of users, so the system could take a slight hit in performance in order to respond if the 10 users all look at different subjects at the same time. This hit should not be too noticeable, and the problems must still display in less than half a second.
Other issues that must be dealt with are professors uploading material or problems to the database. It is possible that these materials could be fairly sizeable, but student performance should not suffer at all during material upload. People expect systems to take a while to upload material, so this delay should not be a problem.
Another issue is the need for professors to respond on the forums. This performance criterion is untestable but goes a long way in determining if the system will be used. It is hoped that Dr. Finn’s involvement will at least insure one regularly responding professor.
As with any web-based application, the ideal uptime is 100%, as users will expect to be able to access the system at any time, day or night. Though 100% uptime is not a technical possibility, based on real-world issues, it makes sense to strive to get as near as possible to this goal. Two aspects of system reliability are reliability of the hardware and reliability of the software. Although we likely have little control over the reliability of the hardware, the software must be made as reliable as possible. As such, we must be sure to choose a web server and database server that can maintain a reliable system. Beyond that, any software we write must be able to handle flukes and errors gracefully, reporting issues and moving on rather than hanging or crashing the system. In this way, system reliability is insured.
Basics:
Wants:
-invulnerable to outside attack
-students unable to post dangerous (either crude or insulting) material
-professors cannot corrupt database
-does not allow students access to changing database
Needs:
-some filter on student material
-a limit on professor access
-students cannot alter database
Elaboration:
Student Filter:
This filter is a general censorship on words and items that should not appear on our forum. The words themselves are not that tricky to filter out, but the items may be tricky. Here we run into the problem of mathematical notation again. To express themselves properly, the students may want to post a graph or an equation in maple to the forum. Both of these posts would be done with some sort of picture link.
Problems spring up immediately when you give the students this kind of freedom. First, there is the impossibility of guaranteeing the quality of these images. Second, there is the possibility of someone posting too many images and overloading the server.
Seeing these problems, I propose three separate solutions:
Trust the students: As stated, give the students full freedom until they mess up. The mechanism behind this functionality would be some sort of code of conduct. By agreeing to this code, the students receive full functionality. Since we are tracking usernames and profiles adding this functionality should not be too difficult. The downside is the obvious slip up that seemingly always occurs. When coupled with a malicious user who has disguised his/her identity, the freedom to post anything would produce even worse problems.
Filter everything: Going the opposite direction, if we severely limit the input of the students, many security issues will be dealt with too. First off, make the student forum all text. While this might make understanding more difficult, the difficult issues raised by allowing the pictures are eliminated. Add in a heavy language filter and most language problems should be stopped. Of course, almost all these systems can be circumvented in some manner, so all the filtering just cuts out the worst and most obvious of it.
Post through moderator: All posts are routed through a moderator (Finn) who checks to make sure their content is suitable. The advantage and disadvantage here is that someone has direct control over what gets on. Advantages include a human control over content and a reminder that someone has posted to the board. Disadvantages include the problems of dealing with an absent moderator, and the fact that the board is getting closer and closer to just emailing a teacher about a problem.
Personally, I am in favor of trusting the students. I doubt many will abuse this system since the risk (getting expelled) is not worth the reward.
Professor Limitation:
The functionality of this system relies on professor involvement and input. However, the data on the system could easily be destroyed by accident if safeguards are not built into the system. As of this writing, the first product release will be designed for one user, Dr. Finn; however, later releases would like to involve the whole faculty.
Recommendations/ideas:
Dr. Finn will have some knowledge of the system, so he will at least be designated as the moderator of the system, if not its administrator.
Track username for all uploaded documents. Allow only the person who uploaded the material or the moderator access to delete or edit this material.
Create separate backup of all material (outlined in the maintainability section)
Students accessing database:
Since usernames are being tracked, this problem should be taken care of by providing access to only professor usernames. This list of usernames should be easily changeable, so that a later administrator can add or delete professors.
This solution does not deal with malicious users who would seek to disguise themselves as professors. The best solution for that problem is restoring the back-up data, and looking to the Technical Service Center for help in tracking this person down.
HTTP Server – Apache 2.0.44
The HTTP Server for the system must be capable of handling all direct user data access in and out of the system in a reliable fashion. Apache is a proven HTTP server available for many platforms.
Database Server – MySQL 3.23
The database server for the system must reliably contain all data related to the system, from user profile information, to practice problems, and solutions. MySQL is a robust, open-source database server capable of handling this task.
Scripting Interface – Perl 5.8.0
Any scripting necessary for the system will be handled by Perl, as it is a fast, simple, and universal scripting language capable of handling the tasks necessary for this system.
Referring to the “bubble chart” there are two databases: the “User Profile Database” (UP), and the “Topics, Examples, and Practice Problems” (TEP) Database. Each will have different logical requirements. I merely wanted to make this clear before confusion ensued.
Types of Information used by functions
UP Database
· String data representing username and other data which has not yet been decided upon.
· Some sort of representation of what examples have been completed.
TEP Database
· String data to represent topics, examples, and practice problems
Frequency of Use
UP Database
· Frequently accessed as the completed exercise list will need to be known when doling out content (practice problems, examples).
TEP Database
· Frequently accessed. For most use cases, topics, examples, and practice problems will need to be accessed to generate web content.
Accessing Capabilities
UP Database
· Access time must be no more than a couple seconds to not discourage users from using the site. It is likely the UP database will need to be accessed before the TEP database (to figure out what content to grab or not to grab), so it should be relatively fast.
· The UP database should not have to handle many multiple requests as the site load will likely be low. However, it will likely not hurt to make it scalable.
TEP Database
· Access time for this database should also be timely. Timely meaning less than a second or two.
· Like the UP database, this one should never have much user load, however the data amount to be retrieved will be greater and therefore a larger load capacity should be built in.
Integrity Constraints
UP Database
· It is important, yet not vital, that user data remains intact. The most that will be lost is a record of problems already viewed.
TEP Database
· Data integrity is more important for this database as it affects all users of the system. All data in this database should be fully scrutinized to ensure correctness.
The design of this project is being split into two quarters. The goal for the designers in the first quarter will be the creation of a working prototype of the system without support for mathematical notation. It is the opinion of the requirements team that the supporting of mathematical notation in this project is perhaps as difficult as the entire remainder of the project and therefore has an entire semester allocated to its development, implementation and testing.
The project is expected to be completed in the time allotted and sufficient time has been allocated for most mishaps that we may encounter on the way to providing a working product.
Abstract:
The purpose of the content controller is to serve as the universal data point in our project, which provides our sub-apps with database information, user information and as the linking point to the flow controller. Through the content controller we can establish a universal sub-application interface. The content controller concept also provides us with some security benefits. The content controller design is an adaptation of the “Ari” data-center concept and architecture, originally designed by Court Caldwell and Drew Kilz.
Functionality:
The content controller’s responsibilities (instruction set) can be divided into six unique categories: flow controller to content controller, content controller to flow controller, content controller to user profile database, content controller to topic and problem database, content controller to sub-application, and sub-application to content controller.
Flow controller to content controller:
The purpose of this connection is the trafficking of commands from the flow controller to the appropriate sub-application. Furthermore, designing the layout of our program in this fashion (including the FC to CC link) allows us to be consistent with our belief that all data which resides in memory should be the sole property of the content controller, including pointers to sub-applications that the flow controller might wish to execute.
Content controller to flow controller:
The purpose of this connection is two fold; first to reply to requests issued by the flow controller and secondly to traffic requests of all varieties from sub-applications.
Content controller to user profile database:
The purpose of this MONO-directional link is to satisfy the user profile requirements. These profiles which track usage as well as progress (which problems a student has done correctly in which topics), will be both queried and altered by the content controller. You may notice that there is no UPD to CC link; this is consistent with our plan to maintain our databases solely as a transparent backend; in essence speaking only when spoken to.
Content controller to topic and problem database:
The purpose of the MONO-directional link is to provide a transparent linking system to our database of topics, examples and problems. Like the former link this link is one directional; there is no need for the database to “decide” to access our program.
Content controller to sub-application:
One of the most important, and therefore necessarily error free component, of the content controller is its link to the programs many sub-applications. The link interface is detailed below.
Sub-application to content controller:
Like the former, this link is imperative to the functioning of our program and therefore must undergo the most rigorous of evaluations and testing, prior to implementing the sub-applications. The link interface is detailed below.
Details:
The following are interface specifications.
Content controller to sub-application interface:
- Load request
- Register request
- Unload command
- Data request response
- Confirm data addition
- User data request response
- User data creation request response
- Confirm user data addition
Sub-application to content controller interface:
- Submit data request
- Submit sub-application request
- Submit user data request
- Register sub-application
- Submit data addition request
- Submit user data addition request
- Submit user data creation request
Basics:
-Some system for entering and displaying math notation is required
-Could be difficult, recommend to start as soon as possible
Elaboration:
Copied from mathforums.org[1], here is an example of what a text based forum looks like:
> We encountered a question about the integral of tan(x)dx from -pi/2 to
> pi/2 and a related question about the same integral from 0 to pi/2. In
> each case does the integral have a value? Our thinking was that it does
> not from 0 to pi/2 as it has an infinite limit, but it does from -pi/2 to
> pi/2 because of symmetry (odd function). Is this correct and is there a
> better (more formal) way to justify this?
>
It is not the symmetry that justifies it. After all integral (-1, 1) of dx/x
also has symmetry to the origin, but diverges.
let a = pi/2 to speed up typing
integral (-a,a) tan x dx = integral (-a,0) tan x dx + integral (0,a) tan x dx
= lim (b->-a+)[-ln|cos x| (b to 0)] + lim(b->a-)[-ln|cos x| (0 to b)] =
lim (b-> -a+) (-ln|cos b| ) + ln 1 - ln 1 + lim(b->a-) ln |cos b|
Because of the absolute values the left and right side limits can be ignored.
This is an indeterminate form of the type -oo + oo, but it can be evaluated
without using L'Hopital's Rule:
lim(b->a) [-ln |cos b| + ln |cos b|] = lim (b->a) ln (|cos b|/|cos b|) =
lim(b->a) ln 1 = 0
Lin
Lin McMullin
Niantic, CT
This is understandable with some effort, but a lot of examples as to what’s
wrong with this system show up here. The word integral is repeated a couple of
times and figuring out the order of operations for the phrases can be
difficult.
The biggest problem is the third paragraph of the reply, which is essentially
one line of mathematical notation. Actually figuring out what is being said
here is not a trivial task. Imagining extended fractions or square roots
involved only makes the case clearer.
Other problems present themselves as well. The need for a whole new way of
communicating math to students is a difficult thing to do effectively. The form
Rose students use now, Maple, is unfortunately not any easier to understand when
in command line form.
Other formulation, such as Greek letters are difficult as well. Most people
(who aren’t in frats) don’t know the names of all the letters, so they refer to
them as something else. Example: (eta (η), commonly known as squiggly n)
Upon analysis, the only real solution is to create some system to display math
notation and a way to take a text input and create the same math notation. It
is preferable that the system be as easy to use as possible so that use by the
faculty is facilitated quickly and easily.
The requirements team also believes that this aspect of the system may be the
trickiest to implement, so that options and methodology should be researched as
soon as possible.