Project Atlantis: Conceptual Design Document

Table Of Contents

• Executive Summary
• Introduction
• Management Plan
  1. Features of the System
  2. Classes of Functions
  3. Component Interaction
  4. Evaluation of Functional Specification Comments
  5. Project Atlantis Implementation Timeline
  6. Division of Work in the Development Team
• Context Diagrams
  1. Features of the System
  2. Classes of Functions
• Entity Relationship Diagrams

  Legend

  1. Overview
  2. Administrator Diagrams
  3. Student Diagrams
• Data Dictionary
  1. Entity: Student
  2. Entity: Administrator
  3. Entity: Class
• Data Flow Diagrams

  Legend

  1. User

     1.0.0 User Login

  2. Student

     2.1.0 Student System

     2.2.0 Change Password

     2.2.1 View Timetable

     2.2.2 Course Registration

     2.2.3 View Courses Taken

     2.2.4 View Course Information

     2.3.0 Add Course

     2.3.1 Drop Course

  3. Administrator

     3.1.0 Administrator System

     3.2.0 Assigning Grades

     3.2.1 Overload a Course

     3.2.2 Modify a Course

     3.2.3 Add a new Course

     3.2.4 Remove a Course

     3.2.5 Add a new Administrator

     3.2.6 Modifying an Administrator

     3.2.7 Overriding Co/Pre-Requisites

     3.2.8 Modifying a Student

     3.2.9 Add a new Student

     3.2.10 Change Password

     3.2.11 Set Trimester Deadlines

• User Interfaces
  1. General Interfaces

     1.1 Login

     1.2 Logout

     1.3 Change Password

  2. Student Interfaces

  2.1 Main Menu

  2.2 View Timetable

  2.3 Register in Course

  2.4 Drop Course

  2.5 Access Calendar Information

  2.6 View Course Availability

  2.7 View Courses Completed

  3. Administrator Interfaces

     3.1 Main Menu

     3.2 Assign Grades

     3.3 Overload Course

     3.4 Add Course

     3.5 Modify Course

     3.6 Remove Course

     3.7 Set Trimester Deadlines

     3.8 Add Student

     3.9 Modify Student

     3.10 Override Co/Pre-Requisites

     3.11 Add Administrator

     3.12 Modify Administrator

• Walkthroughs
  1. Student Task Scenario
  2. Administrator Task Scenario
• Summary
• Glossary

Introduction

next previous top

This document outlines the formal design of the Project Atlantis Registration System. In this document, we plan to discuss all aspects of functionality of the aforementioned system. After careful consideration of the informal specifications outlined in the Informal Specification of Requirements document, as well as comments contained in Evaluation of Functional Specification and Management Plan document, Wintersoft feels that we have a high level of understanding of the University of Atlantis’ system requirements and needs. With this knowledge, we are confident that the Project Atlantis Registration System will meet these needs.

The content of the following document includes the Management Plan, where we outline various aspects of the system and address the University of Atlantis’ concerns regarding the Functional Specifications and Management Plan. In addition, the Management Plan includes the timeline of internal deadlines. Furthermore, this document includes diagrams that assist in the clarification of relationships between the system and its users and the data that is exchanged by them. As well, prototypes and walkthroughs of the system are provided to illustrate possible user interactions.

Management Plan

next previous top

The Management Plan outlines the basic features of Project Atlantis. Discussion of the different types of users and how they interact with the system provides an overview of Project Atlantis. It also provides Wintersoft with the opportunity to discuss component interaction and the features offered by the system. This section also provides a timeline by which the University of Atlantis can measure our progress. Finally, the division of work is provided so that specific teams may be contacted if there are any concerns with a particular aspect of the system.

1. Features of the System

next previous top

• All users will be required to login to the system using their unique assigned ID number.
• The system will consist of a timetable scheduling system for students, professors and administrators.
• The system will allow students to enroll, drop and change registration in classes. To be able to do this conveniently, the students must be able to display the courses that are being offered and the information associated with a particular course. The system will allow the student to be placed on a waiting list in the event that a class is full.
• The system will also allow the student to access grades from previous courses that they have completed.
• The students will be able to view their schedules at all times while logged on the system.
• Professors and administrators will be able to add and delete course from the course database as well as edit courses and their personal information. They will be able to enter course descriptions and set the time and place at which the courses will be held.
• For security purposes, all users are required to logout when they are finished using the system. The system will automatically log them out if there is a period of six minutes or more of inactivity.

2. Classes of Functions

next previous top

The system will be comprised of the following components: users and courses. All functionality of the system will involve the interaction of these two components.

The user component consists of instructors/administrators and students. Each of the two user groups will have different capabilities according to their access level.

The student level of access allows the user to construct and modify their course timetable, view grades from courses already taken and change their password.

The main functionality of an administrator is to access student information and to add users to the system. As well, administrators are able to manage the course database.

The course component contains all information relative to a course, which consists of:

• Name and Number
• Lecture, lab and tutorial sections
• Location (room, building)
• Length of each section
• Instructor
• Description
• Pre-requisite(s) and Co-requisite(s), if applicable
• Class list
• Maximum class size
• Waiting list

To create a new course, its name and number is required. For each course name, the course number, lecture number, lab number, tutorial number, description and waiting list must be unique. Since classes often become full, waiting lists will be used.

3. Component Interaction

next previous top

Users and Courses

