university workflow management system - Google Project Hosting

farmacridInternet and Web Development

Feb 2, 2013 (4 years and 9 months ago)

898 views





FAST
-
NUCES

©

2012


PROJECT
REPORT

UNIVERSITY
WORKFLOW
MANAGEMENT
SYSTEM

Designed & Developed for FAST
-

NUCES,
Lahore Campus

by UWMS TEAM


University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠
N


Project Report





U
U
n
n
i
i
v
v
e
e
r
r
s
s
i
i
t
t
y
y


W
W
o
o
r
r
k
k
f
f
l
l
o
o
w
w


M
M
a
a
n
n
a
a
g
g
e
e
m
m
e
e
n
n
t
t


S
S
y
y
s
s
t
t
e
e
m
m






Project Code: UWMS


FAST


NU



Internal Advisor: Mr. Waqas Zyad





Submitted By:


Project Team

MS(SPM)

Rabia Akhtar

L10
-
5082

Mahwish Sonia

L10
-
5021

Bushra Maqbool

L10
-
5111

Nida Sarwar

L10
-
5106

Muhammad Aamir

L10
-
5032




Submission Date:
J
une

11
, 2012























University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠
O




Acknowledgement:



T
HIS
P
ROJECT WOULD NOT
HAVE BEEN POSSIBLE

WITHOUT THE ESSENTI
AL AND
GRACIOUS GUIDANCE
OF OUR PROJECT AD
VISOR
M
R
.

W
AQAS
Z
YAD HIS PERSONAL
SUPPORT AND INTERE
ST IN THE WEEKLY
PROGRESS

MEETINGS AND PRESE
NTATIONS
ENABLED US TO KEEP

THE PROJECT ON TR
ACK
.

W
E ALSO EXPRESS OU
R GRATITUDE TO
OUR PARENTS
&

FAMILIES WHO SUPPO
RTED US IN EVERY

CRUCIAL TIME OF OUR
STUDIES
.





























University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠
P


Executive Summary


FAST



NU is an educational institution, aiming to provide high quality education to the generations. To enhance
the performance of Administration and good coordination among different departments of the institution, students
from each department need many typ
es of requests to submit to different sections of the university. For this purpose,
manual forms are used, submitted and processed. The problems in this request process management are listed as
under:




Time Consumption



No knowledge of status of request



Re
source unavailability



Transfer of authority to process pending requests


University Workflow Management System is a web based open source request circulation system aiming to
computerize the existing manual system. Printed forms will be replaced with elect
ronic forms, submission and
forwarding process will remain as implemented by FAST


NU management; only this forwarding will be over the
software and request will be parked at authorized person’s dashboard. Students are able to generate the request in
orde
r to get their activities smooth which is then sent

step by step

to every user defined in a list. Also attachments
facility will be enabled to the every required request form (i.e. for illustration material) which allows the authorizing
personnel of the un
iversity to see the referenced documents, and take decision on immediate basis. At every level of
the request, users will be able to see the status of the request on dashboard unless it is marked as closed. All
operations like starting a workflow, tracking
, workflow definition or status observation can be done within a
comfortable and easy to use web interface. This system will be working in the premises of the institution and

will
also be accessible via Internet. Main features of the system are enlisted be
low:




Web based user interfaces



Dashboard facility to view the request status



User can attach files



System will be accessible via internet



Each user can perform required tasks related to his/her scope of work



Student user can view remarks by different depa
rtments



Student can view declined requests, reasons for declining and can resubmit a new request after resolving
issues identified by the authorities


Limitation of the project is availability of student and staff data from existing student management system running
in FAST
-
NU i.e., Radix. Also the project scope is limited to few requests received by Department of Computer
Sciences most frequently. Succe
ssful deployment of few requests handling can lay a strong ground for a complete
University Workflow Management System with all types of requests and staff involvement.

The future of this project is the extension of modules that will be deployed by UWMS t
eam. This will extend the
project to other departments of the institution enabling whole staff to manage student affairs electronically.








University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠
Q


Table of Contents

1.1

Introduction

................................
................................
................................
................................
.......................

9

2.1

Introduction

................................
................................
................................
................................
.....................

12

2.1.1

Purpose

................................
................................
................................
................................
................................
........

12

2.1.2

Scope

................................
................................
................................
................................
................................
...........

12

2.1.3

Problem Statement

................................
................................
................................
................................
......................

12

2.1.4

Intended Audience

................................
................................
................................
................................
.......................

12

2.1.6

Overview

................................
................................
................................
................................
................................
.....

13

2.2

Overall De
scription

................................
................................
................................
................................
..........

13

2.2.1

Product Perspective

................................
................................
................................
................................
.....................

13

2.2.2

Operating Environment

................................
................................
................................
................................
...............

13

2.2.3

User Characteristics

................................
................................
................................
................................
.....................

13

2.
2.4

Assumptions and Constraints

................................
................................
................................
................................
......

13

2.2.5

Stakeholder Identification
................................
................................
................................
................................
............

14

2.2.6

Actors List

................................
................................
................................
................................
................................
...

14

2.3

Software Requirements

................................
................................
................................
................................
...............

15

2.3.1

Functional Requirements

................................
................................
................................
................................
.

15

2.3.2

Non
-

Functional Requirements:

................................
................................
................................
.......................

32

2.3.2.2

Availability Requirements:

................................
................................
................................
................................
..........

35

2.3.2.3

Security Requirements:

................................
................................
................................
................................
...............

36

2.3.2.4

Performance Requirements:

................................
................................
................................
................................
........

36

2.3.2.5

Supportability

................................
................................
................................
................................
..............................

37

2.3.2.
6

Design Constraints:

................................
................................
................................
................................
.....................

37

2.3.2.7

Software Quality Attributes:

................................
................................
................................
................................
........

38

2.3.2.8

Reliability

