Software Requirements Specification

Version 1.0
17.01.2016

Fee Management System

Submitted in partial fulfillment

Of the requirements of
CS 223 Software Engineering

This work is based upon the submissions of the course Software Engineering (CS223).
The students who submitted this team projects were Kshitij Minocha [UG201310043],
Rajan Vaghela [UG201310039], Piyush Yadav [UG201310023] and Tapan Bhatnagar
[UG201310037].

Table of Contents
Table of Contents ............................................................................................................................................ i
List of Figures ................................................................................................................................................ ii
1.0. Introduction ............................................................................................................................................. 1
1.1. Purpose ................................................................................................................................................ 1
1.2. Scope of Project................................................................................................................................... 1
1.3 Constraints ............................................................................................................................................ 3
1.4 Assumptions and Dependencies ........................................................................................................... 3
1.3. Glossary ............................................................................................................................................... 3
1.4. References ........................................................................................................................................... 3
1.5. Overview of Document ....................................................................................................................... 4
2.0. Overall Description ............................................................................................................................ 5
2.1
System Environment ....................................................................................................................... 5
2.2
Functional Requirements Specification .......................................................................................... 5
2.2.1
Use case 1 ............................................................................................................................... 5
Use case: ............................................................................................................................................. 5
2.3
User Characteristics ........................................................................................................................ 5
2.4
Non-Functional Requirements ........................................................................................................ 5
3.0. Requirements Specification ................................................................................................................ 6
3.1
Functional Requirements ................................................................................................................ 6
3.1.1
<< Name of the first feature>> ............................................................................................... 6
3.1.2
<< Name of the second feature>> ......................................... Error! Bookmark not defined.
3.3
Detailed Non-Functional Requirements ......................................................................................... 8
3.4
Logical Structure of the Data .................................................................................................... 9
4.0 Supporting information ............................................................................................................................ 9
4.1 Table of contents and index .................................................................................................................. 9
4.2 Appendixes ........................................................................................................................................... 9

List of Figures
No table of figures entries found.

ii

1.0. Introduction
1.1. Purpose
The purpose of this document is to describe the design and implement of a fee
management system for the students of an institution. The implementation of the system
will be based on .Net framework. The system will be based on a universal application
[Windows Desktop and Mobile App] that the students can use to pay their fee. The
system will have a simple UX and will be secured through encryption of important data,
will be fast enough to provide access to stored information and transaction history in
reasonable amount of time and have separate operation modes for the administrative staff
and students.
1.2. Scope of Project
This software system will be designed to implement the process of fee
management in an institution. The different parts of the system are as follows:
(a) Types of Users: Administrative Staff and Students of the Institution.
(b) Roles of Users:

Role of Admin: The admin of the system will have master access to the
system. He will have full access to the database that will contain fee records
of all students of the institution. He can modify the information in the
database anytime. Only he will have the access to the encryption key that will
allow him the access to important information like transaction history, bank
details and private information of students.

Role of Administrative Staff: Their primary role will be to verify that the
transactions made by students are successful, by matching the transaction IDs
in the generated fee receipts to the transaction history of the fee account of the
institution.

Role of Students: The students will log into the system using their unique
institute email IDs as username and their password. The student will have
access to their own information only that includes transaction history along
with their personal information. The student will select the type of fee to be
paid for ex. Mess Fee, Mess Dues, etc. After that the entire fee payment
process will be automated and the student will just have to enter details into
the payment gateway to complete the fee payment.

(c) System Features:

User Login This will be a one-step login procedure in which the user
will be required to enter his unique user id, his password and his role
[Admin, Staff or Student].

Payment Gateway This will be a either a paid gateway of any suitable

bank or if the service will be unavailable then we would demonstrate the
functioning of the system by simulating this gateway.

Automatic receipt generation After the fee payment will be over, the
receipt of the fee payment will be generated automatically by the system.
In case any exception occurs then failsafe features like forwarding the
SMS that the user receives from the bank to a specified number of
uploading the receipt downloaded from the bank website as a proof of
payment, will be present to ensure the confirmation of fee payment.

Confirmation through e-mail and SMS As soon as the automated receipt

generation is complete a confirmation mail will be sent to the users
registered email and a SMS will be sent to users registered mobile
number. Both of these will help the user to keep record of the payment and
would help the user in confirming the completion of the payment
procedure.

Encryption of personal information of students Our application

maintains a master database in which each student record contains the
students private information along with transaction history. As the
visibility of this database will be different to the user depending on the
user type, sensitive personal information of the student will be encrypted
for security and the encryption key will only be made known to the system
admin. This feature will help in increasing the security of the system and
will prevent the accidental leak of sensitive and private information of
students.

Database that will store students personal information along with the
transaction history that will contain all the receipts generated till now for
record. There will be different levels of access to this database based on
the type of user.

Report Generation: After the process of fee payment is complete for all the
students the system can generate a summary report. The report will

contain details of all the transactions made during the process of academic
registration along with related details. Again different amount of
information will be made available in the report depending on the user
type.

1.3 Constraints

The system will only manage the fees of B.Tech Students.

The application will only run in Windows Desktop and Windows Phone.
A working payment gateway is needed to demonstrate the practical
working of the system else the gateway will have to be simulated.

1.4 Assumptions and Dependencies

The system is dependent on the following assumptions:

The database of registered students will be made available along with the
login details of administrative staff.
The list of dues of each department like mess, library etc. will be made
available.
The fee structure of the academic year will be made available beforehand.
We are assuming access to the payment gateway service of any bank.
The transaction history of the institutions fee account will be made
available to the administrative staff for verification.
The Admin or Administrative staff should not be corrupt. :p

