Pharmazone Final SRS

Software Requirements
Specification
For
Pharmazone
Version 1.0
Prepared by
Group Name: F7
Afrasiab Khan F141FBCSE301 afrasiabkk@yahoo.com

Muhammad Adnan Zaib F141FBCSE311 adnanfui311@gmail.com
Aiman Mubarik F141FBCSE347 aimankayani812@gmail.com
Waniya Hassan F141FBCSE354 waniahassan15@gmail.com
Supervisor: Mr. Sherjeel Farooqui
Coordinator: Mr. Babar Yaqoob
Date: January 1st, 2018

Software Requirements Specification for <Project> Page ii
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 Product Scope.................................................................................................................................2
1.5 References.......................................................................................................................................3
2. Overall Description..................................................................................................................4
2.1 Product Perspective.........................................................................................................................4
2.2 Product Functions...........................................................................................................................4
2.3 User Classes and Characteristics.....................................................................................................6
2.4 Operating Environment...................................................................................................................8
2.5 Design and Implementation Constraints..........................................................................................8
2.6 User Documentation........................................................................................................................8
2.7 Assumptions and Dependencies.......................................................................................................9
3. External Interface Requirements..........................................................................................11
3.1 User Interfaces..............................................................................................................................11
3.2 Hardware Interfaces......................................................................................................................15
3.3 Software Interfaces........................................................................................................................16
3.4 Communications Interfaces...........................................................................................................16
4. System Features......................................................................................................................17
4.1 Android Application......................................................................................................................17
4.2 Desktop Software..........................................................................................................................17
4.3 Behavior Requirements…………………………………………………………………………...19
5. Nonfunctional Requirements................................................................................................25
5.1 Performance Requirements............................................................................................................25
5.2 Safety Requirements......................................................................................................................25
5.3 Security Requirements...................................................................................................................25
5.4 Software Quality Attributes...........................................................................................................25
Group Log……………………………………………………………………………………….27
Revision History
Name Date Reason For Changes Version
Software Requirements Specification for Pharmazone 1
1. Introduction
1.1 Purpose
The purpose of this document is to create a platform for patients/users to interact with the pharmacy
system for medication along same salt formula with different company products. The idea is unique
because of its nature that the system is a combination of desktop software and a mobile application.
By using this system the pharmacies can manage their inventory system in their pharmacies based on
desktop software and on other hand users can search the medicines of their choices using mobile
application and will have preferences on price and suggested ratings.
1.2 Document Conventions

Headings:
 Heading 1 Size: 20
 Heading 2 Size: 14
 Heading Style: Times New Roman
Content:
 Content Size: 12
 Content Style: Times New Roman
 Stress on Content: Bold
1.3 Intended Audience and Reading Suggestions

This respective SRS will be available for:
 Supervisors and Coordinators, to review the document.
 Intended audience of Pharmazone is of two types;
o Mobile User (use our Mobile assistance application)
o Pharmacists (use Desktop application for pharmacy inventory functioning)
The Users interested in a brief overview of the product should focus on the rest of Part 1
(Introduction), as well as Part 2 of the document (Overall Description), which provide a brief
overview of each aspect of the project as a whole.
Users who wish to explore the features of SRS in more detail should read on to Part 3 (Specific
Requirements), which expands upon the information laid out in the main overview. This part tells us
about the entire External Interface Requirements of our system like User Interfaces, Hardware
Interfaces, Software Interfaces and Communication Interfaces. It also tells us about Functional
Requirements and Behavior Requirements as well with the help of Use-case View. Else this part
would describe further technical details, including information on the user interface as well as the
hardware and software platforms on which the application will run.
Users interested in the non-technical aspects of the project should read Part 4 (Non-functional
Requirements) for further details, which cover performance, safety, security, and various other
attributes that will be important to users. Readers who have not found the information they are
looking for, should check Part 5 (Other Requirements), which includes any additional information
which does not fit logically into the other sections.
1.4 Product Scope