................................
................................
................................
................................
................................
....

39

2.3.3

On
-
line User Documentation and Help
System Requirements

................................
................................
....................

41

2.3.4

Purchased Components

................................
................................
................................
................................
...............

41

2.3.5

Interfaces

................................
................................
................................
................................
................................
.....

42

User Interfaces

................................
................................
................................
................................
............................

42

Hardware Interfaces

................................
................................
................................
................................
....................

42

Software

................................
................................
................................
................................
................................
.......

42

Interfaces

................................
................................
................................
................................
................................
.....

42

Communications Interfaces

................................
................................
................................
................................
.........

42

2.3.6

Licensing Requirements

................................
................................
................................
................................
..............

42

2.3.7

Legal, Copyright, and Other Notices

................................
................................
................................
...........................

42

2.3.8

Applicable Standards

................................
................................
................................
................................
...................

42

2.5

Process Flow

................................
................................
................................
................................
....................

42

2.6

Use
-
Cases

................................
................................
................................
................................
........................

43

2.7

Traceability Matrix

................................
................................
................................
................................
..........

53

2.8.1

Login

................................
................................
................................
................................
................................
...........

54

2.9

Exclusio
ns from the Project

................................
................................
................................
.............................

65

3.1

Purpose

................................
................................
................................
................................
................................
........

67

3.2

References

................................
................................
................................
................................
................................
...

67

3.3

Project Deliverables
................................
................................
................................
................................
.....................

67

3.4

Project Organization

................................
................................
................................
................................
........

68

3.4.
1

Organizational Structure

................................
................................
................................
................................
..............

68

3.4.2

External Interfaces

................................
................................
................................
................................
.......................

68

3.4.3

Management Process

................................
................................
................................
................................
.......

69

3.4.3.1

Project Estimates & Schedule

................................
................................
................................
................................
......

69

3.4.3.2

Work Breakdown Structure (WBS)

................................
................................
................................
..............

71

3.4.3.3

Gantt Chart

................................
................................
................................
................................
..................

72

University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠
R


Table 07: Project Releases

................................
................................
................................
................................
.............................

74

3.
5

Project Feasibility Report

................................
................................
................................
................................
............

76

3.5.1


Technical Feasibility:

................................
................................
................................
................................
.

76

3.5.2


Operational Feasibility:

................................
................................
................................
.............................

77

3.5.5


Specification Feasibility:

................................
................................
................................
............................

77

3.5.7

Legal and Ethical Feasibility

................................
................................
................................
.......................

78

3.6. Tools and Technologies

................................
................................
................................
................................
...........................

78

3.8

FP Analysis:

................................
................................
................................
................................
.....................

8
0

3.9

Supporting Process Plans

................................
................................
................................
................................
.

85

3.9.1

Quality Assurance Plan

................................
................................
................................
................................
...............

85

3.9.2

Additional Plans

................................
................................
................................
................................
..............

85

4.1

Introduction

................................
................................
................................
................................
................................
.

88

4.1.1

Purpose

................................
................................
................................
................................
................................
........

88

4.1.2

Scope

................................
................................
................................
................................
................................
...........

88

4.1.3

Definition
s:

................................
................................
................................
................................
................................
..

88

4.1.4

Document Maintenance

................................
................................
................................
................................
...............

88

4.2.1

UWMS

................................
................................
................................
................................
................................
........

89

4.2.1.1

Project Director

................................
................................
................................
................................
...........

89

4.2.1.2

Project Manager (PM)

................................
................................
................................
................................

89

4.2.1.3

Risk Manager

................................
................................
................................
................................
...............

89

4.2.1.4

Risk Analyst

................................
................................
................................
................................
.................

89

4.2.1.5

Project Stakeholders and Vendors

................................
................................
................................
...............

89

4.3.1

Risk Management Process

................................
................................
................................
................................
...........

89

4.4

Project Activity Impact Report

................................
................................
................................
........................

98

4.5

Project Closeout

................................
................................
................................
................................
...............

98

4.5.1

Risk Review

................................
................................
................................
................................
................................

98

4.5.2

Lessons Lear
ned

................................
................................
................................
................................
..........................

99

4.5.3

Archive and Storage

................................
................................
................................
................................
....................

99

4.6


Appendix for RMP:

................................
................................
................................
................................
........

99

Risk Identification Template

................................
................................
................................
................................
...........................

99

Risk Analysis Report Template

................................
................................
................................
................................
......................

99

Risk Han
dling Strategy

................................
................................
................................
................................
................................
...

99

Risk Probability Definition

................................
................................
................................
................................
.............................

99

5.1

Introduction

................................
................................
................................
................................
...................

101

5.1.1

Purpose

................................
................................
................................
................................
................................
......

101

5.1.2

Scope

................................
................................
................................
................................
................................
.........

101

5.2

System Overview

................................
................................
................................
................................
...........

101

5.3

Management

................................
................................
................................
................................
..................

101

5.3.1

Organization Structure

................................
................................
................................
................................
...............

101

5.3.2

Tasks

................................
................................
................................
................................
................................
.........

102

Quality Assurance Manage

................................
................................
................................
................................
.......

102

UWMS QA team lead responsibilities are:

................................
................................
................................
................

102

Quality Assurance Engineers:

................................
................................
................................
................................
...

103

5.4

Documentation

................................
................................
................................
................................
...............

103

5.4.1

Purpose

................................
................................
................................
................................
................................
......

103

5.4.2

Documentation Requirements

................................
................................
................................
................................
...

103

5.4.3

Documents Used to Develop SQAP

................................
................................
................................
..........................

103

5.4.4

Relationship to other plans

................................
................................
................................
................................
........

103

5.5

Standards, Conventions and Metrics

................................
................................
................................
.............

103

5.5.1

Standards

................................
................................
................................
................................
................................
...

103

University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠
S


