1.
Introduction
1.1 Purpose
The purpose of this document is to describe the design and implementation of an e-payment
system for the students of a university to getting a document.It explains the purpose and
features of the application, the interface through which a student can access a personal
account and the constraints that must be satisfied for security purposes.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 Document Conventions
This document will use IEEE format. The document uses the following conventions.
Short Form Abbreviation
DB Database
CRC Class Relationship Collaboration
DFD Data Flow Diagram
ER Entity Relationship
1.3 Intended Audience and Reading Suggestions
This Software Requirements Specification (SRS) is intended for several audiences, including
the project manager as well as the designers, developers and testers.
● The project managers of the developer team will use this SRS to plan milestones and
a delivery date, and ensure that the developing team is on track during development of
the system.
● The designers will use this SRS as a basis for creating the system’s design. The
designers will continually refer back to this SRS to ensure that the system they are
designing will fulfil the customer’s needs.
● The developers will use this SRS as a basis for developing the system’s functionality.
The developers will link the requirements defined in this SRS to the software they
create to ensure that they have created software that will fulfil all of the customer’s
documented requirements.
● The testers will use this SRS to derive test plans and test cases for each documented
requirement. When portions of the software are complete, the testers will run their
tests on that software to ensure that the software fulfils the requirements documented
in this SRS.
1.4 Product Scope
We know that the traditional method of payment for taking a document is quite troublesome.
There are several students who use bank payment process, but this is a time-consuming
process.There are many students who don't take their semester grade sheet because of the
manual payment system and they don't know where to improve for better result.Similar
problem arise when student want to get transcript, certificate, library card and medical card.
So, the purpose of the e-payment system is to ease the payment system and to create a
convenient and easy-to-use web application for students. It is very easy to make a payment
for a document.Students also see payment details.
System will calculate the payable amount according to the taking document.Students can pay
money online by some payment method like MasterCard, Visa, bKash, DBBL,...etc.
2. Overall Description
2.1 Domain Analysis
● Technical Research: From past experience we have seen that a university student has
to pay manually for a document which is a very time consuming matter. Manually a
student has to go to a particular building to collect a document and collect a form then
after depositing money in the bank he has to go to that building again and submit the
form so that he can apply. He has to go to the designated building again and again to
check when he will get the document.That’s why many problems arise in the manual
payment system for getting a document.
● Existing Application: In the circumstances of our university, this system does not
exist.
In my proposed system I would like to create a web interface or application through
which students can collect any document through online payment without any
hassle.The features of my application are:
1. Student, Administrative Staff, Admin authentication.
2. Students will be able to apply for any semester's marksheet and pay the
application cost online.
3. Students will be able to apply for a transcript and pay the application costs
online.
4. Students will be able to apply for a main/provisional certificate and pay the
application costs online.
5. Students will be able to apply for medium of instruction and pay the
application costs online.
6. Students will be able to apply for a medical card and pay the application costs
online.
7. Students will be able to apply for a library card and pay the application costs
online.
8. Students will be able to apply for an ID card and pay the application costs
online.
9. Students can pay the library fine.
10. Students can pay the semester fee.
11. Students can select the delivery type of the document (Normal/Urgent).
● Potential Customer Identify: Students are the main customers of our system and
they will use this system to take documents.
2.2 Product Features and Prioritisation
1.Normal Requirement: Normal requirement consists of objectives, goals, minimal function
and performance that are stated during the meeting with students. The normal requirement of
our project are:
● Student, Administrative Staff, Admin authentication.
● Students will be able to select the document they want to take ● Students will be able
to pay through an integrated payment gateway.
● Students will be able to see their payment receipt.
● Students can choose the type of document delivery.
● Students will be able to search payment receipts.
● Once the documents are ready, students will receive a notification via email.
2.Expected Requirement: Expected requirement consists of implicit requirements and may
be so fundamental that the student does not explicitly state them. Their absence will be a
cause of dissatisfaction. The expected requirement of our project are:
● Accessible via the internet.
● Student, Administrative Staff, Admin register.
● Student, Administrative Staff, Admin log in.
● Student, Administrative Staff, Admin log out.
● Maintain a database of e-payment systems.
● Change user password.
● Make and cancel payment option.
● Provide appropriate error messages.
3. Exciting Requirement: These requirements are for features that go beyond the student’s
expectation and prove to be very satisfying when present. The exciting requirement of our
project are:
● Offer to log in with a mobile phone.
● Offer to find the building location from where documents can be collected.
● Offer to get notification for confirmation message.
● Help Centre.
● Providing security.
2.3 User Story
As a student user he/she can authenticate in our system by creating an account.If he/she
already has an account then he/she will log in the system with his/her email and
password.He/She can pay for a particular document and get receipt of this.When document is
ready he/she is notified via email.
As an administrative staff user can authenticate in our system by creating an account.If they
already have an account then they will log in the system with their email and password.They
will be able to see what kind of document the students want and will be able to respond to
them accordingly.
As an admin user he/she can log in his/her account and see all the information of students
payment, administrative staff's response.
2.4 Stakeholders
Stakeholder refers to any person or group who will be affected by the system directly or
indirectly. The possible internal stakeholders of e-payment application are:
.
Administrative Staff: Administrative Staff can easily use this application.They will be a big
part of our system
System Operator: He will be able to interact with the software directly.
Developers: We can take developers as stakeholders because the system will be updated day
by day and if there is any system interruption, they will find the problem and try to solve it.
The possible external stakeholders of doctor appointment application:
Student: Mainly the software will be made for the student. They can easily pay their payment
for a document.
2.5 Operating Environment
The online payment system is basically web based application apps.
● Windows
● Mac OS
● Linux
● Android Mobile
● iOS
2.6 Actors and Goals
Actors Goals
Admin Add document information from
administrative staff and monitor the system.
Student Easily can pay for the document.
Administrative Staff Can see students' payment information and
which type of document they want.
2.7 Design and Implementation Constraints
Front End:
● HTML
● CSS
● Javascript
● Bootstrap
Back End:
● Python
● Django
Database:
● SQLite
2.8 User Documentation
Along with the software product, a user manual would be written to help people understand
the working methodology and usage of the developed prototype system.
2.9 Assumptions and Dependencies
It is assumed that the user is familiar with an internet browser and also familiar with handling
the keyboard and mouse. Since the application is a web based application there is a need for
the internet browser. It will be assumed that the users will possess decent internet
connectivity
Use Case Description: In this section use case scenarios of the above features are described
elaborately.
Use Case Name: Sign up
Primary Actor: Students, Administrative Staff, Admin.
Goal in Context: To register in the system.
Precondition:
● The e-payment system has been designed to add students, administrative staff and
admin.
● It has an interface for registration.
Triggers: The students, administrative staff and admin have to register.
Scenario:
● Visit the register page.
● Input required information
● Check availability for email and check validity of password.
● Email sent to the user's email address.
● User confirms from his/her email address.
● Confirmation messages are shown.
Exception:
● Invalid Input.
● Not valid for Registration ● Authentication failed.
Priority: Must be implemented.
When Available: At the first time of registration.
Use Case Name: Sign In
Primary Actor: Students, Administrative Staff, Admin.
Goal in context: When users want to enter the system.
Precondition: Must be registered.
Triggers: Need to log in the system.
Scenario:
● Visit the login page.
● Input Email and Password.
● Proceed to the next activity.
Exception:
● Email address invalid. ● Wrong Password.
Priority: Must be implemented.
When Available: First implemented and after log out for the system.
Use Case Name: Sign out
Primary Actor: Students, Administrative Staff, Admin.
Goal in Context: To exit from the system.
Precondition: Must be logged in.
Triggers: The Students, Administrative Staff, Admin have to logout.
Scenario: Tap the logout button.
Priority: Must be implemented.
When Available: First increment.
Use Case Name: Request for a document.
Primary Actor: Students.
Goal in Context: To get a document from the system.
Precondition: Must be logged in.
Triggers: The Students can request for a document.
Scenario: Tap the Apply button.
Priority: Must be implemented.
When Available: First increment.
Use Case Name: Request for payment
Primary Actor: Students.
Goal in Context: Payment can be done for the document.
Precondition:
● Must be logged in.
● Must complete the information of the students. ● Must select the delivery type.
Triggers: The Students can pay for the document..
Scenario: Tap the pay now button.
Priority: Must be implemented.
When Available: First increment.
Use Case Name: Request for cancellation of payment.
Primary Actor: Students.
Goal in Context: Payment Cancellation.
Precondition:
● Must be logged in.
● Must complete the information of the students.
Triggers: The Students can cancel pay for the document..
Scenario: Tap the cancel button.
Priority: Must be implemented.
When Available: First increment.
Use Case Name: Request for searching payment receipt.
Primary Actor: Students.
Goal in Context: Search Payment Receipt.
Precondition:
● Must be logged in.
● Must enter the information of the payment
Triggers: The Students can search payment receipts..
Scenario: Tap the Search Payment Receipt button.
Priority: Must be implemented.
When Available: First increment.
Use Case Name: Request for support.
Primary Actor: Students.
Goal in Context: Get help from the administrative staff.
Precondition:
● Enter the system Triggers: The Students get support..
Scenario: Tap the support button.
Priority: Must be implemented.
When Available: First increment.
