Systematic Drug Store

MUHAMMAD HAROON MUNIR

Roll No. M2MA05
Haroonmunir40@gmail.com

Advisor:
Dr. Nadeem Akhtar
11 March, 2019

Department of Computer Science & Information Technology

THE ISLAMIA UNIVERSITY OF BAHAWALPUR

Systematic Drug Store

Acknowledgement
All praise is to ALLAH, who created the universe and appointed the man as His vicegerent. I offer my
humble thanks to ALLAH who blessed and enabled me to complete this dissertation in the predetermined
time frame. All respects for the Holly Prophet (Peace Be Upon Him) who recognized us to our creator.

No volume of words is enough to my deep and sincere gratitude to my project Supervisor Dr.Nadeem
Akhtar, Assistant Professor, DCS & IT, The Islamia University of Bahawalpur, who has been helpful me
to explore this vast topic in an organized manner and provided me with all the ideas on Clinic
Management System. He encourages me how to work towards a project, without his devoted interest,
valuable attention and continuous encouragement it is not possible for me to complete work in time. He
gave positive approach in every matter even in unfavorable and odd situations shaped patience in me.

.
Most importantly, I would oblige a great depth of thankfulness to my loving parents for their prayers,
love, care and continuous encouragement. Their realistic love shows me right direction out of blue. I must
also thanks to all my family members and friends for their prayers and moral support which enable me to
achieve the desired destination.

Muhammad Haroon Munir

Project Document Page 1 of 51 03/14/19 f

Systematic Drug Store

Table of Contents
Chapter1 .................................................................................................................................................................... 5-6
Introduction .............................................................................................................................................................. 5-6
1.1 Purpose .................................................................................................................................................... 5-7
1.2 Scope ........................................................................................................................................................ 5-7
1.3 Definitions, Acronyms, and Abbreviations. .............................................................................................. 5-7
1.4 References ................................................................................................................................................ 5-7
1.5 Overview .................................................................................................................................................. 5-8
1.6 Product Perspective ................................................................................................................................. 5-8
1.6.1 System Interfaces ............................................................................................................................ 5-8
1.6.2 Interfaces ......................................................................................................................................... 5-8
1.6.3 Hardware Interfaces ........................................................................................................................ 5-9
1.6.4 Software Interfaces ........................................................................................................................ 5-10
1.6.5 Communications Interfaces ........................................................................................................... 5-10
1.6.6 Microsoft SQL Server ................................................................................................................... 5-10
1.6.7 Operations ..................................................................................................................................... 5-10
1.6.8 Site Adaptation Requirements ....................................................................................................... 5-11
1.7 Product Functions .................................................................................................................................. 5-11
1.8 User Characteristics .............................................................................................................................. 5-11
1.9 Constraints ............................................................................................................................................. 5-12
1.10 Assumptions and Dependencies ............................................................................................................. 5-12
Chapter2 .................................................................................................................................................................. 5-13
Software Requirements Specification .................................................................................................................... 5-13
2.1 Specific Requirements ............................................................................................................................ 5-14
2.2 Functions................................................................................................................................................ 5-14
2.3 Functional Requirements ....................................................................................................................... 5-14
2.4 Item Sale................................................................................................................................................. 5-14
2.4.1 Introduction ................................................................................................................................... 5-14
2.4.2 Inputs ............................................................................................................................................. 5-15
2.4.3 Processing...................................................................................................................................... 5-15
2.4.4 Outputs .......................................................................................................................................... 5-15
2.4.5 Error Handling ............................................................................................................................... 5-15
2.5 Item Purchase ........................................................................................................................................ 5-15
2.5.1 Introduction ................................................................................................................................... 5-15
2.5.2 Inputs ............................................................................................................................................. 5-15
2.5.3 Processing...................................................................................................................................... 5-15
2.5.4 Outputs .......................................................................................................................................... 5-15
2.5.5 Error Handling ............................................................................................................................... 5-16
2.6 Employee ................................................................................................................................................ 5-16

Project Document Page 2 of 51 03/14/19 f

Systematic Drug Store

2.6.1 Introduction ................................................................................................................................... 5-16

2.6.2 Inputs ............................................................................................................................................. 5-16
2.6.3 Processing...................................................................................................................................... 5-16
2.6.4 Outputs .......................................................................................................................................... 5-16
2.6.5 Error Handling ............................................................................................................................... 5-16
2.7 Product Unit and Category .................................................................................................................... 5-16
2.7.1 Introduction ................................................................................................................................... 5-16
2.7.2 Inputs ............................................................................................................................................. 5-16
2.7.3 Processing...................................................................................................................................... 5-17
2.7.4 Outputs .......................................................................................................................................... 5-17
2.7.5 Error Handling ............................................................................................................................... 5-17
2.8 Product ................................................................................................................................................... 5-17
2.8.1 Introduction ................................................................................................................................... 5-17
2.8.2 Inputs ............................................................................................................................................. 5-17
2.8.3 Processing...................................................................................................................................... 5-17
2.8.4 Outputs .......................................................................................................................................... 5-17
2.8.5 Error Handling ............................................................................................................................... 5-17
2.9 Stock ....................................................................................................................................................... 5-17
2.9.1 3.2.3.1 Introduction ....................................................................................................................... 5-17
2.9.2 3.2.3.2 Inputs ................................................................................................................................. 5-17
2.9.3 Processing...................................................................................................................................... 5-18
2.9.4 Outputs .......................................................................................................................................... 5-18
2.9.5 Error Handling:.............................................................................................................................. 5-18
2.10 Update Stock .......................................................................................................................................... 5-18
2.10.1 Introduction ................................................................................................................................... 5-18
2.10.2 Inputs ............................................................................................................................................. 5-18
2.10.3 Processing...................................................................................................................................... 5-18
2.10.4 Outputs .......................................................................................................................................... 5-18
2.10.5 Error Handling:.............................................................................................................................. 5-18
2.11 Generate Bill .......................................................................................................................................... 5-18
2.11.1 Introduction ................................................................................................................................... 5-18
2.11.2 Inputs ............................................................................................................................................. 5-18
2.11.3 Processing...................................................................................................................................... 5-18
2.11.4 Outputs .......................................................................................................................................... 5-18
2.11.5 Error Handling:.............................................................................................................................. 5-18
2.12 Print Bill................................................................................................................................................. 5-19
2.13 Introduction............................................................................................................................................ 5-19
2.13.1 Inputs ............................................................................................................................................. 5-19
2.13.2 Processing...................................................................................................................................... 5-19

Project Document Page 3 of 51 03/14/19 f

Systematic Drug Store

