Volere Specifications Example PDF

Online Registration System
Volere
Requirements Specification for
Online registration system
Final Project CS348 Human Computer Interaction, Prof. Claudia Roda
Editor:
Alessandro Cardone alessandro.cardone@gmail.com
Contributors:
Alessandro Cardone alessandro.cardone@gmail.com
Ryan LaFountain ral@ccs.neu.edu
Jiyoung Mun a60003@aup.fr
Fares Rabbat faresrabbat@gmail.com
Volere Template by James & Suzanne Robertson principals of the Atlantic Systems Guild
The Volere Requirements Specification Template is intended for use as a basis for your requirements
specifications. The template provides sections for each of the requirements types appropriate to today's
software systems. You may download a pdf version from the Volere site and adapt it to your requirements
gathering process and requirements tool. The Volere site also has a Word RTF version. The template can
be used with Requisite, DOORS, Caliber RM, IRqA and other popular tools.
The template may not be sold, or used for commercial gain or purposes other as a basis for a requirements
specification without prior written permission. We encourage you to see the donation notice. The
Template may be modified or copied and used for your requirements work, provided you include the
following copyright notice in any document that uses any part of this template:
We acknowledge that this document uses material from the Volere Requirements Specification Template,
copyright © 1995 – 2006 the Atlantic Systems Guild Limited.
CS/CM 348 SP07 – human Computer Interaction 1

Contents
Project Drivers
1. The Purpose of the Project 3
2. The Client, the Customer, and Other Stakeholders 5
3. Users of the Product 6
Project Constraints
4. Mandated Constraints 6
5. Naming Conventions and Definitions 7
6. Relevant Facts and Assumptions 8
Functional Requirements
7. The Scope of the Work 9
8. The Scope of the Product 10
9. Functional and Data Requirements 11
Nonfunctional Requirements
10. Look and Feel Requirements 15
11. Usability and Humanity Requirements 16
12. Performance Requirements 17
13. Operational and Environmental Requirements 17
14. Maintainability and Support Requirements 17
15. Security Requirements 18
16. Cultural and Political Requirements 18
17. Open Issues 18
Project Issues
18. New Problems 19
19. Tasks 20
20. Migration to the New Product 20
21. Risks 20
22. Costs 20
23. User Documentation and Training 20
Appendix 21

1. The Purpose of the Project