The two types of users interact with the course component differently. Student users add courses to their timetables and can view course attributes.

The administrators will interact with the student and course information but will have little interaction with the scheduler. Administrators have the ability to add students and courses to the system as well as access and edit student and course information.

4. Evaluation of the Functional Specification and Management Plan Comments

next previous top

Wintersoft takes any comments and concerns from the University of Atlantis very seriously. We have studied the Evaluation of Functional Specification and Management Plan document and would like to clarify the following concerns. Subsequently, we are confident that our system design will be a more accurate reflection of the University of Atlantis' requirements.

• An important issue is the inappropriate language in our document. Wintersoft would like to offer sincere apologies for that serious oversight in business etiquette and also deliver an assurance that such a violation of protocol will not occur in the future.
• We would like to clarify that our system warranty expires April 12th, 2001. Also the warranty is void in Hawaii and Alaska.
• Wintersoft understands that the emphasis of Project Atlantis is on student functionality, which includes viewing and editing trimester timetables.
• Administrators can set trimester deadlines.
• The logout feature will be implemented to automatically log out the user after 6 minutes of inactivity. We had included this feature in our design, but had failed to specify this in the document.
• Wintersoft would like to clarify that the expression "enter" used in the context of data input from the user will not restrict this to typed input from a keyboard.
• Wintersoft does not make it a policy to develop software that is not user-friendly.
• It our understanding that a student dropping a course past the drop deadline will be assigned a grade of "W" to signify a withdrawal from the class.
• We would like to assure the University of Atlantis that the system will confirm any user choice that will involve modification of data in the database.
• A student will be able to change lecture/lab/tutorial section without dropping and re-registering in the course. We apologize for failing to mention this functionality explicitly.
• There will be a course list for each instructor, which will be checked for conflicts when they are assigned to teach a course. This course list will be used exclusively by the system.
• As requested, registration deadlines are set by an administrator for each trimester.
• Wintersoft understands the necessity of implementing a feature where, if course information is modified, the timetables of the students registered in this particular course are updated.
• Student and administrator records are not to be removed from the database, rather they are to be marked as inactive.
• The Management Plan section of our Functional Specification and Management Plan document suggests that only student functionality use is possible on-line. We understand that the whole system will have an on-line functionality as requested.
• Distinguishing between students and administrators will allow for the implementation of a more efficient interface.

We would like to thank the University of Atlantis for their constructive feedback. We are confident that the final product will benefit from this constructive exchange.

5. Project Atlantis Implementation Timeline:

next previous top

The following is an estimated timeline for the development process of the Project Atlantis Registration System.

• February 11th, 2001 - The Conceptual design document is completed and submitted.
• February 18th, 2001 - Evaluation of Conceptual design document. Acceptance tests are conducted.
• February 27th, 2001 - The System design presentation is conducted.
• March 4th, 2001 - The Technical design document is completed.
• March 25th, 2001 - The User manual is submitted to our customer.
• April 1st, 2001 - Evaluation of User manual and Change Request document begins.
• April 5th, 2001 - The Test report record is completed.
• April 6th, 2001 - Demonstration of the final product. Delivery of the Project Atlantis.

6. Division of Work Among the Development Team:

next previous top

User Database
David Hayes
Ai (Tino) Duong
Erin Moeller
Keith Kwong
Trudy Petersen
Dave Nilsson

Courses
Abu Sesay
Lucas Galek
Ian Ko
Jan Yangji
David Mitchell
Daisuke Kinjo
Saima Makhani

The purpose of this Management Plan was to outline the fundamental sections of the system. It provides a list of components and their interaction, giving a general idea of how the system will function. As well, it gives a general overview of sections that will be discussed in greater detail, later on in this document.

Context Diagrams

next previous top

Context diagrams give a brief view of the two different types of users and the functionality that they can perform in the system. They provide a very general view without specifying the technical details of how the tasks are performed.

Legend

next previous top

	The blue rectangles with rounded edges represent users who control the system.
	The yellow rectangles represents a the system, which responds to the requests of users.
	Arrows show requests and responses passing back and forth between the user and the system.

1. Student User Diagram

next previous top

The following diagram represents the relationship between a student user and the Project Atlantis Registration System. Interaction between the two entities is evident as the user sends requests for either data display or record manipulation and the system responds appropriately. For example, if a student wishes to delete a course, the system confirms the choice and deletes the desired course from the student's timetable.

fig.3.1 Student User Context Diagram

2. Administrator User Diagram

next previous top

The following diagram represents the relationship between an administrator user and the Project Atlantis Registration System. The user requests a service and the system responds appropriately. For example, if an administrator wishes to overload a course, they add the student to the course and the system responds by updating the class list and the student's timetable.

fig.3.2 Administrator User Context Diagram

The above diagrams give a nice overview of the Project Atlantis system. This general view of the functions each user can perform is useful in outlining aspects of the system that will be discussed in more detail later on in this document.

Entity Relationship Diagrams

next previous top

Entity Relationship Diagrams (ERDs) are designed to show the relationship between different types of users and courses, as well as their attributes. These users are referred to as entities and the interaction between them is called a relationship. The following ERDs outline the different roles of each entity and how they relate to different aspects of the system.

Legend

next previous top

	This represents a relationship between entities.
	An entity is a real world object such as a person, place, or thing. An entity can be a student, an administrator or a course.
	An entity's attribute - what it "has".