2.13.3 Outputs .......................................................................................................................................... 5-19

2.13.4 Error Handling:.............................................................................................................................. 5-19
2.14 Performance Requirements .................................................................................................................... 5-19
2.15 Logical Database Requirements ............................................................................................................ 5-19
2.16 Design Constraints ................................................................................................................................. 5-19
2.17 Software System Attributes ..................................................................................................................... 5-20
2.17.1 Standards Compliance ................................................................................................................... 5-20
2.18 No Functional Requirements .................................................................................................................. 5-20
2.18.1 Performance .................................................................................................................................. 5-21
2.18.2 Reliability ...................................................................................................................................... 5-21
2.18.3 Availability .................................................................................................................................... 5-21
2.18.4 Security.......................................................................................................................................... 5-21
2.18.5 Maintainability .............................................................................................................................. 5-21
2.18.6 Portability ...................................................................................................................................... 5-21
2.19 Organizing the Specific Requirements ................................................................................................... 5-21
2.19.1 System Mode ................................................................................................................................. 5-21
2.19.2 User Class ...................................................................................................................................... 5-22
2.19.3 Objects........................................................................................................................................... 5-22
2.19.4 Feature ........................................................................................................................................... 5-22
2.19.5 Stimulus ......................................................................................................................................... 5-22
2.19.6 Functional Hierarchy ..................................................................................................................... 5-22
Chapter3 .................................................................................................................................................................. 5-23
System Design and Architecture .............................................................................................................................. 5-23
3.1 Architectural Design .............................................................................................................................. 5-24
3.2 Decomposition Description .................................................................................................................... 5-25
3.2.1 Use Case Diagram ......................................................................................................................... 5-25
3.2.2 Sequence Diagram ......................................................................................................................... 5-27
3.2.3 Activity Diagram ........................................................................................................................... 5-28
3.2.4 State Transition.............................................................................................................................. 5-29
3.2.5 DFD(Data Flow Diagram) ............................................................................................................. 5-30
3.2.6 DFD 0/context level ...................................................................................................................... 5-30
3.2.7 DFD 1 level ................................................................................................................................... 5-31
3.3 Design Rationale .................................................................................................................................... 5-31
3.4 ER-Diagram ........................................................................................................................................... 5-31
3.5 Data Description .................................................................................................................................... 5-32
Registration Table Definition .............................................................................................................................. 5-32
Product Table Definition ..................................................................................................................................... 5-32
Medicine Table Definition .................................................................................................................................. 5-33
3.6 Data Dictionary ..................................................................................................................................... 5-34

Project Document Page 4 of 51 03/14/19 f

Systematic Drug Store

3.6.1 Admin or Employee: ..................................................................................................................... 5-34

3.6.2 Stock Information .......................................................................................................................... 5-34
3.6.3 Purchase ........................................................................................................................................ 5-35
3.6.4 Sale ................................................................................................................................................ 5-35
3.7 Component Design ................................................................................................................................. 5-35
Chapter4 .................................................................................................................................................................. 5-37
Implementation and Testing .................................................................................................................................... 5-37
4.1 Database Connectivity ........................................................................................................................... 5-38
4.2 Overview of User Interface .................................................................................................................... 5-38
4.3 Screen Images ........................................................................................................................................ 5-39
4.3.1 Login form..................................................................................................................................... 5-39
4.3.2 Main Interface ............................................................................................................................... 5-40
4.3.3 Employee Form ............................................................................................................................. 5-40
4.3.4 View All Employee Form ............................................................................................................. 5-41
4.3.5 Add New Product Form................................................................................................................. 5-42
4.3.6 Medicine Form .............................................................................................................................. 5-43
4.3.7 Dealer Form................................................................................................................................... 5-43
4.3.8 Category Form............................................................................................................................... 5-45
4.3.9 Purchase Form ............................................................................................................................... 5-46
4.3.10 Sale Item Form .............................................................................................................................. 5-47
4.4 Implementation....................................................................................................................................... 5-47
4.5 Testing .................................................................................................................................................... 5-48
Black box Testing: .......................................................................................................................................... 5-48
White Box Testing: .......................................................................................................................................... 5-48
Unit Testing: ................................................................................................................................................... 5-48
Debugging:.......................................................................................................................................................... 5-49
Syntax Errors: ..................................................................................................................................................... 5-49
Logic Errors: ....................................................................................................................................................... 5-49
4.6 Test Cases .............................................................................................................................................. 5-49
4.6.1 Test Case: 1. Login Module Testing. ............................................................................................ 5-49
4.6.2 Test Case: 2. Registration Module Testing.................................................................................... 5-50
4.6.3 Test Case: 3. Add new Products. ................................................................................................... 5-50
4.6.4 Test Case: 4. Add purchases or new stock. ................................................................................... 5-51
4.6.5 Test Case: 5. Make a sale. ............................................................................................................. 5-51
5 Testing summary ............................................................................................................................................. 5-52

Project Document Page 5 of 51 03/14/19 f

Systematic Drug Store

Chapter1

Introduction

Project Document Page 6 of 51 03/14/19 f

Systematic Drug Store

1.1 Purpose
The purpose of this project used in the medical store to maintain the detail of the stack and
account of our pharmacy store. The Systematic Drug Store are used to designed to work load our
medical store are professional. The features include inventory and stocks control, client
management. The requirements were to develop a flexible Pharmacy information system which
we can be used for administration, who wants to get information. The main purpose of my
project is that every companies of Medicine are Available in this store. If the customer wants to
change the medicine that is easily change. The customer come to pharmacy store with receipt
and asked the admin to change the medicine. The admin edit the slip and give the required
medicine of the customer. Only authorized administrators can update, delete, edit and search and
change any records

1.2 Scope
The project has following aspect that helps the Administrator of the Systematic Drug Store

1) It can manage all the records of the medicine and their information.
2) It can manage all the records of the works order and their information.
3) Search the particular record of the database and generate the Report.
4) It is not costly all the record can be managed only single computer.
5) It is not time consuming system.
6) It can easily add or remove the records of the medicine.
7) All the information stored in a single place the redundancy cannot occur.
8) If all the record are lost they can easily generate a backup.
9) It is set of different types of constrains.
10) It is centralize database system.

1.3 Definitions, Acronyms, and Abbreviations.

Terms/Abbreviations Explanations
SDS Systematic Drug Store
CMS Content management system
GUI Graphical User Interface
DDBMS Distributed Database Management System
DSS Data storage system
RBAC Role back Access Control
STD Standards
USER System User

1.4 References
In this section of the reference:
I search the different website and collect the data get idea.specifications of IEE recommended by
the software requirements and also follow the instruction of the IEE template.