Documentatio
n Standard:
................................
................................
................................
................................
..........

103

5.5.2

Conventions

................................
................................
................................
................................
...............................

104

Code Conventions

................................
................................
................................
................................
......................

104

5.5.3

Metrics

................................
................................
................................
................................
................................
.......

104

Internal Quality Metrics for Deliverables:

................................
................................
................................
................

104

We measure
to plan, control, improve and organize the activities. Quality Metrics for Deliverables are:

..............

104

5.6

Reviews

................................
................................
................................
................................
.........................

104

5.6.1

Minimum Requirements

................................
................................
................................
................................
............

104

5.6.2

Audits

................................
................................
................................
................................
................................
........

105

5.6.3

Training

................................
................................
................................
................................
................................
.....

105

5.7

Problem Reporting and Corrective Action

................................
................................
................................
....

105

5.7.1

Issue Tracki
ng Process

................................
................................
................................
................................
..............

105

Table 36: Defect severity status after release

................................
................................
................................
...............................

105

Table 37: Defect density report after release
................................
................................
................................
................................

106

5.7.2

Problem Reporting Process

................................
................................
................................
................................
.......

106

5.8

Risks and Contingencies

................................
................................
................................
................................

106

5.9

Tools, Techniques, and Methodologies

................................
................................
................................
.........

106

5.9.1

Development Methodology

................................
................................
................................
................................
.......

106

5.9.2

Quality Assurance Methodology

................................
................................
................................
...............................

106

QA Reviews Test Plan


Test Plan identifies the scope, objective, testing sequence, testing strategy, automation
strategy, resources, testing types and coverage area. Test Plan and Test
data will be generated in the Integration
and testing stage of the project. Testing life cycle will be as follows:

................................
................................
.......

107

5.10

Code
Control and Media Control

................................
................................
................................
...................

107

5.11

Records Collection, Maintenance, and Retention

................................
................................
..........................

107

5.11.1

Quality assurance Repository

................................
................................
................................
................................
....

107

5.11.2

C
ode Repository

................................
................................
................................
................................
........................

107

Test Cases and Test Data Design

................................
................................
................................
..............................

108

6.1

Introduction

................................
................................
................................
................................
...................

109



















University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠
T





University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠
U
































University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠
9


1.1

Introduction

FAST


NU is an educational institution, aiming to provide high quality education to the generations. To enhance
the performance of Administration and good coordination among different departments of the institution, students
from each department need many

types of requests to submit to different section s of the university. For this
purpose, manual forms are used, submitted and processed.


1.2

Current System Overview

Currently University is already using LIMS software which developed by (www.paklag.org) in order to manage its
library. The old system is currently running in MS access form interfaces. At the moment, only librarians can use the
system. For a user to perfo
rm normal operations like search, reserve and borrow
etc.
, he/she must have to go through
librarian. The librarians need training in order to use the system. Only limited person are allowed to use the system.
The system also cannot be accessed remotely. Th
e system uses MS access database in order to manipulate and
manage data.

1.3

Problem Statement

The medium of communication among different sections of FAST


NU are forms printed, filled and processed by
officials. The problems in this request process man
agement are listed as under:



Customers (Teachers or students)



Time consuming



Resource unavailability

1.4

High end Goals /
objectives

The High end Goals / objectives of the project are divided into parts:

Project (Request Management System)
:



System will be
accessible
anywhere

(premises of the university or internet).



Student can submit request, and can get the feedback for status of each request processed.



Each stakeholder will manage the requests.



Make software more user friendly (Desktop interface and web
based interface).

Team (Who are going to make this project)
:



Understand domain from which the problem has been identified capturing all the actors, processes and their
interactions.



Interview (Meeting or Questioning) the customer for understanding what th
e customer wants, analyzing
needs, and negotiating a reasonable solution to the problem.



Produce a SRS, domain document and FS.



Validated FS document with the help of a RE tool by checking the requirements validity, consistency or
completeness.

1.5

Project

Scope

The software product to be produced is the Web based Student Request Management System for Universities. The
scope of the project is thus limited to FAST
-
NU Lahore. This system will be working in the premises of the
institution and

will also be acce
ssible online via Internet.


The system shall allow online users to submit different requests in order to get their Academic activities smooth. A
large list of request types has been collected, with respect to almost all sections of the institutions. The r
equest will
therefore be limited due to limited time span of 1 year for the project implementation. It will allow the users to
generate new requests and see the status of approval/disapprove/cancelled for the request already submitted. This
new system will

have an intuitive and user friendly

graphical user interfaces.


The new product will eliminate all the limitations and disadvantages of the old system, i.e.:



Manual request forms will be replaced



The flow of request forms for approval and remarks from d
ifferent sections of the institution will be done
automatically through the implemented business processes



Every part of the application will be available to the authorized person only.


University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠



cA協


NU Request management System will provide web based interfaces

for users through which they will be
able to perform user management, request levels management and request forwarding and approvals/rejections.


Currently the circulation of request forms have time problem and the request status is not clear to
anyone

w
ho has
either generated the request or has forwarded one. Therefore this system will help the users to keep track of requests
for their status and take immediate actions on whate
ver is required by the students.

1.6

Resources

The project team comprises
five

resources. To understand the problem, resources can divide the work and perform
the entire task to solve the problem. By sharing data among the resources, team can produce SRS, and FS. To
validate the requirements and get feedback during prototyping perio
d, we can get all information easily from FAST
-
NU Academic Coordinator, Department Secretaries and Faculty Members in order to complete this project. We can
conduct interviews and meetings with the available staff members to understand the exact requiremen
ts.































University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠





























University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠



2.1

Introduction

FAST


NU is an educational institution, aiming to provide high quality education to the generations. To enhance
the performance of Administration and provide better services to the students, students from different departments
are offered to raise their n
eedful requests. On daily basis, many types of requests are submitted to different sections
of the university. These requests are processed, circulated through different sections and reaches back to the student,
with relevant actions taken. This activity i
s currently carried out through manual forms available in all sections of
the institution.

