Software Requirements

Specification
for

<QAU Pharmacy Management

System>

Version 1.0 approved

Prepared by

UMAR SHEHZAD (04162213005)

MUHAMMAD AMMAR (04162213001)

SAFYAN AHMED (04162213023)

<INSTITUTE OF INFORMATION TECHNOLOGY>

<02/04/2024>
Software Requirements Specification for <Project> Page iii

Table of Contents
Table of Contents....................................................................................................................... ii
Revision History......................................................................................................................... ii
1. Introduction.......................................................................................................................... 1
1.1 Purpose..................................................................................................................................1
1.2 Document Conventions..........................................................................................................1
1.3 Intended Audience and Reading Suggestions..........................................................................1
1.4 Project Scope.........................................................................................................................1
2. Overall Description.............................................................................................................. 2
2.1 Product Perspective................................................................................................................2
2.2 Product Features.....................................................................................................................2
2.3 User Classes and Characteristics.............................................................................................2
2.4 Operating Environment..........................................................................................................2
2.5 Design and Implementation Constraints..................................................................................2
2.6 User Documentation...............................................................................................................3
2.7 Assumptions and Dependencies..............................................................................................3
3. System Features................................................................................................................... 3
3.1 Patient Registration................................................................................................................3
3.2 Patient Record Details............................................................................................................4
3.3 Inventory Details----------------------------------------------------------------------------------
3.4 Retrieving Medicine
Information----------------------------------------------------------------
3.5 Medicine Expiry
Alert-----------------------------------------------------------------------------
3.6 Stock coming with existing information of
medicine-----------------------------------------
3.7 Adding new medicine to the inventory---------------------------------------------------------
3.8 Inventory Forcasting------------------------------------------------------------------------------
3.9 Patient
Reviews------------------------------------------------------------------------------------
4. External Interface Requirements........................................................................................ 4
4.1 User Interfaces........................................................................................................................4
4.2 Hardware Interfaces................................................................................................................4
4.3 Software Interfaces.................................................................................................................4
4.4 Communications Interfaces.....................................................................................................4
5. Other Nonfunctional Requirements.................................................................................... 5
5.1 Performance Requirements.....................................................................................................5
5.2 Safety Requirements...............................................................................................................5
5.3 Security Requirements............................................................................................................5
5.4 Software Quality Attributes....................................................................................................5
6. Other Requirements............................................................................................................. 5
Appendix A: Glossary................................................................................................................ 6
Appendix B: Issues List............................................................................................................... 6

Revision History
Name Date Reason For Changes Version
Software Requirements Specification for <Project> Page iv
SRS<Project Name> V. <0.0> Page 1

1. Introduction

1.1 Purpose
This Software Requirements Specification (SRS) document outlines the requirements for the
development of the Pharmacy Management System for Quality Assurance (QAU Pharmacy). The
system aims to streamline pharmacy operations, enhance inventory management, ensure patient
safety, and facilitate quality assurance processes. This SRS covers the core functionalities of the
pharmacy management system, including patient registration, inventory management, medicine
information, expiry alert, forecasting, stock maintenance, adding new medicines, and patient
reviews. This system is designed to automate and optimize various processes within the pharmacy,
ensuring efficient operations and compliance with quality assurance standards.

1.2 Document Conventions

This document uses different sizes of letters to make it easier to read and understand. For example,
big titles are numbered to make them easy to find, like "1. Introduction" and "3. System Features."
Smaller titles under them are also numbered with dots, like "1.1 Purpose" and "2.1 Product
Perspective," to help organize the information in a clear way. Font used in this document is “Times
New Roman” and Font size for main headings is 18, bold and font size for subheadings is 14 and
they are bold too. Text font size is 12.

1.3 Intended Audience and Reading Suggestions

The Pharmacy Management System (QAU Pharmacy) Software Requirements Specification (SRS)
is intended for various stakeholders, developers, project managers, pharmacists and pharmacy staff,
documentation writers Quality Assurance/Testers involved in the development, implementation,
testing, and usage of the software.

To understand the Pharmacy Management System’s guide, start by reading the Purpose and Scope
to know what the system is for. Then, follow the order of the document which tells different
readers, like developers or managers, where to look for the information, they need. It talks about
what the system does, how it’s built, and any special rules for making it work. There are also steps
on how to check if the system works right. In the end, it wraps up with a summary of how to build
and start using the system. This way, everyone can get a clear picture of how the system is
supposed to work and be used.

1.4 Project Scope

The scope of the Pharmacy Management System for Quality Assurance (QAU Pharmacy)
encompasses a comprehensive software solution designed to streamline pharmacy operations,
enhance patient care, and ensure regulatory compliance. This system aims to address various
aspects of pharmacy management, from patient registration to inventory control and feedback
collection.

