Index to Page

• Use Case:  Initialize (System)
• Use Case:  Load Data File
• Use Case:  Load Student
• Use Case:  Load Test File
• Use Case:  Report Session
• Use Case:  Create Student List
• Use Case:  Create Master List
• Use Case:  Create Upload File
• Use Case:  Archive

• Initialize
• Load Data File
• Load Student
• Load Test File

Index of Figures

Figure 1 — System Environment
Figure 2 -- Overview of System
Figure 3 -- Load Student State Chart
Figure 4 -- Load Test Data File State Chart

1. Introduction
1.1. Purpose
This Software Requirements Specification provides a complete description of all the functions and constraints of the Mathematics Placement System, Version 2, developed for the University of Scranton. The expected audience of this document includes faculty members in the Department of Mathematics, the software developer and students needing a model for software development documentation.

1.2 Scope of Project
The Mathematics Placement System is used to grade multiple-choice mathematics-content examinations given to all incoming freshmen in the day schools and to many evening students of the University of Scranton. Based on test results, the system makes recommendations for mathematics course placement and produces a number of different reports for various campus stakeholders. The system is designed replace a previous system created and used on a mainframe computer. The previous system has proved very valuable for its intended purpose but has an awkward user interface, requires reprogramming to make minor changes and relies on the academic mainframe computer.

The previous system was written in Ada and used a menu-driven text interface and flat files and required minor reprogramming to modify the advisement information. This version of the project adapts the system for use on a Personal Computer using a Visual interface and the Access database management system. The revised system must have at least all the functionality of the previous system with some noted problems corrected and an enhanced ability to easily produce new reports on demand.

1.3 Glossary

1.4 References

• Mathematics Placement System, User Manual. Dr. Dennis S. Martin. University of Scranton, 1991.
• Mathematics Placement System 2.0, Software Design Description. Dr. Dennis S. Martin. University of Scranton, 1999.

2. Overall Description
The Mathematics Placement System utilizes information from the University Database and from a Test Scanner to accomplish its goal. Communication is currently through the file system of the University Academic Computer (Tiger). Most printing is done with the local file system but very large reports are printed remotely on Tiger.

2.1. System Environment

The Mathematics Placement System (MPS) is embedded in a larger system involving several University systems. In this section, we describe this environment. The MPS Administrator requests CRN data files and freshmen data files from the University Database when needed. These are sent in text format to the Pretest account on Tiger (Remote File System). Student answer sheets are scanned and a text file with the test answers is sent to the Pretest account on Tiger. (This file must then be converted into a standard text file format on Tiger.) The Administrator uses FTP to move these files to the file system of the PC (Local File System) where the Mathematics Placement System software is located. All grading and report generation is done on this PC with reports in text files stored in its file system. Most reports are printed on a printer networked directly with this PC. One large file is sent via FTP to Tiger, formatted there, and printed on the printer attached to Tiger. One file is put on disk and delivered physically to the Registrar for uploading to the University Database.

2.2. Functional Requirements Definition
Functional Requirements are those that refer to the functionality of the system, i.e., what services it will provide to the user. Nonfunctional (supplementary) requirements pertain to other information needed to produce the correct system and are detailed separately.

Survey Description

• The Administrator uses the Initialize (not shown) to clear the current database for a new semester. S/he uses Access directly to update academic majors, placement recommendations, test versions and answer keys.
• The Administrator uses Load Data File to add/update a file of semester CRN's with course information and instructors.
• The Administrator uses Load Student to add/update a file of persistent (non-testing) student information to the System.
• The Administrator uses Load Test File to add a file of student test data to the System.
• The Administrator uses Report Session to generate test results for all students since the last session was reported.
• The Administrator uses Create General Reports to generate various reports on all students in the database.
• The Administrator uses Archive (not shown) to store one year’s students before initializing for the next year.

Use Case:  Initialize (System)

Diagram:

Brief Description
The system is prepared for use for an academic year. Usually done in June when the previous group of freshmen has become sophomores.

Initial Step-By-Step Description
Before this use case can be initiated, the Administrator has already archived any previous year’s students.

1. The Administrator selects New from the File menu.
2. The system reports completion.
 

Load Data Use Cases

Diagram:

Brief Description
The use case Load Data File is initiated by the administrator to add/update all course and section data to the database.
It must be done after Initialize and it must be done at least once before Load Student.

Initial Step-By-Step Description
Before this use case can be initiated, the Administrator has already initialized the system.

1. The administrator selects the Load CRN Data option from the File menu.
2. The system presents the local file directory to the administrator.
3. The administrator selects the correct file.
4. The system loads the CRN (course and section) data.
(If a CRN is not in the database, it is added with the relevant information. If the CRN is in the database, the relevant information is updated.)

 
Use Case:  Load Student

Diagram:

Brief Description
The use case Load Student is initiated by the administrator to add/update all incoming students to the database.
It must be done after Load CRN and at least once before Load Test File.
It will allow generation of a student list report (names with identification numbers).

Initial Step-By-Step Description
Before this use case can be initiated, the Administrator has already loaded the CRN data.

1. The administrator selects the Load Student File option from the File menu.
2. The system presents the local file directory to the administrator.
3. The administrator selects the correct file.
4. The system loads the student data.
(If a student is not in the database, s/he is added with the relevant information. If the student is in the database, the relevant information is updated.)
5. If a student has a CRN not known to the system, the unknown CRN is reported to the administrator.

 
Use Case:  Load Test File

