You are on page 1of 126

MODELING REQUIREMENTS ENGINEERING FOR ABC

(Suite for University Academics Operations)

Software Requirements Specification

Version 2.0
Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

Revision History

Date Version Description Author

30/Apr/2007 1.0 Software Requirements Specification

9/May/2007 2.0 Software Requirements Specification

Confidential XYZ, 2007 Page 2


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

Table of Contents
1 INTRODUCTION.................................................................................................................................................5
1.1 PURPOSE..........................................................................................................................................................5
1.2 SCOPE..............................................................................................................................................................5
2 OVERVIEW..........................................................................................................................................................6

3 PROCESS FLOW.................................................................................................................................................8

4 FUNCTIONAL REQUIREMENTS....................................................................................................................9
4.1 FR01: NEW SEMESTER CREATION..................................................................................................................9
4.2 FR02: NEW SEMESTER COURSE DETAIL.........................................................................................................9
4.3 FR03: SET REGISTRATION PERMISSIONS......................................................................................................10
4.4 FR04: MAKE REGISTRATION SETTINGS........................................................................................................10
4.5 FR05: MANAGE TEACHER PROFILE..............................................................................................................10
4.6 FR06: MANAGE TEACHER PREFERENCES.....................................................................................................10
4.7 FR07: REQUEST STUDENT COURSE REGISTRATION......................................................................................11
4.8 FR08: REQUEST STUDENT ADD/DROP..........................................................................................................12
4.9 FR09: STUDENT COURSE REPEAT.................................................................................................................12
4.10 FR10: AUTHORIZE STUDENT REGISTRATION REQUEST (BY AO).................................................................12
4.11 FR11: AUTHORIZE STUDENT REGISTRATION REQUEST (BY ADVISOR)........................................................14
4.12 FR12: WITHDRAW COURSE..........................................................................................................................14
4.13 FR13: FREEZE SEMESTER.............................................................................................................................15
4.14 FR14: REPLACE COURSE..............................................................................................................................16
4.15 FR15: MANAGE STUDENT PROFILE..............................................................................................................17
4.16 FR16: NEW BATCH REGISTRATION..............................................................................................................18
4.17 FR17: LATE STUDENT REGISTRATION..........................................................................................................18
4.18 FR18: MIGRATED STUDENT REGISTRATION.................................................................................................18
4.19 FR19: REPORT MANAGEMENT......................................................................................................................19
4.20 RC00 - RULES AND CONSTRAINTS...............................................................................................................20
5 NON-FUNCTIONAL REQUIREMENTS.......................................................................................................21
5.1 NFR01: PERFORMANCE.................................................................................................................................21
5.2 NFR02: SECURITY.........................................................................................................................................21
5.3 NFR03: DEFECTS-MAINTENANCE.................................................................................................................21
5.4 NFR04: DOCUMENTATION............................................................................................................................21
5.5 NFR05: DISASTER RECOVERY......................................................................................................................22
6 ACTORS..............................................................................................................................................................23
6.1 ACADEMIC OFFICER.......................................................................................................................................23
6.2 STUDENT.......................................................................................................................................................23
6.3 ACCOUNT OFFICER........................................................................................................................................23
6.4 TEACHER.......................................................................................................................................................24
6.5 ADVISOR........................................................................................................................................................24
6.6 HEAD OF THE DEPARTMENT.........................................................................................................................24
6.7 DIRECTOR......................................................................................................................................................24
6.8 DEAN.............................................................................................................................................................24
7 USE-CASES.........................................................................................................................................................25

Confidential XYZ, 2007 Page 3


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.1 UC01: NEW SEMESTER CREATION...............................................................................................................25


7.2 UC02: NEW SEMESTER COURSE DETAIL......................................................................................................27
7.3 UC03: NEW BATCH REGISTRATION..............................................................................................................30
7.4 UC04: STUDENT REGISTRATION REQUEST...................................................................................................32
7.5 UC05: STUDENT REQUEST AUTHORIZATION BY AO...................................................................................36
7.6 UC06: STUDENT REQUEST AUTHORIZATION BY ADVISOR..........................................................................38
7.7 UC07: STUDENT COURSE WITHDRAW..........................................................................................................40
7.8 UC08: STUDENT SEMESTER FREEZE.............................................................................................................43
7.9 UC09: STUDENT COURSE REPLACEMENT.....................................................................................................45
7.10 UC010: LATE STUDENT REGISTRATION.......................................................................................................49
7.11 UC11: MIGRATED STUDENT REGISTRATION................................................................................................50
7.12 UC12: MANAGE STUDENT PROFILE.............................................................................................................51
7.13 UC13: MANAGE TEACHER PROFILE.............................................................................................................56
7.14 UC14: MANAGE TEACHER PREFERENCES....................................................................................................59
7.15 UC15: REPORT MANAGEMENT.....................................................................................................................62
8 TRACEABILITY MATRIX..............................................................................................................................67

9 SYSTEM ARCHITECTURE DIAGRAM.....................................................................................................105

10 DATA MODEL.............................................................................................................................................106

11 CLASS DIAGRAM.......................................................................................................................................111

12 GUI.................................................................................................................................................................112

13 ASSUMPTIONS............................................................................................................................................131

14 REFERENCES..............................................................................................................................................132

15 GLOSSARY...................................................................................................................................................133

16 Appendix........................................................................................................................................................135

Confidential XYZ, 2007 Page 4


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

Software Requirements Specification

1 Introduction
This document completely specifies the committed software requirements for ABC, an online registration system
available in XYZ INSTITUTE. The aim of this project is to study and analyze this current system running in the
academic institution. On the basis of the analysis performed our goal is to develop a requirements specification
document that supports all the functional and non-functional requirements with improvements suggested for the
current deficiencies.
1.1 Purpose

The purpose of the software requirements specification document is to specify all requirements for the current
registration system as well as those requirements that are suggested as improvements for the current system. . The
document explains the information that will be supplied as input to the system, its transformations and the required
outputs. It also addresses the interactions between the desired system and its users. This document will also act as an
aide for the upcoming object oriented analysis and design of the system. This will help the software designers in
developing this system in accordance with the requirements given in this specification. This specification describes
all functional and non-functional requirements, constraints, and other factors necessary to provide a complete and
comprehensive description of the requirements necessary to design and develop the corresponding software systems

The software developers will use the document for the necessary understanding of the system when implementing
and designing. The other concerned person is the client who would be able to understand the attributes and functions
of the system being developed.

1.2 Scope

The scope of this document is to completely and correctly specify software requirements for the current registration
system and other requirements that have come up as improvements suggested to be incorporated in the existing
system. The following areas are comprehensively covered in the document

 System Process Flow

 Functional Requirements

 Non-Functional Requirements

 List of Actors using the system

 Use-Cases

 System Architecture Diagram

 Data Model represented through Data flow diagrams and Entity Relationship diagram

 Object Model represented through the Class Diagram

 System Graphical User Interfaces

Confidential XYZ, 2007 Page 5


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

2 Overview
ABC is an online registration system available in XYZ INSTITUTE. This course registration system provides a one
window operation to all the stakeholders of the system that specifically include the students, academics officer, and
the teachers. The system provides customized interfaces for the mentioned stakeholders where their queries
regarding the registration, result modules, etc. can be adequately and efficiently handled.

The domain study conducted for this registration system was to acquire a deeper understanding of how the present
system was working and in addition un-cover any gaps or deficiencies in the current system. Although ABC
currently cater to most of the registration related requirements however facilities to Add another course or to Drop a
course, withdraw a course, etc. are not being catered by the system yet. Therefore ABC is being re-studied in order
to identify it possible deficiencies and the system could be re-modeled based on the new requirements that have
been proposed by the stakeholders. The system also need to be properly load tested and concurrency controls for the
database must be placed appropriately so that database updates coming in at the same time must be handled
appropriately.

It is known that the appropriate security must be installed in the system in order to restrain from data forgery or
distortion. Therefore, login system must be secure enough to restrict malicious access to the data that may challenge
its integrity.

Although most of the system functions have been automated, however a slight provision has been made for manual
data entry by the authorized Academics personnel. This freedom has been built into the system while duly
acknowledging the fact that in dealing with the real world situation of course registration, there may be situation in
which such a provision needs to be in place to facilitate the students. This is because accommodating the human
problems and situation factors, some students may not be able to register through the system due to unavailable
circumstances, where this provision can facilitate them in getting their required work done.
Product Functions
The registration system provides the following functions:

The students can perform the following functions:

 Register courses online

 Add/drop course(s)

 Place a survey/thesis request

 Withdraw course

 Freeze a semester

 Course replacement

The Academic Officer can perform the following functions:

 Set registration settings (creation of new semester, adding courses, setting registration permissions)

 Verifies the student information

 Changing student registration status

Confidential XYZ, 2007 Page 6


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

 Creation and updation of teachers’ and students’ profile

 Generate reports

The teacher can perform the following functions:

 View profile

 Accept/reject survey/thesis request

 Set courses preferences


User Characteristics
The following are types of users that are identifiable in the system in context of the system:

 Academic Officer

 Teacher

 Student

The following table describes effect of user characteristics on the system’s functionality.

User Level of Computer Level of Business Frequency of use


Knowledge Knowledge

Academic Good knowledge of Good understanding of the Daily basis


Officer window-based application registration process

Teacher Good knowledge of Understanding of the Depends on the teachers needs


window-based application registration process

Student Good knowledge of the They may or may not know Uses in the beginning of the semester,
window-based application the registration process very and often use during the semester
well.

Have the capability of


learning the system quickly Can follow the instructions
given by the academic
institution

Confidential XYZ, 2007 Page 7


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

3 Process Flow

New Batch Creation

New Semester
Pre Registration Settings
Creation (includes
(includes view
courselist creation,
permissions, etc.)
etc.) Management Reporting

Late Student
Registration Seek Approval from
Student Course Registration
Teacher
View Student
profile

Migrated Student
Registration
Add/Drop Courses

Update Student/
Teacher profiles

Academics Authorization
Withdraw Courses
of Student Request

Update RADIX

Semester Freeze Request RADIX

Course Replacement Verify Student Generating Student Fee


Registration List

Confidential XYZ, 2007 Page 8


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

4 Functional Requirements

4.1 FR01: New Semester Creation

Req. No. Functional Requirements

FR01-01 The system shall enable the Academic Officer to create the new semester in the beginning of the
academic calendar that has three cycles each year - Spring, Summer and Fall. The new semester to
start is automatically selected by the system. Any semester already registered cannot be registered
again and won’t be visible in the list of semesters available.

FR01-02 The system shall remove all the previous pending registration requests. This option is given to the
academic officer at the time of new semester creation. If the academic officer selects this option
then the pending registration requests of the previous semesters is removed.

FR01-03 The system shall allow the Academic Officer to set the status of all the currently registered students
to ‘Allowed’. This will make the registration permission available to all the students.

FR01-04 The system shall enable the Academic Officer to set the status of all unregistered students to
‘Disabled’. All the students whose registration status was previously set as ‘Disabled’ won’t be
allowed to register in the current semester.

FR01-05 The system shall enable the Academic Officer to remove grading/attendance details for the offered
courses completed before the new semester.

FR01-06 The system shall allow the academic officer to disable the option of adding/editing of lectures and
evaluations for the courses to be offered before the new semester.

4.2 FR02: New Semester Course Detail

Req. No. Functional Requirements

FR02-01 The system shall enable the Academic Officer to add course for a new semester from the existing
list of courses. The academic officer selects the semester, department, course name and enters
section, maximum seats and course outline for this course.

FR02-02 The system shall enable an academic officer to edit the course(s). The academic officer enters the
details for the offered course which includes quizzes, assignments, projects, monthly, final weights,
scaling factor and the grading scheme. The academic officer assigns a teacher to a course by
selecting the name of teacher, role and control. The academic officer also selects the batches who
can view the course while registering online.

FR02-03 The system shall allow the academic officer to remove the course(s) from the offered list of courses
for the new semester.

FR02-04 The system shall allow the academic officer to view the course list.

Confidential XYZ, 2007 Page 9


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

4.3 FR03: Set Registration Permissions

Req. No. Functional Requirements

FR03-01 The system shall allow the academic officer to set registration permissions for the students to view
online registration. The academic officer selects the batch and list of Serial No., Roll. No., Name,
Section, Degree, Registration Status and Allow Registration are displayed. The academic officer can
check the allow registration option for students who can view online registration.

FR03-02 The system shall enable the academic officer to select the students who cannot view online
registration by selecting the allow registration option as uncheck.

4.4 FR04: Make Registration Settings

Req. No. Functional Requirements

FR04-01 The system shall enable the Academic Officer to select the ‘Enable Online Registration’ option.
This enables the students to view online registration.

FR04-02 The system shall allow the academic officer to select ‘Disable Online Registration’ after the
registration deadline.

4.5 FR05: Manage Teacher Profile


Req. No. Functional Requirements

FR05-01 The system shall facilitate the academic officer to add a teacher’s profile containing the personal,
contact, office, qualification and university related details.

FR05-02 The system shall allow the academic officer to edit (modify) the teacher’s profile.

FR05-03 The system shall allow the academic officer to remove the teacher’s profile.

FR05-04 The system shall allow the teacher to view his/her profile. Every teacher has a separate login name
and password to enter the system.

4.6 FR06: Manage Teacher Preferences

Req. No. Functional Requirements

FR06-01 The system shall facilitate the academic officer to add the preferences of the teacher in a particular
department for a particular course he/she wants to teach. The academic officer selects the name of
the teacher and the department and a list of all the courses offered in the particular department are
displayed. The course code, title and credits information is displayed in the list. The academic
Officer selects the course (s) form the list that the teacher wants to teach.

FR06-02 The system shall allow the academic officer to edit preferred courses for a teacher.

Confidential XYZ, 2007 Page 10


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

FR06-03 The system shall enable the academic officer and the teacher to view the preferred courses for a
teacher.

4.7 FR07: Request Student Course Registration

FR07-01 The system shall provide an interface to the students where they can place online registration
requests.

FR07-02 The system shall display a list of courses from which the student can perform registration.

FR07-02-01 The system shall display list of all the courses offered to that batch and department.

FR07-02-02 The system shall display list of all courses that the student has withdrawn and are being offered in
the current semester.

FR07-02-03 The system shall display list of all courses that the student can repeat and are being offered in the
current semester.

FR07-02-04 The system shall not display any course to the student whose pre-requisite has not been studied by
the student.

FR07-03 The system shall allow a student to select courses from the list displayed.

FR07-04 The system shall not allow a BS student to register less than three courses.

FR07-05 The system shall not allow a BS student to register more than five courses.

FR07-06 The system shall not allow an MS student to register less than two courses.

FR07-07 The system shall not allow an MS student to register more than three courses.

FR07-08 The system shall allow an MS student to register for his thesis/survey.

FR07-08-01 The system shall display a thesis/survey form to an MS student.

FR07-08-02 The system shall display on the form student’s semester, program, roll number, name, date and
year on the student view.

FR07-08-03 The system shall enable the student to add his topic name, the advisor name, area of specialization
and select thesis or non-thesis option on the form.

FR07-09 The system shall not allow the student to register the survey/thesis as a fourth course.

FR07-10 The system shall allow the student to submit his registration request to the academic officer.

FR07-11 The system shall not allow the student to perform online registration once the request is submitted.
The registration then becomes disabled on the student view.

FR07-12 The system shall display a message to the student once his registration request has been submitted.

Confidential XYZ, 2007 Page 11


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

FR07-13 The system shall allow the student to view his registration status. It is “Pending” after the approval
from the academic officer and then “Submit Fee” after the submission of dues.

4.8 FR08: Request Student Add/Drop

FR08-01 The system shall allow the students to make add/drop course requests.

FR08-02 The system shall display list of courses that the student can add. (This will be the same list as the
registration process list plus all the courses that the student has dropped will not be visible.)

FR08-03 The system shall allow the student to select courses he wants to add.

FR08-04 The system shall not allow the student to add more courses than his registration limits.

FR08-05 The system shall enable the student to view his registered courses in the current semester.

FR08-06 The system shall allow the student to drop course(s) from the registered course(s) list of the current
semester.

FR08-07 The system shall allow the student to submit his add/drop course requests to the academic officer.

FR08-08 The system shall display a message to the student once his add/drop request has been submitted.

FR08-09 The system shall display all add/drop course request status as “Pending”.

FR08-10 The system shall not allow a student to add a course once dropped, in the current semester.

FR08-11 The system shall display to the student the number of seats remaining in a course.

4.9 FR09: Student Course Repeat

FR09-01 The system shall enable the student to view a list of courses from his previous semesters, which he
can or should repeat. It includes all the courses with grade F and GPA C- or less.

4.10 FR10: Authorize Student Registration Request (by AO)


FR10-01 The system shall enable the academic officer to view all the registration requests send to him by the
student. The request should display the student’s semester, program, roll number, name, date, year
and courses they requested for.

FR10-02 The system shall enable the academic officer to view all the thesis/survey requests send to him by
the student. The request should display the student’s semester, program, roll number, name, date,
year, topic name, the advisor name, area of specialization and thesis or non-thesis option.

FR10-03 The system shall allow the academic officer to forward MS students course registration request to
the current available advisor.

FR10-04 The system shall allow the academic officer to forward MS students survey/thesis request to the
advisor requested.

Confidential XYZ, 2007 Page 12


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

FR10-05 The system shall enable the academic officer to change the course registration status to “Pending”.

FR10-06 The system shall enable the academic officer to change the course registration status to “Submit
fee”.

FR10-07 The system shall allow the academic officer to change the survey/thesis status to “Meeting
Required”.

FR10-08 The system shall allow the academic officer to change the survey/thesis status to “Approved”.

FR10-09 The system shall enable the academic officer to select the ‘Enable Online Course(s) Add/Drop’
option. This enables the students to view online course add/drop option.

FR10-10 The system shall enable the academic officer to select the ‘Disable Online Course(s) add/drop’
option. This disables the students’ view of online course add/drop option.

FR10-11 The system shall enable the academic officer to view all the add/drop requests send to him by the
student. The request should display the student’s semester, program, roll number, name, date, year
and courses they added and dropped.

FR10-12 The system shall allow the academic officer to forward MS students add/drop course request to the
current available advisor.

FR10-13 The system shall maintain the seat status of all courses.

FR10-14 The system shall maintain a list of names of all students who added the course when there were
seats available.

FR10-15 The system shall maintain a list of names of all students who added the course when there were no
seats available.

FR10-16 The system shall maintain a list of names of all students who dropped a course.

FR10-17 The system shall reduce the number of seats available in a course dynamically as the students’
request to add that course.

FR10-18 The system shall increase the number of seats available in a course dynamically as the students’
request to drop that course.

FR10-19 The system shall allow the academic officer to add the course requested by the students in their
current course lists.

FR10-20 The system shall allow the academic officer to drop the course requested by the students from their
current course lists.

4.11 FR11: Authorize Student Registration Request (by Advisor)


FR11-01 The system shall enable the advisor to view the students’ registration requests sent to him by the
academic officer. The request should display the student’s semester, program, roll number, name,
date, year and courses they requested for.

Confidential XYZ, 2007 Page 13


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

FR11-02 The system shall enable the advisor to view the students’ add/drop requests sent to him by the
academic officer. The request should display the student’s semester, program, roll number, name,
date, year and courses they added and dropped.

FR11-03 The system shall enable the advisor to view the students’ survey/thesis requests sent to him by the
academic officer. The request should display the student’s semester, program, roll number, name,
date, year, topic name, the advisor name, area of specialization and thesis or non-thesis option.

FR11-04 The system shall enable the advisor to mark the registration requests as “Approved”.

FR11-05 The system shall enable the advisor to mark the registration requests as “Disapproved”.