Key Components and Features:

1. Patient Registration and Record Details.
SRS<Project Name> V. <0.0> Page 2

2. Inventory Management.
3. Medicine Information and Expiry Alert.
4. Inventory Forecasting.
5. Stock Management
6. Adding New Medicines to the inventory.
7. Reviews from Patients.
SRS<Project Name> V. <0.0> Page 3

2. Overall Description

2.1 Product Perspective

The pharmacy management system being specified in this Software Requirements Specification
(SRS) is a new, self-contained product designed to meet the specific needs of QAU Pharmacy. It is
not a replacement for any existing system but rather a comprehensive solution tailored to streamline
pharmacy operations and enhance patient care within the context of the pharmacy at QAU.
This system will serve as the primary tool for managing all aspects of pharmacy operations,
including patient registration, inventory management, medicine transactions (in and out), medicine
information, expiry alerts, forecasting, stock management, adding new medicines, and gathering
patient reviews.

2.2 Product Features

The pharmacy management system for QAU Pharmacy encompasses several major features
essential for efficient pharmacy operations and patient care:

Patient Management:

• Register patients and maintain their personal and medical history records.
• Facilitate easy retrieval of patient information during medication dispensing.

Inventory Management:

• Track inventory levels of medicines, including quantity, batch number, and expiry dates.
• Record transactions for medicines going in (purchases) and out (dispensing to patients).

Medicine Information Management:

• Store comprehensive details about each medicine, including generic name, brand name,
dosage, and usage instructions.
• Provide information on side effects, precautions, and contraindications to assist pharmacists
in patient counseling.

Medicine Expiry Alert:

• Notify staff about medicines nearing their expiry dates to prevent dispensing expired
medications.

Inventory Forecasting:

• Utilize historical data to forecast inventory needs and optimize stock levels to meet patient
demand without overstocking.

Stock Management:
• Enable efficient management of existing stock by allowing adjustments to quantities and
expiration dates.
SRS<Project Name> V. <0.0> Page 4

Adding New Medicines:

• Provide a mechanism for adding new medicines to the inventory, including data entry for
relevant details and validation processes.

Patient Reviews:

• Allow patients to submit reviews and feedback about medicines and services, enhancing
patient engagement and satisfaction.

These features are interconnected to support seamless pharmacy operations and ensure the
delivery of quality pharmaceutical services at QAU Pharmacy.

2.3 User Classes and Characteristics

The pharmacy management system for QAU Pharmacy is designed to cater to several user classes,
each with distinct characteristics:

Pharmacists:

• Characteristics: Highly trained professionals with expertise in medication management and

patient care.
• Frequency of Use: Regular and extensive use of the system for various pharmacy tasks.
• Functions Used: Access to all system functionalities including patient registration, inventory
management, medicine information, and transaction recording.
• Technical Expertise: Moderate to high technical proficiency required to navigate and utilize
the system effectively.

Administrators:

• Characteristics: Individuals responsible for overseeing the overall operations of the

pharmacy.
• Frequency of Use: Moderate use, mainly for system configuration, user management, and
generating reports.
• Functions Used: System configuration, user management, generating reports, and
overseeing system performance.
• Technical Expertise: Moderate technical proficiency required for system configuration and
report generation.

Patients:

• Characteristics: Individuals seeking pharmaceutical services from QAU Pharmacy.

• Frequency of Use: Occasional use for obtaining medicines and submitting reviews.
• Functions Used: Patient registration, viewing medicine information, receiving medicines,
and providing feedback.
• Technical Expertise: Basic technical skills required for interacting with the system interface.

Suppliers:

• Characteristics: External entities supplying medicines to QAU Pharmacy.

• Frequency of Use: Infrequent use, mainly for supplying medicines and updating inventory
information.
SRS<Project Name> V. <0.0> Page 5

• Functions Used: Providing information about supplied medicines and updating inventory
records.
• Technical Expertise: Basic technical proficiency required for submitting information
through the supplier interface.

Each user class plays a crucial role in the pharmacy's operation, with pharmacists being the
primary users responsible for day-to-day pharmacy activities. Administrators manage
system configuration and oversee overall performance, while patients interact with the
system to receive medicines and provide feedback. Suppliers contribute to maintaining
accurate inventory records by supplying medicines and updating relevant information.

2.4 Operating Environment

The software made for QAU Pharmacy must be good for use in busy pharmacies. It should work on
all kinds of computers found in pharmacies, whether they're big or small. This means it should
work with things like barcode scanners and printers too. Also, it should work with different types of
operating systems like Windows, macOS, and Linux because different pharmacy owners prefer
different systems. It should even work with different versions of these operating systems. If the
pharmacy already uses other software, the new one should work well with them without causing
any problems.