1.3. Glossary
Term

Definition

1.4. References
IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements
Specifications. IEEE Computer Society, 1998.

1.5. Overview of Document

The rest of the document is designed in the following way:

2.0.

Overall Description

2.1

System Environment

<< Keep blank for the time being >>

2.2

Functional Requirements Specification

. << Keep blank for the time being >>

2.2.1 Use case 1

Use case:
Diagram:

Brief Description
Initial Step-By-Step Description

2.3

User Characteristics
The user of this software system requires the following skills to use this software

2.4

Non-Functional Requirements

3.0.

Requirements Specification

3.1

Functional Requirements

3.1.1 User Login

Use Case Name
Trigger
Precondition
Basic Path

Alternative Paths
Postcondition
Exception Paths
Other

User Login
The registered user selects the login button on the login screen.
The user must have a unique user id and password.
1. The user enters his unique user id and password.
2. The user selects his role [Student, Admin or Staff].
3. The user clicks the login button. At this point the login
verification takes place and if all fields are correct then the
user is logged into the system.
None
The user is logged into the fee management system.
1. The user enters incorrect login details.
2. The user abandons the login process in between.
None.

3.1.2 Payment Gateway

Use Case Name
Trigger
Precondition
Basic Path

Alternative Paths
Postcondition

Exception Paths

Other

Fee Payment
The user selects the pay fees button after logging into the system.
The user must be logged into the system and hasnt paid the
respective fee before.
1. After logging into the system the user selects the type of fees
he wants to pay. For ex. Mess, dues, etc.
2. Then the user proceeds to the payment gateway where he
enters valid bank details.
3. After the gateway verification through OTP or any other
means the user clicks the make payment button and the fees is
paid.
None
The selected type of the fees is paid the receipt is generated by
the system automatically. This is followed by the confirmation
email and SMS to the user.
1. The user enters incorrect bank details that results in
interruption at the gateway.
2. The connection is timed out.
3. The user causes a delay and the session expires.
4. The verification step does not take place properly.
5. The user has insufficient balance in his account.
Even if the transaction is unsuccessful the system will generate a
receipt mentioning the status of payment as FAILED.
6

3.1.3 Automatic Receipt Generation

Use Case Name
Trigger
Precondition
Basic Path

Alternative Paths
Postcondition

Exception Paths

Other

Receipt Generation
The user has completed the fee payment.
The user must have completed the fee payment process at the
payment gateway.
1. The user completes the fee payment at the payment gateway.
2. Then the receipt is generated by the system automatically and
is displayed to the user.
None
The confirmation of the fee payment follows the automatic
receipt generation. A confirmation email is sent to the user along
with a SMS. The generated receipt is added to the transaction
records [history] of the user.
1. The user does not complete the fee payment process at the
gateway.
2. An exception occurs and the receipt does not get generated
automatically.
Even if due to some reason the receipt does not gets generated
automatically the user will have the option to confirm his
payment by either uploading the transaction record downloaded
from his bank account or forwarding the transaction message
that the user receives to a predefined mobile number.

3.1.4 Payment Confirmation

Use Case Name
Trigger
Precondition
Basic Path

Alternative Paths
Postcondition

Exception Paths
Other

Payment Confirmation
The automatic receipt generation has taken place.
The user must have completed the fee payment successfully and
the receipt must be generated automatically by the system.
1. The user has completed the fee payment successfully.
2. The automatic receipt generation has taken place.
3. After these steps the confirmation takes place via email and
SMS.
None
A confirmation mail is sent to the users registered email id and
SMS to the users registered mobile number. This receipt is
added to the transaction history of the user where he can view all
his transactions made so far.
1. The registered email id/mobile number is incorrect.
None.

3.1.5 Master Database Query

Use Case Name
Trigger
Precondition
Basic Path

Alternative Paths
Postcondition
Exception Paths
Other

Database Query
The admin is logged into the system and decides to make the
query.
The user must be the admin of the system.
1. The user logs into the system as the admin.
2. After logging into the system the user clicks the view
database button.
3. The user makes the required query after entering the database.
None
The query is served and if any modification has been made then
the database is updated.
1. The query is invalid.
2. The database is empty.
None.

3.1.6 Summary Report Generation

Use Case Name
Trigger
Precondition
Basic Path
Alternative Paths
Postcondition
Exception Paths
Other

3.2

Report Generation
The user [Staff or Admin] clicks the generate report button.
The user must be logged into the system and must be either a
Staff member or the system Admin.
1. The user login into the system.
2. The user selects the generate report button.
None
The generated report is saved onto the users device in a
specified format.
1. The code malfunctions during the report generation.
Different reports will be generated based on whether the user is a
Staff member or the system Admin.

Detailed Non-Functional Requirements

System performance: All system must perform all the mentioned

operations at a reasonable speed so that the user experience is not affected.
Security: The personal information of the students along with other
sensitive information must be hidden from administrative staff and should
only be visible to the system admin. Hence this data must remain in an
encrypted form to increase system security.
Usability: As the system is implemented through a universal app the user
can log into the system both from his mobile and desktop, anywhere.

3.4

Capacity: The system must have the capacity to handle large amount of
student data and should not slow down as the amount of data increases.
Maintainability: The system must be able to modify the stored records so
that any change in the student information that can occur can be
accommodated easily in the student database.

Logical Structure of the Data

<< Keep this blank for the time being>>

4.0 Supporting information

4.1 Table of contents and index
4.2 Appendixes