National college business administration & economics

Department of Computer Science

SOFTWARE REQUIREMENTS
SPECIFICATION
(SRS DOCUMENT)

for
24*7MediCare
Version 1.0
By
Ms. Sajjal Zafar
Ms. Tanzeela Ibtisam
Ms. Qundeel Zahra
Session Fall 2019 – 2023

Supervisor
Mr. Ali Asghar
 Bachelor of Science in Computer Science

Table of Contents
Version 1.0..........................................................................................................................1
Revision History.........................................................................................................................1
Application Evaluation History..................................................................................................2
1. Introduction............................................................................................................................3
1.1 Purpose.................................................................................................................3
1.2 Scope....................................................................................................................3
2. Overall description.................................................................................................................4
2.1 Product perspective...............................................................................................................4
2.2 Operating environment.........................................................................................4
2.3 Design and implementation constraints................................................................4
3. Requirement identifying technique........................................................................................5
3.1.1 Use case diagram For User................................................................................5
Fig 3.1.1 User Use Case Diagram..............................................................................5
3.1.2 Use case diagram For Admin............................................................................6
Fig 3.1.2 Admin Use Case Diagram...........................................................................6
3.2 Use case description For User..............................................................................7
3.3 Use case description For Admin.........................................................................13
TABLE 3.3.1 LOGIN ADMIN CASE DESCRIPTION..........................................13
4. Functional Requirements Of 24*7MediCare........................................................................19
4. 24*7MediCare Functional requirements Tables..................................................20
TABLE 4.1 FUNCTION LOGIN PAGE.................................................................20
TABLE 4.2 FUNCTION LOGIN PAGE.................................................................20
TABLE 4.5 FUNCTION DOCTORS APPOINTMENT.........................................................22
TABLE 4.6 FUNCTION USER REVIEW..............................................................................22
TABLE 4.7 FUNCTION PAYMENT METHOD....................................................................23
5. Non-Functional Requirements..............................................................................................23
6. References............................................................................................................................24
 Revision History
Name Date Reason for changes Version
Comments (by committee) Action Taken
*include the ones given at scope time both in doc and
presentation

Application Evaluation History

Supervisor
Mr. Ali Asghar

Signature
Chapter #1
1. Introduction
We live in a world where technology is constantly changing the way we live. With the
booming app market keeping you in touch with your audience, healthcare as we knew it
has changed forever. Around the world, smartphones are becoming increasingly
popular for medical applications. Increasingly, people use them for everything from
medical care to general health. The healthcare application development boom is evident
in every indicator, which leads to one all-important question. You can keep in touch
with your patients via smartphone apps whether you run a small clinic or a medical
store. You can use it to assure your patients that you are “right by their side. Without an
app, your patients might find another provider for their healthcare or wellness needs.
Having an app for your patients shows them that they're getting everything they need.
You need to make sure that technology is contributing to your business in terms of
healthcare and wellness.
1.1 Purpose
Medicare application is developed according to the needs of users. In this application,
all the functionalities are introduced, makings it helpful to the user. Medicare
Application provides a user-friendly environment. Time and money can be saved by
using this application. Online medical businesses provide more chances for success
when many businesses shift to the Internet at the same time. There is a greater benefit
to this application when users need their medicine urgently and in a short amount of
time. This application is operated in every city from some large pharmacies and
hospitals and provides facilities to the user. When you have a short time to check on
your patient after getting an appointment with a top doctor in your city. This
application is much useful for the user. With this application, you can purchase
medications from your home, school, college, or university.

1.2 Scope
Medicare application is an online mobile app, which provides all the basic facilities that
meet the needs of the user. This application allows you to order lab tests, doctor
appointments, and medicine. You can also get a prescription based on your symptoms 3
that this application will recommend to you. You can decide if you want to order that
medicine at your place. This application saves the user both time and money and fulfills
its requirements.