M	One student can register in up to M courses
N	Any number up to infinity
1	A single entity
1...X	A range of entities from one to X, where X is M or N

1. Overview

next previous top

This diagram illustrates the overall relationships that exist between administrators, students and courses.

A student manages their timetable and may register in one to M courses, while an administrator can manage infinitely many students and courses.

fig.4.1 An Overview of Relationships between Students, Administrators, and Courses

2. Administrator Relationship Diagrams

next previous top

As illustrated in the previous diagram, an administrator can manage infinitely many courses. An administrator can manage a course and its attributes, which include a course's name and number, description, lecture, lab and tutorial sections, pre- and co-requisites, maximum class size, class list, waiting list, location, and the instructor teaching each section.

The manage relationship encompasses the following functionality: adding, removing and modifying course information.

fig.4.2.1 An Administrator manages Courses

As illustrated in the overview diagram, an administrator can manage infinitely many students. An administrator can manage a student and its attributes, which include the student's ID number, password, status, current timetable and past courses and grades.

The manage relationship includes the following responsibilities: adding students, overriding course pre- and co-requisites, assigning student grades and overloading students in classes.

fig.4.2.2 An Administrator manages Students

3. Student Relationship Diagrams

next previous top

As illustrated in the general ERD, a student registers in one to M courses, where M is the maximum number of courses a student is allowed to add to their timetable.

The register relationship includes the following capabilities: a student can access all course information including availability and description, add a course to their timetable and drop a course from their timetable.

fig.4.3.1 A Student registers in Courses

As illustrated in the general diagram, a student can manage their timetables. A student can manage their own attributes, which includes password and timetable.

The manage relationship includes the following functionality: a student can view their timetable, courses taken and grades received, and change their password.

fig.4.3.2 A Student manages his/her personal information

Without going into too much detail, this section used ERDs to provide a quick and easy way to see how entities are related. This section was designed to provide a better understanding of how one entity interacts with another and to display the attributes that make each entity distinct.

Data Dictionary

next previous top

As illustrated in the last section, entities are composed of attributes. This section expands the ERDs by providing a detailed description of each attribute. These descriptions are provided to give a better understanding of their purpose in the Project Atlantis Registration System.

1. Entity: Student

next previous top

Name: ID number
Description: The unique identifier for each person in the system.

Name: Password
Description: The sequence of characters that a user must provide

Name: Course History
Description: A list of previously taken courses along with the grades earned in each course.

Name: Status
Description: The standing of a student will be either full-time, part-time or inactive.

Name: Timetable
Description: A schedule listing the times at which a student's current courses occur.

2. Entity: Administrator

next previous top

Name: Name
Description: An administrator's full name.

Name: ID number
Description: A unique identifier for each person in the system.

Name: Password
Description: The sequence of characters that a user must provide to gain access to the registration system.

Name: Course List
Description: A list of all the courses the instructor is currently scheduled to teach.

Name: Status
Description: The standing of the administrator can be either active or inactive.

3. Entity: Course

next previous top

Name: Name
Description: The name of the department that offers the specified course.

Name: Course Number
Description: The numerical identifier for the course.

Name: Description
Description: Textual information pertaining to the course as found in the University of Atlantis calendar.

Name: Pre-requisite
Description: The course that a student must have previously completed with a passing grade.

Name: Co-requisite
Description: The course that a student must be concurrently registered in.

Name: Lecture Number
Description: The numerical identifier for the lecture section.

Name: Lab Number
Description: The numerical identifier for the lab section.

Name: Tutorial Number
Description: The numerical identifier for the tutorial section.

Name: Location
Description: The building name and room number, where a lecture, lab or tutorial section is scheduled to occur.

Name: Maximum Class Size
Description: The maximum number of students allowed to register in a course.

Name: Waiting List
Description: A list of students sequenced for registration in a full course.

Name: Class List
Description: The list of students who are currently registered in a course.

Name: Professor Name Description: The instructor who is scheduled to teach a course.

The attributes are provided to outline the specific qualities associated with each entity. The data dictionary is designed to give a clearer understanding of these attributes. In the above section, we have described all the attributes for the three entities that compose the Project Atlantis Registration System.

Data Flow Diagrams

next previous top

This section deals with the flow of information through the system and its processes. This flow of information is best displayed with the use of data flow diagrams (DFDs). As illustrated below, the flow of data starts with the users of the system. These users can be either students or administrators. There are four levels of DFDs, level zero through level three. Level zero deals with the initial login onto the system. It is here that the system will decide if the user is a student or an administrator. Level one separates the different functionality of the student and administrator. The diagrams showing levels two and three deal with the specific tasks for each type of user.

Legend

next previous top

	Entity: An entity supplies data to the system and/or receives data from it. In this system, entities are users, which can be administrators or students.
	Process: A process performs operations on data. In this system, entities carry out tasks through processes.
	Database: A collection of data arranged for ease and speed of search and retrieval. In this system we have three databases, one for administrators, students and courses.
	Data Flow: Represents the flow of data.

1. User

0.0 User Login

next previous top

The user logs into the system by providing an ID number and a password. Depending on the range of the number, the system will access either the student database or the administrator database. The password is then checked by the login process, which will decide if the user has the proper access. If the ID number is in the student range, and their password is correct, they will be given access to the student system. If the ID number is in the administrator range, and the password is correct, the user will be given access to the administrator system. An error will occur if the ID is not found in either the student or the administrator database, or if the password is not valid for the given ID number.

