Problem
statement for a Graduation Planning System
|
Date |
Version |
Description |
Edited
by |
|
September
16, 2003 |
1.0 |
Initial
Draft – Team input only |
Lauren
Toffolo, PMP |
|
September
21, 2003 |
2.0 |
Client
input – Additional team input. |
Lauren
Toffolo, PMP |
|
September
26, 2003 |
2.1 |
Changes
from use case brainstorming session.
See team meeting notes for 9/26.
Added filename to document footer. |
Lauren
Toffolo, PMP |
|
October
3, 2003 |
3.0 |
Updates
features included and excluded from scope based on client ranking. |
Lauren
Toffolo, PMP |
|
October
19, 2003 |
3.1 |
Add
feature numbers and ranking for cross reference with other documentation. |
Lauren
Toffolo, PMP |
|
October
21, 2003 |
3.2 |
Added
course restriction constraint. |
Lauren
Toffolo, PMP |
|
October
24, 2003 |
3.3 |
Added
scheduling to out of scope, removed students having the ability to give
access to others, removed teachers from sentence in maintainability. |
Lauren
Toffolo, PMP |
|
October
28, 2003 |
4.0 |
Add
client changes and additional features requested after GUI presentation. |
Lauren
Toffolo, PMP |
The Graduation Planning System will allow current students
and advisors to plan a course of study for any Rose-Hulman major and
minor. The system will be designed to
show which classes must be taken during which quarter to graduate at a specific
time. Additionally, changes of majors
and minors will be allowed and the system will show what impact these changes
will have on the graduation date. The
system will be integrated with the existing Rose-Hulman Banner Web to allow
students to register for online for the classes they have chosen.
Not included in the scope of this project are:
·
·
The application
will not perform and scheduling functions.
·
Graduation
planning for Master level students.
·
Perspective Rose
Students will not be able to view a course of study.
·
Tools for
advisors
·
Tools for
registrar (student interest level, alert for scheduling conflicts)
·
Reporting by
quarter, year, student status, major, professor, class size, class room
·
Integration with
financial aid office.
·
Ability to
recognize courses that don't count for overloading (ROTC, life skills)
·
Ability to be
used as a forecasting tool for department heads in order to predict the number
of sections required.
·
Ability to create
adhoc reports.
·
Ability to see
final test schedules.
·
Handling online
web based courses.
|
Feature No. |
Feature Name |
|
1 |
Ability to generate
suggested courses and setup a timeline. |
|
2 |
Ability for a department
head to add new courses or remove old courses. |
|
6 |
Ability to generate
different freshman schedules based on possible majors. |
|
7 |
Ability to recognize fast
track credits. |
|
8 |
Allow quarters to be
skipped. |
|
9 |
Allow part time, full time
and course overload. |
|
10 |
Auto link to preview course
descriptions and prerequisites. |
|
11 |
Department head has access
to modify course offerings, need of prerequisites and class size. |
|
14 |
Ability to have double
majors |
|
15 |
Ability to enter advance
placement credits |
|
16 |
Ability to enter off campus
credits |
|
17 |
Access to grade replacement
for failing grades to indicate that a course has been passed. |
|
18 |
Ability to recognize
transfer credits. |
|
19 |
Ability to substitute a
class. |
|
20 |
Ability to recognize
major/minor change. |
|
21 |
Ability to recognize
dropped or added courses. |
|
23 |
Course information and
prerequisite information available for viewing. |
|
25 |
Ability for dept. head to
add a new major or minor. |
|
27 |
Ability to ‘preview” what
if majors and minors |
|
28 |
Graphical representation |
|
30 |
Ability to save a scenario |
|
31 |
Ability to identify course
sequences for all majors including prerequisites. |
|
32 |
Ability to allow for co op
or sitting out a quarter. |
|
33 |
Ability for dept. head to
drop an old major or minor. |
|
34 |
Ability to take
prerequisites at the same time as course. |
|
35 |
Ability to assign another
advisor |
|
52 |
Ability to view course name
on the schedule grid when the mouse is moved over the course number. |
|
53 |
Ability for changes in the
schedule to ripple throughout the graduation plan as they are applied as
constraints. |
|
54 |
Visual Queues: Show which
courses have been taken: area, fee, tech, or restricted elective. |
|
56 |
Allow for “fixing” a
quarter so that the ripple affect will not change the specific quarter. |
|
57 |
Use drop down boxes for
area, tech and restricted elective.
(See Design Constraints) |
|
58 |
Split Free Elective
Selection into a separate screen showing course prefix and course
number. (See Design Constraints) |
|
59 |
Allow generic class prefix
and number selection as placeholders for humanities and tech electives. (See usability) |
|
60 |
Ability to add constraints
to schedule via buttons on the main schedule screen. (See Design constraints) |
|
Feature No. |
Feature Name |
|
4 |
Compatible with existing
software. |
|
5 |
Compatible with existing
hardware. |
|
22 |
Access to system with
knowledge of which courses have been completed successfully. |
|
Feature No |
Feature Name |
|
3 |
Integration with banner. |
·
The system should be stable, be able to handle a load of 400 students
registering simultaneously. (Constraint
imposed by client)
·
Schedules should be generated in less than 5 seconds and constraints
should update the schedule within 5 seconds.
(Constraint imposed by client)
Reliability and availability
·
The application should be available the majority of the time with only
minimal time allowed for maintenance.
Downtime should be less than 1 hour per month.
·
The system should be available when Banner Web is available, except
during scheduled maintenance periods.
Usability
·
Web based user interface similar to existing Banner Web system. (Minimal graphics to allow for dial up
users.)
·
The system will make use of color to distinguish between courses
completed, courses scheduled and fixed and technical, area, and free electives.
(See feature 55)
·
The user will be allowed to use generic placeholders for classes such
as humanities and technical electives so as not to have to pick a certain
class. (See feature 59)
Security
·
Secure entry using a user Kerberos name and password. (Constraint imposed by client) Students will have access to their
information only. Advisors will have
access to their advisees’ schedules, which will be granted by area department
heads.
Modifiability, maintainability, and customizability
·
The system will be developed in the Rose-Hulman standard development
environment and will utilize object oriented and re-usable code modules to
allow modifications, customization and support.
·
System should be
able to adapt to changing requirements, majors, and course offerings without
extensive modification.
Testability
·
The system will be developed in a development environment, separate
from the testing and production environments to allow for regression and load
testing to be performed.
·
Test cases will be built from Uses Cases and Supplemental
Specifications detail. In the case of
orthogonality, use case rationalization will be used.
Must be web based and developed in an application supported by the Rose-Hulman IT department. Current software/hardware include Microsoft Windows based operating systems and Oracle database and development environment.
The client has requested that specific features be designed using tools such as drop down boxes and separate screens. (See Features 57, 58, 60)
·
Integrated with Banner Web through Oracle database calls.
Will support the Rose-Hulman IT coding, verification, validation, and user training, installation and implementation support standards.
In the current climate several “issues” exist that the client would like to have removed for planning a student graduation strategy. Freshman are not assigned a department, but are randomly assigned an advisor. When the student enters with several advance placement credits or declares a major outside of the advisors area it is difficult and cumbersome to think about long term graduation plans. For this reason, advisors usually only plan for the next quarter and have a hard time generating graduation dates for the occasional “what if” scenario of major and minor changes, additions of majors and minors and skipping quarters.
Students, advisors and registrar users should have access to this application via secure entry over the World Wide Web. Basic browser skills will be necessary to use the application.
Students and their advisors will automatically have permission to students’ information.
This application will not interface with Banner Web to allow for scheduling. Therefore, a course may be recommended by the application that is full. The student will manually have to remove this course when he/she becomes aware of this conflict.
Students will develop the application and therefore access to “live student records” must be prevented. The students are expected to have the software development life cycle skills necessary to complete the project.
It is expected that this project will have a budget that includes at least the following:
Advisors and students currently do graduation planning manually. Advisors usually only plan for the next quarter.
The market window for this product should be quite
long and there are no competing products at this time.
This application could possibly be extended to
include interfaces to the financial aid applications and for department heads
and instructors to view class interest in planning for the number of sections
of courses.
The time to implement this project will be dependent
on the following:
o
Number of requirements
o
Budget (as related to the number of man hours required to meet all
requirements)
|
Name |
Project Relationship |
Signature |
|
Mark
Yoder |
Business
Owner |
|
|
Steve
Chenoweth |
Project
Advisor |
|
|
Charles
Lehman |
Project
Team |
|
|
Lauren
Toffolo |
Project
Team |
|
|
Geoff
Ulman |
Project
Team |
|
|
Matt
Weinstock |
Project
Team |
|
|
Registrar
|
End
User |
|
|
Rose-Hulman
IT Dept. |
Maintenance
and Support |
|
|
Admissions
and Standings |
Legal |
|