Comprehensive Report on E-commerce

Online Retail Store Project

This report details the comprehensive planning and design for an e-commerce online retail
store project, addressing all speci�ed requirements from preliminary investigation to system
design and sample code implementation. The analysis is grounded in established so�ware
engineering principles and current industry trends, aiming to outline a robust and user-centric
solution.

I. Preliminary Investigation and its Activities

This foundational section provides a thorough understanding of the project's necessity, the
challenges it aims to resolve, the methodologies employed for information gathering, and an
assessment of its overall viability.

1.1 Problem Identi�cation and De�nition

The landscape of retail has undergone a profound transformation, driven primarily by the rise
of e-commerce. Traditional brick-and-mortar stores face considerable challenges that
fundamentally limit their competitive edge. These limitations include inherent constraints such
as �xed operating hours, restricted geographical reach, and higher overhead costs associated
with physical infrastructure like rent, utilities, sta�ng, and security.1 Consumers in a traditional
retail se�ing o�en encounter inconveniences such as the inability to easily compare prices
and products, navigating outdated store designs, and experiencing inconsistent pricing
strategies that rely on physical coupons or hard-to-�nd discounts.5 Furthermore, traditional
retail models have struggled with a lack of dedicated focus on online sales and o�en provide
subpar customer service due to understa�ng or ine�cient processes.5 Supply chain and
inventory management also present signi�cant hurdles, leading to issues like empty shelves or
lengthy delivery delays, particularly evident during global disruptions.5
The emergence of e-commerce has not merely introduced an alternative shopping channel; it
has fundamentally reshaped consumer expectations, making convenience, price
transparency, and 24/7 accessibility non-negotiable aspects of the shopping experience. 1 This
shi� has intensi�ed competition across the retail sector, compelling businesses to o�er
greater value and a more seamless experience to a�ract and retain customers.1 Consequently,
developing an online retail store is no longer a discretionary enhancement but a strategic
imperative. The proposed system must inherently address these evolving consumer demands
while simultaneously overcoming the operational ine�ciencies that plague traditional retail
models. This involves a fundamental re-evaluation of how products are presented, how
transactions are processed, and how customer relationships are managed in a digital-�rst
environment.

1.2 Problem Description

The existing retail environment, encompassing both traditional and o�en poorly implemented
online stores, presents a myriad of speci�c pain points for both consumers and businesses,
directly impacting revenue and customer satisfaction. For consumers, the online shopping
experience can be marred by several critical issues. These include unprofessional or outdated
website designs that deter engagement within milliseconds, and ine�cient on-site search
functionalities that fail to provide data-based suggestions, lack tolerance for typos, or are
simply too slow.6 A poor user experience extends to non-mobile-friendly sites, intrusive
pop-ups, and frustratingly slow loading times, with over half of mobile users abandoning a
page if it takes more than three seconds to load.6 The absence of personalization, missing or
unclear product information, overly complex checkout processes, and payment failures
further contribute to high shopping cart abandonment rates.6 Additionally, consumers are
o�en frustrated by hidden charges, poor order tracking, long delivery times, and inadequate
customer support, including a lack of live chat options.6
From a business perspective, these consumer-facing issues directly translate into signi�cant
revenue loss, increased shopping cart abandonment, and considerable di�culty in customer
retention.6 The e-commerce industry itself is a prime target for online fraud, leading to billions
in losses annually due to weak security measures and cybera�acks.7 The low barrier to entry
in e-commerce has also led to hyper-competition, making it challenging for businesses to
di�erentiate themselves and driving up customer acquisition costs, which can be �ve times
higher than retention costs.7 Operational challenges for businesses include the complex
management of product returns and refunds, where a generous policy can be exploited, while
a restrictive one deters purchases.7 Optimizing product pricing and managing shipping costs
also present a delicate balance, as low shipping costs erode pro�ts, and high costs deter
shoppers.7 Finally, a global labor shortage in the e-commerce sector makes hiring the right
talent for critical roles a persistent challenge, impeding growth and operational stability. 7
The detailed enumeration of online shopping problems, particularly those related to user
experience and security, reveals a crucial underlying dynamic: these aspects are not merely
desirable features but are fundamental determinants of business success or failure in the
digital marketplace. A subpar user experience or a perceived security vulnerability directly
translates into lost sales and a damaged brand reputation. This emphasizes that achieving
technical excellence in user experience and security is a prerequisite for pro�tability and
sustained growth in the competitive e-commerce landscape. The system's design must
prioritize these elements to convert visitors into loyal customers and safeguard sensitive data.
1.3 Fact Finding Techniques

To gather and analyze the information necessary for de�ning the requirements of the online
retail store, a systematic approach involving multiple fact-�nding techniques is essential. This
multi-faceted methodology ensures a comprehensive and accurate understanding of the
system's needs.
Common techniques employed include:
● Background Reading: This involves reviewing existing documentation, such as internal
reports, market research, and industry best practices, to gain an initial understanding of
business objectives and requirements.8 This provides a foundational context before
engaging with stakeholders.
● Interviewing: Widely regarded as the most e�ective technique for gaining an in-depth
understanding of user needs, interviewing involves structured discussions with various
stakeholders, including potential customers, business owners, and operational sta�.8
This allows for clari�cation of ambiguities and exploration of nuanced perspectives.
● Observation: By directly watching users perform tasks within their work environment,
analysts can gain valuable insights into existing work�ows, information processing, and
potential bo�lenecks that might not be articulated in interviews.8 This provides a
practical perspective on system procedures.
● Document Sampling: This technique involves analyzing existing paper documents,
digital records, and databases, such as customer complaints, sales reports, and user
manuals, to identify pa�erns, data �ows, and recurring issues.8 Randomization and
strati�cation can be used for systematic sampling.9
● Questionnaires: For gathering standardized responses from a large number of users
e�ciently and economically, questionnaires are invaluable.8 They can be free-format for
opinions or �xed-format for speci�c data points, allowing for quick analysis of
responses.9
● Research and Site Visits: This involves exploring external resources, such as industry
databases, case studies of similar systems, and visiting sites where comparable
solutions are implemented.9 This helps in learning from existing solutions and staying
updated with technological advancements.
● Prototyping: Creating small-scale, working models of the proposed system allows for
early testing and validation of requirements with users before full-scale development.9
This helps in con�rming requirements and obtaining design approvals, reducing
development costs and time.
● Joint Requirements Planning (JRP): A structured group meeting approach that brings
together key stakeholders (sponsors, users, managers, IT sta�) to collectively identify
and analyze problems, and de�ne system requirements.9 This method is highly e�cient
for gathering facts and achieving group consensus in a shorter timeframe than
individual interviews.9
The diverse array of fact-�nding techniques underscores the multi-faceted nature of
requirements gathering in so�ware development. No single technique can provide a complete
picture; rather, a strategic combination of methods is necessary to achieve a comprehensive,
accurate, and unbiased understanding of system needs. For instance, while interviews o�er
qualitative depth, questionnaires provide quantitative breadth. Observation o�ers practical
validation, and prototyping allows for early user feedback. By triangulating data from multiple
sources, the risk of requirement omissions, misinterpretations, or biases is signi�cantly
minimized, leading to a more robust and e�ective system design.

1.4 Drawbacks of Existing System

An e�ective online retail store project must address the shortcomings of not only traditional
retail models but also the common pi�alls observed in many existing e-commerce systems.
The drawbacks of traditional retail are numerous and have driven the shi� towards online
commerce. These include high overhead costs for physical spaces, utilities, and a large
workforce, coupled with signi�cant security expenses.2 Their operations are con�ned by
limited business hours and geographical reach, preventing 24/7 accessibility and global
market penetration.1 The inability for customers to easily compare prices and products across
di�erent stores further disadvantages them.1 Speci�c issues like outdated store designs,
inconsistent pricing strategies (e.g., reliance on paper coupons), and o�en poor customer
service due to understa�ng contribute to a subpar customer experience.5 Furthermore,
traditional supply chains can be in�exible and prone to disruptions, leading to inventory
management challenges and stockouts.5
While e-commerce o�ers signi�cant advantages, poorly implemented or generic existing
e-commerce systems also exhibit critical drawbacks:
● Security Threats: Online businesses are constant targets for cybera�acks, data
breaches, and payment fraud, which can severely damage �nances and reputation if
robust security measures like SSL encryption and regular audits are not in place.2
● High Competition: The low barrier to entry means the market is saturated, making it
di�cult for new stores to stand out and leading to increased customer acquisition
costs.2
● IT Issues and Downtime: Website crashes, slow loading times, or payment processor
problems can lead to immediate revenue loss and frustrated customers, especially
during peak periods.2
● Shipping Logistics: Managing order ful�llment, stockouts, customs issues, courier
delays, and high shipping costs can be complex and negatively impact customer
satisfaction and brand credibility.2
● Limited Personal Interaction: Online interactions o�en lack the human touch of
physical stores, making it harder to build trust and guide hesitant buyers. This
necessitates proactive customer service solutions like live chat.2
● Maintenance Costs: While generally lower than physical stores, maintaining an
 e-commerce site still requires ongoing investment in so�ware updates, hosting fees,
technical support, and security upgrades.10
● Lack of Physical Product Experience: Customers cannot physically touch, try on, or
test products online, which can lead to hesitation and higher return rates for certain
product categories.3
The dual nature of "existing system drawbacks"—encompassing both the inherent limitations
of traditional retail and the common failures of many online businesses—underscores that a
successful new online retail store must be a hybrid solution. It must not only capitalize on the
fundamental advantages of digital commerce, such as global reach and 24/7 accessibility, but
also proactively design against the prevalent security, logistical, and competitive challenges
that plague many existing online businesses. This necessitates a robust, secure, and
user-centric design from its inception, ensuring that the system is built to overcome both
legacy ine�ciencies and modern digital complexities.

1.5 Scope of the Proposed System

The proposed online retail store system is designed to be a comprehensive digital pla�orm,
extending beyond basic transactional capabilities to o�er a rich, personalized, and e�cient
shopping experience. Its scope is de�ned by a set of core components and strategic
objectives aimed at maximizing market reach and operational e�ciency.
The core components of this modern e-commerce system will include:
● Online Storefront: This serves as the virtual face of the brand, featuring intuitive
product listings, robust search functionality, and an engaging design to a�ract and
retain customers.11
● Shopping Cart and Secure Payment Gateway: A seamless shopping cart experience
is crucial, coupled with robust and secure payment gateways (e.g., PayPal, Stripe) to
ensure safe transactions and build customer trust.11
● Inventory Management: Automated systems will track stock levels in real-time, trigger
restocking alerts, and ensure product availability to meet customer demand.11
● Order Ful�llment and Logistics: E�cient ful�llment processes will integrate with
shipping carriers and provide real-time tracking, enhancing customer satisfaction
through reliable and transparent delivery.11
● Customer Support Tools: Integration of live chat, email support, and Customer
Relationship Management (CRM) systems will facilitate enhanced customer interactions
and enable personalized service.11
● Analytics and Reporting: Advanced analytics tools (e.g., Google Analytics 4, Hotjar)
will monitor customer behavior, identify trends, and provide actionable insights to
optimize marketing strategies and business performance.11
The strategic bene�ts and objectives driving the system's development are:
● Expanded Global Reach: The system will break geographical barriers, enabling the
business to tap into international markets and signi�cantly increase its customer base. 3
 ● Cost E�ciency: Operating an online store will substantially reduce overhead costs