The software should be easy for the pharmacy staff to use. They should be able to use it on any
device, like a computer or tablet, and it should work the same on all of them. It should help the staff
with tasks like keeping track of inventory, recording when medicines are given out, and getting
information about medicines easily. It should also connect to barcode scanners to help manage
inventory and medicine distribution. It should give alerts if any medicines are about to expire so
that they can be taken care of before causing issues. The software should also be able to predict
how much inventory will be needed in the future based on past usage. And most importantly, it
should keep all the data safe and follow rules to keep patient information private and secure.

2.5 Design and Implementation Constraints

Design and making the pharmacy software has some rules to follow:

1. Following Rules:
The software must follow healthcare rules and standards to keep patient info private and to
follow pharmacy practices.

2. Keeping Things Safe:

We need to make sure only the right people can access patient records and other important info.
We also need to keep data safe from being stolen or changed.

3. Working with Different Computers:

The software needs to work with different types of computers, even if they're not very powerful.
It should also work with the computers the pharmacy already has and be ready for more in the
future.

4. Connecting with Other Programs:

Sometimes, the software needs to work with other healthcare programs, like electronic health
records. It is necessary to talk to these programs in a way they understand, so they can share info
easily.
SRS<Project Name> V. <0.0> Page 6

5. Using the Right Technology:

We might be limited in what technology and tools we can use to build the software. We need to
pick ones that work well with what we already have and what the team knows how to use.

6. Handling Data Right:

The software needs to be good at managing data, like keeping it organized and easy to find. We
need to pick the right tools to store and manage this data.

7. Taking Care of the Software:

We need to make sure it's easy to fix and update the software after it's done. We should also train
people how to use it properly and give them help when they need it.

8. Making it Easy to Use:

The software should be easy to use, even for people who aren't good with computers. It should
look nice and work well, so people can do their jobs without any trouble.

By following these rules when making the software, we can make sure it does what it's supposed to
and follows all the right rules and standards.

2.6 User Documentation

The user guide for the QAU Pharmacy software includes different parts to help users understand
how to use the software:

1. User Manual: Gives detailed instructions on using the software, like registering patients,
managing records, and handling medicine.

2. Online Help: Lets users get help while using the software, with tips for what they're doing.

3. Tutorials: Shows users how to do specific tasks with the software, using pictures and step-by-step
guides.

4. Medicine Information Guide: Gives lots of details about the medicines in the software, like how
they're used and any side effects.

5. Expiry Alert and Inventory Forecasting Guides: Helps users know when medicines are expiring
and how to predict what they'll need in the future.

6. Stock Management and Adding New Medicine Guides: Explains how to manage inventory and
add new medicines to the system.

7. Patient Reviews Guide: Shows how to collect and use feedback from patients to improve
pharmacy services.

The guides will be easy to access online or download from the software. They'll be easy to
understand, with clear language and organized information. They'll be available in different formats
to suit different users' preferences.

2.7 Assumptions and Dependencies

Assumptions:
SRS<Project Name> V. <0.0> Page 7

Availability of Patient Information:

It is assumed that patients will provide accurate and complete information during the registration
process. Any inaccuracies or omissions could affect the quality of patient care and medication
dispensing.

Reliability of Medicine Information Sources:

The system assumes that the sources providing medicine information, such as dosage, side effects,
and usage instructions, are reliable and up to date. Inaccurate or outdated information could lead to
improper medication administration.

Timely Notification of Medicine Expiry:

The system assumes that medicine expiry alerts will be triggered and received by staff members in
a timely manner. Delays or failures in receiving alerts could result in dispensing expired
medications to patients.

Dependencies:

Third-Party Software Components:

The project may depend on the integration of third-party or commercial components for
functionalities such as inventory forecasting or patient review submission. Any changes or updates
to these components could impact on the project's development and operation.

Development Environment:
The project's development may depend on specific development tools, libraries, or frameworks.
Changes to the development environment, such as updates or compatibility issues, could affect the
project timeline and deliverables.

Data Sources for Inventory Forecasting:

The accuracy of inventory forecasting relies on historical data and trends. The availability and
quality of data from sources such as sales records and inventory logs are crucial for accurate
forecasting.

External Systems for Patient Reviews:

Dependency exists on external systems or platforms for patient review submission. Integration with
these systems needs to be seamless and reliable to ensure proper functioning of the patient review
feature.

These assumptions and dependencies are vital considerations for the successful development and
operation of the pharmacy management system for QAU Pharmacy. Any deviations from these
assumptions or disruptions in dependencies could impact the project's outcomes and performance.
SRS<Project Name> V. <0.0> Page 8

3. System Features

3.1 Patient Registration

Use Case Name: Patient Registration

Priority: High

Participating Actors: Receptionist, Patient

