You are on page 1of 16

Software Requirement Specifications

Medicine.ai

Version: 2.0
Project Code F23-414D

Supervisor Sir Farrukh Hassan Syed

Co Supervisor

Shayan Hassan 20K-1873


Project Team Muhammad Hasan
20K-1873
Mohsin Ahmed 20K-0123

10-December-2023
Submission Date
Document History
Versi Name of Person Date Description of change
on

1.0 Shayan Hassan 4-12-2023 Document Created


2.0 Mohsin Ahmed 6-12-2023 Added Use Cases
Distribution List
Name Role
Dr Farrukh Hasan Syed Supervisor

Co- Supervisor

Document Sign-Off
Version Sign-off Authority Sign-off Date
2.0

Table of Contents

1. INTRODUCTION 7

1.1. Purpose of Document 7 1.2. Intended Audience 7 1.3


Abbreviations........................................................................................................................................7 1.4.
Document Convention 7 2. OVERALL SYSTEM DESCRIPTION 8

2.1. Project Background 8 2.2. Project Scope 8 2.3. Not In Scope 8 2.4. Project Objectives 8 2.5.
Stakeholders 8 2.6. Operating Environment 8 2.7. System Constraints 8 2.8. Assumptions &
Dependencies 8 3. EXTERNAL INTERFACE REQUIREMENTS 9

3.1. Hardware Interfaces 9 3.2. Software Interfaces 9 3.3. Communications Interfaces 9 4. FUNCTIONAL
REQUIREMENTS 10

4.1. FUNCTIONAL HIERARCHY 10

4.2. Use Cases 10 5. NON-FUNCTIONAL REQUIREMENTS 11

5.1. Performance Requirements 11 5.2. Safety Requirements 11 5.3. Security Requirements 11 5.4.
User Documentation 11 6. REFERENCES 12

7. APPENDICES 13

1. Introduction
1.1. Purpose of Document
This document ensures that stakeholders are in clear contact by outlining the project's
features, goals, and limitations. It acts as a development roadmap, coordinating goals and
directing the production of the software.
1.2. Intended Audience
The individuals involved with or expected to use this document include our supervisor, the
jury responsible for evaluating your project, and the FYP committee overseeing the
project's progression.
1.3 Abbreviations
No abbreviations are used in the document.
1.4 Document Convention
The document will utilize Arial font throughout, maintaining a consistent font size of 12
and alignment is justified for improved readability and uniformity across all sections and
content.
2. Overall System Description
2.1. Project Background
Medicine.ai aims to revolutionize medicine management through computer vision. It
addresses challenges in tracking and organizing medication inventory, aiming for a more
accurate, efficient system in healthcare, pharmacies, and personal use
2.2. Project Scope
The project centers on implementing computer vision in various locations to estimate
medication inventory. This technology offers a streamlined method for inventory
management without manual intervention
2.3. Not In Scope
The project does not aim to provide precise medication counts using the computer vision
model. Furthermore, it won't provide an extensive inventory management system. Rather,
the emphasis is on using computer vision to estimate inventory levels.
2.4. Project Objectives
The objectives of the project are to leverage computer vision for estimating medication
inventory, mitigating the challenges in inventory management. The outcome will be an
automated system capable of providing approximate inventory levels, improving the
efficiency of inventory tracking without manual intervention.
2.5. Stakeholders
Stakeholders include pharmacists and inventory personnel as primary users. Technical
teams comprising software developers, computer vision developers.
2.6. Operating Environment
The software is designed to use computer vision algorithms in a networked environment
and is dependent on adaptable hardware such as cameras. It must integrate seamlessly
with existing database systems for inventory records and other relevant applications.
2.7. System Constraints

● Software Constraints: The system must be compatible with various operating systems and
software versions commonly used in inventory management.
● Hardware Constraints: Dependency on accessible hardware for computer vision
functionality, requiring integration of compatible cameras.
● Cultural Constraints: Need for multilingual support in the user interface to ensure usability
across diverse cultural backgrounds
● Legal Constraints: Compliance with healthcare or privacy regulations regarding sensitive
inventory data, ensuring data security and privacy.
● Environmental Constraints: Consideration for varying lighting conditions that might affect
computer vision accuracy.
● User Constraints: User interface design tailored for ease of use, potentially favoring visual
elements over text for better accessibility.
● Off-the-shelf Components: Constraints imposed by the functionalities and limitations of
components utilized within the project, potentially affecting overall system capabilities and
performance.
2.8. Assumptions & Dependencies

● System Environment and algorithmic Assumptions:

Assumption that the system will primarily operate in indoor environments


with controlled lighting conditions for optimal performance.
Assuming a stable internet connection for potential cloud-based
functionalities or updates.
Assuming the accuracy of inventory estimation based on predefined object
recognition algorithms.
Assuming consistent object placement for reliable inventory detection.

