Problem statement for a Graduation Planning System

Revision History

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

High Level Problem Summary

Summary of Primary Success Criteria

• Storyboards are created and approved by the client.
• A working prototype is demonstrated and approved by the client.
• A user manual is created to articulate how the system will be used.
• Use cases are written and tested against the requirements with success. (Client described these use cases and “working scenarios”.

Scope

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.

Detailed Problem Statement

1.0 Function

Key Business Features

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)

Key enabling features

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.

Key interfaces

Feature No	Feature Name
3	Integration with banner.

2.0 Form

Key attributes

Performance and Capacity

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

Hardware and Software Constraints

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)

Key Interfaces

· Integrated with Banner Web through Oracle database calls.

Required Standards

Will support the Rose-Hulman IT coding, verification, validation, and user training, installation and implementation support standards.

3.0 Economy

Business Context

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.

Customer Organizational Constraints

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.

Development Organizational Constraints

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.

Key Risks and Uncertainty

• Scope creep in key features. The team will mitigate by meeting with the client weekly and reviewing use cases and GUI’s to get quick feedback and negotiate release features.
• Long-term support costs.

It is expected that this project will have a budget that includes at least the following:

• Development Costs by man-hours for Discovery, Development, Quality Assurance, User testing, Training, and minimal post implementation support.
• Annualized first year maintenance costs

4.0 Time

Historical Context

Advisors and students currently do graduation planning manually. Advisors usually only plan for the next quarter.

Current Context

The market window for this product should be quite long and there are no competing products at this time.

Future Context

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.

Development Time

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)

Key Stakeholders

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