Demo Docs by Rafiq

Online Registration System Vision

Version 1.0

Online Registration System Vision Jean-Claude Franchitti Assignment 1

Version: 1.0 Date: 2/5/2006

Revision History
Date 1/5/2012 Version 1.0 Initial version Description Author Rafiq Mohammed

Confidential

Christopher Fagiani hw1

ii

Online Registration System Vision Jean-Claude Franchitti Assignment 1

Version: 1.0 Date: 2/5/2006

Table of Contents
1. Introduction 1.1 Scope 1.2 Definitions, Acronyms and Abbreviations 1.3 References 1.4 Overview 2. Positioning 2.1 Problem Statement 3. Stakeholder and User Descriptions 3.1 Stakeholder Summary 3.2 User Summary 3.3 User environment 3.4 Stakeholder Profiles 3.4.1 Student 3.4.2 Registrar 3.4.3 Administrator 3.4.4 IT Staff 3.5 Key Stakeholder / User Needs 4. Product Overview 4.1 Product Perspective 4.2 Summary of Capabilities 5. Product Features 5.1 Course Searching and Browsing: 5.2 Course Set Up 5.3 Course Override 5.4 Easy to use 5.5 Secure 5.6 Reporting 5.7 Self-Service Registration & Inquiry 5.8 Linked with Other University Systems 6. Quality Ranges 7. Precedence and Priority 8. Other Product Requirements 8.1 Applicable Standards 8.2 System Requirements 8.3 Performance Requirements 9. Documentation Requirements 9.1 Online Help 1 1 1 1 1 1 1 1 2 2 3 3 3 3 3 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 5 5 5

Confidential

Christopher Fagiani hw1

iii

Online Registration System Vision Jean-Claude Franchitti Assignment 1

Version: 1.0 Date: 2/5/2006

Vision
1. Introduction
The purpose of this document is to collect, analyze and define high-level needs and features of the Online Registration System (ORS). It focuses on the capabilities needed by the stakeholders, and the target users, and why these needs exist. The details of how the ORS fulfils these needs are detailed in the requirement documents included in this Requisite Pro project. 1.1 Scope The ORS project is focused on delivering a web-based self-service registration system for University courses. The initial incarnation of the system will contain three modules: a student module through which users may register for courses and browse available course offering, a administration module used by University personnel to enter course offerings, and a reporting module used by University officials to track course enrollment. Additional functionality, such as providing an interface and workflow for professors to submit course offerings has been deemed out of scope for the system. 1.2 Definitions, Acronyms and Abbreviations Please refer to the Glossary document contained in this Requisite Pro project for definitions of all terms and acronyms used throughout the project documentation. 1.3 References Hardware Requirements Document Feature Requirements Document Supplemental Requirements Document Glossary 1.4 Overview The remainder of this document outlines the business case for the creation of the ORS as well as a description of the stakeholders involved in the project. We conclude with a brief description of the system features identified during the project inception. For a full requirement list, please refer to the requirements documents contained in the Requisite Pro project repository.

2.

Positioning
2.1 Problem Statement The University student registration system is unable to cope with the high volume of telephone calls received at registration time. Rather than incur the additional cost of augmenting the staff around registration periods, an online student registration system must be developed. This system should reduce the manpower needed to staff the registrars office during course registration, thereby allowing the University to realize significant cost-savings.

3.

Stakeholder and User Descriptions

The ORS has three primary user groups and four stakeholder groups. The users are classified as students, registrar staff, and administrators and representatives of each group are stakeholders for system development. In addition to these three groups, the University IT staff is another stakeholder as they will be tasked with maintaining the system.

Confidential

<Company Name>, 2000

Online Registration System Vision Jean-Claude Franchitti Assignment 1 3.1 Name Student Focus Group Stakeholder Summary Represents The students represent the largest group of end-users for the system. Role

Version: 1.0 Date: 2/5/2006

The focus group will provide input as to what features will be useful from the registration side of the application. The staff member assigned to the project will serve as the business process expert in regard to the process by which courses are made available and students register for them. This stakeholder group will provide input as to which features are needed for useful reporting from the system.

Registrar staff member

The registrars represent the administrators of the system and will be responsible for publishing course information.

Administrator

University administrators represent users of the reporting features of the system. The stakeholders for this role will include a member of one of the academic departments as well as a representative of the deans office. The Universitys IT staff will have to provide support for the ORS after it goes live thus their requirements will be taken into consideration throughout the project lifecycle.

IT Staff

This stakeholder group will provide requirements needed to ensure the system is maintainable and fits in well with the existing infrastructure at the University.

3.2 Name Student

User Summary Description Students use the system to register for courses. They must have a way of logging into the system, browsing for courses, and selecting the courses they want to take. In order to gather their requirements for the system, a focus group will be formed. Personnel in the registrars office will enter course information into the ORS. They will also have mechanisms for overriding system limits such as maximum enrolment and to move students in and out of courses. The project team will work closely with the registrar office staff to ensure the system requirements capture their needs. Members of the University administration will use the system to run reports on course enrolment. They will have a read <Company Name>, 2000 Stakeholder Represented by the student focus group.

Registrar

Represented by member of registrar staff assigned to project team.

Administrator

Represented by member of University administration

Confidential