This project is a combination of a Mobile application and a Desktop application. System benefits
both pharmacists and user/customer in different manner. In Mobile application user/customer after
installing application will create a user profile where he/she can search medicines and can compare
their choice they made with the preferred suggested medicines of that type on bases of price and user
given ratings. Another feature will entertain user with daily dosage option in which he/she will enter
the bought medicine name and quantity along with daily dosage scheme to have track of the medicine
being used and remaining medicine. Various features are the part of this system to make it near
possible best product for human well-being. For better health facilities the system will provide equal
grounds to users and pharmacists. Through this system pharmaceutical industry and pharmacies will
be regularized and users as well as government will have check and balance on pharmacies. The
factor of third-party forgery and illegal manufacturing of medicines will eliminate to a certain extent
and it will be the major role of the system for society.
1.5 References
Medicine salt formulas and names will be gathered from different pharmaceutical companies, hospital
facilities and consulting doctors. Alternative knowledge will be gained from the following sources;
 British National Formulary (Offered By: British Medical Association)

 Pharmapedia Pakistan (Offered By: Pharma Developers)

 Medicoz (Offered By: fida.pk)
2. Overall Description
The following section presents an overall description of the Pharmazone. In particular, the product
has been put into perspective through a detailed assessment of the system, user, hardware, software
and communication interfaces and operational modes requirements. Further, characteristics of the
system’s end-users are discussed along with the identified system constraints and assumptions. To
conclude the section, an assigning of requirements has been outlined.
2.1 Product Perspective

The requirement described in this SRS is for Pharmazone. Pharma represents the pharmacists and
zone represents the stakeholders which are being involved directly or indirectly with pharmaceutical
industry. Pharmazone is comprised of desktop software and an android application.
Desktop software is solely for pharmacists to keep track of invoicing, inventory, stock control,
multiple users, accounting, profits, loss, diseases trend in local areas and vendor management. It is
flexible and adaptive software suited to medical shops, stores or pharmacies of any size.
An android application designed to support desktop software will be helpful for customers to create
a profile, view prices, medicine rating, dosage scheduling, medicine depletion alerts and stock of
medicines along with the location of pharmacies nearby. The main focus of this application is to
benefit the customer with different financial backgrounds to have equal health rights and quality
control in health.
2.2 Product Functions

The following list offers a brief outline and description of the main features and functionalities of the
Pharmazone. The features are split into two major categories: Essential features and Optional
features. Essential features are core to the application’s operation, whereas Optional features simply
add new functionalities. The optional features will only be implemented as time permits. The
functions are mixed of mobile application and desktop software.
2.2.1 Product features
Product features are as follow;
2.2.1.1 Multiple – Logins

System login interface, it will validate role of user under which kind of account he/she is handling the
system. E.g. Administrator, Accountant, etc.
2.2.1.2 Expiry and Near-Expiry Predictions
Desktop Software which will be implemented in pharmacies will pop alerts of medicines that are near
to expiry and will demand to take action on it whether administrator doesn’t take any action then
after expiry date system pop alert of expired medicine.
2.2.1.3 Stock Alerts
Product also have feature to show how much stock is left on the basis of sales and the listed stock in
the database.
2.2.1.4 Black-list Medicine Control
Black-list medicines are controlled by their batch number provided by the concerned companies.
2.2.1.5 Medicine Availability
When user search for medicine in the Pharmazone mobile application, available medicines will list
with similar salt formula and on bases of price difference and user ratings help customers along with
the location of pharmacies nearby with that particular medicine available.
2.2.1.6 Next Purchase Prediction
Desktop software will show next sale prediction on the basis of present sales and stock available in
the database.
2.2.1.7 User Profile
Pharmazone mobile application has a feature so the user of mobile application should have to create
a custom user profile to get alerts, can mention allergies to medicines and dosage function to keep
track of medicines in use and their possible depletion before time.
2.2.1.8 Online
The desktop software will be online so that the functioning logs and database can be managed and
update time to time and this data will be extracted and filtered to be available for mobile application
for medicine searches and stocks availability on nearby pharmacies.
2.2.1.9 Disease Trend
The rapid demand of a particular medicine will give an idea about a disease spread and its trend from
starting to totally cured.
2.2.2 Essential/Optional Features
Features Essential Optional