compared to traditional brick-and-mortar establishments, freeing up resources for
innovation and marketing.3
● 24/7 Accessibility: Customers will have the convenience of shopping anytime,
anywhere, increasing sales potential and enhancing customer convenience.3
● Personalized Customer Experiences: Leveraging advanced AI tools (e.g., Dynamic
Yield, ChatGPT) will enable the delivery of hyper-personalized experiences, including
targeted o�ers and product recommendations, fostering stronger customer
relationships.3
● Real-Time Analytics and Decision Making: The system will provide real-time insights
into customer behavior, sales trends, and performance optimization, empowering
data-driven strategic decision-making.3
● Scalability for Growth: The chosen pla�orm and architecture will ensure the system
can e�ortlessly scale to accommodate increasing demand and evolving business needs
without signi�cant performance degradation.11
The emphasis on AI-powered personalization, data-driven marketing, and real-time analytics
indicates that the scope of a modern online retail store extends signi�cantly beyond basic
transactional capabilities. It is fundamentally a data-intensive system engineered for
continuous optimization of customer experience and overall business strategy. This implies
that robust data collection, sophisticated processing, and advanced analytical capabilities are
not merely auxiliary features but are central to the system's value proposition and its
long-term success in a competitive digital environment.

1.6 Feasibility Study

A thorough feasibility study is crucial to determine the viability and practicality of developing
the proposed online retail store. This comprehensive assessment examines the project from
multiple critical perspectives, ensuring that all potential challenges and opportunities are
identi�ed.
A comprehensive feasibility study typically comprises �ve key components:
● Economic Feasibility: This involves a detailed cost-bene�t analysis to ascertain
whether the project's bene�ts outweigh its costs. It evaluates the minimum inputs
required for successful operation, such as labor, infrastructure, utilities, and raw
materials.12 It also assesses existing and prospective contracts, environmental risks, and
the overall economic impact, including potential market creation and sector
development.12 The project's cost is weighed against the anticipated increase in
revenues or other tangible and intangible bene�ts.
● Market Feasibility: This component focuses on understanding the market landscape
for the proposed online store. It analyzes current and future market potential, identi�es
the target customer segments, and thoroughly assesses the competition.12 Key
elements include evaluating the marketing plan, identifying potential by-product
 revenue streams, and assessing industry-speci�c risks such as scalability challenges
and supply chain vulnerabilities.12 The goal is to determine if su�cient demand exists
and if the business can e�ectively compete.
● Technical Feasibility: This analysis scrutinizes the reliability and availability of the
technology required for the project. It includes an assessment of commercial
o�-the-shelf solutions versus custom development, the success record of similar
products or processes, and the experience of potential service providers.12 It also
examines delivery logistics, including transportation infrastructure, business location
(for physical operations like warehousing), and the availability of necessary technology,
materials, and skilled labor.12 Construction risks, if any, are also considered.
● Financial Feasibility: This component identi�es the �nancial elements necessary for
the project's long-term sustainability. It involves developing detailed �nancial
projections over a multi-year period (e.g., �ve years), outlining revenue and expense
assumptions.12 It assesses funding sources, equity contributions, repayment plans, and
the availability of short-term credit.12 Comparison with peer industry �nancial
performance helps benchmark expectations and identify potential �nancial risks. 12
● Management Feasibility: This aspect examines the organizational capacity to execute
the project. It reviews the history of the business or organization, its ownership
structure, and the composition and quali�cations of its board.12 A critical assessment is
made of the key sta�, focusing on their professional background, experience, skills, and
character, to ensure the management team possesses the necessary expertise to
implement and operate the project successfully.12
The multi-dimensional nature of the feasibility study highlights that a successful so�ware
project is not solely a technical endeavor. It requires a holistic evaluation that extends beyond
code and infrastructure to encompass market demand, �nancial viability, operational
capabilities, and human resources. A de�ciency in any one of these areas, even if the
technical solution is sound, can lead to project failure. This underscores the critical need for
interdisciplinary planning and a thorough risk assessment across all these dimensions to
ensure a robust and realistic project plan.

II. Requirement Speci�cation

This section meticulously details the functional and non-functional needs of the online retail
store, along with the data inputs, outputs, and the identi�cation of its various users.

2.1 Data Requirements of the System

The online retail store system will rely on a comprehensive set of data elements that must be
meticulously collected, stored, processed, and managed to ensure seamless operations,
personalized experiences, and informed decision-making.
The critical data elements include:
● Customer Data: This encompasses personal information such as name, email address,
physical address (for shipping and billing), phone number, and securely stored login
credentials (e.g., hashed passwords).13 It also includes customer preferences,
demographic data, buying behavioral data (e.g., browsing history, clicks, time spent on
pages), and search pa�erns.17 Explicitly shared information, o�en referred to as
zero-party data, such as wishlist additions or survey responses, is also vital for
personalization.17
● Product Data: Each product requires detailed information including a unique Product
ID, name, comprehensive description, price, current stock quantity, image URLs,
physical a�ributes like weight and dimensions, and a Stock Keeping Unit (SKU).14
Products are also linked to categories for easier navigation and supplier information for
inventory management.14
● Order Data: This captures the speci�cs of each purchase, including a unique Order ID,
the date the order was placed, the total amount, and its current status (e.g., pending,
processing, shipped, delivered, cancelled).14 Each order is associated with a Customer
ID and links to speci�c shipping and payment records.
● Order Item Data: To detail the contents of an order, this data includes an Order Item ID,
the associated Order ID and Product ID, the quantity of the product ordered, its unit
price at the time of purchase, and any applied discounts.14
● Payment Data: This involves a Payment ID, the associated Order ID, the type of
payment used (e.g., credit card, PayPal), the amount, payment date, transaction ID from
the payment gateway, and the payment status (e.g., success, pending, failed).14
● Shipping Data: Details related to product delivery include a Shipping ID, the shipping
address, chosen shipping method, shipping cost, tracking number, and the current
shipping status.14
● Operational/Analytical Data: Beyond transactional data, the system will collect data
on website tra�c, on-site behavior (e.g., bounce rates, session duration), marketing
campaign performance (e.g., email interactions), and various operational metrics.4
External data sources like social media trends and competitor analysis also contribute to
this category.17
A critical aspect of data requirements is data privacy and compliance. With regulations like
the General Data Protection Regulation (GDPR), the system must ensure explicit consent for
data collection, maintain clear and easily understandable privacy policies, and implement
robust security measures for data storage.13 Sta� training on data protection best practices
and mechanisms for customers to request data access, recti�cation, or deletion are also
mandatory.13
The extensive nature of data requirements, spanning from explicit customer inputs to
passively collected behavioral and market data, coupled with stringent privacy regulations like
GDPR, highlights a fundamental tension in modern e-commerce. Businesses aim to maximize
data utility for personalization and business intelligence, yet they must rigorously ensure data
protection and user privacy. This necessitates a "privacy-by-design" approach where data
governance and security are integrated into every layer of the system architecture from the
outset, rather than being treated as an a�erthought. This proactive integration ensures that
the system can leverage data for strategic advantage while upholding ethical and legal
obligations.
Table: Key Data Entities and A�ributes
Entity Primary Key Key A�ributes Foreign Keys Description
(Referenced
Table)
Customer CustomerID Name, Email, UserID (User - if Stores all
PasswordHash, separate login) user-speci�c
ShippingAddress, information,
BillingAddress, including contact
Phone, details, addresses,
RegistrationDate, and shopping
Preferences preferences.
Essential for
personalization.
Product ProductID Name, CategoryID Stores details
Description, Price, (Category), about each item
StockQuantity, SupplierID available for sale.
ImageURL, (Supplier) Critical for catalog
Weight, management and
Dimensions, SKU inventory.
Category CategoryID Name, Description Organizes
products into
logical groups for
easier browsing
and search.
Supplier SupplierID Name, Stores information
ContactPerson, about product
Phone, Email, suppliers.
Address Important for
supply chain
management.
Order OrderID OrderDate, CustomerID Represents a
TotalAmount, (Customer), customer's
OrderStatus ShippingID purchase. Tracks
(Pending, (Shipping), the overall
Processing, PaymentID transaction details
Shipped, (Payment) and its lifecycle.
 Delivered,
Cancelled)
OrderItem OrderItemID Quantity, OrderID (Order), Details individual
UnitPrice, ProductID products within a
Discount (Product) speci�c order.
Essential for
breaking down an
order into its
constituent items.
Payment PaymentID PaymentType OrderID (Order) Records all
(Credit Card, payment
PayPal), Amount, transactions
PaymentDate, associated with
TransactionID, orders. Ensures
PaymentStatus �nancial tracking
(Success, and reconciliation.
Pending, Failed)
Shipping ShippingID ShippingAddress, OrderID (Order) Manages the
ShippingMethod, logistics and
ShippingCost, status of product
TrackingNumber, delivery. Provides
ShippingStatus customers with
tracking
information.

This table provides a clear, structured overview of the fundamental data model for the
e-commerce system. It explicitly lists the core information pieces (entities), their unique
identi�ers (primary keys), key descriptive a�ributes, and how they relate to each other
(foreign keys). This serves as a direct, actionable blueprint for the subsequent database
design, ensuring comprehensive data capture and integrity, which is vital for the system's
operational and analytical capabilities.

2.2 Identify End Users of the System

The online retail store system will serve a diverse set of end-users, each with distinct
interaction pa�erns, roles, and responsibilities. Understanding these roles is crucial for
designing appropriate interfaces, permissions, and work�ows.
The primary types of end-users include:
● Customers (Shoppers): These are the most critical external users of the system. Their
primary activities involve browsing and searching for products, adding items to a virtual
shopping cart, proceeding through the checkout process, making secure payments,
 tracking the status of their orders, managing their personal pro�les (e.g., updating
addresses, viewing past purchases), and interacting with customer support for inquiries
or issues.21
● Administrators/Store Owners/Managers: This broad category encompasses various
internal roles responsible for the overall operation, strategic direction, and health of the
e-commerce pla�orm. Speci�c roles within this group include:
○ Chief eCommerce O�cer (CEO): An executive-level role responsible for the
overarching vision, strategy, and performance of the entire e-commerce
operation, overseeing technology, customer experience, and pro�tability.19
○ eCommerce Manager/Director: The operational backbone, managing
day-to-day activities, coordinating cross-functional teams (marketing, sales,
logistics, IT), monitoring key performance indicators (KPIs), and mentoring sta�.19
○ Digital Marketing Manager: Focuses on driving customer acquisition,
engagement, and retention through various online channels, including SEO, PPC,
email marketing, and social media.19
○ Data Analyst/Business Intelligence Specialist: Responsible for transforming
raw data (customer behavior, sales pa�erns, marketing performance) into
actionable insights to inform strategic decision-making and optimize business
operations.19
○ eCommerce Developer/Technical Lead: Designs, creates, and maintains the
website and its underlying technology infrastructure, ensuring performance,
security, and scalability.19
○ Product Manager: Oversees product optimization and development, creates new
features, and addresses technical issues related to the product catalog and user
experience.21
● Order Clerks: These users are responsible for the logistical aspects of order ful�llment.
Their duties include receiving and processing customer orders, verifying shipping
details, handling receipts, and sometimes communicating shipping dates or delays to
customers.21
● Customer Service Representatives: These individuals are in constant communication
with customers, responding to inquiries, assisting with orders, and resolving any issues
or complaints through various channels like email, social media, or live chat.21 Their role
is crucial for maintaining customer satisfaction and loyalty.
● Delivery Drivers: For businesses managing their own logistics, delivery drivers are
essential. They gather items from the warehouse, load them, and deliver them to
customer addresses, ensuring the accuracy and completeness of orders.21
The broad spectrum of internal and external end-user roles necessitates a highly modular
system architecture with robust role-based access control (RBAC). This design approach
implies that the system must support distinct user interfaces, granular permissions, and
tailored work�ows for each role. For example, a customer will interact with a public storefront,
while an administrator will use a secure backend dashboard, and an order clerk might use a
specialized interface for order processing. Failure to properly segment access and customize
experiences could lead to signi�cant security vulnerabilities, operational ine�ciencies, and a
suboptimal user experience for internal sta�, ultimately impacting the overall e�ectiveness of
the e-commerce pla�orm.

2.3 Input Data to the System