fig.6.1 Login Flow

2. Student

1.0 The Student System

next previous top

Once the student has been granted access to the system, they will be able to choose from the list of student processes. For a student to view their timetable, the system requires their student ID number and will return their timetable information. Course Registration requires a student's ID number to access the current list of courses and the courses taken for that student. To view course information, the course name and number provide the student with the course details. To change passwords, the student's ID number is needed to provide access to the student database information.

fig.6.2 Student Capabilities (click for a larger image)

2.0 Change Password

next previous top

If a student would like to change their password, they must provide the system with their old password, as well as a new password that must be entered twice. The old password is retrieved from the student database with the use of the student's ID number. If the old password matches the one in the student database, and the two new passwords match, the new password will be updated in the database.

fig.6.3 Change Password

An error will arise if the user's two new passwords do not match or if the old password does not match the one retrieved from the database.

2.1 View Timetable

next previous top

fig.6.4 View Timetable

When a student would like to display their current timetable, the system will access the student database with their ID number. The timetable, detailing the student's current list of courses, will be accessed from the database and displayed to the student.

2.2 Course Registration

next previous top

To add or drop a course from their schedule, a student must provide the system with basic course information.

fig.6.5 Course Registration

This information includes the class name and number, as well as the lecture, lab and tutorial section numbers. After this, the user has the choice to add or drop the course.

2.3 View Courses Taken

next previous top

When a student would like to view the list of courses that they have already taken, along with the grades they received in those courses, they perform this action.

fig.6.6 View Finished Courses

The student's ID number is used to access the student database, from which the list of previously taken courses and grades are returned. This information is then displayed to the user.

2.4 View Course Information

next previous top

To access the information for a particular course, the system will take the supplied course name and number to retrieve the course attributes from the course database.

fig.6.7 View Course Information

These attributes include the course description, the instructors and availability of each lecture, lab and tutorial section of the course.

3.0 Add Course

next previous top

Once a student decides to add a course to their schedule, the system will add this course to the student's information. It will also add the student to the class list, through the course database. If the add is unsuccessful, an error will occur. A message will be generated if the course was full, the student is already registered in this course or if the student does not have the required pre/co-requisites.

fig.6.8 Add a Course

If the course is full, the student will have the option of being added to the waiting list.

3.1 Drop Course

next previous top

The dropping of a course is handled in a similar way to the add function. The student tells the system which course they would like removed from their schedule and then that course is removed from the student's information.

fig.6.9 Drop Course

The class list, in the course database, is updated to reflect this change. There will be a confirmation message when dropping. An error will occur if the course is a co-requisite of another course.

3. Administrator

1.0 Administrator System

next previous top

Once an administrator has been granted access to the system, they will be able to choose from the list of administrator processes. There are four types of tasks an administrator can perform, those pertaining to students, courses, administrators and general tasks.

Student tasks include adding a new student, modifying a student's information and overriding pre/co-requisites. Each of these tasks requires different information: Adding a student requires all the student's information including the student's ID number, status and password. Modifying a student's information requires the student's ID number, and to override course pre/co-requisites requires the student's ID number and the pertinent information for the course the student is registering in.

Course-related tasks include assigning grades, adding a course to the system, modifying a course's information, removing a course, and overloading a course. Each of these tasks requires information particular to the specific task: assigning grades requires the course name, number, and lecture section and the grades to assign to each student registered in the course. To add a course to the system, the information required is the course name, number, number of lectures, labs and tutorials, the maximum number of students, the instructor teaching it, and the day(s), time(s) and location(s) of the lecture(s), lab and tutorial sections.

Tasks related to the administrator include adding a new administrator, which requires the new administrator's ID number, name and status; and modifying an administrator's information, which requires the administrator's ID number.

General tasks include changing the current user's password, which requires the user's old password and new passwords; and setting trimester deadlines, which requires the start and end dates for the trimester.

fig.6.10 Administrator Capabilities (click for a larger picture)

2.0 Assigning Grades

next previous top

Once a trimester has finished, an administrator will enter the grades for the students. The assignment of grades is accessed via the class list in each lecture section. The course name, number and lecture sections are needed so the class list can be returned from the database.

fig.6.11 Assigning Grades

For each student ID number in the course list, the administrator will assign a grade. The student ID number is used to access the student database where the grade for the course specified will be updated in the student's list of courses taken.

2.1 Overload Course

next previous top

If an administrator wishes to overload a course without expanding the maximum class size, the administrator enter the student's ID number and the course name, number, lecture, lab and tutorial sections. The course information is used to access the class list in the course database and add the student to it.

fig.6.12 Overload Course

As well, the student's ID number is needed to add the course to the student's timetable in the student database. An error will occur if the student is already registered in this course.

2.2 Modify a Course

next previous top

To modify course information an administrator is required to provide the system with the course name, number, and lecture section. Information that can be edited includes: instructor, location, course description, maximum class size, and number of lecture/lab/tutorial sections.

fig.6.13 Modify Course

This information is used to access the course in the course database. Once the information has been modified it will be updated in the course database. An error will occur if there are still students in the class list of a section to be removed.

2.3 Add a New Course

next previous top