4
Chapter #2
2. Overall description
2.1 Product perspective
Besides being the next member of a growing product line, this project also represents
the next version of an intelligent system. In the market, multiple online applications are
already available, but it is the upgraded version of those applications. There are many
advanced features included in this application, which make it different from others.
You can use the application to predict diseases and get prescriptions.
2.2 Operating environment
The Medicare Applications are designed for people who wish to access multiple
services from a mobile application while sitting at home or in the office. The mobile
application facilitates patients, doctors, and users that want to buy online medicine at
home and have it delivered with ease and speed. The Medicare mobile application is
user-friendly, "quick to learn," and the best mobile application for e-business. Hosting
the related database on the server. This application is compatible with all Android
versions, but it is more flexible on Android's latest version.
Database: SQLite
An Android mobile with good health should be able to run the application correctly.
1. Android version Marshmallow (6.0) to
2. Tiramisu (OS 13)
2.3 Design and implementation constraints
A Python 3.8 version is used for coding. Python is the language used in coding this
application. We also used the well-known Python frame Kivvy. Application
development uses Kivvy as a front-end user interface. The database that is used in the
application is SQLite DB.
Machine learning is also included in the application, making it an intelligent mobile
app.
Here are some famous Python libraries which are used in the development of machine
learning and intelligence mobile application.
1. NumPy
2. Pandas 5

3. TensorFlow
The payment method also includes a mobile application, For Example, if some
user does not want to pay cash on hand it also prefers online payment method
such as:
EasyPaisa Account and Jazz Cash Account

6
Chapter #3

3.1 Requirement identifying technique

3.1.1 Use case diagram For User

7
 Fig 3.1 User Use Case Diagram

3.1.2 Use case diagram For Admin

8
 Fig 3.2 Admin Use Case Diagram

3.2 Use case description For User

TABLE 3.1 LOGIN USE CASE DESCRIPTON
Use Case ID: UC-1
Use Case Name: Login

Actors: User
Description: It is necessary for every user first sign up and log in to the application.

Trigger: The user indicates that he wishes to see anything and makes use of the features
of the application.
Preconditions: PR-1: First Login is required if user already register.
PR-2: If user is new on application the registration firstly, otherwise cant perform
Anything.
Postconditions: PCT-1: After login user can see the features of the application.
PCT-2: Use the all function which given in application.
PCT-3: Get access to all the services which are provided in application.
Normal Flow: There are following step of all the process.
User enter their username and password.
If it is registered in application all ready.
Else if it is new user firstly it can be registered in the application.
Users can enter the required information on the registration page.
The System verifies the information provided by the user for registration.
Then show the home page of the application.
Exceptions: EC-1: If the user attempts to log in without registering, the error will appear on the
screen.
EC-2: When the user enters incorrect information, the registration process cannot
proceed to the next step.
EC-3: The System verifies the confirmed password or email given by the user
otherwise it will cancel the registration.
Business BR-1: Logging in is required to access the application services.
Rules BR-2: Only accurate information is needed; incorrect information will not
be accepted. 9
Assumptions By failing to register, incorrect information may be provided.
:

10
Use Case ID: UC-2
Use Case Lab Test
Name:
Actors: User
Description: In this step, the user can get a token for a lab test and receive your report online
if you want.
Trigger: Online scheduling for tests actually provides convenience for the user.

Preconditions PR-1: The user can first check the empty blocks of time.
: PR-2: The system can find the most suitable time based on their availability and
fill in the data accordingly.

Postcondition PCT-1: The system will give you a token according to the information the
s: user provides.
PCT-2: The user reached the time specified on the slip provided by the system.
Normal Flow: 1. When the user gets a token, he will go to the lab with the patient for
tests.
2. The patient displays the slip that the system provides to the
administration.
3. After verification of the slip, the technical team will perform the test on
the patient.
4. After that, the lab admin uploads the test report to the application and
sends it physically to the user.
Exceptions: EC-1: If the user tries to select a time that is already allocated to another user,
the system will show an error message.
EC-2: If the user forgets their slip anywhere, they need to show the online slip
from the application.
EC-3: Without payment, the user could not use the lab.
Business BR-1: Ensure your report is not the other patient's report.
Rules BR-2: Clearly define the object of the lab test.
BR-3: Your lab test is totally dependent on the generation of your slip.
Assumptions In the event of a problem, the lab will be closed at that time. However, the
: system will notify you if anything happens. 11
 TABLE 3.2 LOGIN USE CASE DESCRIPTION
