Process Model and Functionality
Process Model and Functionality
Requirements
Defination
System And
Software Design
Implementation
And Unit
Testing
Integration And
System Testing
Integration And
System Testing
The system shall allow Pharmacy and sales person to create user accounts that they can use to
authenticate to the system. Other users created and control by administer using they roll.
2. Order products
• Description
Once the pharmacy or seals person is successfully logged in there Requisition Form (Requested
by, sales person, license number, Description, unit of measurement, Quantity). State all the fields
one by one and click submit to order the products.
When the pharmacy or seals person successful order the admin and approver person get new
notification new order and the approver person check the pharmacy previous debt and approve the
new order based on debt.
When the casher finish Cash sales attachment Invoice or credit sales attachment Invoice pass to
store and the order product deliver on time to the pharmacy
Non-Functional Requirements
Security: - Every information shared with the Users should be secure and hidden from other
user via logging in with credentials made for a single user.
: - Only direct managers can see personnel records of staff
Safe: - Information shared on this website should only be written by professionals and well-made
researches
Usability: - Any familiar in using web operation can operate the system since it has a user-
friendly user interface. Which have the instruction menu’s that shows how to create an account
upload picture, make a purchase and more?
Reliability: - This e-commerce market place is available based on the user needs, can work
properly, and do transactions efficiently including safe data management of the pharmacy. For
invalid and malfunctioned operation the system will restart in order to prevent data loss as well as
she operation within few seconds
Performance: -This system operates in a small amount of time, and can be accessed by
multiple users at the same time.
Scenarios
As-is scenario
Purpose of scenario: Describes the aspect of the system and its interaction with
the user.
Registration and authentication:
Mr. X wants to use the system for the first time. First user opens the website when the web page
appear the login page will first show on the screen. Mr. X will be asked to provide user name and
password to authentication to the web system. Since this is the first time Mr. X does not have a
user for authentication. Mr. X click ‘register’ and gets redirected to the registration page. Once
the registration page opens the Mr. X will be asked for pharmacy name, pharmacy License
number, Address, Email, Phone number, Tin number & password Mr. X will state all the asked
fields one by one. After Mr. X is done the information will be recorded and user will be
redirected back to the login page. Mr. X will state registered pharmacy name and password for
authentication.
FOR ORDER
Once Mr. X is successful logged in he/she be redirected to the dashboard which contains
Requisition Form like Requested by, sales person, license number, Description, unit of
Measurement . , Quantity. Mr. X state all the fields one by one and click submit to order the
products.
STORE
When the casher finish Cash sales attachment Invoice or credit sales attachment Invoice pass to
store and the order product deliver on time to the pharmacy
A use case model is comprised of one or more use case diagrams and any supporting
documentation such as use case specifications and actor definition. An actor is a person,
organization, or external system that plays a role in one or more interactions with your system.
Admin,
Sales Person (Pharmacy),
Approver
Store
Figure 2: UML Diagram
ACTORS: ADMIN
FLOW OF EVENT:
1 The Admin initiates the system.
2 The system displays the first page.
3 The first page consists of menu’s new orders, medicine Add, Delete, Update, Notification for
expire products, generate reports.
4 Admin manage users Add, Delete and Update pharmacy, Sales, Casher, Store, Approver
roles
ACTORS: PHARMACYS
FLOW OF EVENT:
1 The pharmacy initiates the system.
2 The system displays the first page.
3 The first page consists of Requisition For Pharmaceuticals orders form.
4 The form contains Requested by, License No, Sales Person after that select medicines, Unit
of Msr. & Quantity.
5 Click Submit the system notified Successful ordered.
ACTORS: SALES MAN
FLOW OF EVENT:
1 The pharmacy initiates the system.
2 The system displays the first page.
3 The first page consists of Requisition For Pharmaceuticals orders form.
4 The form contains Requested by, License No, Sales Person after that select medicines, Unit of
Msr. & Quantity.
5 Click Submit the system notified Successful ordered.
ACTORS: APPROVER
FLOW OF EVENT:
1 The approver person initiates the system
2 The system displays the first page.
3 The first page consists of getting new orders
4 The Approver checks the pharmacy have a previous debt.
If it yes he/she doesn’t approve that product order
5 Else the approver pass that order to casher.
ACTORS: STORE
FLOW OF EVENT:
1 The store initiates the system.
2 The system displays the first page.
3 The first page consists of the approved order product form.
4 Then deliver the orders products to the destination pharmacy include in Cash sales
5 attachment Invoice or credit sales attachment Invoice
Conceptual Database Design
1, Admin
Field Name Data type Field Length Relationships Description
ID num 11 pm
Name Varchar 255 Not null
Email Varchar 255 Not null
Password Varchar 255 Not null
Roll Type Varchar 255 Foreign key Type of the user.
phone Varchar 10 Not null
avatar Varchar
2, Pharmacy
Field Name Data type Field Length Relationships Description
License_no int 11 PM
Name(Requested By) Varchar 255 Not null
Salesman_id Varchar 255 Not null
Description Varchar 500 Not Null
Unit Not null
Qty Varchar 255 Not null Type of the user.
Credit Varchar Not null
Cash Varchar Not null
date date Not null
3, SalesMan
Field Name Data type Field Length Relationships Description
S_ID num 11 pm
Name varchar 255 Not null
Email Varchar 255 Not null
Password Varchar 255 Not null
Roll_Type Varchar 255 Foreign key Type of the user.
Phone Varchar Not null
Avater Varchar Not null
4, cashier
Filed Name Data type Field Length Relationships
C_ID Num 11 PK
Name Varchar 255 Not null
Email 255 Not null
Password 200 Not null
Roll_Type 50 Foreign key
Phone Not null
Avater Not null
5, store
Filed Name Data type Field Length Relationships
batchNo Num 11 PK
ManufacturingDate Date Not null
ExpiryDate Date Not null
Quantity Varchar Not null
DateofEntry Date Not null
6, ROLL
Field Name Data type Field Length Relationships Description
R_ID num 11 PK
Roll_Type Varchar 255 Not null
7, order
Field Name Data type Field Length Relationships Description
Id Num 11 PK
License_no Varchar Foreign key
Quantity Num
pid Num
Created_at Date
Updated_at Date
8, Drug
Field Name Data type Field Length Relationships Description
DrugID PK
Drug_name Varchar
No_of-
unit_in_pakage
Manfacturer
UnitPrice
9, sales
Field Name Data type Field Length Relationships Description
Sales_id Num 11 PK
Drug_name Varchar Not null
Quantity Varchar Not null
price Varchar Not null
Total Varchar Not null
Sale_date Date Not null
10, Sale Invoice
Field name Data type Field Length Relationships Description
saleinvoiceID num 11 PK
Date date Not null
totalAmount Varchar Not null
payedAmount Varchar Not null
RemainigAmount Varchar Not null
Payment_Type Varchar Not null