● Dependencies on External Factors:

Hardware Dependencies:
Dependency on compatible cameras or sensors for accurate image
acquisition and processing.

Data Dependencies:
Dependency on the availability and quality of the input data (images or
videos) for inventory estimation.

Software Dependencies:
Dependency on third-party libraries or frameworks for computer vision
functionalities.

3. External Interface Requirements

3.1. Hardware Interfaces


The system interacts with hardware components primarily through:
● Camera/Sensor Interface:
Supported Device Types: High-definition cameras capable of capturing clear
images.
Nature of Interactions: Data transfer of captured images to the software for
computer vision processing.
Control Interactions: Configuration settings for image capture quality and
resolution.

3.2. Software Interfaces


The system interfaces with the following external software components:

● Computer Vision Framework (YOLO):


Purpose: Utilized for object recognition and image processing.
Data Items: Images and video frames exchanged for analysis.

● Operating System Compatibility:


Purpose: Ensuring compatibility with various OS versions (e.g., Windows, Linux,
MacOS).
Data Shared: System configurations and compatibility checks.

● Database Integration (PHPMyAdmin):


Purpose: Storage and retrieval of inventory data.
Data Shared: Inventory records, updates, and retrieval queries.

3.3. Communications Interfaces

● Web-based Interface:
Purpose: Accessing the system via web browsers for remote management.
Message Formatting: HTML/CSS for user interface rendering.
Security: User authentication and authorization protocols for access control.

4. Functional Requirements
4.1. Functional Hierarchy
4.1.1.User Authentication and Authorization:
• 1.1 Authenticate User
• 1.2 Authorize User Roles
4.1.2.User Management:
• User Registration
• Stripe Payment Gateway
• User Login
• Forgot Password
• User Settings
4.1.3.Product Management:
• View Products
• Add Product
• Edit Product
• Delete Product
4.1.4.Inventory Management:
• View Inventory
• Add Inventory
• Remove Inventory
4.1.5.Settings Page:
• Update Password
• Update Name
• Update Email
4.1.6.Forgot Password Functionality:
• Request Password Reset
• Reset Password
4.1.7.Products Page:
• Add Product
• Edit Product
• Delete Product

4.2. Use Cases


<Use case Id: Login>
Use case Id: UC001

Actors: User, Admin (Panel)

Feature: User Login

Pre-condition: The user has an active internet connection, and the user has
not registered with the system before.

Scenarios

Step# Action Software Reaction

1. User navigates to the login


● User enters an email and password.
page.
● System validates the credentials.
2. If the entered credentials belong
Admin is redirected to the admin dashboard.
to the admin:
3. If the entered credentials belong
System checks if the user has paid for membership.
to a registered user:
● If yes, user is redirected to the vendor portal.
● If no, an error message is displayed,
prompting the user to pay for membership.

4. If the entered credentials are


An error message is shown, asking the user to enter
incorrect
valid credentials.
Alternate Scenarios:

1a: If the entered email is not found in the system, show an error message prompting the user
to register.
3a: If the user enters the wrong password, show an error message and ask the user to enter
the correct password.

Post Conditions

Step# Description

1 If admin credentials are correct, access to admin features is granted.

2 If user credentials are correct and membership is paid, access to the vendor portal is granted.

3 If user credentials are correct but membership is not paid, an error message is displayed.

Use Case Cross referenced None

<Use case Id: UserSignUp>


Use case Id: UC002

Actors: User, Admin (Panel)

Feature: User Registration and Payment Processing

Pre-condition: The user has an active internet connection, and the user has not
registered with the system before.

Scenarios

Step# Action Software Reaction


1. User fills in registration
● System verifies that the provided email is
details
unique.
● If email is duplicate, show an error message.
● If email is unique, proceed to the next step.

● User fills in payment details.


2.
User is redirected to Stripe
● If user quits or goes back without completing
payment gateway.
payment:
○ User is listed as a lead in the admin
panel.
● If user completes the payment:
○ User is marked as a customer in the
system.
○ User receives login credentials.

Alternate Scenarios:

1a: If email is a duplicate, show an error message and prompt the user to use a different
email. 2a: If the user encounters an issue during payment, provide appropriate error
handling and guidance.

Post Conditions

Step# Description

1 If successful registration and payment, the user becomes a customer.

2 If the user quits before payment, they are listed as a lead in the admin panel.

Use Case Cross referenced None

<Use case Id: ForgotPassword>


Use case Id: UC003

Actors: User, System

Feature: Forgot Password Functionality

Pre-condition: The user has an active internet connection, and the user has a
registered email in the system.

Scenarios
Step# Action Software Reaction

1. User navigates to the "Forgot


