Sample Response to  Discussion Question 1:  Problem Definition

This semester's case study is a decision support system to assist GMU students in planning a program of study.

Problem Description:  A system is required to assist students at George Mason University in planning a program of study.  One of the services provided by the PatriotWeb information system is the degree audit, which informs students of which degree requirements have been met and which are still outstanding.  However, PatriotWeb does not include any planning functions, and currently the process of planning which courses to take in the future is entirely a manual process.  As a consequence, many students find themselves needing to stay a semester or two longer than planned, or having to take different courses than they would prefer to take.  Many of these situations would have been easily prevented with advance planning.  Many students do plan ahead diligently, and would be well-served by a tool that would reduce the tedium and help to prevent errors.  Furthermore, planning data, if available, would be useful for program administrators and department chairs in forecasting demand for courses and planning course offerings. Although program planning is outside the intended scope of this project, interoperation with an eventual program planning system should be considered in the design.

  1. Who are the stakeholders of the case study DSS? Describe the impact of the DSS on the major groups of stakeholders.
  2. How will the DSS be used? We will use the responses for this question to begin developing an operational concept for our system.
  3. Describe your approach to obtaining user requirements, and your approach to obtaining feedback from the user population to ensure that the system meets the needs of its target users.

1. Describe the current process of how a typical student plans a program of study.   What sources of information are currently available to support this process?

The process of planning a program of study varies from student to student. A typical student begins by selecting a major or a set of majors he/she is interested in pursuing.  The students examines the requirements of the chosen major or majors, and develops a list of required courses that need to be fulfilled to graduate, along with electives the student is interested in taking. The student and advisor jointly create a plan of study which shows a yearly schedule of courses that should be taken to graduate by the intended date.  In some departments this plan is required; in others it is optional.  Each year, the plan is updated to reflect what the student actually took, and to reflect declaration or change of major. This can be a tedious process if there are many changes.  The student is responsible for making sure all degree requirements are met.  In the final semster, the student submits a degree application. In departments that do not require a formal plan, many students simply select a set of courses to take each semester without planning ahead. If the student did not have a formal plan or if the formal plan wasn't checked carefully against requirements, the student may discover unmet requirements at degree application time, and be unable to graduate as planned.  Because of deficient planning, many students graduate later than they had planned or miss opportunities to take courses they wanted to take. 

The following sources of information are available to students for planning a program of study:

  1. The university catalog describes degree requirements and university and department policies.  It also contains course listings and prerequisites.
  2. Past schedules of classes provide data that can be used to predict frequencies of course offerings and the semester in which courses will be given.
  3. Department websites, department brochures, and advisors can provide additional information not listed in the catalog.
  4. For entering transfer students, transfer agreements and course equivalency information can be obtained from the registrar's office or the transerring institution.  NOVA publishes transfer guides by major program.
  5. Students also obtain information from their peers about course offerings, schedule conflicts, elective sequences, etc.

2.  Who are the stakeholders of the case study DSS?

The primary stakeholders are the following:
  1. Students – primary users of the decision support capability and key evaluators of the system.
  2. Advisors – provide advice on plans of study prepared by their advisees.
  3. GMU Information Technology Unit – fiscal stakeholders.
  4. System Developers & Maintainers – concerned with the development, implementation and maintenance of the system.
  5. Department Administrators – administer study plans and degree applications; would like to use aggregate plan of study data to forecast demand for courses.
Secondary stakeholders include prospective students, both potential rising freshmen and transfer students, and parents of students.

3.  How will the DSS be used?  

The purpose of the DSS is to assist GMU students in planning a program of study.  

Basic functionality: The system will allow a student to enter and evaluate one or more plans of study. To enter a plan of study, the student will select a set of courses and the semester each course is to be taken.  Courses the student has already taken will be included automatically.  The system will display the currently selected plan, which the student can browse and edit.  Changes can be saved to update the existing plan of study, or as a new plan of study.  The student can evaluate the plan of study against degree requirements for a selected major and catalog year, using the existing degree audit rules.  Unmet requirements, unsatisfied prerequisites, and other problems will be identified and displayed. Advisors or other authorized officials can enter prerequisite overrides, course substitutions, elective approvals, and other information using an approval authorization. Advisor authorizations are preliminary; official university approval process must be followed to obtain final approvals.

Optional additional functionality: Upon stakeholder approval, the following additional capabilities will be added to later versions of the system.  (1) The system will categorize courses by semester according to an approved set of categories relating to the likelihood that the course will be offered.  The catalog currently lists courses as being offered in fall, spring or summer.  Some courses will be further noted as being guaranteed to be offered in the indicated semester.  For other courses, historical data on offerings may be accessed by users.  (2) Another optional capability is to evaluate plans of study with respect to a student's educational goals. Example goals include semester of graduation, maximum number of credits per semester, preferred open days, preferred class times.  (3) A final optional capability would be to suggest one or a set of alternative programs of study that meet the student's educational goals.

4.  Describe your approach to obtaining user requirements, and your approach to obtaining feedback from the user population to ensure that the system meets the needs of its target users.

The first step is data gathering and refining my understanding of the problem.  I would begin by conducting interviews with students, alumni, and advisors to understand how they choose courses and to identify what they consider the biggest problems that decision support could alleviate.   I would also gather information about the PatriotWeb degree audit capability. A key design decision is whether to add study plan creation as a new capability within PatriotWeb or to develop a separate standalone DSS.  Information about PatriotWeb is essential to making this design decision.  

After this initial data gathering phase, I would identify a small group (2-3 students, 1-2 faculty) of committted stakeholders who were willing to devote considerable energy to helping to develop and refine requirements.   I would develop my scrubbed "laundry list" into an initial proposed operational concept with use cases and storyboard, a proposed set of requirements and a set of issues (conflicts I resolved; gaps I filled; interpretations I made of statements people made to me).   I present these to the committed stakeholders, and then work with them to reach consensus on (1) initial requirements, (2) functionality of the first prototype, and (3) staged implementation plan.  I would also develop cost estimates for the prototype and for the final system with different levels of functionality.

After achieving consensus on these items, I would brief the decision-making authorities, including fiscal stakeholders, on the estimated cost and the staged implementation plan.  After obtaining their buy-in, after which I would move forward to implement the first prototype.

My first implementation of the prototype would be evaluated by my small committed stakeholder group.   I would incorporate their feedback and refine it until they agreed it was ready for broader evaluation.  I would then present the prototype to a broader group of stakeholders for feedback.  At this point we would reach a decision on whether to (1) abandon the entire effort; (2) clean up the initial prototype and stop with the current level of functionality; or (3) develop a plan to implement additional functionality in future prototypes.

Back to SYST 542 homepage