Project Document Page 7 of 51 03/14/19 f

Systematic Drug Store

The references are :

1) www.google.com
2) www.youtube.com

1.5 Overview
The Systematic Drug store is developed in order to replace the manual base system to the
computerize. Here system is expected to the efficient, useful and affordable to implemented task
in the order of the pharmacy management.

 It contains all the description material provided for the project.

 Section 1 defines the introduction, purpose and scope of the software.
 Section 2 defines the General description, Constrains, Functions of the software.
 Section 3 defines the detail requirements and specific functions and other related
requirements of the software Like Functional Requirements and No-Functional
Requirements.
 Section 4 defines to Analysis the Models.
 Section 5 provides the Supporting appendix

1.6 Product Perspective

The product of the software system is the PMS. The software maintains all the records of the
transactions. This is also a facility checking stock, issue sales orders and to purchase the item
which is less or more saleable.This System should depend on the different types of medicine
comes from the different country and cities and their companies. There is different Types of the
Users so there is functionality between with customers will occurs with respect of the data item.
Our Software of Pharmacy Management System (PMS) should work with efficiently according
to the pharmastic data. So there is interface that is exit with the suitable of the Customer and
Manager that work with the Software and deals with the customer and generate the token with
very reliable and efficient manner. The system will be efficient and compete able with our
system and working with our environment that will provide him.

1.6.1 System Interfaces

The system interface is like a different GUI forms that are filled to enter the data into the system
of the pharmacy management. The Employee and others regular clients are interact with the
system through the interfaces.

1.6.2 Interfaces
There is a pharmacy manager Interface. He can add or remove the employee information in this
system. The important part of the interface is that the admin can generate the token bill of the
user. We will provide a better and efficient interface of this Pharmacy system. My thought is that

Project Document Page 8 of 51 03/14/19 f

Systematic Drug Store

every pharmacy store attract this interface and wish to purchase this pharmacy management
interface.

Administrator Interface
The administrator can view the record of his staff members and the Dealers that are involved
into the system. He can add or Remove any staff member from the system. He can view different
types of reports for example sale or purchase report. He can manage stock, add new items to the
system. He can update the staff record as well as the stock record as required.

The Employee interface

The Employee or the computer operator is the person at the Pharmacy Store, which directly
communicate with customers and take sale orders. He must have an account on the system to
utilize it according to the features provided by the administrator. Like he should be able to make
sales transactions, search items to check whether the corresponding item has enough quantity in
to be sold. After a sales order has confirmed. He should be able to print a bill receipt for that
order. He should also have an authority to view sales reports.

1.6.3 Hardware Interfaces

Minimum Configurations:

Processor 2.5 Hz Pentium processor

Motherboard Intel chipset
RAM 512 MB
Hard-disk 20 GB
Disk-drive 6x Compact Disk
Monitor lcd or led 640 * 480 [Display]
Input device Keyboard , Mouse

Recommended Configurations:

Processor 2 GHz duel Core

Motherboard Intel 81x chipset
RAM 2 GB
Hard-disk 80 GB
Disk-drive 52x Compact Disk
Monitor lcd or led 800 * 600 [Display]

Input device Keyboard , Mouse

Project Document Page 9 of 51 03/14/19 f

Systematic Drug Store

1.6.4 Software Interfaces

Operating System Windows 7 , 8 or Windows 10 [32 or 64 bit ]

Development tool/GUI Visual studio 2015
Framework .NET Framework 4.5
Software Ms office , word Install

1.6.5 Communications Interfaces

The Systematic Drug Store is a standalone project that does not requires any communication
interface.

1.6.6 Microsoft SQL Server

SQL server is used to connect with the database using OLEDB and ODBC data connection.
Many backend software are available for data storage such as MS access, Sybase, oracle and my
SQL. Here we are choosing Microsoft SQL Server as database for the system. It has best features
supporting the .net framework. Some features are:
1) Multiple platform supported by the system.
2) Integration with Windows 8.1 or 10 or 7.
3) Integration with MS .NET Enterprise Servers.
4) Scalability.
5) Replication.
6) Centralized Management.
7) Reliability.
1.6.7 Operations
The Administrator will be performed the operation of the Systematic Drug Store to handle these
task. The maintenance of this project is done by the Administrator. Administrator can Login the
management system first he will enter username and password and login the PMS. Administrator
can check the stock, it can update delete and insert the stock of the pharmacy management
system. Administrator can print the bills using print command of the Systematic Drug Store.
Admin can also used to generate the report using the system. Administrator can pay the salaries
of our Employee and update the record of the chemist of the PMS. Administrators can deal the
clients with efficient manner. All the stock purchase and its sales is also maintains by the Admin.
He can also accept or reject the particular stock.

Project Document Page 10 of 51 03/14/19 f

Systematic Drug Store

1.6.8 Site Adaptation Requirements

In this section:

Data Requirements:
1) The particular format for the data should be accepted by the system.
2) We will have to know about it the data that we are entering is acceptable for the
system or not.
Change Requirement:
1) If you have to change the some part for example about employee or supplier you
will have enter the updated version of the software requirement specification
documents.
1.7 Product Functions
1) It keeps the information’s about the employees, suppliers and categories etc.
2) The sufficient quantity of the stocks is issued by the admin to the customers.
3) Due to insufficient quantity that the customers are demanding that will not be issued.
4) The orders are given to different parties for purchasing if the stocks are less quantity in the
pharmacy store.
5) The payment can be deposited in time or sometimes.
To attract the customer in pharmacy store discount and different offers can be given to the all
customers in given dates
1.8 User Characteristics
This system is intended to use by various users. we can divided all the users in four stages each
one is responsible and role in the PMS.

User Function & Responsibilities Source

Manager Responsible for the batch of the project and 1st project
control overall development flow and Description
Assigns the projects.
The project team leader fulfillment of the
project task and control the functionality of
the project.
Project Team leader Responsible for the particular project. 1st project
Leads a project for 2-20 members of each Description
project team.
Assigns the task to project team members
and controls to their fulfillments, Reports to
the manager.

Project Document Page 11 of 51 03/14/19 f

Systematic Drug Store

Project team member Responsible for a particular task or part of 1st project
the task. Description
Reports to the project team leader.
System Administrator Responsible for the installation , 1st project
maintenance , security and troubleshoot the Description
productive system to manages the PMS.
It is responsible for generating the reports.

Table no 1 User and their responsibilities

These roles describe the important role of the pharmacy management system (PMS).

