Software Requirements Document
Student Registration System
Prepared by
Team 3
Kofi Ebong
George Landers
Kyle Lovinggood
Frederick Maier
Software Requirements
Student Registration System, Team 3 Page 1 of 20
Table of Contents
I. Introduction .................................................................................................................. 3
Overview ...................................................................................................................... 3
Purpose of the System ................................................................................................ 3
Scope of the System.................................................................................................... 3
Objectives and Success Criteria of the Project ............................................................ 4
II. Proposed System ........................................................................................................ 5
Functional Requirements ............................................................................................. 5
Basic Requirements of the System .......................................................................... 5
Requirements for Administrative Users .................................................................... 5
Requirements for Student Users .............................................................................. 6
Requirements for Faculty Users ............................................................................... 7
Nonfunctional Requirements ....................................................................................... 7
Data Storage and Maintenance:............................................................................... 7
Documentation ......................................................................................................... 7
Hardware Considerations: ........................................................................................ 7
Performance characteristics ..................................................................................... 8
Error Handling and Extreme Conditions ................................................................... 8
System Security: ...................................................................................................... 8
System modifications: .............................................................................................. 8
Pseudo Requirements ................................................................................................. 9
System Models ............................................................................................................ 9
Use Cases ............................................................................................................... 9
Object Model .......................................................................................................... 17
User Interface......................................................................................................... 17
Project Timeline ......................................................................................................... 19
III. Glossary ................................................................................................................... 19
Software Requirements
Student Registration System, Team 3 Page 2 of 20
I. Introduction
Overview
This document describes the functional and nonfunctional software requirements for an
online student registration system to be provided to a college. Detailed use cases are
presented, as is the system data model.
Purpose of the System
The proposed system will be the primary means used by students to register for
classes. Faculty members will use the system to determine which classes they are
assigned to teach and to view class rolls. Administrators will be able to create and edit
all data elements required for the registration process.
The system will be Web based and will allow access via remote computers utilizing
commonly available web browsers. Standard practices for secure web transactions will
be used.
Scope of the System
1700 students are currently enrolled in the college. Classes take place in 8 buildings.
There are 20 academic departments offering a total of 220 courses taught by a total of
150 faculty members.
The current registration process of the college is unknown, as is whether the college’s
size will change in the future. It is known, however, that enrollment has increased for
the last several years.
The proposed system will provide to students a list of offered courses as well as related
information and allow the student them to register. It will also allow them to view their
schedule and validate it (e.g., determine that the selected classes do not meet at the
same time and that the student has the proper permissions to take the courses).
Users of the system will have unique account id’s and passwords. Initially, there will be
only a small set of administrator accounts created. The administrators will then create
accounts for students and faculty members (and new administrators). Students and
faculty members will be informed of their accounts and initial passwords externally to
the system.
In order for registration to be possible, administrators will need to be able to create lists
of offered classes, and of buildings, and teachers, and departments, and be able to edit
them. The proposed system will provide for this. Furthermore, the proposed system
Software Requirements
Student Registration System, Team 3 Page 3 of 20
will validate the data entered by the administrator (for instance, it will check to see that
two courses have not been scheduled to meet at the same time in the same room).
The proposed system will not, however, have the ability to automatically assign courses
to classrooms, or in general to automatically produce a consistent schedule of classes.
As maintaining academic records is an important part of the registration process, the
system will be able to backup and export all information stored within the system.
Objectives and Success Criteria of the Project
Specific functional and nonfunctional requirements of the system are defined below.
The system will be considered successful if it can reasonably be said to have satisfied
all of the individual requirements.
Software Requirements
Student Registration System, Team 3 Page 4 of 20
II. Proposed System
Functional Requirements
Basic Requirements of the System
The system will be Web based, allowing users access via a common web
browser. Interface screens will be implemented using the normal capabilities of
the browser.
The system will allow concurrent access by many users (see the section on
nonfunctional requirements below). Each user will be required to log on using a
unique identifier and a password. The system will not allow access to those
entering an invalid ID/password combination.
Requirements for Administrative Users
Creation/Editing of Personal Accounts: The system will allow college
administrators to create personal accounts for new administrators, faculty
members, and students and edit their personal information. The system will
assign a unique identifier to each account which will be used by the student,
administrator, or faculty member when logging into the system.
Building List: The system will allow administrators to create, edit, and delete
records storing information about the college buildings. The system will create a
unique identifier for every building entered into the system. The administrator will
be allowed to record the name and address of each building, as well as the
numbers of all classrooms in the building.
Master Course List: The system will allow administrators to create, edit, and
delete records for courses available at the college. This will be called the master
list of courses. The administrator will be able to edit the course name, the
department that teaches it, and the course number as well as provide a
description for the course. The administrator will be able to specify prerequisites
of the course. The system will verify that the departments and call numbers are
valid for the system (that is, that the department exists, and that the course
number is not already taken).
Creation/Editing of a Schedule of Classes: The system will allow
administrators to create from the master list of courses a list of courses offered in
a particular term. By default, there will be one section associated with each
course. However, administrators will be able add new sections and specify their
student capacity. Each section will be given a unique identifying number for a
given term.
Software Requirements
Student Registration System, Team 3 Page 5 of 20
Editing Class Rolls: The system will allow administrators to edit existing roll
lists for a given term. He or she will be able to add or delete students from a
given section’s roll.
Controlling Access: The system will allow administrators to bar access by
particular faculty and students to all or some features of the system (e.g., a
student may be barred from entering the system at all, or simply barred from
registering for classes but not for viewing previous courses taken).
Specifying Registration Times: The system will allow administrators to specify
the times at which students will be able to register for courses or adjust their
schedule.
Specifying Grade Assignment Times: The system will allow administrators to
specify the times at which Faculty members will be able to assign final grades to
students registered in their courses. Outside of this time, faculty members will
not be able to alter student grades.
Viewing Editing Student Records: The system will allow administrators to view
and edit both the personal and academic information contained in student
records.
Searching the System: The system will allow administrators to search the
personal records of users, the master list of courses, and the current schedule of
classes for records based upon:
o user name
o account id
o building name
o department name
o course name
o section call number
A list of records matching the search term will be returned.
Requirements for Student Users
Editing Personal Account Information: A student will be allowed to view and
edit his or her personal information, but not delete his record entirely.
Viewing/Creation of Personal Schedules: The system will allow students to
view a list of currently offered courses, check their availability, and add courses
to his or her schedule (within the timeframe defined by the administrator). If he
or she is barred from registering, either because the student has not taken the
prerequisites or for none academic reasons, a message will be displayed to the
user.
Software Requirements
Student Registration System, Team 3 Page 6 of 20
Editing Personal Schedules: The student will be allowed to view his or her
class schedule, and add or remove courses from it during valid registration times
as specified by the administrator.
Viewing Previously Taken Courses and Grades (Transcripts): The system
will allow students to view a list of all the courses he or she has taken (within 20
terms) and the grades that he or she received.
Requirements for Faculty Users
Viewing Class Rolls: The system will allow faculty members to view a list of
courses he or she is assigned as well as the enrollment of each course section.
Assigning Grades: With a timeframe specified by an administrator, faculty
members will be allowed to assign or alter student grades in the sections
assigned to the faculty member. Outside of that timeframe, the faculty member
will not be able to alter or view the class roll.
Nonfunctional Requirements
Data Storage and Maintenance:
The system will be able to store 20 terms’ worth of class schedules and course
grades.
The database schema will be provided to the client, as will a specification of the
database systems’ configuration.
The database interface will be written utilizing JDBC, so that another relational
database management system could be substituted for the one initially used.
The system will be able export data as an ASCII text file.
Documentation
Online Documentation will be available to all users. The contents of the help
document will vary according to the classification of the user (student, faculty,
member).
A separate document describing the installation and maintenance of the system
will be provided.
Hardware Considerations:
[Need to ask about the system it will run on. ]
Software Requirements
Student Registration System, Team 3 Page 7 of 20
The system will occupy no more than 500MB of secondary memory at any time.
The system will utilize no more than 1 GB of primary memory at any time.
CPU Usage?
The system will not be required to interface with any of the college’s other
systems directly. However, it will be required to export data as described above.
Performance characteristics
Since the system will be Web based, it is impossible to ensure that it will be
accessible to users at all times. Networks failure is inevitable.
The system will be able to handle at least 200 concurrent users (Such a load
appears acceptable for Tomcat and MySQL, the server/database combination
that will be used). It is assumed that registration will be staggered (that is, the
college will not allow every student to register at the same time). Since the
typical user will spend considerably more time viewing a web page than
requesting one, the typical load on the system will typically be lower.
The system will be able to completely process any request in less than 30
seconds. If a system error occurs that does not affect the system’s ability to
send information to the user, then the system will notify the user (if the network
permits) within that time.
Error Handling and Extreme Conditions
If the system encounters an error which prevents a series of alterations to the
data store from completing, then the data store will be returned to its initial state.
If a system error occurs while processing a user’s request, and the error does not
affect the system’s ability to send information to the user, then the system will
notify the user (if the network permits) within 30 seconds.
System Security:
The client has made to guarantee that the system will run on a machine devoted
entirely to registration. As this is so, complete security of the system cannot be
assured. However, the following measures will be taken:
The system will utilize SSL or S-HTTP to secure client-server information
exchange.
Direct interaction with the database will be possible only locally.
System modifications:
Software Requirements
Student Registration System, Team 3 Page 8 of 20
As stated in the section on Data Storage, the system will be implemented so that
its relational database system could be replaced with one of similar capabilities.
The system will be implemented so that a doubling of the enrollment from its
current size would not impair the functioning of the system.
Pseudo Requirements
The college representative has specifically stated that:
The system must operate on a computer using the Sun Solaris 2.8 operating
system
The System must be implemented in Java or C++. The project team members
have decided that Java is the better choice.
Since the system will utilize a relational database, it must be MySQL
System Models
Use Cases (By Actor)
[Put a brief description of the use cases and what they are used for]
Student Use-Cases
①
Use Case: ViewTranscript
Description:
1. The Student logs into the system using his/her id_number and password.
2. The Student clicks on “View Transcript” in the Main Menu.
[Screen shot of browser with cursor over “View Transcript.”
3. The Student’s transcript_information, which includes a list of previously taken
Courses with the corresponding grades and credits received, total credits
received, and semester as well as cumulative GPA. is presented in the right pane
of the web page.
4. If the Student wishes, he/she may use the GPA Calculator by clicking the
appropriate button.
Software Requirements
Student Registration System, Team 3 Page 9 of 20
[Screen shot of GPA calculator]
End State(s):
1. A screen with the Student’s transcript as described above.
②
Use-Case Name: CalculateGPA
Description:
1. If the Student is currently taking any Courses, all of them will be displayed on the
transcript page along with radio buttons to fill in the expected grade to be
received for the Course.
2. The Student will fill in the expected grades, and click the CALCULATE button to
view the possible semester and overall GPA.
End State(s):
1. A screen with the Student’s transcript and calculated GPAs as described above.
③
Use-Case Name: ViewClassSchedule
Description:
1. The Student logs into the system using his/her id_number and password.
2. The Student clicks on “View/Edit Class Schedule” in the Main Menu. The screen
will then display a chronological time table of the Student’s daily class_schedule,
a table of the Student’s class_schedule with various information (such instructor,
location, time, etc.) and a drop button for each registered Course, and finally a
Course search feature with a drop-down box to choose the Department. At this
point the Student can search for Courses from a specific Department, in which
case the ViewDepartmentCourses use case is used.
Software Requirements
Student Registration System, Team 3 Page 10 of 20
End State(s):
1. A screen displaying a list of the student’s enrolled courses as described above.
④
Use-Case Name: ViewDepartmentCourses
Description:
1. From the ViewClassSchedule page, the Student selects a specific Department
and clicks the “Go!” button.
2. The Courses and all their sections from the selected Department are arranged in
order of their 4-digit numerical suffix, and sections within arranged by
call_number. At this point, three options are available: the Student can add a
Course to his/her class_schedule, (in which case the EnrollCourse use case is
used) mark a Course, (in which case the MarkCourse use case is used) or view a
Course’s description (in which case the ViewCourseDescription is used).
End State(s):
1. A screen with a list all the Courses and sections offered in a particular
Department as described above.
⑤
Use-Case Name: ViewCourseDescription
Description:
1. From the ViewDepartmentCourses page, the Student clicks either the hyperlink
for a specific Course’s name or title.
2. The screen will then display a description of that specific course, and provide a
back button to return to the previous screen.
End State(s):
1. A Course’s description screen, as described above.
Software Requirements
Student Registration System, Team 3 Page 11 of 20
⑥
Use-Case Name: MarkCourse
Description:
1. From the ViewDepartmentCourses page, the Student clicks the Mark button for a
specific Course.
2. After clicking “Yes” when the pop-up window asks if the user is sure, the Course
is then added to the Student’s marked_list.
End State(s):
1. The ViewDepartmentCourses screen.
⑦
Use-Case Name: ViewMarkedCourses
Description:
1. The Student logs into the system using his/her id_number and password.
2. The Student clicks on “View Marked Courses” in the Main Menu. Any Courses
the Student has marked will be listed on the screen in the same manner as they
are on the ViewDepartmentCourses page. The Student can view a Course’s
description from here (ViewCourseDescription use case) or add the Course to
his/her class_schedule. (In this case, the EnrollCourse use case is used)
End State(s):
Software Requirements
Student Registration System, Team 3 Page 12 of 20
1. A screen displaying a list of the Student’s marked Courses as described above.
⑧
Use-Case Name: EnrollCourse
Description:
1. Either from the ViewDepartmentCourses page, or the ViewMarkedCourses page,
the Student clicks the Add button for the Course he/she wants to add to his/her
class_schedule.
2. The Student will be prompted to click “Yes” or “Cancel” from a pop-up window
after the Add button is clicked.
End State(s):
1. The same screen the Student was on before if he/she clicks “Cancel” when the
pop-up window ask if they are sure.
2. The Student’s updated ViewClassSchedule page if he/she clicked “Yes”
⑨
Use Case Name: DropCourse
Description:
1. From the ViewClassSchedule page, the Student clicks the Drop button for the
Course he/she wants to remove from his/her class_schedule.
2. The Student will be prompted to click “Yes” or “Cancel” from a pop-up window
after the Drop button is clicked.
End State(s):
1. The same screen the Student was on before if he/she clicks “Cancel” when the
pop-up window ask if they are sure.
2. The Student’s updated ViewClassSchedule page if he/she clicked “Yes”.
⑩
Use Case Name: ViewProfile
Software Requirements
Student Registration System, Team 3 Page 13 of 20
Description:
1. The Student logs into the system using his/her id_number and password.
2. The Student clicks on “View Profile” in the Main Menu. The screen will then
display the Student’s personal information including first_name, last_name,
id_number, date_of_birth, address, phone_number, year and major. From this
screen, the Student can now edit his/her profile. (In which case the EditProfile
use case is used)
End State(s):
1. A screen displaying the Student’s profile as described above.
⑪
Use Case Name: ViewProfile
Description:
1. From the ViewProfile page, the Student clicks the Edit Profile button.
2. After the list of fields displays, the Student will click on any available field he/she
wants to change, type in the new information, and click the Submit button.
End State(s):
1. The Student’s updated ViewProfile page as described above.
⑫
Use Case Name: Search
Description:
Software Requirements
Student Registration System, Team 3 Page 14 of 20
1. The Student logs into the system using his/her id_number and password.
2. The Student clicks on “Search” in the Main Menu. The screen will then display a
search box, where the Student will input a keyword to search for classes.
End State(s):
1. A screen displaying the message, “No matches were found” if no Courses with
the keyword exist.
2. A screen with a list of all Courses that contain the keyword either in their
description or among any of their attributes.
⑬
[Use this as Template for Use Cases. Actors, objects, attributes, etc, should be
italicized. Use screen shots to describe the flow of events. ]
Use Case Name: Logout
Description:
1. At any point when the Student is logged in, he/she click “Logout” in the Main
Menu.
End State(s): The Student is logged out and the system program is exited.
Use Case Name Login
Participating Actor Administrator, Faculty, or Student
Initial Condition 1. Administrator, Faculty, or Student is not initially logged
into the system and visits Login websight.
Flow of events 2. Regardless of which actor is visiting Login websight, actor
types unique ID into text field labeled “Enter ID.” The actor’s
ID is displayed on the screen as typed.
3. Actor types Password into field labeled “Enter Password.”
The actor’s Password is not displayed on the screen as it is
typed, but with each character in Password shown as the “*”
character.
4. Actor clicks button labeled “Login.” If the actor is an
Administrator, Faculty, or Student that has access to the
enrollment system and has typed ID and Password correctly,
Software Requirements
Student Registration System, Team 3 Page 15 of 20
…[system checks login info against stored records], and
screen updates to InitialUsageScreen,
End Condition 5. Actor is logged into system, viewing InitialUsageScreen
which has a static frame used for an index, and a frame that
changes according to which option the user selects in the
index.
Alternate events At step 4, if the actor does not have access to the system, or
types ID or Password incorrectly, a LoginError is displayed
on a new window. The actor clicks the “Ok” button to dispel
the message, and is back at step 2 of the main flow of
events.
Use case name View Class Enrollment
Participating actor Faculty
Initial Condition 1. Faculty user has logged into system, and is at
InitialUsageScreen.
Flow of events 2. Faculty user clicks on “View Schedule” button in
static index, which causes the other frame on webpage
to change to show the Faculty user’s teaching schedule,
along with links for each class enrollment.
3. Faculty user clicks on enrollment link for a specific course
and section, and a new window appears with course info and
class enrollment list for that semester.
End Condition 5.
Alternate events
Software Requirements
Student Registration System, Team 3 Page 16 of 20
Object Model
(N) Object Name: Description
Attributes:
Attribute1Name: Description
Attribute2Name: Description
(N) Object Name: Description
Attributes:
Attribute1Name: Description
Attribute2Name: Description
(N) Object Name: Description
Attributes:
Attribute1Name: Description
Attribute2Name: Description
User Interface
A Minimalist Design:
Users will interact with the system using an ordinary web browser (specifically,
Netscape Navigator or MS Internet Explorer).
It is the intent of the team to keep the technology used in the interface as simple as
possible. The use of scripting languages will be avoided, as will Java applets, in order
increase compatibility with web browsers.
This section provides a brief description of how the interface will appear and function.
When users first direct their web browsers to the system server’s web site, all they will
see is simple log in screen, as shown below.
Software Requirements
Student Registration System, Team 3 Page 17 of 20
After logging on, the screen will contain two panes separated by a vertical line. The left
pane will contain a menu describing actions that the user can perform. These options
will depend upon the type of user (administrator, faculty member, or student). Selecting
one of the options will cause the contents of the right pane to change.
For instance, the below screen mockup shows an administrator that has chosen to add
a new faculty member to the system.
Software Requirements
Student Registration System, Team 3 Page 18 of 20
Most screens will contain dynamically generated information. Warning screens
and screens containing static information (or pages found on other sites) will
likely be presented in their own windows.
The use of the web browser allows the utilized the browser’s built in capabilities.
For instance, one can use the browser’s own search facility to find keywords on a
page.
Project Timeline
Task Deadline
Requirements Document ............................................................. 9/15/2003
Analysis Document .................................................................... 10/06/2003
System Design Document ......................................................... 10/20/2003
Object Design Document ........................................................... 11/11/2003
Implementation and Testing ...................................................... 12/10/2003
Demonstration ........................................................................... 12/10/2003
III. Glossary
(Just a list of words for now)
Faculty
Software Requirements
Student Registration System, Team 3 Page 19 of 20
Administrator
Student
Class Roll
Registration
Departments
Building
Master course list.
Schedule of classes
Courses
personal information
Personal Accounts
Section
course number
section call number
Personal Schedules
Registration Times
Grade Assignemnt Times
Transcripts
database schema
JDBC
ASCII
Tomcat
MySQL
SSL
S-HTTP
Java
Software Requirements
Student Registration System, Team 3 Page 20 of 20