Mathematics Placement System 2.0

 

Software Requirements Specification

 

Dr. Dennis S. Martin

 

February 28, 1999

 

Submitted in partial fulfillment

Of the requirements of

A Sabbatical Project

<<Annotated Edition>>

 

<<Please note that all comments in double diamond brackets (such as these) are comments about the paper and are not part of the paper. They are intended to help clarify how this report meets the requirements of the documentation standards. Also note that double-spacing has been suppressed for better viewing on the screen.

 

<< The project described here is an actual project produced by the author in the time frame stated in the proposal. These documents are faithful to the spirit of the project but were created to help clarify the application of the standards that they accompany. They have been edited to enhance their usefulness as models for documentation at the expense of being useful documents for the project. In fact, this set of documents does not fully or accurately describe the project. Several critical features of that project protecting security and any data that might identify individual students have been changed. In addition, the project has evolved since it was created and several of the items discussed here no longer apply.

<<The reader is further warned that the author takes the stipulation Fall 2001 Version very seriously. This is always a work in progress. As problems are pointed out in either these documents or the standards that they exemplify, changes will be made immediately and, possibly, without notice. On the other hand, this is an opportunity for students to edit a faculty work to improve it. Turnabout is fair play in this instance! Comments such as “I read the section on … and it still does not make sense.” are actually useful at this stage. >>

Index to Page

1. Introduction. 3

1.1. Purpose. 3

1.2 Scope of Project 3

1.3 Glossary. 3

1.4 References. 4

1.5 Overview of Document 4

2. Overall Description. 4

2.1. System Environment 4

2.2. Functional Requirements Definition. 5

Survey Description. 5

Prepare System Use Cases. 6

Use Case: Archive. 6

Use Case: Initialize (System) 6

Use Case: Modify Persistent Data. 7

Load Data Use Cases. 7

Use Case: Load CRN Data. 7

Use Case: Load Student Data. 8

Use Case: Load Test Data. 9

Use Case:  Enter Student 10

Use Case: Enter Test Data. 10

Create Reports Use Cases. 11

Use Case: Create Student List 11

Use Case: Report Session. 11

Use Case: Create Custom Report 12

Use Case: Create Master Report 12

Use Case: Create Upload List 12

2.3. User Interface Specification. 13

2.4. Non-Functional Requirements. 14

2.5. System Evolution. 14

3. Requirements Specification. 14

3.1. External Interface Requirements. 14

File Format: CRN File. 15

File Format: Student Data File. 15

File Format: Test Data File (Raw) 15

File Format: Test Data File (Modified) 15

3.2. Functional Requirements. 15

Archive. 15

Initialize (System) 16

Modify Persistent Data. 16

Persistent Data Items. 16

Load CRN Data. 17

Load Student Data. 18

Load Test Data. 19

Enter Student 20

Enter Test Data. 20

Create Student List 21

Report Session. 21

Create Custom Report 21

Create Master Report 22

Create Upload List 22

3.3. Detailed Non-Functional Requirements. 22

Appendix — User Interface Examples. 23

Main Menu Screen: 23

File Menu: 23

Edit Menu: 24

Report Menu: 24

Help Menu: 24

Add Student/Test: 24

Custom Report Screen: 25

Testing Information: 26

Index. 26

 

Table of Figures

Figure 1 - System Environment 6

Figure 2 - Overview of System.. 7

Figure 3 - Load CRN State Chart 23

Figure 4 - Load Student State Chart 24

Figure 5 - Load Test Data State Chart 26

Figure 6 - Enter Student State Chart 28

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 who will use the system, the software developer and persons desiring a model for software development documentation.

<<Note the purpose of this document and the intended audiences. >>

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 academic mainframe computer was chosen as only it had the power to run this program when first created but the mainframe environment is no longer the sole, or even the preferred, environment for such programs today.

Two test versions are supported. One is called The Placement Test and is used for placement into the Calculus sequence. The other is called The Diagnostic Algebra Test and is given to students whose majors do not have a high-level mathematics requirement. It is used for recommendations for the General Education Quantitative Reasoning requirement.

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.

<<This is an overview of the project including need, context and rationale. Specific functionality of the system are below. >>

1.3 Glossary

Administrator

Faculty member in charge of Mathematics Placement System

Archive Database

Students from past years stored for reference

CRN

Course Registration Number — primary key used by the University to identify courses; unique within one academic year

CRN Info File

File with information about mathematics sections offered

Current Database

Active students (incoming freshman)

Current Students

Current grouping of students in one session.