The online retail store system will receive a variety of input data, originating from di�erent
sources and serving diverse purposes. This data fuels the system's operations, enables
personalization, and provides critical information for business intelligence.
Key categories of input data include:
● Customer-Provided Inputs: These are direct and explicit data entries made by users
interacting with the storefront:
○ Registration/Login Data: New user sign-up details (username, password, email,
personal information like name and phone number) and existing user login
credentials.17
○ Order Details: Product selections, desired quantities, shipping address, billing
address, and chosen shipping methods during the checkout process.
○ Payment Information: Sensitive data such as credit card numbers, digital wallet
credentials, or bank account details, entered securely for transactions.
○ Feedback & Preferences: Customer-generated content like product reviews,
ratings, responses to surveys, additions to wishlists, and explicit preferences
shared through preference centers (o�en referred to as zero-party data).17 This
data is intentionally and proactively shared by the customer.
○ Search Queries: Keywords and �lters entered by customers when searching for
products on the website.17
● Administrator/Seller Inputs: These inputs are typically made via a backend
administration panel by internal sta�:
○ Product Information: Details for new products (name, description, price, initial
stock levels, images), updates to existing product details (e.g., price changes,
stock adjustments), category assignments, and supplier information.
○ Order Management: Manual status updates for orders (e.g., "marked as
shipped"), processing of return or refund requests.
○ User Management: Creation or modi�cation of administrator accounts,
management of customer accounts (e.g., account activation, suspension).
○ Promotions: Creation and management of discount codes, special o�ers, and
marketing campaign details.
● System/External Inputs (o�en automated): These data streams are typically
collected passively or received from integrated third-party services:
○ Behavioral Data: Automatically captured data on website tra�c (e.g., visitor
counts, session duration), on-site behavior (e.g., clickstreams, pages viewed,
items added to or removed from carts), and triggers for shopping cart
 abandonment.4 Email interactions (opens, clicks) also fall into this category.4
○ Payment Gateway Responses: Real-time feedback from payment processors
indicating transaction authorization, denial, or status updates.4
○ Shipping Carrier Updates: Automated tracking information and delivery
con�rmations from integrated shipping partners.
○ Market Intelligence: Data on trends in consumer behavior, industry standards,
competitor pricing and product o�erings, marketing strategies, and social media
sentiment.17
○ Regulatory Updates: Information on changes in tax laws or data privacy
regulations that may impact system operations.10
The distinction between direct, explicit user inputs (such as login credentials or purchase
details) and indirect, o�en passively collected, behavioral and market data (such as website
tra�c pa�erns or social media trends) points to the necessity of a sophisticated data
ingestion and processing pipeline. This architectural consideration highlights that the system
needs to be designed not just to accept explicit data, but also to continuously capture,
process, and analyze a wide array of implicit data. This capability is essential for transforming
raw inputs into actionable intelligence, which is then used for personalization, fraud detection,
and strategic decision-making, moving the system far beyond simple data storage.

2.4 Output Information from the System

The online retail store system will generate and present a wide array of output information to
its various stakeholders, including customers, administrators, and other business users. These
outputs are crucial for facilitating transactions, providing customer service, and enabling
informed business decisions.
Key categories of output information include:
● Customer-Facing Outputs: These are directly presented to the end-users (shoppers):
○ Product Displays: Forma�ed listings of products with comprehensive details,
including names, descriptions, high-quality images, prices, available sizes/colors,
current stock status, and aggregated customer reviews or testimonials.20
○ Search Results: Dynamically generated lists of relevant products based on
customer search queries, o�en accompanied by �ltering and sorting options.
○ Shopping Cart Summary: A clear and concise overview of items currently in the
cart, their quantities, subtotal, and estimated shipping costs.
○ Order Con�rmations: Detailed summaries of placed orders, including a unique
order ID, a list of purchased items, the total cost, shipping address, and estimated
delivery dates.22
○ Shipping Updates: Real-time tracking information and automated noti�cations
regarding shipping status and delivery progress.22
○ Personalized Recommendations: Tailored product suggestions based on the
customer's browsing history, past purchase pa�erns, or explicitly stated
 preferences.22
○ Invoices/Receipts: Digital documents con�rming the purchase and payment
details.
○ Customer Account Information: Access to personal pro�les, complete order
history, saved shipping and billing addresses, and payment methods.
● Administrator/Business-Facing Outputs (Reports & Dashboards): These outputs
provide critical business intelligence for internal management and operational oversight:
○ Sales Reports: Comprehensive overviews of sales activities, detailing gross sales,
applied discounts, returns, collected taxes, and shipping charges.22 These reports
help evaluate promotional strategies.
○ Financial Reports: Detailed views of all payment transactions, categorized by
payment method, credit card type, and sales channel. This also includes reports
on gi� card balances and tax liabilities for compliance.22
○ Fraud Reports: Metrics such as acceptance rates for orders, percentages of
high-risk orders, the value of orders canceled due to suspected fraud, and overall
chargeback rates, including those speci�cally for fraudulent reasons.22
○ Product Performance Reports: Data on the number of products ordered and
returned, identifying best-selling items, frequently returned items, and the
e�ectiveness of product recommendations.22
○ Inventory Reports: Snapshots of product quantities in stock at speci�c times
(e.g., month-end), total inventory value, average items sold per day, and the
percentage of inventory sold from the total starting quantity.22
○ Customer Behavior Reports: Insights into customer demographics and interests,
top geographic locations of visitors, analysis of �rst-time versus returning
customers, active shopping carts, checkout progress, search conversion rates,
and sessions broken down by landing page or device type.22
○ Ful�llment Reports: Tracking of orders over time, including the total number of
orders received, and detailed metrics on ful�llment, shipping, and delivery times.22
The extensive and diverse range of output reports, particularly those related to sales, �nance,
fraud, inventory, and customer behavior, indicates that the e-commerce system functions not
just as a transactional pla�orm but as a critical business intelligence and operational
management tool. This means that the system's design must prioritize robust data
aggregation, sophisticated analytical processing, and customizable reporting capabilities. This
focus empowers strategic decision-making, enables continuous performance monitoring,
facilitates proactive fraud detection, and supports ongoing business optimization, moving far
beyond merely displaying basic transaction records.

2.5 Functional, Non-Functional, and Processing Requirements of the

System

This crucial section de�nes the core capabilities (functional), quality a�ributes
(non-functional), and underlying operations (processing) that the online retail store system
must embody to be successful.

2.5.1 Functional Requirements (What the system does)

Functional requirements specify the speci�c actions and features the system must provide to
its users.
● User Management: The system must allow new users to register securely, provide
secure login and logout functionalities, and enable users to create and manage their
pro�les, including updating personal details and viewing their order history.
● Product Catalog & Search: Users must be able to browse products by various
categories, utilize a robust search function with advanced �lters (e.g., price range,
brand, size, color), and view detailed product pages that include high-resolution
images, comprehensive descriptions, customer reviews, and real-time stock status.4
● Shopping Cart Management: The system must support adding and removing items
from the shopping cart, updating product quantities, saving items for later purchase
(wishlist), and applying discount codes or promotions.
● Checkout Process: A seamless and intuitive multi-step checkout process is required,
including an option for guest checkout, clear display of delivery options and costs, and
auto-�lling of customer details for registered users.4
● Payment Processing: The system must integrate with secure and reliable third-party
payment gateways (e.g., PayPal, Stripe) and support multiple payment methods,
including credit/debit cards and popular digital wallets.4
● Order Management: Customers should be able to view their complete order history,
track the real-time status of current orders, and initiate returns or refunds in
accordance with clearly de�ned policies.
● Customer Support: The system must provide various channels for customer
assistance, such as live chat, email support, and a comprehensive Frequently Asked
Questions (FAQ) section.4
● Personalization: To enhance the user experience and drive sales, the system should
provide personalized product recommendations and tailored o�ers based on individual
user behavior and preferences.4
● Admin Panel: A comprehensive administrative interface is essential for internal sta� to
manage products (including Create, Read, Update, Delete operations), orders, user
accounts, categories, promotions, and to access various business reports.

2.5.2 Non-Functional Requirements (How the system performs)

Non-functional requirements de�ne the quality a�ributes and constraints under which the
system must operate.
 ● Performance: The system must exhibit fast loading speeds, with a target of less than 3
seconds for mobile devices, to prevent user abandonment.4 Search results must be
delivered quickly, and the system should maintain e�cient response times and
throughput even under peak user load.23
● Security: Robust security measures are paramount to protect against online fraud and
cybera�acks. This includes implementing SSL certi�cates for data encryption, ensuring
PCI DSS compliance for payment handling, deploying �rewalls, o�ering two-factor
authentication (2FA), utilizing AI-driven anti-fraud systems, and establishing regular
data backup and recovery procedures.23 Sensitive data, such as payment details, must
be encrypted.24
● Usability: The system must o�er an intuitive and user-friendly interface, designed with
a mobile-�rst approach to ensure optimal experience across devices.4 Navigation
should be straigh�orward, and the system must adhere to accessibility standards to
cater to all users.24
● Scalability: The pla�orm must be capable of handling increasing tra�c, data volume,
and transactions without signi�cant degradation in performance.23 This is achieved
through architectural choices like cloud-based hosting, load balancing, database
scalability techniques (e.g., sharding), and a modular, API-�rst approach.23
● Reliability: The system should maintain a high uptime (e.g., 99.9%) to minimize
disruptions.25 It must incorporate fault tolerance mechanisms to recover gracefully from
failures or errors without data loss, along with robust error handling and backup
procedures.23
● Maintainability: The system's design and codebase must facilitate easy updates,
repairs, or modi�cations. This implies clear, well-documented code, modular
architecture, and e�cient processes for implementing changes or �xing issues.24

2.5.3 Processing Requirements (Behind-the-scenes operations)

Processing requirements describe the internal, o�en automated, operations that enable the
system's functionalities.
● Automated Order Processing: Orders must be processed and routed e�ciently to
appropriate warehouses or ful�llment centers, minimizing manual intervention.23
● Real-time Inventory Updates: Stock levels must be automatically adjusted in real-time
upon product purchase, return, or new stock arrival to ensure accuracy and prevent
overselling.11
● Payment Transaction Processing: The system must securely handle payment
authorization, capture of funds, and processing of refunds through integrated payment
gateways.11
● Shipping & Returns Management: This includes automated generation of shipping
labels, provision of real-time tracking updates to customers, and streamlined
 management of return authorizations and refund processes.23
● Data Analytics Processing: The system must continuously collect, aggregate, and
analyze customer behavior data, sales trends, and marketing campaign performance to
generate actionable insights.11
● Personalization Engine: Algorithms must process user data to dynamically generate
and deliver personalized product recommendations, targeted advertisements, and
tailored content to individual users.11
The intricate interdependencies between functional, non-functional, and processing
requirements underscore that these are not isolated concerns but form a cohesive system. For
instance, the functional requirement for "personalization" directly relies on the processing
requirement for a "personalization engine," which in turn demands high "performance" and
"scalability" (non-functional requirements) to process large volumes of data e�ciently.
Similarly, robust "security" (non-functional) is critical for "payment processing" (functional
and processing) to protect sensitive customer data. This interconnectedness means that the
system's design must holistically consider how these di�erent types of requirements in�uence
and enable one another, ensuring a robust, e�ective, and secure e-commerce pla�orm.

III. Database Design

E�ective database design is foundational for the performance, scalability, and integrity of any
e-commerce system. This section details the identi�cation of entities, their a�ributes, the
relationships between them, and the principles of database normalization.

3.1 Identify the entities and the a�ributes

In a relational database, data is organized into tables, each representing an entity. An entity is
a real-world object or concept about which data is stored, and a�ributes are the properties or
characteristics that describe these entities. A primary key uniquely identi�es each row within
an entity table, ensuring data integrity and e�cient retrieval.14 Foreign keys are used to
establish links between tables, representing relationships between entities. 16
For an online retail store, the core entities and their key a�ributes are identi�ed as follows:
● Customer: This entity stores all information pertaining to registered users.
○ A�ributes: CustomerID (Primary Key), Name, Email, PasswordHash (for security),
ShippingAddress, BillingAddress, Phone, RegistrationDate, and Preferences (e.g.,
marketing opt-ins, product categories of interest).14
● Product: This entity holds details about each item available for sale in the store.
○ A�ributes: ProductID (Primary Key), Name, Description, Price, StockQuantity,
ImageURL, Weight, Dimensions, SKU (Stock Keeping Unit), CategoryID (Foreign
Key to Category), and SupplierID (Foreign Key to Supplier).14 A�ributes like size
and color can be managed within this table or in related tables depending on
 complexity.14
● Category: This entity organizes products into logical groups, facilitating browsing and
search.
○ A�ributes: CategoryID (Primary Key), Name, Description.
● Supplier: This entity stores information about the vendors or manufacturers providing
the products.
○ A�ributes: SupplierID (Primary Key), Name, ContactPerson, Phone, Email,
Address.
● Order: This entity represents a customer's purchase transaction.
○ A�ributes: OrderID (Primary Key), OrderDate, TotalAmount, OrderStatus (e.g.,
'Pending', 'Processing', 'Shipped', 'Delivered', 'Cancelled'), CustomerID (Foreign
Key to Customer), ShippingID (Foreign Key to Shipping), and PaymentID (Foreign
Key to Payment).14
● OrderItem: This entity details the individual products included within a speci�c order,
as an order can contain multiple items.
○ A�ributes: OrderItemID (Primary Key), OrderID (Foreign Key to Order), ProductID
(Foreign Key to Product), Quantity, UnitPrice (price at the time of order), and
Discount (applied to this speci�c item).14
● Payment: This entity records all payment transactions associated with orders.
○ A�ributes: PaymentID (Primary Key), OrderID (Foreign Key to Order),
PaymentType (e.g., 'Credit Card', 'PayPal', 'UPI'), Amount, PaymentDate,
TransactionID (from payment gateway), and PaymentStatus (e.g., 'Success',
'Pending', 'Failed').14
● Shipping: This entity manages the logistics and status of product delivery.
○ A�ributes: ShippingID (Primary Key), OrderID (Foreign Key to Order),
ShippingAddress, ShippingMethod, ShippingCost, TrackingNumber, and
ShippingStatus.14
These entities and their a�ributes form the backbone of the e-commerce database, ensuring
that all essential information is captured and organized for e�cient operations, reporting, and
customer service.

3.2 E-R Diagram

An Entity-Relationship (E-R) Diagram is a powerful visual representation of the data model,

illustrating the logical structure of a database and the relationships between di�erent entities
in a graphical manner.16 It serves as a blueprint for database designers to understand and
communicate the data architecture.
Key concepts in an E-R Diagram include:
● Entities: Objects or concepts represented in the database (e.g., Customer, Product),
typically depicted as rectangles.16
● A�ributes: Properties or characteristics describing entities (e.g., Name for Customer),
 typically shown as ovals connected to entities.16
● Relationships: Associations between entities (e.g., a Customer places an Order),
depicted as diamonds connecting entities.16
● Cardinality: De�nes the numerical relationship between entities in a relationship,
indicating how many instances of one entity are related to another. Common
cardinalities include one-to-one (1�1), one-to-many (1:N), and many-to-many (M:N).16
● Primary Key: A unique identi�er for a record within an entity, underlined in the a�ribute
list.16
● Foreign Key: A �eld in one table that refers to the primary key in another table,
establishing a link.16
Conceptual E-R Diagram for an Online Retail Store:
A typical E-R Diagram for an online retail store would visually represent the following
relationships:
● Customer and Order: A Customer can place multiple Orders (One-to-Many
relationship: 1 Customer : N Orders). The OrderID would have a foreign key to
CustomerID.
● Order and OrderItem: An Order can contain multiple OrderItems, but each OrderItem
belongs to only one Order (One-to-Many relationship: 1 Order : N OrderItems). The
OrderItem would have a foreign key to OrderID.
● Product and OrderItem: A Product can be included in multiple OrderItems, and each
OrderItem is associated with one Product (Many-to-One relationship: N OrderItems : 1
Product). The OrderItem would have a foreign key to ProductID.
● Product and Category: A Product can belong to one or more Categories, and a
Category can contain multiple Products (Many-to-Many relationship: N Products : M
Categories). This typically requires an intermediary "junction" table (e.g.,
ProductCategory).
● Product and Supplier: A Product is supplied by one Supplier, and a Supplier can supply
multiple Products (One-to-Many relationship: 1 Supplier : N Products). The Product
table would have a foreign key to SupplierID.
● Order and Payment: An Order is associated with one Payment (One-to-One
relationship: 1 Order : 1 Payment). The Payment table would have a foreign key to
OrderID.
● Order and Shipping: An Order is associated with one Shipping record (One-to-One
relationship: 1 Order : 1 Shipping). The Shipping table would have a foreign key to
OrderID.
This visual representation aids in tracking customer orders, organizing product categories,
managing inventory, and ensuring the integrity of transaction data.26 It clari�es how di�erent
pieces of information are interconnected, which is fundamental for building a robust and
e�cient database.

3.3 Identifying all tables, �elds, relationship between tables etc.

Building upon the conceptual E-R Diagram, this section details the speci�c tables, their �elds
(a�ributes), and the explicit relationships between them, including the use of primary and
foreign keys. This tabular representation provides a clear blueprint for database
implementation.
1. Customer Table
● Purpose: Stores information about registered users.
● Fields:
○ CustomerID (Primary Key)
○ Name (VARCHAR)
○ Email (VARCHAR, UNIQUE)
○ PasswordHash (VARCHAR, for security)
○ ShippingAddress (TEXT)
○ BillingAddress (TEXT)
○ Phone (VARCHAR)
○ RegistrationDate (DATETIME)
○ Preferences (TEXT, e.g., JSON or comma-separated list)
● Relationships: One-to-Many with Order (a customer can place many orders).
2. Product Table
● Purpose: Stores details about each item available for sale.
● Fields:
○ ProductID (Primary Key)
○ Name (VARCHAR)
○ Description (TEXT)
○ Price (DECIMAL)
○ StockQuantity (INTEGER)
○ ImageURL (VARCHAR)
○ Weight (DECIMAL)
○ Dimensions (VARCHAR)
○ SKU (VARCHAR, UNIQUE)
○ CategoryID (Foreign Key to [Link])
○ SupplierID (Foreign Key to [Link])
● Relationships: Many-to-One with Category and Supplier. One-to-Many with OrderItem
(a product can be in many order items).
3. Category Table
● Purpose: Organizes products into logical groups.
● Fields:
○ CategoryID (Primary Key)
○ Name (VARCHAR, UNIQUE)
○ Description (TEXT)
● Relationships: One-to-Many with Product.
4. Supplier Table
● Purpose: Stores information about product suppliers.
 ● Fields:
○ SupplierID (Primary Key)
○ Name (VARCHAR)
○ ContactPerson (VARCHAR)
○ Phone (VARCHAR)
○ Email (VARCHAR)
○ Address (TEXT)
● Relationships: One-to-Many with Product.
5. Order Table
● Purpose: Represents a customer's purchase transaction.
● Fields:
○ OrderID (Primary Key)
○ OrderDate (DATETIME)
○ TotalAmount (DECIMAL)
○ OrderStatus (VARCHAR, e.g., 'Pending', 'Processing', 'Shipped', 'Delivered',
'Cancelled')
○ CustomerID (Foreign Key to [Link])
○ ShippingID (Foreign Key to [Link], One-to-One relationship)
○ PaymentID (Foreign Key to [Link], One-to-One relationship)
● Relationships: Many-to-One with Customer, Shipping, Payment. One-to-Many with
OrderItem.
6. OrderItem Table
● Purpose: Details individual products within a speci�c order.
● Fields:
○ OrderItemID (Primary Key)
○ OrderID (Foreign Key to [Link])
○ ProductID (Foreign Key to [Link])
○ Quantity (INTEGER)
○ UnitPrice (DECIMAL)
○ Discount (DECIMAL)
● Relationships: Many-to-One with Order and Product. The combination of OrderID and
ProductID could also form a composite unique key.
7. Payment Table
● Purpose: Records all payment transactions associated with orders.
● Fields:
○ PaymentID (Primary Key)
○ OrderID (Foreign Key to [Link], UNIQUE to enforce One-to-One)
○ PaymentType (VARCHAR)
○ Amount (DECIMAL)
○ PaymentDate (DATETIME)
○ TransactionID (VARCHAR, from payment gateway)
○ PaymentStatus (VARCHAR, e.g., 'Success', 'Pending', 'Failed')
● Relationships: One-to-One with Order.
8. Shipping Table
● Purpose: Manages the logistics and status of product delivery.
● Fields:
○ ShippingID (Primary Key)
○ OrderID (Foreign Key to [Link], UNIQUE to enforce One-to-One)
○ ShippingAddress (TEXT)
○ ShippingMethod (VARCHAR)
○ ShippingCost (DECIMAL)
○ TrackingNumber (VARCHAR)
○ ShippingStatus (VARCHAR, e.g., 'Pending', 'In Transit', 'Delivered')
● Relationships: One-to-One with Order.
This detailed breakdown of tables, �elds, and their relationships provides a comprehensive
structural de�nition for the e-commerce database, ensuring logical organization, data
integrity, and e�cient querying.

3.4 Normalize database

Database normalization is a systematic process in relational database design aimed at

organizing data e�ciently to reduce redundancy and improve data integrity.27 It involves
breaking down large, complex tables into smaller, more manageable, and well-structured
ones, de�ning clear relationships between them. The primary goal is to prevent common data
anomalies: insertion anomalies (di�culty adding new data due to missing other data), update
anomalies (inconsistencies arising from updating data in multiple places), and deletion
anomalies (unintended loss of data when other data is deleted).28 Normalization also
enhances data consistency, accuracy, and scalability, while reducing storage costs.28
The process follows a hierarchy of normal forms, each imposing stricter rules:

3.4.1 First Normal Form (1NF)

De�nition: A table is in 1NF if all its columns contain atomic (indivisible) values, each row is
unique (typically enforced by a primary key), each column has a unique name, and there are
no repeating groups or arrays within a row.27
E-commerce Example:
Consider an unnormalized table CustomerPurchases where a customer's purchased products
are stored in a single, multi-valued column:
Customer ID Customer Name Purchased Products
101 John Doe Laptop, Mouse
102 Jane Smith Tablet
This violates 1NF because "Purchased Products" is not atomic. Searching for customers who
bought "Mouse" would be ine�cient, and data integrity would be di�cult to enforce.
Transformation to 1NF: To achieve 1NF, the multi-valued column is split into separate rows,
ensuring each cell contains only one value:
CustomerProducts (in 1NF):
Customer ID Customer Name Product
101 John Doe Laptop
101 John Doe Mouse
102 Jane Smith Tablet

Now, each row represents a single product purchased by a customer, simplifying queries and
updates.

3.4.2 Second Normal Form (2NF)

De�nition: A table is in 2NF if it is already in 1NF, and every non-prime a�ribute (an a�ribute
not part of the primary key) is fully functionally dependent on the entire primary key, not just a
part of it.27 This addresses partial dependencies.
E-commerce Example:
Consider a 1NF table OrderDetails with a composite primary key (Order ID, Product):
Order ID Customer ID Customer Name Product
201 101 John Doe Laptop
202 101 John Doe Mouse
203 102 Jane Smith Tablet

Here, "Customer Name" depends only on "Customer ID," which is only a part of the composite
primary key (Order ID, Product). This is a partial dependency. If John Doe places multiple
orders, his name is redundantly repeated for each order line item.
Transformation to 2NF: To achieve 2NF, separate the customer information into its own table:
Orders Table (in 2NF):
Order ID Customer ID Product
201 101 Laptop
202 101 Mouse
203 102 Tablet

Customers Table (in 2NF):

Customer ID Customer Name
101 John Doe
102 Jane Smith

This eliminates redundancy of customer details and simpli�es updates.

3.4.3 Third Normal Form (3NF)

De�nition: A table is in 3NF if it is already in 2NF, and all non-prime a�ributes are functionally
dependent only on the primary key, meaning there are no transitive dependencies (non-key
a�ributes depending on other non-key a�ributes).27
E-commerce Example:
Consider a 2NF table OrderItems that includes product and supplier information:
Order ID Product Supplier
201 Laptop HP
202 Mouse Logitech
203 Tablet Apple

Here, "Supplier" depends on "Product," and "Product" depends on "Order ID." This forms a
transitive dependency: "Supplier" indirectly depends on "Order ID" through "Product." The
supplier information for "Laptop" (HP) is repeated every time "Laptop" appears in an order.
Transformation to 3NF: To achieve 3NF, move product and supplier information to separate
tables:
Orders Table (in 3NF):
Order ID Product ID
201 301
202 302
203 303

Products Table (in 3NF):

Product ID Product Name Supplier ID
301 Laptop 401
302 Mouse 402
303 Tablet 403

Suppliers Table (in 3NF):

Supplier ID Supplier Name
401 HP
402 Logitech
403 Apple

This removes transitive dependencies, reducing data duplication and improving

maintainability.

3.4.4 Boyce-Codd Normal Form (BCNF)

De�nition: BCNF is a stricter version of 3NF. A table is in BCNF if, for every non-trivial
functional dependency X → Y, X must be a superkey (a unique identi�er for a record in the
table).27 It addresses certain edge cases where 3NF does not eliminate all redundancy,
particularly with overlapping candidate keys.
E-commerce Example:
Consider a table ProductSellerSKU where a product can be sold by multiple sellers, each
assigning a unique SellerSKU for that product, and SellerSKU uniquely identi�es the
ProductCode:
ProductCode SellerID SellerSKU
P101 S001 SKU-A
P101 S002 SKU-B

Functional dependencies: (ProductCode, SellerID) → SellerSKU (Primary Key). Also, SellerSKU

→ ProductCode.
This table is in 3NF, but not in BCNF, because SellerSKU is a determinant for ProductCode but
is not a superkey for the entire table (it doesn't uniquely identify a row by itself).
Transformation to BCNF: Decompose the table so that every determinant is a candidate key
in its respective table:
ProductSeller Table (in BCNF):
ProductCode SellerID
P101 S001
P101 S002

SellerProductSKU Table (in BCNF):

SellerSKU ProductCode
SKU-A P101
SKU-B P101

Applying these normal forms ensures that the database is e�cient, consistent, and scalable,
minimizing data redundancy and improving overall data integrity. For most practical
applications, achieving 3NF or BCNF is su�cient to design a robust and maintainable
relational schema.
IV. System Design

System design translates the requirements into a high-level architecture, outlining the
components, their interactions, and how they are deployed. This section utilizes Uni�ed
Modeling Language (UML) diagrams to visually represent di�erent aspects of the system.

4.1 Class diagram

A UML Class Diagram is a fundamental visual tool in object-oriented so�ware engineering that
represents the static structure of a system.29 It depicts the system's classes, their a�ributes
(data members), methods (operations), and the relationships between them. These diagrams
are invaluable for modeling the data structure and designing the system in detail, helping all
project stakeholders understand how components are organized and interact.30
Conceptual Class Diagram for an E-commerce Website:
The class diagram for an e-commerce system would typically include classes representing
core entities and their interactions:
● User Class:
○ A�ributes: Username, PasswordHash, Email, RegistrationDate
○ Methods: Login(), Logout(), Register()
● Customer Class (inherits from User or has a relationship with User):
○ A�ributes: CustomerID, Name, ShippingAddress, BillingAddress, Phone,
Preferences
○ Methods: UpdatePro�le(), ViewOrderHistory()
● Admin Class (inherits from User or has a relationship with User):
○ A�ributes: AdminID, AdminName, AdminPasswordHash
○ Methods: Login(), Logout(), ManageProducts(), ManageOrders(), ManageUsers()
● Product Class:
○ A�ributes: ProductID, ProductName, ProductDescription, ProductPrice,
StockQuantity, ImageURL, SKU, Weight
○ Methods: AddProduct(), RemoveProduct(), UpdateStock()
● Category Class:
○ A�ributes: CategoryID, Name, Description
● ShoppingCart Class:
○ A�ributes: CartID, CreationDate
○ Methods: AddToCart(product, quantity), RemoveFromCart(product),
UpdateQuantity(product, quantity), CalculateTotal(), Checkout()
● Order Class:
○ A�ributes: OrderID, OrderDate, TotalAmount, OrderStatus
○ Methods: PlaceOrder(), UpdateStatus()
 ● OrderItem Class:
○ A�ributes: OrderItemID, Quantity, UnitPrice, Discount
● Payment Class:
○ A�ributes: PaymentID, PaymentType, Amount, PaymentDate, TransactionID,
PaymentStatus
○ Methods: MakePayment(), ProcessRefund()
● Shipping Class:
○ A�ributes: ShippingID, ShippingAddress, ShippingMethod, ShippingCost,
TrackingNumber, ShippingStatus
○ Methods: ShipOrder(), UpdateShippingStatus()
Relationships between classes:
● User {1}--{*} Order: One User can place multiple Orders.
● Order {1}--{*} OrderItem: One Order can contain multiple OrderItems.
● OrderItem {1}--{1} Product: Each OrderItem refers to one Product.
● ShoppingCart {1}--{*} Product: A ShoppingCart can contain multiple Products.
● Order {1}--{1} Payment: One Order is associated with one Payment.
● Order {1}--{1} Shipping: One Order is associated with one Shipping.
● Admin {1}--{} Product, Admin {1}--{} Order, Admin {1}--{*} User: An Admin can manage
multiple Products, Orders, and Users.
● Product {0..}--{0..} Category: A Product can belong to multiple Categories, and a
Category can have multiple Products (many-to-many, o�en resolved with an association
class or junction table).
● Dependencies (represented by dashed arrows): Payment depends on Order (e.g.,
MakePayment method needs Order details), Shipping depends on Order.
This class diagram provides a clear blueprint of the system's structure, illustrating how
features like product listings, inventory, shopping carts, orders, payments, and shipping details
interact during an online sales transaction.30 It helps in planning and development, ensuring all
necessary elements are included and properly connected.

4.2 Object diagram

A UML Object Diagram provides a snapshot of the system at a particular point in time,
showing speci�c instances of classes (objects) and their relationships.32 Unlike class
diagrams, which represent the static structure, object diagrams illustrate the runtime objects
with their actual a�ribute values. They are useful for visualizing complex data structures and
demonstrating speci�c scenarios or con�gurations of the system.
Conceptual Object Diagram for a Login Scenario:
While a detailed e-commerce object diagram can be extensive, a simple example for a login
controller object can illustrate the concept:
Imagine a user johnDoe a�empts to log in. The system would create instances of the User
class and potentially a LoginController class to handle the authentication process.
 ● johnDoe:Customer
○ Username = "[Link]"
○ PasswordHash = "hashed_password_123"
○ Email = "[Link]@[Link]"
○ IsLoggedIn = false
● loginHandler:LoginController
○ A�emptCount = 0
○ LastLoginA�empt = null
○ StatusMessage = "Please enter credentials"
In this snapshot, johnDoe is an instance of the Customer class, with speci�c values for his
username, hashed password, email, and a false login status. loginHandler is an instance of a
LoginController class, tracking login a�empt metrics and a status message. As the user
interacts, these a�ribute values would change (e.g., A�emptCount increments, IsLoggedIn
becomes true upon successful authentication). This diagram helps visualize the state of
objects and their data during a speci�c operation.

4.3 Component diagram

A UML Component Diagram provides a high-level, "white-box" view of the system's

architecture, illustrating how di�erent so�ware components interact and depend on each
other.33 Components are modular, reusable parts of the system, o�en implemented as
so�ware modules, classes, or packages, and they encapsulate their behavior and data.35 They
interact through well-de�ned interfaces, which specify the services a component provides or
requires.
Conceptual Component Diagram for an Online Retail System:
An e-commerce system can be broken down into several key subsystems and components:
● WebStore Subsystem («Subsystem» WebStore)
○ Search Engine Component: This component handles product search and
browsing functionalities.
■ Provided Interface: Product Search (allows users/other components to
search for products).
■ Required Interface: Search Inventory (needs to query the Inventory
component for product data).
○ Shopping Cart Component: Manages user shopping carts and the checkout
process.
■ Required Interface: Manage Orders (needs to interact with the Orders
component during checkout to create new orders).
○ Authentication Component: Manages user login, registration, and account
security.
■ Provided Interface: User Authentication (allows users to log in/out).
■ Required Interface: User Management (needs to interact with the
 Customers component in the Accounting Subsystem).
● Warehouses Subsystem («Subsystem» Warehouses)
○ Inventory Component: Manages product stock levels and availability.
■ Provided Interface: Search Inventory (provides product stock information to
the Search Engine).
■ Provided Interface: Manage Inventory (allows other components to update
stock levels).
● Accounting Subsystem («Subsystem» Accounting)
○ Orders Component: Manages all order-related data and processes.
■ Provided Interface: Manage Orders (allows other components to create or
update orders).
○ Customers Component: Manages customer account details.
■ Provided Interface: Manage Customers (allows other components to access
or modify customer data).
○ Payment Processing Component: Handles all �nancial transactions.
■ Required Interface: Payment Gateway API (interacts with external payment
services).
Interactions and Dependencies:
● The Search Engine component in the WebStore uses the Search Inventory interface
provided by the Inventory component in the Warehouses subsystem.
● The Shopping Cart component in the WebStore uses the Manage Orders interface
provided by the Orders component in the Accounting subsystem during checkout.
● The Authentication component in the WebStore uses the Manage Customers interface
provided by the Customers component in the Accounting subsystem for user validation
and management.
● The Payment Processing component in the Accounting subsystem communicates with
external Payment Gateway services.
This component diagram visually structures the e-commerce system into logical, independent,
and reusable units, highlighting their interfaces and dependencies.34 This modularity aids in
development, testing, and maintenance, allowing di�erent teams to work on separate
components concurrently while ensuring proper integration.

4.4 Deployment diagram

A UML Deployment Diagram is a structural diagram that illustrates the physical deployment of
so�ware components (artifacts) on hardware nodes within a system.35 It provides a view of
the hardware system's topology, showing where so�ware elements are placed on physical
devices and how these devices connect and communicate. This diagram is crucial for planning
hardware infrastructure, network setups, and ensuring that so�ware parts have su�cient
resources to run e�ectively.35
Key elements of a deployment diagram include:
 ● Nodes: Represented as three-dimensional boxes, these are physical hardware entities
(e.g., servers, workstations, mobile devices) or execution environments (e.g., operating
systems, JVMs) where so�ware components are deployed.35
● Artifacts: These are physical �les that represent the actual implementation of so�ware
components, such as executable �les, libraries, or database schemas. They are typically
depicted as rectangles with the word «artifact».35
● Components: Represented as rectangles with two small tabs, these denote so�ware
modules or reusable parts of the system that are deployed onto nodes.35
● Communication Paths (Associations): Lines connecting nodes, indicating channels or
connections that facilitate communication between them (e.g., network connections like
HTTP/HTTPS).35
Conceptual Deployment Diagram for an E-commerce System:
A typical deployment diagram for an online retail store would show the distribution of its
so�ware across various hardware resources:
● User's Device Node («device» UserClient)
○ Represents the client-side hardware, such as a user's laptop, desktop, or mobile
phone.
○ Artifacts: «artifact» [Link], «artifact» [Link], «artifact»
[Link] (representing the web application �les accessed by the
browser).
○ Communication Path: Connects via Internet (HTTPS) to the Web Server.
● Web Server Node («device» WebServer)
○ Hosts the front-end application and handles incoming HTTP/HTTPS requests.
○ Components: Web Application Server (e.g., Nginx, Apache).
○ Artifacts: «artifact» [Link] (containing compiled web application code).
○ Communication Path: Connects via Internal Network (HTTP/HTTPS) to the
Application Server.
● Application Server Node («device» ApplicationServer)
○ Hosts the backend business logic and services.
○ Components: Product Service, Order Service, User Authentication Service,
Inventory Service.
○ Artifacts: «artifact» [Link] (containing backend application code).
○ Communication Path 1: Connects via Database Connection (JDBC/ODBC) to the
Database Server.
○ Communication Path 2: Connects via External API (HTTPS) to the Payment
Gateway Server.
● Database Server Node («device» DatabaseServer)
○ Hosts the relational database for storing product, customer, and order data.
○ Components: Database Management System (e.g., MySQL, PostgreSQL).
○ Artifacts: «artifact» [Link], «artifact» [Link] (representing
database schemas and data �les).
● Payment Gateway Server Node («device» PaymentGatewayServer)
 ○ Represents an external, third-party payment processing service.
○ Communication Path: Connects via External API (HTTPS) to the Application
Server.
This diagram visually represents how the e-commerce so�ware is distributed across di�erent
physical machines and how these machines interact to provide the online shopping
experience.35 It is essential for understanding the system's infrastructure, planning resource
allocation, and identifying potential bo�lenecks or points of failure in the physical deployment.

4.5 Use case diagram

A UML Use Case Diagram is a behavioral diagram used in the early stages of so�ware
development to model the behavior of a system and capture its functional requirements from
the perspective of external actors.37 It illustrates "what" a system does, rather than "how" it
does it, by depicting the interactions and relationships between actors and use cases.
Key elements of a Use Case Diagram include:
● Actors: Represented by stick �gures, these are individuals or external systems that
interact with the system to achieve a goal (e.g., Customer, Administrator, Payment
Gateway).38
● Use Cases: Represented by ovals, these describe a speci�c functionality or a sequence
of actions performed by the system to yield an observable result of value to an actor
(e.g., Browse Products, Make Payment).38
● Relationships: Lines connecting actors to use cases (associations), or connecting use
cases to other use cases (include, extend, generalization).38
○ «include»: Indicates that one use case incorporates the functionality of another
(e.g., Checkout «include» Make Payment).
○ «extend»: Shows that one use case extends the behavior of another under
speci�c conditions (e.g., Make Payment «extend» Apply Promotional Code).
Conceptual Use Case Diagram for an Online Retail Store:
Actors:
● Customer: The primary user who shops online.
● Administrator: Manages the store's operations.
● Payment Gateway: External system for processing payments.
● Shipping Carrier: External system for handling product delivery.
Use Cases:
Customer Use Cases:
● Browse Products: View available items, categories.
● Search Products: Find speci�c products using keywords or �lters.
● View Product Details: Access detailed information about a product (images,
descriptions, reviews).
● Add to Cart: Place selected items into the shopping cart.
● View Shopping Cart: Review items in the cart, quantities, and subtotal.
 ● Update Shopping Cart: Modify quantities or remove items from the cart.
● Checkout: Initiate the purchase process.
○ «include» Make Payment: Process the payment for the order.
■ «extend» Apply Promotional Code: Apply a discount code during
payment.
● Register Account: Create a new user account.
● Login: Access an existing user account.
● Track Order: Monitor the status and delivery progress of a placed order.
● Manage Pro�le: Update personal information, addresses, and preferences.
● Initiate Return/Refund: Request a return or refund for a purchased item.
Administrator Use Cases:
● Manage Products: Add, edit, or remove product listings.
● Manage Categories: Create, update, or delete product categories.
● Manage Orders: View, update status, or cancel customer orders.
● Manage Users: View, activate, or suspend user accounts.
● Manage Promotions: Create, modify, or deactivate discount codes and sales
campaigns.
● View Reports: Access various business intelligence reports (sales, inventory, customer
behavior).
System-to-System Use Cases (o�en implied by interactions):
● Process Payment: (Performed by Payment Gateway, initiated by Make Payment).
● Ship Order: (Performed by Shipping Carrier, initiated by Order Management).
This diagram provides a high-level overview of the system's functionalities, clearly de�ning the
interactions between di�erent types of users and the system's capabilities.38 It serves as a
valuable tool for communicating the system's scope to both technical and non-technical
stakeholders.

4.6 Activity diagram

A UML Activity Diagram is a behavioral diagram that models the dynamic aspects of a system
by representing the �ow of control and the sequence of actions or activities performed.39 It is
particularly useful for visualizing business processes, work�ows, and the steps involved in
complex operations, such as an online shopping order process. Activity diagrams use
swimlanes to partition activities by the organizational unit or actor responsible for them,
clarifying responsibilities.
Conceptual Activity Diagram for Online Shopping Order Process:
This diagram illustrates the typical �ow a customer follows from browsing to order
con�rmation.
● Initial Node ((O))
○ Represents the start of the process.
● Activity: Browse Products
 ○ Customer explores the product catalog.
● Decision Node (◇): Search or Browse?
○ If Search:
■ Activity: Search Products
■ Customer enters keywords or applies �lters.
○ If Browse or a�er Search Products:
■ Activity: View Product Details
■ Customer examines speci�c product information.
● Activity: Add to Cart
○ Customer adds a product to their shopping cart.
● Fork Node (=)
○ Indicates parallel activities.
○ Activity: Price is Calculated (System responsibility, o�en concurrent)
○ Activity: View/Update Shopping Cart (Customer can review and modify items in
cart at any time).
● Decision Node (◇): Continue Shopping or Checkout?
○ If Continue Shopping:
■ Returns to Browse Products or View Product Details.
○ If Checkout:
■ Activity: Enter Shipping Information
■ Customer provides delivery details.
■ Activity: Process Payment
■ Customer enters payment details, system interacts with payment
gateway.
■ Activity: Place Order
■ Customer con�rms the �nal order.
● Activity: Order Con�rmation
○ System displays a con�rmation message and sends an email.
● Final Node ((X))
○ Represents the end of the process.
Swimlanes (Optional but Recommended for Clarity):
● Customer: Browse Products, Search Products, View Product Details, Add to Cart,
View/Update Shopping Cart, Enter Shipping Information, Process Payment, Place Order.
● System: Price is Calculated, Order Con�rmation.
● Payment Gateway (External): (Implicitly interacts with Process Payment).
This activity diagram provides a clear, step-by-step visual representation of the online
shopping process, highlighting the sequence of actions and decision points.39 It helps in
understanding the work�ow, identifying potential bo�lenecks, and ensuring a seamless
customer journey from product discovery to order completion.

4.7 State chart diagram

A UML State Chart Diagram (also known as a State Machine Diagram) is a behavioral diagram
that visualizes the lifecycle of an object, showing the di�erent states an object can be in and
the transitions between these states triggered by events.41 It is particularly useful for modeling
reactive systems and understanding how an object behaves in response to internal or external
events, clarifying intricate system behaviors.
Conceptual State Chart Diagram for E-commerce Order Status:
This diagram illustrates the typical states an Order object transitions through from creation to
completion or cancellation.
● Initial State ((O))
○ Represents the starting point of an order's lifecycle.
● State: Pending
○ The order has been placed by the customer but not yet con�rmed or processed
(e.g., payment awaiting authorization).
○ Transition: Payment Authorized → Processing
○ Transition: Customer Cancels → Cancelled
○ Transition: Payment Failed → Failed
● State: Processing
○ The order has been con�rmed, and internal ful�llment processes have begun
(e.g., inventory allocation, picking items).
○ Transition: Items Packed → Ready for Shipment
○ Transition: Out of Stock Item → Backordered (if applicable)
● State: Ready for Shipment
○ Items are packed and awaiting pickup by the shipping carrier.
○ Transition: Shipped → Shipped
● State: Shipped
○ The order has le� the warehouse and is in transit to the customer.
○ Transition: Delivered → Delivered
○ Transition: Delivery Exception → Delivery Issue
● State: Delivered
○ The order has successfully reached the customer. This is a �nal state.
● State: Cancelled
○ The order was cancelled by the customer or administrator. This is a �nal state.
● State: Failed
○ The order could not be processed due to payment failure or other issues. This is a
�nal state.
● State: Backordered
○ One or more items in the order are out of stock and awaiting replenishment.
○ Transition: Stock Replenished → Processing
This state chart diagram provides a clear visual representation of the various statuses an
e-commerce order can have and the events that cause transitions between these statuses.41 It
helps in understanding the order ful�llment work�ow, managing expectations, and designing
the logic for order tracking and noti�cations.
4.8 Sequence diagram

A UML Sequence Diagram (also known as an Event Diagram) is a behavioral diagram that
illustrates how objects interact with each other in a speci�c order over time to perform a
particular function or use case.32 It shows the sequence of messages exchanged between
objects, arranged chronologically from top to bo�om. This diagram is particularly useful for
visualizing complex interactions and identifying potential bo�lenecks or points of friction in a
user �ow.
Conceptual Sequence Diagram for User Login in an E-commerce System:
This diagram illustrates the step-by-step interaction for a user logging into the e-commerce
pla�orm.
● Actors/Objects: User (Actor), Login Page (Boundary/UI), Authentication Service
(Control), Database (Entity).
● Sequence of Messages:
1. User activates Login Page.
2. User enters username and password into Login Page.
3. User clicks Login Bu�on on Login Page.
4. Login Page sends authenticate(username, password) message to Authentication
Service.
5. Authentication Service sends validateCredentials(username, password) message
to Database.
6. Database processes validation.
7. Database returns isValidUser(boolean) to Authentication Service.
8. Alternative Fragment (alt):
■ [If isValidUser is true]:
■ Authentication Service sends loginSuccess() to Login Page.
■ Login Page redirects User to Homepage.
■ Login Page displays “Login successful!” message to User.
■ [Else (isValidUser is false)]:
■ Authentication Service sends loginFailed() to Login Page.
■ Login Page displays “Invalid username or password.” message to
User.
■ Login Page clears password �eld for User.
This sequence diagram provides a clear, chronological overview of the login process, showing
how the user, login interface, authentication logic, and database interact to complete the
task.43
Conceptual Sequence Diagram for E-commerce Checkout Process:
This diagram outlines the interactions involved when a customer completes a purchase.
● Actors/Objects: Customer (Actor), Shopping Cart (Boundary/UI), Checkout Service
(Control), Payment Gateway (External System), Inventory Management (Control), Order
Service (Control), Shipping Service (Control), Alerts System (Control).
 ● Sequence of Messages:
1. Customer initiates Checkout from Shopping Cart.
2. Shopping Cart sends getCartItems() to Checkout Service.
3. Checkout Service displays shipping and payment options to Customer.
4. Customer enters shipping details and payment method into Checkout Service.
5. Checkout Service sends authorizePayment(paymentDetails) to Payment Gateway.
6. Payment Gateway processes authorization.
7. Payment Gateway returns paymentStatus to Checkout Service.
8. Alternative Fragment (alt):
■ :
■ Checkout Service sends deductStock(cartItems) to Inventory
Management.
■ Inventory Management returns stockUpdateStatus to Checkout
Service.
■ Checkout Service sends createOrder(customerInfo, cartItems) to
Order Service.
■ Order Service returns orderCon�rmationDetails to Checkout Service.
■ Checkout Service sends scheduleShipment(orderDetails) to Shipping
Service.
■ Shipping Service returns trackingNumber to Checkout Service.
■ Checkout Service displays Order Con�rmation to Customer.
■ Checkout Service sends sendCon�rmationEmail(orderDetails) to
Alerts System.
■ :
■ Checkout Service displays “Payment Failed. Please try again.” to
Customer.
This sequence diagram o�ers a precise, systematic perspective of how consumers interact
with the backend of an online store during checkout, from item selection to order
con�rmation.42 It helps identify bo�lenecks and speci�es every interaction, which is crucial for
optimizing conversion rates.

4.9 Collaboration diagram

A UML Collaboration Diagram (now more commonly referred to as a Communication Diagram)

is a behavioral diagram that illustrates the interactions between objects in a system, focusing
on the structural organization of objects that send and receive messages.32 Unlike sequence
diagrams that emphasize the time ordering of messages, collaboration diagrams highlight the
relationships between objects and the messages they exchange to achieve a speci�c goal.
Messages are numbered to indicate their sequence.
Conceptual Collaboration Diagram for "Add to Cart" Scenario in E-commerce:
This diagram illustrates the objects involved and the messages exchanged when a customer
adds a product to their shopping cart.
● Objects/Roles:
○ webCustomer (Actor)
○ productSearch (representing the Search Engine component)
○ productCatalog (representing the Product Catalog/Database)
○ shoppingCart (representing the Shopping Cart component)
○ inventory (representing the Inventory Management component)
● Interactions and Messages:
1. webCustomer sends 1: �nd_products() to productSearch.
■ This iterative message represents the customer searching or browsing for
products.
2. productSearch sends 1.1: query_products(keywords) to productCatalog.
■ The search engine queries the product catalog for relevant items.
3. productCatalog returns 1.1.1: product_list to productSearch.
4. webCustomer sends 1.2 [interested]: view_product_details(productID) to
productSearch.
■ If interested, the customer requests to view details of a speci�c product.
5. productSearch sends 1.2.1: get_product_details(productID) to productCatalog.
6. productCatalog returns [Link]: product_details to productSearch.
7. webCustomer sends 1.3 [decided to buy]: add_to_cart(productID, quantity) to
shoppingCart.
■ The customer decides to add a product to the cart.
8. shoppingCart sends 1.3.1: check_stock(productID, quantity) to inventory.
■ The shopping cart veri�es stock availability.
9. inventory returns [Link]: stock_status to shoppingCart.
10. shoppingCart sends 1.3.2: update_cart(productID, quantity) to itself (internal
message).
11. shoppingCart sends 1.3.3: display_cart_con�rmation() to webCustomer.
■ The shopping cart con�rms the addition to the customer.
This collaboration diagram visually emphasizes the relationships between the objects involved
in the "add to cart" scenario and the sequence of messages exchanged to accomplish this
task.46 It provides a clear understanding of the structural context of the interactions.

V. Python Sample Codes

This section provides illustrative Python code snippets for key functionalities of the
e-commerce online retail store, demonstrating basic logic for user authentication, product
listing, shopping cart operations, and order processing. These examples are simpli�ed for
clarity and educational purposes, rather than being production-ready code.
5.1 User Authentication

User authentication is a critical security feature, allowing only authorized users to access their
accounts. This example demonstrates a basic console-based login and registration system.
For a real-world application, a web framework like Django would provide more robust, secure,
and production-ready authentication features, including password hashing and session
management.47

Python

# Basic User Authentication System (Console-based)

users_db = {} # In a real system, this would be a database

def register_user():
"""Handles new user registration."""
print("\n--- Register New User ---")
while True:
username = input("Enter desired username: ").strip()
if username in users_db:
print("Username already exists. Please choose a di�erent one.")
else:
break
password = input("Enter password: ").strip()
users_db[username] = password # In real app, hash password!
print(f"User '{username}' registered successfully!")

def login_user():
"""Handles user login."""
print("\n--- User Login ---")
username = input("Enter username: ").strip()
password = input("Enter password: ").strip()

if username in users_db and users_db[username] == password: # In real app, compare

hashed passwords
print(f"Welcome, {username}! Login successful.")
return True
else:
print("Invalid username or password.")
return False
# --- Main program loop for authentication demo ---
if __name__ == "__main__":
while True:
print("\n--- Authentication Menu ---")
print("1. Register")
print("2. Login")
print("3. Exit")
choice = input("Enter your choice (1-3): ")

if choice == '1':
register_user()
elif choice == '2':
if login_user():
# Simulate access to e-commerce features a�er successful login
print("You can now access the online store features.")
# break # Uncomment to exit a�er successful login
elif choice == '3':
print("Exiting authentication system. Goodbye!")
break
else:
print("Invalid choice. Please try again.")

Explanation:
This code provides a simple command-line interface for user registration and login. The
users_db dictionary acts as a placeholder for a database. For registration, it prompts for a
unique username and a password, storing them. For login, it checks if the provided username
and password match the stored credentials. In a production environment, passwords would
always be securely hashed, and a proper database or authentication framework (like Django's
built-in system) would be used to handle user accounts and sessions.47

5.2 Product Listing

Displaying products is a core function of any online retail store. This example demonstrates
how to represent products using a list of dictionaries and display them to the user. In a real
e-commerce pla�orm, this data would be fetched from a database and dynamically rendered
on a web page using a framework's templating system.50

Python
# Product Listing Example

products =

def display_products(product_list):
"""Displays a list of products with their details."""
print("\n--- Available Products ---")
if not product_list:
print("No products available at the moment.")
return

for product in product_list:

print(f"Product ID: {product['id']}")
print(f"Name: {product['name']}")
print(f"Description: {product['description']}")
print(f"Price: ${product['price']:.2f}") # Format price to 2 decimal places
print(f"Stock: {product['stock']}")
print(f"Category: {product['category']}")
print("-" * 30) # Separator for readability

# --- Main program loop for product listing demo ---

if __name__ == "__main__":
display_products(products)

# Example of �ltering products (e.g., by category)

electronics_products = [p for p in products if p['category'] == 'Electronics']
print("\n--- Electronics Products ---")
display_products(electronics_products)

# Example of searching products (e.g., by name keyword)

search_term = "mouse"
found_products = [p for p in products if search_term.lower() in p['name'].lower()]
print(f"\n--- Products matching '{search_term}' ---")
display_products(found_products)

Explanation:
The products list stores product information as dictionaries, where each dictionary represents
a product with keys like id, name, price, and stock. The display_products function iterates
through this list and prints each product's details in a forma�ed way. This simple structure
allows for easy access and display of product information, which is fundamental for a product
catalog.52
5.3 Shopping Cart Operations

The shopping cart is a crucial component where customers collect items before purchase.
This example demonstrates basic operations like adding, viewing, removing items, and
calculating the total.

Python

# Shopping Cart Operations Example

# Assume 'products' list from the previous section is available

# products = [...]

class ShoppingCart:
def __init__(self):
[Link] = # Stores {'product_id': id, 'quantity': qty}

def add_item(self, product_id, quantity):

"""Adds an item to the cart or updates its quantity."""
product = next((p for p in products if p['id'] == product_id), None)
if not product:
print(f"Error: Product with ID {product_id} not found.")
return

if product['stock'] < quantity:

print(f"Not enough stock for {product['name']}. Available: {product['stock']}")
return

for item in [Link]:

if item['product_id'] == product_id:
if product['stock'] < item['quantity'] + quantity:
print(f"Cannot add {quantity} more. Only {product['stock'] - item['quantity']}
available.")
return
item['quantity'] += quantity
print(f"Updated quantity for {product['name']} to {item['quantity']}.")
return

[Link]({'product_id': product_id, 'quantity': quantity})

print(f"Added {quantity} x {product['name']} to cart.")
 def remove_item(self, product_id):
"""Removes an item from the cart."""
initial_len = len([Link])
[Link] = [item for item in [Link] if item['product_id']!= product_id]
if len([Link]) < initial_len:
product = next((p for p in products if p['id'] == product_id), {"name": "Unknown
Product"})
print(f"Removed {product['name']} from cart.")
else:
print(f"Product with ID {product_id} not found in cart.")

def view_cart(self):
"""Displays all items currently in the cart."""
print("\n--- Your Shopping Cart ---")
if not [Link]:
print("Your cart is empty.")
return

for item in [Link]:

product = next((p for p in products if p['id'] == item['product_id']), None)
if product:
line_total = product['price'] * item['quantity']
print(f" {product['name']} (ID: {product['id']}) x {item['quantity']} @
${product['price']:.2f} = ${line_total:.2f}")
else:
print(f" Unknown Product (ID: {item['product_id']}) x {item['quantity']}")
print("-" * 30)

def compute_total(self):
"""Calculates the total price of all items in the cart."""
total_price = 0
for item in [Link]:
product = next((p for p in products if p['id'] == item['product_id']), None)
if product:
total_price += product['price'] * item['quantity']
print(f"\n--- Cart Total: ${total_price:.2f} ---")
return total_price

# --- Main program loop for shopping cart demo ---

if __name__ == "__main__":
my_cart = ShoppingCart()

display_products(products) # Show available products �rst

 my_cart.add_item(1, 2) # Add 2 Laptops
my_cart.add_item(3, 1) # Add 1 Keyboard
my_cart.add_item(2, 3) # Add 3 Wireless Mice
my_cart.add_item(1, 1) # Add 1 more Laptop (updates quantity)
my_cart.add_item(99, 1) # Try to add non-existent product

my_cart.view_cart()
my_cart.compute_total()

my_cart.remove_item(3) # Remove Keyboard

my_cart.remove_item(99) # Try to remove non-existent item

my_cart.view_cart()
my_cart.compute_total()

Explanation:
The ShoppingCart class manages items in the cart. The add_item method adds a product by
its ID and quantity, checking for product existence and stock availability. If the item is already
in the cart, it updates the quantity. The remove_item method removes a product by ID.
view_cart displays the current contents, and compute_total calculates the sum of all item
prices. This class-based approach encapsulates shopping cart logic, making it reusable and
organized.59

5.4 Order Processing

Order processing involves taking the items from the shopping cart, �nalizing the purchase,
and calculating the total. This example provides a simpli�ed console-based demonstration of
order creation and total calculation. In a full e-commerce system, this would involve database
transactions, payment gateway integration, and inventory updates.47

Python

# Order Processing Example

# Assume 'products' list from the previous section is available

# products = [...]

# Simulate a user's �nalized shopping cart for order processing

# In a real system, this would come from the ShoppingCart object a�er checkout
sample_�nal_cart_items =

def process_order(cart_items):
"""
Processes a list of items to create an order summary and calculate total.
In a real system, this would also handle payment, inventory deduction, etc.
"""
print("\n--- Processing New Order ---")
order_details =
order_total = 0.0

if not cart_items:
print("No items to process in the order.")
return None

for item in cart_items:

product = next((p for p in products if p['id'] == item['product_id']), None)
if product:
line_item_price = product['price'] * item['quantity']
order_details.append({
"product_name": product['name'],
"quantity": item['quantity'],
"unit_price": product['price'],
"line_total": line_item_price
})
order_total += line_item_price
print(f" Added: {item['quantity']} x {product['name']} @ ${product['price']:.2f} =
${line_item_price:.2f}")

# Simulate inventory deduction (in a real system, this would update the database)
product['stock'] -= item['quantity']
print(f" (Inventory for {product['name']} reduced to {product['stock']})")

else:
print(f" Warning: Product with ID {item['product_id']} not found in catalog. Skipping.")

print("\n--- Order Summary ---")

for detail in order_details:
print(f" {detail['product_name']} (Qty: {detail['quantity']}) - Unit Price:
${detail['unit_price']:.2f} - Line Total: ${detail['line_total']:.2f}")

print(f"\nTotal Order Amount: ${order_total:.2f}")

print("Order successfully placed!")
 # In a real system, return an order object or ID, and trigger other processes
# like sending con�rmation email, updating order status in DB, etc.
return {"items": order_details, "total": order_total, "status": "Placed"}

# --- Main program loop for order processing demo ---

if __name__ == "__main__":
# Display current stock before processing order
print("--- Stock before order ---")
display_products(products)

processed_order_info = process_order(sample_�nal_cart_items)

if processed_order_info:
print("\nProcessed Order Details:")
print(f" Total: ${processed_order_info['total']:.2f}")
print(f" Status: {processed_order_info['status']}")
# print(f" Items: {processed_order_info['items']}") # Uncomment to see full item details

# Display updated stock a�er processing order

print("\n--- Stock a�er order ---")
display_products(products)

Explanation:
The process_order function takes a list of cart_items (simulating a �nalized cart). It iterates
through each item, retrieves its details from the products list, calculates the line total, and
adds it to the overall order_total. It also includes a basic simulation of inventory deduction. For
a production system, this function would involve complex logic for payment gateway
integration, creating persistent order records in a database, updating actual inventory levels,
and triggering shipping and noti�cation processes [47, S

Works cited

1. The Impact of eCommerce on Traditional Retail, accessed on July 24, 2025,

h�ps://[Link]/blog/impact-of-ecommerce-on-traditional-re
tail/
2. E-Commerce: Advantages and Disadvantages | Mailchimp, accessed on July 24,
2025,
h�ps://[Link]/resources/advantages-and-disadvantages-of-ecommerce
/
3. What Is Ecommerce? De�nition, Types, Advantages, and ..., accessed on July 24,
2025, h�ps://[Link]/learn/what-is-ecommerce
4. 6 Functional Requirements for eCommerce Website Success ..., accessed on July
24, 2025,
 h�ps://[Link]�[Link]/articles/functional-requirements-for-ecommerce-we
bsite/
5. The Fall of Traditional Retail Commerce | Nexcess, accessed on July 24, 2025,
h�ps://[Link]/resources/fall-of-traditional-commerce/
6. 15 Common Online Shopping Problems Causing Revenue Loss for ..., accessed on
July 24, 2025, h�ps://[Link]�[Link]/blog/online-shopping-problems/
7. Unlock Growth: Solve These 7 eCommerce Challenges - OptinMonster, accessed
on July 24, 2025,
h�ps://[Link]/ecommerce-business-challenges-solutions/
8. Fact Finding Techniques | PDF | Usability | Questionnaire - Scribd, accessed on
July 24, 2025,
h�ps://[Link]/presentation/360058617/2-Fact-Finding-Techniques
9. Fact �nding methods in system analysis and design, accessed on July 24, 2025,
h�ps://[Link]/ipp/images/uploads/�les/[Link]
10. The Real eCommerce Advantages and Disadvantages: Who Will ..., accessed on
July 24, 2025,
h�ps://[Link]/blog/ecommerce-advantages-and-disadvantages/
11. The Ultimate Guide to E-commerce Systems in the AI Age: Build ..., accessed on
July 24, 2025,
h�ps://[Link]/community/what-is-the-ecommerce-system-meaning-and-r
equired-resources
12. 5 Key Components of a Feasibility Study | August Brown, accessed on July 24,
2025,
h�ps://[Link]/news-item/5-key-components-of-a-feasibility-study/
13. GDPR for Ecommerce: The Ultimate Guide - CookieYes, accessed on July 24,
2025, h�ps://[Link]/blog/gdpr-for-ecommerce/
14. Extreme UltraDev - E-commerce Database Design Part 1, accessed on July 24,
2025, h�ps://[Link]/~rcurtis/ultradev/[Link]
15. What is an eCommerce Database? Components, Types & Design - Brainspate,
accessed on July 24, 2025, h�ps://[Link]/blog/ecommerce-database/
16. ER Diagram Sample for Ecommerce Project - DEV Community, accessed on July
24, 2025,
h�ps://[Link]/fpaghar/er-diagram-sample-for-ecommerce-project-1o2h
17. eCommerce Data Collection: Best Practices & Examples - Research AIMultiple,
accessed on July 24, 2025,
h�ps://[Link]/ecommerce-data-collection/
18. The Ultimate Guide to Retail Store Analytics - Dragon�y AI, accessed on July 24,
2025,
h�ps://dragon�[Link]/resources/blog/the-ultimate-guide-to-retail-store-analytics
19. Ecommerce Team Structure: 7 Key Roles for Success, accessed on July 24, 2025,
h�ps://[Link]/blog/ecommerce-team-structure
20. 8 Product Description Examples to Copy for Your Store - Tadpull, accessed on
July 24, 2025,
h�ps://[Link]/blog/product-description-examples-ecommerce-store/
21. Job Roles Within Ecommerce With Job Specs and Salaries, accessed on July 24,
 2025, h�ps://[Link]/guides/ecommerce-job-roles/
22. The Top Ecommerce Reports For Your Store (2025) - Shopify, accessed on July
24, 2025, h�ps://[Link]/enterprise/blog/ecommerce-reports
23. E-Commerce System Requirements: A Guide to Build an Online Store - DhiWise,
accessed on July 24, 2025,
h�ps://[Link]/blog/requirement-builder/ecommerce-system-require
ments
24. NFRs: What is Non Functional Requirements (Example & Types) - BrowserStack,
accessed on July 24, 2025,
h�ps://[Link]/guide/non-functional-requirements-examples
25. Understanding Non-Functional Requirements: Insights & Examples - QAT Global,
accessed on July 24, 2025,
h�ps://[Link]/guide-understanding-non-functional-requirements/
26. ER Diagram for Online Shopping | Templates and Examples, accessed on July 24,
2025,
h�ps://[Link]/erd/[Link]
27. Normal Forms in DBMS - GeeksforGeeks, accessed on July 24, 2025,
h�ps://[Link]/dbms/normal-forms-in-dbms/
28. Database Normalization: 1NF, 2NF, 3NF & BCNF Examples ..., accessed on July 24,
2025, h�ps://[Link]/community/tutorials/database-normalization
29. E-commerce website - UML Class diagram example | Gleek, accessed on July 24,
2025, h�ps://[Link]/templates/ecommerce-website-class
30. UML Class E-Commerce System Template - Miro, accessed on July 24, 2025,
h�ps://[Link]/templates/uml-ecommerce-system/
31. Class Diagram | Uni�ed Modeling Language (UML) - GeeksforGeeks, accessed on
July 24, 2025,
h�ps://[Link]/system-design/uni�ed-modeling-language-uml-
class-diagrams/
32. Online Shopping Uml Examples | PDF | Credit Card | Use Case, accessed on July
24, 2025,
h�ps://[Link]/document/235682525/Online-Shopping-Uml-Examples
33. UML Component Diagram Template | Miro, accessed on July 24, 2025,
h�ps://[Link]/templates/uml-component-diagram/
34. UML component diagram example for online shopping - search ..., accessed on
July 24, 2025,
h�ps://[Link]/examples/online-shopping-uml-component-diagr
[Link]
35. Deployment Diagram in Uni�ed Modeling Language(UML ..., accessed on July 24,
2025,
h�ps://[Link]/system-design/deployment-diagram-uni�ed-mo
deling-languageuml/
36. Deployment Diagram Tutorial | Lucidchart, accessed on July 24, 2025,
h�ps://[Link]/pages/uml-deployment-diagram
37. UML Diagram Online Shopping UML Use Case | PDF - Scribd, accessed on July 24,
2025,
 h�ps://[Link]/document/514500906/UML-Diagram-Online-Shopping-
UML-Use-Case
38. A UML Use-Case Analysis of an Online Shopping System: Actors ..., accessed on
July 24, 2025,
h�ps://[Link]/post/a-uml-use-case-analysis-of-an-online-shop
ping-system-actors-use-cases-and-relationships
39. UML activity diagram examples - online shopping, process order ..., accessed on
July 24, 2025, h�ps://[Link]/[Link]
40. Activity Diagram Example: Order Processing - Visual Paradigm Online, accessed
on July 24, 2025,
h�ps://[Link]/diagrams/templates/activity-diagram/activity-
diagram-example-order-processing/
41. Online shopping - State diagram example | Gleek, accessed on July 24, 2025,
h�ps://[Link]/templates/online-shopping-state
42. UML Sequence Diagram | Components, Examples & How to Create ..., accessed
on July 24, 2025, h�ps://[Link]/template/uml-sequence-diagram/
43. User login – UML sequence diagram example | Gleek, accessed on July 24, 2025,
h�ps://[Link]/templates/sequence-user-login
44. sequence diagram for ecommerce - Creately, accessed on July 24, 2025,
h�ps://[Link]/diagram/example/hbscitcx3/sequence-diagram-for-ecomme
rce
45. Online Shopping Cart UML Class Diagram Template: E-commerce Design -
[Link], accessed on July 24, 2025,
h�ps://[Link]/template/online-shopping-cart-uml-class-diagram
46. UML communication diagram example for online shopping - web ..., accessed on
July 24, 2025,
h�ps://[Link]/examples/online-shopping-uml-communication-di
[Link]
47. How to Build an E-commerce Website Using Python? - LogicRays, accessed on
July 24, 2025,
h�ps://[Link]/how-to-build-an-e-commerce-website-using-python
/
48. Django Login, Logout, Signup, Password Change, and Password Reset |
[Link], accessed on July 24, 2025,
h�ps://[Link]/tutorials/django-login-and-logout-tutorial
49. User Registration & Sign Up - Django Tutorial - Tech with Tim, accessed on July
24, 2025, h�ps://[Link]/tutorials/django/user-registration
50. E-commerce Product Catalog using Django - GeeksforGeeks, accessed on July
24, 2025,
h�ps://[Link]/python/e-commerce-product-catalog-using-dja
ngo/
51. Python in E-commerce: Building Dynamic Online Stores - Search My Expert,
accessed on July 24, 2025,
h�ps://[Link]/resources/python-development/python-web-
ecommerce
52. 5. Data Structures — Python 3.13.5 documentation, accessed on July 24, 2025,
h�ps://[Link]/3/tutorial/[Link]
53. Print lists in Python - GeeksforGeeks, accessed on July 24, 2025,
h�ps://[Link]/python/print-lists-in-python-4-di�erent-ways/
54. How to Print a List in Python: 5 Di�erent Ways (with code) - FavTutor, accessed on
July 24, 2025, h�ps://[Link]/blogs/print-list-python
55. How to create list of dictionary in Python - GeeksforGeeks, accessed on July 24,
2025,
h�ps://[Link]/python/how-to-create-list-of-dictionary-in-pyth
on/
56. How to extract values from a list of dictionaries in Python - LabEx, accessed on
July 24, 2025,
h�ps://[Link]/tutorials/python-how-to-extract-values-from-a-list-of-dictionarie
s-in-python-397992
57. How to print out dict. values from a list? - Codecademy, accessed on July 24,
2025,
h�ps://[Link]/forum_questions/506de056fe9cc6000200aa�
58. Python - Dictionary Key's Product in list - GeeksforGeeks, accessed on July 24,
2025,
h�ps://[Link]/python/python-dictionary-keys-product-in-list/
59. Shopping cart program - Python Forum, accessed on July 24, 2025,
h�ps://[Link]/[Link]
60. Shopping-Cart-using-Python/[Link] at master - GitHub, accessed on
July 24, 2025,
h�ps://[Link]/mdlkumaran/Shopping-Cart-using-Python/blob/master/Shopp
[Link]
61. Customer Order Models - Django Wednesdays ECommerce 31 - YouTube,
accessed on July 24, 2025, h�ps://[Link]/watch?v=D6wCDunDa74
62. Python Shop Management System Project with Source Code, accessed on July
24, 2025, h�ps://[Link]/python-shop-management-system/
63. How to Create an E-Commerce website with Python Django - Project Gurukul,
accessed on July 24, 2025,
h�ps://[Link]/e-commerce-website-python-django/
64. Simple python order book - GitHub Gist, accessed on July 24, 2025,
h�ps://[Link]/HandsomeManKris/3fe89b0f5f74d2a6fc565725e7fa2a52
65. Chapter 2.1. Simple Calculations - Programming Basics with Python - So�Uni
Global, accessed on July 24, 2025,
h�ps://[Link]�[Link]/[Link]
66. Product Process Order - python - Stack Over�ow, accessed on July 24, 2025,
h�ps://stackover�[Link]/questions/52694063/product-process-order
67. How to Use sorted() and .sort() in Python - Real Python, accessed on July 24,
2025, h�ps://[Link]/python-sort/