1.9 Constraints
1) The main Constraint which would be the checking the requirements of the buyer.
2) The development system run Under the platform (Windows , Unix , Linux , Mac etc)
3) It is necessary to run this project to install the visual studio 2015.
4) It is necessary to install SQL server 2007, 2017 or 2012.
5) The hardware Must be Attached this system.
6) The user Get information about the Medicine or its product.
7) It cans also control functions of this software.
8) It is also contains a set of rules that can be predefined.
9) Execution time of software cannot longer than 1 or 2 second.
10) It can have regulatory policies.
11) It has high order language required.
12) It has hardware limitations.
13) It is safety and security considerations.
1.10 Assumptions and Dependencies
The PMS stores all the operational (projects, tasks, subtask, dependencies and resources).The
data is a centralize data storage with using Distributed database system. There are no
requirements of the data storage system. We assume that the pharmacy management system
(PMS) will able to access a data with Database management system through standard interfaces
like ODBC, ADO Provide by Development environment. The pharmacy management system
(PMS) support distributed project management. It can be run over the various platforms. In this
platform you cannot be communicate with other medical stored to get the information about the
medicine. Because the system cannot provide the communication interface to the client. The
detail also related the project, customer, payment and service transactions. The Administrator
can created the system is already and their roles and task are also predefined.

Project Document Page 12 of 51 03/14/19 f

Systematic Drug Store

Chapter2
Software Requirements Specification

Project Document Page 13 of 51 03/14/19 f

Systematic Drug Store

2.1 Specific Requirements

In this section we will discussed about the requirements engineering process that provide the
mechanism for understanding what the customer want analyzing , feasibility , unambiguously
and reasonable solution. It can validate the specifications and managing the requirements and
they are transformed to the operational system.

1) Requirements specifications
2) Requirements validations
3) System Modeling
4) Requirements Management
5) Reports Generated
Requirements Specification leads the following faces.
1) Identify the External interface
2) Allocate Requirements
3) User characteristics
4) Development of requirements in Matrix
5) Prioritize requirements
2.2 Functions
1) Administrator manages information for employee.
2) Manages the stock and purchases.
3) Make product sale to the customers.
4) View different reports.
5) Manages the information of debit customer.
6) Manages the debit customer account.
7) Manages the Dealer information.
8) Manages the debit purchases.
9) Total bill of the customer purchases.
10) Total bill of the sales items
2.3 Functional Requirements
This section describes specific features of the software project. If desired, some requirements
may be specified in the use-case format and listed in the Use Cases Section.

2.4 Item Sale

2.4.1 Introduction
Sales orders are issued by the chemist or by the administrator, when a customer or dealer request
for some items available at the store. Both administrator and the chemist can make a sales order
as required to make a sale transaction.

Project Document Page 14 of 51 03/14/19 f

Systematic Drug Store

2.4.2 Inputs
The person who is logged in to the system can issue sale orders by checking the demand of
customers or viewing the stock. The item name, item quantity, rate, city of the customer or
client, sale order date are the basic inputs for this module.
2.4.3 Processing
The data processed in it can be in the form of adding a sale order, updating orders issued and
searching order by date etc. changing customer required items, order dates by updating of
records are common processing elements of the module.
2.4.4 Outputs
The data is organized in well and understandable and efficient format. The output can be
generated in different formats i.e. checking whether an order is issued by an employee or not.
Different type of reports can be produced by the employees of the shop for checking their order
to maintain the super store.
2.4.5 Error Handling
If some record is inserted that is incorrect then it can be updated by administrator. The records
that contains some errors can be resolve by the update operation which is the authority of store
administrator to maintain data accuracy and consistency.
2.5 Item Purchase
2.5.1 Introduction
Purchase order are given by the employee, chemist or by the administrator itself to different
parties. The purchase order are given when the items for some stock are finished in stock or are
in less quantity than selling quantity

2.5.2 Inputs
The Admin which is login into the system can give a purchase order by checking the demand of
customers or viewing the stock. The item name, item quantity, rate, city of the company,
purchase order date, delivery date etc. of purchase order are the basic inputs.
2.5.3 Processing
The data processed in it can be in the form of adding a purchase order, deleting orders, updating
orders issued and searching order by date or order number etc. Changing delivery dates, order
dates by updating of records are common processing elements of the module.
2.5.4 Outputs
The data is organized in well and efficient format. The output can be generated in different
formats i.e. checking whether an order is given by the employee, chemist or the administrator or
not. Different type of reports can be produced by the employee and the administrator of the
Systematic Drug store for checking their purchase order to maintain stock.

Project Document Page 15 of 51 03/14/19 f

Systematic Drug Store

2.5.5 Error Handling

If some record is inserted incorrectly then it can be updated by administrator. The records that
contains some errors can be resolve by the update operation which is the authority of Systematic
Drug Store administrator to maintain data accuracy and consistency.
2.6 Employee
2.6.1 Introduction
This model is used to store the information about the employees and I can be check by the
Administrator and they can be responsible for the employee record management.

2.6.2 Inputs
The administrator input the system of employee id that can be assigned of each employee of the
pharmacy store. The employee id contains the name,cinic#,mobile#,salary , salary status . The
administrator can set the each employee salary and then stored a record of each employee in the
database

2.6.3 Processing
The data process in the form of adding records , update Employee’s record and search the
particular employees working in the system that are currently work here and also check which
employees are left the job.

2.6.4 Outputs
The format of the data that can be organize as well and understandable or efficient. The output of
every each employee generated differently for example the admin check the employee that are
currently work there and salary status and their information is also remarked these things.
Different types of the reports can be generated by the admin and it can be comparing the
employees performance.

2.6.5 Error Handling

If some record enters by incorrectly to the employees it can be set by the Administrator. The
record in which errors occurs are stored in the database of the different table after sometimes we
should prove that where error are made and how it can be corrected.

2.7 Product Unit and Category

2.7.1 Introduction
This module is used to keep the information of the products units and its category. It can
maintained by the Admin of Systematic Drug Store. Only the administrator responsible for
adding new units or categories.
2.7.2 Inputs
To maintain the products units and its category record in the system these should be assigned an
category id and unit name.

Project Document Page 16 of 51 03/14/19 f

Systematic Drug Store

2.7.3 Processing
The data processed in it can be adding records, and search a particular unit or Product which is to be
deleted or updated.
2.7.4 Outputs
The data is organized in well and understandable and efficient format. The output can be
generated in different formats.
2.7.5 Error Handling
If some record is inserted that is incorrect then it can be updated by administrator. The records
that contains some errors can be resolve by the update operation which is the authority of store
administrator to maintain data accuracy and consistency.
2.8 Product
2.8.1 Introduction
This module is used to keep the information of the products. It is maintained by the Admin of
Systematic Drug store . Only the administrator responsible for adding new products.