Stimulus and Trigger: A new patient arrives at the medical facility and needs to register.

Entry Conditions: The receptionist is logged into the registration system, and the patient is
present at the medical facility.

Flow of Events:

 The receptionist welcomes the patient and requests necessary information for
registration.
 Patient provides personal information such as name, date of birth, address, contact
details, and insurance information.
 Receptionist enters the information into the registration system.
 System verifies the entered information for completeness and accuracy.
 If any information is missing or incorrect, the receptionist requests clarification or
completion from the patient.
 Once all necessary information is provided and verified, the system generates a
unique patient ID.
 Receptionist assigns the patient a primary care physician if necessary.
 Receptionist provides the patient with any necessary documents, such as consent
forms or privacy notices.
 The receptionist informs the patient about any additional paperwork that needs to be
completed and assists the patient in filling it out.
 Patient completes any required paperwork.
 The receptionist provides the patient with a summary of the registration process and
next steps.

Exit Conditions: The patient is successfully registered in the system, necessary paperwork is
completed, and the patient is informed about further steps in their healthcare journey.

Quality Requirements:

 Accuracy: Ensure that the information entered by the receptionist is accurately

captured and verified by the system.
 Efficiency: The registration process should be completed swiftly to minimize
waiting times for the patient.
 User-Friendliness: The registration system should be built-in for the receptionist to
navigate and input information efficiently.
 Reliability: The system should be available and functional during operating hours to
facilitate patient registration without delays.
SRS<Project Name> V. <0.0> Page 9

 Security: Patient information should be securely stored and accessible only to

authorized personnel to maintain confidentiality and compliance with privacy
regulations.

3.2 Patient Record Details

Use Case Name: Patient Record Management

Priority: High

Participating Actors: Pharmacy Staff, Pharmacist, Patient

Stimulus and Trigger: Patient arrives at the pharmacy for medication pickup or consultation,
or pharmacy staff initiates the record management process for a new or existing patient.

Entry Conditions: The pharmacy system is operational, and the patient is physically present,
or the pharmacy staff needs to access or update patient records.

Flow of Events Step by Step:

 A patient arrives at the pharmacy or pharmacy staff needs to access patient records.
 The pharmacy staff identifies the patient using their name, ID, or any other unique
identifier.
 The pharmacy staff accesses the patient's record from the pharmacy database or
system.
 If there are any updates or changes needed, the pharmacy staff makes necessary
amendments to the patient's record.
 If the patient is picking up medication, the pharmacy staff records the dispensed
medication and any associated instructions in the patient's record.
 If the patient has a consultation with the pharmacist, the details of the consultation
are recorded in the patient's record.
 The pharmacy staff verifies the accuracy of the updated information and ensures all
necessary details are recorded.

Exit Conditions:

The patient's record is updated and accurate.

The patient receives their medication and/or consultation successfully.
The pharmacy staff concludes the record management process.

3.3 Inventory Details

Use Case Name: View Inventory Details

Priority: High

Participating Actors: Pharmacy Staff

Stimulus and Trigger: The need to access inventory details arises when pharmacy staff want
to check the stock of available medicines and related products.
SRS<Project Name> V. <0.0> Page 10

Entry Conditions: The pharmacy staff must be logged into the system with appropriate
access permissions.

Flow of Events Step by Step:

 The pharmacy staff accesses the system interface.

 They navigate to the inventory management section.
 The system displays the option to view inventory details.
 The staff selects the "View Inventory Details" option.
 The system retrieves and displays the current stock details, including:
o Name of the product
o Quantity available
o Expiry dates (if applicable)
o Batch numbers (if applicable)
o Location within the pharmacy (if applicable)

 The staff can browse through the list of available products and their respective
quantities.
 If necessary, the staff can use search or filter options to locate specific products.
 The system provides options to sort the inventory list based on different parameters
such as alphabetical order, quantity available, etc.
 The staff reviews the inventory information as needed.

Exit Conditions: The pharmacy staff closes the inventory details view and continues with
their tasks.

3.4 Retrieving Medicine Information:

Use case name: Retrieve Medicine Information

Priority: High

Participating actors: Pharmacist, Customer

Stimulus and trigger: The need for information about a particular medicine arises, either
from the pharmacist or the customer.

Entry conditions: The system is operational and accessible to the pharmacist or customer.

Flow of events step by step:

 Pharmacist or customer initiates the request to retrieve information about a

medicine.
 The system prompts the user to input the name or code of the medicine.
 Pharmacist or customer provides the name or code of the medicine.
 The system validates the input and searches the database for relevant information.
 If the medicine is found, the system retrieves and displays its information, including
but not limited to:
o Generic name
o Brand name
o Dosage form
o Indications
SRS<Project Name> V. <0.0> Page 11

