Top Banner

of 126

FS ABC_ver2

Apr 09, 2018

Download

Documents

Faisal Sheikh
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
  • 8/8/2019 FS ABC_ver2

    1/126

    MODELINGREQUIREMENTS ENGINEERING FOR ABC

    (Suite for University Academics Operations)

    Software Requirements Specification

    Version 2.0

  • 8/8/2019 FS ABC_ver2

    2/126

    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

  • 8/8/2019 FS ABC_ver2

    3/126

    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 SEMESTERCREATION..............................................................................................................................9

    4.2 FR02: NEW SEMESTERCOURSE 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

    ..............................................................................................................................194.20 RC00 - RULESAND 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 ACADEMICOFFICER.................................................................................................................................................. 23

    6.2 STUDENT................................................................................................................................................................ 23

    6.3 ACCOUNTOFFICER...................................................................................................................................................236.4 TEACHER................................................................................................................................................................ 24

    6.5 ADVISOR................................................................................................................................................................ 24

    6.6 HEAD OFTHE DEPARTMENT.....................................................................................................................................24

    6.7 DIRECTOR............................................................................................................................................................... 24

    6.8 DEAN....................................................................................................................................................................24

    7 USE-CASES .............. .............. ............... .............. .............. .............. .............. ............... .............. .............. ............ ....25

    7.1 UC01: NEW SEMESTERCREATION............................................................................................................................ 25

    Confidential XYZ, 2007 Page 3

  • 8/8/2019 FS ABC_ver2

    4/126

    Modeling RE for ABC Version: 1.0

    Software Requirements Specification Date: 9/May/2007

    7.2 UC02: NEW SEMESTERCOURSE 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 SEMESTERFREEZE.......................................................................................................................... 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

    FR06: MANAGE TEACHER PREFERENCES .......................................................................................................................70

    FR07: REQUEST STUDENT COURSE REGISTRATION........................................................................................................... 71

    FR08: REQUEST

    STUDENT

    ADD

    /DROP

    ...........................................................................................................................76FR09: STUDENT COURSE REPEAT.................................................................................................................................. 78

    FR10: AUTHORIZE STUDENT REGISTRATION REQUEST (BY AO) ....................................................................................... .79

    FR11: AUTHORIZE STUDENT REGISTRATION REQUEST (BY ADVISOR) .................................................................................83

    FR12: WITHDRAW COURSE..........................................................................................................................................85

    FR13: FREEZE SEMESTER............................................................................................................................................. 88

    FR14: REPLACE COURSE.............................................................................................................................................. 93

    9 SYSTEM ARCHITECTURE DIAGRAM .............. ............... .............. .............. .............. .............. .............. ........104

    10 DATA MODEL .............. .............. .............. ............... .............. .............. .............. .............. ............... ..... ..... ...... ....105

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

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

    13 ASSUMPTIONS ............. ............... .............. .............. .............. .............. ............... .............. .............. ............ ...... ..122

    14 REFERENCES ............. .............. .............. ............... .............. .............. .............. .............. ............... .............. ...... ..123

    15 GLOSSARY ............... .............. .............. .............. .............. ............... .............. .............. .............. .............. ......... ...124

    16 APPENDIX ............. .............. .............. ............... .............. .............. .............. .............. .............. ............... ..... ...... ...126

    Confidential XYZ, 2007 Page 4

  • 8/8/2019 FS ABC_ver2

    5/126

    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 indeveloping 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

  • 8/8/2019 FS ABC_ver2

    6/126

    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

  • 8/8/2019 FS ABC_ver2

    7/126

    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 systems functionality.

    User Level of Computer

    Knowledge

    Level of Business

    Knowledge

    Frequency of use

    Academic

    Officer

    Good knowledge of

    window-based application

    Good understanding of the

    registration process

    Daily basis

    Teacher Good knowledge of

    window-based application

    Understanding of the

    registration process

    Depends on the teachers needs

    Student Good knowledge of the

    window-based application

    Have the capability of

    learning the system quickly

    They may or may not know

    the registration process very

    well.

    Can follow the instructions

    given by the academic

    institution

    Uses in the beginning of the semester,

    and often use during the semester

    Confidential XYZ, 2007 Page 7

  • 8/8/2019 FS ABC_ver2

    8/126

    Modeling RE for ABC Version: 1.0

    Software Requirements Specification Date: 9/May/2007

    3 Process Flow

    Student Course Registration

    Academics Authorization

    of Student Request

    Course Replacement

    Semester Freeze Request

    Withdraw Courses

    Add/Drop Courses

    Verify Student

    Registration

    Seek Approval from

    Teacher

    RADIX

    Update RADIX

    Pre Registration Settings

    (includes view

    permissions, etc.)

    Late Student

    Registration

    Migrated Student

    Registration

    Generating Student F ee

    List

    New Semester

    Creation (includes

    courselist c reation,etc.)

    New Batch Creation

    View Student

    profile

    Update Student/

    Teacher profiles

    Management Reporting

    Confidential XYZ, 2007 Page 8

  • 8/8/2019 FS ABC_ver2

    9/126

    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 wont 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 wont 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

  • 8/8/2019 FS ABC_ver2

    10/126

    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 cancheck 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 teachers profile containing the personal,

    contact, office, qualification and university related details.

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

    FR05-03 The system shall allow the academic officer to remove the teachers 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

  • 8/8/2019 FS ABC_ver2

    11/126

    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 students 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

  • 8/8/2019 FS ABC_ver2

    12/126

    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 students 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 students 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

    Confidential XYZ, 2007 Page 12

  • 8/8/2019 FS ABC_ver2

    13/126

    Modeling RE for ABC Version: 1.0

    Software Requirements Specification Date: 9/May/2007

    advisor requested.

    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 students 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 noseats 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.

    Confidential XYZ, 2007 Page 13

  • 8/8/2019 FS ABC_ver2

    14/126

    Modeling RE for ABC Version: 1.0

    Software Requirements Specification Date: 9/May/2007

    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 students semester, program, roll number, name,

    date, year and courses they requested for.

    FR11-02 The system shall enable the advisor to view the students add/drop requests sent to him by theacademic officer. The request should display the students 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 students 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 himby the students. The request should display the students 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.

    Confidential XYZ, 2007 Page 14

  • 8/8/2019 FS ABC_ver2

    15/126

    Modeling RE for ABC Version: 1.0

    Software Requirements Specification Date: 9/May/2007

    FR12-10 The system shall facilitate the faculty member to view the course withdraw requests forwarded to

    him. The request should display the students 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.

    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 students 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 students view when the academic officer

    enables the online registration option.

    FR13-07 The system shall disable the semester freeze option on the students 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 students 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 students 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 students with semester

    freeze requests to submit their dues.

    Confidential XYZ, 2007 Page 15

  • 8/8/2019 FS ABC_ver2

    16/126

    Modeling RE for ABC Version: 1.0

    Software Requirements Specification Date: 9/May/2007

    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

    the academic officer. The request should display the students 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 replacementrequests.

    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 students view when the academic

    officer enables the online registration option.

    FR14-09 The system shall disable the course replacement option on the students 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 students 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.

    Confidential XYZ, 2007 Page 16

  • 8/8/2019 FS ABC_ver2

    17/126

    Modeling RE for ABC Version: 1.0

    Software Requirements Specification Date: 9/May/2007

    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 students course with another course he

    has studied.

    FR14-15 The system shall facilitate the head of the department to view the course replacement requestsforwarded to him. The request should display the students 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 students 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 students semester, program, roll number, name, date, year, the course toreplace 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.

    Confidential XYZ, 2007 Page 17

  • 8/8/2019 FS ABC_ver2

    18/126

    Modeling RE for ABC Version: 1.0

    Software Requirements Specification Date: 9/May/2007

    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.

    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 batchs 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 students

    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.

    Confidential XYZ, 2007 Page 18

  • 8/8/2019 FS ABC_ver2

    19/126

    Modeling RE for ABC Version: 1.0

    Software Requirements Specification Date: 9/May/2007

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

    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 havent

    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 havent

    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

    Confidential XYZ, 2007 Page 19

  • 8/8/2019 FS ABC_ver2

    20/126

    Modeling RE for ABC Version: 1.0

    Software Requirements Specification Date: 9/May/2007

    registration has been disabled and their total.

    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 14th 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

  • 8/8/2019 FS ABC_ver2

    21/126

    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

  • 8/8/2019 FS ABC_ver2

    22/126

    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

  • 8/8/2019 FS ABC_ver2

    23/126

    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. Multiplepeople 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 AOs

    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 teachers profile and managing teachers preferences about the courses they can teach isalso done by the AO.

    He will also forward MS students 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 officers responsibilities in

    Confidential XYZ, 2007 Page 23

  • 8/8/2019 FS ABC_ver2

    24/126

    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 tofinalize 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 teachers 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 students 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

  • 8/8/2019 FS ABC_ver2

    25/126

    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 semesters 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 officers 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 students 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 havent 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 havent 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

  • 8/8/2019 FS ABC_ver2

    26/126

    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 officers 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 Changesbutton.

    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 andsimilarly 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

  • 8/8/2019 FS ABC_ver2

    27/126

    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 shouldnt 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 officers 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 shouldnt be allowed to access the registration system have been blocked by the academicofficer so that they cant 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

  • 8/8/2019 FS ABC_ver2

    28/126

    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 officers 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 inthe 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, gradingscheme 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 officers 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

  • 8/8/2019 FS ABC_ver2

    29/126

    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 officers 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

  • 8/8/2019 FS ABC_ver2

    30/126

    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 officers 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 officers main window.

    Confidential XYZ, 2007 Page 30

  • 8/8/2019 FS ABC_ver2

    31/126

    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 officers 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

  • 8/8/2019 FS ABC_ver2

    32/126

    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 andregisters 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 officers 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 batchs 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

  • 8/8/2019 FS ABC_ver2

    33/126

    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 Flows3ai) The student cannot register survey/thesis as a fourth course.

    7.4.2.5 Post-condition(s)

    The students thesis/survey request has been submitted and send to the academic officer.

    Confidential XYZ, 2007 Page 33

  • 8/8/2019 FS ABC_ver2

    34/126

    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 cant 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

  • 8/8/2019 FS ABC_ver2

    35/126

    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 students 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

  • 8/8/2019 FS ABC_ver2

    36/126

    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 madetheir 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 students 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 forapproval (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 P