FR11-06 The system shall enable the advisor to mark the add/drop requests as “Approved”.

FR11-07 The system shall enable the advisor to mark the add/drop requests as “Disapproved”.

FR11-08 The system shall enable the advisor to mark the thesis/survey requests as “Approved”.

FR11-09 The system shall enable the advisor to mark the thesis/survey requests as “Disapproved”.

4.12 FR12: Withdraw Course


FR12-01 The system shall enable the student to make withdraw course requests.

FR12-02 The system shall enable the student to select from registered course(s) to withdraw it.

FR12-03 The system shall allow the student to submit his withdraw course requests to the academic officer.

FR12-04 The system shall display a message to the student once his withdraw request has been submitted.

FR12-05 The system shall enable the academic officer to select the ‘Enable Online Course(s) withdrawal’
option. This enables the students to view online course withdraw option.

FR12-06 The system shall enable the academic officer to select the ‘Disable Online Course(s) withdrawal’
option. This disables the students’ view of online course withdraw option.

FR12-07 The system shall enable the academic officer to view all the course withdraw requests send to him
by the students. The request should display the student’s semester, program, roll number, name,
date, year and the course(s) requested to withdraw.

FR12-08 The system shall enable the academic officer to forward the course withdraw requests to the faculty
member teaching that course.

FR12-09 The system shall enable the academic officer to mark the students grade as “W”.

FR12-10 The system shall facilitate the faculty member to view the course withdraw requests forwarded to
him. The request should display the student’s semester, program, roll number, name, date, year and
the course(s) requested to withdraw.

FR12-11 The system shall allow the faculty member to mark the course withdraw requests as “Approved”.

Confidential XYZ, 2007 Page 14


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

FR12-12 The system shall allow the faculty member to mark the course withdraw requests as
“Disapproved”.

FR12-13 The system shall enable the faculty member to send his decision on the requests back to the
academic officer.

4.13 FR13: Freeze Semester


FR13-01 The system shall enable the student to make semester freeze requests.

FR13-01-01 The system shall enable the student to view the semester freeze form.

FR13-01-02 The system shall display on the form student’s semester, program, roll number, name, date and
year.

FR13-01-03 The system shall enable the student to enter his reason in the form for freezing the semester.

FR13-02 The system shall allow the student to submit his semester freeze requests to the academic officer.

FR13-03 The system shall not allow the student to view the semester freeze option once he has submitted the
freeze request.

FR13-04 The system shall display a message to the student once his semester freeze request has been
submitted.

FR13-05 The system shall not allow the student to make any registration or withdraw course requests once
the student has made a semester freeze request.

FR13-06 The system shall enable the semester freeze option on the student’s view when the academic officer
enables the online registration option.

FR13-07 The system shall disable the semester freeze option on the student’s view when the academic
officer disables the online registration option.

FR13-08 The system shall enable the academic officer to view all the semester freeze requests send to him
by the student. The request should display the student’s semester, program, roll number, name,
date, year and the reason to freeze the semester.

FR13-09 The system shall enable the academic officer to block the registration for all the student’s with
semester freeze requests. Their status will be changed to “Decline”.

FR13-10 The system shall enable the academic officer to generate a mail to all the student’s with semester
freeze requests to submit their dues.

FR13-11 The system shall mark the semester freeze requests of students with warning in any of their
previous semesters.

FR13-12 The system shall allow the academic officer to send the marked semester freeze requests of the
students to the advisor for approval.

FR13-13 The system shall enable the advisor to view the students’ semester freeze requests sent to him by

Confidential XYZ, 2007 Page 15


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

the academic officer. The request should display the student’s semester, program, roll number,
name, date, year and the reason to freeze the semester

FR13-14 The system shall enable the advisor to mark the semester freeze requests as “Approved”.

FR13-15 The system shall enable the advisor to mark the semester freeze requests as “Disapproved”.

FR13-16 The system shall enable the advisor to send his decision on all type of requests back to the
academic officer.

4.14 FR14: Replace Course


FR14-01 The system shall enable the student to make course replacement requests.

FR14-02 The system shall enable the student to view the course(s) he has failed in the previous semesters.

FR14-03 The system shall enable the student to view all the courses he cleared atleast one semester after the
failed course(s).

FR14-04 The system shall enable the student to select from the failed course(s) he wants to replace.

FR14-05 The system shall enable the student to select from the cleared courses he wants to replace the failed
one with.

FR14-06 The system shall allow the student to submit his course replacement requests to the academic
officer.

FR14-07 The system shall display a message to the student once his course replacement request has been
submitted.

FR14-08 The system shall enable the course replacement option on the student’s view when the academic
officer enables the online registration option.

FR14-09 The system shall disable the course replacement option on the student’s view when the academic
officer disables the online registration option.

FR14-10 The system shall enable the academic officer to view all the course replacement requests send to
him by the student. The request should display the student’s semester, program, roll number, name,
date, year, the course to replace and the course to replace by.

FR14-11 The system shall enable the academic officer to forward the requests to head of the department.

FR14-12 The system shall enable the academic officer to forward the requests to the director.

FR14-13 The system shall enable the academic officer to forward the requests to the dean.

FR14-14 The system shall enable the academic officer to replace a student’s course with another course he
has studied.

FR14-15 The system shall facilitate the head of the department to view the course replacement requests

Confidential XYZ, 2007 Page 16


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

forwarded to him. The request should display the student’s semester, program, roll number, name,
date, year, the course to replace and the course to replace by.

FR14-16 The system shall allow the head of the department to mark the course replacement requests as
“Approved”.

FR14-17 The system shall allow the head of the department to mark the course replacement requests as
“Disapproved”.

FR14-18 The system shall enable the head of the department to send his decision on the requests back to the
academic officer.

FR14-19 The system shall facilitate the director to view the course replacement requests forwarded to him.
The request should display the student’s semester, program, roll number, name, date, year, the
course to replace and the course to replace by.

FR14-20 The system shall allow the director to mark the course replacement requests as “Approved”.

FR14-21 The system shall allow the director to mark the course replacement requests as “Disapproved”.

FR14-22 The system shall enable the director to send his decision on the requests back to the academic
officer.

FR14-23 The system shall facilitate the dean to view the course replacement requests forwarded to him. The
request should display the student’s semester, program, roll number, name, date, year, the course to
replace and the course to replace by.

FR14-24 The system shall allow the dean to mark the course replacement requests as “Approved”.

FR14-25 The system shall allow the dean to mark the course replacement requests as “Disapproved”.

FR14-26 The system shall enable the dean to send his decision on the requests back to the academic officer.

4.15 FR15: Manage Student Profile


Req. No. Functional Requirements

FR15-01 The system shall facilitate the academic officer to add a student profile containing the personal
information, student contact, parent contact, correspondence contact, university related
information, family information and previous academic record.

FR15-02 The system shall allow the academic officer to edit (modify) the student profile.

FR15-03 The system shall allow the academic officer to remove the student profile.

FR15-04 The system shall enable the student to view his/her academic profile. The student can also view his
registration status and the results of the previous semesters.

Confidential XYZ, 2007 Page 17


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

4.16 FR16: New Batch Registration


Req. No. Functional Requirements

FR16-01 The system shall enable the Academic Officer to add new batch to the university. The system
displays the option to add a new name and starting semester for the new batch.

FR16-02 The system shall allow the Academic Officer to add sections of the new batch. Any section added
by mistake can also be removed. This option can be used to edit any existing batch information too.
The academic officer has to enter the name of the batch to edit and can add and remove batch
sections

FR16-03 The system shall allow the Academic Officer to migrate student profiles from NUTES to ABC.

FR16-04 The system shall allow the academic officer to perform registration of the new batch’s students.
The academic officer enters the batch, section and degree name and selects from the list of courses
which are to be registered for all the students of the first semester.

4.17 FR17: Late Student Registration


Req. No. Functional Requirements

FR17-01 The system shall facilitate the academic officer to enter the registration information of the students
who have made late registration requests. This option helps the academic officer to register the
courses for a student who has missed the registration due to some reason.

FR17-02 The system shall help the academic officer to verify that the courses requested by the student are
available for that student to register. For this purpose the academic officer can check the student’s
transcript through the system to review the previous courses he has studied.

FR17-03 The system shall not allow the late registration of the student who does not have the registration
permissions.

4.18 FR18: Migrated Student Registration


Req. No. Functional Requirements

FR18-01 The system shall enable the academic officer to create a new profile of the student who has
migrated from one campus to other campus of NU-FAST. (Reference requirement number FR12-
01)

FR18-02 The system shall facilitate the academic officer to enter the previous courses and semester details
of the student who has migrated. The system displays the list of all the semesters not registered for
a particular student. The academic officer provides the roll number of the student and the system
displays a list of all the semesters not registered for him.

FR18-03 The system shall enable a migrated student to view his previous semester’s information.

Confidential XYZ, 2007 Page 18


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

4.19 FR19: Report Management


Req. No. Functional Requirements

FR19-01 The system shall enable the academic officer to view the report of all students whose registration
status is declined.

The academic officer selects the batch and a list of serial numbers, roll numbers, names, section,
degree and registration status is displayed.

FR19-02 The system shall enable the academic officer to view the report of the seat status of the courses in
the current semester.

A list of the serial numbers, roll numbers, course codes, course titles, sections, maximum seats,
registered students, requested registration and remaining seats status is displayed.

FR19-03 The system shall enable the academic officer to view the report of all the students who have been
registered and who have made a request for registration in a particular course.

The academic officer selects a particular course and a list of serial numbers, roll numbers, names is
displayed for all students who have registered in that course and for all students who have made
requests for that course.

FR19-04 The system shall enable the academic officer to view the report of all the students who haven’t
registered in the current semester.

The academic officer selects a batch and a list of serial numbers, roll numbers, name, section,
degree and registration status is displayed.

FR19-05 The system shall enable the academic officer to view the report of the work load of the students in
the current semester according to their batches.

The academic officer selects a particular semester and all the batches in that semester are displayed
with a total of all the students registered in a particular batch and their average courses and average
credit hours.

FR19-06 The system shall enable the academic officer to view the report of the registration summary of a
particular semester.

The academic officer can select the semester and the information displayed includes the batches in
the current semester, total number of male and female students in all the current degrees.

FR19-07 The system shall enable the academic officer to view the report of the registration summary of all
the current batches.

The information displayed consists of all the current batches, number of students who haven’t
registered in a batch, number of students who have pending requests in a batch, number of students
who have declined requests in batch, number of students who have submit fee status in batch,
number of students whose requests have been completed in a batch and number of students whose
registration has been disabled and their total.

Confidential XYZ, 2007 Page 19


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

4.20 RC00 - Rules and Constraints

Ref # Rule

RC00-01 Students are not allowed to pursue two degrees at the same time.

RC00-02 Teacher would provide the preference of courses that he would like to teach when he is being
inducted in the university

RC00-03 The addition or dropping of students in offered courses would only be done till the second
week from the start of the semester

RC00-04 Withdrawal from an offered course would be allowed only till the end of 14 th week from the
start of the semester

RC00-05 Number of courses that can be selected by a student online can be fixed by the academic office

RC00-06 Online registration can only be done by student once. If there are any problems or errors,
he/she should contact the academic office

RC00-07 The system would find the best of for the assignments and quizzes.

RC00-08 There shall be no transfer of Grade or GPA from the courses taken at the previous university
for a migrated student

RC00-09 A course shall be allowed to be run by multiple teachers

RC00-10 The student selects at least 3 or at the most 5 courses in BS registration.

RC00-11 The student selects at least 2 or at the most 3 courses in MS registration.

Confidential XYZ, 2007 Page 20


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

5 Non-Functional Requirements
5.1 NFR01: Performance

NFR01-01 Average load time of the starting page of the system must be less than 2 second.

NFR01-02 Average processing time taken by the system to complete a transaction/request should be less than
10 seconds.

NFR01-03 System Mean Time to Failure should not be more than 60seconds within 24 hours of use.

NFR01-04 Average system response time should not be greater than 5 seconds.

NFR01-05 System must successfully run on a client machine with 256 MB RAM or above.

NFR01-06 100 Students should be able to simultaneously access the system and update the database.

5.2 NFR02: Security

NFR02-01 System must provide access to authorized users only that enter through the login module.

NFR02-02 System must not provide access to ANY user EXCEPT the designated user to update the database.

NFR02-03 No user can view data of any other user through any report or views provided by the system.

NFR02-04 After the end of a user Session, no information must be saved any where on the client machine.

5.3 NFR03: Defects-Maintenance

NFR03-01 Post Release defects of the system must not exceed 1 critical bug per month.

NFR03-02 Post Release bug fixing should not take more than 5 hours.

5.4 NFR04: Documentation

NFR04-01 Help documentation must be complete in providing information about each and every module and
functionality provided by the system.

NFR04-02 Help option must be easily accessible on all system web pages.

NFR04-03 Help must be written using minimal technical terms; any technical terms used must be additionally
defined at the end of the document

Confidential XYZ, 2007 Page 21


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

5.5 NFR05: Disaster Recovery


NFR05-01 In case of client /server crash all information/data should be recoverable within 30 minutes of the
incidence.

Confidential XYZ, 2007 Page 22


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

6 Actors
Following is a list of the actors and their responsibilities involved in the registration process.

6.1 Academic officer


The academic officer is the person who will operate the registration system in the administrative view. Multiple
people can play the role of the academic officer depending on the size of the administrative staff. The rights and
access have to be provided to AO to perform various responsibilities. He acts like a system operator and a full time
commitment to handle the system is required. He will be one of the end user of the system. A list of all the
functionalities and responsibilities of the AO are defined as under.
 He can make pre-registration settings including:
 Creation of new semester prior to the start of each semester
 Maintaining (adding/removing/editing) course offerings and the details
 Setting registration permissions to those students who can view online registration
 And making registration settings to either enabled or disabled.
 All the requests placed by the students for registration will be handled by the AO in the administrative view.
 He will also verify the information provided by the student from the academic record and the consult the
related department.
 In case of late registration of any student he will be responsible for fulfilling the request and registering the
courses from the administrative view.
 Creation of student profile and entering of the relevant information (in case of a migrated student) is also AO’s
responsibility.
 Changing students’ registration status to submit fee or decline is conducted by AO.
 He will also be responsible for receiving the list of the students send by the account officer.
 Creating and updating teacher’s profile and managing teacher’s preferences about the courses they can teach is
also done by the AO.
 He will also forward MS student’s requests to the related advisors.

6.2 Student
The registration process remains incomplete without the input from the student. In fact all the major activities
revolve around the student and it is one of the main goals of the automated process to facilitate the student entity. He
will be responsible for interacting with the student view of the registration process. The major role and
responsibilities of a student includes:
 A student is responsible for placing a request for registration.
 The Course registration request will be forwarded by the student, through system generated messages
submitted to the Academics Officer.
 The student is responsible for providing his transcript to the academic officer.
 He is responsible for submitting the request and conducting meeting with the advisor.

6.3 Account officer


The role of the account officer comes in registration when he has to submit the list of the students to the academics
so that they can change the status of the students who have submitted the fees. This can be done by any of the
accounts personnel depending on whom the responsibility is assigned to. The accounts officer’s responsibilities in

Confidential XYZ, 2007 Page 23


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

the registration process include transferring the list of students; either submitted the dues for freezing or registering,
to the academic office.

6.4 Teacher
Teacher is another actor that plays an important role in the whole registration process. Not only his information is
required by the system for making a list of teachers who can be assigned the courses but also he has the authority to
finalize the survey and thesis requests made by the students at the time of registration. His actions include:
 Providing the profile information and preferences. Every teacher has to provide his personal and academic
information so that his profile can be created and entered in the system. By conducting a meeting with the head
of the department (HOD) the teacher can finalize the courses he is interested in teaching. These courses are
then entered in the system as teacher’s preferences. The academic is responsible for making these entries in the
system.
 He also approves the course withdrawal request. All the course withdrawal requests are forwarded to the
teacher teaching that course and he can finalize the decision.

6.5 Advisor
Advisor is another actor that plays an important role in the whole registration process. Not only his information is
required by the system (as mentioned above for the teacher) but also he has the authority to finalize the survey and
thesis requests made by the students at the time of registration.
 Whenever a student makes a request for survey or thesis that request is send to the teacher against whom the
request is made. The teacher can view the form and on the basis of his own decision he can choose to allow the
student to conduct a survey of thesis. If the teacher requires the student can also conduct meetings with teacher
to finalize the topic and other details.
 He also approves the MS course registration requests.
 He also approves the MS course add/drop requests.
 He also approves the semester freeze request if there is any warning in the student’s current transcript.

6.6 Head Of the Department


 He approves the course replacement request according to university conditions and policies.
 He for wards the request back to the academic officer.

6.7 Director
 He approves the course replacement request according to university conditions and policies.
 He for wards the request back to the academic office

6.8 Dean
 He approves the course replacement request according to university conditions and policies.
 He for wards the request back to the academic office

Confidential XYZ, 2007 Page 24


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7 Use-Cases
7.1 UC01: New Semester Creation

7.1.1 UC01-01: Create New Semester

7.1.1.1 Brief Description

The purpose of this use case is to create a new semester in the beginning of the registration process. The process
starts when the previous semester has ended and the academic officer plans to begin the new semester’s registration.
This use case helps the academic officer to create a new semester in the system and start its registration process. The
user from the Academics Office selects the season and the year for the new semester and starts it.

7.1.1.2 Pre-condition(s)

1. The previous semester has finished.

2. The university has announced the starting of the new semester.

3. Academic Officer has logged on to the application

7.1.1.3 Main Flow

1. The academic officer starts the use case by clicking on the “New Semester” link provided on the front
screen of the academic officer’s main window.

2. The system opens a new screen which displays the name of the new semester to start according to the
academic calendar that has three cycles each year - Spring, Summer and Fall.

3. The screen displays all the options available to set for the new semester.

4. The academic officer sets the status of all the currently registered students to “Allowed”.

5. As a result the system allows the currently registered student’s to register in the new semester.

6. The academic officer sets the status of all the currently unregistered students to “Disabled”. This option is
used to disable the registration for all the students who haven’t registered in the previous semesters. It can
include the students with completed degree status.

7. As a result the system disables the registration to all the students who haven’t registered in the previous
semester.

8. The academic officer can also select the option to remove the previous pending registration requests,
remove grading/attendance details for the offered courses completed before the new semester and disable
the option of adding/editing of lectures and evaluations for the courses to be offered before the new
semester.

9. The academic officer confirms the creation of the new semester and clicks on the “Start” button.

10. The system displays the message that a new semester is created.

7.1.1.4 Alternative Flows

If the academic officer accidentally closes the screen no information is saved and he has to restart the whole process.

Confidential XYZ, 2007 Page 25


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.1.1.5 Post-condition(s)

As a result of the new semester, the courses can be offered and the teachers for those courses etc. can be specified.
The grading details related to various courses are removed from the students’ front end and they are shown the data
related to the new semester only.

7.1.2 UC01-02: Make Registration Settings

7.1.2.1 Brief Description

The purpose of this use case is to make registrations settings of the new semester. The academic officer initiates this
use case after the creation of the new semester and when the university announces the start of the registration
process. This enables the registration process for all the students.

7.1.2.2 Pre-condition(s)

1. The new semester has been created.

2. Settings have been done.

3. The courses detail has also been added.

4. Academic Officer has logged on to the application

7.1.2.3 Main Flow

1. The use case begins when the academic officer clicks on the “Registration Settings” link provided on the
front screen of the academic officer’s main window.

2. The system displays the “Registration Settings” screen which has the option to enable and disable the
online registration.

3. The academic officer selects the “Enable Online Registration” option and clicks the “Apply Changes”
button.

4. As a result the system enables the online registration for all the students whose registration status was
previously set to “Allowed”.