To add a new course, an administrator enters the course information, including description, name, number, lecture, lab and tutorial sections, pre- and co-requisites, the instructor teaching each lecture, the size of each lecture, and the rooms for each section.

fig.6.14 Add a new Course

The new course is then added to the course database. An error will occur if the course name and number already exist in this database.

2.4 Remove a Course

next previous top

If a course is to be removed from the system, the course name and number must be specified.

fig.6.15 Remove a Course

This information will be used to remove the course and all of its lecture, lab, and tutorial sections from the course database. An error will occur if there are still lecture sections with class lists that are not empty.

2.5 Add a New Administrator

next previous top

To add a new administrator to the system, the administrator's name and ID number are required. The new administrator is then added to the administrator database.

fig.6.16 Adding a New Administrator

An error will occur if a staff member with the same ID number already exists in the database.

2.6 Modifying an Administrator

next previous top

To modify an administrator's information, the administrator's ID number is used to retrieve their information from the administrator database.

fig.6.17 Modifying an Administrator

The administrator's name, password and status can be modified, and the changes will be updated in the administrator database.

2.7 Overriding Co/Pre-Requisites

next previous top

A student may get special permission to take courses without having taken its pre-requisite(s) or meeting the co-requisite requirements. An administrator needs to enter the student's ID number and the details for the course they wish to register in: the course name, number, and lecture, lab and tutorial sections. The student is then added to the class list for the course in the course database and the course is added to the student's timetable in the student database.

fig.6.18 Overriding Co/Pre-Requisites

2.8 Modifying a Student

next previous top

fig.6.19 Modifying a Student

If a student forgets their password, or their record becomes inactive, their information can be accessed from the student database through their student ID number. The updated password or status is provided and the student's information is updated in the student database.

2.9 Adding a new Student

next previous top

fig.6.20 Adding a Student

When a new student is added to the system, their ID number, status, and password are entered. The new student is then added to the student database. An error will occur if there already exists a student in the database with the same ID number.

2.10 Change Password

next previous top

If an administrator would like to change their password, they must provide the system with their old password, as well as a new password that must be entered twice. The old password is retrieved from the administrator database with the use of the ID number. If the old password matches the one in the administrator database, and the two new passwords match, the password will be updated. An error will arise if the user's two new passwords do not match or if the old password does not match the one retrieved from the database.

fig.6.21 Changing a Password

2.11 Set Trimester Deadlines

next previous top

When setting the trimester deadlines, the administrator provides the system with the dates, which are stored in the course database. All courses will follow the same deadlines.

fig.6.22 Adding a Student

The flow of data is important because it shows the explicit exchange of information between users, databases and the system. It provides a nice overview of how the each process will be carried out and handled by the system. These can be viewed as the next level in the system description because it provides more specific implementation ideas, although it is generally simple enough for non-technical people to follow.

User Interfaces

next previous top

The purpose of this section is to provide an early view of what the system will look like, and how users will interact with the system. Provided below is a series of graphical user interface (GUI) descriptions that define all of the possible operations that Project Atlantis can perform. All the GUIs presented in this section are divided into two major groups: Student and Administrator. These GUIs are further grouped into specific tasks with descriptions that detail the steps required to complete each task.

1. General Interfaces

1.1 Login

next previous top

Description: To gain access to the Project Atlantis Registration System, the user must login with a login name and password. This will inform the system if the user is a student or an administrator and will give the user the appropriate functionality. fig.7.1 Login Screen Interface Navigation: After choosing to login to the system, the user will be presented with the login window. The user now enters their login ID number and their password. If the user is a student, they will be presented with the student menu that will allow them to perform all student functions. If the user is an administrator, they will be presented with the administrator menu that will allow them to perform all administrator functions. Error Handling: If an error occurs, a message screen will appear, which will describe the specific error to the user. Errors that could occur are: invalid login ID or invalid password.

1.2 Logout

next previous top

Description: When the user wishes to end their session with the Project Atlantis Registration System, they must logout.

Interface Navigation: To end their session, the user selects ‘Logout’ from the bottom of the student or administrator menus.

Error Handling: No errors can be generated by this function.

1.3 Change Password

next previous top

Description: The user has the option of changing passwords when desired. fig.7.2 Change Password Screen Interface Navigation: The user must first select the ‘Change Password’ from the bottom of the student or administrator menus. To change their password, the user enters their current password, their new password and then the new password again to confirm. Error Handling: If an error occurs, a message screen will appear, which will describe the specific error to the user. Errors that could occur are: invalid current password or new password and confirmation password do not match.

2. Student Interfaces

2.1 Main Screen

next previous top

Description: This is the initial screen a student will see when they log into the Project Atlantis Registration System. From the left part of the screen, which is visible throughout the student’s session, the student may choose to perform a variety of tasks. fig.7.3 Student's Main Screen (click for a larger picture) Interface Navigation: The student may view their current timetable by selecting the ‘View Timetable’ option. Adding, dropping, and changing course registration may be performed via the ‘Course Registration’ option. ‘Course Information’ allows the student to look up information about a specific course such as its calendar description and current availability. Selecting ‘View Courses Taken’ will provide the student with a list of courses they have previously completed, and the grades they were assigned. The ‘Change Password’ option will allow the student to change their current password. ‘Logout’ will terminate the student’s session on the system. Also, for the student’s convenience, the student’s ID number and the current date are displayed in the upper left corner of the screen. Error Handling: No errors can be generated by using this interface.

