Transcript Analyzer – Requirements Analysis Document



Transcript Analyzer – Requirements Analysis Document

Authors:

Duc Duong (duc178@)

Jason Morris (jason.c.morris@)

Nicholas Lloyd (nlloyd@)

Introduction

1. Purpose of the system

A central task that a student performs when planning for their own graduation is the analysis of their transcript records and how the courses they have taken satisfy the graduation requirements set by their program of study in the University. By evaluating where they are lacking with respect to graduation a student can better plan the future of their academic career in order to graduate in a timely manner. Faculty Advisors to these students also perform this task in order to better understand the current needs of their advisees. However, manually checking and rechecking transcript records against written requirements within University catalogs is a tedious and time consuming task. Additionally, graduation requirements change within each department and program from time to time, adding another level of complication. Some of the systems used by the registrar require automatic evaluation of a student’s transcript for assigning warnings to different students in danger of not graduating or losing financial aid. In these situations the transcript needs to be evaluated through limited requirements simply to determine how many requirements are missing or, more frequently, how many classes have been failed (No Record, NR).

The purpose of the Transcript Analyzer is to provide both students and faculty advisors with a tool that will automatically evaluate a student’s transcript using current or previous graduation requirements. This evaluation should show the user what requirements have been satisfied for the student in question, and for those requirements unsatisfied information regarding what credits and/or courses are missing. The Transcript Analyzer should also allow University administrators to create, review, update, and delete graduation requirement sets for the different programs and majors.

2. Scope of the system

The Transcript Analyzer is a reporting tool only for performing detailed and unofficial analyses of student transcripts against graduation requirements. They are unofficial precisely because regardless of the accuracy of their reports, they should not supersede the authority of the University officials directly responsible for evaluating students for graduation. As a reporting tool on a given student’s academic progress its intended non-administrative users include students and any faculty member who is either an advisor or requires special access to the student’s progress information, as is the case for ROTC officers. Administrative access to create, modify, and delete graduation requirements within the system is intended for University personnel who are responsible for performing the formal degree evaluations prior to a student’s graduation.

3. Objectives and success criteria of the project

The objectives of Transcript Analyzer are to:

• Provide advisors and students a fast, adequate, accurate, and reliable report on the status of a student toward his/her undergraduate degree at Worcester Polytechnic Institute based on a given transcript and a set of degree requirement rules.

• Enable the registrar office to manage the set of degree requirement rules easier and more efficiently through a simple and friendly interface. 

The success of the Transcript Analyzer project is based on the ability to minimize the time and effort needed to manage degree requirement rules, as well as to help professors save time on advising their students. The future system has to provide these advantages in order to be accepted and replace the current one.

4. Definitions, acronyms, and abbreviations

A transcript is a listing of all the courses and projects a student has completed or failed to complete for University credit over the period of their studies. A transcript is analyzed, or “audited,” by applying a set of constraints represented as program graduation requirements (and departmental requirements) to the information contained within the transcript. If all constraints are satisfied by the courses and projects completed by the student, as detailed in the transcript, then the student is allowed to graduate. Any unfulfilled constraints indicate where the student is lacking in their academic career.

A program graduation requirement, which will be referred to simply as a Program, consists of the following:

• A collection of Areas representing groups of similar requirements, such as globally applied University requirements and Major specific requirements

• An Area representing a collection of Major specific requirements may be associated with additional collections of requirements called Groups which represent Concentrations within a Major area of study.

• Areas and Groups consist of Rules which are conditional (AND/OR) relationships between courses provided by the University as well as a number indicating how many credits (in other words how many valid courses) are required to satisfy the Rule.

A transcript is complete if it satisfies all requirements for the student’s specific program of study, incomplete if otherwise. When a transcript is incomplete, there is a set of uncompleted areas, together with counts of the degree to which these individual areas have been partially satisfied based upon credits satisfying the requirement areas.

Additional terms include:

• Course numbers – human readable unique identifiers for each course offered, they consist of…

o 2 letter program code – for instance CS for Computer Science.

o 4 digit course number – four numbers to further specify the course, the first of which indicates the level of difficulty (from 1 to 4) of the course.