2.1.1

Purpose

The purpose of University Workflow Management System is to facilitate students and Administration by providing
an electronic medium to process student

requests on daily basis. Its primary objective is speed up the request
management processes with automation of the manual system to provide ease to students and administration by
cutting the cost of time and effort.

2.1.2

Scope

The software product to be produc
ed is the University Request Management System. The scope of the project is thus
limited to FAST
-
NU Lahore. This system will be working in the premises of the institution and

will also be
accessible via Internet.


The system is aimed to allow students to s
ubmit different requests in order to get their Academic activities smooth.
A large list of request types has been collected, with respect to almost all sections of the institutions. The request list
will therefore be limited due to limited time span of 1 y
ear for the project implementation. The system will allow the
users to submit their requests and to see the status (approved/disapproved/cancelled) for the submitted requests. This
new system will have an intuitive and user friendly

graphical user interfac
e.


The proposed system will eliminate the problems with the old system and also remove the limitation because of its
enhanced scope .i.e.:



Manual request forms will be replaced with electronic forms



The flow of request forms for approval and remarks from

different sections of the institution will be
handled automatically through the implemented business processes



Every part of the application will be available to the authorized person only.


University Workflow Management System will provide web based int
erfaces to users of FAST
-
NU Lahore through
which they will be able to perform user management, request levels management and request forwarding and
approvals/rejections.

2.1.3

Problem Statement

The current manual system has a major time problem with the circula
tion of request forms and the request status is
not clear to anyone who has either generated the request or has forwarded one. The person who is assigned to
process the request at any level, if may not available, there is no one who could check his pending

forms and can
authorize any other person to process the request. Because of this, students have to wait for a long time t
o get their
requests processed and also student have to appear oneself to check the status and it’s very difficult, especially for
MS
students who have bus schedules.
Therefore this system will surely help the users to keep track of requests
pending at their level and take immediate actions on whatever is required by the students.

2.1.4

Intended Audience

The intended audience for this document

is listed below:



Project Advisor



Project Manager



Project Team



External Advisor



Project Team who will continue upgrades in current system



Department Secretaries

University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠



2.1.5

References



Initial RS draft was provided by Project Advisor: Waqas Zyad

2.1.6

Overview

This document
is prepared to gather requirements for University Workflow Management System. The aim of the
project is to handle all request types that are generated by student and circulate among all departments of the
institution. Due to short time, and less resources,

this SRS is listed with limited set of request types. The main
purpose of the project is to speed up the request processing among different departments, facilitate the users and
support RADIX Student Management System and Accounts Management System curren
tly running in the
university. These systems require feedback of the request to update registration and fee statuses of the students.
Initially, system will provide an interface for the users of each of these systems. The integration of 3 systems is
exclud
ed from the scope of the project, as there are many Business rules and constraints apply on it.

2.2

Overall Description

FAST
-
NU Lahore is currently using manual system i.e., paper printed form to manage the student request. This
system has a major issue of tim
e management with the circulation of request forms and the request status is not clear
to anyone who has either generated the request or has forwarded one. The person who is assigned to process the
request at any level, if may not available, there is no on
e who could check his pending forms and can authorize any
other person to process the request. Because of this, students have to wait for a long time to get their requests
processed. Therefore this system will surely help the users to keep track of request
s pending at their level and take
immediate actions on whatever is required by the students.

2.2.1

Product Perspective

This application will be a web based application. Server machine will have a web server and database server. Client
will run on web browsers. T
his application will support all the renowned web browsers i.e. Firefox and Internet
Explorer 8.

2.2.2

Operating Environment

This is a web based application and client can be run on any browser (i.e. Firefox and Internet Explorer 8) in


Windows XP, 7
.



The user

should have the basic know how of internet and computers

2.2.3

User Characteristics



All the users of Application will be students of the university or university other staff i.e. teachers
and administration.



User Training should be there specially to train the

users about the usage of the system.



IT staff are expected to have solid computer skills and some experience dealing with web server
configuration and database installation.

2.2.4

Assumptions and Constraints

The following constraints are applied:



The project t
eam will pull out data from exiting Radix and Accounts System running currently in FAST
-
NU. It strictly depends on the cooperation and i
nterest of the Management in other case, we will provide
link to the respective radix page to the user so that the one
can perform validations.



Only few request types will be covered ensuring all nodes of request workflow processing are touched.



Initially, at first level, The Department of Computer Sciences of FAST
-
NU will be automated. Later on, the
other departments will

be invited to experience with the new software.



The system is required to be used only in University premises at start, but as this is web based application
so if university allows to access their server from outside this can be accessed from outside the
premises.




Regarding validation, the requirements will be verified against business processes of the university.

University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠





Integration with the existing systems of Radix and Accounts Management System is out of scope of this
project.



UWMS wi
ll provide separate inter
faces to Radix and Accounts Management system users in order to update
real
-
time Student Statuses on the basis of decisions made by the departments.



FAST NU
will provide computers to developers, QA for development of this project

2.2.5

Stakeholder Identification

Below is the stakeholder list that can be effected directly or indirectly with the system and involve in the system
development life cycle.

1.

Student

1.

MS Students (CS
)

2.

BS Students (CS)

3.

PHD Students (CS
)

2.

Faculty

4.

Computer Science Faculty

3.

Accounts

4.

Admin



Front Office/Reception

5.

Academics



Manager Academics



Student Co
-
coordinator



Departmental Secretaries

6.

Library

7.

Computer Labs

8.

Director Office

9.

Development Team

10.

Project Advisor

2.2.6

Actors List

1.

Student

2.

Teacher

3.

Department Secretary

4.

Academic Coordinator