2.8.2 Inputs
To maintain the information of Product in the system these should be assigned an id, Product
name, Product category and unit name etc. if some fields are empty the system prompts to fill the
required fields
2.8.3 Processing
The data processed in it can be in the form of adding record of the new products, and search a
particular Product which is to be deleted or updated.
2.8.4 Outputs
The data is organized in well and understandable and efficient format. The output can be
generated in different formats.
2.8.5 Error Handling
If some record is inserted that is incorrect then it can be updated by administrator. The records
that contains some errors can be resolve by the update operation which is the authority of store
administrator to maintain data accuracy and consistency.

2.9 Stock
2.9.1 Introduction
Through stock view work, employees and the admin of the system check and view the real status
of the stock.
2.9.2 Inputs
For perspective of stock status, any id or item name use as a sources of info.

Project Document Page 17 of 51 03/14/19 f

Systematic Drug Store

2.9.3 Processing
After this, user select a button related this function or select any other menu.
2.9.4 Outputs
In the wake of entering id or item name, demonstrate the all data of stock like stock amount,
stock cost and so on.
2.9.5 Error Handling:
If the item id or item name is not entered client cannot check stock .Enter item id.

2.10 Update Stock

2.10.1 Introduction
Refreshing capacity incorporate into the framework. Refreshing make conceivable after deal and
buy of stock.
2.10.2 Inputs
For refreshing, client utilized deal and buy of stock information utilized as info.
2.10.3 Processing
Refresh choice connected on this capacity. This choice accessible in type of catch or menu
2.10.4 Outputs
After perform this function, stock record update Through updating stock increase and decrease.
2.10.5 Error Handling:
If the record of sales and purchase is not refreshed stock record will not be updated .Update the
stock.

2.11 Generate Bill

2.11.1 Introduction
After sale, user generate bill of sold items to customer through system.
2.11.2 Inputs
Product items and customer record required as input to generate bill for payment after sales.
2.11.3 Processing
For generate bill, many option like button, menu and some mathematical operations performed.
2.11.4 Outputs
Item name, amount, value, rebate and client name are show on bill to make installment
conceivable.
2.11.5 Error Handling:
If user do not have sale record bill will not be generated. Generate the bill.

Project Document Page 18 of 51 03/14/19 f

Systematic Drug Store

2.12 Print Bill

2.12.1 Introduction
Bill would be printed as a confirmation of finish exchange for both sides.
2.12.2 Inputs
Charge data utilized as contribution to played out this capacity.
2.12.3 Processing
To print the bill, select catch choice and utilized printer for this reason.
2.12.4 Outputs
After print explanation, a bill is print in hard shape for proof utilized.
2.12.5 Error Handling:
Confirmation of exchange is not finished from both sides then bill will not be printed .complete
the explanation from both sides and print the bill.

2.13 Performance Requirements

This subsection specifies both the static and the dynamic numerical requirements placed on the
software or on human interaction with the software, as a whole. Static numerical requirements
may include:

(a) The number of terminals to be supported

(b) The number of simultaneous users to be supported
(c) Amount and type of information to be handled
Static numerical requirements are sometimes identified under a separate section entitled capacity.
Dynamic numerical requirements may include, for example, the numbers of transactions and tasks
and the amount of data to be processed within certain time periods for both normal and peak
workload conditions. All of these requirements should be stated in measurable terms. For
example,95% of the transactions shall be processed in less than 1 second rather than, An operator
shall not have to wait for the transaction to complete.
(Note: Numerical limits applied to one specific function are normally specified as part of the
processing subparagraph description of that function.

2.14 Logical Database Requirements

There will be database used for the storing the manager username or password and their daily
medicine history. What logical requirements exits for data format, storage capabilities, data
constraints and data integrity.
2.15 Design Constraints
Specify design constraints that can be imposed by other standards, hardware limitations, etc In
order to provide a system at no or little cost to partners and to supports the above Systematic
Drug Store requirements, this sets of design goals and constraints developed.

Project Document Page 19 of 51 03/14/19 f

Systematic Drug Store

In this requirement , Specify the requirements derived from existing standards or regulations.
They might include:
Report format
1) Data naming
2) Accounting procedure
3) Audit Tracing

Inventory control and management enable EMS agencies to Improvement. Efficiency and
effectiveness. Complex environment requires administrator to constantly juggles issues like
tightening budgets, drug shortages, strict governmental regulation and a highly engage and
connected staff –all while operating in a litigious society. Using this approach to inventory
management and supply and logistics is no longer an acceptable practice.

2.16 Software System Attributes

There are a number of attributes of software that can serve as requirements. It is important that
required attributes by specified so that their achievement can be objectively verified. The
following items provide a partial list of examples. These are also known as non-functional
requirements or quality attributes. These are characteristics the system must possess, but that
pervade (or cross-cut) the design. These requirements have to be testable just like the functional
requirements. Its easy to start philosophizing here, but keep it specific.

2.16.1 Standards Compliance

The requirements are derived to the existing standards and their regulation it can include like.
1) The report you can generate their format.
2) The medicine is stored in the database with their data names.
3) The main thing is that the accounting procedures for example how to calculate the price of
the medicine and generate the bills.
4) The specific piece of financial information’s back to its organizations documents by
following the audit trace
For anything but trivial systems the detailed requirements tend to be extensive. For this reason,
it is recommended that careful consideration be given to organizing these in a manner optimal
for understanding. There is no one optimal organization for all systems. Different classes of
systems lend themselves to different organizations of requirements in section 3. Some of these
organizations are described in the following subclasses.

2.17 No Functional Requirements

The non-functional requirements are more critical than functional requirements, because if these
are missing the system is useless.
Non-Functional requirements are stated here:

Project Document Page 20 of 51 03/14/19 f

Systematic Drug Store

2.17.1 Performance
System will perform each task almost within 15 seconds. Increasing the hardware specification
will increase the performance of the system.
2.17.2 Reliability
The Reliability means that the chance to avoid the failure of the software, that operation
performed in this software are specified to the environment. The reliability of the software is also
a main factor.

2.17.3 Availability
Availability means that incase of network failure, we cannot connect the database. In this
situation only right operation can be perform and they cannot retrieved the data in the database
until after the cluster system is prepared.

2.17.4 Security
The security of the system main part of any software management system. It can avoid the use of
unauthorized persons that cannot get any information about the products. No other person can be
seen the product history. The record of the system must be changed the admin system in case
admin are not available the employee of the pharmacy are not authority to use the admin
account.