TABLE 3.3 LOGIN USE CASE DESCRIPTION
Use Case ID: UC-3
Use Case Name: Medicine Buy
Actors: User
Description: User Can buy medicine from this application online at their home office etc.
Trigger: The user can take orders for medicines using the application at their place.
Preconditions: PR-1: The user can search for their required medicine.
PR-2: He can then choose the medicine he wants to order.

Postconditions: PCT-1: Placed an order, the rider gets it and goes to the order destination.
PCT-2: Also, check the payment status.
PCT-3: Deliver the order to the user after verification.
Normal Flow: 1. The user selects the medicine from the list.
2. If it cannot be found, it will be added to the formula of that medicine.
3. Then show a list of alternative medicines for that.
4. Click on that medicine that meets needs of the user and place
an order.
5. After verification, the order will be accepted by the system.
6. Clarification of the payment method and location of the user should
be clarified.
7. It should be sent to the user via the rider.
Exceptions: EC-1: If the user wants to cancel the order at the time of receiving it, it cannot
be accepted.
EC-2: The user can only update the order within 5 minutes.
EC-3: If the payment method is not verified, the system will display an error.

Business Rules BR-1: For verification, you must make an online payment before receiving the
Order.
BR-2: Orders will be delivered within the time frame specified when the order
is placed.
12
 Assumptions: There may be a mistake that alters the delivery time of the order.

TABLE 3.4 LOGIN USE CASE DESCRIPTION

Use Case ID: UC-4
Use Case Name: Disease Diagnose
Actors: User
Description: User can give some symptoms to the application, and it predicts and it
give prescription according to diseases.
Trigger: Using these features, the user can predict diseases based on their symptoms.
Preconditions: PR-1: The user selects the symptoms of a disease and the next steps will be taken.
PR-2: The system receives the information provided by the user.

Postconditions: PCT-1: The system gives a prescription for the disease after analyzing
the symptoms.
PCT-2: It is the user's choice whether or not to purchase the medicine
recommended by the system.
PCT-3: Depending on the user's action, the system completes the process.
Normal Flow: 1. The user selects the symptoms of two or more from the list.
2. Based on symptoms, the system predicts diseases.
3. As soon as the system receives the necessary information to analyze
the diseases, it will display the results.
4. The user will receive the results in the form of a prescription.
5. The system allows the user to decide if he wants to buy the
medicine online from the application.
6. If the user places an order the system will accept it and give a slip to
the user.
Exceptions: EC-1: The user gives wrong information to the system, which results in the
wrong result.
EC-2: Since the user has selected no alternate symptoms, the system will not
predict are diseases.

Business Rules No Rules Required. 13

 Assumptions: The user cannot be satisfied with the prediction because he does not give
accurate information to the system.

TABLE 3.5 LOGIN USE CASE DESCRIPTION

Use Case ID: UC-
Use Case Name: Doctors Appointment
Actors: User
Description: In This case, the user gets an appointment with the doctors from your home
and office, etc.
Trigger: The user wants to save time from doctors online without going to the doctor.
Preconditions: PR-1: The user selects the doctor after seeing his profile.
PR-2: The system recommends doctors according to the requirements of the user.

Postconditions: PCT-1: The user gets information about the doctor.