5.

Accounts
Department Staff

6.

Administrator


Admin term is used for department secretary, academic coordinator, account Department staff
and Administrator. Administrator is the super admin who is managing all type of users.



University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠



2.3

Software Requirements

2.3.1

Functional Requireme
nt
s

The system access will be managed with user authorization assigned by Administrator to all types of users.
.
Different functions of the system will need their respective authorizations to allow the user to perform its required
functions. Therefore, any
user from any role can be authorized to access the system whenever needed by the
Administrator


2.3.1.1

General Requirements:


Requirement #

FR
-
01

Identifier

User.Login

Title

User Login

Requirement

System shall allow the user [all actors] to log in to

the system

Source

Requirement Engineering Team

Rationale

To allow the registered user to login in to the system

Restrictions and Risks

Nil


Dependencies

Nil

Additional information

Login Attributes: Email, Password

Priority rating (H/L/M)

High

Actor(s)

All authorized users of the system


Requirement #

FR
-
02

Identifier

User.Logout

Title

User Logout

Requirement

System shall allow the user[all actors] to log out from the System

Source

Requirement Engineering Team

Rationale

To allow the
registered user to log out from the system and destroy its user
session.

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

Nil

Priority rating (H/L/M)

High

Actor(s)

All authorized users of the system


Requirement #

FR
-
03

Identifier

User.SignUp

Title

User SignUp

Requirement

System shall allow the user to sign up to the system.

Source

Requirement Engineering Team

Rationale

To allow the unregistered user to register itself to the system and can avail
the functionality of

the system.

Restrictions and Risks

Nil


Dependencies

User.Signup

Additional information

User has to provide the Name, email, address, phone number, gender, city,
country and new password with confirmation password to register itself to
the system.

University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠



mr楯r楴i r慴楮g E䠯i⽍L

䡩eh

A捴crEsF

A汬⁡uthor楺敤 us敲s of th攠sys瑥m xonly 乕kstud敮瑳z



Requirement #

FR
-
0
4

Identifier

View. Dashboard

Title

View Dashboard

Requirement

System shall allow user to view their dashboard.

Source

Requirement
Engineering Team

Rationale

To allow user to see the incoming requests.

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

Nil

Priority rating (H/L/M)

High

Actor(s)

All authorized users of the system


Requirement #

FR
-
05

Identifier

User.Edit.Profile

Title

User.Profile.Edit

Requirement

System shall allow users to edit their profile.

Source

Requirement Engineering Team

Rationale

To provide functionality to the user to be able to update its profile
information if any profile attribute get changed.

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

Nil

Priority rating (H/L/M)

High

Actor(s)

All
authorized users of the system



2.
3.1.2

Approving Authorities Requirements:


Requirement #

FR
-
0
6

Identifier

User.Requests.Notification

Title

Requests Notification

Requirement

System shall send notification of his/her pending or queued requests to
user
via email.

Source

Requirement Engineering Team

Rationale

To provide ease to user, we notify via email about number of requests has
been received in a day.

Restrictions and Risks

Nil


Dependencies

User should have account of FAST
-
NU Lahore mail.

Additional information

Nil

Priority rating (H/L/M)

High

Actor(s)

All authorized users of the system


University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠



Requirement #

FR
-
0
7

Identifier

Request.Status.Approved

Title

Request Status as Approved

Requirement

System shall allow the actors to approve the
request which are pending to
them.

Source

Requirement Engineering Team

Rationale

Requests are required to approve or disapprove.

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

User should know the requirement completely and have rights to approve

Priority rating (H/L/M)

High

Actor(s)

Teacher, Department Secretary,Academic Coordinator,Accounts
Department Staff


Requirement #

FR
-
0
8

Identifier

Request.Status.Declined

Title

Request Status as Declined

Requirement

System shall allow the approving authority to decline the request which is
pending to them.

Source

Requirement Engineering Team

Rationale

Requests are required to approve or disapprove.

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

User should know the requirement completely and have rights to declined

Priority rating (H/L/M)

High

Actor(s)

Teacher, Department Secretary,Academic Coordinator,Accounts
Department Staff


Requirement #

FR
-
0
9

Identifier

Request.Attachments.Upload

Title

Upload Attachments

Requirement

System shall allow the user to upload reference documents / images with
the request which are open to them.

Source

Requirement Engineering Team

Rationale

To provide the
evidence or reference for any request, the user shall be able
to upload attachments, so that where required, the authorized personnel can
download them and make decisions easily.

Restrictions and Risks

NFR02
-
02

Dependencies

User.Login

Additional
information

Attachments are allowed to be added along any request only till the request
entry is valid for the user to update.

Priority rating (H/L/M)

Medium

Actor(s)

All authorized users of the system


Requirement #

FR
-
10

Identifier

Request.Attachments.Download

Title

Download Attachments

University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠



o敱u楲em敮t

pys瑥m sha汬⁡汬lw 瑨攠慰prov楮g author楴y 瑯 down汯慤 慴瑡捨敤 f楬攠wi瑨
r敱u敳琮

卯ur捥

o敱u楲em敮琠tng楮敥ring q敡m

o慴楯n慬a

qh攠suppor瑩tg do捵m敮ts 慲攠of瑥t r敱u楲敤 瑯 b攠慴瑡ah敤 w楴h th攠r敱u敳t
慳a 愠 proof. qo 敮sur攠 smooth 慮d 瑩m攠 eff楣楥i琠 d散is楯n mak楮gI th敳e
慴瑡ahm敮瑳 shou汤 b攠down汯慤慢汥lfor 瑨攠慵瑨or楺ing s瑡ff.

o敳瑲楣瑩ens and o楳ks

乩k


䑥a敮d敮捩敳

啳敲.iog楮
I o敱u敳琮䅴瑡捨em敮瑳.啰汯慤

Add楴楯n慬ainform慴楯n