2.2.1.1 E
2.2.1.2 E
2.2.1.3 E
2.2.1.4 E
2.2.1.5 E
2.2.1.6 E
2.2.1.7 E
2.2.1.8 E
2.2.1.9 O
2.2.3 Desktop Application
 Intelligent early purchase prediction.

 Medicines Database.
 Stock alerts.
 Single Admin and different User profiles.
2.2.4 Mobile Application
 Medicine search.
 User Profile after installation.
 Medicine dosage scheme.
 Ratings from users.
2.3 User Classes and Characteristics
They are two core users of our system.

Seller/Desktop Software User
2.3.1 Super Administrator
 Can Login
 Edit sale record
 Delete record
 View sub-admin record
 Add new record
 Add new medicine record
 Logout
2.3.2 Sub-Admin
 Sub-Admin can login

 View Sales
 View Stock
 Delete Record
 Add new Record
 Edit Record
 Logout.
2.3.3 Employee
 Can Login
 Can view sales
 Print bill
 Logout
Customer/User
 Can Login
 Create profile
 Search medicine
 Rate medicine
 Dosage Scheme control
 Logout
2.4 Operating Environment

Desktop based software will operate in Pharmaceutical departments (i.e. Medical Stores) where
security issues regarding sensitive data or a human life is concerned. Desktop software run on any
given PC of 64-bit OS and android based application run on any android phone compatible 4.1.2
android version or above. The technologies that will be used for this tool are C# in .NET and visual
studio. Hardware required for this project will be Operating System including laptops, computers and
android phones mobile phones.
2.5 Design and Implementation Constraints
 Our main constraint is collecting Salt Formulas, because that’s difficult to collect number of
faces and search through a thousand of medicines from a database in a neon-seconds, it takes the
delay of approximate 1-5 seconds. Since the application is designated for desktop, no limited screen
size and resolution will be a major design consideration. Other constraints such as limited memory
and processing power are not also worth considering.
 Limited time, 6 months
 Learning new Language/Technology
2.6 User Documentation

The User Documentation of Pharmazone will be available all the time on internet with some guiding
so that every user can access the functionalities at any time for this purpose User Documentation is
very important as a user manual help.
2.6.1.1 Manuals
Pharmazone manuals will be available on internet just for the convenience of the users. The
instructions given in the help manual can be applied on the Pharmazone products to meet the user
needs in less and efficient means of time.
2.6.1.2 Video Manuals (if required)

Video Demo will also be provided for Pharmazone products, in which user can watch a streaming
video and learn how it works. It will prevent the user from reading and saves time.
2.7 Assumptions and Dependencies
Assumptions
Following are the assumptions

1. Project will be completed in 6 months.
2. All members will adapt new technology.
Risks
Following are the risks;

1. Tight time frame. The deadline doesn’t allow for any force major circumstances.
2. Part of the team is volunteers with no-money motivation, which may mean that you’ll have to
find and train new project participants.
Dependencies
3. Time Dependencies
As mentioned before, the features of Pharmazone are divided into two groups: Core features
must all be implemented in order for the application to be useful. Optional features, however, are not
critical to the function of the application. They are usability improvements and convenience
enhancements that may be added after the application has been developed. Thus, the implementation
of these features is entirely dependent upon the time spent designing and implementing the core
features. The final decision on whether or not to implement these features will be made during the
later stages of the design phase.
4. Hardware Dependencies
There is no as such hardware dependency for this project, but every computer must have a
minimum 1 GB ram 2.8 GHz processor and 10 GB hard drive and in contrast to android application
every user must have an android phone compatible 4.1.2 android version or above.
5. External Dependencies
1. Majority of the features presented in this system rely on the existence of the database.
2. We are using the database of Pharmacies for adding medicines.
3. Team Members will cooperate till the end of project.
4. University will help if stuck somewhere in project.
6. External Interface Requirements
6.1 User Interfaces