5. Alternative Flows

6. If the academic officer presses the cancel button on the page no option will be selected and the settings for
registration will not be applied.

7.1.2.4 Post-condition(s)

The student will be allowed access to the registration system if the option is enabled by the administrator and
similarly will not be allowed access to the system if it is disabled.

7.1.3 UC01-03: Set Registration Permissions

7.1.3.1 Brief Description

The purpose of this use case is to set the registration permissions of the students. It is initiated by the academic
officer to select which students are not allowed to view the registration amongst all the students. This can include
students who have DC cases and are not allowed to register in the current semester.

Confidential XYZ, 2007 Page 26


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.1.3.2 Pre-condition(s)

1. The new semester has been created.

2. The academic officer has the finalized list of all the students who shouldn’t be allowed to register in the
new semester.

3. Academic Officer has logged on to the application.

7.1.3.3 Main Flow

1. The use case begins when the academic officer clicks on the “Registration Permission” link provided on the
front screen of the academic officer’s main window.

2. The system displays the “Registration Permission” screen.

3. The academic officer selects the batch from the drop down menu list.

4. The system displays the list of all the students their serial so., roll. no., name, section, degree, registration
status and a check box in front of all the students to check or uncheck their registration permission.

5. The academic officer unchecks the registration option of all the students of the batch who are not allowed
to perform the registration and presses the “Allow Checked” button.

6. The system disables the registration of all such students.

7.1.3.4 Alternative Flows

If the academic officer forgets press the “Allow Checked” button, no changes made will be saved.

7.1.3.5 Post-condition(s)

All the students who shouldn’t be allowed to access the registration system have been blocked by the academic
officer so that they can’t view the online registration process.

7.2 UC02: New Semester Course Detail

7.2.1 UC02-01: Add Course

7.2.1.1 Brief Description

The purpose of this use case is to add course in the new semester created by academic officer. This is initiated when
a course is offered and is made available to the students having a minimum level. The course offer refers to a
specific course code of a department. As a part of the offering the semester, department, course name, section,
maximum seats and course outline is also mentioned.

7.2.1.2 Pre-condition(s)

1. The new semester has been created

2. The academic officer has the finalized list of all courses to be offered in the new semester.

3. Course code, department and credit hours of course are known.

4. Academic Officer has logged on to the application

Confidential XYZ, 2007 Page 27


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.2.1.3 Main Flow

1. The use case begins when the academic officer clicks on the “Add/Remove Offered Course” link provided
on the front screen of the academic officer’s main window.

2. The system displays the “Add/Remove Offered Course” screen.

3. The academic officer selects the semester, department and course name to be offered in the new semester.

4. The system displays the text fields to enter the sections, maximum seats and course outline is loaded from
the course DB for the courses.

5. The academic officer makes the entries and clicks the “Add” button.

6. The system makes the course available for registration in that particular department for that particular
semester.

7.2.1.4 Alternative Flows

If the academic officer does not enters the sections and maximum seats for that course, the course is still added in
the system but the system displays a warning message that no details have been given.

7.2.1.5 Post-condition(s)

All the courses to be offered are added in the semester and batch specified for the course.

7.2.2 UC02-02: Edit Course

7.2.2.1 Brief Description

The purpose of this use case is to add/edit the current information of a course. This use case is initiated when the
academic officer wants to make changes or update changes to the current information of a course. The fields that can
be modified include sections, maximum seats, outline, weight of assignments, quizzes, scaling factor, grading
scheme preferred list of teachers that can taught that course and the batches to which that course is to be offered.

7.2.2.2 Pre-condition(s)

1. The semester and the name of the course to be offered must be known by the academic officer.

2. Academic Officer has logged on to the application.

7.2.2.3 Main Flow

1. The use case begins when the academic officer clicks on the “Edit Offered Course” link provided on the
front screen of the academic officer’s main window.

2. The system displays the “Edit Offered Course” screen.

3. The academic officer selects the semester and course offered to add/edit.

4. The system displays the details of that course including the quizzes, assignments, projects, monthly, final
weights, scaling factor, the grading scheme, the teachers preferred to teach the course and the batches to
which that course can be offered.

5. The academic officer makes his selections and clicks on the “Update” button.

Confidential XYZ, 2007 Page 28


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

6. The system updates the changes for that particular course in the courses being offered.

7.2.2.4 Alternative Flows

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.2.2.5 Post-condition(s)

The changes made should be updated in the course detail.

7.2.3 UC02-03: Remove Course

7.2.3.1 Brief Description

The purpose of this use case is to delete any course from the list of courses being offered. The academic officer can
select a course from the drop down menu and then select the course to be deleted. As a result all the information of
that course would be removed.

7.2.3.2 Pre-condition(s)

1. The course must not be offered in any semester and it must not be part of exemption of a student.

2. Academic Officer has logged on to the application.

7.2.3.3 Main Flow

1. The use case begins when the academic officer clicks on the “Add/Remove Offered Course” link provided
on the front screen of the academic officer’s main window.

2. The system displays the “Add/Remove Offered Course” screen.

3. The academic officer selects the semester, department and course name to be deleted from the particular
semester.

4. The system displays the sections, maximum seats and course outline of that particular course.

5. The academic officer clicks on the “Delete” button to remove the course.

6. The system deletes the course from the list of courses offered for that particular semester.

7.2.3.4 Alternative Flows

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.2.3.5 Post-condition(s)

All the course details should be removed from the system.

Confidential XYZ, 2007 Page 29


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.2.4 UC02-04: View Course List

7.2.4.1 Brief Description

The purpose of this use case is to view a list of offered courses for a semester. This is initiated when the user from
the Academics Office needs to view all the offered courses from a particular semester. The user selects the semester
and gets a list of all the offered courses along with the links for grade sheet, attendance sheet, and results.

7.2.4.2 Pre-condition(s)

1. The academic officer has logged in the system.

2. All the courses have been added in the system.

7.2.4.3 Main Flow

1. The use case begins when the academic officer clicks on the “Offered Courses” link provided on the front
screen of the academic officer’s main window.

2. The system displays the “Offered Courses” screen.

3. The academic officer selects the semester whose list of courses is to be displayed.

4. The system displays the list of courses of that semester along with the links for grade sheet, attendance
sheet, and results.

7.2.4.4 Alternative Flows

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.2.4.5 Post-condition(s)

A list of all the courses of the semester selected is viewed by the academic officer.

7.3 UC03: New Batch Registration

7.3.1 UC03-01: Create New Batch

7.3.1.1 Brief Description

The purpose of this use case is to add a new batch in the system. This use case is initiated when new admissions are
made and passing students list are to be added in the system. The academic officer creates a new batch by providing
a name and starting semester of that batch.

7.3.1.2 Pre-condition(s)

1. The semester of the batch intake has already been created in the system.

2. Academic Officer has logged on to the application.

7.3.1.3 Main Flow

1. The use case begins when the academic officer clicks on the “Add/Edit Batch” link provided on the front
screen of the academic officer’s main window.

Confidential XYZ, 2007 Page 30


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

2. The system displays the “Add/Edit Batch” screen.

3. The academic officer enters the name of the new batch and selects the starting semester from the drop
down menu and clicks on the “OK” button.

4. The system creates a new batch and enters it in the list of current batches.

7.3.1.4 Alternative Flows

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.3.1.5 Post-condition(s)

The newly admitted students can be entered into the batch which has been created for them.

7.3.2 UC03-02: Edit Batch

7.3.2.1 Brief Description

The purpose of this use case is to add/edit the information of the current batch in the system or add information to
the new batch created. The information that can be added or updated includes the sections in that batch.

7.3.2.2 Pre-condition(s)

1. The batch exists in the system and its name is known by the academic officer.

2. Academic Officer has logged on to the application.

7.3.2.3 Main Flow

1. The use case begins when the academic officer clicks on the “Add/Edit Batch” link provided on the front
screen of the academic officer’s main window.

2. The system displays the “Add/Edit Batch” screen.

3. The academic officer enters the name of the existing batch and clicks the “OK” button.

4. The system displays the information stored related to that batch.

5. The academic officer makes required changes to the sections and the starting semester and clicks on the
“Update” button.

6. The system updates the changes related to that batch.

7.3.2.4 Alternative Flows

7.3.2.5 Post-condition(s)

The details of the relevant batch is updated in the system.

Confidential XYZ, 2007 Page 31


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.3.3 UC03-03: Register New Batch

7.3.3.1 Brief Description

The purpose of this use case is to perform the registration of the students of the new batch or of the first semester.
This is initiated after the new batch is created in the system and the lists of passing students have been entered in
ABC from NUTES. The academic officer selects the courses that are to be offered to the first semester students and
registers those courses to all the students of first semester.

7.3.3.2 Pre-condition(s)

1. The new batch has been created in the system and the list of the new students have been added.

7.3.3.3 Main Flow

1. The use case begins when the academic officer clicks on the “Register New Batch” link provided on the
front screen of the academic officer’s main window.

2. The system displays the “Register New Batch” screen.

3. The academic officer selects the batch and the degree and clicks on the “OK” button.

4. The system displays a list of all the students and the courses offered to those students.

5. The academic officer selects all students and presses the “Register” button.

6. The system registers those courses for all the students of the first semester.

7.3.3.4 Alternative Flows

7.3.3.5 Post-condition(s)

The new batch’s registration has been done.

7.4 UC04: Student Registration Request

7.4.1 UC04-01: Make Course Registration Request

7.4.1.1 Brief Description

The purpose of this use case is to request for a course for registration. This is initiated when students are allowed to
submit their requests for registration of courses for a semester. The student who wants to request registration in a
course selects the course and submits the request to the system.

7.4.1.2 Pre-condition(s)

1. The registration has started and the students can view the list of offered courses for the new semester.

2. Student has logged on to the application.

7.4.1.3 Main Flow

1. The use case starts when the student clicks on the “Online Registration” button on the main screen.

2. The system displays all the courses the student can register in the new semester.

Confidential XYZ, 2007 Page 32


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

3. The student selects the courses he wants to register and clicks on the “Register” button.

4. The system sends the request to the academic officer and displays a message to the student that the request
has been submitted.

7.4.1.4 Alternative Flows


3ai) The student cannot register for courses more than his maximum limit as defined by the university
rules.
4ai) The student cannot generate more than one registration requests.
7.4.1.5 Post-condition(s)

The student has placed a registration request and it is send to the academic officer.

7.4.2 UC04-02: Make Survey/Thesis Registration Request

7.4.2.1 Brief Description

The purpose of this use case is to request a thesis/survey for registration. This is initiated by an MS student at the
time of registration. He has to enter the topic and teacher name to request for registration.

7.4.2.2 Pre-condition(s)

1. The student belongs to MS degree and has completed the two specialization courses requirement.

2. Student has logged on to the application.

7.4.2.3 Main Flow

1. The use case starts when the student clicks on the “Online Registration” button on the main screen.

2. The system displays all the courses the student can register in the new semester.

3. The student clicks on the “Register Thesis/Survey”.

4. The system displays the form for registering survey/thesis.

5. The student enters the topic name, the advisor name, area of specialization and select thesis or non-thesis
option on the form.

6. The student presses the “Submit Request” button and the system displays a message that the request has
been submitted.

7. The system sends the request to the academic officer for authorization.

7.4.2.4 Alternative Flows


3ai) The student cannot register survey/thesis as a fourth course.
7.4.2.5 Post-condition(s)

The student’s thesis/survey request has been submitted and send to the academic officer.

Confidential XYZ, 2007 Page 33


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.4.3 UC04-03: Allow/Disallow Add/Drop Requests

7.4.3.1 Brief Description

The purpose of this use case is to allow/disallow the students to make add/drop requests. This use case is initiated by
the academic officer when the institution announces the add/drop date. Before and after that the student can’t place
any add/drop request.

7.4.3.2 Pre-condition(s)

1. The academic officer is logged in the system.

2. The institution has announced the date of add/drop courses.

7.4.3.3 Main Flow

1. The use case starts when the academic officer clicks on the “Allow Add/Drop Request”.

2. The screen for “Allow Add/Drop Request” is displayed.

3. The academic officer allows the students to start submitting their add/drop course requests by clicking on
the “Enable Add/drop” button.

4. As a result the system allows all the students who can view the registration to make add/drop requests.

7.4.3.4 Alternative Flows

7.4.3.5 Post-condition(s)

The add/drop screen is viewable to all the students and they can send their add/drop requests until the time specified
by the university

7.4.4 UC04-04: Make Add/Drop Request

7.4.4.1 Brief Description

The purpose of this use case is to make an add/drop course request. It is initiated by the student when the academic
officer announces the date for add/drop and the he allows the students to generate add/drop course requests.

7.4.4.2 Pre-condition(s)

1. Student has logged on to the application.

2. The course requested to drop has been requested for registration.

3. The course student wants to add is in the list of offered courses for that student.

4. The university has announced the date of add/drop for the students.

7.4.4.3 Main Flow

1. The use case starts when the student clicks on the “Add/Drop” button on the main screen.

2. The system displays all the courses the student has registered in the new semester.

3. The student selects the courses he wants to add from the list of all the available courses he can register in

Confidential XYZ, 2007 Page 34


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

the current semester.

4. The student clicks on the “Add” button.

5. The student selects the courses from the already registered courses to drop.

6. The student then clicks on “Drop” button.

7. The requests of add/drop are send to the academic officer.

7.4.4.4 Alternative Flows


4ai) The student cannot register for more courses then his registration limit.
5ai) The course once dropped cannot be added again.
7.4.4.5 Post-condition(s)

The add/drop course request is send to the academic officer and the student’s current status is set to “pending” for
the add/drop course requests.

7.4.5 UC04-05: View Repeat Courses Request

7.4.5.1 Brief Description


The main purpose of this use case is to view the courses that the student can repeat. It is initiated whenever the
student wants to see the list as this list only shows the courses and their names he can repeat regardless of whether
they are offered in the current semester or not.
7.4.5.2 Pre-condition(s)

1. The student has logged on to the application.

2. The list of the courses that the student can repeat is updated in the system.

7.4.5.3 Main Flow

1. The use case starts when the student clicks on the “view repeat courses” on the main screen displayed to
him.

2. The system displays a list of courses that the student can repeat regardless of the fact that they are offered
in the current semester or not.

7.4.5.4 Alternative Flows

7.4.5.5 Post-condition(s)

The list is visible to the student who requests to see the repeat courses in his transcript.

Confidential XYZ, 2007 Page 35


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.5 UC05: Student Request Authorization BY AO

7.5.1 UC05-01: Authorize Student Registration Request by AO

7.5.1.1 Brief Description


The main purpose of this use case is to enable the academic officer to view and approve the course registration
requests send to him by the students. The use case is initiated by the academic officer when the students have made
their registration requests. All the requests are forwarded to the academic officer and he has to verify them before
getting them approved from the higher authorities in the chain.
7.5.1.2 Pre-condition(s)

1. The academic officer has logged on to the application.

2. The students have completed their course registration requests.

7.5.1.3 Main Flow

1. The use case starts when the academic officer clicks on the “registration requests” on his main screen.

2. The system displays the batch name and the students roll no who have requested for registration.

3. The academic officer selects the particular student and views his request.

4. The system displays the student’s semester, program, roll number, name, date, year and courses he has
requested.

5. The academic officer approves the request and marks the status as “pending”.

6. After the submission of the students dues, the Academic Officer changes the registration status from
“Pending” to “Submit Fee” for all the students.

7.5.1.4 Alternative Flows

5ai) If the student is an MS student the academic officer after reviewing the request sends it to the advisor for
approval (use case: Authorize Student Registration Request by Advisor). After the approval of the
advisor then the status of registration of MS students’ is changed to “Pending”.

5bi) If the academic officer finds any issue with the request he wont change the status and the student has to
resolve the issue to continue the process.

6ai) The Academic Officer changes the registration status from “Pending” to “Decline” for all the students
who haven’t paid the fees or has submitted a semester freeze request.

7.5.1.5 Post-condition(s)

The registration request is approved and completed.

7.5.2 UC05-02: Authorize Student Thesis/Survey Request by AO

7.5.2.1 Brief Description

The main purpose of this use case is to enable the academic officer to view and approve the survey/thesis requests
send to him by the students. The use case is initiated by the academic officer when the students have made their
survey/thesis requests. All the requests are forwarded to the academic officer and he has to verify them before
getting them approved from the advisor with whom the students have requested to do their survey/thesis.

Confidential XYZ, 2007 Page 36


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.5.2.2 Pre-condition(s)

1. The academic officer has logged on to the application.

2. The MS students have completed their survey/thesis requests.

7.5.2.3 Main Flow

1. The use case starts when the academic officer clicks on the view survey/thesis request link on the main
screen.

2. The system displays the list of all students who have made the survey/thesis request.

3. The academic officer selects a particular student to view his request.

4. The system displays the student’s semester, program, roll number, name, date, year, topic name, the advisor
name, area of specialization and thesis or non-thesis option.

5. The academic officer reviews the request and if there are no issues, he changes the status of the registration
of survey/thesis to “Meeting Required”.

6. He forwards the request to the advisor with whom the student has made a request to do his survey/thesis.

7. When the advisor approves the request, the academic officer changes the status of the request as
“Approved”.

7.5.2.4 Alternative Flows

5ai) If the academic officer finds any issues in the request he does not changes the status and informs the
student to resolve the issues to continue the process.

7ai) If the advisor does not approves the request the academic officer change the status to “Disapproved”.

7.5.2.5 Post-condition(s)

The survey/thesis request is approved by the academic officer and the advisor and status of the student has been
changed.

7.5.3 UC05-03: Authorize Student Add/Drop Request by AO

7.5.3.1 Brief Description

The main purpose of this use case is to enable the academic officer to view and approve the course add/drop
requests send to him by the students. The use case is initiated by the academic officer when the students have made
their add/drop requests. All the requests are forwarded to the academic officer and he has to verify them.

7.5.3.2 Pre-condition(s)

1. The academic officer has logged on to the application.

2. The students have completed their add/drop requests.

7.5.3.3 Main Flow

1. The use case starts when the academic officer clicks on the “add/drop requests” on his main screen.

Confidential XYZ, 2007 Page 37


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

2. The system displays the courses list against which add/drop requests are made.

3. The academic officer selects a course and the system displays the list of students who added the course
when there were seats, the waiting list and the drop list.

4. The academic officer selects the name of the student from the list and either adds or drops the requested
course from his academic record as requested by the student.

7.5.3.4 Alternative Flows

4ai) If there are issues in the student’s request than the academic officer does not adds or removes the course.
The student has to resolve the issue to complete the process.

7.5.3.5 Post-condition(s)

The add/drop requests of the students are complete.

7.6 UC06: Student Request Authorization BY Advisor

7.6.1 UC06-01: Authorize Student Registration Request by Advisor

7.6.1.1 Brief Description


The purpose of this use case is to authorize the MS students’ registration requests. MS students’ registration for
courses is not completed until the advisor approves the requests. This use case is initiated by the advisor when the
academic officer sends him all the registration requests.
7.6.1.2 Pre-condition(s)

1. The academic officer has checked all the requests and forwarded them to the concerned advisor.

2. The advisor is also part of the application.

3. The advisor has logged on to the application.

7.6.1.3 Main Flow

1. The use case starts when the advisor clicks on the student registration requests send to him.

2. The system displays the lists of the MS students.

3. The academic officer selects a student and the system displays his semester, program, roll number, name,
date, year and courses he requested for.

4. The advisor marks the request as “Approved”.

5. The system displays all the requests and their status marked by the advisor.

6. When all the requests are done the advisor sends it back to the academic officer.

7.6.1.4 Alternative Flows

4ai) If the advisor has some issues he marks the request as “Disapproved” and sends it to the academic
officer.