A瑴慣hmen瑳 慲攠慬汯w敤 瑯 b攠v楥w敤 慮d down汯慤 瑯 慮y r敱u敳琠enly 瑩汬
瑨攠r敱u敳琠en瑲y is v慬楤 for 瑨攠us敲 瑯 upd慴攮

mr楯r楴i r慴楮g E䠯i⽍L

䵥d極m

A捴crEsF

A汬⁡uthor楺敤 us敲s of

th攠sys瑥m


2.
3.1.3

Academic Requirements:


Requirement #

FR
-
1
1

Identifier

Request.Offer.Course

Title

Request to Offer New Course

Requirement

System shall allow the student to submit a request for offering a new course
in the coming semester.

Source

Requirement Engineering Team

Rationale

Students are facilitated to have request to offer a new course

Restrictions and Risks

User can submit request to offer a course only if request is open to him/her.


Dependencies

User.Login

Additional information

NA

Priority rating (H/L/M)

Medium

Actor(s)

Student



Requirement #

FR
-
1
2

Identifier

Request.Add.Course

Title

Add Course

Requirement

System shall allow the student to submit a request to add course.

Source

Requirement Engineering Team

Rationale

A
student can submit a request to add a new course form the list of offered
courses for the current academic session.

Restrictions and Risks

User can submit request to add a course only if request is open to him/her.


Dependencies

User.Login

Additional
information

NA

Priority rating (H/L/M)

High

Actor(s)

Student


Requirement #

FR
-
1
3

Identifier

Request.Drop.Course

Title

Drop Course

Requirement

System shall allow the student to submit a request to drop course.

University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠



卯ur捥

o敱u楲em敮琠tng楮敥ring q敡m

o慴楯n慬a

ff 愠s瑵d敮琠do敳eno琠w慮琠瑯 con瑩tu攠愠捯urs攠楮 愠s敳e楯nI 愠r敱u敳琠捡n b攠
subm楴瑥i 瑯 drop 瑨慴a捯urs攠from h楳Lh敲 敮rolm敮琮

o敳瑲楣瑩ens and o楳ks

啳敲 捡n submi琠t敱u敳琠瑯 慤d 愠捯urs攠only if r敱u敳琠楳 op敮 瑯 himLh敲.

䑥a敮d敮捩敳

啳敲.iog楮

Add楴楯n慬ainform慴楯n



mr楯r楴i r慴楮g E䠯i⽍L

䡩eh

A捴crEsF

却pdent


Requirement #

FR
-
1
4

Identifier

Request.Course.Withdraw

Title

Withdraw Course

Requirement

System shall allow a student to submit a request to withdraw a course.

Source

Requirement Engineering team

Rationale

To facilitate students to raise request to withdraw a course.

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

NA

Priority rating (H/L/M)

High

Actor(s)

Student


Requirement #

FR
-
1
5

Identifier

Request.Change.Section

Title

Request to Change Section

Requirement

System shall allow the student to submit a request to change the section in a
registered course.

Source

Requirement Engineering team

Rationale

To facilitate students
to change their section in a particular course in which
they have enrolled in current session.

Restrictions and Risks

Nil

Dependencies

User.Login

Additional information

NA

Priority rating (H/L/M)

Medium

Actor(s)

Student


Requirement #

FR
-
1
6

Identifier

Request.Freeze.Semester

Title

Request to Freeze Semester

Requirement

System shall allow the student to submit a request to freeze his/her
semester.

Source

Requirement Engineer team

Rationale

Students are allowed to freeze the semester
within given time.

Restrictions and Risks

Nil


Dependencies

User.Login, In one session, only one Semester Freeze request can be
submitted, conditional to previous request are not marked as cancelled in
the system.

Additional information

NA

University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠



mr楯r楴i
r慴楮g E䠯i⽍L

䵥d極m

A捴crEsF

却pdent


Requirement #

FR
-
1
7

Identifier

Request.Change.Password

Title

Request to change password

Requirement

System shall allow the user to change password successfully.

Source

Requirement Engineering team

Rationale

Users are allowed to change the password to keep their system accounts
secure.

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

Nil

Priority rating (H/L/M)

High

Actor(s)

All authorized users of the system


Requirement #

FR
-
1
8

Identifier

Filter.Requests.Program

Title

Filter Requests with respect to Students’ Degree Program

o敱u楲em敮t

啳敲 sh慬氠l攠慢汥l瑯 f楬瑥i r敱u敳es 慣捯rd楮g 瑯 瑨攠av慩污al攠d敧r敥
progr慭s EB匯䵓⽐䡄e

卯ur捥

o敱u楲em敮琠tng楮敥ring 瑥tm

o慴楯n慬a

啳敲 n敥ds 瑯 b攠 prov楤敤 w楴h d敧r敥 汥le氠 f楬瑥ts to v楥w r敱ues瑳
submitted by specific discipline’s students.

o敳瑲楣瑩ens and o楳ks

乩k


䑥a敮d敮捩敳

啳敲.iog楮

Add楴楯n慬ainform慴楯n

乩k

mr楯r楴i r慴楮g E䠯i⽍L

䡩eh

A捴crEsF

q敡捨敲I
䑥a慲瑭敮琠卥捲整慲yIA捡dem楣iCoord楮慴arIA捣ounts
䑥a慲tm敮琠却慦f


Requirement #

FR
-
1
9

Identifier

Filter.Requests.Date

Title

View Request with respect to calendar date

Requirement

User shall be able to view received requests submitted against any
calendar
date

Source

Requirement Engineering team

Rationale

User needs to be provided with filters to view request w.r.t Date As requests
are submitted with newest date will be displayed on top.

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

Nil

Priority rating (H/L/M)

High

Actor(s)

Teacher, Department Secretary,Academic Coordinator,Accounts
Department Staff


Requirement #