PCT-2: The user also checks the time which is given by the doctor.
PCT-3: The message is displayed on their profile along with the time and date
of the appointment.
Normal Flow: 1. The user opens the doctor's profile.
2. Additionally, the user should check the specialization of the physician based
on their specific needs.
3. The system displays the available time of the doctor's block for the selected
date.
4. Users see the time of the block that is displayed by the system.
5. After the user gets a convenient time for the appointment, he or she will post
an appointment with the doctor and receive a slip.
Exceptions: EC-1: If the user does not pay the doctor's fee the appointment will be
canceled.
EC-2: If for any reason, the user cannot change their time without the
system's permission.
EC-3: If the user wants to change their appointment time, the system deducts
his or half fee.
Business Rules BR-1: When the user pays a fee, the fee cannot be refunded if the user cancels
the appointment.
BR-2: If the user gets an appointment personally without the system involving
14
then it cannot be responsible for any convention.
 Assumptions: The doctor if some time is not available at that time the appointment does not
cancel system gives an update time to the user.
TABLE 3.6 LOGIN USE CASE DESCRIPTION
Use Case ID: UC-6
Use Case Name: Payment Method
Actors: User
Description: In this case, the user can payments online like banking jazz cash, etc., and cash
on delivery.
Trigger: The user can use many ways to pay for the service provided by the application.

Preconditions: PR-1: The user can place an order.

PR-2: The system gets confirmed the payment method from the user.
Postconditions: PCT-1: Online payments can be verified by the system before a transaction
is completed.
PCT-2: If the user wants to pay cash when delivery is made, the system
sends information to the admin.
PCT-3: When the order is delivered, the rider can collect the payment.
Normal Flow: 1. The user can check the payment order before placing an order.
2. Users will be able to choose from several payment methods.
3. The user can choose which is more beneficial and easy for him.
4. The system then verifies it and accepts the order.
5. If the system then chooses online payment it will pay within 10 minutes.
6. After system verification, the order will be delivered to the user.
Exceptions: EC-1: When the user pays online payment using jazz cash easy paisa and a bank
account, it will not be recovered if the user wants to pay cash on delivery.
EC-2: Sometimes a payment can not be received by the system due to some
network issue the system can not verify and not update the order status.

Business Rules

Not Required.
Assumptions: Fake payments cannot be accepted without the system's verification.

15
3.3 Use case description For Admin
TABLE 3.7 LOGIN ADMIN CASE DESCRIPTION
Use Case ID: UC-7
Use Case Name: Login Admin Penal
Actors: Admin
Description: In this case, the Login Admin panel is open with the admin login.
Trigger: The admin can control the application from the penal.

Preconditions: PR-1: First Login has required if admin is already register.

PR-2: If admin is new on the application the registration first, otherwise can’
perform any action.

Postconditions: PCT-1: After login, the admin can see the features and records of the application.
PCT-2: Check the all function given in the application.
PCT-3: Get access to all the services and records which are provided in
The application.
Normal Flow: There is the following step of the process.
1. Admin can enter their username and password.
2. If it is registered in the application already.
3. Else if it is a new admin firstly it can be registered in the application.
4. Admin can enter the required information on the registration page.
5. The System verifies the information provided by the admin for registration.
6. Then show the admin penal of the application.
Exceptions: EC-1: If the user attempts to log in without registering, the error will appear
on the screen.
EC-2: When the user enters incorrect information, the registration process
cannot proceed to the next step.
EC-3: The System verifies the confirmed password or email given by the user
otherwise it will cancel the registration.
Business Rules BR-1: Logging in is required to access the admin penal of the application.
BR-2: Only accurate information is needed; incorrect information will not
be accepted.
Assumptions: By failing to register, incorrect information may be provided.
16

TABLE 3.8 LAB RECORD ADMIN CASE DESCRIPTION

Use Case ID: UC-8
Use Case Name: Lab Records
Actors: Admin
Description: In this case, the admin checks and maintain the record of a lab test.
Trigger: Basically, it provides all the information about a laboratory test to the admin.