1a. The User Business or Background of the Project Effort
The American University of Paris does not provide an internet system that allows the students to reserve
the classes for an incoming semester.
The existing system only allows users to browse course schedules and create a mock up of their proposed
schedule. Users can currently view course sections, times, and professors. The current system identifies
conflicts within the schedule and alerts the user to these conflicts. It does not submit this mock schedule
to an advisor for approval. The schedule created on the current system must be taken to the registrar's
office and the classes must be manually scheduled by hand.
The only advantage currently given by the internet is the process of browsing the classes, but it does not
provide an official registration. It only displays the possible options that the student can have according to
the classes offered in the chosen semester. As a consequence, at the end and the beginning of every single
semester the registrar’s office is invaded by students who need to obtain the official approval for the
classes that they picked on the Internet and then transcribed manually on paper. Furthermore surprisingly
often the requested classes are full, or there is some sort of a conflict in the schedule. Therefore the
student needs to redo the whole schedule once again, until the latter is not approved by the registrar. Each
and every student must see his/her personal advisor before scheduling classes. Once this meeting is
completed, the student must go to another office and have a meeting with another member of the
administration. This member of the registrar's office must manually transcribe the student's printed
schedule into the registrar system which is different from any system the student has access to.
Also the drop-add process is extremely laborious and it creates unacceptable queues.
The goal of the system we are designing is to automatically all the necessary information to register
students for the coming semester. It will be connected to the AUP database and it will instantaneously
refuse all the unfeasible requests, saving many ours of waiting and work to students, faculty, and staff.
Furthermore, subject to agreement with the appropriate stakeholders, the system might provide many
useful services such as:
• An efficient and detailed description of the classes under many aspects;
• The notification of the most overloaded class to the registrar;
• The possibility of creating a waiting list for the students who want to have access to some classes with
drop-add;
• A more efficient classification of the hierarchy according to which the students can register.
If the program turns out to be successful, the faculty will gain in time, work and money and the students
will gain in time, work, energies and satisfaction regarding the classes that they are going to attend.
The program will be one of many tools used by the university to help students manage their university
career. Users will be full time and part time students of AUP as well as faculty and administrators
(registrar's office etc).
The reasons why the University needs such a program are several and heterogeneous. This device:
• Would save a massive amount of work to the registrar’s office, with directly consequent economical
gain as well as conservation of time;
• It would provide a more efficient and satisfactory schedule for the client (students);
• It would provide clear and precise statistical information (such as the students’ interest and the most
requested classes) that would probably be useful for future reference.

Furthermore, the program would also provide a great service to the students:
• It would provide a better chance to obtain the desired classes, which would directly influence the
scholastic career and, therefore, the working career;
• It would make it possible to register for the coming semesters without physically being in Paris;
• It would take less time to conclude the registration process;
• It would spare the enormous amount of time wasted on the stares of the Bosquet building waiting for
their turn during the drop-add period.
The students are particularly discontent about the registration process proposed by AUP. It is at least
reprehensible to think that in 2007 the registration to one of the most important American Universities in
Europe still offers a service that obliges the student to handwrite all the classes on a paper that will later
have red “registered” stamp over it once the process is over.
1b. Goals of the Project

The product envisages ameliorating the registration process under several points of view.
The most important are:
• An explanatory file that clarifies how the program works the very first time that a student logs in;
• A log-in process to guarantee security of the recognition of every single student;
• The creation of a link between the registration program and a university’s database that comprehend
students’ accounts, offered courses, and all the related data;
• The display of a detailed list of courses that the university proposed in the considered semester;
• The possibility of creating a virtual schedule before the registration is made official;
• The possibility of guaranteeing the official registration of every student that goes through the program;
• The registrar must have the possibility to monitor all the affluence to the classes and be notified
anytime there is any sort of issue;
• The fast movements of students into classes according to the drop-add indications given by the
students.
The first advantage will be measured by the costumers. The registration is a process that takes a long time
and that cannot be undertaken elsewhere than Paris. With this program, the students will be able to
register from any place that has an Internet connection without needing any sort of information and
signature, thanks to the log-in identification. Furthermore, they will not have to worry about not entering
in a class, because the waiting list will spare them hours and hours of queue in the registration office
without any guarantee whatsoever that they will be able to obtain the desired class. With this program, if
there is the practical chance that a student can be registered in a class, she/he will have 100% of guarantee
to have it, thanks to the fast and practical changes in the classes that the program can provide through the
waiting list.
The practical advantages to the university will also be enormous. One of the major concern of the
registrar office is the drop add period, which is an infernal week already because it takes place at the
beginning of the semester where everybody starts posing problems and asking questions. The Internet
drop-add will propose an alternative and will massively lighten the faculty and administration from the
major trouble of having to do it manually. The whole faculty and administration will instead be concerned
elsewhere, working on the several different issues that the beginning of the semester can present.
Furthermore, the program will be able to answer many of the questions that are asked daily to the
registrar.

2. The Client, Customer, and Other Stakeholders

2a. The Client
The client, the American University of Paris, needs this product because the current registration process
and relative drop-add tears apart the whole image that the university has. The registration is the very first
official step that a new student has to undertake in the AUP experience. It is therefore extremely
important that the first impression obtained by the costumer reflects the identity of the university.
Moreover, the part of the administration that is concerned with the registration program wastes a massive
amount of time dealing with processes that ought to be computerized.
2b. The Customer

The client of this program is also the costumer, but not only. In this case, AUP would use the program to
provide a better service to another costumer, which would be the students. The clients from the actual
point of view would mainly be the students and the registrar’s office.
2c. Other Stakeholders

The different stakeholders for this product are:
Students:
• They are the clients of the product.
• They need to know details about the registration in itself, either through papers or the system.
• They do not need to know the technical parts of the system.
• They are directly involved in the system as one of the three main stakeholders.
• Their knowledge influences directly the system, for the latter needs to be changed according to the
students’ knowledge.
Registrar:
• She is at the same time client and costumer of the product.
• She has a complete knowledge of what services the system should provide. She does not need to know
the technical parts of the system;
• She are directly involved in the system because she make the registration effective.
• The database that the system uses is kept by the registrar.
ITS:
• We need their approval and advice on the technical part of the project. They can help us figure out for
example what parts of the system are doable, or what parts are too much of a trouble for the advantage
that we might draw from it.
• Their knowledge is more focused on the technical part of the system, even though they still need to
understand the process to provide a satisfactory service;
• Their knowledge of the registration process is still high, but they need to know how to design the
system so that it appropriately serves the user and the processes involved;
• They are directly involved, in the design, and in the effective concretization of the design into an
effective program.
The advisors:
• They can provide invaluable suggestions on how to guide a student through registration.
• They have no need to know how the system works, but they are the ones who probably know the best
the interests of the students;
• Their knowledge of the registration process is high, they will not need to know the technical details of
the system;

• They can provide important insights in the design of the system about the processes used by students to
build their schedules (questions asked, frequent difficulties, constraints, desires, etc.).
3. Users of the product
3a. The Hands-On Users of the Product

The users of the product will be:
• Students: the students may use the registration system to register for the incoming semester. The
program will compensate any lack of knowledge of the courses, the schedule and even of the system
itself (with an help file)
• Faculty and administration: the faculty and administration will have to know how to access the system
and the database connected to it, in order to straighten possible mistakes in the data or in the
description of the classes, or just to update the database according to possible changes.
3b. Priorities Assigned to Users

Even though the system is thought for the students, there is not a hierarchy for the users, in that the
administration is as important as the students.
3c. Maintenance Users and Service Technicians

Maintenance users are a special type of hands-on users who have requirements that are specific to
maintaining and changing the product. The maintenance users will be the ITS staff, the Dean's office, and
the registrar. The ITS staff will have to deal with any kind of operating discrepancy in the code. Most
likely, even though it should not happen, there will be a problem in the process. Therefore the ITS must
have the possibility to have access to the system.
The Registrar must have access to the database, mostly. However, she might need to change the priority
criteria of the waiting list or of the suggested schedules for the incoming semester. In general the registrar
and possible other "special" users will have the right to override any system decision.
4. Mandated Constraints
There are many constraints for the system we are currently attempting to design. Most of these constraints
will probably be social and budgetary as opposed to technical constraints. Although we assume that these
constraints will occur, we currently have no direct knowledge of them. The system will run on technology
that has already been created, tested and is being widely used in many systems and industries. There
would be no need to invent new technology for this system. The system can be purchased as an out-of-
the-box system, a turnkey system with modifications, or a complete in house custom creation.
4a. Solution Constraints

The only constraint we are currently aware of is the accordance between the system and the university
database
4b. Implementation Environment of the Current System

The environment in which this system is going to take place is The American University of Paris. This
environment guarantees at the moment a fairly organized ambience composed mostly by humans whose
task is to follow personally the students, especially in the registration process. However, the whole
process of registration is almost completely hand-made, with the exception of the possibility of screening
the following semester’s schedule through the course browser. However there is already a database that
provides many of the information that the system needs.
4c. Partner or Collaborative Applications

Description: The system shall integrate with the university database.
Rationale: Input is required from the database and registration information will be stored in the database.
Fit criterion: Input/output to DB works.
4d. Off-the-Shelf Software

Here is the link to popular products and vendors:
http://www.oln.org/et/testbed/categories.php?id=18
See also Wesleyan University Drop-Add Manual in appendix 1.
4d.1 Reusable Components
We are not aware of reusable components that could support the development of the product.
Currently the "course browser" and the "Amis" systems are the two components that most closely
resemble parts of the product we plan to design. These two systems however, could not be reused "as
it is" as components of the envisaged system.
4e. Anticipated Workplace Environment

The system we envisage has a Web based interface and therefore it may be used in any environment.
Specific interfaces for:
• Handheld devices
• Users with disabilities
o Vocal output and input for blind users
o Interface facilitations for users with motion disabilities
• Students with poor English skills (other languages interface)
The interface must be flexible so to accommodate different levels of experience with computers
4f. Schedule Constraints

We are not aware of any schedule constraints
4g. Budget Constraints

We are not aware of any budget constraints
5. Naming Conventions and Definitions

5a. Data Dictionary for Any Included Models
Advisor: member of the faculty who personally follows the student and closely helps her/him to choose
her/his courses as adequately as possible.
Approval for non-taken prerequisites: some classes need some previous prerequisites.
Advising session: a meeting that every student has with her/his academic advisor before the official
registration for the classes.
Confirmation email: an email that would confirm to the student that a system action has been taken (e.g. a
change of courses has officially taken place).
Course browser: currently existing system that allows the students to choose their courses and the
teachers to follow what their students are planning for their future.
Drop-Add: the operation through which the students signs out or in a class after the official registration
took place, and before the drop/add period ends.
Enrollment in classes: a student is enrolled in a class when s/he is officially registered in the course.
Facility for registrar and ITS to overwrite and over-read the changes: these two stakeholders need to be
able to interfere with the system to straighten the possible mistakes or simple changes. They also need to
be able to screen the changes operated.
Faculty: the teaching staff of the University.
Generation of report for overloaded classes: a report that will notify the registrar for the classes
undergoing requests that pass some pre-established limits.
Guest Tour: in case someone who is not currently enrolled in AUP wants to visit the system and/or the
classes offered during the semester.
ITS (Information Technology Service): technical staff for anything that concerns computers and Internet
in the University.
Lost/forgot password: in case the student no longer has access to her/his AUP password.
Proposition of schedules: the system several possible schedules that fit with the personal case of the
students according to her/his requests and needs.
Registrar: member of the administration responsible of the official enrollment of the students as a
member of the university.
Registration: enrollment of a student in the university program for the subsequent semester.
Students: people currently enrolled in the undergraduate or graduate program of the University.
Tutorial: an explanation of how the system works (the form still has to be defined: video? Step by step
presentation?).
Waiting list: a list of students that are asking to be enrolled in a class. The priority is given according to
several criteria (such as class standing and major) that still need to be better defined.
6. Relevant Facts and Assumptions

6a. Facts
• About 1000 students.
• About 100 professors.
• About 240 courses scheduled per semester.
• Classes may have different sizes varying from 8, to 40.
• Students can register for at most 5 classes.
• A 6th class can be added if the student has a GPA of 2.80 or above.
6b. Assumptions
• We assume that the users have Internet access whenever they want to use the product. We assume that
every semester there are enough classes offered by the administration
• We assume that the students have some minimal knowledge:
• Of the English language;
• Of his/her current state: the student needs to know what his ID number and his password are;
• Of the AUP website: the student needs to know how to reach the system within the University
website;
• Of the AUP email account: everything will be notified through the AUP email, therefore the
student must know how to access his email account;
• Of the catalogue, that they are required to read as soon as they are accepted in the college.
• Students should have the choice to register in person not using the online registration system
• During staggered registration period, the online registration system should be available only during
office hours (to avoid unfair disadvantage to students that do not have Internet access)
• Students should have the choice to want the advisor’s help or not.
7. The Scope of the Work

7a. The Current Situation
The current situation does not provide an internet registration process whatsoever. The only service
available on the internet is the organization of the schedule of the student for the incoming semester,
without any sort of official version of the schedule. The student still must go to his advisor’s office, talk
his schedule over with him, get it approved and signed, then take the approved schedule at the registrar’s
office to be officially signed in.
7b. The Context of the Work

The product will have to interact with a university environment. Therefore we are interested in keeping
under control the adjacent systems such as the database, the university website, the mailing system, or the
computerized environment. Regarding the human environment, we have to consider the registrar above
all and the indulgency for the rules of the faculty.
7c. Work Partitioning

Business Event List
Event Name Input and Output Summary

1. New course is added Course details (name, Record new course amongst those
syllabus, prerequisites, available for registration
…) (in)
2. DB supplies students data Students details (name, Use data for processing.
GPA, …) (in)
3. Class is full Student applies for Creation of waiting lists for the
waiting list (out) classes
4.Conflict between two classes System searches and The student is given valid
proposes the alternatives alternatives when there is a conflict
(in/out) between two classes
5. Non taken prerequisites System asks for the The Registrar evaluates the request
Registrar’s approval
(To be completed)

8. The Scope of the Product

8a. Product Boundary
8b. Product Use Case List

• Confirmation email: whenever something changes on the schedule of the student, the latter will be
notified by email with the occurred changes listed in an automated email system in the system.
• Drop-Add: the operation through which the students signs out or in a class after the official registration
took place
• Taken / non- taken classes – the student has access all the time to the list of classes s/he has taken, as
well as the classes he/she should take according to: general education requirements, declared majors,
and declared minors.
• Generation of report for overloaded classes: The system will notify the registrar with any classes that is
loaded over a pre-established limit in order to make her aware of the students’ need to be enrolled in
determined classes.
• Proposition of schedules: The system will offer a few options that will accord to the student’s
parameters. The student will then be able to pick the option that he believes best suits her/his needs.
• Tutorial: an explanation of how the website works (the form still has to be defined: video? Step by step
presentation?).
• Waiting list: if a student requires the enrollment in a class that is already full s/he will be offered the
choice to enter a waiting list for that course. The student will be able to access and modify her/his
waiting list all the time. A student may require to be automatically enrolled in a wait-listed course that
becomes available. In this case, the student may have to indicate which course he/she would like to be
replaced by the wait-listed course.

9. Functional and Data Requirements

9a. Functional Requirements
Requirement #: 1F
Description: The system defines and proposes one or more schedules to student
Rationale: To help students select their courses
Originator: ITS, us and students
Fit Criterion: The system provides the user accurate acknowledgement of passed and
future courses needed to complete their requirement. Also propose a
schedule for the incoming semester that satisfies requirements and
constraints
Customer satisfaction: 4
Customer dissatisfaction: 2
Priority: 4 (1 highest)
Supporting materials: Ryan report of meeting with ITS
Conflict: None
Requirement #: 2 NF
Description: Courses taken and courses still to be taken must be set apart in an obvious
way
Rationale: The student must have a clear idea of the classes s/he needs to take
Originator: ITS interview
Fit Criterion: User test cases of a prototype
Conflict: None
Requirement #: 3F
Description: Have some facility for the administrative overwrite
Rationale: To provide some administrative control on the system
Fit Criterion: Overwrite applies to necessary function
Conflict: None
Requirement #: 4F
Description: Facility to store overrides actions
Rationale: Administrator tracking
Fit Criterion: Override actions are accessible after some time

Conflict: None
Requirement #: 5F
Description: Override reversal
Rationale: Administrative control and mistake fixing
Originator: ITS Interview
Fit Criterion: Observation, accessibility
Conflict: None
Requirement #: 6F
Description: When courses are displayed, show the ratio of occupied over available
Rationale: Students want to how full the class is
Originator: Focus Group
Fit Criterion: The number of students applying needs to appear
Supporting materials: Jiyoung report from focus group
Conflict: None
Requirement #: 7F
Description: Staggered access should be implemented for registration (criteria to be
defined)
Rationale: 1. Priority to classes should be given to certain students
2. Do not want to overload and crash the system
Originator: focus group
Fit Criterion: students who do not fit the requirement cannot register
Conflict: None
Requirement #: 8F
Description: Possibility to reserve a certain percentage of the class for certain students
(students majoring in the subject)
Rationale: Students in the major get priority over the students not in the major
Originator: Focus group
Fit Criterion: Only students matching the criteria will be able to register to reserved places

in the class
Conflict: None
Requirement #: 9F
Description: Email confirmation to the students is sent whenever a course is added or
dropped
Rationale: Students are notified about what changes in the schedule (trust)
Fit Criterion: Email is received whenever things change
Conflict: None
Requirement #: 10 F
Description: Either the online registration system is only open during office hours or a
telephone registration has to be provided
Rationale: Fair access for all students
Fit Criterion: students who do not have internet access have equal opportunity of getting
into wanted classes
Conflict: None
Requirement #: 11 F
Description: Search should be allowed based on time professor and major
Rationale: More precise choice of the courses
Originator: Focus group / Advisors’ meeting
Fit Criterion: Easy browsing and choice of the courses from catalogue
Conflict: None
Requirement #: 12 F
Description: Emailing system for prerequisite in case a requested prerequisite is not met
Rationale: Faster requests of possibility of skipping prerequisites


Fit Criterion: Send email when the prerequisite is not taken
Conflict: None
Requirement #: 13 F
Description: Emailing system to contact advisor about a class
Rationale: Solving doubts about the course
Fit Criterion: the student gets suggestions from the advisor
Conflict: None
Requirement #: 14 F
Description: Final schedule emailed to students when registration is over
Rationale: Gives a concrete image of all the classes together.
Fit Criterion: The student receives the definite schedule for the semester
Conflict: None
Requirement #: 15 F
Description: A report should be generated for the registrar indicating when waiting lists
for courses become very long
Rationale: Notifies the registrar with possible new sections that need to be created
Fit Criterion: Whenever there is a massive waiting list the registrar gets notified about it
Conflict: None
Requirement #: 16 F
Description: Associated with course information a syllabus with list of books
Rationale: The students can check the syllabus from the system

Fit Criterion: The student downloads the syllabus with any information needed
Conflict: None
Requirement #: 17 F
Description: Selection of classes on the basis of personal criteria:
• Taking the same classes as someone else
• Having classes only in the afternoon
Rationale: The students chooses the classes according to his “needs”
Fit Criterion: The student who wants only afternoon classes can browse only those
according to this criterion
Conflict: None
Requirement #: 18 Integration
Description: The system shall integrate with the university database.
Rationale: Input is required from the database and registration information will be
stored in the database.
Originator: our analysis
Fit Criterion: Input/output to DB works
Supporting materials: None
Conflict: None
Requirement #: 19 F
Description: The system shall allow for suggestions by users (e.g. notes on missing or
unclear information).
Rationale: Given the dynamicity, size, and complexity of the information on course
schedules it is possible that mistakes or inconsistency are present in
database, or in the presentation. Allowing users to report on such problems,
and taking timely actions to correct them can significantly improve the
reliability of the data.
Originator: our analysis
Fit Criterion: availability of a "suggestion form" which reaches the appropriate person
who may take care of any problem

Supporting materials: None
Conflict: None
10. Look and Feel Requirements

10a. Appearance Requirements
The AUP logo and the current basic design of AUP registration system should be displayed. The system
should be attractive according to the university-level students. The design and the color should make
users feel comfortable when using the system instead of flashing useless colors on the screen. The design
should also reflect the seriousness of the AUP environment.
10b. Style Requirements

The overall style should be built up easily in order for users to use it easily and efficiently. After
accessing the system, the users should feel comfortable while looking at it and browsing through it. The
design should not be too colorful to maintain a certain seriousness of the web design of the college but at
the same time it should not be too boring for the eye, so that it can appear pleasant to use.
11. Usability and Humanity Requirements

11a. Ease of Use Requirements
The system should have an easily understandable design in order for users to use it. It should provide the
necessary information when the user commits possible errors. It should indicate the several possibilities
that the user has to go on in using the system. The user will be allowed to undo any of the operation
computed or, for irreversible operation, will always be asked to double-check their choice in case they
misunderstood the option or clicked on a button by accident. The system will have easy access to help
center whenever the user needs any kind of assistance. The system will also provide a tutorial page where
it will explain the functionalities provided by the system.
11b. Personalization and Internationalization Requirements

The registration system will provide be presented as a part of the AUP website, which is only offered in
English and French. However, the system is thought as registration tool for students who are already
enrolled in the University. Therefore, since the system is being thought for an American educational
institute, the system will be provided in English. Perhaps, only the guest tour, that will be available to all
the visitors, should be offered also in French as the rest of the website is.
11c. Learning Requirements

It should not require a massive amount of time learning how to use the system. In fact, our goal is to
create a self-explanatory system that does not ideally need any tutorial section. However, we are
conscious of the different levels of confidence that the AUP students might have with the media tools.
We will therefore provide a “tutorial” section that will concretely solve any possible problem concerning
the use of the system.

11d. Understandability and Politeness Requirements

The system will not use any term that is not specified in the AUP catalogue. The whole dictionary utilized
by the system is supposed to be at least familiar if not completely acknowledged by the user. However, all
the vocabulary and metaphors might be further explained in the “tutorial” section.
11e. Accessibility Requirements

The system should also consider people with common disabilities and should make possible access to
registration system. For example, since approximately 20% of males are red-green colorblind, the system
should be designed in different colors avoiding red and green. Also, all the buttons that need to be clicked
should be big enough to be clearly distinguished also by people who have sight issues.

12. Performance Requirements

12a. Speed and Latency Requirements
The system is required a fair amount of speed especially while browsing through the catalogue and
presenting different possibilities for the schedule. The outcomes of the product are not directly influenced
by its speed, because all the operations are linked to each other and one operation can not be computed
before the one causing it.
12b. Reliability and Availability Requirements

The reliability of the system is directly linked to the level of update of the documents to which it is
correlated, such as the catalogue or the students’ database. The system and the external documents must
be updated constantly according to the necessities of the stakeholders. Both catalogue and database will
have to be available to students 24/7. The official registration, however, should be allowed only during
office hours, in order to prevent those students who do not have Internet at home to be disadvantaged
with regard to those who instead do.
12c. Robustness or Fault-Tolerance Requirements

When the system is disconnected or frozen due to over access at the same time, it should save all the
process of the users have made up to the point of abnormal happenings. When the users log in with the
same id, all the work should be provided.
12d. Capacity Requirements

The system should be able to manage all the information incoming from the database and the catalogue.
13. Operational and Environmental Requirements

13a. Expected Physical Environment
The product is Web based therefore it will be used in any environment that allows Web access.
13b. Requirements for Interfacing with Adjacent Systems

For the system to successfully operate the registration system should be integrated with other IT services
and the AUP portal.
14. Maintainability and Support Requirements

14a. Maintenance Requirements
To ensure the functionality for the maximum period of time, the database and the catalogue must be
updated at least every semester. Also, the system should timely integrate modification suggested by
stakeholders (see requirement 19F).
14b. Supportability Requirements

The system should need to be entirely self-supporting since the users would be using it only to register

courses.
14c. Adaptability Requirements

The Web interface should be compatible with standards in order to be usable via all major Web browsers
in a wide variety of environments.
15. Security Requirements

15a. Access Requirements
Everyone (stakeholders and guests) can have access to the system and the catalogue. Every student must
have secure and private access to his/her data. The ITS and the registrar can have access to every part of
the system. All these accesses (except the “guest tour” access) require identification through ID and
password.
15b. Integrity Requirements

Data integrity should be assured by limiting access to the database and by appropriate synchronization,
and back-up functionalities.
15c. Privacy Requirements

The system will provide a protection of the database such as the one that the university already provides.
However, the system will have to increment this level of protection because of the personal data made
available on the system, and the larger share of people that will be having access to it through the online
registration.
The users’ privacy will be granted by the limited access that the log-in process is going to give to the
database. Also, the system does not grant direct access to the database itself. Stakeholders who need to
access the database will have to access it from a source independent from the registration system.
15d. Immunity Requirements

The system will develop a security system that will reduce to the minimum the possibility of corruption
from systems and/or humans.
16. Cultural and Political Requirements

16a. Cultural Requirements
The system should use as little icons and cultural interpretation of figures as possible. AUP has a multi-
cultural community. Therefore, the system can not give for granted nor use cultural knowledge such as
iconography or symbols that are not internationally recognized, or some of the clients of the system might
have some difficulties when using it.
16a. Political Requirements

There are no political involvements in this system design.

17. Open Issues

• Hierarchy in base of which the waiting list will be organized. Does a senior student majoring in Art
History have priority over a junior student majoring in business for the ranking in a class such as
BA330 (Human Resources Management)?
• The system should assist students in becoming acquainted with AUP administration, so that they know
who to refer to for every problem they might have
• Students should not be registered if they have not paid their fees.
• Possibility to have students "temporarily" registered, or "unofficially" registered
• Possibility to create moke-up just as in the course browser
18. New Problems

18a. Effects on the Current Environment
The problems that might emerge from the creation of the registration system are the following:
• The student might reveal the need of a more personal contact with the advisor than the one that the
system will provide. This problem will directly enlarge the distance between
professors/advisors/administration and the students.
• It might be more difficult to allow exceptions to prescribed processes and requirements.
• Whenever a heavy technical problem occurs, the registration system might cause sever delays to the
whole registration process.
18b. Effects on the Installed Systems

The existing "course browser" will become obsolete as soon as the online registration system is active. In
fact, the new system will also browse through the courses without needing to officially register.
18c. Potential User Problems

Every page of the system is very clear, simple and pleasant. Every student will find out how easy the
system is to use as soon as they start acceding to it. The only issues they might encounter concerns the
poor or late update of the database or the difficulties for each case. For that matter, the system will
provide several contacts to gather all the information needed to solve any problem.
18d. Limitations in the Anticipated Implementation Environment That May Inhibit the New Product
The implementation environment for the system is not known at the time of writing therefore we cannot
state exactly its limitations. We expect however peak-load periods for the server at staggered registration
times.
18e. Follow-Up Problems

Significant changes in the methodologies and regulation for the registration process may make the
product obsolete.

19. Tasks
19a. Project Planning
No implementation plan has been made to date.
20. Migration to the New Product

We suggest that the migration to the online registration system will overlap, at least for the first times that
will be used, with the currently available paper-based system. The registrar office will have to at least
verify the operations that are being computed on the registration system to detect every unforeseen issue
that might come up. Once the system had been successfully used and proved efficient, it will be possible
to migrate to the new product.
21. Risks
The risks that might arise in the implementation of such a system are few; especially if we consider that
the system will be constantly monitored in the first years of its effective application, anything that might
be wrong will be almost instantly corrected by one of the stakeholders, be it the registrar or the ITS for
example. On a general level, however the main risks that this system is facing are:
• The possible overload of the system in the critical days during registration.
• The need of the stakeholders to update the catalogue.
22. Costs
Our concern about the system does not deal with its costs.
23. User Documentation and Training

23a. User Documentation Requirements
All user documentations should be supplied online. Different documentation should be foreseen for
different stakeholders (students, administration, ITS).
23b. Training Requirements

No training should be necessary for the students to be able to use the system (online help will be
provided). Some training may be necessary for those using the back-end interface (Registrar, Dean's
office). Training could be provided by ITS. The system should provide training material, and tutorials.

Appendix 1
Ceci est la version HTML du fichier http://www.wesleyan.edu/registrar/DropAddManual.pdf.

Lorsque G o o g l e explore le Web, il crée automatiquement une version HTML des documents récupérés.
Pour créer un lien avec cette page ou l'inclure dans vos favoris/signets, utilisez l'adresse suivante :
http://www.google.com/search?q=cache:4BSPmsj1EugJ:www.wesleyan.edu/registrar/DropAddManual.
a.
Google n'est ni affilié aux auteurs de cette page ni responsable de son contenu.
Les termes de recherche suivants ont été mis en valeur : online registration online drop add
Page 1
WESLEYAN UNIVERSITY
Registrar’s Office
Drop/Add
Manual
Page 2
WESLEYAN UNIVERISTY – OFFICE OF THE REGISTRAR
Drop/Add Manual
© Wesleyan University – Office of the Registrar
North College, 237 High Street
Middletown, Connecticut
Phone (860) 685-2810 • Fax (860) 685-2601
Page 3
Table of Contents
INTRODUCTION
1
AVAILABLE HELP
2
ACCESSING THE SYSTEM
3
STUDENT

3
Adding An Enrollment Request
4
Canceling A Request
5
Dropping A Course
6
Instructor-Initiated Drops
7
Advisor Action
7
Credit Limit
7
Cross-listing and Grading Mode Changes
8
INSTRUCTOR
8
Viewing Available Drop/Add Information for Courses
9
Adding a Student to the Class List
9
Notes to Instructor
10
Dropping a Student from the Class List
10
Student-Initiated Drops
11
Closing a Course
12
ADVISOR
12
Viewing Advisee Drop/Add Information
12
Advisor Actions
13
Approving a Drop/Add Request
13
Disapproving a Drop/Add Request
13
See Advisor
13
Semester Credit Limits and Credit-Limit Overrides
13
Page 4
WESLEYAN
UNIVER SITY
-
REGISTRAR ’SOFFICE
Introduction
Overvi
he electronic Drop/Add system allows instructors to determine who will be offered a
seat in their class. The system is designed to replace the paper Drop/Add form and

provide information about course enrollment (available seats) during the Drop/Add
period. Drop/Add transactions will happen in real-time on the computer instead of by
signing and submitting paper forms.
ew of the System
T
To add a class, the student must submit an electronic enrollment request, the instructor must
offer the student a seat in the class by accepting the electronic request, and the advisor must
approve the transaction. To drop a class the student must submit a drop request. The student
will then be dropped automatically from the instructor’s class list and the advisor must approve
the completed transaction.
The electronic Drop/Add process will
1. Eliminate the paper Drop/Add form and provide students and faculty with an
electronic Drop/Add submission process.
2. Facilitate and enhance academic advising through timely notification of drops and
adds and the ability to view these in conjunction with the students' full schedules.
3. Provide students and faculty with up-to-date class enrollment figures.
4. Improve class access.
5. Utilize information collected as electronic enrollment requests.
6. Lengthen the Drop/Add period to ten days and no longer require the red/black
distinction.
1
DROP/ADD
8/22/05
Page 5
WESLEYAN
UNIVER SITY
-
Availab
here are several ways to obtain additional help during the Drop/Add period:
le Help
Staff from the Registrar’s Office will be available to answer any questions you
may have through the Drop/Add Help Line. The phone number of the Drop/Add Help
Line is x3222, or (860) 685-3222, if you are dialing from off-campus. The Help Line is
open during normal business hours, Monday through Friday from 8:30 a.m. to 5 p.m.,
from the first day of classes when Drop/Add begins until the end of the Drop/Add
period, the morning of the eleventh day of classes. You may leave a message after hours
and a staff member will get back to you during business hours.
T
Graduate Students may also contact Barbara Schukoske, Assistant to the Director of
Graduate Student Services, at x2224 if they have questions.
You may also access the Drop/Add Frequently Asked Questions page at any time at
http://www.wesleyan.edu/registrar/dropaddfaq.html. This page contains a link to
Common Error Messages with explanations.
If you have a technical problem, you can either call the help line, or you can call the ITS

Help Desk directly at 4000. If you have a problem with a username or lost password, you
can call Information Technology Services directly at ext. 2128 or 2132.
If you have an advising problem, you can also try to reach help directly by contacting the
Dean of the College’s office at ext. 2600.
DROP/ADD
8/22/05
2
Page 6
WESLEYAN
UNIVER SITY
-
Acc
tudents and faculty will access the electronic Drop/Add system through their portfolios.
As faculty have two primary roles in Drop/Add, they will have two paths to access the
Drop/Add system, one as course instructors to drop and add students from their courses
(by clicking on Course Management under “Courses”), and one as advisors to review
advisee schedules and perform advisor actions (by clicking on Drop/Add under “Advising).
essing the System
S
Student
Once in their portfolios, students will find the Drop/Add link (1) in the Course Registration
box (2) under “Courses at Wes” (3), as shown in the frame below. Once students have
entered the system, they have the option of adding and deleting course enrollment requests.
3
2
1
3
DROP/ADD
8/22/05
Page 7
WESLEYAN
UNIVER SITY
-
ENROLLMENT REQUESTS
Students had the opportunity to submit four ranked enrollment requests during On-Line
Registration for courses in which they were unable to obtain a seat. During Drop/Add, the
system allows students to submit additional unranked course requests. When students first access
the Drop/Add system, they will see WesMaps (1), their current approved schedule (2), and any
ranked Enrollment requests they made during On-Line Registration (3), as shown below.
1
2
3
1. WesMaps
2. Current Course Schedule
3. Ranked Enrollment Requests
TO ADD AN ENROLLMENT REQUEST
From here, students may add additional course enrollment requests. Students may now use
WesMaps during drop/add to search for courses that have available seats. In the new

Drop/Add system, WesMaps course pages will show updated enrollments that reflect drop/add
activity, thereby allowing students and advisors to assess efficiently which courses may still have
space. (These pages are updated nightly to reflect completed drop/add transactions as recorded
in the University database.)
Students may search WesMaps using the “Class with Seats Available” link (figure 1a above and
also elsewhere in WesMaps) or by using the other search capabilities. Once the student has found
an appropriate course, she will click on the highlighted course number link to view the course
description. If the student is interested in adding this course to her enrollment request, she will
select the grading mode and crosslisting (if applicable) and click the button “Add to My
Enrollment Requests.” Once this button has been clicked, the course appears under “Pending
DROP/ADD
8/22/05
4
Page 8
WESLEYAN
UNIVER SITY
-
Enrollment Requests” (figure 3 above) and appears in the instructor’s portfolio for the instructor’s
review.
As this is only an enrollment request, students may submit a request for any class. The system
will not prescreen students for major status or class year. The system will check the student’s
academic history record to confirm whether the prerequisite(s) has been met. An indication of
this will appear as a column on the enrollment request list. This is informational only and will not
prevent a student from enrolling if the instructor has allowed the student into the course.
Students cannot change their original request rankings at this point or add a rank to a new request.
Students may send a message to the instructor by clicking on the “Note to Instructor”
button, which brings students to a text box that allows them to submit a brief note to the
instructor. This message is viewed by the course instructor only.
Should the instructor admit the student, the course enrollment will move from “Pending
Enrollment Requests” to the student’s in-process schedule (“Drop Add Transactions”),
highlighted in green with a status of “Instructor Add” and the notation “Advisor Pending” in the
“Approval” column (see PHYS214 in the figure below).
A student may cancel a pending enrollment request at any time by clicking the “Cancel” box.
Should the instructor not approve the add, the enrollment request will not be altered. The
request will remain in “Pending Enrollment Requests” on the student’s Drop/Add portfolio page
unless the student cancels it.
The add is not final until approved by the advisor. Should the advisor approve the add, the
student will see “Advisor Approved” in the approval column next to the course, and it will
become official and turn white in the “Drop/Add Transactions” schedule overnight. If the
advisor “disapproves” the add, the student will see “Advisor Disapproved” in the approval
column, and the course will be deleted from the schedule. Until the advisor takes an action,
that column will say “Pending Advisor.” If the advisor wants to discuss the add request, “See
Advisor” will appear in that column.
DROP/ADD
8/22/05
5
Page 9
WESLEYAN
UNIVER SITY
-
TO DROP AN ENROLLMENT
Students may drop a course they are enrolled in using the online Drop/Add system. In their in-
process schedule (Drop Add Transactions), students will click the box in the “Drop” column for
the appropriate course and then click on the “Submit Class Drop” button (see PHYS124 in

figure 1 below).
1
Once the student has submitted a class drop request, a confirmation page appears (as below) so
that the student may either finalize the drop or cancel the transaction.
When the student reviews the schedule he or she will see at the top of the schedule screen that
there is a note “Successfully Created Drop Request” (figure 2) and the “dropped” course is
highlighted on the student’s course grid. The “Status” column indicates that the student initiated
the drop. The “Approval” column indicates the advisor’s approval of the drop is pending.
DROP/ADD
8/22/05
6
Page 10
WESLEYAN
UNIVER SITY
-
2
When the student confirms the class drop by clicking the button, he or she is
automatically dropped from the course and would need to submit a new enrollment
request to be added to the class again.
INSTRUCTOR-INITIATED DROP OF AN ENROLLMENT
Consistent with the EPC Statement on attendance, an instructor may drop a student from his or
her class list should that student fail to attend the first class session and to communicate directly
with the instructor prior to the first class. If a student has been dropped from the course by the
instructor, the student will see “Instructor Dropped” in the “Status” column. The student would
need to submit a new enrollment request to be added to the class again.
ADVISOR ACTION
The advisor has access to the advisee’s current in-process schedule and drop/add requests. The
advisor may approve drop/add requests, disapprove them, or request a meeting with the student
to discuss the schedule. If the advisor disapproves an add request, “Advisor Not Approved” will
show in the “Status” column and the course will eventually be deleted from the student’s
schedule. If the advisor disapproves a drop, the student, advisor, and instructor would need to
explore the feasibility of the student’s being readmitted to the class. If the advisor would like to
meet with the student before taking action, “See Advisor” will show in the “Advisor” column
under “Pending Enrollment Requests.” In this case, the student should see the advisor to discuss
the schedule.
CREDIT LIMIT
To meet graduation requirements, undergraduates are expected to enroll in four courses a
semester. In order to keep untaken seats available, the system will automatically enroll an
undergraduate student in no more than four courses that carry a value of 1.00 or greater
(excluding tutorials, private music lessons, and all partial-credit courses) and a graduate student in
no more than six courses that carry a value of 1.00 or greater (excluding tutorials, private music
lessons, and all partial-credit courses). If a student has a legitimate pedagogical reason to exceed
the credit limit, she must request a credit-limit override from the advisor. Students accepted into a
course that exceeds their limit will need either to drop a course or seek a credit override to add the
new class. A student who submits a request for enrollment in a course that would exceed
her limit will see that the extra course appears highlighted in red. If the student has not
DROP/ADD
8/22/05
7
Page 11
WESLEYAN
UNIVER SITY
-
dropped another course or obtained a credit-limit override by 5:00pm of the next business
day, the nightly process will return the seat in the extra course to the instructor. Students

are encouraged meet early with their advisors if they have reasons for a credit overload so that
they do not risk losing seats in required courses.
CROSSLISTING AND GRADING MODE CHANGES
Changes to the grading mode or cross-listing of a course must be made in the Drop/Add system
before Drop/Add. Courses that allow for this type of change will have a drop-down selection in
the schedule or enrollment request list. The student must select the new grading mode or cross-
listing from the drop-down menu. If a drop-down menu does not appear in the cross-listing or
grading mode column, this means that the course is not cross-listed or only has one grading
mode.
Instructor
Instructors may use the Drop/Add system to add students to classes and to delete students who
do not attend the first day of class or communicate directly with the instructor prior to that class
(consistent with the EPC Statement). Instructors will access the electronic Drop/Add system by
selecting Course Management (1) under ‘Courses (2), and selecting a specific course in the drop-
down menu at the top of the page which opens up.
2
1
3
DROP/ADD
8/22/05
8
Page 12
WESLEYAN
UNIVER SITY
-
Once the instructor selects a specific course, the available options for viewing information appear
on the screen: “Enrollment Requests” (4 below) will allow the instructor to view all add
requests from students and add students to the class. “Class Totals” (5) will show a
summary of current enrollment and enrollment requests by class year and major/non-major
status. “Class Enrollment” (6) will allow the instructor to view a real-time classlist, with
the option to delete students from the class (consistent with the EPC statement).
5
6
4
TO ADD A STUDENT TO THE CLASS LIST (“ENROLLMENT REQUEST” LIST)
As soon as a student completes a course enrollment request in her portfolio, the student’s name
appears highlighted on the instructor’s Enrollment Request page. In the figure below, the
instructor has one enrollment request. Students may add four ranked enrollment requests during
online registration. If the student requested the course during a previous semester, a hyperlinked
number corresponding to the number of semesters the course was requested will appear in the
Previously Requested column. Click on the hyperlinked number in the Previously Requested
column to view detailed information about the earlier requests (7). The fact that the request below
is unranked indicates that this student added the request after Online Registration.
7
To accept the request and add the student, the instructors will check the box by the student’s
name in the “Enroll Student” column (1 below) and click on the “Enroll In Class” button (2). If
there is a long list of requests, there will be an “Enroll All” box at the bottom of the list.
DROP/ADD
8/22/05
9
Page 13
WESLEYAN
UNIVER SITY
-
If the instructor does not wish to add the student, the instructor takes no action.
1

2
When the “Enroll in Class” button is clicked, a confirmation page appears (as below) to verify
that the instructor does indeed wish to enroll the student. The instructor can cancel the process at
this point or click the “Confirm Enrollment” button to complete the process.
NOTES TO INSTRUCTOR
Students have the opportunity to send a note to the instructor when they create an enrollment
request. Instructors can view these messages when they review the enrollment requests by
clicking the link “Read Note” in the far right column.
DROP/ADD
8/22/05
10
Page 14
WESLEYAN
UNIVER SITY
-
A text box with a brief message (limited to 500 characters) will appear:
Instructors will receive a nightly email directing them to new enrollment requests and deletions.
However, instructors are strongly encouraged to check their Enrollment Request and Class
Enrollment pages regularly in order to have up-to-date class enrollment figures and improve the
course enrollment process.
TO DROP A STUDENT FROM THE CLASS (“CLASS ENROLLMENT” LIST)
Consistent with the EPC Statement on attendance, the system allows instructors to delete those
students who do not come to the first day of class and do not communicate directly with the
instructor prior to the first day of class. Instructors are encouraged to print out their classlist, take
attendance, and after verifying absences, delete those students who did not present themselves.
This will provide accurate enrollment figures for the instructor and for those students who may
wish to add the course.
The Class Enrollment page allows the instructor to view a classlist that includes all recently
accepted adds and includes a “drop” function. To drop a student from the class, the instructor
will click the box in the “Drop” column for the appropriate student, then click the “Drop From
Class” button at the bottom of the page.
After clicking this button, the instructor will be asked to confirm the drops. The instructor may
cancel the process at this point or proceed with the drop. If for some reason a student is dropped
DROP/ADD
8/22/05
11
Page 15
WESLEYAN
UNIVER SITY
-
DROP/ADD
8/22/05
12
from a class in error, the student will need to complete an enrollment request and go through the
process of obtaining approval of instructor and advisor to be readmitted to the course.
STUDENT-INITIATED DROPS
Students may drop from an “enrolled” course or cancel an enrollment request using the
Drop/Add system. For enrolled courses, students click on a “Drop” box in their schedule and
click on the “Submit Class Drop” button. No action is required on the instructor’s part for a
student to drop a course.
Once the student has submitted a drop request, his or her name is immediately removed from the
instructor’s Course Enrollment page (under “Enrollment Requests in the portfolio menu) to
show real-time enrollment figures. The instructor’s official classlist, however (under “Classlists”
in the portfolio menu), will be updated nightly with the University database.
CLOSING A COURSE
Instructors can indicate that a course is closed by clicking the “Close This Course” button which

appears above the enrollment requests for the course. Clicking on the button will send a message
to all of the students enrolled in the course, informing them that the class has been closed and
encouraging them to leave their names on the enrollment request lists in the event that space
becomes available later. Students who request a space in the course after it has been closed will
see a message indicating that the course is closed, encouraging them to still submit a request in
case space opens up. Instructors will still be able to enroll students in the course after they have
closed it.
Advisor
The online Drop/Add system gives the advisor the capability to approve or disapprove course
enrollment requests and drop requests or to indicate that the student should see the advisor to
discuss the requests. In the Drop/Add system, advisors also have the capability to authorize a
credit overload for particular advisees.
VIEWING ADVISEE DROP/ADD INFORMATION
Advisors access the electronic Drop/Add advising pages by clicking on Drop/Add (1) under
‘Advising’ (2). The list of advisees will appear in the page (3), and the name of any advisee
who requires an advisor action will be highlighted. (The names in the figure below are
deleted for the purpose of this document.)
Page 16
WESLEYAN
UNIVER SITY
-
2
1
3
Clicking on a student’s name will allow the advisor to view that student’s current schedule
(“Drop Add Transactions,” 1) and any pending drop/add requests (Pending Advisor
Approval, 2).
1
2
ADVISOR ACTIONS
If the instructor has not yet accepted the student’s add request, the “Approve” column will show
“Pending Inst Action” (as in the first three rows above). The advisor takes no action at this point.
If the instructor has accepted the add request, or if the student is requesting a drop from a class,
DROP/ADD
8/22/05
13
Page 17
WESLEYAN
UNIVER SITY
-
DROP/ADD
8/22/05
14
the “Approve” column will show a pull-down box for advisor action. The advisor may
“approve” the add or drop, “disapprove” the add or drop, or choose “See Advisor” to indicate
that a meeting with the student is necessary to discuss the request.
“APPROVING” A DROP/ADD REQUEST
To approve an add or drop, the advisor will choose that option from the pull-down menu in the
“Approve” column, then click the “Submit” button. The advisor will be given a chance to cancel
or confirm the action.
If the advisor confirms the approval, “Advisor Approved” will appear immediately in the
student’s in-process schedule (“Drop/Add Transactions”) and in the course instructor’s Class
Enrollment list. Overnight, the class will move to the student’s official schedule and the
instructor’s official classlist.
“DISAPPROVING” A DROP/ADD REQUEST
To “disapprove” an add or drop request, the advisor will choose “disapprove” from the pull-
down menu. The advisor will be given a chance to cancel or confirm the action.
Once the “disapprove” action is confirmed for an add request, that course will be deleted from
the student’s schedule by the staff of the registrar’s office. If an advisor disapproves an advisee’s
drop of a course, the student would need to submit a new enrollment request, and the advisor,
student, and instructor would need to explore the feasibility of the student’s being readmitted to
the class.
Due to the repercussions of this action, advisors are encouraged to use “disapprove” only when
they mean explicitly to reject a drop or add for a student, and to use “See Advisor” to initiate a
discussion about a particular drop or add that may be in question.
“SEE ADVISOR”
After reviewing an advisees’ enrollment request, the advisor may wish to meet with an advisee to
discuss their course decisions. Advisors can click the “Meet with Advisor” button to initiate this
meeting.
GRANT CREDIT OVERRIDE
In order to keep untaken seats available, the system will enroll an undergraduate student in no
more than four courses that carry a value of 1.00 or greater (excluding tutorials, private music
lessons, and partial-credit courses) and a graduate student in no more than six courses that carry a
value of 1.00 or greater (excluding tutorials, private music lessons, and partial-credit courses). If a
student has a legitimate pedagogical reason to exceed the credit limit, she must request a credit-
limit override from the advisor.
To grant a credit-limit override, the advisor will click on the advisee’s name to view her drop/add
information page. At the top of the advisee’s information page, the advisor will use the pull-down
menu (see arrow below) to select a new course limit for the student (keeping in mind the courses
not included in this limit, listed above).
Page 18
WESLEYAN
UNIVER SITY
-
When a student requests enrollment in a course that would put her over her credit-limit, the
student, advisor, and instructor will see “Instructor Add Exceeds Limit,” and the course/student’s
name highlighted in red. If the student has not dropped another course or obtained a credit-
limit override by 5:00pm of the next business day, the nightly process will return the seat
in the extra course to the instructor. Students are encouraged to meet with their advisors to
discuss any reasons for requesting an override well in advance so that the student does not risk
losing seats in required courses.
The advisor has the option of approving individual “extra” courses without approving a credit-
limit override, thereby allowing the student to choose which courses to keep.
THE STUDENT PROCESS
The beginning of this manual is written for students and describes the process through which
students make requests for drops and adds. Some of that information which may be useful to the
advisor is highlighted below.
Students are informed that no transaction is final until approved by the advisor.
Students may now use WesMaps search for all classes with available seats. This link is found on
the WesMaps homepage and is visible to students as soon as they open their own drop/add
information in their portfolio. These enrollment figures are updated nightly to reflect all
completed and official drop/add transactions.
Consistent with the standing drop/add procedures of the University, students may submit an
enrollment request for any class; the system will not screen for major status or class year. Students
may submit a “note” to the instructor to address these issues. When a student adds an enrollment
request, the system will check the student’s academic history to confirm that they have met the
prerequisite(s). An indication of this will appear as a column in the instructor’s enrollment request
list. This is informational only and will not prevent a student who has not met the prerequisite(s)
from enrolling in the course if the instructor has chosen to accept the student.

DROP/ADD
8/22/05

Volere Specifications Example PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Volere Specifications Example PDF

Uploaded by

Copyright:

Available Formats

Online Registration System

CS/CM 348 SP07 – human Computer Interaction 1

CS/CM 348 SP07 – human Computer Interaction 2

1. The Purpose of the Project

CS/CM 348 SP07 – human Computer Interaction 3

1b. Goals of the Project

CS/CM 348 SP07 – human Computer Interaction 4

2. The Client, Customer, and Other Stakeholders

2b. The Customer

2c. Other Stakeholders

CS/CM 348 SP07 – human Computer Interaction 5

3a. The Hands-On Users of the Product

3b. Priorities Assigned to Users

3c. Maintenance Users and Service Technicians

4a. Solution Constraints

4b. Implementation Environment of the Current System

4c. Partner or Collaborative Applications

4d. Off-the-Shelf Software

4e. Anticipated Workplace Environment

4f. Schedule Constraints

4g. Budget Constraints

5. Naming Conventions and Definitions

6. Relevant Facts and Assumptions

7. The Scope of the Work

7b. The Context of the Work

7c. Work Partitioning

Event Name Input and Output Summary

CS/CM 348 SP07 – human Computer Interaction 9

8. The Scope of the Product

8b. Product Use Case List

CS/CM 348 SP07 – human Computer Interaction 10

9. Functional and Data Requirements

CS/CM 348 SP07 – human Computer Interaction 11

CS/CM 348 SP07 – human Computer Interaction 12

CS/CM 348 SP07 – human Computer Interaction 13

Originator: Focus group

CS/CM 348 SP07 – human Computer Interaction 14

CS/CM 348 SP07 – human Computer Interaction 15

10. Look and Feel Requirements

10b. Style Requirements

11. Usability and Humanity Requirements

11b. Personalization and Internationalization Requirements

11c. Learning Requirements

CS/CM 348 SP07 – human Computer Interaction 16

11d. Understandability and Politeness Requirements

11e. Accessibility Requirements

CS/CM 348 SP07 – human Computer Interaction 17

12. Performance Requirements

12b. Reliability and Availability Requirements

12c. Robustness or Fault-Tolerance Requirements

12d. Capacity Requirements

13. Operational and Environmental Requirements

13b. Requirements for Interfacing with Adjacent Systems

14. Maintainability and Support Requirements

14b. Supportability Requirements

CS/CM 348 SP07 – human Computer Interaction 18

14c. Adaptability Requirements

15. Security Requirements

15b. Integrity Requirements

15c. Privacy Requirements

15d. Immunity Requirements

16. Cultural and Political Requirements

16a. Political Requirements