o Contraindications
o Side effects
o Interactions
o Storage instructions
 Pharmacist or customer reviews the information.
 If necessary, the pharmacist or customer can request additional details or
clarification.
 The system provides any additional information requested.
 The pharmacist or customer concludes the interaction.

Exit conditions: The requested information is provided satisfactorily, and the interaction is
concluded.

3.5 Medicine Expiry Alert:

Use case name: Medicine Expiry Alert

Priority: High

Participating actors:

Pharmacy staff (Primary actor)

System (Secondary actor)

Stimulus and trigger:

Stimulus: Expiry date approaching for medicines in the pharmacy inventory.

Trigger: System detects medicines nearing their expiry dates during routine checks.

Entry conditions:

The pharmacy system is operational and connected to the database containing

medicine inventory information.

Flow of events step by step:

 Pharmacy staff initiates the system, or the system automatically runs scheduled
checks for medicine expiry dates.
 System scans the medicine inventory database to identify medicines with expiry
dates within a defined threshold (e.g. 30 days).
 System generates a list of medicines that are nearing their expiry dates.
 The system displays an alert/notification to the pharmacy staff, indicating the list of
medicines with their expiry dates and quantities.
 Pharmacy staff reviews the alert and acknowledges receipt.
 Pharmacy staff takes necessary actions such as:
o Removing expired medicines from shelves.
o Checking for availability of replacements or ordering new stock.
o Updating inventory records.
 System logs the alert and actions taken by the pharmacy staff for future reference.
SRS<Project Name> V. <0.0> Page 12

Exit conditions:

The alert/notification is acknowledged, and necessary actions are taken by the

pharmacy staff to manage medicines nearing expiry.

3.6 Stock coming with existing information of medicine:

Use case name: Stock Management with Existing Medicine Information

Priority: High

Participating actors: Pharmacy Staff, Inventory Management System

Stimulus and trigger: Arrival of new stock

Entry conditions: The pharmacy receives a new batch of medicines with existing
information.

Flow of events step by step:

 Pharmacy staff receive the new stock of medicines from suppliers.

 The staff initiate the stock management process in the inventory management
system.
 The system prompts the staff to input the details of the received stock, including
batch number, expiration date, quantity, and existing information about the
medicines.
 Pharmacy staff scan or manually input the existing information of the medicines into
the system, including but not limited to name, dosage, manufacturer, active
ingredients, and any other relevant data.
 The system verifies the accuracy and completeness of the entered information.
 If any discrepancies are found, the system alerts the pharmacy staff to review and
correct the information.
 Once all information is accurately entered and verified, the system updates the
inventory database with the new stock information, associating it with the existing
medicine records.
 The stock is now available for dispensing to customers.

Exit conditions: The stock management process is completed, and the inventory database is
updated with the information about the new stock.

3.7 Adding new medicine to the inventory:

Use Case Name: Add New Medicine to Inventory

Priority: High

Participating Actors: Pharmacy Staff, Inventory Manager

Stimulus and Trigger: Pharmacy receives a new medicine to be added to the inventory.
SRS<Project Name> V. <0.0> Page 13

Entry Conditions: Pharmacy staff have access to the inventory management system and
authorization to add new items.

Flow of Events Step by Step:

 Pharmacy staff receive new medicine to be added to the inventory.

 The pharmacy staff accesses the inventory management system.
 The staff selects the option to add a new medicine to the inventory.
 The system prompts the staff to enter the details of the new medicine, including:
o Name of the medicine
o Manufacturer
o Batch number.
o Expiry date
o Quantity received.
o Purchase price.
o Selling price
 The staff enters the required information accurately.
 The system verifies the entered information for accuracy and completeness.
 If any information is missing or incorrect, the system prompts the staff to correct it.
 Once all information is accurately entered and verified, the system adds the new
medicine to the inventory database.
 The system updates the inventory levels accordingly.
 The staff receives a confirmation message indicating that the new medicine has been
successfully added to the inventory.

Exit Conditions: The new medicine is successfully added to the inventory, and the staff can
continue with their pharmacy operations.

3.8 Inventory Forecasting

Use Case Name: Inventory Forecasting

Priority: High

Participating Actors: Pharmacy Manager, Inventory Manager, System Administrator

Stimulus and Trigger: The need to forecast inventory levels based on historical data, current
demand, and future trends.

Entry Conditions: The system must have access to historical sales data, current inventory
levels, and any relevant external factors affecting demand (e.g. seasonal trends, promotions,
etc.).

Flow of Events Step by Step:

 The Pharmacy Manager or Inventory Manager initiates the inventory forecasting

process through the system interface.
 The system gathers relevant data including historical sales data, current inventory
levels, upcoming promotions, seasonal trends, and any other relevant information.
 Based on the collected data, the system performs analysis using forecasting