Confidential XYZ, 2007 Page 38


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.6.1.5 Post-condition(s)

The advisor checks all the requests and sends his feedback to the academic officer.

7.6.2 UC06-02: Authorize Student Thesis/Survey Request by Advisor

7.6.2.1 Brief Description


The purpose of this use case is to authorize the MS students’ survey/thesis requests. MS students’ survey/thesis
requests are not completed until the advisor approves the requests. This use case is initiated by the advisor when the
academic officer sends him all the survey/thesis requests of the MS students.
7.6.2.2 Pre-condition(s)

1. The academic officer has checked all the requests and forwarded them to the concerned advisor.

2. The advisor is also part of the application.

3. The advisor has logged on to the application.

7.6.2.3 Main Flow

1. The use case starts when the advisor clicks on the student survey/thesis requests send to him.

2. The system displays the lists of the MS students.

3. The academic officer selects a student and the system displays his semester, program, roll number, name,
date, year, topic name, the advisor name, area of specialization and thesis or non-thesis option.

4. The advisor marks the request as “Approved”.

5. The system displays all the requests and their status marked by the advisor.

6. When all the requests are done the advisor sends it back to the academic officer.

7.6.2.4 Alternative Flows

4ai) If the advisor has some issues he marks the request as “Disapproved” and sends it to the academic
officer.

7.6.2.5 Post-condition(s)

The advisor checks all the requests and sends his feedback to the academic officer.

7.6.3 UC06-03: Authorize Student Add/Drop Request by Advisor

7.6.3.1 Brief Description


The purpose of this use case is to authorize the MS students’ add/drop requests. MS students’ registration for
courses is not completed until the advisor approves the requests. This use case is initiated by the advisor when the
academic officer sends him all the add/drop course requests.
7.6.3.2 Pre-condition(s)

1. The academic officer has checked all the requests and forwarded them to the concerned advisor.

2. The advisor is also part of the application.

Confidential XYZ, 2007 Page 39


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

3. The advisor has logged on to the application.

7.6.3.3 Main Flow

1. The use case starts when the advisor clicks on the student add/drop requests send to him.

2. The system displays the lists of the MS students.

3. The academic officer selects a student and the system displays his semester, program, roll number, name,
date, year and courses they added and dropped.

4. The advisor marks the request as “Approved”.

5. The system displays all the requests and their status marked by the advisor.

6. When all the requests are done the advisor sends it back to the academic officer.

7.6.3.4 Alternative Flows

4ai) If the advisor has some issues he marks the request as “Disapproved” and sends it to the academic
officer.

7.6.3.5 Post-condition(s)

The advisor checks all the requests and sends his feedback to the academic officer.

7.7 UC07: Student Course Withdraw

7.7.1 UC07-01: Allow/Disallow Withdraw Requests

7.7.1.1 Brief Description

The purpose of this use case is to allow/disallow the students to make withdraw requests. This use case is initiated
by the academic officer after the registration is over. Until the seventeenth week of the semester the student can
place a request to withdraw a course from the list of courses registered. After that this option is not available to the
students.

7.7.1.2 Pre-condition(s)

1. The academic officer is logged in the system.

7.7.1.3 Main Flow

1. The use case starts when the academic officer clicks on the “Allow Withdraw Request”.

2. The screen for “Allow Withdraw Request” is displayed.

3. The academic officer allows the students to start submitting their withdraw course requests by clicking on
the “Enable Add/drop” button.

4. As a result the system allows all the students who can view the registration to make withdraw requests until
the seventeenth week of the semester.

5. After the seventeenth week the academic officer disables the option by clicking on the “Disallow Withdraw
Request”.

Confidential XYZ, 2007 Page 40


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

6. The system disables the withdraw screen for all the students.

7.7.1.4 Alternative Flows

7.7.1.5 Post-condition(s)

The student can’t make any more requests once the withdraw course screen has been disabled for all the students.

7.7.2 UC07-02: Make Course Withdraw Request

7.7.2.1 Brief Description

The purpose of this use case is to make a course withdraw request. It is initiated by the student until the seventeenth
week of the semester. After that the academic officer enables that option for all students.

7.7.2.2 Pre-condition(s)

1. Student has logged on to the application.

2. The desired course has been offered in the current semester and the student has registered it.

7.7.2.3 Main Flow

1. The use case starts when the student clicks on the “Withdraw Course” link on the main screen.

2. The system displays the list of all the registered courses for that student.

3. The student selects the courses to withdraw and presses the “withdraw” button.

4. The system sends the course withdraw request to the academic officer and displays a message to the student
that the request has been submitted.

7.7.2.4 Alternative Flows

7.7.2.5 Post-condition(s)

The course withdraw request is submitted to the academic officer for approval.

7.7.3 UC07-03: Authorize Course Withdraw Request by AO

7.7.3.1 Brief Description


The purpose of this use case is to authorize the course withdraw request. The use case is initiated by the academic
officer after the students have made their course withdraw requests. The academic officer checks all the requests,
makes sure there are no issues with the students requests, gets the request approved by the teacher and then
withdraws the student’s course.
7.7.3.2 Pre-condition(s)

1. The academic officer is logged on to the application.

2. The students have completed their withdraw requests.

7.7.3.3 Main Flow

1. The use case starts when the academic officer clicks on to the link that displays all the course(s) withdraw
requests.

Confidential XYZ, 2007 Page 41


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

2. The academic officer selects the course withdraw request of a particular student.

3. The system displays the student’s semester, program, roll number, name, date, year and the course(s)
requested to withdraw.

4. After reviewing the request, the academic officer forwards the request to the faculty member teaching that
particular course(s).

5. After the approval from the teacher the request is forwarded back to the academic officer.

6. The academic officer clicks on the “course withdraw” link on his main screen.

7. The system displays the course withdraw screen.

8. The academic officer enters the roll no and semester of the student whose course(s) are to be withdrawn.

9. The system displays all the courses of that student registered in the current semester.

10. The academic officer selects the courses to withdraw and presses the “Withdraw” button.

11. The system changes the grades of the courses withdrawn to “W” and updates it in student’s view.

7.7.3.4 Alternative Flows


4ai) If the academic officer finds any problem with the request he informs the student to come and visit
to resolve the issue.
5ai) If the faculty member does not approves the request and marks it as disapproved then the student
can’t withdraw the course and has to resolve the issue with the faculty member.
7.7.3.5 Post-condition(s)

The request is approved and the course has been withdrawn from the student’s current registered courses list.

7.7.4 UC07-04: Authorize Course Withdraw Request by Teacher

7.7.4.1 Brief Description


The purpose of this use case is to authorize the course withdraw request. The use case is initiated by the teacher after
the academic officer sends the course withdraw requests. The teacher checks the requests, makes sure there are no
issues with the students requests, marks them as approved and send them back to the academic officer.
7.7.4.2 Pre-condition(s)

1. The academic officer has checked all the requests and forwarded them to the concerned faculty member.

2. The teacher is also part of the application.

3. The teacher is logged on to the application.

7.7.4.3 Main Flow

1. The use case starts when the teacher officer clicks on to the link that displays all the course(s) withdraw
requests.

2. The teacher selects the course withdraw request of a particular student.

Confidential XYZ, 2007 Page 42


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

3. The system displays the student’s semester, program, roll number, name, date, year and the course(s)
requested to withdraw.

4. The teacher marks the request as “Approved” and forwards it to the academic officer.

7.7.4.4 Alternative Flows


4ai) If the teacher does not approves the request he marks the request as “Disapproved” and sends it to
the academic officer. The student cant withdraw the course.
7.7.4.5 Post-condition(s)

The request is approved by the teacher and forwarded back to the academic officer.

7.8 UC08: Student Semester Freeze

7.8.1 UC08-01: Make Semester Freeze Request

7.8.1.1 Brief Description

The purpose of this use case is to make a semester freeze request. This is initiated at the time of registration when
the students can request to freeze the new semester. The student has to enter the reason for freezing the semester and
submit the request to the academic officer.

7.8.1.2 Pre-condition(s)

1. Student has logged on to the application

2. This is not the third consecutive semester freeze request.

7.8.1.3 Main Flow

1. The use case starts when the student clicks on the “semester freeze” button on the main screen.

2. The system displays the student’s semester, program, roll number, name, date and year.

3. The student enters his reason for freezing the semester.

4. The student completes the form and submits the request to the academic officer by pressing the “Submit
request” button.

5. The system sends the semester freeze request to the academic officer and displays a message to the student
that the request has been submitted.

7.8.1.4 Alternative Flows

7.8.1.5 Post-condition(s)

The request for semester freeze has been send to the academic officer and the student can’t request for any courses
now.

Confidential XYZ, 2007 Page 43


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.8.2 UC08-02: Authorize Semester Freeze Request by AO

7.8.2.1 Brief Description


The purpose of this use case is to authorize the semester freeze request of the student. The use case is initiated by the
academic officer after the students have made their semester freeze requests. The academic officer checks all the
requests, makes sure there are no issues with the students requests and then allows them to freeze the semester.
7.8.2.2 Pre-condition(s)

1. The academic officer is logged on to the application.

2. All the semester freeze requests have been submitted to the academic officer and date for registration is
closed.

7.8.2.3 Main Flow

1. The use case starts when the academic officer clicks on to the link that displays all the semester freeze
requests.

2. The academic officer selects the semester freeze request of a particular student.

3. The system displays the student’s semester, program, roll number, name, date, year and the reason to freeze
the semester.

4. The academic officer opens the student’s registration permissions and changes the status to “Decline”.

5. The system applies the changes immediately.

7.8.2.4 Alternative Flows


4ai) If the student has any warning on his transcript then the academic officer forwards the request to
the advisor for approval. (use case: Authorize Semester Freeze Request by Advisor)
4bi) If the academic officer finds any issue then he doesn’t approves the request and would inform the
student to discuss the issues.
7.8.2.5 Post-condition(s)

The request is approved and the student’s current semester is freezed.

7.8.3 UC08-03: Authorize Semester Freeze Request by Advisor

7.8.3.1 Brief Description


The purpose of this use case is to authorize the semester freeze request of the student. The use case is initiated by the
advisor after the academic officer forwards the semester freeze request to the advisor. The advisor checks all the
requests, makes sure there are no issues with the students’ requests and then allows them to freeze the semester.
7.8.3.2 Pre-condition(s)

1. The academic officer has checked all the requests and forwarded them to the concerned advisor.

2. The advisor is also part of the application.

3. The advisor is logged on to the application.

7.8.3.3 Main Flow

1. The use case starts when the advisor officer clicks on to the link that displays all the semester freeze

Confidential XYZ, 2007 Page 44


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

requests.

2. The advisor selects the semester freeze request of a particular student.

3. The system displays the student’s semester, program, roll number, name, date, year and the reason to freeze
the semester.

4. The teacher marks the request as “Approved” and forwards it to the academic officer.

7.8.3.4 Alternative Flows


4ai) If the advisor has any issues he marks the request as “Disapproved” and sends it to the academic
officer. Then the academic officer informs the student about it.
7.8.3.5 Post-condition(s)

The request is approved by the advisor and he sends the request back to the academic officer.

7.9 UC09: Student Course Replacement

7.9.1 UC09-01: Make Course Replacement Request

7.9.1.1 Brief Description

The purpose of this use case is to make course replacement request. It is initiated by the student if he/she wants to
replace a particular course in order to improve his/her course grade. The course selected should be from the course
list already studied during the past one year.

7.9.1.2 Pre-condition(s)

1. Student has logged on to the application.

2. The course selected is present in the list of courses already studied.

3. The student has got an F grade in that course.

4. The course has not been offered in previous one year.

7.9.1.3 Main Flow

1. The use case starts when the student clicks on the “Replace Course” link on the main screen.

2. The system displays a list of courses already studied with grade “F” is displayed.

3. The student selects a course he wants to replace.

4. The system also displays a list of courses that the student studied atleast one semester after the failed
courses.

5. The student selects a course to replace by and clicks the “replace” button.

6. The system sends the course replacement request to the academic officer and displays a message to the
student that the request has been submitted.

Confidential XYZ, 2007 Page 45


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.9.1.4 Alternative Flows

7.9.1.5 Post-condition(s)

The request has been generated and submitted to the academic officer.

7.9.2 UC09-02: Authorize Course Replacement Request by AO

7.9.2.1 Brief Description


The purpose of this use case is to authorize the course replacement request of the student. It is initiated by the
academic officer when the students submit their requests. The academic officer checks the requests, makes sure
there are no issues with it regarding university’s policies and then forwards it to the HOD, director and dean for
approval. After their approval the request is completed.
7.9.2.2 Pre-condition(s)

1. The academic officer has logged on to the application.

2. The students’ course replacement requests have been completed and sent to the academic officer.

7.9.2.3 Main Flow

1. The use case starts when the academic officer clicks on to the link that displays all the course replacement
requests.

2. The academic officer selects the course replacement request of a particular student.

3. The system displays the student’s semester, program, roll number, name, date, year, the course to replace
and the course to replace by.

4. After reviewing the request, the academic officer forwards the request to the HOD.

5. After the approval from the HOD the academic officer forwards the request to the Director.

6. After the approval from the Director the academic officer forwards the request to the Dean.

7. After the approval from the dean the academic officer clicks on the “course replacement” link on the front
screen of his main window.

8. The system displays a screen where the academic officer can enter the roll no of the student whose course
is to be replaced.

9. The academic officer enters the roll no and presses the “find” button.

10. The system displays the students record and lists of all courses he failed and which he passed.

11. The academic officer selects the course to replace and the course to replace by and presses the “replace”
button.

12. The system makes the changes immediately and makes the course replacement on student’s record and
view.

7.9.2.4 Alternative Flows


5ai) If the HOD does not approves the request, academic officer can not forward it to the director. He

Confidential XYZ, 2007 Page 46


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

has to get HOD’s approval. So the student’s request would not be completed if the HOD marks the
request as “Disapprove”.
6ai) If the Director does not approves the request, academic officer can not forward it to the dean. He
has to get Director’s approval. So the student’s request would not be completed if the Director
marks the request as “Disapprove”.
7ai) If the dean does not approves the request, academic officer can not complete the request. He has to
get dean’s approval. So the student’s request would not be completed if the dean marks the request
as “Disapprove”.
7.9.2.5 Post-condition(s)

The request has been approved and the course requested has been replaced.

7.9.3 UC09-03: Authorize Course Replacement Request by HOD

7.9.3.1 Brief Description


The purpose of this use case is to authorize the course replacement request of the student. The use case is initiated
by the HOD when the academic officer forwards the request of the course replacement to him. He checks the request
makes sure there are no issues with it regarding university’s policies and then approves the request and forwards it
back to the academic officer.
7.9.3.2 Pre-condition(s)

1. The academic officer has checked all the requests and forwarded them to the HOD.

2. The HOD is also part of the application.

3. The HOD is logged on to the application.

7.9.3.3 Main Flow

1. The use case starts when the HOD officer clicks on to the link that displays all the course replacement
requests.

2. The HOD selects the course replacement request of a particular student.

3. The system displays the student’s semester, program, roll number, name, date, year, the course to replace
and the course to replace by.

4. The HOD marks the request as “Approved” and forwards it to the academic officer.

7.9.3.4 Alternative Flows


4ai) If the HOD has any issues he marks the request as “Disapproved” and sends it to the academic
officer.
7.9.3.5 Post-condition(s)

The request has been approved by the HOD and forwarded back to the academic officer.

7.9.4 UC09-04: Authorize Course Replacement Request by Director

7.9.4.1 Brief Description


The purpose of this use case is to authorize the course replacement request of the student. The use case is initiated
by the director when the academic officer forwards the request of the course replacement to him. He checks the
request makes sure there are no issues with it regarding university’s policies and then approves the request and
forwards it back to the academic officer.

Confidential XYZ, 2007 Page 47


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.9.4.2 Pre-condition(s)

1. The academic officer has checked all the requests and forwarded them to the Director.

2. The director has an access to all the students’ request.

7.9.4.3 Main Flow

1. The use case starts when the director clicks on to the link that displays all the course replacement requests.

2. The director selects the course replacement request of a particular student.

3. The system displays the student’s semester, program, roll number, name, date, year, the course to replace
and the course to replace by.

4. The director marks the request as “Approved” and forwards it to the academic officer.

7.9.4.4 Alternative Flows


4ai) If the director has any issues he marks the request as “Disapproved” and sends it to the academic
officer.
7.9.4.5 Post-condition(s)

The request has been approved by the Director and forwarded back to the academic officer.

7.9.5 UC09-05: Authorize Course Replacement Request by Dean

7.9.5.1 Brief Description


The purpose of this use case is to authorize the course replacement request of the student. The use case is initiated
by the dean when the academic officer forwards the request of the course replacement to him. He checks the request
makes sure there are no issues with it regarding university’s policies and then approves the request and forwards it
back to the academic officer.
7.9.5.2 Pre-condition(s)

1. The academic officer has checked all the requests and forwarded them to the Dean.

2. The Dean has an access to all the students’ request.

7.9.5.3 Main Flow

1. The use case starts when the dean clicks on to the link that displays all the course replacement requests.

2. The dean selects the course replacement request of a particular student.

3. The system displays the student’s semester, program, roll number, name, date, year, the course to replace
and the course to replace by.

4. The dean marks the request as “Approved” and forwards it to the academic officer.

7.9.5.4 Alternative Flows


4ai) If the dean has any issues he marks the request as “Disapproved” and sends it to the academic
officer.

Confidential XYZ, 2007 Page 48


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.9.5.5 Post-condition(s)

The request has been approved by the Dean and forwarded back to the academic officer.

7.10 UC010: Late Student Registration


7.10.1 UC010-01: Make Late Registration

7.10.1.1 Brief Description

The purpose of this use case is to make registration of the students after the registration deadline on behalf of the
academic officer. The student places the request to the academic officer and he registers the courses.

7.10.1.2 Pre-condition(s)

1. The academic officer is logged in the system.

2. The registration time for the students is over and they can no longer make any more requests online.

7.10.1.3 Main Flow

1. The use case starts when the academic officer clicks on the “Register Student” link provided on the front
screen of the academic officer’s main window.

2. The system displays “Register Student” screen.

3. The academic officer enters the roll number of the student he wants to register and clicks on the “Find”
button.

4. The system displays the list of offered courses for that student, with their credit hours, seats remaining and
type as core or elective.

5. The academic officer selects the courses and clicks on the “Place Request” button.

6. The system generates a request and makes the registration status of the student to “pending”.

7.10.1.4 Alternative Flows

Registration of any such student cannot be made that is not allowed to view the registration process and his
registration status is disabled.

7.10.1.5 Post-condition(s)

The course registration request has been made for the student who has requested for late registration.

7.10.2 UC10-02: Verify Registration

7.10.2.1 Brief Description

The purpose of this use case is to verify the registration requests made by the student. The initiator of this use case is
the academic officer who checks the academic record of the student to confirm his registration requests.

7.10.2.2 Pre-condition(s)

The registration requests have been made by the students.

Confidential XYZ, 2007 Page 49


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.10.2.3 Main Flow

1. The use case starts when the academic officer clicks on the “Registration Fee” link provided on the front
screen of the academic officer’s main window.

2. The system displays the list of all the pending registration requests of all the students.

3. The academic officer changes the status to “Submit Fee” of all the students who have no issues to resolve.

7.10.2.4 Alternative Flows

In case the student issues are yet to be resolved the academic officer does not changes the status of the student and
the status remains “pending”, until there are no more issues.

7.10.2.5 Post-condition(s)

The new status is now visible at the student end too.

7.11 UC11: Migrated Student Registration


7.11.1 UC11-01: Load Student Courses and Results

7.11.1.1 Brief Description