2.2 View Timetable

next previous top

Description: Students can view their timetables for the current trimester. fig.7.4 Student Timetable Interface Navigation: When a student wishes to see his/her timetable, they have the option to do so from the side student menu (see fig.7.3) displayed at all times. After this option is selected, the timetable outlining the student’s schedule will appear. Error Handling: No errors can be generated by using this interface.

2.3 Register in Course

next previous top

Description: The student may add courses to his or her timetable. fig.7.5 Course Registration fig.7.6 Add or Change Course Details Interface Navigation: The student must first select “Course Registration” from the student menu. They are then asked for the name and number of the course in which they would like to register in. After selecting to add the course, the system asks the student for the appropriate lecture, lab and tutorial sections. After successfully entering this information, the student will be registered in the course. Error Handling: If an error occurs, a message screen will appear, which will describe the specific error to the user. Errors that could occur are: invalid course name; invalid lecture, lab or tutorial section. If the specified sections are full, a message is returned to the student, asking them if they would like to be placed on the waiting list.

2.4 Drop Course

next previous top

Description: Courses can be dropped from the student’s timetable.

Interface Navigation: The student begins by selecting “Course Registration” from the student menu. They will be shown the “Course Registration” window as in the last section. From here, they must enter the sections of the course they wish to drop from their schedule. Selecting “Drop” will present them with a final window that will ask them to confirm. If they confirm, the course will be dropped from their schedule.

Error Handling: If an error occurs, a message screen will appear, which will describe the specific error to the user. An error that can occur is: invalid course name. A student cannot drop a course if it is a co-requisite.

2.5 Access Calendar Information

next previous top

fig.7.7 Course Information Request Description: All students have quick and easy access to the information contained in the University of Atlantis calendar. This allows the student to view the calendar information and availability of all courses. Interface Navigation: Upon selection of the “Course Information" option in the Student Menu, the student is shown the "Select Course” screen as seen in the next figure. The student then can enter the desired course name and number, when the student is finished filling out the form, the "OK" button is pressed, then the student is shown the “Course information” screen as seen in the next figure. In this page, the student can view the calendar information of specified course. fig.7.8 Course Information (click for a larger image) Error Handling: If an error occurs, a message screen will appear, which will describe the specific error to the user. An error that can occur is: invalid course name.

2.6 View Course Availability

next previous top

Description: To verify that a desired course has room for registration, a user can easily view the course availability. This is designed for student to see what sections of course are available before trying to add or modify a course.

Interface Navigation: Upon selection of the “Course Information" option in the Student Menu, the student is shown the "Select Course" screen as seen in figure 7.8. The student then can enter the desired course name and number, when the student is finished filling out the form, the "OK" button is pressed, then the student is shown the “Course information” screen as seen in the next figure.

Error Handling:If an error occurs, a message screen will appear, which will describe the specific error to the user. An error that can occur is: invalid course name.

2.7 View Courses Taken

next previous top

Description: It is often the case that when a student needs to register for a new course they must check to see if the pre-requisite has been satisfied. Previous grades of courses taken can be accessed quickly by using the “View Courses Taken” functionality of the system. fig.7.9 Courses Taken Interface Navigation: The student selects “View Courses Taken” from the student menu. A window listing of all the courses the student has taken, with the corresponding dates and grades will be displayed. Error Handling: No errors are generated by this interface.

3. Administrator Interfaces

3.1 Main Screen

next previous top

Description: This is the initial screen an administrator will see when they log into the Project Atlantis Registration System. From the left part of the screen, which is visible throughout the administrator’s session, they may choose to perform a variety of tasks. fig.7.10 Administrator's Main Screen (click for a larger picture) Interface Navigation: The Project Atlantis administrator interface has been divided into four subsections based on their functionality. Each will be described individually. Courses: ‘Assign Grades’ allows an administrator to assign grades to all students registered in a particular course. By selecting ‘Overload Course’, an administrator may register a student in a course, even if the course is full, and ignore the waiting list. To add a course, the administrator may select the ‘Add Course’ option. The ‘Modify Course’ option will allow an administrator to modify the information about a course that already exists. ‘Remove Course’ may be used if a course is no longer offered at the University of Atlantis. ‘Set Trimester Deadlines’ will allow the administrator to set the initial and final course registration dates. Student: The ‘Add New Student’ option will allow the administrator to add a new student into the registration system. ‘Modify Student’ will allow the administrator to modify a student’s information. The ‘Override Pre/Co-Requisites’ option will allow an administrator to admit a student to a course, ignoring any pre- and co-requisites for that course which the student may be missing. Administrator: ‘Add Administrator’ allows an existing administrator to add a new administrator to the system. ‘Modify Administrator’ allows an administrator to change their own or another administrators’ data. The ‘View Schedule’ option will allow an administrator to view their current teaching timetable. General: The ‘Change Password’ option will allow the administrator to change their current password. ‘Logout’ will terminate the administrator’s session. Error Handling: No errors can be generated by using this interface.

3.2 Assign Grades

next previous top