Diagram:

Brief Description
The use case Load Test File is initiated by the administrator to add student test data to the database.
It must be done after Load Student File.
It will allow generation of a session report.

Initial Step-By-Step Description
Before this use case can be initiated, the Administrator has already loaded the student data.

1. The administrator selects the Load Test Data option from the File menu.
2. The system presents the local file directory to the administrator.
3. The administrator selects the correct file.
4. The system loads the test data.
5. If an identification number cannot be matched, the administrator will have to identify the student either by providing a correct identification number or by adding the student to the database.
 
Use Case:  Report Session

Diagram:

Brief Description
The administrator requests a list of all students tested in the current session. The format is pre-determined.

Initial Step-By-Step Description
Before this use case can be initiated, the Administrator has already added student test data since the last session was reported.

1. The administrator selects the Report Session option from the Report menu.
2. The system selects all students added since the last session was reported, grades their tests, decides recommendations based on stored criteria, adds this information to files and reports to the screen any student who needs further testing.
3. The administrator directs that the list of students who need further testing be placed in a file.
4. All files created are placed in the Local File System.
 
Create General Report Use Cases

Use Case:  Create Student List

Diagram:

Brief Description
The administrator creates a list of all students in alphabetical order with their identification numbers. The test proctors use this list if a student does not remember their identification number.

Initial Step-By-Step Description
Before this use case can be initiated, the Administrator has already loaded the student data files from the University Database.

1. The administrator selects the Student List option from the Report menu.
2. The system creates a file containing the list and puts it into the Local File System.
 
Use Case:  Create Master List

Diagram:

Brief Description
The administrator selects a report from a menu of options covering all the students in the database.

Initial Step-By-Step Description
Before this use case can be initiated, the Administrator has already initialized the database and added students data.

1. The administrator selects the Custom Report option from the Report menu.
2. The system presents a screen of options for possible.
3. The administrator selects the options desired.
4. The system creates the report and stored it in the local File System.

 
Use Case:  Create Upload File

Diagram:

Brief Description
The administrator creates a file of all students in the database who have been tested to upload to the University Database for checking prerequisites for registration for classes.

Initial Step-By-Step Description
Before this use case can be initiated, the Administrator has already added all tested students to the database.

1. The administrator selects the Upload File option from the Report menu.
2. The system creates a file containing the list and puts it into the Local File System.

 
Use Case:  Archive

Diagram:

Brief Description
The administrator stores data for the academic year for future reference.

Initial Step-By-Step Description
Before this use case can be initiated, the administrator has already obtained all reports needed for the academic year.

1. The administrator selects the Archive option from the File menu.
2. The system stores the information and removes all the students from the active database.

 
2.3. User Interface Specification
The anticipated users are faculty members in the Mathematics Department at the University. They have accounts on Tiger with which they are familiar. They are familiar with using FTP to move files. They are comfortable with the concept of a database and will need minimal training to utilize the Access features to update persistent information about courses, majors and faculty.

The system will have a standard Windows type interface with pull-down menus on a top menu bar and buttons and text boxes for communications.

The contents of the reports to be printed are as follows:

2.4. Non-Functional Requirements
These are requirements that are not functional in nature, that is, these are constraints within which the system must work.

The program must be self-contained so that it can easily be moved from one PC to another. It is assumed that Access will be available on the PC on which the program resides. It is not required that a Visual language be available on that computer.

The database must be small enough when it holds an entire class to be held on one 3.5” disk (at most 1.4 megabytes). This is for backup purposes and for transportability. The Archive database may be a separate database for size considerations. It will not have to hold more than four years of student records.

The program must be efficient. We require that any operation other than report generation must be completed with five minutes 100% of the time. Within any operation, responses to an entry must be done within 15 seconds 100% of the time. Report printing for the session reports must be completed with 15 minutes 100% of the time. Report printing for other reports must be completed within 1 hour 100% of the time.

The User Manual will include all Tiger instructions as well as instructions for correct use of the MPS.

2.5. System Evolution
Only the essential requirements have been listed here other than the Archive functionality.

The next goal is to remove all usage of Tiger from the system. This would involve mailing files directly to the Royal Mail account of the Administrator. As the scan files are currently a problem to read directly, this would be a high risk item that should be handled first.

When this system was devised, it was assumed that most of the printing would be on the Remote Printer. As this is no longer the case, it would be desirable to use the report generation subsystem of Access rather than to create text print files. Currently, these files must be brought into a word processor and reformatted, a wasted step.

Version 3.0 is planned to be available in Summer 2001.

3. Requirements Specification
3.1. External Interface Requirements

Input File Formats pre-defined by past usage.

 3.2. Functional Requirements

Initialize

Load Data File

 
Load Student

Hardware:
IBM compatible Pentium-based PC with standard or better keyboard, mouse and monitor. Color monitor is assumed but not required. At least 2M of available disk memory.

Operating System:
Windows that can support Access version used.

Software Needed:
Access 98 needed. Visual interface provided by executable file.

Performance:
No noticeable delays in performance — see section 2.4.

Software Standard:
Every function will have a cancel option if logically permissible. Cancel will restore to a previous safe system state.

Network Interface:
Need access to Tiger for FTP and Telnet capabilities.

Code Standards:
Each code module fully documented using departmental standards.