There are two user interfaces:
 Desktop Software Interface.
 Mobile Application Interface.
1. Desktop Software:
This application is preliminary for users at pharmacy stores where pharmacist will interact to our
system through a desktop software interface. Where pharmacy users will have multiple screens for
entering and viewing data in and from database of pharmazone centralized system. An interface is
for entering medicines stock to store in database of pharmazone and also to view blacklisted
medicines on that interface; pharmacist will he will have list of all medicines that are blacklisted in
our software to ensure safe medication.
2. Mobile Application:
Mobile application is for public use and will be connected to pharmazone centralized system. An
android application gives user a Sign In option to access his/her personal profile information and
stores information. By using this application user can easily search for medicine, nearest stores, either
medicine available at that stores, prices of medicine and ratings by users. Another feature of personal
profile is that user enter all information about his/her allergies and when he will buy his/her medicine
he will enter his daily dosage and total amount of medicine he bought and on that basis an alert
would be generated. User can search medicine along with salt formula.
6.2 Hardware Interfaces

Hardware interfaces are not applicable but hardware support is required as per criteria;
 Desktop software compatible with 64-bit OS minimum 1 GB Ram, 2.8 GHz Processor
and 10 GB hard drive.
 Android phone compatible 4.1.2 android version or above.
6.3 Software Interfaces

i. .NET
ii. Android SDK Tools
iii. MS SQL
iv. Windows OS
v. Android OS
6.4 Communications Interfaces
i. Intelligent pop alerts

ii. Emails
7. System Features
Pharmazone is divided into two interfaces: Android and Desktop application. Their functionalities
differ from each other. This section includes all requirements that specify all actions of the system.
7.1 Android Application
a) Registration and Login
After the installation of android application, welcome screen appears then a new user of
Pharmazone can register itself whereas the existing users can login with their ID. All the users
have access to their profile.
 If the user registers, a screen will appear where the user enters all his required information.
b) Home Screen
After the user logs in, Home screen shall appear which will include these options: Search
Medicine and Medicine Schedule.
i) Search Medicine
User can search the medicines in search bar by name or by salt formula and a full description
of medicine will be displayed along with similar tab on bottom which will have the medicines
of same salt formula searched by user with different companies and will have their prices and
ratings given by the users.
ii) Medicine Schedule
On home screen medicine schedule option will be displayed in which user can specify his/her
medicine regularity schedule with its name, daily dosage, tablets in possession and can also
specify time on which the application should alarm to give reminder of medicine intake time.
System will give alerts when dosage of 3 days will be remaining to refill or purchase
medicines before medicine ends.
7.2 Desktop Software
a) Welcome Screen
A Welcome screen shall appear that will display Login for the users. Once user logs in he/she can
use the features of this desktop application with respect to their account type permissions given
by authorities. After successful login, user will be directed to the Home Screen.
b) Home Screen
The Home Screen of this interface will contain different tabs with the functionalities of sale
record, purchase record, inventory, prediction, billing, disease trend and graphs.
i) Sale Record
On home screen sale record option will be displayed in which account user can see the sale
record of medicines with the periodic selection menu from weekly, fortnightly, monthly up to
1 year.
ii) Purchase Record
On home screen purchase record option will be displayed in which account user can see the
purchase record of medicines with the periodic selection menu from weekly, fortnightly,
monthly up to 1 year.
iii) Inventory
On home screen inventory option will be displayed in which account user can see inventory
record and can perform different tasks like editing, deletion, updating and insertion.
iv) Prediction
On home screen predictions option will be displayed in which account user can predict the
next purchase ratio on the basis of previous sales in accordance of periodic selection of sales
from weekly, fortnightly, monthly up to 1 year options.
v) Billing
On home screen billing option will be displayed in which account user can enter the ID of
medicine, product name, quantity and price. When account user press print bill the grand total
will be calculated of items sold and bill will be printed for customer use on other hand the
items selected in billing will be cut from inventory and inventory will automatically update.
vi) Disease Trend
On home screen disease trend option will be displayed in which account user can see the
disease trend in the area on the criteria of particular medicines sudden high rate of sale from
disease outbreak till cure.
vii) Graphs
On home screen graphs option will be displayed in which account user can see the sale,
purchase and profit graphs in periodic manner; weekly, fortnightly, monthly up to 1 year.
7.3 Behavior Requirements
7.3.1 Use Case Diagrams
i. Android Application
ii. Desktop Software
7.3.2 Textual Use Cases
Use Case 01:

Name: Log in.

Actor: Application Users.
Precondition: Desktop software and Mobile application must install on the system/mobile.
Post condition: Profile of user already exists.
Main Success Scenario: User login successfully.
Actors Action System Response
2. The system prompts the user for username

1. The user selects ‘Log in’ from device display. and password.
4. The system will verifies entered data from
the database and system enables access to the
3. The user will enter username and password. user account.
Alternatives:
1. If user is unable to login, he must click the ‘Forgot Password’ button, verify his identity and then
Login again.
Use Case 02:

Name: User Profile Generation/Signup.
Precondition: Desktop software and Mobile application must install on the system/mobile.
Post condition: Application should be properly working.
Main Success Scenario: User successfully creates personal user profile.
1. Installed Pharmazone application on mobile. 2. User profile form appears to fill.
3. Fill personal information in user profile form. 4. Accept and create user profile.
Alternatives:
1. User didn’t install the application.
2. Application doesn’t work properly.
Use Case 03:
Name: Profile update.
Precondition: Profile of user already exists.

Post condition: Must enter medicines in use to the profile whenever bought for better functioning.
Main Success Scenario: User profile updated with medicines in use.

1. The user selects update profile from device 2. The system prompts user to update the
menu. changes in his profile.
4. The device enables access to the system
3. The user makes desired changes.
according to access control.
Alternatives:
1. Same detail already exists in database.
Use Case 04:

Name: Inventory update.
Actor: Super administrator.
Precondition: Pharmazone must be installed on desktop/laptop.
Post condition: Access to adding new records is granted.
Main Success Scenario: New record added successfully.
1. Add new medicine. 2. Check medicine entry and expiry date.
Alternatives:
1. Either the Pharmazone is not installed on system.
2. The medicine is added before.
Use Case 05:

Name: View Sales Report.
Actor: Super administrator, Sub-admin.
Precondition: Database is managed successfully.
Post condition: All the sales are updated successfully.
Main Success Scenario: Wants to view the Sales Report to perform further action.

1. Super admin or sub-admin Staff selects the
2. The system will fetch the Sales report and
Sales Report of the concerned Retail Outlets
display it to user.
from Report Option in the application.
Alternatives:
1. When the user clicks on ‘Sales Report’ and it doesn’t show up, he will send an email to
Executive to inquire about the reason.
Use Case 06:

Name: Medicine Scheduling.
Actor: Application user.
Precondition: User must enter his daily dosage in profile.
Post condition: User Profile must be existed.
Main Success Scenario: Medicine dosage scheduling successfully done.

2. Generate the list of medicines with respect
1. Enter medicine name
to their dosage.
4. Update the dosage records in the database.
3. Select the dosage level
Alternatives:
1. Wrong medicine name is entered.
2. No user profile is created.
Use Case 07:
Name: Log out.
Actor: All Users.
Precondition: The user must be using the software.
Post condition: The user must log in.
Main Success Scenario: To disable user access to the system through an electronic device.
1. The user selects Log out from device menu. 2. Disable access to the system.
Alternatives:
1. If user is unable to logon the system records if no activity is performed in the profile the system
will log him out automatically.
8. Non-Functional Requirements
8.1 Performance Requirements

<If there are performance requirements for the product under various circumstances, state them here and
explain their rationale, to help the developers understand the intent and make suitable design choices.
Specify the timing relationships for real time systems. Make such requirements as specific as possible. You
may need to state performance requirements for individual functional requirements or features.>
8.2 Safety Requirements

a) This system only allows its users to access the system by providing unique username and
password to each account user.
b) The data transmission between the system and server is secure.
8.3 Security Requirements