Preconditions: PR-1: The admin also check the empty blocks of time when lab is free and update
The time of availability.
PR-2: The system can find the most suitable time based on their availability and
fill in the data accordingly to the need of the user.
Postconditions: PCT-1: The system will give a token shown in the database according to the
information the user provides.
PCT-2: The admin checks the time specified on the slip provided by the system.
Normal Flow: The process can be the following flow:
1. When the admin gets a token in the database, he will go to update the lab
record and maintain the time of a block of an application.
2. After verification of the slip, by the admin the system generates a slip.
3. After that, the lab admin uploads the test report to the application and
sends it physically to the user and the admin can also verify it by
contacting to the user.
Exceptions: EC-1: If the user tries to select a time that is already allocated to another user,
the system will show an error message but the admin can update the record
and solve the problem.
EC-2: If the user forgets their slip anywhere, they need to show the online slip
from the application and the admin can verify it.
EC-3: Without payment, the admin could not allow using of the lab.
Business Rules BR-1: Admin ensures the report is not the other patient's report.
BR-2: Clearly define the object of the lab test by the user and the admin can check
it.

Assumptions: If an admin can notice some incontinence in the payment procedure it can stop the
Lab test process.
TABLE 3.9 MEDICINE RECORDE ADMIN CASE DESCRIPTION 17

Use Case ID: UC-9

Use Case Name: Medicine Record
Actors: Admin
Description: In this case, the admin checks the stock and medicine detail from the store.

Trigger: The admin can control the flow of medicine stock inventory.

Preconditions: PR-1: The admin can search for their required delivered medicine.
PR-2: He can then choose the medicine he wants to re-order from the company.

Postconditions: PCT-1: Check information about placing an order, the rider gets it and goes to
The order destination.
PCT-2: Also, check the payment status.
PCT-3: Update the status of delivering the order to the user after verification.
Normal Flow: 1. The admin selects the medicine from the list of sales.
2. Then show a list of medicines that are sealed mostly.
4. Click on the medicine that is less in stock.
5. After verification, the order will be purchasing the new stock.
6. It should be sent to the store via company transport.
Exceptions: EC-1: If the admin wants to cancel the order at the time of receiving it, it can
be accepted.
EC-2: The admin can only update the order within 20 minutes.
EC-3: If the payment method is not verified, the admin will reject the order.
Business Rules BR-1: For verification, you must make an online payment before receiving the
Order.
BR-2: Orders will be delivered within the time frame specified when the order
is placed.
Assumptions: There may be a mistake that alters the delivery time of the order.

18
TABLE 3.10 DOCTORS APPOINTMENT ADMIN CASE DESCRIPTION
Use Case ID: UC-10
Use Case Name: Doctors Appointment
Actors: Admin
Description: In this case, the admin also checks the record about the doctor like name,
address, and specialization.
Trigger: The can hold the record of all doctors which are linked in the application

Preconditions: PR-1: The admin selects the doctor after seeing his profile is it the right person
or not.
PR-2: The system recommends doctors according to the requirements of the
admin.
Postconditions: PCT-1: The admin gets information about the doctor.
PCT-2: The admin also checks the time which is given by the doctor to the user.

Normal Flow: 1. The admin opens the doctor's profile.

2. Additionally, the admin should check the specialization of the
physician based on the specific needs of the user.
3. The admin also checks the available time of the doctor's block for the
selected date.
4. Admin sees the time of the block that is displayed by the system.
5. After the user gets a convenient time for the appointment, the admin will
post an appointment with the doctor.
Exceptions: EC-1: If the admin does not pay the doctor's fee the appointment will be
canceled.
EC-2: If for any reason, the admin cannot change their time without the
doctor’s permission.
EC-3: If the admin wants to change their appointment time, the doctor
deducts his or half fee.
Business Rules BR-1: When the user pays a fee, the fee cannot be refunded if the user cancels
the appointment.
BR-2: If the user gets an appointment personally without the system involved
then it cannot be responsible for any convention.
19
 Assumptions: The doctor if some time is not available at that time the appointment does not
cancel system gives an update time to the user.

TABLE 3.11 ORDERS DETAILS ADMIN CASE DESCRIPTION

Use Case ID: UC-11
Use Case Name: Orders Details
Actors: Admin
Description: In that case, the admin can check details about the order or other service which
is done by the application.
Trigger: The admin can check the all details about the order placement.