● System checks if the entered email is
Password" page.
registered:
● User enters their registered
● If registered, an email with a reset link is
email.
sent to the provided email address.
● If not registered, an error message is
displayed, indicating that the email is not
found.
2. User receives the email and clicks
User is redirected to a page to enter a new
on the reset link.
password.
3. User enters a new password and
System validates the new password.
submits the form.
4.
If the new password is valid: User's password is reset ,and the user is
redirected to the login page.

Alternate Scenarios:

1a: If the reset link is expired or invalid, show an error message and prompt the user to request
a new reset link.
4a: If the entered new password is invalid, show an error message and ask the user to enter a
valid password.

Post Conditions

Step# Description

1 If the email is registered, a reset link is sent.

2 If the email is not registered, an error message is displayed.

3 After successfully resetting the password, the user is redirected to the login page.

Use Case Cross referenced None

<Use case Id: updateSettings>


Use case Id: UC004

Actors: User

Feature: User Settings

Pre-condition: The user has an active internet connection, and the user is logged
in and navigates to the Settings page.

Scenarios

Step# Action Software Reaction

1. User navigates to the "Settings" page. Settings page is displayed

2. User updates their password:


System checks if the new password and
● User enters a new password.
confirmation match.
● User enters the same password
If matching, the user's password is updated.
in the confirmation field.

If not matching, an error message is


displayed, prompting the user to enter
matching passwords.
1.

3. User updates their name: User enters a


System updates the user's name.
new name.

User submits the form.


4. User updates their email:
System updates the user's email.

User enters a new email.

User submits the form.

Alternate Scenarios:

2a: If the new password and confirmation do not match, show an error message and prompt
the user to enter matching passwords.
4a: If the new email is already registered in the system, show an error message and prompt the
user to enter a different email.

Post Conditions

Step# Description
1. If the password is successfully updated, the user is notified.
2. If the name is successfully updated, the user is notified.
3. If the email is successfully updated, the user is notified.

Use Case Cross referenced


None

<Use case Id: ProductsPage>


Use case Id: UC005

Actors: Shop Owner

Feature: Product Management

Pre-condition: The user has an active internet connection, and the


shop owner is logged in and navigates to the Products
page

Scenarios

Step# Action Software Reaction

1. Shop owner navigates to the "Products" page. Products page is displayed

2. Shop owner adds a new product:


System adds the new
● Shop owner clicks on the "Add Product" button.
product to the product
● A modal pops up with fields for title and description.
list.
● Shop owner fills in the details and submits the form.

3. Shop owner edits an existing product:


System updates the
● Shop owner clicks on the "Edit" button for a specific
product details.
product.
● A modal pops up with the product details pre-filled.
● Shop owner modifies the title or description and submits the
form.
4.
Shop owner deletes an existing product:
A warning modal
● Shop owner clicks on the "Delete" button for a specific
appears, asking for
product.
confirmation to delete.

If confirmed, the
product is removed
from the product list.
Alternate Scenarios:

2a: If the shop owner submits the form without filling in required fields, show an error message
and prompt them to complete the necessary information.
3a: If the shop owner decides not to delete the product after the warning, the product remains in
the product list..
Post Conditions

Step# Description

1. If a new product is added, it is displayed in the product list.


2. If an existing product is edited, the changes are reflected in the product
list. 3. If an existing product is deleted, it is removed from the product list.

<Use case Id: AddInventory>


Use case Id: UC006

Actors: Shop Owner

Feature: Add Inventory


Pre-condition:
The user has an active internet connection, and the shop owner is logged in and
navigates to the inventory page

Scenarios

Step Action Software Reaction


#

1. Shop owner navigates to the "Inventory" page. Inventory page is displayed


2. Shop owner adds new inventory:
On click of each line item,
● Shop owner clicks on the "Add Inventory" button.
the system adds a line item
● A new page appears with the option to add multiple line
to the form
items.
● For each line item, the shop owner selects the product
and enters the quantity.
3. Shop owner submits the form. System updates the inventory:
● For each line item
submitted, the system
updates the inventory
with the specified
quantity for the
selected product.

Alternate Scenarios:

2a: If the shop owner attempts to submit the form without selecting a product or entering a
quantity for any line item, show an error message and prompt them to complete the necessary
information.

Post Conditions

Step Description
#

1. The inventory is updated with the new quantities for the specified products

<Use case Id: RemoveInventory>


Use case Id: UC007

Actors: Shop Owner

Feature: Remove Inventory

Pre-condition: The user has an active internet connection, and the shop owner
is logged in and navigates to the inventory page
Scenarios

Step Action Software Reaction


#

1. Shop owner navigates to the "Inventory" page. Inventory page is displayed

2. Shop owner removes new inventory:


On click of each line item,
● Shop owner clicks on the "Remove Inventory" button.
the system adds a line item
● A new page appears with the option to add multiple line
to the form
items.
● For each line item, the shop owner selects the product
and enters the quantity.

3.

