Professional Documents
Culture Documents
Medicine.ai
Version: 2.0
Project Code F23-414D
Co Supervisor
10-December-2023
Submission Date
Document History
Versi Name of Person Date Description of change
on
Co- Supervisor
Document Sign-Off
Version Sign-off Authority Sign-off Date
2.0
Table of Contents
1. INTRODUCTION 7
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
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
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.
● 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
Pre-condition: The user has an active internet connection, and the user has
not registered with the system before.
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
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.
Pre-condition: The user has an active internet connection, and the user has not
registered with the system before.
Scenarios
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
2 If the user quits before payment, they are listed as a lead in the admin panel.
Pre-condition: The user has an active internet connection, and the user has a
registered email in the system.
Scenarios
Step# Action Software Reaction
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
3 After successfully resetting the password, the user is redirected to the login page.
Actors: User
Pre-condition: The user has an active internet connection, and the user is logged
in and navigates to the Settings page.
Scenarios
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.
Scenarios
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
Scenarios
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
Pre-condition: The user has an active internet connection, and the shop owner
is logged in and navigates to the inventory page
Scenarios
3.
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.
• 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.
• 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]
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]
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]
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]
7. Appendices
Not Applicable