0% found this document useful (0 votes)
283 views6 pages

Token Management System

The document provides a software requirements specification for a hall token management system with the following key points: 1) It describes the purpose of creating a web application to allow students to easily pay for and get meal tokens without long queues. 2) It outlines the intended audiences of the document, conventions, product scope, and features including student authentication, online payment, token purchase history, and notifications. 3) Stakeholders are identified as students, administrative staff, and an admin who can view payments and monitor the system. The system will be web-based and use common programming languages and a MySQL database.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
283 views6 pages

Token Management System

The document provides a software requirements specification for a hall token management system with the following key points: 1) It describes the purpose of creating a web application to allow students to easily pay for and get meal tokens without long queues. 2) It outlines the intended audiences of the document, conventions, product scope, and features including student authentication, online payment, token purchase history, and notifications. 3) Stakeholders are identified as students, administrative staff, and an admin who can view payments and monitor the system. The system will be web-based and use common programming languages and a MySQL database.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Software Requirements

Specification

for

Hall Token Management System

Version 1.0

Prepared By

Sumaiya Sadia Bristy

Dept. of CSE, Jashore University of Science and Technology

Submission Date:

07.04.2022
1. Introduction

1.1 Purpose
The purpose of this document is to describe the design and implementation of a hall token
management system for the students of a university to getting everyday meal token easily, it
handles long queues with ease. It explains the purpose and features of the application, the
interface through which a student can get their meal token without any hassle. Thereby
reducing the strain of handling a large crowd and also gives the option of making the waiting
area noise free. The system will decrease customer wait times and improve services
efficiency & revenues with advanced token management system.

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 manual token system is quite troublesome. Many students who have to
stand in a line to pay and collect token in this process, but this is a time-consuming
process.There are many students who have to suffer for collecting tokens because of the
manual payment system and they don't know how to improve this system.
So, the purpose of the hall token management system is to ease the payment and getting
token and to create a convenient and easy-to-use web application for students. It is very easy
to make a payment and collecting token.Students also see payment and token history.

System will calculate the payable amount according to the taking token.Students can pay
money online by some payment method like bKash, Rocket...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 token which is a very time consuming matter. Manually a student has to go in
hall office to a particular room to pay and collect a token for their meal.Many students who
have to stand in a line to pay and collect token in this process, but this is a time-consuming
process.There are many students who have to suffer for collecting tokens because of the
manual payment system and they don't know how to improve this system. That’s why many
problems arise in the manual payment system for collecting token.

● 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 their token through online payment without any hassle.
The features of my application are:

1. Student Student, Administrative Staff, Admin authentication.


2. Student will able to pay for meals through a payment gateway
3. Student will able to see their payment transaction.
4. Student will able to buy token for lunch/dinner.
5. Student will able to see their previous meal history,
6. Student will able to see their total amount of meal brought in a month.
7. Student will be notified if they pay for their next meal.
8. Student will be able to see their monthly cost for consumed meal.
● Potential Customer Identify: Students are the main customers of our system and
they will use this system to b and collect token.

2.2 Product Features and Prioritization

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 pay for meals through a payment gateway.
● Students will be able to see their payment receipt.
● Students will be able to buy token(s) for lunch/dinner (not more than 4 tokens at a
day).
● Students will be able to see their previous meal history.
● Students will be able to see their total amount of meal bought in a month.
● Students will be notified if she/he has pay for her next meal.

● Student will be able to see their monthly cost for consumed meal.

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 token-management systems.
● Change user password.
● Make and cancel token option.

● Provide appropriate error messages in the system.

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 and take for a particular token and get receipt of this.When
document is ready he/she is notified via massage.

As an administrative staff user can authenticate in our system by creating an account.If they
already have an account then they can log in the system with their email and password.

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 hall token management system application
are:
.
Administrative Staff: Administrative Staff can easily use this application. They will be a big
part of our system
System Operator: He/she will be able to interact with the software directly and can
authenticate user details.
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.

Student: Mainly the software will be made for the student. They can easily collect and pay
for their token.

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 and buy token.

Administrative Staff Can see students' payment information and


their token.

2.7 Design and Implementation Constraints


Front End:
● HTML
● CSS
● Java script
● Bootstrap

Back End:
● Python
● Django

Database:
● MySQL

You might also like