DAT

Diagnostic Algebra Test – used for placement into General Education Quantitative Reasoning courses

Functional Requirements

A detailed list of all the services provided by the system. Information about what the system does not do is also in this category.

Local File System

Files available on PC on which the Placement System resides

Major

Code for academic major/program

MPS

Mathematics Placement System — this system

Non-Functional Requirements

Constraints on product (e.g., performance or memory restrictions) and process (e.g., development paradigm or documentation standards)

Persistent Data

Certain tables retained from one year to another; can be modified; see Supplemental Requirements

Placement System

Mathematics Placement System or MPS

PT

Placement Test – used for placement into the calculus sequence

Recommendation

Analysis of student test result with reference to student's academic major with suggested course placement

Remote File System

Files available on the academic mainframe

Session

Group of students tested at one time

Student

Information about a student including all tests taken

Student Data File

File with information about incoming freshmen from University Database

Student ID

Primary key identifying student

Student Name

Field in last name, first name order

System Databases

Contain all data for current year and archives of previous years

Test

Consists of version number and answer key; at least two versions must be supported; versions are stable during one administration year

Test Data File

File with information from test scan sheets from one session

Test Results

Score on test and all subtests and/or indicated areas of weakness

Transient Data

Information for one academic year

<<This contains all the technical words that the user and the developer must have in common to read this document. >>

1.4 References

<<At the beginning, only the Proposal was listed. As the other documents were created, they were added and the Proposal was removed. >>

1.5 Overview of Document

This document contains two additional chapters. The first (Overall Description) is designed to be understandable to faculty members in the Department of Mathematics (“the customers”). It lists all the functions performed by the system and the constraints under which it is to operate. The second chapter (Requirements Specification) is a list of all the constraints on and functions performed by the system in full detail to define the product fully for the software developer. The two lists of functions are cross-referenced to allow easy comparison.

<<Note that this is not a Table of Contents but a “guide to better reading.” >>

2. Overall Description

<< Note that this would be on a new page. >>

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

Figure 1 - System Environment