2.17.5 Maintainability
The system should be consistent and never slow down. If error is occurs as soon as possible
automatically maintained. The database maintainability is to proved flexibility, usability and
suitability of the given database. A section to prove the database is fit and use for the purpose.

2.17.6 Portability
Portability means that the system can be run on any windows operating system by installing it
another platform. The Visual programming can provide the environment of any windows
operating system that is possible to run the system

2.18 Organizing the Specific Requirements

For anything but trivial systems the detailed requirements tend to be extensive. For this reason,
it is recommended that careful consideration be given to organizing these in a manner optimal
for understanding. There is no one optimal organization for all systems. Different classes of
systems lend themselves to different organizations of requirements in section 3. Some of these
organizations are described in the following subclasses.

2.18.1 System Mode

1) To develop a desktop application for order .
2) To Provide efficient way to control the transaction process of the company.
3) Provide the registration of the new Employee Or Chemists and the customer simply.
4) Provide facility to manage stock.

Project Document Page 21 of 51 03/14/19 f

Systematic Drug Store

2.18.2 User Class

1) Prompt Data class is used to enter or input any Entry in pharmacy management system.
2) Employee class is used to insert the Employee Information in pharmacy management
system.
3) Product class is used to add and view the products
4) Purchase class is used to purchase the stock through the dealer
5) Sale class is used to sale the items of our system when customer want to purchase some
item in pharmacy management system.
6) Admin class is most important component of the whole the system it can managed all the
entries of the system
7) Database is used for database connectivity.

2.18.3 Objects
1) Insert () insertion operation are used to insert the data .
2) View () method is used to view the output.
3) Update() is used to update the employees , products , medicines , and further updating in
the system
4) Search () selects the desired data from database.
5) Delete () is used to delete the record in the database.

2.18.4 Feature
The Administrator are full authority to change the entire system, and also convert the data in
different forms and the user just has to describe desired input the data to be execute.You can
easily generate the reports of the purchase and sale items.

2.18.5 Stimulus
1) Open Systematic Drug Store application
2) After login to the system you can have many operations like insert, update, and view and
delete the products and employees information.
3) Adding new companies of medicines and their dealers information.
4) Generates the reports of purchases and sales item in pharmacy system.

2.18.6 Functional Hierarchy

When none of the above organizational schemes prove helpful, the overall functionality can be
organized into a hierarchy of functions organized by either common inputs, common outputs, or
common internal data access. Data flow diagrams and data dictionaries can be use dot show the
relationships between and among the functions and data.

Project Document Page 22 of 51 03/14/19 f

Systematic Drug Store

Chapter3
System Design and Architecture

Project Document Page 23 of 51 03/14/19 f

Systematic Drug Store

3.1 Architectural Design

This system will maintain and records all the transactions such as sale or purchase order and
storing the record of employees and Dealer. It is also store the New Contacts, Medicine
Company Name. There is also the facility of checking stock, issue sale orders and to purchase
orders. Basic interface through which the user will interact with the system are the different
screens with multiple items having the facility of adding, deleting, updating and searching of
records facility with different aspects. The system will be efficient and compatible with other
system working in the environment.

Fig 3.1 Architectural Design.

This image define the Architecture design of the pharmacy system all the components of the
system i.e customer , admin , dealer of the company , employee or chemist staff are connected in
main Component of Systeatic Drug Store and the Whole system are connected to the Database
which the records are stored.

Project Document Page 24 of 51 03/14/19 f

Systematic Drug Store

3.2 Decomposition Description

3.2.1 Use Case Diagram
3.2.1.1 Use Case of Administrator

Fig 3.2.1.1 Use Case Administrator

This diagram is used to perform some functions i.e the actor is admin that can login the system
after login he can print bills ,c heck stocks , emp salaries , update stocks , maintain stock and
other functions that are used in the pharmacy management system.

Project Document Page 25 of 51 03/14/19 f

Systematic Drug Store

3.2.1.2 Use Case of Systematic Drug Store

Fig 3.2.1.2 Use Case of Pharmacy

This is the complete use case diagram of the system where the customer and Manager/admin can
performed some operations check the stocks, update ,delete ,print, search medicine and print the
sale item report

Project Document Page 26 of 51 03/14/19 f

Systematic Drug Store

3.2.2 Sequence Diagram

Fig 3.2.2 Sequence Diagram

This is the sequence diagram of the system , firstly user is enter it can show the login form after
it can fill this form enter the system and performed operations i.e check Admin/manager
controller and submit the account info and check the account is available or not if available then
proceed next step or if not available then destroy the instruction.
Project Document Page 27 of 51 03/14/19 f
Systematic Drug Store

3.2.3 Activity Diagram

Fig 3.2.3 Activity diagram

This is the activity diagram of the system . this diagram divide the 3 portion first admin , second
stock and third for customer . In the first portion the admin can validate all the activity of the
system. The second portion is stock it can check the stock is available or not if available generate
the bill. And the third portion is the customer ask for medicine.

Project Document Page 28 of 51 03/14/19 f

Systematic Drug Store

3.2.4 State Transition

Fig 3.2.4 State Transition diagram

This is the state transition diagram user login and enter to the system and insert , edit ,update and
delete the record the user can generate the reports , view reports , customer information and view
information.

Project Document Page 29 of 51 03/14/19 f

Systematic Drug Store

3.2.5 DFD(Data Flow Diagram)

3.2.6 DFD 0/context level

Fig 3.26 0/context level

Project Document Page 30 of 51 03/14/19 f

Systematic Drug Store

3.2.7 DFD 1 level

Fig 3.2.7 1 level

3.3 Design Rationale

As we know some important feature such as performance, Maintainability generalization of the
software system. We will be agreeing on how we will design the system according to the
requirement of the system. The Pharmacy software should be public demand generic to use. We
will write our code in simple easily and understood able way by adding comments. This will be
providing easy to understand that which function is doing what.

3.4 ER-Diagram

Project Document Page 31 of 51 03/14/19 f

Systematic Drug Store

3.5 Data Description

3.5.1 Registration Table Definition

Fig 3.5.1 Registration Table

This is the Registration table it contain to store all the record of the new registered user. If you
want to add a new member of this system the role filed is contain the admin and user.

3.5.2 Product Table Definition

Fig 3.4.2 Product

Project Document Page 32 of 51 03/14/19 f

Systematic Drug Store

This is product table it can used to store the product table definition it can contain name, data
type, allow nulls , default columns .

3.5.3 Medicine Table Definition

Fig 3.4.3 Medicine

This is medicine table it can used to store the all the record of the medicine and the table
definition it can contain name, data type, allow nulls, default columns.
3.5.4 Sale Table Definition