Online Registration System Vision Jean-Claude Franchitti Assignment 1 only view into the system and can see data either in aggregate or on a studentby-student basis. The project team will have input from a representative of the administration for purposes of gathering requirements.

Version: 1.0 Date: 2/5/2006

assigned to project team.

3.3 User environment There are two differing user environments for the system: University offices (for administrators and registrars) and student PCs (for students). All user groups will interact with the system via a web browser connected to the Internet. The difference between the two environments is that the university IT staff controls the PCs in offices thereby ensuring that the same web browser is used by all users whereas no assumptions can be made about which browser students will use. 3.4 3.4.1 Stakeholder Profiles Student Student focus group Students at the university who will use the system to register for classes. Normal-User; have varying levels of familiarity with computer systems Provide input as to the desired functionality for the student module. A usable system through which they are able to reliably register for classes. Focus group will be involved during requirements gathering and will serve as a reviewer of the requirements before construction begins. Registrars Office staff member Staff member at the university who is responsible for entering courses into the system. Power-User; will be trained on the system and have ability to perform all user functions. Provide input as to the desired functionality for the staff module as well as server as the subject matter expert for the registration process.. A usable system through which they are able to publish classes and allow students to register without having to field questions from end-users. Will be involved during requirements gathering and will serve as a reviewer of the requirements before construction begins. Involvement will continue throughout project lifecycle. Academic department / Deans office staff member Univeristy administrator Normal-User; have varying levels of familiarity with computer systems Provide input as to the desired functionality for the reporting module. A usable system through which they are able to easily retrieve accurate enrolment reports. Will be involved during requirements gathering and will serve as a reviewer of the requirements before construction begins. Feedback will be solicited on an ongoing basis throughout the project.

Representative Description Type Responsibilities Success Criteria Involvement 3.4.2 Registrar

Representative Description Type Responsibilities Success Criteria Involvement

3.4.3

Administrator

Representative Description Type Responsibilities Success Criteria Involvement

Confidential

<Company Name>, 2000

Online Registration System Vision Jean-Claude Franchitti Assignment 1 3.4.4 IT Staff

Version: 1.0 Date: 2/5/2006

Representative Description Type Responsibilities Success Criteria Involvement

Member of the IT staff Information technology staff member responsible for supporting the ORS GURU; will have intimate understanding of the way the system works Provide input as to the technical standards that must be met by the system A system that is well documented adheres to standards and is easy to maintain. Will be involved throughout the project lifecycle and will serve as a requirements and design reviewer.

3.5 Key Stakeholder / User Needs The ORS system needs to be developed because the current telephone-based system can no longer support the number of students trying to register for classes. Rather than adding phone lines and staff members to answer them, the ORS system will allow self-service access to course registration.

4.

Product Overview
4.1 Product Perspective While the ORS system can operate as a self-contained system, it is meant to operate in conjunction with the Universitys billing system and its grading system. The ORS will take an input file from the billing system that contains student records when a student enrolls in the University. It will provide the billing system with student course enrollment information so a student can be accurately billed for the courses he takes. The system will also take feed from the grading system so students and administrators can see grades for courses the student has taken in past terms. 4.2 Summary of Capabilities Online Registration System Customer Benefit Supporting Features Fewer people are needed to staff the Web-based self-service system will Registrars Office. minimize student phone calls to the office. Administration can run reports onReporting module can run a variety of demand without intervention from reports useful to deans, instructors and registrar. department chairpeople. Audit trail of changes to student System logs each transaction with a user id registration. and timestamp.

5.

Product Features
5.1 Course Searching and Browsing: Students can search/browse for courses using a web interface. 5.2 Course Set Up Registrars Office staff people can set up courses with data about where the course will meet, who will teach it, and how many people can enroll. 5.3 Course Override Registrar can override system enrollment limits or move students in/out of courses.

Confidential

<Company Name>, 2000

Online Registration System Vision Jean-Claude Franchitti Assignment 1

Version: 1.0 Date: 2/5/2006

5.4 Easy to use Web-based system will be accessible anywhere with internet access and online help documentation will aid users in navigating the system. 5.5 Secure System will require users to log in, will encrypt all traffic over the Internet, and will log all transactions with user ids and time stamps. 5.6 Reporting System will provide on-demand reporting for administrators and department heads. 5.7 Self-Service Registration & Inquiry System will greatly reduce calls to Registrars office by providing students with self-service web interface that is available nearly 24 hours a day. 5.8 Linked with Other University Systems System will interface with billing and grading systems to eliminate need for double entry of data. Interface with grading system also provides a one-stop-shop for students looking for enrollment history with course performance.

6.

Quality Ranges
The system must be highly-available and should only be inaccessible during a 1-hour maintenance window each week.

7. 8.

Precedence and Priority

See the feature report in Requisite Pro project for feature priority.

Other Product Requirements

System must be browser independent. 8.1 Applicable Standards System should comply with standard OO design techniques. 8.2 System Requirements System should run on the Universitys existing Linux-based server infrastructure. Similarly, it should use the Universitys existing Oracle 9i instance for its database. 8.3 Performance Requirements System must render all UI pages in no more than 9 seconds for dynamic pages. Static pages (HTML-only) must be rendered in less than 3 seconds.

9.

Documentation Requirements
9.1 Online Help The system will contain HTML-based online help files that describe each function within the application.

Confidential

<Company Name>, 2000