Description: Assigning student grades is a task that instructors must complete at the end of the trimester. fig.7.11 Grade Assignment Screens Interface Navigation: To begin this task the administrator must select 'Assign Grades' from the administrator menu. The first window displayed prompts the user for the course in which to set the grades. Once the user has specified the course name and number, they will be presented with the next window where they specify the lecture number. To complete the task a new window listing all of the students in the lecture will be displayed. At this stage, the administrator is required to assign the grades to the respective student ID numbers. Error Handling: If an error occurs, a message screen will appear, which will describe the specific error to the user. Errors that can occur are: invalid course name or invalid lecture section.

3.3 Overload Course

next previous top

Description: When more students wish to register in a course that is already full, an administrator can overload the course. fig.7.12 Course Overloading Screen fig.7.13 Course Overloading: Details Interface Navigation: When an administrator overloads a course, she has the option to do so from the side administrator menu displayed at all times (see fig. 7.10). This interface will be shown to the administrator. After entering the student ID and the course name, the next window will appear. The administrator enters a lecture section, a lab section and a tutorial section for the course that they are overloading. Error Handling: If an error occurs, a message screen will appear, which will describe the specific error to the user. Errors that can occur are: invalid student ID or invalid course number, invalid lecture section; invalid lab section; invalid tutorial section.

3.4 Add Course

next previous top

fig.7.14 Request to Add or Modify a Course fig.7.15 Overview of Course and Possible Modifications fig.7.16 Request an Addition/Modification to Course Sections fig.7.17 Modify Section Details fig.7.18 Change Pre and Co-Requisites for a Course Description: An administrator can add a new course to the main course database to allow students to take the course. It is up to the administrator to specify course information. Information that is required for the administrator to enter when adding a course is: the course name, number, lecture, lab, tutorial section, pre-requisites, and co-requisites. Interface Navigation: When adding a new course to the course database, first the user must specify the course name and number. This will bring the user to a new list of options where they must enter the lecture, lab, tutorial, pre-requisites, and finally co-requisite information. When entering the lecture, lab, and tutorial information, the user must enter the days, time, room number, maximum students and the instructor which will be teaching the course. Then finally the user must enter the Pre-requisite and Co-requisites for the course being added. Then the course will be added to the course database. Error Handling: An error message screen will appear, which will describe the specific error to the user on the error message screen. Errors that could occur are: duplicate course names, and some type of time conflict (i.e. lecture, lab, tutorial, and instructor schedule conflicts).

3.5 Modify Course

next previous top

fig.7.14 Request to Add or Modify a Course

Description:Often a need to modify course information arises as class sizes and course demand changes. Such altering of course details can easily and efficiently be performed by an administrator. Information that an administrator is able to modify is: lecture, lab, tutorial section, pre-requisites, and co-requisites information.

Interface Navigation: (please refer to the interface diagrams in the previous section, as they are used for modifying courses)
When modifying course information, first the user must specify the course abbreviation and number. This will bring the user to a new list of options where they are able to modify Lecture, Lab, Tutorial, Pre-requisites, and finally Co-requisites information.
When modifying the lecture, lab, and tutorial information, the user can change the days, time, room number, maximum students and the instructor which will be teaching the course. Then finally the user must enter the Pre-requisite and Co-requisites for the course being added.
Finally the modifications are added to the database.

An error message screen will appear, which will describe the specific error to the user on the error message screen. Errors that can occur are: duplicate course names, time conflicts (i.e. lecture, lab, tutorial, and instructor schedule conflicts).

3.6 Remove Course

next previous top

Description:In the event that there are no students registered in a course, the administrators can remove it from the system. There will be an interface similar to add/modify course displayed to the user.

Interface Navigation: When an administrator removes a course, they have the option to do so from the side administrator menu displayed at all times (see fig.7.10). The administrator enters the specific course name. An appropriate message will be shown to the administrator to confirm their choice.

Error Handling:If an error occurs, a message screen will appear, which will describe the specific error to the user. An error that can occur is: invalid course name.

3.7 Set Trimester Deadlines

next previous top

Description: The dates that each trimester start and stop are different every year. So administrators must be able to set the registration start and stop dates for the students. Students are able to register courses for the following trimester one month before the trimester begins, up to three weeks after it has started. fig.7.19 Set Deadline for Trimester Registration Interface Navigation: When setting trimester deadlines, administrators must provide a start date and end date to the system. The start date is the date one month before lectures begin in the trimester. The end date is the date three weeks into the trimester. The system will update this information. Error Handling: No errors can be generated by this interface.

3.8 Add New Student

next previous top

Description: New students will need to be added to the system before they are able to register in courses. The new student will need to be assigned a login name, initial password and a part-time or full-time status. fig.7.20 Request to Add/Modify a Student fig.7.21 Add/Modify Student Details Interface Navigation: From the administrator menu, the administrator chooses ‘Add New Student’. Next, a new ID number for the student is chosen and entered. The administrator now enters the student’s name, initial password and also part-time or full-time status. Error Handling: If an error occurs, a message screen will appear, which will describe the specific error to the user. Errors that can occur are: the student ID number being assigned is already in use or the password is invalid.

3.9 Modify Student

next previous top

Description: The administrator has the ability to modify the student information as needed. The information that can be modified includes name, password and status.

Interface Navigation: (please note that the diagrams in the previous section are relevant to this one) To modify the student information, the administrator begins by selecting ‘Modify Student’ from the administrator menu. As above, the administrator will be presented with the ‘Modify Student’ window. Here the student’s ID number is entered. Next, the administrator has the options of modifying the student’s name, password or status. From here, the administrator may also view the student’s current timetable and courses taken.