Preconditions: PR-1: First admin can check the status of the order.
PR-2: if the order is accepted by the system then the system can send its details to
The database

Postconditions: PCT-1: The admin clears the status of the order.

PCT-2: The admin also updates the inventory of stock when the order is delivered.
Normal Flow: The medicine of order flow is that:
1. The admin selects the medicine from the list of sales.
2. Then show a list of medicines that are sealed mostly.
4. Click on the medicine that is less in stock.
5. After verification, the order will be purchasing the new stock.
6. It should be sent to the store via company transport.
Exceptions: EC-1: If the admin wants to cancel the order at the time of receiving it, it can
be accepted.
EC-2: The admin can only update the order within 20 minutes.
EC-3: If the payment method is not verified, the admin will reject the order.
Business Rules

Not Required
Assumptions: The Order will not be delivered to the customer due to some reason.

20
TABLE 3.12 PAYMENT VERIFICATION ADMIN CASE DESCRIPTION
Use Case ID: UC-12
Use Case Name: Payment Verification
Actors: Admin
Description: In this case, the admin can check payments online like banking jazz cash
Account, etc., and cash on delivery by the rider.
Trigger: The admin can use many ways to verify payment for the service provided by the
user.

Preconditions: PR-1: First Login is required for access to account details.

PR-2: Then check the payment status of the order.

Postconditions: PCT-1: Online payments can be verified by the system before a transaction
is completed.
PCT-2: If the user wants to pay cash when delivery is made, the system
sends information to the admin.
PCT-3: When the order is delivered, the rider can collect the payment and send
Message to the admin.
Normal Flow: 1. The admin can check the payment order before placing an order.
2. Admin will be able to choose from several payment methods for the user.
3. The admin can choose which is more beneficial and easy for him.
4. The system then verifies it and accepts the order.
5. If the system then chooses online payment it will pay within 10 minutes.
6. After system verification, the order will be delivered to the user.
Exceptions: EC-1: When the admin checks online payment using jazz cash easy paisa and
a bank account, he can update the status of the order.
EC-2: Sometimes a payment can’t be received by the system due to some
network issue the system cannot verify and not update the order status.

Business Rules

Not Required
Assumptions: Fake payments cannot be accepted without the system's verification.

21
Chapter #4

Functional Requirements Of 24*7MediCare

1.1Requirements 22

1) Login Page
 The login page is the first page on which a user logs in to the application or signs up
if he is a new user. It is mandatory for all new or existing users of the application.
2) Lab Test
As soon as the user logs into the application, the first thing he sees is that lab tests
are recorded and he is given a token number for each test.
3) Medicine Buy
With this feature, you can order and purchase medicine at any time, and you can
change the required medicine as well.
4) Diseases Diagnose
Machine learning is used in it to make it more intelligent, and this allows for
accurate prediction according to the user's requirements.
5) Doctors Appointment
This feature provides the facility of setting up appointments with doctors using the
Medicare application.
6) User Review
User reviews play a vital role in the success of a project. We can change the system
according to feedback.
7) Payment Method
This feature allows the user to make payments using online payment and cash on
hand.

4.2 24*7MediCare Functional requirements Tables

TABLE 4.1 FUNCTION LOGIN PAGE
Identifier UC-1
Title Login

23
Requirement Users can log in to open the home page of the application, and the
system gets information about users.

From a user perspective

The user can give login and signup information in this case.

From a system perspective

The System also checks the required information which is given from
the user side.
Source This comes from the user side of the system.
Rationale The purpose is to check the traffic on the application.
Business Rule (if It is necessary.
required)
Dependencies All the features depend on it.
Priority Have high priority

TABLE 4.2 FUNCTION LOGIN PAGE

Identifier UC-2
Title Lab Test
Requirement After login users can access these features and get facilities about lab tests.
From a user perspective
The user can give detail about the test and their token number.
From a system perspective
The System also checks the required information which is given by the user
Side and maintain & update the records from the database.