Fig 3.4.4 Sale

This is sale table it contains to stored the sales item . if the customer want to purchase some
items in the system . the record are stored in the table.

Project Document Page 33 of 51 03/14/19 f

Systematic Drug Store

3.6 Data Dictionary

3.6.1 Admin or Employee:
Field name Data type Description

Id Int Identity number or serial number.

Firstname varchar(50) Complete First Name
Lastname varchar(50) Complete Last Name
Street varchar(50) Complete address of employee
City varchar(50) Employee residence
Province varchar(50) State
Email varchar(50) Unique can be email
Cnic varchar(50) National identity card
Contactno varchar(50) Numbers
Username varchar(50) Unique name its not compulsory
your name
Password varchar(50) Your Authentication keywords
Role varchar(50) Which can login to system Admin or
Users

Table no 3.6.1

3.6.2 Stock Information

Field name Data type Description

Product_id Int Identity number

Product Name nvarchar(MAX) Name of the Items

Product Quantity Int Total number or weight of item
Product Unit nvarchar(MAX) Unit of the item i.e. kg grams or liter.

Table no 3.6.

Project Document Page 34 of 51 03/14/19 f

Systematic Drug Store

3.6.3 Purchase

Field name Data type Description

Purchase Id Int Identity number
Product name nvarchar(MAX) Name of the product
Product Quantity nvarchar(MAX) In numbers
Product Unit nvarchar(MAX) In number or alphabets
Product price nvarchar(MAX) In numbers
Product Total nvarchar(MAX) In numbers
Product Date nvarchar(MAX) Date
Purchase Party Name nvarchar(MAX) Alphabets
Purchase Type nvarchar(MAX) Alphabets
Expire Date nvarchar(MAX) Date time
Profit nvarchar(MAX) In number or percentage
Product category nvarchar(MAX) In number or alphabets
Table no 3.6.3
3.6.4 Sale

Field name Data type Description

Id Int Identity number
Order_id nvarchar(MAX) Unique
Product nvarchar(MAX) In numbers
Price nvarchar(MAX) In number
Quantity nvarchar(MAX) In numbers
Total nvarchar(MAX) In numbers
Table no 3.6.4
This is sale table it contains to stored the sales item . if the customer want to purchase some
items in the system . the record are stored in the table.

3.7 Component Design

The system is capable to do work according to the direction. Every simplest or complex
Component is responsible to do work which is assigned to it. The system considers every
Component as best efficient way component for the mutual cooperation of the whole
Process Component design follows as:-

Hardware Software Database

Project Document Page 35 of 51 03/14/19 f

Systematic Drug Store

The short detail of the component design working describes as the user after login to the system
will choose an option for the submission or other action. Consider an example if a user choose
the option to save the project, he or she will press the tab of submission. The given data in the
text box will be stored in the database and a user can also retrieve the data on demand. Suppose
he or she want to see his or her data of project proposal submission, the user will only click to
the data showing tab the stored data in the of the system

Project Document Page 36 of 51 03/14/19 f

Systematic Drug Store

Chapter4
Implementation and Testing

Project Document Page 37 of 51 03/14/19 f

Systematic Drug Store

4.1 Database Connectivity

using System;
usingSystem.Data;
usingSystem.Linq;
usingSystem.Text;
usingSystem.Threading.Tasks;
usingSystem.Data.SqlClient;

namespaceDatabaseConnectivity
{
public class Database
{
Private String ConnectionString =

(@"DataSource=(LocalDB)\v11.0;AttachDbFilename=E:\FinalYearProjecMCS\PhramacySt
ore\PhramacyStore\pharmadb.mdf;Integrated Security=True"");
SqlConnection conn = new SqlConnection (this.ConnectionString); SqlConnection conn = new
SqlConnection(this.ConnectionString);
SqlCommandcmd = new SqlCommand(sqlText, conn);
SqlDataAdapteradpt = new SqlDataAdapter(cmd);
DataTabledt = new DataTable();
SqlDataReaderrdr = cmd.ExecuteReader();
}
}

4.2 Overview of User Interface

After log in to the system the user or the admin has home page or main page, where he can
choose the option according to the requirement and the according to the access permission
granted by the admin. The only admin can use full fledge options of the system, rest of members
can use as access provided by the admin.

Project Document Page 38 of 51 03/14/19 f

Systematic Drug Store

4.3 Screen Images

4.3.1 Login form

Fig 4.3.1 Login Interface

When the application is run this page is visible. This is main entrance page to enter into the
application after enter correct username and password.

Project Document Page 39 of 51 03/14/19 f

Systematic Drug Store

4.3.2 Main Interface

Fig 4.3.2 Main Interface

This is main page of the application. It contains all the controls to use to maintain pharmacy store
management. The most the components are placed in this strip.

4.3.3 Employee Form

Fig 4.3.3Add New Employee

This is the employee information form. We can used to create the new users in this application.
All the necessary information is stored in this form.

Project Document Page 40 of 51 03/14/19 f

Systematic Drug Store

4.3.4 View All Employee Form

Fig 4.3.4 View All Employee

This page contains the list all the employee in the system. If we want to delete the employee you
can select the row and delete the record using the delete selected button. .

Project Document Page 41 of 51 03/14/19 f

Systematic Drug Store

4.3.5 Add New Product Form

Fig 4.3.5 Add New Product

This page is Add new product you can enter the product code , name , category and price and
quantity to enter and these records are saved in the product table.

Project Document Page 42 of 51 03/14/19 f

Systematic Drug Store

4.3.6 Medicine Form

Fig 4.3.6 Add New Medicine

This page is used to add the new medicine of the medicine table , user or admin can enter the
medicine code , name , category , units , price and medicine expire date to insert the medicine
table

4.3.7 Dealer Form

Project Document Page 43 of 51 03/14/19 f

Systematic Drug Store

Fig 4.3.7 Add New Company Dealer

This is the dealer form we can add the different companies of the medicine . we add can the
dealer name their company , contact , address and city and also save this record in Dealer table in
the database.

Project Document Page 44 of 51 03/14/19 f

Systematic Drug Store

4.3.8 Category Form

Fig 4.3.8 Add New Category

This page is used to add the new category of the medicine . for example the new medicine of the
formulae are published the market we can also add this system.

Project Document Page 45 of 51 03/14/19 f

Systematic Drug Store

4.3.9 Purchase Form

Fig 4.3.9 Purchase Entry

This page is contains the purchase entry of this system , we can purchase the new products
through different companies i.e. insert the product name, unit , quantity of the stock , price and
also purchase type the dealer can pay this through the cash or debit