The purpose of this use case is to load the courses and the course results taken by a transferred student. This is
initiated by the Academics Office to take the student’s previous academic record from the prior campus and enter it
into the new campus’s system. The user selects the roll number for transfer of courses and loads the information
from a file.

7.11.1.2 Pre-condition(s)

1. The academic officer is logged in the system.

2. He has received the previous semester and course details of the migrated student.

7.11.1.3 Main Flow

1. The use case starts when the academic officer clicks on the “Register Previous Semesters” link provided on
the front screen of the academic officer’s main window.

2. The system displays the “Register Previous Semester” window.

3. The academic officer enters the roll number of the migrated student and clicks on the “Find” button.

4. The system displays the semesters registered and not registered for that student.

5. The academic officer selects the semesters he wants to register for that student and clicks on the “Add”
button.

6. The system adds those semesters in the student’s list.

7. The academic officer then clicks on the “Final Grades” link on the main screen.

8. The window for “Final Grades” is opened.

Confidential XYZ, 2007 Page 50


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

9. The academic officer selects the semester and course and the grades of the new student added in that
semester and assign him the grade he obtained in the previous campus.

10. The academic officer continues to add the grades to the courses the student studied in the previous
semesters.

11. The system updated the previous semesters and course detail for that particular student.

7.11.1.4 Alternative Flows

If the student is not found in the system this means his profile is not yet created. Then the academic officer has to
create his profile and then proceed with normal flow.

7.11.1.5 Post-condition(s)

The migrated student’s information is updated in the system and he can now view it online through his log in.

7.11.2 UC11-02: View Migrated Semesters Info

7.11.2.1 Brief Description

The purpose of this use case is to view the previous semesters’ information of a transferred/migrated student. This is
initiated by the student to view his previous academic record of the other campus.

7.11.2.2 Pre-condition(s)

1. Migrated student information has been added in the system

2. The student is logged in the system.

7.11.2.3 Main Flow

1. The use case starts when the student clicks on the “Results” link in his log in.

2. The system displays all the courses and their grades the student obtained in the previous campus.

7.11.2.4 Alternative Flows

7.11.2.5 Post-condition(s)

The student has viewed the details of his courses and grades obtained.

7.12 UC12: Manage Student Profile


7.12.1 UC12-01: Create Student Profile

7.12.1.1 Brief Description

The purpose of this use case is to create a profile for personal information and past records of a student. This is
initiated when the information regarding the student being admitted to the university reaches the Academic Officer.
The information relates to the personal information, contact information and the past academic record of the
candidate student. After getting the information, the Academic Officer inputs the information of the corresponding
fields related to the student into the system.

Confidential XYZ, 2007 Page 51


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.12.1.2 Pre-condition(s)

1. User’s identity has been authenticated.

2. Academic Officer has logged on to the application.

3. Database is up and running.

4. Year of enrollment and serial number of the new student should be known before entering the data and
profile information into the system.

7.12.1.3 Main Flow

1. The use case begins when the academic officer clicks on the “Create/Modify Profile” link provided on the
home page of the academic officer’s view.

2. The system displays the “Create/Modify Profile” page.

3. The Academic Officer selects the “New” radio button to create a profile for a new student and selects the
year of enrollment from the drop down list and enters the serial number of the new student and presses the
“Ok” button.

4. The system displays the “Create Profile” page.

5. The Academic Officer enters “Full Name”, selects “Gender” from the drop down list, and enters “Date of
Birth”, “Blood Group”, “NIC No.”, and “Nationality” of the student.

6. The Academic Officer enters the contact information of the student, which includes the “E-mail”, “URL”,
“Phone No.”, “Mobile Phone No.”, “Address”, “City”, “Country” and “Postal Code”.

7. The Academic Officer enters the parent’s contact information in the “E-mail”, “URL”, “Phone No.”,
“Mobile Phone No.”, “Address”, “Postal Code” text fields and selects the “City” and “Country” from the
drop down list.

8. The Academic Officer can also click on the “Copy Student’s Contact” link in case the contact information
of the student is same as that of the parent’s contact information.

9. The system copies the text entered in the contact information of the student into the parent’s contact fields.

10. The Academic Officer enters the correspondence contact information in the “Phone No.”, “Address”,
“Postal Code” text fields and selects the “City”, and “Country” from the drop down list.

11. The Academic Officer can also click on the “Copy Student’s Contact” link, in case the contact information
of the student is same as that of the correspondence contact information.

12. The system copies the text entered in the contact information of the student into the correspondence contact
fields.

13. The Academic Officer enters the university related information that includes the “Registration No.”,
“Admission Roll No.” in the text fields and selects the “1st Choice Campus”, “2nd Choice Campus” and
“Admission test Campus” from the drop down list.

14. The Academic Officer selects the background information of the student from the options: “Is computer

Confidential XYZ, 2007 Page 52


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

User?” “Is Internet user?” “Has PC at home” and “Knows programming” from the drop down list.

15. The Academic Officer enters the ABC information in the “Profile Password” and “Confirm Password” text
fields.

16. The Academic Information presses the “Save & Next” button.

17. The system saves the profile information of the student.

7.12.1.4 Alternative Flows

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.12.1.5 Post-condition(s)

A student becomes available to the university database and can be mentioned in all the corresponding records.

7.12.2 UC12-02: Edit Student Profile

7.12.2.1 Brief Description

The purpose of this use case is to edit/update the personal information of a student already present in the system
database. This is initiated when the information regarding the student needs to be changed. After getting the new
information, the Academic Officer changes the personal information, previous academic record, or the contact
information, whichever applicable, already present in the system.

7.12.2.2 Pre-condition(s)

1. User’s identity has been authenticated.

2. Academic Officer has logged on to the application.

3. Database is up and running.

4. Student roll number should be known in order to retrieve the profile information.

7.12.2.3 Main Flow

1. The use case begins when the academic officer clicks on the “Create/Modify Profile” link provided on the
home page of the academic officer’s view.

2. The system displays the “Create/Modify Profile” page.

3. The Academic Officer selects the “Existing” radio button to modify a profile for already entered student
and enters the roll number of the new student and presses the “Ok” button.

4. The system displays the “Modify Profile” page.

5. The system displays the personal information, which includes “Full Name”, “Gender”, “Date of Birth”,
“Blood Group”, “NIC No.”, and “Nationality”. Student Contact Information which includes “E-mail”,
“URL”, “Phone No.”, “Mobile Phone No.”, “Address”, “City”, “Country” and “Postal Code”.

Confidential XYZ, 2007 Page 53


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

6. The system displays the parent’s contact information in the “E-mail”, “URL”, “Phone No.”, “Mobile Phone
No.”, “Address”, “Postal Code”, “City” and “Country”.

7. The system displays the correspondence contact information in the “Phone No.”, “Address”, “Postal Code”,
“City”, and “Country”.

8. The system displays the university related information that includes the “Registration No.”, “Admission
Roll No.”, “1st Choice Campus”, “2nd Choice Campus” and “Admission test Campus”.

9. The system displays the background information of the student, which includes: “Is computer User?” “Is
Internet user?” “Has PC at home” and “Knows programming”..

10. The system displays the ABC information in the “Profile Password” and “Confirm Password” fields.

11. The Academic Officer make changes in the desired fields and presses the “Save & Next” button.

12. The system updates the changes made in the student profile.

7.12.2.4 Alternative Flows

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.12.2.5 Post-condition(s)

Changes are made in the existing profile of the student.

7.12.3 UC12-03: Remove Student Profile

7.12.3.1 Brief Description

The purpose of this use case is to delete the personal information of a student from the system database. This is
initiated when the information regarding the student needs to be deleted. After getting student profile roll number,
the Academics Officer deletes the profile already present in the system.

7.12.3.2 Pre-condition(s)

1. User’s identity has been authenticated.

2. Academic Officer has logged on to the application.

3. Database is up and running.

4. Student roll number should be known by the academics office in order to delete the profile.

7.12.3.3 Main Flow

1. The use case begins when the academic officer clicks on the “Create/Modify Profile” link provided on the
home page of the academic officer’s view.

2. The system displays the “Create/Modify Profile” page.

3. The Academic Officer selects the “Remove” radio button to delete a profile for already entered student.

Confidential XYZ, 2007 Page 54


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

4. The Academic Officer enters the roll number of the student whose profile needs to be deleted and presses
the “Ok” button.

5. The system displays a message that the profile has been deleted.

7.12.3.4 Alternative Flows

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.12.3.5 Post-condition(s)

The student profile is permanently deleted from the database.

7.12.4 UC12-04: View Student Profile

7.12.4.1 Brief Description

The purpose of this use case is to view the personal information of a student already present in the system database.
This is initiated by the student when he needs to view the registration status, course details and personal profile.

7.12.4.2 Pre-condition(s)

1. User’s identity has been authenticated.

2. Student has logged on to the application.

3. Database is up and running.

4. The student profile has been created before.

7.12.4.3 Main Flow

1. The use case begins when the student clicks on the “Personal Information” link provided on the home page
of the student’s view.

2. The system opens the student profile page.

3. The student views the personal, student’s contact, parent’s contact, correspondence contact, university
related and background information.

4. The student views the registration status on the home page of the student’s view.

5. The student clicks on the “Result” link provided on the home page of the student view.

6. The student selects the “degree” from the drop down list.

7. The system displays all the courses that the student has taken in the previous semester.

7.12.4.4 Alternative Flows

The Student closes this page.

The Student clicks on other links provided on this page.

Confidential XYZ, 2007 Page 55


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.12.4.5 Post-condition(s)

The student is able to view his/her profile, registration status and course details.

7.13 UC13: Manage Teacher Profile


7.13.1 UC13-01: Create Teacher Profile

7.13.1.1 Brief Description

The purpose of this use case is to create a profile for personal information of a teacher. This use case is initiated
when the academics office has to input the profile of a teacher/visiting faculty into the system. Faculty profiles
include the personal information along with pictures, degrees and qualification details, contact information and
current designation and employer.

7.13.1.2 Pre-condition(s)

1. User’s identity has been authenticated.

2. Academic Officer has logged on to the application.

3. Database is up and running.

7.13.1.3 Main Flow

1. The use case begins when the academic officer clicks on the “Add/Edit Teacher Profile” link provided on
the home page of the academic officer’s view.

2. The system displays the “Add/Edit Teacher Profile” page.

3. The Academic Officer selects the “New” radio button to create a profile for a new teacher and enters the
user name for the teacher and presses the “Ok” button.

4. The system displays the “Create Profile” page.

5. The Academic Officer enters the personal information of the teacher that includes “Full Name”, “Date of
Birth”, “NIC No.” and selects “Gender” and “Title” from the drop down list.

6. The Academic Officer clicks the “Browse” button and selects the picture of the teacher to be uploaded in
the picture box.

7. The Academic Officer clicks the “Set Picture” button.

8. The system displays the picture of the teacher in the picture box on the top right side of the add/edit teacher
profile page.

9. The Academic Officer enters the contact information of the teacher, which includes the “E-mail”, “URL”,
“Phone No.”, “Mobile No.”, “Address”, “City”, “Country” and “Postal Code”.

10. The Academic Officer enters the Office information in “Office”, “Designation”, “E-mail”, “URL”,
“Address”, “Phone No.”, “Fax No.”, “Postal Code” text fields and selects the “City” and “Country” from
the drop down list.

11. The Academic Officer enters the qualification information in the “Qualification”, “Year of Qualification”,

Confidential XYZ, 2007 Page 56


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

“Awarding Institute”, “Professional Experience” and “Teaching Experience” text fields.

12. The Academic Officer enters the University Related information in “Teacher Type”, “Active”, “Profile
Password”, “Confirm Password”, “Roll No.” textbox and check/uncheck the “Change Password” option.

13. The Academic Information presses the “Save” button.

14. The system saves the profile information of the teacher.

7.13.1.4 Alternative Flows

The Student closes this page.

The Student clicks on other links provided on this page.

7.13.1.5 Post-condition(s)

The teacher profile is created successfully.

7.13.2 UC13-02: Edit Teacher Profile

7.13.2.1 Brief Description

The purpose of this use case is to update the personal information related to a teacher/faculty member. This is
initiated when the profile of a teacher including personal, contact and academic information needs to be updated.
The academics office updates the relevant information and it is saved back in the system overwriting the previous
record.

7.13.2.2 Pre-condition(s)

1. User’s identity has been authenticated.

2. Academic Officer has logged on to the application.

3. Database is up and running.

4. Teacher name or ID in the system should be known.

7.13.2.3 Main Flow

1. The use case begins when the academic officer clicks on the “Add/Edit Teacher Profile” link provided on
the home page of the academic officer’s view.

2. The system displays the “Add/Edit Teacher Profile” page.

3. The Academic Officer selects the “Existing” radio button to modify a profile for already entered teacher
and enters the username of the teacher and presses the “Ok” button.

4. The system displays the “Modify Profile” page.

5. The system displays the “Modify Instructor’s Profile” page and shows the personal, contact, office,
qualification and university related information.

6. The Academic Officer make changes in the personal, contact, office, qualification and university related

Confidential XYZ, 2007 Page 57


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

information and presses the “Save” button.

7. The system updates the information of the teacher’s profile.

7.13.2.4 Alternative Flows

The Student closes this page.

The Student clicks on other links provided on this page.

7.13.2.5 Post-condition(s)

Changes are made in the existing profile of the teacher.

7.13.3 UC13-03: Remove Teacher Profile

7.13.3.1 Brief Description

The purpose of this use case is to delete the personal information of the teacher. This is initiated when the
information regarding the teacher needs to be deleted. The user from the academics office deletes the record of the
teacher and updates the system database.

7.13.3.2 Pre-condition(s)

1. User’s identity has been authenticated.

2. Academic Officer has logged on to the application.

3. Database is up and running.

4. Teacher name or ID in the system should be known.

7.13.3.3 Main Flow

1. The use case begins when the academic officer clicks on the “Add/Edit Teacher Profile” link provided on
the home page of the academic officer’s view.

2. The system displays the “Add/Modify Teacher Profile” page.

3. The Academic Officer selects the “Remove” radio button to delete a profile for already entered teacher.

4. The Academic Officer enters the teacher’s username whose profile needs to be deleted and presses the
“Ok” button.

5. The system displays a message that the profile has been deleted.

7.13.3.4 Alternative Flows

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.13.3.5 Post-condition(s)

The teacher profile is permanently deleted from the database.

Confidential XYZ, 2007 Page 58


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.13.4 UC13-04: View Teacher Profile

7.13.4.1 Brief Description

The purpose if this use case is to view the personal information related to a teacher/faculty member. This is initiated
by the teacher when personal, contact and academic information needs to be viewed.

7.13.4.2 Pre-condition(s)

1. User’s identity has been authenticated.

2. Teacher has logged on to the application.

3. Database is up and running.

7.13.4.3 Main Flow

1. The use case begins when the teacher clicks on the “Personal Information” link provided on the main page
of the teacher’s view.

2. The system displays the profile of the teacher.

7.13.4.4 Alternative Flows

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.13.4.5 Post-condition(s)

The teacher views his/her profile.

7.14 UC14: Manage Teacher Preferences


7.14.1 UC14-01: Add Preferred Courses

7.14.1.1 Brief Description

The purpose of this use case is to add preferred courses for a teacher. This is initiated when a teacher informs the
Academics Office of the courses she/he prefers to teach. This helps the Academics Office determine who should be
assigned to teach which course. The academics office user selects that teacher and adds the new courses to it.

7.14.1.2 Pre-condition(s)

1. User’s identity has been authenticated.

2. Academic Officer has logged on to the application.

3. Database is up and running.

4. Name of teacher and course title for the preferred course should be known.

7.14.1.3 Main Flow

1. The use case begins when the academic officer clicks on the “Manage Teacher Preferences” link provided
on the home page of the academic officer’s view.

Confidential XYZ, 2007 Page 59


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

2. The system displays the “Manage Teacher Preferences” page.

3. The Academic Officer selects the name of the instructor and the department from the drop down list.

4. The system displays the list of all the courses code, course title and the credit hours.

5. The Academic Officer checks the course(s) from the list that the teacher wants to teach and presses the
“Update Preferences” button.

6. The system saves the preferences of teacher.

7.14.1.4 Alternative Flows

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.14.1.5 Post-condition(s)

The course preferences are successfully added for the teacher.

7.14.2 UC14-02: Edit Preferred Courses

7.14.2.1 Brief Description

The purpose of this use case is to edit a preferred course(s) for a teacher. This is initiated when a teacher informs the
Academics Officer to modify a preferred course(s).

7.14.2.2 Pre-condition(s)

1. User’s identity has been authenticated.

2. Academic Officer has logged on to the application.

3. Database is up and running.

4. A preferred list of courses is added for the teacher.

7.14.2.3 Main Flow

1. The use case begins when the academic officer wants to delete the preferences of clicks on the “Manage
Teacher Preferences” link provided on the home page of the academic officer’s view.

2. The system displays the “Manage Teacher Preferences” page.

3. The Academic Officer selects the name of the instructor and the department.

4. The system displays the list of all the courses code, course title and the credit hours.

5. The Academic Officer check/uncheck the course(s) from the list of courses displayed and presses the
“Update Preferences” button.

6. The system updates the changes.

Confidential XYZ, 2007 Page 60


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.14.2.4 Alternative Flows

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.14.2.5 Post-condition(s)

The preferred course(s) list is modified for a teacher.

7.14.3 UC14-03: View Preferred Courses

7.14.3.1 Brief Description

The purpose of this use case is to view preferred courses for a teacher. This is initiated when the Academics Office
wants to view a list of the courses s/he would prefer to teach in the future. This helps the Academics Office
determine who should be assigned to teach which course. The user selects the teacher and gets a list of courses that
the teacher prefers. The teacher can also view these courses list.

7.14.3.2 Pre-condition(s)

1. User’s identity has been authenticated.

2. Academic Officer has logged on to the application.

3. Database is up and running.

4. The preferred courses are added in the system against each teacher.

7.14.3.3 Main Flow

1. The use case begins when the academic officer clicks on the “View Teacher Preferences” link provided on
the home page of the academic officer’s view.

2. The system displays the “View Teacher Preferences” page.

3. The Academic Officer selects the name of the instructor from the drop down list.

4. The system displays the list of preferred serial number, courses code, course title and the level of the
course.

7.14.3.4 Alternative Flows

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.14.3.5 Post-condition(s)

The academic Officer views the preferred courses for a teacher.

Confidential XYZ, 2007 Page 61


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.15 UC15: Report Management


7.15.1 UC15-01: View Declined Requests

7.15.1.1 Brief Description

The purpose of this use case is to view all list of all the students whose registration requests have been declined. The
academic officer initiates this use case when he wants to generate a report of all such students. The academic officer
selects the batch and a list of serial numbers, roll numbers, names, section, degree and registration status is
displayed.

7.15.1.2 Pre-condition(s)

1. User’s identity has been authenticated.

2. Academic Officer has logged on to the application.

3. Database is up and running.

7.15.1.3 Main Flow

1. The academic officer starts the use case by clicking on the “Declined Requests” link provided on the home
page of the academic officer’s view.

2. The system displays the “Declined Requests” page.

3. The Academic Officer selects a batch from the drop down menu.

4. The system displays the list of all the students whose registration request is declined along with their serial
number, roll number, name, section, degree and registration status.

7.15.1.4 Alternative Flows

The system displays a message when no declined requests are present.

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.15.1.5 Post-condition(s)

The Academic Officer has viewed the declined requests report.

7.15.2 UC15-02 View Course Seat Status

7.15.2.1 Brief Description

The purpose of this use case is to view the seat status of all courses offered in the current semester. The academic
officer initiates it when he wants to generate a report of the seat status of the courses in the current semester. A list
of serial number, roll number, course code, course title, section, maximum seats, number of registered students,
number of requested registrations and number of remaining seats is displayed.