<<This diagram was created in ArgoUML using a use case blank, adding actors, and using graphical tools (lines and text boxes for the rest. Most system environments will not be this complicated but the project determines the diagrams. >>

The Mathematics Placement System is embedded in a larger system involving several University systems. In this section, we describe this environment. To reduce risk, we have grafted the new system onto the communications structure of the old system. Therefore, we can develop this system without having to coordinate with the people running the other systems. The new system will be transparent to them. With the old system based on the academic mainframe (Tiger), it was proper that this computer be the sole link to the outside environment. It is anticipated that several of the file transfers described here may soon be removed.

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 (the Remote File System). Student answer sheets are scanned and a text file with the test answers is sent to the Pretest account on Tiger. (Preliminary work has shown that 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 stored as text files in its file system. Originally, all reports were to be transferred to Tiger for printing but the users have requested a change. Most reports are now to be 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 at the end of the summer. An additional text file is mailed from Tiger to the University Database for uploading into the prerequisite-checking software of the registration system.

<<Note that a diagram is essential but is not sufficient. We add whatever text is needed to explain the diagram. The purposes of this diagram are to limit the system (show what is contained and what is external) and to serve as a help to explain the functions of the system below. >>

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.

<<This really needs to be stated here for the customer to understand. >>

Figure 2 - Overview of System

 

<<This diagram was created using a blank use case diagram, adding the actors, and using graphics tools (rounded rectangles, lines and text boxes). >>

Survey Description

<< Note that we use text to explain the diagram again. We use this overview to group the use cases below. >>

Prepare System Use Cases

Use Case: Archive

Diagram:

   

<<Use cases show actor(s) involved in a use case. All actors are mentioned below. >>

Brief Description

The Administrator removes all previous students from the active database and stores non-transient information about tested students in an Archive database. This is done so that the size of the active database remains as small as possible for efficiency purposes.

 

Initial Step-By-Step Description
No precondition needed. If the database is empty, nothing will happen.

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

<<Note that Initial Step-By-Step Description is basically in the form of User action/System response pairs. Two sequential system actions suggest that you are into Design already. >>

See also detailed use case: Archive.

<<Cross-references must be explicit. >>

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

 

See also detailed use case: Initialization

 

Use Case: Modify Persistent Data

Diagram:

   

 

Brief Description

The administrator updates test version, tests, recommendations, etc.

This is not part of the MPS software system as the Administrator is expected to be familiar enough with Access to do this. More details are in the Data Description in the Software Design Description and in the User Manual.

 

Initial Step-By-Step Description

This should be done before loading any data, however, persistent data can be corrected at anytime.

 

  1.  The Administrator opens the Placement.mdb Access database and changes field values directly.

 

See also detailed use case: Modify Persistent Data

 

Load Data Use Cases

Use Case: Load CRN Data

Diagram:
   

<<Use cases show actor(s) involved in a use case. All actors are mentioned below. >>

Brief Description
The use case Load CRN Data File is used 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.

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, thus this operation may be performed several times as needed.

 

Initial Step-By-Step Description

Before this use case can be initiated, the Administrator has already initialized the system.

  1. The Administrator requests a CRN file from the University Database either through the telephone or email.
  2. The University Database deposits the file in the Pretest account on Tiger.
  3. The Administrator transfers the file from Tiger to the local file system through FTP.
  4. The Administrator selects the Load CRN Data option from the File menu.
  5. The system presents the local file directory to the Administrator.
  6. The Administrator selects the correct file.
  7. The system loads the CRN (course and section) data and notifies completion.

See also detailed description of use case: Load CRN Data.

Use Case: Load Student Data

Diagram:
   


Brief Description
The use case Load Student Data File is used by the Administrator to add/update all student data  (identification number, name, college, major, math course enrolled) to the database.

This use case must be done after Load CRN data and before Load Test Data.

The primary key is the student identification number. 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, thus this operation may be performed several times as needed.

If a student has a CRN not known to the system, the unknown CRN is reported to the Administrator.

This use case 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 CRN data.

  1. The Administrator requests a Student file from the University Database either through the telephone or email.
  2. The University Database deposits the file in the Pretest account on Tiger.
  3. The Administrator transfers the file from Tiger to the local file system through FTP.
  4. The Administrator selects the Load Student Data option from the File menu.
  5. The system presents the local file directory to the Administrator.
  6. The Administrator selects the correct file.
  7. The system loads the Student data and notifies completion.

See also detailed description of use case: Load Student Data.

Use Case: Load Test Data

Diagram:
   


Brief Description
The use case Load Test Data File is used by the administrator to add student test results to the database.

It must be done after CRN and Student data are entered.

 

Initial Step-By-Step Description

Before this use case can be initiated, the Administrator has already loaded CRN and Student data.

  1. The Administrator takes the scan sheets to the test scanning facility on campus.
  2. The Tests are scanned and the results file is deposited in the Pretest account on Tiger.
  3. The Administrator modifies the results file into standard format.
  4. The Administrator transfers the file from Tiger to the local file system through FTP.
  5. The Administrator selects the Load Test Data option from the File menu.
  6. The system presents the local file directory to the Administrator.
  7. The Administrator selects the correct file.
  8. The system loads the Test data allowing the Administrator to correct any problems.
    1. 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.
    2. The system notifies completion.
    3. The system reports all students who need to take a second test.
  9. The system notifies completion.

See also detailed description of use case: Load Test Data.

Use Case:  Enter Student

Diagram:

   

 

Brief Description

This use case allows the easy hand entry of an individual student.

 

Initial Step-By-Step Description

Before this use case can be initiated, the Administrator has already initialized the system.

 

  1. The Administrator chooses Add New Student from the Edit menu.
  2. The system provides a form to fill in student information.
  3. Steps 1 and 2 are repeated until done.

 

See also detailed use case:  Enter Student

 

Use Case: Enter Test Data

Diagram:

   

 

Brief Description

This use case allows the easy hand entry of student test results. It is used for students taking tests at other than standard times when using the optical scanner is overkill.

 

Initial Step-By-Step Description

Before this use case can be initiated, the Administrator has already initialized the system.

 

  1.  The Administrator chooses Add Test Grades from the Edit menu.
  2. The system requests a student ID number.
  3. The Administrator provides the ID number.
  4. The system requests the test results and the test version.
  5. The Administrator provides the data.
  6. Steps 2 through 5 are repeated until done.

In step 3, if the ID number is not matched, the Administrator is prompted to enter full student information.

 

See also detailed use case:  Enter Test Data

 

Create Reports Use Cases

Use Case: Create Student List

Diagram:

   

 

Brief Description

The Administrator prints a list of student names and identification numbers. The list is alphabetical by name. This is used for the proctors to assist students while taking the test if they are not sure about their identification number.

<<These comments must be meaningful to the user. >>

Initial Step-By-Step Description

Before this use case can be initiated, the Administrator has already loaded the Student data.

 

  1. The Administrator selects Student List from the Report menu.
  2. The system creates a file containing the list and puts it into the Local File System.

 

See also detailed use case:  Create Student List

Use Case: Report Session

Diagram:
   

Brief Description
The administrator creates a fixed series of reports for all students tested in the current session, that is, all students tested since the last Report Session was performed. The system also reports students who should take an additional test. (See detailed list below.)

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.

See also detailed use case:  Report Session

Use Case: Create Custom Report

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 student 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.

See also detailed use case:  Create Custom Report

Use Case: Create Master Report

Diagram:

   

 

Brief Description

At the end of the summer, there is a fixed set of reports that must be generated. This option generates them all automatically. (See detailed list below.)

 

Initial Step-By-Step Description

Before this use case can be initiated, the Administrator has already initialized the database and added student data.

 

  1. The administrator selects the Master Report option from the Report menu.
  2. The system creates the reports and stored them in the local File System.

 

See also detailed use case:  Create Master Report

Use Case: Create Upload List

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 currently 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.

See also detailed use case:  Create Upload List

As the reports are to be equivalent to those produced by Version 1 of this system, the user is referred to the old User Manual for more details.

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

Report

When Generated

Description

Class List

Create Master Report

For each CRN, report on each student; analysis of class by question and topic.

Individual Student Results

Create Master Report

One sheet per student with full diagnostic information.

Student Scores

Create Master Report

Lists of student names, scores and recommendations listed by school, major, etc.

Students Not Tested

Create Master Report

All students not yet tested.

Student List

Create Student List

Names and ID numbers of all incoming freshmen.

Upload File

Create Upload List

ID and test scores to upload to University Database.

Current Student List

Report Session

Student names with scores by school.

Individual Student Results

Report Session

One sheet per student with full diagnostic information.

Retest Students

Report Session

Students in session who should take other list.

 

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 dialogue boxes for communications. No pull-down menu will have more than seven choices. Unavailable choices will be faded out.

The Help System will display sections of the User Manual, as the users are familiar with using computers.

See Appendix for example screens.

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.

<<This really must be stated here so the user will understand what is intended. >>

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 stored 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. Currently, Archive stores data only. There is no functionality to either use this data or to remove data by year.

The next goal is to remove all usage of Tiger from the system as Tiger will be removed at a future date. 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.

The Help system is currently unimplemented. That is why there is no use case for it.

Version 3.0 is planned to be available in Summer 2002.

<<Be as complete as possible here but do not write science fiction. Record future plans, as they will influence the Design. >>

3. Requirements Specification

<<This section is primarily for the software developer but must also be understandable for the user. The user would use this section to obtain more details. The developer would refer to the previous section to see the context for the fuller descriptions here. >>

3.1. External Interface Requirements

Input File Formats are pre-defined by past usage. This project must use the previously existing file formats so that the system will be transparent to the external actors. The file formats follow.

<<Normally, the SRS would not have as detailed information as this. All fields would be named and described but their size and position would be determined at Design time. However, the constraint on transparency forces us to record these details here and now. Please note that we do not describe the database tables. That is a Design decision. >>

File Format: CRN File

Field

Location

CRN

1-5

Course Number

6-8

Section Number

9-10 (left justified)

Faculty Name

12-31

 

File Format: Student Data File

Field

Location

ID Number

1-9

Name

10-29

CRN

31-35

Major

36-39

School

40

File Format: Test Data File (Raw)

This file is one long line divided logically into 4 line records (without end-of-line markers). The four records have 49 characters each and are logically divided as follows:

Record Number

Field

Location

1

Name

1-20

1

ID Number

33-41

1

Test Version Code

49

2

Test Data

1 - # questions

3

Blank

 

4

Blank

 

File Format: Test Data File (Modified)

The Pascal program Modify on the remote file system converts the raw file into a standard text file with this format:

Record Number

Field

Location

1

Name

1-20

1

ID Number

33-41

1

Test Version Code

32

2

Test Data

1 - # questions

 

3.2. Functional Requirements

<<Note that these are in the same order as the brief descriptions above. Although this is not required, the order should be meaningful, not random. >>

Use Case Name

Archive

Priority

Desired

Trigger

Selection from menu.

Precondition

None.

Basic Path

The system copies data on all tested students to the Archive database.

1.      The data pointer is set to the first student in the database.

2.      If the student is tested, the student name, identification and test results are copied to the Archive database. (The student’s major and math course are not copied.)

3.      The student is deleted from the database.

4.      Steps 2 and 3 are repeated until the database is empty of students.

5.      The system reports completion to the user.

Alternative Paths

None

Postcondition

There are no students in the database.

Exception Paths

None

See Also

Brief description: Archive

Other

 

 

Use Case Name

Initialize (System)

Priority

Essential

Trigger

Selection from menu.

Precondition

Student table is empty.

Basic Path

1.      All non-student transient information is deleted.

2.      Default entries are updated.

3.      User is notified of completion.

Alternative Paths

None.

Postcondition

All transient data is deleted. System is ready to accept new data.

Exception Paths

If the student data is not empty, the operation stops, notifies the user, and returns control to the main screen.

See Also

Brief description: Initialize (System)

Other

 

 

Use Case Name

Modify Persistent Data

Priority

Essential

Trigger

Administrator opens Placement database.

Precondition

Database exists.

Basic Path

Administrator uses database tools to modify persistent data.

Alternative Paths

None.

Postcondition

Placement database is modified as desired.

Exception Paths

None.

See Also

Brief description: Modify Persistent Data

Other

 

 

Persistent Data Items

Item Name

Description

Modification Info

Courses

Numbers and names of math courses

Add new courses or changed names

DAT Recommendations

Question numbers and topics

Must agree with DAT

CRNs

List of CRN, Instructor name, course number and section number

Created by system; may be modified for changes

Defaults

Various default values

See User Manual

Majors

Major number, name, abbreviation and recommendation type

Add new majors or changed information

PT Recommendations

Topics, masks, messages

Must agree with PT

Recommendations

Major types and recommendations

See User Manual

Schools

College and abbreviation

Update as needed

Test Information

Version number, name, answer key and abbreviation of tests

Must agree with tests given

 

 

Use Case Name

Load CRN Data

Priority

Essential

Trigger

Selection from menu.

Precondition

System is initialized.

Basic Path

See State Transition Diagram below.

Alternative Paths

See State Transition Diagram below.

Postcondition

CRN data is in CRN table.

Exception Paths

If file has wrong format, operation is aborted.

See Also

Brief description: Load CRN Data

Other

 

<<When the sequence is complicated consider a state transition diagram to help with the explanation. >>

Figure 3 - Load CRN State Chart

 

Comments on Load CRN State Chart

<<Note that a diagram is very valuable but it needs accompanying text. >>

Use Case Name

Load Student Data

Priority

Essential

Trigger

Selection from menu.

Precondition

CRN Data is loaded.

Basic Path

See State Transition Diagram below.

Alternative Paths

See State Transition Diagram below.

Postcondition

Student data is loaded into Student table.

Exception Paths

If file has wrong format, operation is aborted.

See Also

Brief description: Load Student Data

Other

If there are unmatched CRN’s, the report creators will not work.

 

Figure 4 - Load Student State Chart

Comments on Load Student State Chart

 

Use Case Name

Load Test Data

Priority

Essential

Trigger

Selection from menu.

Precondition

Student Data is loaded.

Basic Path

See State Transition Diagram below.

Alternative Paths

See State Transition Diagram below.

Postcondition

Student Data is updated.

Exception Paths

If file has wrong format, operation is aborted.

See Also

Brief description: Load Test Data

Other

 

 

Figure 5 - Load Test Data State Chart

Comments on Load Test Data State Chart

 

Use Case Name

Enter Student

Priority

Essential

Trigger

Selection from menu.

Precondition

System is initialized.

Basic Path

1.      Administrator chooses Enter New Student from menu.

2.      System provides form to fill in.

3.      Administrator fills in form and pushes enter button.

4.      Repeat 2 and 3 until signaled done.

Alternative Paths

If duplicate ID, student information is replaced.

Postcondition

Student is added to database.

Exception Paths

Operation may be canceled.

See Also

Brief description: Enter Student

Other

 

 

 

Use Case Name

Enter Test Data

Priority

Essential

Trigger

Selection from menu.

Precondition

Student Data is loaded.

Basic Path

See State Transition Diagram below.

Alternative Paths

See State Transition Diagram below.

Postcondition

Student Data is updated.

Exception Paths

None.

See Also

Brief description: Enter Test Data

Other

Use Enter Student use case above.

 

 

Figure 6 - Enter Student State Chart

Comments on Enter Test Data State Chart

 

 

Use Case Name

Create Student List

Priority

Essential

Trigger

Selection from menu.

Precondition

Student data is in database.

Basic Path

1.      Administrator selects Student List from the menu.

2.      System produces an alphabetical list by name of all students’ names and ID numbers. This is placed in a file in the Local File System.

Alternative Paths

None.

Postcondition

File is in Local File System.

Exception Paths

None. (If there are no students in the database, a file with just a heading is produced.)

See Also

Brief description: Create Student List.

Other

Name of file is fixed as only latest version should be stored.

 

Use Case Name

Report Session

Priority

Essential

Trigger

Selection from menu.

Precondition

At least one student test data set has been added since the last time this operation was called.

Basic Path

1.      Administrator selects Report Session from the menu.

2.      System produces files required (see User Manual).

3.      System reports students who should take the other test version to the screen and reports completion.

Alternative Paths

None.

Postcondition

The reports are stored in the local file system.

The system is reset for the next session.

Exception Paths

If a student CRN is not matched in the CRN data, the operation aborts. The partial file created can be scanned to see where it ended and to correct the database.

See Also

Brief description: Report Session.

User Manual for description of reports.

Other

A session is all the student test information added since the last Report Session operation (or from the beginning if no prior operation).

Each file produced is uniquely identified as to contents (by prefix) and version (by number). It is expected that all reports generated will remain available for the use of the mathematics faculty.

 

Use Case Name

Create Custom Report

Priority

Essential

Trigger

Selection from menu.

Precondition

The system is initialized.

Basic Path

1.      Administrator selects Create Custom Report rom the menu.

2.      System presents a form to create a filter for the report.

3.      Administrator chooses desired report characteristics.

4.      System produces report and reports completion.

Alternative Paths

None.

Postcondition

The report is stored in the local file system.

Exception Paths

None.

See Also

Brief description: Create Custom Reports

Other

Each file produced is uniquely identified as to contents (by prefix) and version (by number). It is expected that all reports generated will remain available for the use of the mathematics faculty.

 

Use Case Name

Create Master Report

Priority

Essential

Trigger

Selection from menu.

Precondition

There is test data in the database.

Basic Path

1.      Administrator selects Create Master Reports from the menu.

2.      System produces files required (see User Manual).

Alternative Paths

None.

Postcondition

The reports are stored in the local file system.

Exception Paths

None.

See Also

Brief description: Create Master Reports

User Manual for description of reports.

Other

Normally done once at the end of the entire testing process just before the start of the semester.

 

Use Case Name

Create Upload List

Priority

Essential

Trigger

Selection from menu.

Precondition

Test data is in the database.

Basic Path

1.      Administrator selects Create Upload List from the menu.

2.      System produces files required (see User Manual).

Alternative Paths

None.

Postcondition

The file is stored in the local file system.

Exception Paths

None.

See Also

Brief description: Create Upload List

Other

 

 

 

3.3. Detailed Non-Functional Requirements

Hardware:

The system needs an IBM compatible Pentium-based PC with standard or better keyboard, mouse and monitor. A color monitor is assumed but not required. It also needs sufficient main memory to run the version of Access used and at least 4M of available disk memory to store the program and databases.

Operating System:

Windows that can support Access version used.

Software Needed:

Access 98 or better needed. Visual interface provided by executable file.

Performance:

No noticeable delays in performance — see section 2.4.

<<Cross-reference rather than repeat. Stating the same thing in two places can cause an inconsistency if one is updated. >>

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.

Documentation standards:

Each document follows departmental standards.

Appendix — User Interface Examples

Main Menu Screen:

 

This is what the screen might look like during the middle of the testing process.

 

File Menu:

Note that New is unavailable, as the current students have not been archived. We have already loaded of CRN and Student files so all the Loads are available.

 

Edit Menu:

For details on these two choices, see below.

Report Menu:

This is the basic report menu. Upload List is unavailable until Master Report is run. For the Custom Report options see below.

Help Menu:

This is a minimal Help System that accesses the User Manual.

Add Student/Test:

This can be used directly to add a student manually.

When a valid student ID is inputted, the student name appears on the screen. If a valid ID is not entered, the Add a New Student screen above is available. After typing in the answers, buttons pop up to allow the user to choose the test version.

Custom Report Screen:

These are the options to design a report. Although the Registrar Upload is available here, it is also available directly from the Report Menu.

Testing Information:

When adding test scores, if a student scores very high on the easier test or very low on the harder test, s/he is asked to take the other test also for diagnostic purposes. Most students do this in response to an announcement during the testing session. This reports on those who do not but should do so.

Index

<<Place here. >>

 

© 2001 by Dennis Martin

Branch to the Project Documentation Standards Homepage

Branch to Martin’s Homepage