FR
-
20

University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠



fd敮瑩t楥i

䙩c瑥t.o敱ues瑳.乡m攠

Title

View Request with respect to user name

Requirement

System shall allow the user to view received requests submitted against any
user name

Source

Requirement Engineering team

Rationale

User needs to be provided with filters to view request w.r.t name

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

Nil

Priority rating (H/L/M)

High

Actor(s)

Admin staff


Requirement #

FR
-
21

Identifier

Filter.Requests.Roll No

Title

View Request with respect to student roll no

Requirement

System shall allow the user to view
received requests submitted against any
roll no

Source

Requirement Engineering team

Rationale

User needs to be provided with filters to view request w.r.t roll no

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

Nil

Priority

rating (H/L/M)

High

Actor(s)

Admin staff


Requirement #

FR
-
22

Identifier

Filter.Requests.Assignee

Title

View Request with respect to
user assigned currently to process the request

Requirement

System shall allow the user to view received requests submitted against any
assignee name

Source

Requirement Engineering team

Rationale

User needs to be provided with filters to view request w.r.t assignee name
e.g.: HoD, dept secretary, etc.

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

Nil

Priority rating (H/L/M)

High

Actor(s)

Admin staff


Requirement #

FR
-
23

Identifier

Filter.Requests.Status

Title

View Request with respect to status of the request

Requirement

System shall allow the user to view received requests submitted against any
status


Source

Requirement Engineering team

University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠



o慴楯n慬a

啳敲 n敥ds 瑯 b攠 prov楤敤 w楴h f楬瑥is 瑯 v楥w r敱ues琠 w.r.琠 s瑡tus 攮g.W
p敮d楮gI subm楴瑥iI r敪散瑥t e瑣t

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

Nil

Priority rating (H/L/M)

High

Actor(s)

Admin staff


Requirement #

FR
-
24

Identifier

Filter.Requests.Type


Title

View Request with respect to type of the request

Requirement

System shall allow the user to view received requests submitted against any
type of the request


Source

Requirement Engineering team

Rationale

User needs to be provided with filters to view request w.r.t type of the
request e.g. : add
course, withdraw course , etc.

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

Nil

Priority rating (H/L/M)

High

Actor(s)

Admin staff




Requirement #

FR
-
2
5

Identifier

View.Authorize.Requests

Title

View authorized
requests only

Requirement

User shall be able to view the listing of only those requests for which he is
authorized to.

Source

Requirement Engineering team

Rationale

User needs to be able to view the requests. The view of user shall be
restricted according to the level of authorization granted to each user. For
example, users related to Accounts department shall be able to view only
accounts issues related requests.

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

Nil

Priority rating (H/L/M)

High

Actor(s)

All authorized users of the system


Requirement #

FR
-
2
6

Identifier

Request.Forget.Password

Title

Request to forget password

Requirement

System shall allow the user to change password by sending a new password
via email.

Source

Requirement Engineering team

University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠



o慴楯n慬a

ff 瑨攠us敲 forg整s 楴i p慳swordI us敲s 慲攠慬汯w敤 瑯 捨ange 瑨攠p慳aword

o敳瑲楣瑩ens and o楳ks

乩k


䑥a敮d敮捩敳

啳敲.iog楮

Add楴楯n慬ainform慴楯n

bm慩氠慤dr敳eI s散ur楴y ques瑩on.

mr楯r楴i r慴楮g E䠯i⽍L

䡩eh

A捴crEsF

A汬⁡uthor楺敤 us敲s of th攠sys瑥m


2.
3.1.
4

Administrator Request:


Requirement #

FR
-
2
7

Identifier

System.Create.User

Title

User
Definition

Requirement

System shall allow admin to create new user.

Source

Requirement Engineer team

Rationale

To provide the facilities to logged in users to make request to treat with
requests.

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

Admin Rights

Priority rating (H/L/M)

High

Actor(s)

Administrator


Requirement #

FR
-
2
8

Identifier

System.Change.Rights

Title

Change Rights of Users

Requirement

System shall allow the administrator to change rights of users
[All actors
except self and student].

Source

Requirement Engineer team

Rationale

Administrator can change the rights of requests for different users. E.g.

Department Secretary can receive the request of add course of his
department. He can process this request.

Restrictions and Risks

Nil


Dependencies

System.Define.User

Additional information

Nil

Priority rating (H/L/M)

High

Actor(s)

Administrator


Requirement #

FR
-
2
9

Identifier

System.EnableDisable.RequestType

Title

Enable or disable Request Type

Requirement

System shall allow the user to enable or disable the request types.

Source

Requirement Engineering team

Rationale

To ensure meet the
deadlines by department, the user of the system needs to
make requests available/unavailable to the student users. For this purpose,
the admin user can enable or disable the request types whenever needed.

Restrictions and Risks

Nil


Dependencies

User.Login

University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠



Add楴楯n慬ainform慴楯n

oo汥ld敦楮楴楯n wi汬⁳l散ify th攠慤min and s瑵den琠ts敲s.

mr楯r楴i r慴楮g E䠯i⽍L

䡩eh

A捴crEsF

Admin楳瑲慴ar


Requirement #

FR
-
30

Identifier

System.EnableDisable.User

Title

Enable or disable User of the system

Requirement

Admin user shall be able to enable or disable the user.

Source

Requirement Engineering team

Rationale

Nil

Restrictions and Risks

In order to avoid any request submission by any student; the admin user can
disable the student user logins as
soon as a student is declared as for
example, passed out from the institution.

Dependencies

System. EnableDisable.User

Additional information

Role definition will specify the admin and student users.

Priority rating (H/L/M)

High

Actor(s)

Administrator


Requirement #

FR
-
31

Identifier

System.Create.Multiple.Users

Title

User Definition

Requirement

System shall allow admin to create multiple users by importing data from
excel file.

Source

