Section 4:

Functional Requirements

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Intern Functions:

           

            In order for the coordinator to correctly combine student requests with a work site, the students will need to enter information on their majors and interests.  To begin the process, a student will submit a username and password which was obtained from the coordinator. If the user information is correct, the student will be directed to the student homepage, otherwise they will be directed to an error page with a forgot password function.  From the intern homepage the student can select to fill out an application form or a site evaluation form.  In either case, the intern will fill out the form entries which will be checked for errors and blank fields by a JavaScript program, then submitted and stored in the information database. The student will then receive a confirmation email message verifying that the form that was submitted successfully.  The coordinator will also be notified via an email message that a specific user has completed a form. In the following days the student will receive another confirmation email from the coordinator stating if they are eligible or not.  After the internship has been completed, the students will need to complete an evaluation form describing their experience with the site.  This evaluation helps the coordinator better understand the relationship between the intern and the site.  The evaluations will also be able to help show over time which sites consistently provide good or bad experiences.  This form will also generate a confirmation email as before, for both the student and the coordinator.

 

 

Coordinator Functions

 

            In order for the database to run efficiently and for the coordinator to organize the information that the database is storing, an administrative account will be needed with special functions only available to the coordinator.  The coordinator begins by logging in. If the log in is correct, he will be directed to the coordinator homepage, otherwise, an error page will appear with a forgot password function.  From the coordinator homepage, the coordinator can chose to create a user, delete a user, or generate a report.  When creating a user, the coordinator will submit information to create a new username and password and it sends the information into the database. It then sends a confirmation back to the coordinator whether the user was created or not.  The coordinator can then send the user information to the respective student, allowing students access to the information system.  If the coordinator chooses to run a query, he or she will need to enter search parameters. The information system submits the request into the database, which returns the results in formatted reports to the coordinator.  These reports will give the coordinator charts to better match interns and sites.


Site Functions

 

            Sites must be able to fill out the informational forms to participate in the internship program.  To begin, the site will submit a username and password.  If correct, the site will be directed to the site homepage, otherwise they will be directed to an error page with a forgot password function. Once at the site homepage they will be able to create a profile about the internship site, and to submit a project proposal that they wish to have an intern work on.  The forms will then be submitted and stored into the database. The site receives confirmation regarding the completion of the forms.  The coordinator will also be notified when the work site submits these forms by email. The work site must also fill out an evaluation form when the internship has been completed.  This information will be used in the future to better predict site to student compatibility.  As with the above forms, they will be submitted and stored in the database, the site will receive confirmation on the submittal of their forms, and the coordinator will be notified upon completion of the evaluation as well.

 

 

 

 

 

Section 5:

Performance Requirements

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

SCIPAnet shall not be a bandwidth or disk space intensive application.  At any given time there will be a limited number of students registered in the system also there will a small number of work sites registered.  Therefore, there is no need to consider the possible hard disk ramifications of the system.  The performance of the internet is the major limiting factor regarding the everyday use of the system.  Bandwidth is a limiting factor in our design.  To this end the web pages used in SCIPAnet shall contain a minimal number of elements. This will lead to the efficient navigation of the website and procurement of information.  The development team shall endeavor to avoid gaudy and extravagant elements that would detract from this goal.

 

A further performance requirement involves the speed of access to the database.  This can be increased by properly normalizing tables.  In addition, any SQL (structured query language) query shall be of proper syntax to avoid unnecessary delays in the optimization and parsing of that command.  This will avoid a lot of headaches with reports taking forever to generate.  Furthermore since our website will be generated “on the fly” using the Oracle Database, it is of paramount importance to the internet speed to have the queries optimized and performing within specification.

 

To this end the following defines our performance requirements in a clear and concise way.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Section 6:

Exception Handling

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

SCIPAnet will utilize an Oracle Database, which will allow exception handling to be carried out more easily.  The natural concurrency and data type controls that are built into the database will allow it to recover gracefully from a mal-input.  Furthermore SCIPAnet will utilize JavaScript as a first line of defense against poor input.  By asserting certain requirements for information, such as, all emails must contain an “@” symbol, SCIPAnet will be able to curb the number of bad inputs made into the system.  Since this system relies heavily on the use of forms, which usually generates error prone user input, the need for error checking is clear. 

 

Another problematic point in SCIPAnet is the user login/authentication.  If a user repeatedly enters a wrong password it may be an indication that a person has immoral intentions with their actions.  It may also show that a person has forgotten their password or is having trouble with a login.  To this end SCIPAnet will take action after a predetermined number of failed attempts to log in.  After the indicated number of attempts the user will be forwarded from the current login screen to a help screen. This will have options for retrieving a lost password, including contact information for the internship coordinator.  Employers will be directed from this screen to contact the current internship coordinator for a lost password, since he is the only one that will have access

to their password.  This procedure will help reduce attacks on the system as well as help students who have forgotten their password to log in again.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Section 7:

Early Subsets and Implementation Priorities

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Early Subsets and Implementation Priorities

 

1.      The major priority of our company is to create a user friendly, web-based system.  We will allow for three users: Coordinator, Site, and the Student.

 

2.      We will be using an Oracle 9i Database which will gather information from the users through the use of the Internet.

 

3.      User updates and corrections will be allowed and stored back into the database.

 

4.      The coordinator will have the once cumbersome task of keeping track of interns and sites streamlined, so that the coordinator will be expending minimal effort.  This will ease the burden of dealing with hard documents and allow them to be easily accessible through our database.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Section 8:

Foreseeable Modifications and Enhancements

 

 

 

 

 

 

 

 

 

 

 

 

 

 

            The client may request changes to the software based on a variety of circumstances.  Modifications to the product may need to be completed.  Possibilities include:

 

1.)        Page formats may need to be addressed at the clients request for items such as page style.

 

 

2.)        Functionality may be enhanced by matching up the student’s requests to the business positions offered.

 

 

3.)        The need to upgrade the Oracle database system past 9i to give more functionality to the information system.

 

 

4.)        The evaluation and information sheets may need to be changed to fit new criteria and there may be a possibility to add or remove form page entries.

 

 

5.)        Students which have submitted forms can be given email addresses of businesses that fit their needs which also may decrease Lederman’s work load. 

 

 

 

 

 

 

 

Section 9:

Acceptance Criteria

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1.)        The system must include a database which contains all of the student’s and         business’s internship interest and requirement information.

 

2.)        The system should allow the user to complete forms to help match students and             businesses.  It must also incorporate confirmation emails to be sent to the user        after he/she has completed a form.

 

3.)        The system should allow the administrator (Lederman) to be able to efficiently    keep records off all of the entries from the students and work sites in a web based   database system this will be separate from the Siena College web page removing the need for the outdated paper forms.

 

4.)        The system should allow the administrator (Lederman) access to this database and produce reports, communicate with both the students and businesses that complete the forms, and match student with businesses that fit each others requirements.

 

5.)        The system should allow for the printing of various reports and queries.  These   reports should include: student reports, business reports, evaluation reports, and       queries based on student interest to business match ups.

 

6.)        The system should allow access to multiple users on a plethora of security levels.            The database administrator (Lederman) should have full control over the database         to add and delete users and records.

 

7.)        The system must provide a form of a feedback mechanism in regards to the form           that the user completed.  This feedback will be incorporated into an HTML based   email giving the user a copy of the form that he/she completed.

 

8.)        The system must be user-friendly.  This includes all necessary instruction to        navigate the site, login correctly, and complete the correct form that the user is          looking to fill out.

 

9.)        The system must be able to run on any internet browser.  This means that there will be no need for a specific type of computer or operating system to successfully       access the entire web site.

 

10.)      The system should be able to allow easy maintenance and a means of upgrade should the need arise.  This will concentrate on minimizing cost and maximizing efficiency.

 

 

 

 

 

 

 

 

 

 

 

 

Section 10:

Testing Requirements

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

            Digital Foundry will ensure that the software meets the requirements identified in this document by testing the following:

 

1)      Data that does not concur with the parameters will not be entered into the database.

 

2)      The data that is stored is stored in the expected location.

 

3)      Automated emails are reliable and sent only to appropriate parties.

 

4)      Queries run by the coordinator return accurate results.

 

5)      When a password is forgotten the user can receive their password in a secure and precise fashion.

 

6)      Each user has access to appropriate areas of database.  No more and no less then is needed per user.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Section 11:

Glossary of Terms

 

 

 

 

 

 

 

 

 

 

 

 

 

Glossary of Terms

 

 

Alpha testing – an early stage of testing a software program.

 

Beta testing – a more advanced stage of testing a software program.

 

Database – a collection of information organized in a way that makes it easier to locate desired pieces. 

 

Debugging – finding and correcting errors in a program.

 

Digital Foundry – The name of our team, which is developing ScipaNet.

 

HTML – Hyper Text Markup Language

 

ITS – Information and Technology Services, the branch of Siena College which is in charge of information technology on campus.

 

Java Script – A web based scripting language

 

Normalization – The process of removing redundancies from a Database.

 

NT Administrator – the member of our team who is responsible for controlling user accounts on our Windows NT computer, they are also responsible for security and networking.

 

Oracle –  A particular brand of Database Management Systems, and also the name of the parent company that makes this brand.

 

ScipaNet – The name given to the software plan which Digital Foundry is developing for Dr. Lederman

 

SQL – Structured Query Language, a way of requesting specific information from a database.

 

Waterfall Model – a sequential approach to software development that involves the following steps: Project Definition, Analysis and Requirements, Design of Solutions, Code Programming, Testing, and Installation and Maintenance.

 

Webmaster – the member of our team that is responsible for making all of our documents accessible through a web page.

 

Web server – a computer that stores and delivers web pages.