algorithms to predict future demand for each item in the inventory.
SRS<Project Name> V. <0.0> Page 14

 The system generates a forecast report detailing predicted inventory levels for each
item over a specified time horizon (e.g. weekly, monthly).
 The forecast report is reviewed by the Pharmacy Manager or Inventory Manager for
accuracy and feasibility. They may approve the forecast or request adjustments.
 Upon approval, the forecasted inventory levels are used to guide appropriate
decisions, reorder points, and inventory management strategies.
 The system continuously monitors actual sales data and inventory levels to compare
against the forecast, identifying any discrepancies or deviations.
 If significant deviations are detected, the system alerts relevant personnel to reassess
the forecast and make necessary adjustments.

Exit Conditions: The inventory forecasting process is completed, and the forecasted
inventory levels are implemented into the inventory management system.

Quality Requirements:

1. Accuracy.
2. Timeliness.
3. Scalability.
4. Flexibility.
5. Reliability.

3.9 Reviews From Patients:

Use Case Name: Patient Review Submission

Priority: High

Participating Actors:

Patient
Pharmacy Staff

Stimulus and Trigger:

The stimulus for this use case is when a patient wishes to provide a review or
feedback about their experience with the pharmacy services.

Entry Conditions:

The patient must have interacted with the pharmacy in some capacity to provide a
review.
The pharmacy must have a system in place for collecting and managing patient
reviews.

Flow of Events Step by Step:

 The patient visits the pharmacy website or mobile application.

 They navigate to the section dedicated to reviews or feedback submission.

 If the patient is not already logged in, they may need to log in or create an account.
 This step ensures that the review is attributed to the correct individual.
SRS<Project Name> V. <0.0> Page 15

 The patient selects the option to leave a review.

 They provide details about their experience, such as the service received, staff
behavior, waiting times, etc.
 Optionally, they may provide a star rating or numerical score to summarize their
experience.

 The pharmacy staff may review the submitted feedback for authenticity and
appropriateness.
 If necessary, they may reach out to the patient for clarification or validation.

 The submitted review may be integrated into the pharmacy's internal systems for
tracking and analysis.
 This data could be used for quality improvement initiatives or marketing purposes.

Exit Conditions:
The patient successfully submits their review.
Optionally, the review is verified and integrated into the pharmacy's systems.

Quality Requirements:

User-Friendly Interface:
The review submission process should be easy to follow for patients of all technical
abilities.

Secure Authentication:
The system should ensure the security and privacy of patient information during the
authentication process.

Accuracy and Reliability:

The system should accurately capture and reflect the feedback provided by patients without
distortion.

4. External Interface Requirements

4.1 User Interfaces

1. Patient Registration:
Fields for patient information like name, age, and contact details.
Form layout with labeled fields.
Making sure all fields for entering data look the same and are in line.
Showing clear messages if something is entered incorrectly.
Having buttons like "Save" and "Cancel" that are commonly used.
Using keyboard shortcuts to move around quickly.

2. Patient Records:
SRS<Project Name> V. <0.0> Page 16

Patient records are displayed in a table.

Search tool to find specific records easily.
Using a standard way to show data in tables.
Buttons to do things like see more details or edit records.
Keyboard shortcuts to move around faster.

3. Inventory Details:
Showing what medicines are available and how many there are.
List of medicines with all the details.
Making sure the information about inventory is easy to see.
Buttons to add new medicines or remove them.
Using keyboard shortcuts for managing inventory.

4. Medicine Information:
Giving lots of details about each medicine.
Tabs to quickly find information about dosage, how to use it, and more.
Organizing information clearly.
Buttons like "Print" and "Close" for common tasks.
Using keyboard shortcuts to move around quickly.

5. Medicine Expiry Alert:

Warning messages for medicines that will expire soon.
Pop-up messages or a notification bar to show the alerts.
Making sure the alerts are easy to see and do something about.
Buttons to deal with the alerts.
Using keyboard shortcuts to get rid of alerts quickly.

6. Inventory Forecasting:
Showing predictions for how much medicine will be in stock.
Using graphs or charts to show trends.
Making sure the predictions are easy to understand.
Buttons to make forecasts or export data.
Using keyboard shortcuts for forecasting tasks.

7. Adding New Medicine:

Form for entering information about new medicines.
Fields to fill in like name and quantity.
Making sure the layout of the form stays the same.
Common buttons like "Save" and "Cancel."
Using keyboard shortcuts for entering data quickly.

8. Patient Reviews:
Showing reviews and ratings from patients.
Section to easily read through reviews.
Making sure the reviews are easy to read.
Buttons to see more reviews or write one yourself.
Using keyboard shortcuts to go through reviews faster.

