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

i
 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 ID’s
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 ID’s 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.

1
(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 user’s
registered email and a SMS will be sent to user’s 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
student’s 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

2
 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 institution’s 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.

3
1.5. Overview of Document

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

4
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

5
3.0. Requirements Specification
3.1 Functional Requirements

3.1.1 User Login

Use Case Name User Login
Trigger The registered user selects the login button on the login screen.
Precondition The user must have a unique user id and password.
Basic Path 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.
Alternative Paths None
Postcondition The user is logged into the fee management system.
Exception Paths 1. The user enters incorrect login details.
2. The user abandons the login process in between.
Other None.

3.1.2 Payment Gateway

Use Case Name Fee Payment
Trigger The user selects the pay fees button after logging into the system.
Precondition The user must be logged into the system and hasn’t paid the
respective fee before.
Basic Path 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.
Alternative Paths None
Postcondition 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.
Exception Paths 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.
Other 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 Receipt Generation
Trigger The user has completed the fee payment.
Precondition The user must have completed the fee payment process at the
payment gateway.
Basic Path 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.
Alternative Paths None
Postcondition 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.
Exception Paths 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.
Other 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 Payment Confirmation
Trigger The automatic receipt generation has taken place.
Precondition The user must have completed the fee payment successfully and
the receipt must be generated automatically by the system.
Basic Path 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.
Alternative Paths None
Postcondition A confirmation mail is sent to the user’s registered email id and
SMS to the user’s registered mobile number. This receipt is
added to the transaction history of the user where he can view all
his transactions made so far.
Exception Paths 1. The registered email id/mobile number is incorrect.
Other None.

7
3.1.5 Master Database Query
Use Case Name Database Query
Trigger The admin is logged into the system and decides to make the
query.
Precondition The user must be the admin of the system.
Basic Path 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.
Alternative Paths None
Postcondition The query is served and if any modification has been made then
the database is updated.
Exception Paths 1. The query is invalid.
2. The database is empty.
Other None.

3.1.6 Summary Report Generation

Use Case Name Report Generation
Trigger The user [Staff or Admin] clicks the generate report button.
Precondition The user must be logged into the system and must be either a
Staff member or the system Admin.
Basic Path 1. The user login into the system.
2. The user selects the generate report button.
Alternative Paths None
Postcondition The generated report is saved onto the user’s device in a
specified format.
Exception Paths 1. The code malfunctions during the report generation.
Other Different reports will be generated based on whether the user is a
Staff member or the system Admin.

3.2 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.

8
  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.

3.4 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