POLITEHNICA UNIVERSITY OF BUCHAREST

10

SOFTWARE ENGINEERING

PHARMACY
Software Requirements Specification

Team:
Crina BARBU, MSE I
Alina DICU, MSE I
Șerban-Ionuț GEORGESCU, MSE I
Dragoș SAVA,MSE I

Coordinator: Date created:

NICOLAE GOGA Friday, January 26, 2018
 Delivery report

Delivery Report
(will be delivered along with the project)

Name Group Project implementation [%, reason] Signature

_______________ ______ ____________________________ _________

____________________________
____________________________

_______________ ______ ____________________________ _________

____________________________
____________________________

_______________ ______ ____________________________ _________

____________________________
____________________________

Delivery date:
__________________________________

2
 SRS

Table of Contents

POLITEHNICA UNIVERSITY OF BUCHAREST..........................................................1

SOFTWARE ENGINEERING..................................................................................1
PHARMACY...........................................................................................................................1
DELIVERY REPORT............................................................................................2
TABLE OF CONTENTS.........................................................................................3
REQUIREMENTS ANALYSIS..................................................................................4
1. Introduction....................................................................................................................4
1.1. Purpose...................................................................................................................4
1.2. History.....................................................................................................................4
1.3. Scope......................................................................................................................4
1.4. Definitions, Acronyms and Abbreviations................................................................4
1.5. References..............................................................................................................4
1.6. Structure..................................................................................................................4
2. General description........................................................................................................5
2.1. Product Description.................................................................................................5
2.2. Product Functions...................................................................................................5
2.3. User description......................................................................................................5
2.4. Constraints..............................................................................................................5
2.5. Assumptions and Dependencies.............................................................................5

3
 SRS

Requirements Analysis
1. Introduction
1.1. Purpose

The purpose of the present document is to present the software requirements specification of the
project “Pharmacy”.

1.2. History

First draft: November 17th, 2011.

1.3. Scope

The “Pharmacy” application is intended to be used by any pharmacy, managers and employees
for managing their daily operations: orders, suppliers, supplies, active ingredients, product
catalogs, stock, manufacturers, sales and reports.

1.4. Definitions, Acronyms and Abbreviations

DB = database
SRS = Sofware Requirements Specifications
(To be populated furthermore )

1.5. References

1. Nicolae Goga, Software Enginereeing Lecture notes, Fils, 2011

2. IEEE STD-830-1993, IEEE Recommended Practice for Software Requirements Specification.
3. Luca Dan Serbanati, Crenguta Madalina Bogdan, Programare orientate spre obiecte cu
exemplificari in limbajul Java,Vol. 2, editura Politehnica, 2010.
4. Christian Mancas, Fundamente Teoretice ale modelului relational al datelor, editura Ovidius
University Press, 2007.
5. Luca Dan Serbanati, Programming Paradigms Lecture notes, Fils, 2011.
6. Christian Mancas, Advanced DataBases Lectures notes, Fils, 2011.
7. Legislatie Farmaceutica, http://www.revistagalenus.ro/legislatie-farmaceutica.html

1.6. Structure

Chapter 2 provides the general description of the “Pharmacy” project: product description and
functions, user description, constraints, assumptions, and dependencies.

Chapter 3 presents the system requirements : external interface, functional, and performance
requirements, design constraints, software system attributes, and other system requirements.

Finally, Appendices include: Interview with the customer, System diagram, Use Cases Diagrams,
Class Diagrams, Sequence Diagrams, State Diagrams, Document Evolution, Report regarding
team meetings, and Conclusions regarding the activity.

4
 SRS

2. General description
2.1. Product Description

Pharmacy is a lightweight browser based Java web application created for managing the stock
and sales of a small pharmacy. It's user base and target audience consists of managers of
pharmacies, pharmacists and equivalent categories of pharmacy employees.

Pharmacy is primarily designed for use at POS. However, it's browser based nature and low
system requirements for the clients allows it to be used on virtually any Internet-connected device.
There is no complex roll-out procedure for deployment in large organizations, it requires little
space on the client device, all future updates are made seamlessly at the server and automatically
delivered to the clients, and cross-platform compatibility is very high.

2.2. Product Functions

Pharmacy is intended to be used by managers of pharmacies, and other qualified employees

(pharmacists) for the day-to-day activities of the respective pharmacy: managing stock, sales,
suppliers, product categories, active ingredients, and reports.

At launch (accesing the URL in a browser), the user is presented with a login screen; upon login,
based on the category of the user (pharmacist, manager or administrator), a different page will be
shown, with the valid operations for each category of user. Searching the products (by different
criteria), viewing products and associated information, adding products, modifying price and stock
(upon a sale) for existing products, displaying the list of sales, placing orders for new products are
all intended uses of Pharmacy.

2.3. User description

As Pharmacy's intended user base does not require a high technical level or knowledge of
computer applications, Pharmacy should be designed to be simple and user friendly. All screens
must offer few, intelligible choices of operations, the colour scheme is user-friendly, and the overall
risk of an user mistake is kept low. Furthermore, critical operations (adding users, modifying
everything in the database) is restricted to Administrators.

2.4. Constraints

Pharmacy requires the previous installation of a Javascript-enabled web browser on the client
device.