• Course Registration Number (CRN0 – special serial numbers used internally for the registrar that represent specific courses.

5. References

The current system employed by WPI for transcript analysis, among other things, is the Banner system by Sungard (). In particular the transcript analysis portion is a part of the Banner Student component in the Banner system (). Documentation is available online for this system and its different components.

6. Overview

Current system

The current transcript analysis (also referred to as degree audit) system used by WPI is Sungard’s Banner system (see the References section). This system permits the construction of rule representations of graduation requirements. Rules are constructed using simple conditional logic (AND, OR, NOT operations) with course numbers stored within the system. Similar rules are grouped together into collections known as groups and areas (see the Definitions, acronyms, and abbreviations section). Groups and areas are connected with Programs which represent the different degree programs offered by the University. Records of previous requirement sets from older University catalogs are updated by directly copying old records, updating the requirements that have changed, and saving the modified copies as new records.

Proposed system

1. Overview

In order to develop an improved Transcript Analyzer tool, the new implementation must be built upon the current Banner system. While the Banner system offers a variety of functionality, appropriate interfaces to allow more powerful rule editing and report presentation must be developed. Additionally, rule development in the new system must use more advanced rule representations beyond simple conditional logic.

2. Functional requirements

The Transcript Analyzer supports three types of users:

• The student should be able to see analysis reports of their own transcripts as applied to different program requirements, by year or major. Only one report may be received at a time by the student.

• The advisor should be able to see the same reports a student can see for any student they currently advise. Advisor users include faculty as well as ROTC officers that need to see reports on the progress of their students.

• The administrator should be able to create, modify, delete, and view requirements within the system as well as produce the same reports that the student user can to assist in the formal degree audit process.

o New requirement sets are associated with the course catalog for a particular academic year, identifying what University set requirements the requirements written in the system represent.

o Certain requirement sets are identified as being “global” indicating that they are University requirements applied to all degree programs while other requirement sets are “local” to a particular degree program.

For the report capabilities of the Transcript Analyzer, available to all three user types, the system must receive information regarding who the student is in order to obtain their transcript data, and what requirement sets to apply to their transcript. The latter consists of an academic year and a program of study (i.e. major). The analyzer then performs the analysis by applying the rules contained within the requirement sets to the transcript information, generating a report detailing what requirements have been satisfied and what requirements have not been satisfied. For unsatisfied requirements the system details in its report what rules have not been satisfied by the current transcript. These unsatisfied requirements are displayed by area and, where applicable, group (see Transcript Analyzer Report mockup screenshots, Figures 2 and 3 in section 3.4.2.1).

The report presented to the requesting user presents a brief summary of information regarding the student and the specified area of study as well as overall credits completed and total credits required at the top of the report. The rest of the report is a listing of each requirement section, from global University requirements to more specific program requirements, detailing what courses that have been taken satisfy which condition within a rule of the requirement and what courses are missing for unsatisfied conditions. Additionally each section will show the number of course credits required as well as the number completed, thus the user will be able to see by the unsatisfied conditions what courses they can choose from to satisfy the missing conditions.

The report system is constrained for the advisor user such that the advisor is limited to only selecting programs of study for a given student that they are qualified to advise. The student user, however, may select any program of study in order to simplify instances where a student user may wish to change programs.

The administrator user is the only user capable of creating, viewing, modifying, and deleting requirement rule sets. As such a special Rule Editor interface is available to the administrator user where said user may choose to either view an existing requirement rule set by choosing the desired academic given year, program of study, and associated requirement set (see section 3.4.2.2 for details on rule editing and the Rule Editor interface). For globally applied University requirements only the academic year is necessary to bring up the list of all global requirement sets. For all other requirement sets the program of study is necessary input. With a retrieved requirement set the administrator may edit the current set, copy the set, or delete the set from the system. Creating a new set does not require the user to request a previously constructed set; they just use the editor interface and specify a name and academic year for their new set.

The copy function for the Rule Editor is available in order to simplify the updating of requirements for new academic years where the requirements of the previous year differ by a small margin. In this situation it is easier to copy the previous requirements and then to edit the rules and the academic year for the copy in order to produce the new requirement set.

3. Nonfunctional requirements

1 Usability

General usability is a high-priority attribute of the Transcript Analyzer. For all actors who are also users of the system, particular attention will be paid to the following features and conditions.

1 Assumed user expertise

Users are not assumed to be expert computer users nor even technically competent computer users. Therefore, the application will not require special knowledge of fields including but not limited to: programming languages, computer science theory, database querying, database administration, or internet programming. It is expected that a user can access and manipulate a modern web browser and manipulate common windowing GUI elements such as text boxes, drop-down lists, radio buttons, etc. It is also assumed that the user can navigate a standard windowing file system and be able to perform basic operating system tasks including but not limited to opening a file, printing a file, locating a file, and navigating to a web page.

2 Interface standards

The user interface shall be minimalist in design, meaning that it will use the minimum number of graphical user interface (GUI) elements and human-computer interaction (HCI) principles to produce a transcript analysis. The style and color scheme shall conform to the other currently installed Banner applications so that continuity of presentation is maintained.

The interface will be renderable and manipulable without any additional plugins, controls, or other downloadable components (i.e., Flash, Java Applets, ActiveX controls, etc.). The user will not be burdened with the overhead of downloading large JavaScript libraries to the client browser, consequently client-side scripting will be used sparingly. If client-side scripting is required, care will be taken to avoid performance degradation on the lowest common denominator client system (see hardware standards). Any client-side scripting that places a performance tax upon the client (i.e., AJAX, DoJo, etc.) will be carefully scoped to minimize the effect.

The interface itself will be determined by the browser in which the application is rendered. Obviously, there will be some variation among the supported browsers.

SunGard Higher Education has completed testing with the following browsers:

Table 1 Supported browsers in Banner 7.0[1]

|Banner Version |Browser Comments |

|Internet-native Banner 7.0[2] |Microsoft Internet Explorer 6.0 (with Oracle JInitiator 1.3.1.18) |

| |Netscape 7.0x (with Oracle JInitiator 1.3.1.18) |

| |Macintosh client - Safari 1.2 (Sun plug-in 1.4.2) for Mac OS X (1.4 JDK); must use Forms |

| |patch set patch2 (9.0.4.2) |

|Internet-native Banner via the Luminis|Microsoft Internet Explorer 6.0 |

|Portal |Macintosh client - Safari 1.2 (Sun plug-in 1.4.2) for Mac OS X (1.4 JDK); must use Forms |

| |patch set patch2 (9.0.4.2) |

|Self-Service Banner 7.0 |Microsoft Internet Explorer 6.0 |

| |Netscape 7.01 |

| |Netscape 7.2 |

| |Mozilla 1.7 |

| |Microsoft Internet Explorer 5.2 for Macintosh OS X |

| |Macintosh client - Safari 1.2 for Mac OS X |

|Self-Service Banner via the Luminis |Microsoft Internet Explorer 6.0 |

|Portal |Netscape 7.2 |

| |Macintosh client - Safari 1.2 for Mac OS X |

|At this time, the following browsers are not supported: |

| |

|Browser Java for INB |

|SUN Java Plugin/WebStart for INB |

|AOL's repackaged browser |

|LINUX desktop browsers |

|Other non-Windows browsers |

3 Online help and documentation

The system shall feature an online, HTML-based help system in accord with existing Banner stylistic guidelines (See Banner help documentation for an example). The online help shall be created and compiled using a standard help authoring tool such as JavaHelp, RoboHelp, or MS HTML Workshop. Help shall implement search by index, search by keyword, and search by category. All help and end-user documentation shall be printable in PDF format. The PDF format for the documentation shall allow copy and paste functionality so that users may create their own custom annotations and sub-documents.

Online documentation in PDF form shall be available outside of the Banner context so that end-users are not required to log into Banner in order to view them.

2 Reliability

The general ability of the system to perform its required functions under specified conditions (during normal operation) and over a given time period is described below.

3 Reliability, availability, and robustness

Under normal operating conditions, the system will have a reliability, or meantime until failure, equal to or greater than the meantime for the server hosting the system to require rebooting. That is, the system is expected to have at least 3-sigma (99.99 %) uptime. It is expected the system will be continuously available, except for routine maintenance periods to be specified later. Before these maintenance periods, all system users and administrators shall be notified, preferably by email, that the system will be unavailable for use.

Times of peak use often coincide with times of greatest need for analysis (i.e., at the end of Spring term/semester of any given year). During times of peak use, the system should accommodate the theoretically largest number of concurrent users (i.e., The sum of all possible users, administrators, advisors, etc. simultaneously trying to access the system plus some margin of error factor).

In all cases, the system will robustly reject incorrect inputs and selections to preserve data integrity. All user interfaces will have both client-side and server-side form validation as well as database validation in the case of new data being added to the system (i.e. new auditing rules.).

1 Fail-over restarting

If the server hosting the application requires a reboot, then the system shall send an email notification to all affected users, administrators, etc. that the system will be restarted in an stipulated time period. System administrators shall monitor the system for software failures that require the application to be reloaded. If this situation occurs, the system administrators shall issue a similar warning for a hardware reboot.

2 Fault tolerance

In general, the system shall have the ability to gracefully recover from non-fatal faults (i.e., incorrect data input, wrong button presses, etc.) without causing an application restart. In all cases, the system should restore its previous state before the error occurred and return the user to the GUI view that was visible before the error. Users will not need to exit the system and re-enter for any but the most unforeseen and severe errors.

3 Safety requirements

The system is not required to be mission-critical because the loss of life, property, or other valuable items will not result if the system (either the software or its hardware) fails catastrophically at any time.

4 Security requirements

Though the system is not mission-critical in the purest sense, it does require a secure and encrypted login procedure and mechanism to preserve the confidentiality and privacy of users. Only systems administrators and department administrators are allowed to edit, update, modify, or delete auditing rules. Under no circumstances are students or advisors to be allowed to edit, update, modify, or delete auditing rules. All auditing rules are to be stored on a secure database server with restricted access privileges. Login shall use a typical username and password combination identical to the current WPI Banner requirements. Password fields on the login form shall be encrypted.

4 Performance

Web applications have more liberal performance ranges than native client (fat client) applications. These are enumerated below.

1 Responsiveness

The system will respond to all requests in less than or equal to the time to execute the most complex analysis at peak use time and at peak load. An estimate of this time is fifteen (15) seconds. Actions that do not involve initiating an analysis and that are simply input/output or communications with the application server should be on the order of less than or equal to five hundred (500) milliseconds.

2 Time-critical tasks

A user will not be kept waiting for more than 30 seconds to complete an analysis. If the system cannot fulfill a request in that time, the system will notify the user that that system has become busy and will prompt the user to re-submit the request. If an audit rule editing session is opened, it shall timeout in 30 minutes if the system does not detect any activity. If an analysis session is opened, it shall timeout in 30 minutes if the system does not detect any activity.

3 Concurrent users

The system shall accommodate a number of concurrent users equal to the current number supported by the BANNER system.

4 Data store

The data store shall remain Oracle-based as per the specifications of the current BANNER system.

5 Maximum latency

Latency is a function of the pooling used to connect to the database, therefore the system will employ dynamic database connections. Complex data processing will be done on the database server rather than in application code as much as possible to leverage existing database optimizations.

5 Supportability

It is vital to have a system that can scale as WPI's needs evolve and grow. Therefore, it is necessary that the system have the following capabilities.

1 Extensions and augmentations

The system will be able to support augmentations and extensions via some high-level language, preferably Java, via a public API. The system administrators will work with the system users to determine which APIs are likely to evolve rapidly and to ensure that those are engineered in the most flexible way. A key component of this initiative is the BANNER API itself, which has only been made public since version 7.0. The system administrators will work closely with the BANNER vendors to ensure that system developers have access to sufficient technical documentation and vendor expertise to assist them in their work.

2 Maintaining and updating system

It is recommended that the oversight for the transcript analysis system rest with a university-level committee, that in addition to administering and controlling the general university graduation requirements, also administers and controls the system updates of the various WPI departments. Furthermore, each department shall form a committee headed by a chair whose duty it will be to collate and finalize graduation rules for that department. The chair will then update those rules in the transcript analyzer system or designate an agent who is more familiar with the system's user interface. The university-level administration will perform annual audits of the overall university rule base to ensure data integrity as well as term-by-term partial audits and reminders to individual departments to test and validate their own rule bases before the printing of the next course catalog.

3 Portability to other platforms or hardware

It is not a requirement at this time that the system be portable to another platform or hardware set.

6 Implementation

1 Hardware constraints

The general system has no hardware constraints at this time. The client-side interface will be displayable on all modern personal computer platforms.

2 Maintenance constraints

There are no general maintenance constraints at this time.

3 Testing constraints

There are no general testing constraints at this time.

7 Interface

1 System integration with existing systems

The transcript analysis system is highly constrained by the existing BANNER system, and it will be made to integrate with BANNER's existing interfaces and API. There is no anticipation that this requirement will change in the foreseeable future.

2 Data imported/exported

BANNER is a closed system with regard to data input and output due to the nature of the personal data that it holds. All import and export functionality will be securely password protected and only administrative-level access will be granted. Non-FERPA sensitive data will have a batch processing mechanism for upload and download to be specified at a later date.

3 Supported client standards

All client standards are governed by the existing look and feel of the BANNER system. The appearance of the system to users via the client interface should be transparent with respect to the existing BANNER system (i.e., placement of common controls, color scheme, etc.)

8 Operation

1 System management

The system shall be managed at the university level by the current managers of the BANNER system. Individual WPI departments shall be responsible for creating, managing, and uploading their own graduation rules to the main system.

2 System troubleshooting and support

The current WPI help desk shall be given instruction and documentation to provide support for the new transcript analysis system to the WPI community. Online help will be integrated into the system's user interface. The university shall schedule one in-house training session per term to educate new administrators on the correct procedures for creating, managing, and uploading rules.

9 Packaging

1 Installation procedure

The installation shall consist of deploying a Java *.JAR or *.WAR file containing the transcript analysis code to the BANNER server. It is expected that BANNER administrators are familiar with this procedure.

2 Installation time constraints

There are no installation time constraints at this time.

3 Concurrent access availability

If the system becomes unavailable due to application error, server error, or other errors within BANNER, the system shall generate log entries that indicate the error and its root cause. If possible, any clients that are still in communication with the system shall be notified either through the client interface or via email that the system has become unresponsive and that that actions are being taken to correct the problem. Consequently, an email will be sent to the system administrators notifying them of the problem.

In general, the system shall be designed so as to accommodate the peak server load at the peak usage time as designated elsewhere in this document (See Performance).

10 Legal

1 Legal access

Only authorized WPI administrators, staff, and designated faculty shall have access to the personal data and rule administration functions of the transcript analysis system.

2 Licensing

Since BANNER is already a licensed application at WPI and this transcript analysis system is proprietary sub-system, there should be no further general licensing issues.

3 Intellectual property

All inventions, devices, and algorithms used in transcript analysis system are property of WPI. All intellectual property developed as a result of this project are copyrighted by WPI.

4 Royalties or fees for proprietary components

Should a rule based approach be used, the de facto standard for rule engines implemented in Java is Jess. Jess is proprietary software that is licensed by Sandia Corporation, and a commercial license for its inclusion in the transcript analysis system would need to be negotiated and purchased.

5 Family Educational Rights and Privacy Act (FERPA) constraints

Under all circumstances, the FERPA guidelines and requirements shall be enforced by the administrators of the transcript analysis system. No person shall have access to confidential student information without the express permission and foreknowledge of the university-level administration and the department-level administration involved. The system shall provide tie-ins to the BANNER system to allow senior systems administrators the ability to grant various levels of access rights to those requesting such rights.

4. System models

11 Use Case Model

[pic]

Figure 1: Use Case Diagram of the Transcript Analyzer

|Use case name |Evaluate Transcript |

|Participating actor |Initiated by Advisor or Student |

|Flow of events |Step |Action |

| |1 |The Advisor (or Student) selects “Evaluate Transcript” function for a student |

| | |The Advisor (or Student) selects a desire degree |

| |2 |DES loads the transcript and associated rules |

| | |Initiate “Retrieve Transcript” |

| | |Initiate “Retrieve Rule” |

| |3 |DES shows a report on current statues of the student toward the selected degree |

|Entry |The Advisor (or Student) logged in to DES |

|condition | |

|Exit success condition |The Advisor (or Student) receives a report on the given transcript |

|Exit failure condition |The Advisor (or Student) receives a message indicating why DES cannot retrieve the needed rules OR |

| |The Advisor (or Student) receives a message indicating why DES cannot retrieve the transcript |

|Quality requirements |DES has to provide a accurate evaluation |

| |DES has to show a missing courses or requirements |

|Use case name |Retrieve Transcript |

|Participating actor |Initiated by Advisor or Student |

|Flow of events |Step |Action |

| |1 |DES receives a request to load a transcript |

| |2 |DES retrieves the transcript, changes state to ready, and waits |

|Entry |The Advisor or Student logged into DES and initiated “Evaluate Transcript” |

|condition | |

|Exit success condition |DES changes the state to ready |

|Exit failure condition |DES could not retrieve the transcript |

|Quality requirements | |

|Use case name |Create Rule |

|Participating actor |Initiated by Registrar |

|Flow of events |Step |Action |

| |1 |The Registrar activates the Create Rule function |

| |2 |RMS prepares a list of courses for the new rule and displays a rule definition form |

| | |Initiate “Retrieve Course” |

| |3 |The Registrar defines a new rule and then submits the form |

| |4 |RMS receives form and validates the new rule. |

| | |Initiate “Validate Rule” |

| |5 |RMS saves it and sends confirmation message back to the Registrar |

|Extensions |Step |Branch Action |

| |5a |RMS takes the Registrar back to step 3 and shows a warning message if the new rule conflicts with |

| | |some existing rule |

|Entry |The Registrar logged in to RMS |

|condition | |

|Exit success condition |The Registrar receives a confirmation message that a new rule was created |

|Exit failure condition |The Registrar receives a message indicating RMS cannot retrieve the list of courses OR |

| |The Registrar receives a message indicating why RMS cannot save the rule even it was valid |

|Quality requirements |RMS has to present a rule definition form that allows the Registrar with no knowledge of programming skills and |

| |rule description languages to define the rule. |

|Use case name |Validate Rule |

|Participating actor |Initiated by Registrar |

|Flow of events |Step |Action |

| |1 |RMS receives a request to validate a rule |

| |2 |RMS retrieves all associated rules and compares each of them with the input rule |

| | |Initiate “Retrieve Rule” |

| |3 |RMS prepares the validation result, changes state to ready, and waits |

|Entry |The Registrar logged in to RMS and initiated either “Create Rule”, “Update Rule”, or “Copy Rule” |

|condition | |

|Exit success condition |RMS changes the state to ready |

|Exit failure condition |RMS could not retrieve one or some rules |

|Quality requirements |RMS has to show all the detail conflicts if exist. |

| |RMS has to find out if the input rule is implied by one or some existing rules or reverse |

|Use case name |Retrieve Rule |

|Participating actor |Initiated by Registrar, Advisor, or Student |

|Flow of events |Step |Action |

| |1 |RMS receives a request to load a rule |

| |2 |RMS retrieves the rule from database, changes state to ready and waits |

|Entry |The Registrar logged in to RMS and initiated one of the following use-cases “View Rule”, “Update Rule”, “Copy |

|condition |Rule”, or “Create Rule” |

| |The Advisor or the Student logged in to DES and initiated use-case “Evaluate Transcript” |

|Exit success condition |The rule was retrieved and the state changed to ready |

|Exit failure condition |RMS could not retrieve the rule and changed its state to fail with an error message |

|Quality requirements | |

|Use case name |Retrieve Course |

|Participating actor |Initiated by Registrar |

|Flow of events |Step |Action |

| |1 |RMS receives a request to load a course |

| |2 |RMS retrieves the course, changes state to ready and waits |

|Entry |The Registrar logged in to RMS and initiated either “Create Rule” or “Update Rule” |

|condition | |

|Exit success condition |RMS changes the state to ready |

|Exit failure condition |RMS could not retrieve the course and changed its state to fail with an error message |

|Quality requirements | |

|Use case name |View Rule |

|Participating actor |Initiated by Registrar |

|Flow of events |Step |Action |

| |1 |The Registrar selects a rule to view |

| |2 |RMS gets the rule definition and describes it in a human understandable method |

| | |Initiate “Retrieve Rule” |

|Entry |The Registrar logged in to RMS |

|condition | |

|Exit success condition |The Registrar sees the rule described in a human understandable method |

|Exit failure condition |The Registrar receives a message indicating RMS cannot retrieve the rule |

|Quality requirements |The rule has to be described in some meaningful sentences |

|Use case name |Copy Rule |

|Participating actor |Initiated by Registrar |

|Flow of events |Step |Action |

| |1 |The Registrar activates Copy Rule function |

| |2 |RMS presents a form with a list of original rules and a list of destinations |

| |3 |The Registrar selects a set of rules and destination |

| |4 |RMS retrieves rules from the source and validates them at the new location |

| | |Initiate “Retrieve Rule” and “Validate Rule” |

| |5 |RMS saves rules to the new location |

|Entry |The Registrar logged in to RMS |

|condition | |

|Exit success condition |The Registrar receives a confirmation message that rules were copied |

|Exit failure condition |The Registrar receives a message indicating that there is no rule to copy OR |

| |The Registrar receives a message indicating why RMS cannot copy rules to new location because of conflict with |

| |current rules there OR |

| |The Registrar receives a message indicating why RMS cannot copy rules even there is no conflict |

|Quality requirements |RMS has to allow the Registrar to select a set of rules by filtering them by year, department, or major |

|Use case name |Update Rule |

|Participating actor |Initiated by Registrar |

|Flow of events |Step |Action |

| |1 |The Registrar selects a rule to modify |

| |2 |RMS gets the rule, prepares a list of courses, and displays a rule definition form with the specified|

| | |rule information |

| | |Initiate “Retrieve Rule” |

| | |Initiate “Retrieve Course” |

| |3 |The Registrar modifies the rule and then submits the form |

| |4 |RMS receives form and validates the rule. |

| | |Initiate “Validate Rule” |

| |5 |RMS saves it and sends confirmation message back to the Registrar |

|Extensions |Step |Branch Action |

| |5a |RMS takes the Registrar back to step 3 and shows a warning message if the modified rule conflicts |

| | |with some existing rule |

|Entry |The Registrar logged in to RMS |

|condition | |

|Exit success condition |The Registrar receives a confirmation message that the rule was modified |

|Exit failure condition |The Registrar receives a message indicating RMS cannot retrieve the list of courses OR |

| |The Registrar receives a message indicating why RMS cannot retrieve the rule OR |

| |The Registrar receives a message indicating why RMS cannot save the rule even it is valid |

|Quality requirements |RMS has to present a rule definition form that allows the Registrar with no knowledge of programming skills and |

| |rule description languages to define the rule. |

|Use case name |Delete Rule |

|Participating actor |Initiated by Registrar |

|Flow of events |Step |Action |

| |1 |The Registrar selects a rule to delete |

| |2 |RMS asks the Registrar to confirm the deletion |

| |3 |The Registrar decides to delete |

| |4 |RMS deletes the rule and sends confirmation message back |

|Entry |The Registrar logged in to RMS |

|condition | |

|Exit success condition |The Registrar receives a confirmation message that the rule was deleted |

|Exit failure condition |The Registrar decides not to delete the rule in step 2 OR |

| |The Registrar receives a message indicating why RMS cannot delete the rule |

|Quality requirements | |

12 User interface

1 Transcript Analyzer Report Screen

[pic]

Figure 2: Upper portion of the Transcript Analyzer Report, adapted from the current Banner system report to be more usable.

Since the new Transcript Analyzer will be built upon the current Banner system, it is reasonable to expect the interface components to be similar in format but improved in content. Figure 2, displayed above, depicts a mockup of the first portion of a Transcript Analysis Report for the new system showing basic information regarding a given student’s activity. This information includes the student’s chosen Program, requirements set to evaluate against (based upon catalog term), when the transcript data was last updated, and current credit hour totals compared against required credit hour totals.

[pic]

Figure 3: Areas portion of a Transcript Analyzer Report, adapted from the current Banner system report to be more usable.

While the upper portion of a report will display basic information regarding the student, their program, and the requirement set being applied in this analysis to their current transcript, the power of a Transcript Analyzer Report is in the sections that follow. Figure 3 above shows a mockup of a potential Computer Science student’s Transcript Analysis Report. The report is broken up into a listing of the different Area requirement sets of varying complexity. Every area section shows in its title a color coded label indicating whether or not the requirement area has been satisfied. If the area has been satisfied then the details for the course taken by the student that satisfies this requirement is recorded in the table, along with a grade if the course has been completed (as opposed to courses currently in session). Depending upon the specificity of the requirement set, a section of each Area table, the Required Courses section, shows what courses can be taken to satisfy this requirement. Note that the last Area displayed in the figure is only partially satisfied, thus showing the single course of 5 total required that satisfies this requirement area.

3.4.2.2 Rule Editor Interface

3.4.2.2.1 Using Rules, Rule Engines, and Rule Editing

In general, a rule is a compact representation of a set of logical conditions and the actions to be performed when those conditions are met. Rules are similar to procedural IF-THEN statements, but they are never called in a procedural or algorithmic manner. Rather, rules operate automatically and opportunistically on data as they are made available to a rule-based program.

When, in the course of analyzing the business logic needs for a given software project, it becomes apparent that decisions will be made by many complex modules, classes, or other constructs using copious IF-THEN type code, the use of a rule-based approach makes good sense. The maintainability and scalability of business logic that depends upon such IF-THEN code is well-documented to be poor at best. In all cases, if changes to the business logic need to be made, source code must be checked out of source control, edited, tested, and then checked back in. This cycle is time-consuming, it requires a programmer to edit the code, and has a high probability of introducing side effects due to code dependencies.

For these reasons, rules are well-suited for the implementation of the general transcript analysis functionality. Changes can be made on-the-fly as production code is running. Rules can be edited by non-programmers. Most importantly, rules are generally independent of one another, and with good programming practice their effects can be localized to well-defined modules and data namespaces. Such an implementation would most likely be enabled by an existing component technology that provides rule-based programming support. This component or sub-system technology would then be transparently embedded in the main transcript analyzing system. Such a sub-system would be composed of a:

• Rule engine: a software component capable of applying rules to data.

• Rule base: a database of rules that represents the knowledge for analyzing a transcript.

• Rule manager: a software component that acts as the interface between the rule base and those who create, edit, update, and delete rules.

The general problem of allowing plain-English create, edit, update, and delete functionality for any given rule in a particular rule language is a non-trivial programming project. Most implementations begin with some sort of restricted language – a subset of the complete programming operations from which one can form rules in a given formal rule language[3]. This restricted language is implicitly enforced by the rule manager GUI.

A full treatise on rules, rule-engines, and rule-based declarative programming is beyond the scope of this document. Those who require more details are recommended to read the references listed in the foot notes to this section. What follows is a brief description of possible rule types, editing interfaces, and other issues encountered while analyzing a given transcript for compliance.

3.4.2.2.2 Implementation issues

The holy grail of all rule-based implementations is that the rules will be creatable and manageable by non-programmers. While this goal is noble and understandable, there are significant practical problems that must be overcome to allow non-programmers to construct rules outside of a formal rule language and in plain language. It is impractical to attempt to expose the richness of a given computer programming language via a finite set of grammars and productions rendered via a finite set of GUI components. In the limit, one simply ends up creating a general integrated development environment and unmanageable amount of complexity. However, it is reasonable to expose a subset of a rule based language via a GUI that regulates what kinds of rules can be constructed.

In general, the more complex the rule, the more difficult it will be to map its plain language source to its rule language equivalent. As an example, consider the following plain language rule:

Choose any five (5) courses from {BB, BME, CE, CH,CHE ECE,ES,GE,ME,PH} where at least three (3) are from { BB, CH,GE, PH } and two (2) are from { BB|CH|GE|PH }

In Figure 4, observe what happens when one encodes the above plain language rule in Jess:

(defrule SCIENCE::check-for-general-science-requirement

"General set BB, BME, CE, CH, CHE, ECE, ES, GE, ME, PH"

?ctrl ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download