WEEK-1

Software Requirement Specification (SRS) Format as the name suggests, is a

complete specification and description of requirements of the software that need
to be fulfilled for the successful development of the software system. These
requirements can be functional as well as non-functional depending upon the
type of requirement. The interaction between different customers and
contractors is done because it is necessary to fully understand the needs of
customers.

Software Requirements Specification (SRS) Document for Online shopping

System

1. Introduction
1.1 Purpose
The purpose of this document is to define the requirements for the Online
Shopping System. It will detail system functionality, user interactions, and
performance criteria. The system will allow users to browse products, add them
to a cart, place orders, track deliveries, and make secure payments.
1.2 Scope
The Online Shopping System provides a platform where users can view
products, check availability, add to cart, place orders, and complete payments.
The system enables vendors/admins to manage product catalogs, inventory,
pricing, and customer information.
1.3 Definitions, Acronyms, and Abbreviations

 User: Customer purchasing products online.

 Admin: Manages product catalog, users, and orders.

  Cart: Virtual basket where users keep selected products.

 Order: A confirmed purchase by a user.

 Payment Gateway: Service that processes payments securely.

 Delivery Partner: External entity responsible for shipping products.

1.4 Overview
This SRS contains overall description, functional requirements, non-functional
requirements, and use case scenarios for the Online Shopping System.

2 Overall Description
2.1 Product Perspective
The Online Shopping System will be a web & mobile application integrated
with product databases, inventory management, and secure payment systems.
2.2 Product Functions
The system will provide the following functions:
 User registration/login
 Browse/search products
 View product details
 Add/remove items from cart
 Place orders
 Secure payment processing
 Track orders and delivery
 Manage user accounts
 Admin: manage products, users, and transactions

.
2.3 User Characteristics

 End Users: Customers buying products

 Admin Users: Store managers handling products/orders

 System Administrator: Responsible for platform maintenance

.
 2.4Constraints

 Available 24/7

 Secure handling of payment & personal data

 Must support multiple product categories

 Compliance with payment standards (PCI DSS)

2.5Assumptions and Dependencies

 Stable internet connection assumed

 Uses outside payment services and delivery partners.

3 Functional Requirements

1. User Authentication

 Users should be able to create an account, log in, and reset

passwords.
 This ensures only authorized users can place orders and view
their account details.

2. Product Browsing

 Users can search and filter products by name, price,

category, or brand.
 They should be able to view product details, images, price,
and availability.

3. Cart Management

 Users can add items to the cart, remove them, or change

quantity.
 The cart should display the total price before checkout.

4. Order Placement

 Users can proceed from the cart to order confirmation.

  They must provide delivery details and confirm the
purchase.

5. Payment Processing

 The system integrates with a secure payment gateway.

 Users can pay via credit/debit card, UPI, or net
banking.

6. Order Tracking

 After ordering, users should be able to track the status

(processing, shipped, delivered).
 Delivery updates should be shown in the user account.

7. Notifications

 The system should send email or SMS alerts for order

confirmation, shipping, and delivery.
 Users should also get alerts if an order is delayed or canceled.

8. Admin Features

 Admin can add, edit, or delete products in the catalog.

 Admin can also manage users, view all orders, and
update stock availability.

4 Non-Functional Requirements

1. Performance

 The website should load pages quickly (within 3 seconds).

 It should support multiple users browsing and shopping at
the same time.

2. Security

 All sensitive data like passwords and payments must be

encrypted.
 The system must use HTTPS and follow payment security
standards.
 3. Usability

 The system should be easy to navigate for all users.

 It should work on computers, tablets, and mobile devices with
a simple interface.

4. Availability

 The system should be available 24/7 for shopping.

 Downtime should only occur during planned maintenance.

5. Scalability

 The system should be able to handle growth in products, users,

and orders.
 As business expands, it should support new features without
slowing down

WEEK-2
Unified Modelling Language (UML) is a general-purpose modeling language.
The main aim of UML is to define a standard way to visualize the way a system
has been designed. It is quite similar to blueprints used in other fields of
engineering. UML is not a programming language , it is rather a visual
language.
Different Types of UML Diagrams
UML is linked with object-oriented design and analysis. UML makes use of
elements and forms associations between them to form diagrams. Diagrams in
UML can be broadly classified as:

• We use UML diagrams to portray the behavior and structure of a