Each part of the interface has rules to follow, so it works well, is easy to use, and helps people do
things quickly.
SRS<Project Name> V. <0.0> Page 17

4.2 Hardware Interfaces

1. Patient Registration Terminal:
Easy-to-understand Features: Simple ways for patients to register, like using touchscreens or
keyboards.
Physical Traits: Includes a screen, input devices (like touchscreens or keyboards), and a
computer or tablet.
Data Interaction: The software collects patient information, like personal details and medical
history.
Communication Method: The terminal talks to the software using regular wired or wireless
connections.

2. Inventory Management System:

Simple Features: Keeps track of things like how much stock there is and when shipments come
in.
Physical Traits: Uses tools like barcode scanners, and label printers to track inventory.
Data Interaction: The software checks and updates inventory, follows where medicines go, and
warns if stocks are low.
Communication Method: Talks to scanners and printers using common methods like USB,
Bluetooth.

3. Medicine Information System:

Simple Features: Shows detailed information about medicines, like how much to take and what
side effects there are.
Physical Traits: Uses screens to display medicine details.
Data Interaction: The software gets medicine details from a database and shows them.
Communication Method: Talks to the database using usual ways like SQL.

4. Patient Review System:

Simple Features: Lets patients share thoughts about medicines or services they got.
Physical Traits: Can be machines where patients answer questions or online forums on computers
or phones.
Data Interaction: The software keeps track of what patients say for looking at and getting better.

These hardware setups make sure that the software and physical pieces work well together for
things like patient registration, inventory keeping, medicine details, and patient thoughts.

4.3 Software Interfaces

The QAU Pharmacy system works with different computer programs to handle patient records,
inventory, and information about medicines easily. Here's how it does it:
1. Database Management: It stores and manages information about patients, medicines, and
inventory in databases like MySQL.
2. Operating System: It runs on Windows, Linux, or macOS to do things like managing files and
sharing resources.
3. External APIs: It gets more details about medicines, like what they're made of, from other
sources.
4. Notification Services: It sends reminders about when medicines are going to expire through
email, text messages, or notifications on your phone.
5. User Interface Libraries: It creates easy-to-use screens and buttons using libraries like Qt or
Tkinter.
SRS<Project Name> V. <0.0> Page 18

6. Integration with EHR Systems: It connects with other systems that keep track of patient records
electronically.
7. Security and Authentication: It makes sure that only authorized people can use it by using
services.

Information is shared safely between these parts of the system using formats like JSON or XML.
All of this helps keep track of patients, inventory, and medicine information very well.

4.4 Communications Interfaces

1. Patient Registration and Records:
Method: Website
What it does: Patients sign up and see their records on a safe website.
Safety: Data is coded to keep it safe.
Speed: It's quick with fast internet.
Keeping Up: Records stay up to date right away.
2. Inventory Details and Management:
Method: Network Server
What it does: Checks and handles inventory using network servers.
Standard: It uses HTTP/HTTPS to move data.
Safety: Only users can access it, and it's secure.
Speed: It's fast with a good network connection.
Keeping Up: Inventory info stays current with regular updates.

3. Medicine Info and Expiry Alerts:

Method: Website and Email
What it does: Shows medicine details online and sends alerts by email.
Standard: Uses API’s for emails.
Safety: You need to log in safely, and emails are coded too.
Speed: Emails come right away.
Keeping Up: Medicine expiry info updates automatically.

4. Inventory Forecasting and Stock Management:

Method: Network Server
What it does: Predicts and handles stock using network servers.
Standard: Uses HTTP/HTTPS for moving data.
Safety: Controls who can deal with the stock.
Speed: Moves data quickly for accurate forecasts.
Keeping Up: Regular updates for precise predictions.

5. Adding New Medicine and Patient Reviews:

Method: Website
What it does: Puts new medicines in stock and lets you see patient reviews on a website.
Standard: Moves data with HTTP/HTTPS.
Safety: You need to log in safely, and reviews are coded.
Speed: Updates happen right away.
Keeping Up: Automatically syncs with the databases.

These ways of connecting make sure QAU Pharmacy runs smoothly, keeping data safe, updates
quick, and communication efficient.
SRS<Project Name> V. <0.0> Page 19

5. Other Nonfunctional Requirements

5.1 Performance Requirements

5.1.1 Patient Registration and Record Details:

The system should respond to patient registration requests within 5 seconds to ensure a
seamless user experience.
Patient record retrieval should be instantaneous, with a maximum response time of 2
seconds, enabling pharmacists to access patient information swiftly during consultations.

5.1.2 Inventory Details and Medicine Management:

Retrieving inventory details, including current stock levels and medicine information,
should take no longer than 3 seconds to support efficient inventory management.
Recording medicine transactions (in and out) should have minimal latency, with transactions
processed within 2 seconds to maintain real-time inventory accuracy.