7.15.2.2 Pre-condition(s)

1. User’s identity has been authenticated.

Confidential XYZ, 2007 Page 62


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

2. Academic Officer has logged on to the application.

3. Database is up and running.

7.15.2.3 Main Flow

1. The academic officer starts the use case by clicking on the “Course Seats Status” link provided on the home
page of the academic officer’s view.

2. The system displays the “Course Seats Status” page.

3. The system displays the list of all the courses offered in the new semester and their seats status. The detail
of the report includes the serial number, roll number, course code, course title, section, maximum seats,
number of registered students, number of requested registrations and number of remaining seats.

7.15.2.4 Alternative Flows

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.15.2.5 Post-condition(s)

The Academic Officer has viewed the course seat status report.

7.15.3 UC15-03 View Course Registered Student

7.15.3.1 Brief Description

The purpose of this use case is to view the list of students who have registered in an offered course. This is initiated
when the list of registered students for an offered course is desired. The user from the Academics Office selects the
appropriate course from the list of offered courses. The user selects to view the list of registered students for the
course. A list containing the names and other information about all the students who have registered for the course is
displayed to the user.

7.15.3.2 Pre-condition(s)

1. User’s identity has been authenticated.

2. Academic Officer has logged on to the application.

3. Database is up and running.

7.15.3.3 Main Flow

1. The academic officer starts the use case by clicking on the “Course Registration Status” link provided on
the home page of the academic officer’s view.

2. The system displays the “Course Registration Status” page.

3. The Academic Officer selects an offered course from the drop down menu.

4. The system displays the report containing the list of serial number, roll number and name of all the students
who have registered for the course along with the list of students who have requested this course.

Confidential XYZ, 2007 Page 63


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

7.15.3.4 Alternative Flows

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.15.3.5 Post-condition(s)

The Academic Officer has viewed the course registered student status report.

7.15.4 UC15-04 View Unregistered Students

7.15.4.1 Brief Description

The purpose of this use case is to view the list of all students who haven’t requested for registration in the current
semester. This is initiated when the list of unregistered students is desired. The user from the academic office selects
a batch and a list of serial number, roll number, name, section, degree and registration status is displayed.

7.15.4.2 Pre-condition(s)

1. User’s identity has been authenticated.

2. Academic Officer has logged on to the application.

3. Database is up and running.

7.15.4.3 Main Flow

1. The academic officer starts the use case by clicking on the “Unregistered Students” link provided on the
home page of the academic officer’s view.

2. The system displays the “Unregistered Current Students” page.

3. The Academic Officer selects a batch from the drop down menu.

4. The system displays the report containing the list of serial number, roll number, student name, section,
degree and registration status of unregistered students in the current semester.

7.15.4.4 Alternative Flows

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.15.4.5 Post-condition(s)

The Academic Officer has viewed the unregistered students report.

7.15.5 UC15-05 View Student Workload

7.15.5.1 Brief Description

The purpose of this use case is to view the list of students’ workload in a semester. This is initiated when a list of
workload of the registered students in the current semester is required. The academic officer selects a particular
semester and all the batches in that semester are displayed with a total of all the students registered in a particular

Confidential XYZ, 2007 Page 64


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

batch and their average courses and average credit hours.

7.15.5.2 Pre-condition(s)

1. User’s identity has been authenticated.

2. Academic Officer has logged on to the application.

3. Database is up and running.

7.15.5.3 Main Flow

1. The academic officer starts the use case by clicking on the “Student Workload” link provided on the home
page of the academic officer’s view.

2. The system displays the “Student Workload” page.

3. The Academic Officer selects the semester from the drop down menu.

4. The system displays the report containing all the batches in the selected semester with a total of all the
students registered in the batch and average courses and average credit hours.

7.15.5.4 Alternative Flows

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.15.5.5 Post-condition(s)

The Academic Officer has viewed the student workload report.

7.15.6 UC15-06 View Semester Registration Summary

7.15.6.1 Brief Description

The purpose of this use case is to view the registration summary of a particular semester. The academic officer
initiates the registration summary report. He selects the semester and the information displayed includes the batches
in the current semester, total number of male and female students in all the current degrees.

7.15.6.2 Pre-condition(s)

1. User’s identity has been authenticated.

2. Academic Officer has logged on to the application.

3. Database is up and running.

7.15.6.3 Main Flow

1. The academic officer starts the use case by clicking on the “Registration Summary” link provided on the
home page of the academic officer’s view.

2. The system displays the “Registration Summary” page.

Confidential XYZ, 2007 Page 65


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

3. The Academic Officer selects a semester from the drop down menu and presses the “Go” button.

4. The system displays the report containing all the batches in the selected semester, total number of male and
female students in BS (CS), BS (CE), BS (TE), BBA, MS (CS), MS (SPM), MS (Maths) MS (TE), MBA,
PhD (CS), PhD (Maths) and other degrees and their total.

7.15.6.4 Alternative Flows

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.15.6.5 Post-condition(s)
The Academic Officer has viewed the semester registration summary course seat status report.
7.15.7 UC15-07 View Batch Registration Summary

7.15.7.1 Brief Description

The purpose of this use case is to view the report of the registration summary of all the current batches. It is initiated
by the academic officer. The information displayed consists of all the current batches, number of students who
haven’t registered in a batch, number of students who have pending requests in a batch, number of students who
have declined requests in batch, number of students who have submit fee status in batch, number of students whose
requests have been completed in a batch and number of students whose registration has been disabled and their total.

7.15.7.2 Pre-condition(s)

1. User’s identity has been authenticated.

2. Academic Officer has logged on to the application.

3. Database is up and running.

7.15.7.3 Main Flow

1. The academic officer starts the use case by clicking on the “Registration Home” link provided on the home
page of the academic officer’s view.

2. The system displays the “Registration Home – Registration Summary” page.

3. The system displays the report containing all the current batches, number of students who haven’t
registered in a batch, number of students who have pending requests in a batch, number of students who
have declined requests in batch, number of students who have submit fee status in batch, number of
students whose requests have been completed in a batch and number of students whose registration has
been disabled and their total.

7.15.7.4 Alternative Flows

The Academic Officer closes this page.

The Academic Officer clicks on other links provided on this page.

7.15.7.5 Post-condition(s)

The Academic Officer has viewed the batch registration summary report.

Confidential XYZ, 2007 Page 66


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

8 Traceability Matrix
FR01: New Semester Creation
Req. Actor Functional Requirements UC# Non-Functional GUI #
No. Requirements
FR01-01 Academic The system shall enable the UC01-01 NFR01-01 GUI 1
Officer Academic Officer to create the NFR01-02
new semester in the beginning NFR01-03
of the academic calendar that NFR01-04
has three cycles each year - NFR02-02
Spring, Summer and Fall. The NFR02-03
new semester to start is NFR02-04
automatically selected by the
system. Any semester already
registered cannot be registered
again and won’t be visible in the
list of semesters available.
FR01-02 Academic The system shall remove all the UC01-01 NFR01-01 GUI 1
Officer previous pending registration NFR01-02
requests. This option is given to NFR01-03
the academic officer at the time NFR01-04
of new semester creation. If the NFR02-02
academic officer selects this NFR02-03
option then the pending NFR02-04
registration requests of the
previous semesters is removed.
FR01-03 Academic The system shall allow the UC01-01 NFR01-01 GUI 1
Officer Academic Officer to set the NFR01-02
status of all the currently NFR01-03
registered students to NFR01-04
‘Allowed’. This will make the NFR02-02
registration permission available NFR02-03
to all the students. NFR02-04
FR01-04 Academic The system shall enable the UC01-01 NFR01-01 GUI 1
Officer Academic Officer to set the NFR01-02
status of all unregistered NFR01-03
students to ‘Disabled’. All the NFR01-04
students whose registration NFR02-02
status was previously set as NFR02-03
‘Disabled’ won’t be allowed to NFR02-04
register in the current semester.
FR01-05 Academic The system shall enable the UC01-01 NFR01-01 GUI 1
Officer Academic Officer to remove NFR01-02
grading/attendance details for NFR01-03
the offered courses completed NFR01-04
before the new semester. NFR02-02
NFR02-03
NFR02-04
FR01-06 Academic The system shall allow the UC01-01 NFR01-01 GUI 1
Officer academic officer to disable the NFR01-02
option of adding/editing of NFR01-03
lectures and evaluations for the NFR01-04

Confidential XYZ, 2007 Page 67


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

courses to be offered before the NFR02-02


new semester. NFR02-03
NFR02-04

FR02: New Semester Course Detail


Req. Actor Functional Requirements UC# Non-Functional GUI #
No. Requirements
FR02-01 Academic The system shall enable the UC02-01 NFR01-01 GUI 2
Officer Academic Officer to add course NFR01-02
for a new semester from the NFR01-03
existing list of courses. The NFR01-04
academic officer selects the NFR02-02
semester, department, course NFR02-03
name and enters section, NFR02-04
maximum seats and course
outline for this course.
FR02-02 Academic The system shall enable an UC02-02 NFR01-01 GUI 3
Officer academic officer to edit the NFR01-02
course(s). The academic officer NFR01-03
enters the details for the offered NFR01-04
course which includes quizzes, NFR02-02
assignments, projects, monthly, NFR02-03
final weights, scaling factor and NFR02-04
the grading scheme. The
academic officer assigns a
teacher to a course by selecting
the name of teacher, role and
control. The academic officer
also selects the batches who can
view the course while
registering online.
FR02-03 Academic The system shall allow the UC02-03 NFR01-01 GUI 30
Officer academic officer to remove the NFR01-02
course(s) from the offered list of NFR01-03
courses for the new semester. NFR01-04
NFR02-02
NFR02-03
NFR02-04
FR02-04 Academic The system shall allow the UC02-04 NFR01-01 GUI 29
Officer academic officer to view the NFR01-02
course list. NFR01-03
NFR01-04
NFR02-02
NFR02-03
NFR02-04

Confidential XYZ, 2007 Page 68


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

FR03: Set Registration Permissions


Req. No. Actor Functional Requirements UC# Non-Functional GUI #
Requirements
FR03-01 Academic The system shall allow the UC01-03 NFR01-01 GUI 4
Officer academic officer to set NFR01-02
registration permissions for the NFR01-03
students to view online NFR01-04
registration. The academic NFR02-02
officer selects the batch and list NFR02-03
of Serial No., Roll. No., Name, NFR02-04
Section, Degree, Registration
Status and Allow Registration
are displayed. The academic
officer can check the allow
registration option for students
who can view online
registration.
FR03-02 Academic The system shall enable the UC01-03 NFR01-01 GUI 4
Officer academic officer to select the NFR01-02
students who cannot view NFR01-03
online registration by selecting NFR01-04
the allow registration option as NFR02-02
uncheck. NFR02-03
NFR02-04

FR04: Make Registration Settings


Req. No. Actor Functional Requirements UC# Non-Functional GUI #
Requirements
FR04-01 Academic The system shall enable the UC01-02 NFR01-01 GUI 5
Officer Academic Officer to select the NFR01-02
‘Enable Online Registration’ NFR01-03
option. This enables the students NFR01-04
to view online registration. NFR02-02
NFR02-03
NFR02-04
FR04-02 Academic The system shall allow the UC01-02 NFR01-01 GUI 5
Officer academic officer to select NFR01-02
‘Disable Online Registration’ NFR01-03
after the registration deadline. NFR01-04
NFR02-02
NFR02-03
NFR02-04

Confidential XYZ, 2007 Page 69


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

FR05: Manage Teacher profile


Req. Actor Functional Requirements UC# Non-Functional GUI #
No. Requirements
FR05-01 Academic The system shall facilitate the UC11-01 NFR01-01 GUI 18,
Officer academic officer to add a NFR01-02 GUI 19
teacher’s profile containing the NFR01-03
personal, contact, office, NFR01-04
qualification and university NFR01-05
related details NFR02-01
NFR02-02
NFR02-03
NFR02-04
FR05-02 Academic The system shall allow the UC11-02 NFR01-01 GUI 19
Officer academic officer to edit (modify) NFR01-02
the teacher’s profile. NFR01-03
NFR01-04
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04
FR05-03 Academic The system shall allow the UC11-03 NFR01-01 GUI 18
Officer academic officer to remove the NFR01-02
teacher’s profile NFR01-03
NFR01-04
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04
FR05-04 Academic The system shall allow the UC11-04 NFR01-01 GUI 20
Officer teacher to view his/her profile. NFR01-02
Every teacher has a separate NFR01-03
login name and password to NFR01-04
enter the system. NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04

FR06: Manage Teacher Preferences


Actor UC# Non-Functional GUI #
Req. No. Functional Requirements
Requirements
Academic UC12- NFR01-01 GUI 21
FR06-01 The system shall facilitate the
Officer 01 NFR01-02
academic officer to add the
NFR01-03
preferences of the teacher in a
NFR01-04
particular department for a
NFR01-05
particular course he/she wants to
NFR02-01
teach. The academic officer
NFR02-02

Confidential XYZ, 2007 Page 70


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR02-03
selects the name of the teacher
NFR02-04
and the department and a list of
all the courses offered in the
particular department are
displayed. The course code, title
and credits information is
displayed in the list. The
academic Officer selects the
course (s) form the list that the
teacher wants to teach.
Academic UC12- NFR01-01 GUI 21
FR06-02 The system shall allow the
Officer 02 NFR01-02
academic officer to edit
preferred courses for a teacher. NFR01-03
NFR01-04
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04
Academic UC12- NFR01-01 GUI 31
FR06-03 The system shall enable the
Officer 03 NFR01-02
academic officer and the teacher
to view the preferred courses for NFR01-03
a teacher. NFR01-04
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04

FR07: Request Student Course Registration


Non-Functional GUI #
Req. No. Actor Functional Requirements UC#
Requirements
NFR01-01
FR07-01 The system shall provide an
NFR01-02
interface to the students where
NFR01-03
they can place online registration
NFR01-04
requests.
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR07-02 The system shall display a list of
NFR01-02
courses from which the student
NFR01-03
can perform registration.
NFR01-04
NFR01-05

Confidential XYZ, 2007 Page 71


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR07-02-01 The system shall display list of
NFR01-02
all the courses offered to that
NFR01-03
batch and department.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR07-02-02 The system shall display list of
NFR01-02
all courses that the student has
NFR01-03
withdrawn and are being offered
NFR01-04
in the current semester.
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR07-02-03 The system shall display list of
NFR01-02
all courses that the student can
NFR01-03
repeat and are being offered in
NFR01-04
the current semester.
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR07-02-04 The system shall not display any
NFR01-02
course to the student whose pre-
NFR01-03
requisite has not been studied by
NFR01-04
the student.
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03

Confidential XYZ, 2007 Page 72


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR02-04
NFR01-01
FR07-03 The system shall allow a student
NFR01-02
to select courses from the list
NFR01-03
displayed.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR07-04 The system shall not allow a BS
NFR01-02
student to register less than three
NFR01-03
courses.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR07-05 The system shall not allow a BS
NFR01-02
student to register more than five
NFR01-03
courses.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR07-06 The system shall not allow an
NFR01-02
MS student to register less than
NFR01-03
two courses.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR07-07 The system shall not allow an
NFR01-02
MS student to register more than
NFR01-03

Confidential XYZ, 2007 Page 73


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR01-04
three courses.
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR07-08 The system shall allow an MS
NFR01-02
student to register for his
NFR01-03
thesis/survey.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR07-08-01 The system shall display a
NFR01-02
thesis/survey form to an MS
NFR01-03
student.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR07-08-02 The system shall display on the
NFR01-02
form student’s semester,
NFR01-03
program, roll number, name,
NFR01-04
date and year on the student
NFR01-05
view.
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR07-08-03 The system shall enable the
NFR01-02
student to add his topic name,
NFR01-03
the advisor name, area of
NFR01-04
specialization and select thesis
NFR01-05
or non-thesis option on the form.
NFR01-06
NFR02-01

Confidential XYZ, 2007 Page 74


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR07-09 The system shall not allow the
NFR01-02
student to register the
NFR01-03
survey/thesis as a fourth course.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR07-10 The system shall allow the
NFR01-02
student to submit his registration
NFR01-03
request to the academic officer.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR07-11 The system shall not allow the
NFR01-02
student to perform online
NFR01-03
registration once the request is
NFR01-04
submitted. The registration then
NFR01-05
becomes disabled on the student
view. NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR07-12 The system shall display a
NFR01-02
message to the student once his
NFR01-03
registration request has been
NFR01-04
submitted.
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04

Confidential XYZ, 2007 Page 75


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR01-01
FR07-13 The system shall allow the
NFR01-02
student to view his registration
NFR01-03
status. It is “Pending” after the
NFR01-04
approval from the academic
NFR01-05
officer and then “Submit Fee”
after the submission of dues. NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04

FR08: Request Student Add/Drop


Non-Functional GUI #
Req. No. Actor Functional Requirements UC#
Requirements
NFR01-01
FR08-01 The system shall allow the
NFR01-02
students to make add/drop
NFR01-03
course requests.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR08-02 The system shall display list of
NFR01-02
courses that the student can add.
NFR01-03
(This will be the same list as the
NFR01-04
registration process list plus all
NFR01-05
the courses that the student has
dropped will not be visible.) NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR08-03 The system shall allow the
NFR01-02
student to select courses he
NFR01-03
wants to add.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04

Confidential XYZ, 2007 Page 76


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR01-01
FR08-04 The system shall not allow the
NFR01-02
student to add more courses than
NFR01-03
his registration limits.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR08-05 The system shall enable the
NFR01-02
student to view his registered
NFR01-03
courses in the current semester.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR08-06 The system shall allow the
NFR01-02
student to drop course(s) from
NFR01-03
the registered course(s) list of
NFR01-04
the current semester.
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR08-07 The system shall allow the
NFR01-02
student to submit his add/drop
NFR01-03
course requests to the academic
NFR01-04
officer.
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR08-08 The system shall display a
NFR01-02
message to the student once his
NFR01-03
add/drop request has been
NFR01-04
submitted.
NFR01-05

Confidential XYZ, 2007 Page 77


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR08-09 The system shall display all
NFR01-02
add/drop course request status as
NFR01-03
“Pending”.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR08-10 The system shall not allow a
NFR01-02
student to add a course once
NFR01-03
dropped, in the current semester.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR08-11 The system shall display to the
NFR01-02
student the number of seats
NFR01-03
remaining in a course.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04

FR09: Student Course Repeat


Non-Functional GUI #
Req. No. Actor Functional Requirements UC#
Requirements
NFR01-01
FR09-01 The system shall enable the
NFR01-02
student to view a list of courses
NFR01-03
from his previous semesters,
NFR01-04
which he can or should repeat. It
NFR01-05

Confidential XYZ, 2007 Page 78


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

includes all the courses with NFR01-06


grade F and GPA C- or less.
NFR02-01
NFR02-02
NFR02-03
NFR02-04

FR10: Authorize Student Registration Request (by AO)


Non-Functional GUI #
Req. No. Actor Functional Requirements UC#
Requirements
NFR01-01
FR10-01 The system shall enable the
NFR01-02
academic officer to view all the
NFR01-03
registration requests send to him
NFR01-04
by the student. The request
NFR01-05
should display the student’s
NFR02-01
semester, program, roll number,
NFR02-02
name, date, year and courses
NFR02-03
they requested for.
NFR02-04
NFR01-01
FR10-02 The system shall enable the
NFR01-02
academic officer to view all the
NFR01-03
thesis/survey requests send to
NFR01-04
him by the student. The request
NFR01-05
should display the student’s
NFR02-01
semester, program, roll number,
NFR02-02
name, date, year, topic name, the
NFR02-03
advisor name, area of
specialization and thesis or non- NFR02-04
thesis option.
NFR01-01
FR10-03 The system shall allow the
NFR01-02
academic officer to forward MS
NFR01-03
students course registration
NFR01-04
request to the current available
NFR01-05
advisor.
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR10-04 The system shall allow the
NFR01-02
academic officer to forward MS
NFR01-03
students survey/thesis request to
NFR01-04
the advisor requested.
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04

