Sample Response to  Discussion Question 2:  Operational Concept

Our objective this week is to achieve consensus on an operational concept for a Plan of Study DSS.  Buede (2000) defines an operational concept as follows:
Operational Concept: vision for what the system is (in general terms), a statement of mission requirements, and a description of how the system will be used.  The shared vision is based on the perspective of the system's stakeholders of how the system will be developed, produced, deployed, trained, operated and maintained, refined, and retired to overcome some operational problem and achieve the stakeholders' operational needs and objectives.  The mission requirements are stated in terms of measures of effectiveness.  The operational concept includes a collection of scenarios; one or more for each group of stakeholders in each relevant phase of the system's life cycle. 

The following background information has been provided: 

1.  A vision statement for the Plan of Study DSS.  This should be a one-paragraph description of the vision for the system as agreed upon by all stakeholders.

The George Mason University (GMU) Objectives Assistance Tool (GOAT) is a decision support system (DSS) designed to assist students enrolled at GMU in selecting appropriate classes to reach their academic objectives.  The DSS will allow students to develop, save, and compare multiple plans of study; seek approval from academic advisors; and select the most appropriate courses for a given semester thereby enabling students to make effective, informed decisions as to which classes to take when thereby maximizing the likelihood of meeting their academic objectives within personal and academic constraints. The DSS will interface with the GMU PatriotWeb information system, extracting data as needed for decision support functions. The DSS will not make modifications to PatriotWeb data. The DSS will interoperate with a future system for course planning.  The DSS will be developed via an evolutionary model with basic functionality brought online rapidly, and used by increasingly large and diverse groups of students and advisors from an increasing number of departments. Each evolution will add breadth or depth to the system in both functionality and user community, as agreed to by stakeholders.