system.
• UML helps software engineers, businessmen, and system architects with
modeling, design, and analysis.
• The Object Management Group (OMG) adopted Unified Modelling
Language as a standard in 1997. It’s been managed by OMG ever since.
• The International Organization for Standardization (ISO) published UML
as an approved standard in 2005. UML has been revised over the years
and is reviewed periodically.

Use Case Diagrams

A Use Case Diagram is a vital tool in system design, it provides a visual
representation of how users interact with a system. It serves as a blueprint for
understanding the functional requirements of a system from a user’s
perspective, aiding in the communication between stakeholders and guiding the
development process.

Use Case Diagram Notations

UML notations provide a visual language that enables software developers,
designers, and other stakeholders to communicate and document system
designs, architectures, and behaviors in a consistent and understandable manner.
Actors
Actors are external entities that interact with the system. These can include
users, other systems, or hardware devices. In the context of a Use Case
Diagram, actors initiate use cases and receive the outcomes.
Use Cases
Use cases are like scenes in the play. They represent specific things your system
can do. In the online shopping system, examples of use cases could be “Place
Order,” “Track Delivery,” or “Update Product Information”. Use cases are
represented by ovals.
System Boundary
The system boundary is a visual representation of the scope or limits of the
system you are modeling. It defines what is inside the system and what is
outside. The boundary helps to establish a clear distinction between the
USECASE DIAGRAM FOR ONLINE SHOPPING SYSTEM
Actors:

 User – browses products, manages cart, places orders, makes payment,

tracks delivery
  Admin – manages products, users, orders

 Payment Gateway – processes payments

 Delivery Partner – manages shipment & delivery

Use Cases:
Diagram Description:
 Register/Login – Users can create an account or log in to access
the system.
 Browse Products – Users can view and search products by
category or filters.
 View Product Details – Users can see product information like
price, description, and stock.
 Add to Cart – Users can add selected products to their shopping
cart.
 Place Order – Users can confirm their cart items and provide
delivery details.
 Make Payment – Users can pay securely through the payment
gateway.
 Track Delivery – Users can check the status of their order until
it is delivered.
 Receive Notifications – Users get alerts for order confirmation,
shipping, and delivery.
 Manage Products (Admin) – Admin can add, edit, or remove
products in the catalog.
 View Orders (Admin) – Admin can see all orders placed by
users.
 Manage Users (Admin) – Admin can manage customer
accounts and resolve issues.

In the diagram:
• The User actor interacts with all use cases related to flight booking,
managing reservations, and payments.
• The Admin actor interacts with use cases for managing flights, bookings,
and users.
• The Payment Gateway actor is involved only in the payment processing
use case.
 WEEK-3

Activity Diagrams are used to illustrate the flow of control in a system and refer
to the steps involved in the execution of a use case. We can depict both
sequential processing and concurrent processing of activities using an activity
diagram ie an activity diagram focuses on the condition of flow and the
sequence in which it happens.
Activity Diagram Notations

In activity diagrams, the notations are like visual symbols that help represent
different elements and actions in a simple way.
• We describe what causes a particular event using an activity diagram.
• An activity diagram portrays the control flow from a start point to a finish
point showing the various decision paths that exist while the activity is
being executed.
• They are used in business and process modeling where their primary use
is to depict the dynamic aspects of a system.

ACTIVITY DIAGRAM FOR ONLINE SHOPPING SYSTEM

Key Activities:
  User Login/Registration – The user registers for a new account
or logs in with existing credentials.
 Browse/Search Products – The user searches or browses the
product catalog by category, filters, or keywords.
 Add Items to Cart – The user selects products and adds them to
the shopping cart.
 View Cart & Update Quantity – The user reviews the cart,
updates item quantities, or removes items.
 Place Order – The user confirms the order by providing
shipping details and proceeding to checkout.
 Make Payment (via Payment Gateway) – The user chooses a
payment method and makes a secure payment.
 Receive Order Confirmation – Once payment is successful, the
system confirms the order and generates an invoice.
 Track Delivery – The user can track the order status from
processing to shipping and final delivery.

Flow:
The process begins when the user logs in or registers on the system.
After logging in, the user browses or searches for products from the
catalog.
The user then adds selected items to the cart for purchase.
The cart is reviewed and the user can update item quantities or remove
unwanted items.
The user then proceeds to place the order by providing delivery address and
confirming details.
Next, the user completes the purchase by making a secure payment
through the payment gateway.
If payment is successful, the system confirms the order and sends a
notification via email or SMS.
Finally, the user can track the order delivery until the product reaches their
address.
 Sequence Diagrams