The results of the database operations that Pharmacy performs are considered critical (the client
will not tolerate any errors in sales or stock).

2.5. Assumptions and Dependencies

The application can run on several operating systems. Most POS computers in target pharmacies
run Windows XP, Vista or 7, and the predominant Internet browsers are Mozilla Firefox, Google
Chrome and Microsoft Internet Explorer.

5
 SRS
3. Specific requirements

3.1. Functional requirements

ID Affected entity Description

FR1 Pharmacist Should have a login interface to log to the system.
FR2 Pharmacist Should have a logout interface to log off from the system.
FR3 Pharmacist Should have a textbox or a combobox from which he can
enter search criteria or select a entity type based on which
a search can be made.
FR4 Pharmacist After the search button has been pressed the information
should be displayed.
FR5 Pharmacist A list of the current items of the command should be
always displayed.
FR6 Pharmacist He can cancel the current list of items he can sell.
FR7 Pharmacist He should be able to make the sell.
FR8 Manager Should have a login interface to log to the system.
FR9 Manager Should have a logout interface to log off from the system.
FR10 Manager He can see the current stocks information about every
product.
FR11 Manager He can make reports on time intervals or on product
information.
FR12 Manager He can place orders to the providers of products.
FR13 Administrator The same requirements that the manager have.
FR14 Administrator He can update information about managers and
pharmacists.
FR15 Administrator He can make inactive a product so the pharmacist and
managers can’t sell it or buy it.
FR16 Login Button Login and Cancel, and two text labels User and
Password which have in the right side two textbox to
introduce the information.
FR17 Logout Special button, which will display an message box to ask if
are you sure you want to stop that action.

3.2 Performance requirements

ID Affected entity Description
PR1 The quantity It should be used a precise measurement system, do the
type of data that is being processed.

3.3 Interface requirements

ID Affected entity
IR1 Pharmacist The user interface should be constructed from big
button for easy use with a touchscreen.
IR2 Pharmacist The interface should have bright colors.
IR3 Administrator Interface easy to use.
3.4 Operational requirements
3.5 Resource requirements
ID Affected entity Description
RR1 Pharmacist The pharmacist interaction should be constructed keeping

6
 SRS
in mind that it will run on a POS(point of sale).
RR2 Administrator He should interact with the system without being forced to
install any external resource, (an operating system and a
browser should be the minimum requirements to run it).
RR3 Manager Because of his special roll, he will usually be forced to use
an office solution so the system should be made keeping
in mind the minimum requirements of the other software
he’s going to use.
RR4 System

3.6 Verification requirements

ID Affected entity Description
VR1 System If there are more application instantiated and every one of
them does an operation the server should have no
problem.

3.7 Acceptance-Testing requirements

3.8 Portability requirements
ID Affected entity Description
PR1 administrator He can log to the system from anywhere.
PR2 pharmacist Because POS usually run on Windows, is no need to
make it portable on other systems.
PR3 manager He can only log to the system only at the office.

3.9 Maintainability requirements

3.10 Reliability requirements
ID Affected entity
PR1 Pharmacist If the internet connection fails he should be able to sell and
the server should receive the information later after the
connection has restored.
Pr2 System Should be able to work with concurrent interrogation on
the database.

3.11 Security requirements

ID Affected entity
SR1 Administrator Only the administrator should have online access to the
information that the system can provide.
SR2 Manager & They should have no access to the system from anywhere
pharmacist except the sell point.
SR3 System The pharmacist should have precise rolls, that is different
from that of the manager or administrator.
SR4

3.12 Safety requirements

3.13 Other Quality requirements
3.14 Documentation requirements

7
 SRS
A1. Interview with the customer
1. The application must have a login system
a. The application must be able to make the difference between three types of users :
administrators, managers and pharmacists
b. The application must be able to access a data base which will contain the
information about the users

2. The application must provide different content for each type of user
a. The administrator must have the possibility to modify all kinds of information into
the data base
a.i. The application must allow the administrator to make a search by a
chosen criteria
a.ii. The application must allow the administrator to introduce new
information into the data base
a.iii. The application must allow the administrator to modify the price and
stock for a given product
b. The manager must be able to do the same functions as the administrator along with
some other higher permissions
b.i. The application must allow the manager to run available reports
b.ii. The application must allow the manager to place orders
b.iii. The application must allow the manager to see the amount of
available products
c. The pharmacist must have limited rights
c.i. The application must allow the pharmacist to search for information
into the data base
c.ii. The application must allow the pharmacist to modify the stock for a
product in case of a sale
c.iii. The application must allow the pharmacist to display the list of sales

3. The application must have Internet access

a. The application must allow the manager to access the supplier’s web pages

8
 SRS

A2. System diagram

9
 SRS
A3. Use case diagram

A4. Class diagram

10
 SRS
A6. State diagrams
1. Login

11
 SRS
2. Display information (Pharmacist)

12
 SRS
3. Sell products (Pharmacist)

13
 SRS
A8. Report regarding team meetings

Date: October 27th 2011

Participants: Barbu Crina, Dicu Alina
Results:
- the purpose of the application
- the Entity-Relationship Diagram for the application’s data base

Date: November 3rd 2011

Participants: Barbu Crina, Dicu Alina, Georgescu Serban
Results:
- the types of users
- the use cases for each type of user
- the template for some reports

14