2.   A set of usage scenarios. 

  1. User logs in to GOAT, executes function and logs out (this segment is common across all scenarios)
    1. User accesses main GOAT page via web.
    2. GOAT requests authorization.
    3. User provides valid user id and password.
    4. GOAT verifies unique identification with the registrar's office.  If identification cannot be verified return to step b.
    5. GOAT displays main menu containing the following options: (i) Tutorial; (ii) Create / Modify Plan of Study; (iii) Evaluate Plan of Study; (iv) Search for Courses; (v) Maintain GOAT (available to authorized administrators only)
    6. User selects tab for desired module.
    7. GOAT displays the entry screen for desired module.
    8. User executes desired action.
    9. If not finished, user returns to main menu (step e); otherwise, user logs out or is logged out automatically after maximum inactive period is exceeded.
  2. User executes tutorial
    1. User executes actions a-e of Scenario 1.
    2. User selects tab for tutorial module.
    3. GOAT displays the tutorial module welcome screen.
    4. User enters topic in which he/she is looking for help.
    5. GOAT searches database for relevant training guides on the topic.
    6. GOAT returns listing of available guides.
    7. User selects the most appropriate guide.
    8. GOAT displays the selected training information.
    9. User exits scenario (executes action i of Scenario 1).
  3. Student creates new plan of study (this scenario will be extended in a later version to recommend courses)
    1. Student enters GOAT by executing actions a-e of Scenario 1.
    2. Student selects tab for creating plan of study.
    3. GOAT displays the plan of study screen.
    4. Student selects tab to create new plan of study.
    5. System asks whether student wants to use an existing plan of study as a basis.
    6. Student says no.
    7. Student selects the most appropriate college (e.g. engineering, business).
    8. GOAT displays all academic programs under that college.
    9.  Student selects an academic program.
    10. GOAT retrieves a recommended plan of study for that program from recommended plan database. (Note: we have not specified whether recommended plans will reside in an internal GOAT database or whether they will reside in another university database and be accessed by GOAT. This issue will need to be resolved at detailed design time.) 
    11. GOAT requests student transcript from university database.
    12. GOAT receives student transcript from university database.
    13. GOAT displays recommended plan of study for student's chosen program. Courses student has already taken are indicated on plan. (Note: for some programs there will be multiple recommended plans and this scenario will require an additional step in which student chooses from a list of recommended plans.)
    14. Student modifies the study plan by:
      1. Adding or deleting one or more specific courses to be taken;
      2. Specifying one or more "TBD" courses in a given semester, together with a list of alternative courses for the TBD slot;
      3. Specifying or changing the semester in which a course is to be taken.
    15. GOAT updates, revises, and displays a new recommended plan of study
    16.  Student accepts the plan of study.
    17. GOAT saves the plan of study in student's study plan folder.
    18. Student exits scenario (executes action i of Scenario 1).
  4. Student searches for available courses (this scenario will be extended in a later version to provide recommendations for courses to be taken)
    1. Student executes actions a-j of Scenario 3.
    2. Student selects tab for course search.
    3. GOAT displays the courses screen.
    4. GOAT displays list of saved study plans and requests student to choose a plan from the list.
    5. GOAT displays selected plan and requests selection of courses available for modification.
    6. GOAT displays all available courses (in a given semester) related to student's program of study. (This is the entry point for the course recommendation feature to be inserted later.  System will allow student to select a subset of courses available for modification (default is all non-required courses in degree program).  System will guide student through recommended alternatives to the selected subset that best meet student's objectives.)
    7. Student selects course.
    8. GOAT displays course information.
    9. Student executes actions k-o of Scenario 3.
  5. Student enters goals and constraints (Note: Initial version will include a very limited set of goals and constraints; later versions will expand on factors to be considered.)
    1. Student enters GOAT by executing actions a-e of Scenario 1.
    2. Student selects tab for entering goals and constraints.
    3. GOAT displays the goals and constraints dialog.
    4. Student enters information about goals and constraints, to include:
      1. Number of semesters until degree completion (minimize);
      2. Time slots to avoid scheduling classes (minimize classes scheduled during selected periods);
      3. Number of days per week on which classes are scheduled (minimize);
      4. Desired elective courses (maximize desired courses included in plan);
      5. Number of credit hours above degree/certificate requirements (minimize extra credit hours).
    5. Student indicates whether each item is a constraint (no plan will be accepted if constraint is not satisfied) or a goal (system will attempt to satisfy goals but will accept plans that do not satisfy goal).  Student enters information on relative desirability of different goals.
    6. Student exits scenario (executes action i of Scenario 1).
  6. Student evaluates plan of study (this scenario will be extended in a later version to provide recommendations for courses to be taken)
    1. Student enters GOAT by executing actions a-e of Scenario 1.
    2. Student selects tab for evaluating plan of study.
    3. GOAT displays the evaluate plan of study screen and requests selection of study plan to evaluate.
    4. Student selects a study plan to evaluate.
    5. GOAT evaluates study plan. Evaluation includes:
      1. Degree requirements met (with indicator of pending approvals if necessary approval has been requested);
      2. Degree requirements not met;
      3. Prerequisites not met for planned course sequencing (with indicator of pending approvals if permission to waive prerequisite has been requested);
      4. Approvals pending (advisor or department approval of study plan; university approval of general education requirement; department approval of transfer credit; etc.); 
      5. One or more feasible schedules for upcoming semester(s) for which course schedule is available or indication of schedule conflicts if no feasible schedule exists for planned set of courses.
      6. Overall assessment of how well study plan meets student's goals.
    6. Student selects "request approval" button.
    7. GOAT sends email to student's advisor requesting approval. (Note: some departments may elect to route approvals to someone other than the student's advisor.)
    8. Student exits scenario (executes action i of Scenario 1).
  7. Faculty advisor approves plan of study (Clarification: There is not a uniform process within the university for plan of study approvals, and it is not realistic to expect one to be imposed.  GOAT will be designed to support the existing approval processes.)  
    1. Advisor receives email from student requesting approval of plan of study.  Email contains a link to GOAT plan of study for which approval is desired.
    2. Advior clicks on link and is routed to GOAT entry screen.
    3. Advisor enters GOAT as in actions a-e of Scenario 1.
    4. Upon entry, GOAT displays the student's plan of study evaluation screen with needed approvals highlighted.
    5. Advisor executes one of the following actions:
      1. If approval is routine and advisor is authorized to approve, advisor executes approval.
      2. If issue requires discussion, advisor indicates that approval is deferred pending a meeting with student, and GOAT sends email to student asking student to make appointment with advisor.
      3. If advisor accepts study plan but is not authorized to make approval, advisor requests that approval be routed to appropriate person, and GOAT requests explanation/comments from advisor, and sends email to appropriate approval authority including explanation/comments.
      4. If advisor denies approval, advisor enters reason for denial and GOAT sends email with explanation to student.
    6. Advisor exits scenario (executes action i of Scenario 1).
  8. Authorized administrator updates course and pre-requisite information (Clarification: Several students proposed scenarios in which teachers entered information about their courses.  Course offerings, program requirements, and prerequisites are not up to a teacher's discretion. Courses aren prerequisites are determined by a department, and must go through a school and university level approval process in which other departments can comment and can protest changes that will adversely affect their students. Furthermore, course information is used by other university systems, such as PatriotWeb's degree audit. Therefore, we will make the assumption that GOAT obtains its course information from other university systems.)
    1. Authorized administrator enters GOAT by executing actions a-e of Scenario 1.
    2. Administrator requests to synchronize course information.
    3. Administrator enters secondary password.
    4. GOAT verifies secondary password with the Administrators database.  If secondary password is not valid return to step c.
    5. GOAT requests update of course data from university database.
    6. University database sends to GOAT changes since last update.
    7. University database sends completion message and indicator that update was successful.
    8. GOAT displays successful completion message.
    9. GOAT saves changes.
    10. Administrator exits scenario (executes action i of Scenario 1).

3.   A set of mission requirements.

  1. Coverage. The GOAT system shall provide a means to create, store, evaluate and manage approvals of study plans for all undergraduate and graduate degree and certificate programs and for non-degree students, to include double majors, combined BS/MS programs, and certificates earned along with degree.  Metric: Check list of supported programs against list of programs offered by university.
  2. Capacity. The GOAT system shall support five thousand concurrent users. Metric: Measure performance (speed and unscheduled downtime) of system as function of number of users simultaneously logged in.
  3. Availability. The GOAT system shall be available 24 hours per day, seven days per week, with no more than 5 hours of downtime per month. Metric: Collect statistics on downtime for operational system.
  4. Usability. The GOAT system shall require no more than 20 minutes of training via embedded tutorials for the average high school student to master its usage. Metric: Perform usability study to evaluate task performance and user satisfaction as function of time spent in training.
  5. Interoperability. The GOAT system shall interoperate with PatriotWeb and other university systems. Metric: Demonstrate ability to retrieve data from university database, send emails to request authorizations (and other interoperation specified in detailed design).
  6. Security. The GOAT system shall provide multi-level security to restrict data access and/or updating to users with authorizations appropriate to the data being accessed or updated. Metric: Perform evaluation study in which sophisticated individuals attempt to break into system; demonstrate ability of authorized users to access necessary information.

Back to SYST 542 homepage