Source This comes from the user side of the system.

Rationale The purpose is to maintain the records of a lab test.
Business Rule (if The user can send only original detail about the test.
required)
Dependencies It depends on UC-1.
Priority Have medium priority

24
 TABLE 4.3 FUNCTION MEDICINE BUY
Identifier UC-3
Title Medicine Buy
Requirement Users can use this function to order medicine at their homes and office
etc.

From a user perspective

The user can select medicine according to their need and place an order.

From a system perspective

The System can receive the given order detail of medicine and update
the stock.
Source This comes from the user side of the system.
Rationale The purpose is to maintain the medicine stock and order detail.
Business Rule (if If an order is accepted and delivery is on the way the order can be
required) canceled.
Dependencies It will depend on UC-1
Priority Have medium priority

TABLE 4.4 FUNCTION DISEASE DIAGNOSE

Identifier UC-4
Title Disease Diagnose
Requirement User can diagnose their disease using these features after providing some
Symptoms.
From a user perspective
The user can give symptoms to the system 2 or more.
From a system perspective
The System can predict the diseases through symptoms using a machine
Learning.

Source This comes from the user side of the system.

Rationale The purpose is to provide the facility of predicting disease using Ml.
Business Rule(if Not Required
required) 25
Dependencies It depends on UC-1.
Priority Have medium priority

TABLE 4.5 FUNCTION DOCTORS APPOINTMENT

Identifier UC-5
Title Doctors Appointment
Requirement Users can search for doctors according to their needs getting
appointments.

From a user perspective

User can select doctors and their appointment numbers.

From a system perspective

The System also stored several appointments according to the user.

Source This comes from the user side of the system.
Rationale The purpose is to check the appointments of doctors.
Business Rule (if Not Required
required)
Dependencies It depends on UC-1
Priority Have medium priority

TABLE 4.6 FUNCTION USER REVIEW

Identifier UC-6
Title User Review
Requirement Users can send feedback on the application to the admin.

From a user perspective

Users can do remarks on the application’s performance.

From a system perspective

The System also stored the feedback for the admin to take decisions
about application modification.
Source This comes from the user side of the system.
Rationale The purpose is to check the performance of the system.
26
Business Rule (if Not Required
required)
Dependencies It depends on UC-1
Priority Have medium priority

TABLE 4.7 FUNCTION PAYMENT METHOD

Identifier UC-7
Title Payment Method
Requirement Users can select a payment method when placing an order.

From a user perspective

Users can select online payment or cash on delivery.

From a system perspective

The System also verifies whether the payment is successfully done or

not.
Source This comes from the user side of the system.
Rationale The purpose is to make the payment method easier.
Business Rule (if Not Required
required)
Dependencies It depends on UC-1
Priority Have medium priority

27
Chapter #5
5. Non-Functional Requirements
5.1 Usability
5.1.1 Security
1. Secure from Hacker
2. Secure from google adds
3. All transactions must be stored securely.
4. Physical storage locations of the data for transactions must be secure.
5. All information gained from the end-users that are processed must be kept
secure.
5.2 Performance
1. To maintain an acceptable speed at the maximum number of uploads allowed
from a particular customer.
2. as any number of users can access to the system at any time.
3. Based on the internet speed of the user
5.2.1 Reliability:
In case, if the system crashes the total data will be saved from the crash and uploaded to
the app server.
5.2.2 Availability:
The system should be available during normal operations.

5.2.3 Maintainability:

Administrators will have the ability to edit aspects of the order forms, product
descriptions, prices, and many other operations directly.

5.2.4 Efficiency:
Page loads should be returned and formatted in a timely fashion depending on the
request being made.

28
Chapter #6

6. References
[1] https://crackreview.com/microsoft-visio-2013/
[2] https://scholar.google.com/
[3] https://github.com/
[4] https://pypi.org/
[5] https://docs.python.org/3/installing/index.html
[6] https://pandas.pydata.org/

29