Introduction
A Sequence Diagram is a type of interaction diagram that shows how processes
or objects interact with each other, and in what order. It emphasizes the time
sequence of messages passed between objects.
 It is used to model the flow of logic within a system.
 It shows the sequence of messages exchanged between system
components.
 It is mainly used in scenarios like use case realization.
Features / Terminology
 Actors: Represent external entities (like User, Admin, Payment Gateway,
Database).
 Objects/Lifelines: Shown as vertical dotted lines that represent system
components over time.
 Messages: Horizontal arrows showing communication (synchronous,
asynchronous, or returns).
 Activation Bars: Narrow rectangles that represent the time an object is
active.
 Conditions/Alternatives: Used to represent decision-making paths (alt,
opt, loop).
Sequence Diagram for Online Shopping System
The sequence diagram describes the interactions between User, System,
Database, Payment Gateway, and Admin. The process is:
1. Login / Registration
o User opens application → System shows login page → User enters
credentials → System validates with database → Success or error
returned.
2. Browsing Products
o User requests product list → System fetches from Database →
Products displayed.
3. Cart Operations
 o User adds items to cart → System updates cart data.
4. Placing Order
o User confirms order → System saves order → Order confirmed.
5. Checkout & Payment
o User proceeds to checkout → Payment request sent to Gateway →
Gateway validates → System updates order based on
success/failure.
6. Admin & Support Interaction
o System notifies Admin of new order → Admin approves → User
can request help → System routes support request to Admin →
Response provided.
 WEEK-4
Class diagrams are a type of UML (Unified Modeling Language) diagram used
in software engineering to visually represent the structure and relationships of
classes within a system i.e. used to construct and visualize object-oriented
systems.

UML Class Notation

class notation is a graphical representation used to depict classes and their
relationships in object-oriented modeling.

1. Class Name:
• The name of the class is typically written in the top compartment
of the class box and is centered and bold.
2. Attributes:
• Attributes, also known as properties or fields, represent the data
members of the class. They are listed in the second compartment of
the class box and often include the visibility (e.g., public, private)
and the data type of each attribute.
3. Methods:
• Methods, also known as functions or operations, represent the
behavior or functionality of the class. They are listed in the third
compartment of the class box and include the visibility (e.g.,
public, private), return type, and parameters of each method.
 4. Visibility Notation:
• Visibility notations indicate the access level of attributes and
methods. Common visibility notations include: o + for public
(visible to all classes) o - for private (visible only within the class)
o # for protected (visible to subclasses)

o ~ for package or default visibility (visible to classes in the

same package)
CLASS DIAGRAM FOR ONLINE SHOPPING SYSTEM
Key Classes:
1. User Class
 Attributes: userID, name, email, password, phone, address
 Methods:
o register() → allows new users to sign up
o login() → authenticates existing users
o viewOrders() → shows past and current orders
o updateProfile() → lets users change their details

2. Product Class
 Attributes: productID, productName, category, description, price,
stockQuantity
 Methods:
o viewDetails() → displays full product information
o updateStock() → updates available quantity after purchase
o checkAvailability() → verifies if the product is in stock

3. Cart Class
  Attributes: cartID, userID, productList, totalAmount
 Methods:
o addItem() → adds a product to the cart
o removeItem() → removes a product from the cart
o updateQuantity() → changes product quantity in the cart
o calculateTotal() → calculates the total cost of items

4. Order Class
 Attributes: orderID, userID, productList, orderDate, deliveryAddress,
status
 Methods:
o placeOrder() → confirms purchase of items in the cart
o cancelOrder() → cancels an existing order (if allowed)
o trackOrder() → checks the delivery status
o viewOrderDetails() → shows full order summary

5. Payment Class
 Attributes: paymentID, orderID, amount, paymentMethod,
paymentStatus
 Methods:
o processPayment() → executes the transaction
o verifyPayment() → checks if payment was successful
o refundPayment() → initiates refund if order is canceled

6. Admin Class
 Attributes: adminID, name, email, role
 Methods:
o manageProducts() → add, update, or remove products
o manageUsers() → manage customer accounts and handle issues
o viewAllOrders() → view and track all orders in the system
o generateReports() → create sales or stock reports