Project Document Page 46 of 51 03/14/19 f

Systematic Drug Store

4.3.10 Sale Item Form

.

Fig 4.3.10 Sale Interface

The Last feature of this pharmacy system is sale item , we can sale the item when the customer
asked to purchase the medicine . we can add the medicine name , price , quantity and also
generate the total. the employee of this system is click the save and print the button the report of
the sale item.

4.4 Implementation
A crucial phase in the system life cycle is the successful implementation of the new system
design, Implementation simply means conveying a new system design into operation. This
involves creating computer-compatible files, training the operating staff and installing hardware,
terminals before the system is up and running.
In system implementation, user training is very difficult for minimizing resistance to change and
giving the new system a chance to prove its worth. Training aids, such as user friendly, manuals,
a data dictionary, job performance aids that communicate information about the new system and
“help” screens helps the user to work efficiently on the new system.

Project Document Page 47 of 51 03/14/19 f

Systematic Drug Store

4.5 Testing

Testing Strategy:

The errors may occur at a very inception of the process where the objectives may be erroneously
or imperfectly specified. Because of human inability to perform and communicate with
perfection, software development is accompanied by a quality assurance activity.

The basic Strategies that are used for testing are following.

1) Black box testing

2) White box Testing
3) Unit Testing
4) System Testing
5) Acceptance Testing

Black box Testing:

In Black Box testing only the functionality was tested without any regard to the code written. If
the functionality, which was expected from a component, is provided then black box testing is
completed. Black Box testing is also called as Behavioral testing because it tests the functional
requirements of the software. Black Box testing enables to derive sets of input conditions that
will fully exercise all functional requirements for a program. Black Box testing is not an
alternative to white-box techniques. Rather it is complementary approach that is likely to
uncover a different class of errors than white-box methods.
White Box Testing:

In white Box testing internal code written in every component was tested and it was checked that
the code written is efficient in utilizing various resources of the system like memory or the
utilizing of input/output. White Box testing is a test case design method that uses the control
structure of the procedural design to derive test cases. Logical errors and incorrect assumptions
are inversely proportional to the probability that a program path will be executed.
Unit Testing:

In Unit testing I checked that the entire individual component is working properly. Before
integration of the entire component unit testing is essential because it gives a confidence that all
the component individually are working fine and ready to be integrated with the other one.

Project Document Page 48 of 51 03/14/19 f

Systematic Drug Store

System Testing:

When all the units are working properly and unit testing was performed then the time for system
testing arrives, where I checked all the integrated components as a whole and looked for possible
discrepancies, which could have arisen after the integration.

Acceptance Testing: In acceptance testing the software was checked for completeness that it is
ready. Normally the quality assurance department performs the acceptance testing that the
software is ready and can be exported.

Debugging:

Debugging is not testing but it occurs always as a consequence of testing. It begins with
execution of a test case. Results are assessed and lack of correspondence between expected and
actual performance is encountered. Debugging is one of the more frustrating parts of
programming. It has elements of problem solving or brainteasers coupled with the annoying
recognition that you have made a mistake. While testing my software I found some errors, which
I corrected in debugging modes. I found Syntax errors in Black box testing and Logical errors in
white-box testing.
Syntax Errors:

These are caused by typographical errors & incorrect use of the Programming language.

Logic Errors:

These are caused by the incorrect use of the control structure. These errors were identified while
testing procedure and were corrected in debugging mode.

4.6 Test Cases

4.6.1 Test Case: 1. Login Module Testing.
System: Systematic Drug Store System.

Test:
Login form is opened and login username and password is entered.

Instructions:
1) Open the Login Form
2) Enter user name and password.
Expected Result:
Message will appear that please enter correct user name and password.

Project Document Page 49 of 51 03/14/19 f

Systematic Drug Store

Actual Result:
The entered user name and password is correct, hence you can manage your software system to
make changes into the data and also can get the expected result you desire.

4.6.2 Test Case: 2. Registration Module Testing.

System: Systematic Drug Store

Test:
The registration testing actually a testing in which it is notifies the user that if the new candidate
has unique id and password then it will become a new registered candidate.

Instructions:

1) You can select the option for add new employee to add a new Employee.
2) Against the option you may find any more options.
Expected Result:

1. The “adds new employee” form with its all basic information.
2. The testing will occur consequently on the selected option.
Actual Result:

Result was as per expected on the behalf of the menu and the candidate is registered now.

4.6.3 Test Case: 3. Add new Products.

System: Systematic Drug Store

Test:
The insertion record testing module shows the information of the product is provided correctly. It
needs some basic information like unit category etc.

Instructions:

1) Select add new product form from the main page and provide the required information.
2) Add new product.
3) Update.
Expected Result:

1) Errors may occur in a case if product with duplicate id is added.

Actual Result:
Confirmation of the store of the new item.

Project Document Page 50 of 51 03/14/19 f

Systematic Drug Store

4.6.4 Test Case: 4. Add purchases or new stock.

System: Systematic Drug Store

Test

The insertion record testing module shows the information of the purchases is provided correctly.
It needs some basic information like unit, category, quantity, purchase price, sale price, purchase
id etc.

Instructions:

1) Select add new stock/purchase form from the main page and provide the required
information.
2) Add all the products purchased against the same purchase id.
3) Add quantity and other required information.
4) Add new purchase or stock.

Expected Result:
1) Errors may occur in a case if some fields like quantity and any of the required is not
provided.
Actual Result:

Confirmation about new purchases or stock.

4.6.5 Test Case: 5. Make a sale.

System: Systematic Drug Store

Test:
This module is based on the selling one or more product to the customer. In this module it is
tested that all the information regarding to make a sale is provided like if the product is selected,
quantity to sale is entered customer type is selected etc.

Instructions:

1) Select “Make new sale” form.

2) Select an item to sell.
3) Provide quantity to sell.
4) Select the type of the customer (cash/debit).
5) If debit customer provide customer information.
6) Then click add sale and print bill.
Expected Result:

1) Product may not be selected

Project Document Page 51 of 51 03/14/19 f

Systematic Drug Store

2) Quantity may not be entered.

3) Customer type may not be selected
4) Customer information may not be provided
Actual Result:
Sale is made and invoice is printed.

5 Testing summary
Testing of every module fulfils the requirement of user to check into the system that either all the
options are working correctly or not. To check and test a module it must get the knowledge of
the working type it holds. Many checking techniques are gathered to make sure the testing
criteria but it is the suitable option for the testing authority to attempt the best one so that the
testing technique make sure itself the working of the system.

Project Document Page 52 of 51 03/14/19 f