Confidential XYZ, 2007 Page 79


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR01-01
FR10-05 The system shall enable the
NFR01-02
academic officer to change the
NFR01-03
course registration status to
NFR01-04
“Pending”.
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR10-06 The system shall enable the
NFR01-02
academic officer to change the
NFR01-03
course registration status to
NFR01-04
“Submit fee”.
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR10-07 The system shall allow the
NFR01-02
academic officer to change the
NFR01-03
survey/thesis status to “Meeting
NFR01-04
Required”.
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02
NFR01-01
FR10-08 The system shall allow the
NFR01-02
academic officer to change the
NFR01-03
survey/thesis status to
NFR01-04
“Approved”.
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02
NFR01-01
FR10-09 The system shall enable the
NFR01-02
academic officer to select the
NFR01-03
‘Enable Online Course(s)
NFR01-04
Add/Drop’ option. This enables
NFR01-05
the students to view online
NFR02-01
course add/drop option.
NFR02-02

Confidential XYZ, 2007 Page 80


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR02-03
NFR02-04
NFR04-01
NFR04-02
NFR01-01
FR10-10 The system shall enable the
NFR01-02
academic officer to select the
NFR01-03
‘Disable Online Course(s)
NFR01-04
add/drop’ option. This disables
NFR01-05
the students’ view of online
NFR02-01
course add/drop option.
NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02
NFR01-01
FR10-11 The system shall enable the
NFR01-02
academic officer to view all the
NFR01-03
add/drop requests send to him by
NFR01-04
the student. The request should
NFR01-05
display the student’s semester,
NFR02-01
program, roll number, name,
NFR02-02
date, year and courses they
NFR02-03
added and dropped.
NFR02-04
NFR01-01
FR10-12 The system shall allow the
NFR01-02
academic officer to forward MS
NFR01-03
students add/drop course request
NFR01-04
to the current available advisor.
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR10-13 The system shall maintain the
NFR01-02
seat status of all courses.
NFR01-03
NFR01-04
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR10-14 The system shall maintain a list
NFR01-02
of names of all students who
NFR01-03
added the course when there
NFR01-04

Confidential XYZ, 2007 Page 81


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR01-05
were seats available.
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR10-15 The system shall maintain a list
NFR01-02
of names of all students who
NFR01-03
added the course when there
NFR01-04
were no seats available.
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR10-16 The system shall maintain a list
NFR01-02
of names of all students who
NFR01-03
dropped a course.
NFR01-04
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR10-17 The system shall reduce the
NFR01-02
number of seats available in a
NFR01-03
course dynamically as the
NFR01-04
students’ request to add that
NFR01-05
course.
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR10-18 The system shall increase the
NFR01-02
number of seats available in a
NFR01-03
course dynamically as the
NFR01-04
students’ request to drop that
NFR01-05
course.
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR10-19 The system shall allow the
NFR01-02
academic officer to add the
NFR01-03
course requested by the students
NFR01-04
in their current course lists.
NFR01-05
NFR02-01
NFR02-02

Confidential XYZ, 2007 Page 82


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR02-03
NFR02-04
NFR01-01
FR10-20 The system shall allow the
NFR01-02
academic officer to drop the
NFR01-03
course requested by the students
NFR01-04
from their current course lists.
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04

FR11: Authorize Student Registration Request (by Advisor)


Non-Functional GUI #
Req. No. Actor Functional Requirements UC#
Requirements
NFR01-01
FR11-01 The system shall enable the
NFR01-02
advisor to view the students’
NFR01-03
registration requests sent to him
NFR01-04
by the academic officer. The
NFR01-05
request should display the
NFR02-01
student’s semester, program, roll
NFR02-02
number, name, date, year and
NFR02-03
courses they requested for.
NFR02-04

NFR01-01
FR11-02 The system shall enable the
NFR01-02
advisor to view the students’
NFR01-03
add/drop requests sent to him by
NFR01-04
the academic officer. The
NFR01-05
request should display the
NFR02-01
student’s semester, program, roll
NFR02-02
number, name, date, year and
NFR02-03
courses they added and dropped.
NFR02-04
NFR01-01
FR11-03 The system shall enable the
NFR01-02
advisor to view the students’
NFR01-03
survey/thesis requests sent to
NFR01-04
him by the academic officer. The
NFR01-05
request should display the
NFR02-01
student’s semester, program, roll
NFR02-02
number, name, date, year, topic
NFR02-03
name, the advisor name, area of
specialization and thesis or non- NFR02-04
thesis option.
NFR01-01
FR11-04 The system shall enable the
NFR01-02

Confidential XYZ, 2007 Page 83


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR01-03
advisor to mark the registration
NFR01-04
requests as “Approved”.
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02
NFR01-01
FR11-05 The system shall enable the
NFR01-02
advisor to mark the registration
NFR01-03
requests as “Disapproved”.
NFR01-04
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02
NFR01-01
FR11-06 The system shall enable the
NFR01-02
advisor to mark the add/drop
NFR01-03
requests as “Approved”.
NFR01-04
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02
NFR01-01
FR11-07 The system shall enable the
NFR01-02
advisor to mark the add/drop
NFR01-03
requests as “Disapproved”.
NFR01-04
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02
NFR01-01
FR11-08 The system shall enable the
NFR01-02
advisor to mark the thesis/survey
NFR01-03

Confidential XYZ, 2007 Page 84


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR01-04
requests as “Approved”.
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02
NFR01-01
FR11-09 The system shall enable the
NFR01-02
advisor to mark the thesis/survey
NFR01-03
requests as “Disapproved”.
NFR01-04
NFR01-05
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02

FR12: Withdraw Course


Non-Functional GUI #
Req. No. Actor Functional Requirements UC#
Requirements
NFR01-01
FR12-01 The system shall enable the
NFR01-02
student to make withdraw course
NFR01-03
requests.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR12-02 The system shall enable the
NFR01-02
student to select from registered
NFR01-03
course(s) to withdraw it.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04

Confidential XYZ, 2007 Page 85


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR01-01
FR12-03 The system shall allow the
NFR01-02
student to submit his withdraw
NFR01-03
course requests to the academic
NFR01-04
officer.
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR12-04 The system shall display a
NFR01-02
message to the student once his
NFR01-03
withdraw request has been
NFR01-04
submitted.
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR12-05 The system shall enable the
NFR01-02
academic officer to select the
NFR01-03
‘Enable Online Course(s)
NFR01-04
withdrawal’ option. This enables
NFR01-05
the students to view online
course withdraw option.
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR12-06 The system shall enable the
NFR01-02
academic officer to select the
NFR01-03
‘Disable Online Course(s)
NFR01-04
withdrawal’ option. This
NFR01-05
disables the students’ view of
online course withdraw option.
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR12-07 The system shall enable the
NFR01-02
academic officer to view all the
NFR01-03
course withdraw requests send to
NFR01-04
him by the students. The request
NFR01-05

Confidential XYZ, 2007 Page 86


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

should display the student’s


semester, program, roll number,
NFR02-01
name, date, year and the
NFR02-02
course(s) requested to withdraw.
NFR02-03
NFR02-04
NFR01-01
FR12-08 The system shall enable the
NFR01-02
academic officer to forward the
NFR01-03
course withdraw requests to the
NFR01-04
faculty member teaching that
NFR01-05
course.

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR12-09 The system shall enable the
NFR01-02
academic officer to mark the
NFR01-03
students grade as “W”.
NFR01-04
NFR01-05

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR12-10 The system shall facilitate the
NFR01-02
faculty member to view the
NFR01-03
course withdraw requests
NFR01-04
forwarded to him. The request
NFR01-05
should display the student’s
semester, program, roll number,
name, date, year and the
NFR02-01
course(s) requested to withdraw.
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR12-11 The system shall allow the
NFR01-02
faculty member to mark the
NFR01-03
course withdraw requests as
NFR01-04
“Approved”.
NFR01-05

NFR02-01
NFR02-02
NFR02-03

Confidential XYZ, 2007 Page 87


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR02-04
NFR01-01
FR12-12 The system shall allow the
NFR01-02
faculty member to mark the
NFR01-03
course withdraw requests as
NFR01-04
“Disapproved”.
NFR01-05

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR12-13 The system shall enable the
NFR01-02
faculty member to send his
NFR01-03
decision on the requests back to
NFR01-04
the academic officer.
NFR01-05

NFR02-01
NFR02-02
NFR02-03
NFR02-04

FR13: Freeze Semester


Non-Functional GUI #
Req. No. Actor Functional Requirements UC#
Requirements
NFR01-01
FR13-01 The system shall enable the
NFR01-02
student to make semester freeze
NFR01-03
requests.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR13-01-01 The system shall enable the
NFR01-02
student to view the semester
NFR01-03
freeze form.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03

Confidential XYZ, 2007 Page 88


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR02-04
NFR01-01
FR13-01-02 The system shall display on the
NFR01-02
form student’s semester,
NFR01-03
program, roll number, name,
NFR01-04
date and year.
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR13-01-03 The system shall enable the
NFR01-02
student to enter his reason in the
NFR01-03
form for freezing the semester.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR13-02 The system shall allow the
NFR01-02
student to submit his semester
NFR01-03
freeze requests to the academic
NFR01-04
officer.
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR13-03 The system shall not allow the
NFR01-02
student to view the semester
NFR01-03
freeze option once he has
NFR01-04
submitted the freeze request.
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR13-04 The system shall display a
NFR01-02
message to the student once his
NFR01-03

Confidential XYZ, 2007 Page 89


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR01-04
semester freeze request has been
NFR01-05
submitted.
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR13-05 The system shall not allow the
NFR01-02
student to make any registration
NFR01-03
or withdraw course requests
NFR01-04
once the student has made a
NFR01-05
semester freeze request.
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR13-06 The system shall enable the
NFR01-02
semester freeze option on the
NFR01-03
student’s view when the
NFR01-04
academic officer enables the
NFR01-05
online registration option.

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR13-07 The system shall disable the
NFR01-02
semester freeze option on the
NFR01-03
student’s view when the
NFR01-04
academic officer disables the
NFR01-05
online registration option.

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR13-08 The system shall enable the
NFR01-02
academic officer to view all the
NFR01-03
semester freeze requests send to
NFR01-04
him by the student. The request
NFR01-05
should display the student’s
semester, program, roll number,
name, date, year and the reason
NFR02-01

Confidential XYZ, 2007 Page 90


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR02-02
to freeze the semester.
NFR02-03
NFR02-04
NFR01-01
FR13-09 The system shall enable the
NFR01-02
academic officer to block the
NFR01-03
registration for all the student’s
NFR01-04
with semester freeze requests.
NFR01-05
Their status will be changed to
“Decline”.
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR13-10 The system shall enable the
NFR01-02
academic officer to generate a
NFR01-03
mail to all the student’s with
NFR01-04
semester freeze requests to
NFR01-05
submit their dues.

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR13-11 The system shall mark the
NFR01-02
semester freeze requests of
NFR01-03
students with warning in any of
NFR01-04
their previous semesters.
NFR01-05

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR13-12 The system shall allow the
NFR01-02
academic officer to send the
NFR01-03
marked semester freeze requests
NFR01-04
of the students to the advisor for
NFR01-05
approval.

NFR02-01
NFR02-02
NFR02-03
NFR02-04

Confidential XYZ, 2007 Page 91


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR01-01
FR13-13 The system shall enable the
NFR01-02
advisor to view the students’
NFR01-03
semester freeze requests sent to
NFR01-04
him by the academic officer. The
NFR01-05
request should display the
student’s semester, program, roll
number, name, date, year and the
NFR02-01
reason to freeze the semester
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR13-14 The system shall enable the
NFR01-02
advisor to mark the semester
NFR01-03
freeze requests as “Approved”.
NFR01-04
NFR01-05

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02
NFR01-01
FR13-15 The system shall enable the
NFR01-02
advisor to mark the semester
NFR01-03
freeze requests as
NFR01-04
“Disapproved”.
NFR01-05

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02
NFR01-01
FR13-16 The system shall enable the
NFR01-02
advisor to send his decision on
NFR01-03
all type of requests back to the
NFR01-04
academic officer.
NFR01-05

NFR02-01
NFR02-02
NFR02-03

Confidential XYZ, 2007 Page 92


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR02-04
NFR04-01
NFR04-02

FR14: Replace Course


Non-Functional GUI #
Req. No. Actor Functional Requirements UC#
Requirements
NFR01-01
FR14-01 The system shall enable the
NFR01-02
student to make course
NFR01-03
replacement requests.
NFR01-04
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04

NFR01-01
FR14-02 The system shall enable the
NFR01-02
student to view the course(s) he
NFR01-03
has failed in the previous
NFR01-04
semesters.
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR14-03 The system shall enable the
NFR01-02
student to view all the courses he
NFR01-03
cleared atleast one semester after
NFR01-04
the failed course(s).
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR14-04 The system shall enable the
NFR01-02
student to select from the failed
NFR01-03
course(s) he wants to replace.
NFR01-04
NFR01-05

Confidential XYZ, 2007 Page 93


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR14-05 The system shall enable the
NFR01-02
student to select from the cleared
NFR01-03
courses he wants to replace the
NFR01-04
failed one with.
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR14-06 The system shall allow the
NFR01-02
student to submit his course
NFR01-03
replacement requests to the
NFR01-04
academic officer.
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR14-07 The system shall display a
NFR01-02
message to the student once his
NFR01-03
course replacement request has
NFR01-04
been submitted.
NFR01-05
NFR01-06
NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR14-08 The system shall enable the
NFR01-02
course replacement option on the
NFR01-03
student’s view when the
NFR01-04
academic officer enables the
NFR01-05
online registration option.

NFR02-01
NFR02-02
NFR02-03

Confidential XYZ, 2007 Page 94


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR02-04
NFR01-01
FR14-09 The system shall disable the
NFR01-02
course replacement option on the
NFR01-03
student’s view when the
NFR01-04
academic officer disables the
NFR01-05
online registration option.

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR14-10 The system shall enable the
NFR01-02
academic officer to view all the
NFR01-03
course replacement requests
NFR01-04
send to him by the student. The
NFR01-05
request should display the
student’s semester, program, roll
number, name, date, year, the
NFR02-01
course to replace and the course
NFR02-02
to replace by.
NFR02-03
NFR02-04
NFR01-01
FR14-11 The system shall enable the
NFR01-02
academic officer to forward the
NFR01-03
requests to head of the
NFR01-04
department.
NFR01-05

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR14-12 The system shall enable the
NFR01-02
academic officer to forward the
NFR01-03
requests to the director.
NFR01-04
NFR01-05

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR14-13 The system shall enable the
NFR01-02
academic officer to forward the
NFR01-03

Confidential XYZ, 2007 Page 95


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR01-04
requests to the dean.
NFR01-05

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR14-14 The system shall enable the
NFR01-02
academic officer to replace a
NFR01-03
student’s course with another
NFR01-04
course he has studied.
NFR01-05

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR01-01
FR14-15 The system shall facilitate the
NFR01-02
head of the department to view
NFR01-03
the course replacement requests
NFR01-04
forwarded to him. The request
NFR01-05
should display the student’s
semester, program, roll number,
name, date, year, the course to
NFR02-01
replace and the course to replace
NFR02-02
by.
NFR02-03
NFR02-04
NFR01-01
FR14-16 The system shall allow the head
NFR01-02
of the department to mark the
NFR01-03
course replacement requests as
NFR01-04
“Approved”.
NFR01-05

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02
NFR01-01
FR14-17 The system shall allow the head
NFR01-02
of the department to mark the
NFR01-03
course replacement requests as
NFR01-04
“Disapproved”.
NFR01-05

Confidential XYZ, 2007 Page 96


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02
NFR01-01
FR14-18 The system shall enable the head
NFR01-02
of the department to send his
NFR01-03
decision on the requests back to
NFR01-04
the academic officer.
NFR01-05

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02
NFR01-01
FR14-19 The system shall facilitate the
NFR01-02
director to view the course
NFR01-03
replacement requests forwarded
NFR01-04
to him. The request should
NFR01-05
display the student’s semester,
program, roll number, name,
date, year, the course to replace
NFR02-01
and the course to replace by.
NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02
NFR01-01
FR14-20 The system shall allow the
NFR01-02
director to mark the course
NFR01-03
replacement requests as
NFR01-04
“Approved”.
NFR01-05

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR04-01

Confidential XYZ, 2007 Page 97


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR04-02
NFR01-01
FR14-21 The system shall allow the
NFR01-02
director to mark the course
NFR01-03
replacement requests as
NFR01-04
“Disapproved”.
NFR01-05

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02
NFR01-01
FR14-22 The system shall enable the
NFR01-02
director to send his decision on
NFR01-03
the requests back to the
NFR01-04
academic officer.
NFR01-05

NFR02-01
NFR02-02
NFR02-03
NFR02-04

NFR01-01
FR14-23 The system shall facilitate the
NFR01-02
dean to view the course
NFR01-03
replacement requests forwarded
NFR01-04
to him. The request should
NFR01-05
display the student’s semester,
program, roll number, name,
date, year, the course to replace
NFR02-01
and the course to replace by.
NFR02-02
NFR02-03
NFR02-04

NFR01-01
FR14-24 The system shall allow the dean
NFR01-02
to mark the course replacement
NFR01-03
requests as “Approved”.
NFR01-04
NFR01-05

NFR02-01

Confidential XYZ, 2007 Page 98


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02
NFR01-01
FR14-25 The system shall allow the dean
NFR01-02
to mark the course replacement
NFR01-03
requests as “Disapproved”.
NFR01-04
NFR01-05

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02
NFR01-01
FR14-26 The system shall enable the dean
NFR01-02
to send his decision on the
NFR01-03
requests back to the academic
NFR01-04
officer.
NFR01-05

NFR02-01
NFR02-02
NFR02-03
NFR02-04
NFR04-01
NFR04-02

FR15: Manage Student Profile


Req. No. Actor Functional Requirements UC# Non-Functional GUI #
Requirements
FR15-01 Academic The system shall facilitate UC10-01 NFR01-01 GUI 15, GUI
Officer the academic officer to add NFR01-02 16
a student profile containing NFR01-03
the personal information, NFR01-04
student contact, parent NFR02-02
contact, correspondence NFR02-03
contact, university related NFR02-04
information, family
information and previous
academic record.

Confidential XYZ, 2007 Page 99


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

FR15-02 Academic The system shall allow the UC10-02 NFR01-01 GUI 15, GUI
Officer academic officer to edit NFR01-02 16
(modify) the student profile. NFR01-03
NFR01-04
NFR02-02
NFR02-03
NFR02-04
FR15-03 Academic The system shall allow the UC10-03 NFR01-01 GUI 15
Officer academic officer to remove NFR01-02
the student profile. NFR01-03
NFR01-04
NFR02-02
NFR02-03
NFR02-04
FR15-04 Student The system shall enable the UC10-04 NFR01-01 GUI 17
student to view his/her NFR01-02
academic profile. The NFR01-03
student can also view his NFR01-04
registration status and the NFR02-02
results of the previous NFR02-03
semesters. NFR02-04

FR16: New Batch Registration