Shop owner submits the form. System updates the inventory:


● For each line item
submitted, the system
updates the inventory
with the specified
quantity for the
selected product.
Alternate Scenarios:

2a: If the shop owner attempts to submit the form without selecting a product or entering a
quantity for any line item, show an error message and prompt them to complete the necessary
information.

Post Conditions

Step Description
#

1. The inventory is updated with the new quantities for the specified products

5. Non-functional Requirements
5.1. Performance Requirements

• The web application should provide fast response times to ensure efficient
management of products and inventory by the shop owner.

• Page load times, including those for inventory, product management, and other key
features, should be optimized for quick user interaction.

• The detection model integrated into the system should exhibit high accuracy in
identifying and managing products. The model's precision and recall rates should
meet or exceed specified benchmarks to ensure reliable and correct detection.

5.2. Safety Requirements

• Safeguards should be in place to ensure the integrity of the data used by the system.
Measures such as regular backups and data validation checks should be
implemented to prevent data corruption.
• The system should provide alerts or warnings to the shop owner in case of potentially
harmful actions or errors, ensuring that inadvertent actions can be corrected before
causing significant issues.

5.3. Security Requirements

• The system should incorporate secure user authentication mechanisms to prevent


unauthorized access to sensitive information. This includes login credentials for shop
owners and any other authorized personnel.
• All user data, including product details and inventory information, should be handled with
strict privacy measures. Compliance with data protection regulations and encryption of
sensitive data in transit and at rest should be ensured.
5.4. User Documentation

• Provide comprehensive user manuals that guide shop owners through the
functionalities of the web application, including product management, inventory
control, and any integrated detection model features.
• Include online help features within the application to provide contextual guidance to
users, ensuring they can easily access assistance relevant to their current tasks. • Develop
tutorials or walkthroughs that offer step-by-step instructions for common tasks, making it
easy for shop owners to familiarize themselves with the system's features.

6. References
S. Mane and S. Mangle, "Moving object detection and tracking Using Convolutional Neural
Networks," in 2018 International Conference on Intelligent Computing and Control Systems
(ICICCS), 2018. [1]

B. N. Krishna Sai and S. T. Sasikala, "Object Detection and Count of Objects in Image using
TensorFlow Object Detection API," in 2019 Second International Conference on Smart
Systems and Inventive Technology (ICCSIT), 2019. [2]

Y. Liu, B. Liu, and Y. Chen, "Research on Image Recognition of Supermarket Commodity


Based on Convolutional Neural Network," in 2019 International Symposium on
Computational Intelligence and Design (ISCID), 2019. [3]

S. K. Yedla, V. M. Manikandan, and P. V. Panchami, "Real Time Scene Change detection


With Object Detection For Automated Stock Verification," in 2020 International Conference
on Device, Circuits, Systems (ICDCS), 2020. [4]

N. Kejriwal, S. Gang, and S. Kumar, "Product Counting Using images With the Application to
Robot - Based Retail Stock Assessment." [5]

C. G. Melek, E. B. Sönmez, and S. Albayrak, "Object Detection in Shelf Images with YOLO."
[6]

E. Goldman, R. Herzig, A. Eisenschtat, O. Ratzon, I. Levi, J. Goldberger, and T. Hassner,


"Precise Detection in Densely Packed Scenes." [7]

R. Yilmazer and D. Birant, "Shelf Auditing Based on Image Classification Using


SemiSupervised Deep Learning to Increase On-Shelf Availability in Grocery Stores." [8]

S. Zhang, L. Yao, A. Sun, and Y. Tay, "Deep learning based recommender system: a survey
and new perspectives," ACM Computing Surveys (CSUR), vol. 52, no. 5, 2019. [9]

G. E. Hinton, S. Osindero, and Y. -W. Teh, "A fast learning algorithm for deep belief nets,"
Neural Computation, vol. 18, no. 7, pp. 1527–1554, 2006. [10]

G. E. Hinton and R. R. Salakhutdinov, "Reducing the dimensionality of data with neural


networks," Science, vol. 313, no. 5786, pp. 504–507, 2006. [11]

Y. Bengio, P. Lamblin, D. Popovici, and H. Larochelle, "Greedy layer - wise training of deep
networks," Advances in Neural Information Processing Systems, MIT Press, Cambridge,
MA, USA, 2007. [12]

V. Nair and G. E. Hinton, "Rectified linear units improve restricted Boltzmann machines," in
Proceedings of the 27th International Conference on Machine Learning (ICML-10), Haifa,
Israel, 2010. [13]

G. E. Hinton, N. Srivastava, A. Krizhevsky, I. Sutskever, and R. R. Salakhutdinov, "Improving


neural networks by preventing co-adaptation of feature detectors," 2012,
https://arxiv.org/abs/1207.0580. [14]

7. Appendices
Not Applicable

You might also like