System use your email address only for making the app better and never share any user information
with any third-party.
8.4 Software Quality Attributes

The graphical user interface of Pharmazone is to be designed with usability as the priority. The
system will be presented and organized in a manner that is both visually appealing and easy for the
user. There will be notifications, intelligent predictions and alerts for system users to take the further
actions.
Overall, the system balances both the ease of use and the ease of learning. The layout and the UI of
the system will be simple enough that users will take no time to learn its features and navigate
through it with no difficulty.
a) Flexibility
Pharmazone desktop and mobile application is flexible to add new standard features whenever
required.
b) Integrity
The modules of Pharmazone are integrated and tested per requirements.
The system shall perform correctly and rationally on different sets of input from the user.
c) Availability and Reliability
Super Administrator can view reports anytime.
d) Portability
The product is portable as it can be used anytime from anywhere. The product can be accessed from
anywhere using internet. The software is coded in the world’s standard language that most of the
systems will adopt and executes the desktop software and mobile application with respect to their
hardware.
e) Completeness
The project should be completed in its module according to Functional Requirements. Product
should be able to work efficiently in case of any error and ready for immediate actions to be
performed.
Complete data format of the software and hardware should be defined in specifications document.
f) Maintainability
The standard development of desktop software and mobile application can be edited accordingly
with the passage of time.
Disclaimer
Information provided in mobile application is for general and educational purposes only and
cannot be substituted for any professional medical advice. For any medical advice and
prescription, please consult a medical professional.
Group Log
Serial No. Participants Meeting Agenda Skills Required Meeting Minutes

01 Afrasiab Khan, Adnan Zaib, Aiman
Mubarik, Waniya Hassan
02 Afrasiab Khan, Adnan Zaib, Aiman 40:00

Pharmazone Final SRS

Uploaded by

Copyright:

Available Formats

Pharmazone Final SRS

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pharmazone Final SRS

Uploaded by

Copyright:

Available Formats

Software Requirements

Afrasiab Khan F141FBCSE301 afrasiabkk@yahoo.com

Supervisor: Mr. Sherjeel Farooqui

Coordinator: Mr. Babar Yaqoob

Date: January 1st, 2018

1.2 Document Conventions

1.3 Intended Audience and Reading Suggestions

1.4 Product Scope

 British National Formulary (Offered By: British Medical Association)

 Pharmapedia Pakistan (Offered By: Pharma Developers)

2.1 Product Perspective

2.2 Product Functions

2.2.1 Product features

Product features are as follow;

2.2.1.1 Multiple – Logins

2.2.1.2 Expiry and Near-Expiry Predictions

2.2.1.3 Stock Alerts

2.2.1.4 Black-list Medicine Control

2.2.1.5 Medicine Availability

2.2.1.6 Next Purchase Prediction

2.2.1.7 User Profile

Features Essential Optional

2.2.3 Desktop Application

 Intelligent early purchase prediction.

2.2.4 Mobile Application

2.3 User Classes and Characteristics

They are two core users of our system.

2.3.1 Super Administrator

 Sub-Admin can login

2.4 Operating Environment

2.5 Design and Implementation Constraints

2.6 User Documentation

2.6.1.2 Video Manuals (if required)

2.7 Assumptions and Dependencies

Following are the assumptions

Following are the risks;

6. External Interface Requirements

6.1 User Interfaces

6.2 Hardware Interfaces

6.3 Software Interfaces

6.4 Communications Interfaces

i. Intelligent pop alerts

Use Case 01:

Name: Log in.

Actors Action System Response

2. The system prompts the user for username

Use Case 02:

Actors Action System Response

1. Installed Pharmazone application on mobile. 2. User profile form appears to fill.

Precondition: Profile of user already exists.

Actors Action System Response

Use Case 04:

Actors Action System Response

1. Add new medicine. 2. Check medicine entry and expiry date.

Use Case 05:

Main Success Scenario: Wants to view the Sales Report to perform further action.

Actors Action System Response

Use Case 06:

Actors Action System Response