Req. No. Actor Functional Requirements UC# Non-Functional GUI #
Requirements
FR16-01 Academic The system shall enable the UC03-01 NFR01-01 GUI 6
Officer Academic Officer to add new NFR01-02
batch to the university. The NFR01-03
system displays the option to add NFR01-04
a new name and starting NFR02-02
semester for the new batch. NFR02-03
NFR02-04
FR16-02 Academic The system shall allow the UC03-02 NFR01-01 GUI 7
Officer Academic Officer to add NFR01-02
sections of the new batch. Any NFR01-03
section added by mistake can NFR01-04
also be removed. This option can NFR02-02
be used to edit any existing NFR02-03
batch information too. The NFR02-04
academic officer has to enter the
name of the batch to edit and can
add and remove batch sections
FR16-03 Academic The system shall allow the UC03-03 NFR01-01
Officer Academic Officer to migrate NFR01-02
student profiles from NUTES to NFR01-03
ABC. NFR01-04
NFR02-02
NFR02-03
NFR02-04

Confidential XYZ, 2007 Page 100


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

FR16-04 Academic The system shall allow the UC03-03 NFR01-01 GUI 8, GUI
Officer academic officer to perform NFR01-02 9
registration of the new batch’s NFR01-03
students. The academic officer NFR01-04
enters the batch, section and NFR02-02
degree name and selects from NFR02-03
the list of courses which are to NFR02-04
be registered for all the students
of the first semester.

FR17: Late Student Registration


Req. No. Actor Functional Requirements UC# Non-Functional GUI #
Requirements
FR17-01 Academic The system shall facilitate the UC05-01 NFR01-01 GUI 10
Officer academic officer to enter the NFR01-02
registration information of the NFR01-03
students who have made late NFR01-04
registration requests. This option NFR02-02
helps the academic officer to NFR02-03
register the courses for a student NFR02-04
who has missed the registration
due to some reason.
FR17-02 Academic The system shall help the UC05-02 NFR01-01 GUI 10
Officer academic officer to verify that NFR01-02
the courses requested by the NFR01-03
student are available for that NFR01-04
student to register. For this NFR02-02
purpose the academic officer can NFR02-03
check the student’s transcript NFR02-04
through the system to review the
previous courses he has studied.
FR17-03 The system shall not allow the UC01-03 NFR01-01 GUI 4
late registration of the student NFR01-02
who does not have the NFR01-03
registration permissions. NFR01-04
NFR02-02
NFR02-03
NFR02-04

FR18: Migrated Student Registration


Req. No. Actor Functional Requirements UC# Non-Functional GUI #
Requirements
FR18-01 Academic Officer The system shall enable the UC10-01 NFR01-01 GUI 15,
academic officer to create a NFR01-02 GUI 16
new profile of the student NFR01-03
who has migrated from one NFR01-04
campus to other campus of NFR02-02

Confidential XYZ, 2007 Page 101


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

NU-FAST. (Reference NFR02-03


requirement number FR12- NFR02-04
01)
FR18-02 Academic Officer The system shall facilitate UC06-01 NFR01-01 GUI 11,
the academic officer to enter NFR01-02 GUI 12
the previous courses and NFR01-03
semester details of the NFR01-04
student who has migrated. NFR02-02
The system displays the list NFR02-03
of all the semesters not NFR02-04
registered for a particular
student. The academic
officer provides the roll
number of the student and
the system displays a list of
all the semesters not
registered for him.
FR18-03 Academic Officer The system shall enable a UC06-02 NFR01-01
migrated student to view his NFR01-02
previous semester’s NFR01-03
information. NFR01-04
NFR02-02
NFR02-03
NFR02-04

FR19: Report Management


Req. No. Actor Functional Requirements UC# Non-Functional GUI #
Requirements
FR19-01 Academic Officer The system shall enable the UC13-01 NFR01-01 GUI 22
academic officer to view the NFR01-02
report of all students whose NFR01-03
registration status is NFR01-04
declined. NFR01-05
The academic officer selects
the batch and a list of serial
numbers, roll numbers, NFR02-01
names, section, degree and NFR02-02
registration status is NFR02-03
displayed.
NFR02-04

FR19-02 Academic Officer The system shall enable the UC13-02 NFR01-01 GUI 23
academic officer to view the NFR01-02
report of the seat status of NFR01-03
the courses in the current NFR01-04
semester. NFR01-05
A list of the serial numbers,
roll numbers, course codes,
course titles, sections, NFR02-01

Confidential XYZ, 2007 Page 102


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

maximum seats, registered NFR02-02


students, requested NFR02-03
registration and remaining
NFR02-04
seats status is displayed.

FR19-03 Academic Officer The system shall enable the UC13-03 NFR01-01 GUI 24
academic officer to view the NFR01-02
report of all the students NFR01-03
who have been registered NFR01-04
and who have made a NFR01-05
request for registration in a
particular course.
The academic officer selects NFR02-01
a particular course and a list NFR02-02
of serial numbers, roll NFR02-03
numbers, names is displayed
NFR02-04
for all students who have
registered in that course and
for all students who have
made requests for that
course.
FR19-04 Academic Officer The system shall enable the UC13-04 NFR01-01 GUI 25
academic officer to view the NFR01-02
report of all the students NFR01-03
who haven’t registered in NFR01-04
the current semester. NFR01-05
The academic officer selects
a batch and a list of serial
numbers, roll numbers, NFR02-01
name, section, degree and NFR02-02
registration status is NFR02-03
displayed.
NFR02-04

FR19-05 Academic Officer The system shall enable the UC13-05 NFR01-01 GUI 26
academic officer to view the NFR01-02
report of the work load of NFR01-03
the students in the current NFR01-04
semester according to their NFR01-05
batches.
The academic officer selects
a particular semester and all NFR02-01
the batches in that semester NFR02-02
are displayed with a total of NFR02-03
all the students registered in
NFR02-04
a particular batch and their
average courses and average
credit hours.
FR19-06 Academic Officer The system shall enable the UC13-06 NFR01-01 GUI 27
academic officer to view the NFR01-02
report of the registration NFR01-03
summary of a particular NFR01-04
semester. NFR01-05

Confidential XYZ, 2007 Page 103


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

The academic officer can


select the semester and the
information displayed NFR02-01
includes the batches in the NFR02-02
current semester, total NFR02-03
number of male and female
NFR02-04
students in all the current
degrees.
FR19-07 Academic Officer The system shall enable the UC13-07 NFR01-01 GUI 28
academic officer to view the NFR01-02
report of the registration NFR01-03
summary of all the current NFR01-04
batches. NFR01-05
The information displayed
consists of all the current
batches, number of students NFR02-01
who haven’t registered in a NFR02-02
batch, number of students NFR02-03
who have pending requests
NFR02-04
in a batch, number of
students who have declined
requests in batch, number of
students who have submit
fee status in batch, number
of students whose requests
have been completed in a
batch and number of
students whose registration
has been disabled and their
total.

9 System Architecture Diagram

Confidential XYZ, 2007 Page 104


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

RADIX (Graphical
User Interfaces)
Views/ Reports
Requests

Local Area Network

Student
Student Academics Management
Registration
Registration Authorization Reporting
Verification

RADIX- Application Layer

Updates

NUTES Database

Notifications

Student Profile information


Academics
Registeration

10 Data Model

Data Flow Diagram of Student Registration System

Confidential XYZ, 2007 Page 105


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

Context Level:

Accounts
Confirmed/Rejected
Course registration request(s)
Student
Confirmed/Rejected
Request(s)
Academic
Officer

Fee receipts

Other request(s)

Course Registration Request(s) New Semester


Student Registration
Registration information
System
Accepted/Rejected survey/thesis requests Course replacement request

Student
Survey/Thesis profile
Teacher requests migration
Approved/Disapproved
course replacement HOD
request

NUTES

Confidential XYZ, 2007 Page 106


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

Course Withdraw option enabled


9.0
13.0 Withdraw
Course Add/drop course option enabled 10.0 HOD
Course(s)
Withdraw Add/Drop Course(s)
Settings 11.0 registration request
Create New Information
Add/Drop
Withdraw Approved/disapproved
Batch of first semester Add/drop course course replacement request
request
12.0 details Accepted/
details
Add/Drop Course Rejected
Settings Add/drop Accepted
Course Withdraw
Withdrawal
8.0
request request
Withdraw Course request Course
course New batch replacement Replacement
settings registration information details

Course details
Add/drop course
settings Course
replacement
6.0 request
Update Manage Student Accepted
Academic Officer Student
Registration
course
Update Teacher
Student Profile request(s)
information Replacement
information request
Online
New Semester Offered Offered Courses
Registration registration 2.0 Courses
5.0 enabled DB
Information Register courses information
Manage Teacher Accepted/Rejected
Profile Semester freeze
1.0
Student Registration request
Make Pre- Student Information request Semester
Teacher details
Registration details freeze
reports request
Settings
Request Student DB
Thesis/Survey
for
Teacher DB report(s)
requests Confirmed/Rejected
Accepted/rejected Registration request(s)
Thesis/survey
Registration 7.0
request Freeze
requests
details
Teacher details Freeze Semester
semester
Verification of course
details
registration requests 3.0
Verify Course
4.0 Registration
Generate Requests
Reports Course
Replacement
fee receipts Details

Teacher
Accounts

Student , course registration details

Confidential XYZ INSTITUTE, 2007 Page 107


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

Level 2 – Process 1.0 (Make Pre-Registration Settings)

Academic
Officer

New semester
registration information

1.1
adding courses in Create new semester
new semester Semester

1.3
Offered Courses Course 1.2
details Set Registration
DB Add Courses
Permissions

Registration permissions
made for
new semester

Offered courses information 1.4


Online registration
enabled
Make Registration
Settings
2.0
Register Courses

Confidential XYZ INSTITUTE, 2007 Page 108


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

Level 2 – Process 11.0 (Create New Batch)

Academic
Officer

New batch registration information

11.1
Add New
Batch

New batch creation

11.2 Student profile


Migrate Data NUTES
information

Data Migrated from


NUTES to RADIX

11.3
Registration information
Register Courses of first semester
Student DB
for new batch

Confidential XYZ INSTITUTE, 2007 Page 109


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

Entity Relationship Diagram

Student
RollNo: Number
DegreeEnrolled: String has Batch
Name: String BatchName: String
CGPA: Number P Transcript
BatchName: String (FK) RollNo: Number (FK)
have
Faculty Advisor: String
ProjectAdvisor: String SemesterName: String
CourseCount: Number P TotalCreditHours: Number
CourseName: String
CourseRegStatus: String

registered Degree
DegreeProgram: String
TotalCreditHours: Number
FeePerCourse: Number
Duration: Number has
Course
offered in
CourseCode: Number
CourseName: String
CreditHours: Number can view
CurrentInstructor: String
PreferredInstructors: Number
CourseGrade: String

P has

manages
Teacher
InstructorID: Number
BatchSection
offered in HOD: String
AcademicOfficer SectionName: String
InstructorName: String
EmployeeNo: Number BatchName: String (FK)
Department: String
WorkingHours: Number Age: Number StudentCount: Number

P
Semester
SemesterName: String
CourseCode: Number (FK)

Confidential XYZ INSTITUTE, 2007 Page 110


Modeling RE for ABC Version: 1.0
Software Requirements Specification Date: 9/May/2007

11 Class Diagram

Course
AcademicOfficer
CourseName : String
WorkingHours : Integer
Student CourseCode : Number prerequisites
EmployeeNo : Integer manages CreditHrs : Integer
DegreeEnrolled : String
CurrentInstructor : String
RollNo : Number prepareTranscript() *
PreferredInstructors : String 0..3
CGPA : Decimal performStdRegistration() 1 CourseGrade : String
BatchName : string maintainStdCourseRecord()
CourseName : String confirmRegistration alotRoomtoSection() n
1 changeCourseInstructor()
CourseCount : Int * makeRegSettings()
Section CourseRegStatus : String createStdProf() 1 1
Name : String createTeacherProf() givenFor
NoOfStudents : Integer requestCourseRegistration() updateStdProf() 1
enrollsIn
RoomNo : Integer * selectCourses() historyRecordedIn updateTeacherProf() * Semester
1 addCourse() authorizeStdRegRequest() *
1 CourseGrade SemesterName : String
addStuden() dropCourse() verifyStdRegRequest() CourseOffered
contains CourseCode : Number
deleteStudent() withdrawCourse() Grade : String DegreeName : String
* replaceCourse()
changeRoomNo() Transcript Semester : String
payFees() n *
* SemesterName : String 1 *
freezeSemester()
TotalCreditHrs : Integer
stdMigrationRequest()
Teacher 1 maintainsFinancialRecordOf getCourseGrade() 1
Name : String
ID : type = initval Degree
Department : String TotalCreditHrs : Integer
Age : Integer 1
DegreeProgram : String
HOD : boolean BatchSection feePerCourse : Integer
Batch
UnderGrad Graduate has SectionName : string Duration : Integer
BatchName : String
thesisReg Response() ProjectAdvisor : String FacultyAdvisor : String 1 StudentCount : Number
n
courseReplacement Response()
chooseProjectAdvisor() chooseThesisAdvisor()
surveythesis request()

Confidential XYZ INSTITUTE, 2007 Page 111


Modeling RE for XYZ INSTITUTE Version: 1.0
Software Requirements Specification Date: 9/May/2007

12 GUI

GUI -1

GUI-2

GUI-3

Confidential XYZ INSTITUTE, 2007 Page 112


Modeling RE for XYZ INSTITUTE Version: 1.0
Software Requirements Specification Date: 9/May/2007

GUI-4

GUI-5

GUI-6

GUI-7

Confidential XYZ INSTITUTE, 2007 Page 113


Modeling RE for XYZ INSTITUTE Version: 1.0
Software Requirements Specification Date: 9/May/2007

GUI-8

GUI-9

Confidential XYZ INSTITUTE, 2007 Page 114


Modeling RE for XYZ INSTITUTE Version: 1.0
Software Requirements Specification Date: 9/May/2007

GUI-10

GUI-11

GUI-12

GUI-13

GUI-14

GUI-15

Confidential XYZ INSTITUTE, 2007 Page 115


Modeling RE for XYZ INSTITUTE Version: 1.0
Software Requirements Specification Date: 9/May/2007

GUI-16

Confidential XYZ INSTITUTE, 2007 Page 116


Modeling RE for XYZ INSTITUTE Version: 1.0
Software Requirements Specification Date: 9/May/2007

GUI-17

GUI-18

GUI-19

Confidential XYZ INSTITUTE, 2007 Page 117


Modeling RE for XYZ INSTITUTE Version: 1.0
Software Requirements Specification Date: 9/May/2007

GUI-20

Confidential XYZ INSTITUTE, 2007 Page 118


Modeling RE for XYZ INSTITUTE Version: 1.0
Software Requirements Specification Date: 9/May/2007

GUI-21

Confidential XYZ INSTITUTE, 2007 Page 119


Modeling RE for XYZ INSTITUTE Version: 1.0
Software Requirements Specification Date: 9/May/2007

GUI-22

GUI-23

GUI-24

GUI-25

GUI-26

GUI-27

GUI-28

GUI-29

GUI-30

Confidential XYZ INSTITUTE, 2007 Page 120


Modeling RE for XYZ INSTITUTE Version: 1.0
Software Requirements Specification Date: 9/May/2007

GUI- 31

GUI -32

GUI- 33

Confidential XYZ INSTITUTE, 2007 Page 121


Modeling RE for XYZ INSTITUTE Version: 1.0
Software Requirements Specification Date: 9/May/2007

13 Assumptions

 The application can run only on windows environment.


 The Registration System can potentially have hundreds of users. It is unrealistic to provide training for
everyone. Therefore, the system should be designed for easy to use, providing help instructions, and
appropriate error messages for invalid user inputs.

Confidential XYZ INSTITUTE, 2007 Page 122


Modeling RE for XYZ INSTITUTE Version: 1.0
Software Requirements Specification Date: 9/May/2007

14 References

Confidential XYZ INSTITUTE, 2007 Page 123


Modeling RE for XYZ INSTITUTE Version: 1.0
Software Requirements Specification Date: 9/May/2007

15 Glossary

Actor A person playing a specific role, a software system or a hardware device that interacts with a system to
achieve a useful goal. Also called a user role.
Add/drop It is the facility provided to the students to change any course they have registered for. They can also add
a new course or drop any old one or perform both the operations by removing a course and adding another.
Advisor Any teacher or member of the faculty who is responsible for advising the students about the educational
matters.
Artifacts Any human made object that is a prototype or standard of measurement.
Batch Session of the students usually represented by the year e.g. 2001
Campus The campus is the area in which a college or university and surrounding buildings are situated.
CGPA Cumulative grade point average, it is a method now used for representing a students grade points. Calculated
at the end of each semester after the results. Specific grade points are assigned to the grades and CGPA is
calculated by adding those grade points and taking their average.
Customer A project stakeholder who requests, pays for, selects, specifies, uses or receives the output generated by a
product.
DC abbreviation used for disciplinary committee. Institutions usually have such committees to handle behaviors of
misconduct of the students and they are assigned punishments or penalties according to the committee’s rules.
Department A specialized division in large organization.
Domain analysis The process of analyzing related software systems in a domain to find their common and variable
parts.
XYZ INSTITUTE The educational institution whose registration system is being studied.
Functional requirements A statement of a piece of required functionality or a behavior that a system will exhibit
under specific conditions.
HOD Head of the department. He is the one who can make decisions and is responsible for handling issues related
to that department.
HR The human resource department that handles all the employees and keep their records.
Migrated student The student who has arrived from another campus of the same institution and from now onwards
will continue his studies in the campus he has migrated to.
Non-functional requirements A description of a property or characteristic that a software system must exhibit or a
constraint that it must respect, other than an observable system behavior.
NUTES admission test database of XYZ INSTITUTE from where student information is migrated to ABC.
Pre-registration settings Settings of the registration that are made before allowing the students to start registration.
Pre-requisite Includes those courses that the student must study before the current course. Such courses include
information that is required for a student to acquire before moving on to the next course.
Profile A description of the information of a person that may include his personal information his interests and
education.
ABC An online registration system used in XYZ INSTITUTE for student registration functionality.
Registration status After registration each student is assigned a registration status which shows whether his request
has been completed or rejected by the academics.
Registration system A system designed for performing the registration services which otherwise will be conducted

Confidential XYZ INSTITUTE, 2007 Page 124


Modeling RE for XYZ INSTITUTE Version: 1.0
Software Requirements Specification Date: 9/May/2007

manually.
Semester Includes division of the academic year, which is either fall or spring semester.
Semester freeze A student can request the academic department if he doesn’t wants to study for a semester. But for
that purpose he has to submit some fee and freezing a semester is allowed for only two consecutive semesters.
Student request form This is a general form available for the students if they have some educational issue, they can
fill this form and submit to the academic for their help and support.
Survey An option provided to the Masters student in FAST to take up instead of thesis for degree completion and
includes two additional courses than normal course limit. It is a literature review about a certain topic selected
by the student. Generally requires an advisor’s consultation for conducting it.
System operator A system operator is the person who runs a computer. In general, a sysop or system operator is
one who runs the day-to-day operation of a computer.
TA Teacher Assistant. He is selected by the teacher on his personal choice and is responsible for making
assignments, quizzes etc. depends on the level of responsibility teacher is willing to assign to his TA.
Thesis An option provided to the Masters student in FAST to take up for degree completion. This also requires an
advisor’s consultation to complete.
Transcript A copy of the official record of the students work.
User A customer who will interact with the system either directly or indirectly.
Withdrawal The student has the option to withdraw a course till 14 th week of his classes. But this is different from
add/drop as the fee submitted for the course is not returned and incase of withdraw the course is assigned the status
of incompletion i.e. “W”on the transcript.

Confidential XYZ INSTITUTE, 2007 Page 125


Modeling RE for XYZ INSTITUTE Version: 1.0
Software Requirements Specification Date: 9/May/2007

16 Appendix

Confidential XYZ INSTITUTE, 2007 Page 126

You might also like