Error Handling: If an error occurs, a message screen will appear, which will describe the specific error to the user. Errors that can occur are: invalid student ID number or invalid password.

3.10 Override Pre/Co-Requisites

next previous top

Description: There may be students that wish to take some courses that require a pre-requisite that has not yet been completed. If permission is granted, the administrator can override these restrictions.

Interface Navigation: To override pre- or co-requisite requirement for a student, the administrator must specify the student’s ID number and the course name and number.

Error Handling: An error message will appear if there are no pre- or co-requisites associated to the course specified by the administrator.

3.11 Add Administrator

next previous top

Description: An administrator may be required to add a new staff member to the registration system. fig.7.22 Request to Add/Modify an Administrator fig.7.23 Add/Modify Administrator Details Interface Navigation: The administrator must first enter the administrator’s ID number. Then they are prompted to enter the new administrator’s name and password. A new staff member will always be assigned 'Active' status. Error Handling: The administrator may enter an ID number that is already assigned to an existing staff member. In this case the administrator will be able to enter a new ID number. If the administrator does not provide all the required information, the system will produce an error message.

3.12 Modify Administrator

next previous top

Description: A staff member may need their personal information updated. As the screen shot titles in the previous section imply, modifying this information is as easy as adding a new staff member.

Interface Navigation: The administrator must select the ID number of the staff member to be modified. The administrator is then able to modify the name, password, or status. A staff member's ID number may not be changed.

Error Handling: If the administrator does not provide all the required information, the system will produce an error message.

Project Atlantis Registration System serves the needs of both the students and administrators of the University of Atlantis in a simple and easy-to-use manner.

The student may view and change their current trimester timetable, may view all of the courses taken in previous trimesters, along with the grades received, and they may also look up information on any course in the calendar.

Administrators have the ability to introduce and maintain all types of information supported by Project Atlantis. Some of the options available to aid them include adding, modifying and removing courses, including calendar information; set initial and final course registration dates; add new students into the system and maintain the student’s information; add and maintain the information of other administrators, as well as maintaining their own information; allow students to take courses which are full, or for which they do not have the pre- and co-requisites. The administrator may also enter student grades on a per-course and per-lecture section basis, as well as viewing their own teaching schedules.

Walkthroughs

next previous top

We know that the success of the system largely depends on how the user will be able to relate to the system through the user interface. We use a variety of techniques to arrive at the optimal design. We start our interface design with low fidelity prototypes, which allow us to constructively integrate the system functionality requirements and user-centered design ideas. One of the techniques that we use to guarantee that we are on the right track with our design is a so-called scenario walkthrough. Our design team comes up with a certain number of hypothetical potential users of the system and develops a possible scenario of the user utilizing system functionality. That allows us to better meet the end-user requirements. We would like to present two possible scenarios to cover both student and administrator functionalities.

1. Student Task Scenario

next previous top

Chester Kowalski is a University of Atlantis second year water science student. He is familiar with the old registration at the university and now he wants to register in a course for the coming trimester. He wishes to add FISH201 to his schedule but he does not know whether he has met the pre-requisite requirements. So he checks the courses information on FISH201 and discovers that he has met the requirements. He then adds the course to his schedule. After this is done, he views his timetable for the trimester and logs out of the system.

2. Administrator Task Scenario

next previous top

Mary is an administrator at the University, and would like to add SUNK217. SUNK217 has only one lecture and tutorial. Henry is a new professor at the University and is assigned to teach SUNK217 for the coming trimester. So Mary must add Henry to the system and then SUNK217 to the University curriculum.

Summary

next previous top

Wintersoft prides itself on documentation that is designed to provide updates on the development process as well as clarifying issues that may have not previously been considered. With the continued feedback from the University of Atlantis, we are confident that the system produced will be the one you have envisioned.

This Conceptual Design Document outlines a number of areas in the design process by providing the basic framework from which Project Atlantis will be designed. It details Wintersoft's understanding of the University of Atlantis's requirements and, at the same time, provides the University with a chance to view our progress. We are confident that you are pleased with this progress.

Glossary

next previous top

This glossary of terms borrows some content from Dictionary.com

Active Status

In the Project Atlantis system, an administrator is considered "active" if he or she is currently employed by the University of Atlantis. A student is considered active if he or she is currently enrolled in the University of Atlantis.

Administrator

A user with priviledged access to the Project Atlantis system.

Attribute

A quality or characteristic.

Co-requisite

A course that must be taken concurrently or prior to another.

Concurrent

Occuring simultaneously.

Database

An organized collection of data to be stored in a computer, in this case.

DFD

Data Flow Diagram.

Entity

Something that exists as a particular and discrete unit.

ERD

Entity Relationship Diagram.

Graphical User Interface

A way of "communicating" with a computer graphically, using as system such as Microsoft Windows, and a pointing device, like a mouse.

GUI

Graphical User Interface.

Inactive Status

In the Project Atlantis system, an administrator is considered "inactive" if he or she is no longer employed at the University of Atlantis.

Internet

A global collection of inter-connected computers.

Login

1) The procedure of gaining access to a secure system by means of entering a valid user name and password. 2) The user name.

Pre-requisite

A course that must be completed prior to taking certain other courses.

Prototype

An early model

Schedule

A plan for performing work in the time allotted.

Student

A user with unprivileged access to Project Atlantis Registration System.