Requirement Engineer team

Rationale

To provide the facilities

to logged in users to make request to treat with
requests.

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

Admin Rights

Priority rating (H/L/M)

High

Actor(s)

Administrator


Requirement #

FR
-
32

Identifier

System.Assign.Roles

Title

Assignment of Roles

Requirement

System shall allow admin to assign roles to the created users

Source

Requirement Engineeringing team

Rationale

To provide the facilities to Admin to assign roles to the created users

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

Admin Rights

Priority rating (H/L/M)

High

Actor(s)

Administrator


Requirement #

FR
-
33

Identifier

Users.Add.Comments

University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠



q楴汥i

Add Comments

o敱u楲em敮t

pys瑥m sha汬⁡汬lw 慤min

瑯 慤d 捯mments 瑯 瑨攠r散敩e敤 r敱u敳瑳

卯ur捥

o敱u楲em敮琠tng楮敥ring 瑥tm

o慴楯n慬a

qo prov楤攠瑨攠f慣楬楴楥s 瑯 pr楶楬ig敤 us敲s 瑯 慤d 捯mments 瑯 瑨攠r敱u敳琠

o敳瑲楣瑩ens and o楳ks

乩k


䑥a敮d敮捩敳

啳敲.iog楮

Add楴楯n慬ainform慴楯n

Admin
oigh瑳

mr楯r楴i r慴楮g E䠯i⽍L

䡩eh

A捴crEsF

Admin楳瑲慴ar


Requirement #

FR
-
34

Identifier

Users.View.Comments

Title

View Comments

Requirement

System shall allow users (admin/student) to view comments to the requests,
they are privileged to view.

Source

Requirement Engineering team

Rationale

To provide the facilities to privileged users to view comments that are
added to the request

Restrictions and Risks

Nil


Dependencies

User.Login,

View.Authorize.Requests

Additional information


Priority
rating (H/L/M)

High

Actor(s)

All authorized users of the system


Requirement #

FR
-
35

Identifier

Approve.Authorize.Requests

Title

Approve Requests

Requirement

System shall allow admin to approve request, they are privileged to approve

Source

Requirement Engineering team

Rationale

To provide the facilities to privileged users to approve requests that are
added to the request

Restrictions and Risks

Nil


Dependencies

User.Login,

View.Authorize.Requests

Additional information


Priority rating

(H/L/M)

High

Actor(s)

All authorized users


Requirement #

FR
-
36

Identifier

Decline.Authorize.Requests


Title

Decline Requests

Requirement

System shall allow admin to approve request, they are privileged to decline

Source

Requirement Engineering
team

Rationale

To provide the facilities to privileged users to decline requests that are
added to the request

Restrictions and Risks

Nil


University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠



䑥a敮d敮捩敳

啳敲.iog楮I

噩sw.䅵thor楺攮o敱u敳es

Add楴楯n慬ainform慴楯n


mr楯r楴i r慴楮g E䠯i⽍L

䡩eh

A捴crEsF

A汬⁡uthor楺敤 us敲s


Requirement #

FR
-
37

Identifier

Users.View.Report

Title

View report

Requirement

System shall allow the admin users to view report regarding the requests
placed by the system.

Source

Requirement Engineering team

Rationale

To
provide the facilities to privileged users to view reports based on the
requested search criteria.

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

User can access the reports based on user name, roll number, request type,
requested on date, status of the request.

Priority rating (H/L/M)

High

Actor(s)

Admin Users


Requirement #

FR
-
38

Identifier

Users.Comments.Visibilty

Title

Students Comments Visibility

Requirement

System shall allow the users [students] to view the final comments/ reasons
of rejection.

Source

Requirement Engineering team

Rationale

To avoid to show the internal discussion and decisions of higher authorities
to the student. But the student is eligible to view the reasons of rejection
against their requests.

Restrictions and Risks

Nil


Dependencies

Users.View.Comments

Additional
information

Nil

Priority rating (H/L/M)

High

Actor(s)

All authorized users of the system


Requirement #

FR
-
39

Identifier

Users.Export.Report

Title

Export report

Requirement

System shall allow the admin users to export report in pdf/csv format

Source

Requirement Engineering team

Rationale

To provide the facilities to privileged users to view reports based on the
requested search criteria.

Restrictions and Risks

Nil


Dependencies

User.Login

Additional information

User can access the reports based on user name, roll number, and request
type, requested on date, status of the request.

Priority rating (H/L/M)

High

University Workflow Management System

Version:
2
.0

Project Report

Date: 11
/
Jun/2012


Confidential


䙁協


乕ki慨ore

m慧攠



A捴crEsF

Admin 啳敲s


Summary of all functional Requirements:


No.

Identifier

Summary

FR
-
01

User. Login

System shall allow the user to log in to the system

FR
-
02

User. Logout

System shall allow the user to log out from the System

FR
-
03

User.SignUp

System shall allow the user to sign up to the system.

FR
-
04

View.DashBoard

System shall allow user to view his/her dashboard.

FR
-
05

User.Edit.Profile

System shall allow users to edit their profile.

FR
-
06

User.Requests.Notification

System shall send notification of his/her pending or queued
requests via email

FR
-
07

Request.Status.Approved

System shall allow the actors to approve the request which are
pending to them.

FR
-
08

Request.Status.Declined

System shall allow the approving authority to decline the request
which is pending to them.

FR
-
09

Request.Attachments.Upload

System shall allow the user to upload reference documents /
images with the request.

FR
-
10

Request.Attachments.Download

System shall allow the approving authority to download attached
file with request.

FR
-
11

Request.Offe
r.Course

System shall allow the student to submit a request for offering a
new course in the coming semester.

FR
-
12

Request.Add.Course

System shall allow the student to submit a request to add course.

FR
-
13

Request.Drop.Course

System shall allow the student to submit a request to drop course.