5.1.3 Medicine Expiry Alert and Inventory Forecasting:

Medicine expiry alerts should be generated in real-time as soon as the expiration date is
within the predefined threshold (e.g. 30 days). Notifications should be delivered
immediately to relevant personnel.
Inventory forecasting computations should be completed within 10 seconds, considering
historical data analysis and forecasting algorithms, to provide timely insights for inventory
planning and management.

5.1.4 Adding New Medicine to the Inventory:

The process of adding new medicines to the inventory should be efficient, with the system
capable of accepting and processing new medicine entries within 5 seconds. This ensures
that new medicines can be promptly integrated into the inventory.

5.1.5 Reviews from Patients:

Patient reviews should be submitted and processed in real-time, with the system able to
record and display patient feedback within 3 seconds. This allows pharmacists to promptly
address any concerns or feedback provided by patients.

5.2 Safety Requirements

The safety rules for the QAU Pharmacy Management System make sure that patient
information stays private and safe. This means we keep their details secure with special
codes, and only authorized people can access them. We follow rules like HIPAA (Health
SRS<Project Name> V. <0.0> Page 20

Insurance Portability and Accountability Act of 1996) to protect this data. We also make
sure medicines are tracked well, stored correctly, and checked regularly to avoid mistakes
and keep everything accurate. We give clear information about medicines, warn if they're
expiring soon, and carefully check any new medicines we add to our stock to avoid
problems. We plan ahead for emergencies by keeping extra stock, and we listen to patients'
feedback to keep things safe. Following all these rules and getting the right certifications
shows that we're doing our best to keep everyone safe and healthy.

5.3 Security Requirements

The QAU Pharmacy Management System needs to make sure that patient information and
records stay safe and private. This means using strong codes to keep data safe, like putting a
lock on it. Only the right people should be able to get in. We also need to follow rules, like
HIPAA, to keep patient details private. When medicines come in or go out, we should keep
a record of it, and make sure nobody messes with the records. We also need to protect
information about medicines and when they expire, by using special codes and making sure
only the right people can see it. When we add new medicines to our stock, we should check
if they're real and safe, and only let certain people do it. Patients can also give us feedback,
but we need to keep that safe too, so only the right people can see it. Following all these
rules and getting the right certifications shows that we're doing our best to keep everyone's
information safe and private.

5.4 Software Quality Attributes

The QAU Pharmacy System needs to be good in several important ways:

Easy to Use: It should be simple for both pharmacy staff and patients to understand and use
without needing much training. We'll measure this by asking people how happy they are
with the system and how quickly they can do common tasks.

Reliable: The system should work well all the time, with very few problems or times when
it doesn't work. We'll measure this by checking how often it's not working and how many
big problems happen.

Easy to Keep Up: It should be easy for developers to make changes and fix things in the
system without causing more problems. We'll measure this by seeing how long it takes to
fix things when they go wrong.

Strong: The system should be able to handle mistakes or unexpected things without
breaking. We'll test this by trying to break it in different ways and seeing if it can still work.

Safe: It should keep patient information safe and not let anyone who shouldn't see it get
access. We'll check this regularly to make sure it follows rules about keeping information
safe.

Accurate: The information in the system should be right and not have been mistaken. We'll
check this by making sure the information matches what's supposed to be there.

Always Available: The system should be ready to use whenever people need it, with very
little time when it's not working. We'll check this by making sure it's always working when
it should be and doesn't take too long to respond when someone tries to use it.
SRS<Project Name> V. <0.0> Page 21

6. Other Requirements

6.1.1 Database Requirements:

The system shall utilize a secure and scalable database management system (DBMS) to store
and manage patient records, inventory details, medicine information, and other relevant
data.
Data backups shall be performed regularly to prevent data loss in case of system failures or
emergencies.
The database design shall adhere to normalization principles to ensure data integrity and
minimize redundancy.

6.1.2 Legal Requirements:

The system shall comply with all applicable laws and regulations governing pharmacy
operations, including but not limited to medication dispensing, patient privacy, and data
protection.
Any legal disclaimers or notices required by regulatory authorities shall be prominently
displayed within the system.

6.1.3 Reuse Objectives:

Code reuse shall be encouraged to improve development efficiency and maintainability.

Modular design principles shall be followed to facilitate the reuse of software components
across different modules or future projects.

6.1.4 Usability Requirements:

The user interface shall be built-in and easy to navigate, catering to users with varying
levels of technical proficiency.
Help documentation and tool tips shall be provided within the system to assist users in
performing tasks and understanding system functionalities.

6.1.5 Integration Requirements:

The system shall support integration with external systems or third-party applications for tasks such
as electronic prescriptions, insurance claims processing, and laboratory results management.