Software Requirements

Specification
for

<Computer Store Managemnt

Aepp>
Version 1.0 approved

Prepared by <Group 6>

<10/20/2024>
1. Introduction​ 6
1.1 Purpose​ 6
1.2 Document Conventions​ 7
1.3 Product vision​ 8
1.4 Project Scope​ 9
I. In-Scope Features​ 9
II. Out of Scope​ 9
III. Scope Management​ 9
1.5 References​ 10
2. Overall Description​ 11
2.1 Product Perspective​ 11
a.Context and Origin​ 11
System Context and Major Interfaces​ 11
i. Key Interfaces​ 11
Product Functions​ 12
User Characteristics​ 12
Constraints​ 12
Assumptions and Dependencies​ 12
System Context diagram​ 13
2.2 User Classes and Characteristics​ 13
Primary User Classes​ 13
Favored User Class​ 14
2.3 Operating Environment​ 15
A. Hardware Platform​ 15
b. Operating System and Software​ 15
Database and Storage​ 15
Geographical Locations​ 16
Integration and Compatibility​ 16
Network Requirements​ 16
2.4 Design and Implementation Constraints​ 16
2.4.1 Corporate and Regulatory Policies​ 16
2.4.2 Hardware Limitations​ 16
2.4.3 Technology and Tool Requirements​ 17
2.4.4 Interface and Integration Constraints​ 17
 2.4.5 Network and Security Constraints​ 17
2.5 Assumptions and Dependencies​ 17
2.5.1 Assumptions​ 18
2.5.2 Dependencies​ 18
3. System Features​ 19
3.1 Use Case Diagram​ 19
3.2 Use Case List Description​ 19
System Feature Description​ 23
3.2.1 Usecase 1: Login​ 23
3.2.2 Usercase: Register​ 25
3.2.3 Usercase: Logout​ 29
3.2.4 Usercase: Search​ 31
UC ID and Name:​ 31
3.2.5 Usercase: View Product detail​ 33
Postconditions:​ 34
3.2.6 Usercase: Make Order​ 35
3.2.7 Add to cart​ 39
3.2.8 View cart​ 42
3.2.9 View purchase history​ 45
3.2.10 Manage Product​ 47
3.2.11 Manage Orders​ 50
3.2.12 Update Product​ 53
3.2.13 Process Orders​ 57
3.2.14 Process Returns and Exchanges​ 62
3.2.15 Refund Payment​ 65
3.5.16 Manage Inventory​ 68
3.2.17 View Sales Reports​ 70
3.2.18 Manage Employees​ 72
3.2.19 Handle Customer Inquiries​ 74
4. Data Requirements​ 77
4.1 Logical Data Model​ 77
1. 1. Entities and Attributes​ 77
2. 2. Relationships​ 78
4.2 Data Dictionary​ 78
4.3 Reports​ 86
ii. 4.3.1 Inventory Report​ 86
iii. 4.3.2 Sales Report​ 86
iv. 4.3.3 Customer Order History Report​ 87
v. 4.3.4 Promotions Effectiveness Report​ 87
 vi. 4.3.5 Returns and Refunds Report​ 87
4.4 Data Acquisition, Integrity, Retention, and Disposal​ 88
vii. 4.4.1 Data Acquisition​ 88
viii. 4.4.2 Data Integrity Protection​ 88
ix. 4.4.3 Data Retention Policies​ 88
x. 4.4.4 Data Disposal​ 89
5. External Interface Requirements​ 89
5.1 User Interfaces​ 89
xi. 5.1.1 General Layout and Navigation​ 89
xii. 5.1.2 Module-Specific Interfaces​ 90
1. Inventory Management Interface​ 90
2. Order Processing Interface​ 90
3. Customer Management Interface​ 90
4. Promotions Management Interface​ 91
5. Returns and Refunds Interface​ 91
xiii. 5.1.3 Standard Functions and Messages​ 91
5.2 Software Interfaces​ 91
xiv. 5.2.1 Database Management System (DBMS)​ 91
xv. 5.2.2 Point of Sale (POS) System Integration​ 92
xvi. 5.2.3 Operating System​ 92
xvii. 5.2.4 Java Runtime Environment (JRE)​ 93
xviii. 5.2.5 External Backup Solution (Cloud or Local Backup Service)​ 93
xix. 5.2.6 Reporting and Analytics Tool (Optional Future Integration)​ 93
xx. 5.2.7 Network Protocols and Security​ 94
5.3 Hardware Interfaces​ 94
xxi. 5.3.1 Barcode Scanner​ 94
xxii. 5.3.2 Receipt Printer​ 95
xxiii. 5.3.3 POS Terminal (Optional Integration)​ 95
xxiv. 5.3.4 Customer Display Screen (Optional)​ 95
xxv. 5.3.5 Cash Drawer (Optional)​ 96
5.4 Communications Interfaces​ 96
xxvi. 5.4.1 Internal Network Communication​ 96
xxvii. 5.4.2 Cloud-Based Backup Communication (Optional)​ 97
xxviii. 5.4.3 Email Notification (Optional Future Feature)​ 97
xxix. 5.4.4 POS System Communication (Optional)​ 97
xxx. 5.4.5 Reporting System Integration (Optional Future Feature)​ 98
6. Quality Attributes​ 98
6.1 Usability​ 98
xxxi. 6.1.1 Ease of Use​ 98
 xxxii. 6.1.2 Ease of Learning​ 99
xxxiii. 6.1.3 Memorability​ 99
xxxiv. 6.1.4 Error Avoidance, Handling, and Recovery​ 99
xxxv. 6.1.5 Efficiency of Interactions​ 99
xxxvi. 6.1.6 Accessibility​ 100
xxxvii. 6.1.7 Ergonomics​ 100
xxxviii. 6.1.8 Conformance to Standards​ 100
6.2 Performance​ 100
xxxix. 6.2.1 System Startup and Login​ 100
xl. 6.2.2 Data Retrieval and Display​ 101
xli. 6.2.3 Order Processing and Checkout​ 101
xlii. 6.2.4 Inventory Management Operations​ 101
xliii. 6.2.5 Promotion Application​ 101
xliv. 6.2.6 Return and Refund Processing​ 102
xlv. 6.2.7 Reporting​ 102
xlvi. 6.2.8 Backup and Recovery​ 102
xlvii. 6.2.9 Network Communication​ 102
6.3 Security​ 103
xlviii. 6.3.1 Access Control​ 103
xlix. 6.3.2 Data Security​ 103
l. 6.3.3 Privacy Compliance​ 103
li. 6.3.4 Physical Security​ 104
lii. 6.3.5 Data Backup and Recovery Security​ 104
liii. 6.3.6 Network Security​ 104
liv. 6.3.7 Security Testing and Monitoring​ 104
lv. 6.3.8 User Education and Training​ 104
6.4 Safety​ 105
lvi. 6.4.1 Data Loss Prevention​ 105
lvii. 6.4.2 Financial Data Integrity​ 105
lviii. 6.4.3 System Stability and Operational Continuity​ 105
lix. 6.4.4 Prevention of Unauthorized Actions​ 106
lx. 6.4.5 Compliance with Safety Policies and Certifications​ 106
lxi. 6.4.6 User Safety Education​ 106
lxii. 6.4.7 Safety Precautions for Network and Power Failures​ 106
6.5 Additional product quality​ 106
lxiii. 6.5.1 Availability​ 107
lxiv. 6.5.2 Reliability​ 107
lxv. 6.5.3 Scalability​ 107
lxvi. 6.5.4 Modifiability​ 107
 lxvii. 6.5.5 Interoperability​ 107
lxviii. 6.5.6 Robustness​ 108
lxix. 6.5.7 Portability​ 108
lxx. 6.5.8 Verifiability​ 108
lxxi. Prioritization of Attributes​ 108
7. Internationalization and Localization Requirements​ 109
lxxii. 7.1 Language and Character Set​ 109
lxxiii. 7.2 Currency and Financial Data​ 109
lxxiv. 7.3 Date, Time, and Number Formatting​ 109
lxxv. 7.4 Address and Phone Number Formatting​ 109
lxxvi. 7.5 Time Zone and Regional Settings​ 109
lxxvii. 7.6 Units of Measurement​ 109
lxxviii. 7.7 Legal and Compliance Requirements​ 110
lxxix. 7.8 Other Localization Requirements​ 110

1.​ Introduction
This Software Requirements Specification (SRS) document provides a comprehensive overview of the
Computer Store Management System. The purpose of this document is to outline the functionality,
features, and structure of the system, which is designed to facilitate efficient management of inventory,
customer orders, and sales processes within a computer retail environment. The SRS is organized to
guide stakeholders through understanding the requirements and specifications of the system, covering
essential sections such as system functionality, user roles, data management, and performance
requirements. This document serves as a reference for developers, project managers, and users to
ensure that all parties have a clear understanding of the project's objectives and expectations.

1.1​ Purpose

This document specifies the software requirements for the Computer Store Management
System (Version 1.0). This system is intended to streamline the management processes within a
computer retail store, including inventory tracking, customer orders, sales processing, and
reporting capabilities. The system is designed to improve operational efficiency, enhance
customer service, and support strategic decision-making for store management.

This document is intended for the following readers:

 ●​ Developers: To understand the functional and non-functional requirements needed to
design and implement the system.
●​ Project Managers: To monitor project scope, objectives, and timelines based on system
requirements.
●​ Marketing Staff: To gain insight into the product's functionalities, allowing them to
develop strategies for customer engagement and outreach.
●​ End Users: To understand the system's capabilities and limitations from a user
perspective.
●​ Testers: To define test cases based on specified requirements and validate system
functionality.
●​ Documentation Writers: To create accurate user manuals, guides, and support
documents for the end-users of the system.

Each section of this document is crafted to provide these stakeholders with a clear understanding
of the system's intended features, design scope, and operational expectations.

1.2​ Document Conventions

This document follows specific conventions to ensure consistency, clarity, and easy navigation:

●​ Text Styles:
o​ Bold Text: Used to emphasize key terms, sections, or system components.
o​ Italicized Text: Used for examples, notes, or additional clarifications.
o​ Code-style Text: Used for system commands or inline code references.
●​ Requirement Identifiers:
o​ Each requirement is labeled with a unique identifier following a structured format
to specify the type and sequence. For example:
▪​ FR-1.1: Functional Requirement, Section 1, Requirement 1.
▪​ NFR-2.1: Non-functional Requirement, Section 2, Requirement 1.
o​ Requirement prefixes:
▪​ FR – Functional Requirement
▪​ NFR – Non-functional Requirement
▪​ UIR – User Interface Requirement
▪​ BR – Business Rule (referenced directly in relevant use cases for easy
cross-referencing)
●​ Notations:
o​ [Note]: Indicates additional context or optional information.
o​ [Optional]: Marks non-essential elements that could enhance functionality but are
not required for core operations.

These conventions ensure a standardized format, making it easy for all

stakeholders—developers, project managers, and testers—to understand and reference
requirements accurately.
1.3​ Product vision

The Computer Store Management System is designed to revolutionize how computer

retail stores manage inventory, process orders, and deliver exceptional customer experiences.
This system will streamline daily operations, from inventory management to customer service,
creating a seamless, efficient workflow that minimizes human error and maximizes productivity.
With this product in place, computer stores will experience faster order processing,
accurate stock management, and simplified promotion and customer relationship handling, all
accessible within a single, integrated platform. For customers, this means consistent availability
of products, timely service, and personalized offers, leading to higher satisfaction and loyalty.
Our vision is to empower computer retail businesses to operate with greater agility and
precision, reducing overhead and aligning with modern digital retail demands. This product will
support store growth, data-driven decision-making, and a future-ready infrastructure, catering to
both current and evolving customer needs while aligning with the organization’s strategic goals
of operational efficiency and scalable expansion.
1.4​ Project Scope

The Computer Store Management System aims to streamline and optimize core operations for
computer retail stores. This project will provide functionalities to efficiently manage inventory,
process customer orders, handle returns and exchanges, manage customer information, and
create and update promotions. By implementing an integrated platform, the system will reduce
manual tasks, improve data accuracy, and enable real-time access to inventory and customer
data, ultimately enhancing the customer experience and operational efficiency.

I.​ In-Scope Features

The solution will include the following key capabilities:

●​ Inventory Management: Tracking product quantities, updating product details, managing stock
levels, and ensuring accuracy in real-time to support sales and avoid stockouts.
●​ Order Processing: Handling customer orders from placement to fulfillment, including status
updates, shipping, and delivery management.
●​ Returns and Exchanges: Processing customer returns and exchanges, updating stock and
financial records, and managing eligibility according to policy.
●​ Customer Management: Storing and updating customer information, tracking order history, and
validating customer data for improved service.
●​ Promotions Management: Creating, updating, and applying promotions to products or
categories, including discounts, special offers, and bundles.
●​ Payment Refund Processing: Handling refunds to original payment methods or store credit
based on customer returns or cancellations.

II.​ Out of Scope

The following areas will not be included in this project’s initial scope: (Release)

●​ Advanced Analytics and Reporting: While basic reports may be available, complex analytics or
predictive sales forecasting are outside this scope.
●​ Integration with External E-commerce Platforms: This system will not integrate directly with
external e-commerce or third-party marketplace platforms.
●​ Customer Support Chat or AI-Driven Assistance: No in-built customer support or automated
assistance features are included in the scope.
●​ Detailed Financial Accounting: Comprehensive financial or accounting functions beyond basic
sales and refunds processing are excluded.

III.​ Scope Management

This scope is defined to provide a focused, efficient solution that meets the primary operational
needs of computer retail stores. Any proposed requirements or features outside this scope will be
assessed for alignment with the product vision and prioritized based on their potential value.
Adjustments to scope will only be considered if they support significant improvements in the
system's effectiveness and fit within resource, budget, and timeline constraints. ( define rieng)
1.5​ References ( dua vao constraint)

This section lists resources relevant to the development of the Computer Store Management
System, emphasizing standards, guidelines, and documentation that support requirements
specification, modeling, and Java implementation.

1.​ Visual Paradigm User Guide

o​ Title: Visual Paradigm Online Documentation
o​ Author: Visual Paradigm Team
o​ Version: Latest
o​ Source: Visual Paradigm
o​ URL: Visual Paradigm Documentation
o​ Description: Comprehensive guide covering Visual Paradigm’s features,
including UML modeling, requirements capturing, and use case diagrams, aiding
in effective design documentation.
2.​ Java SE Development Kit (JDK) Documentation
o​ Title: Java SE 17 Documentation
o​ Author: Oracle Corporation
o​ Version: Java SE 17 (or latest version in use)
o​ Source: Oracle
o​ URL: Java SE Documentation
o​ Description: Official Java SE documentation providing essential references for
classes, methods, and language constructs used within the system’s
implementation.
3.​ Software Requirements Specification (SRS) Template
o​ Title: SRS Template and Guidelines
o​ Author: Internal Team
o​ Version: 1.0
o​ Date: October 15, 2024
o​ Source: Internal Repository
o​ Location: Company Document Library /Templates/SRS_Template.docx
o​ Description: Standard SRS template providing a consistent structure and format
for documenting requirements.
4.​ UML and Modeling Standards
o​ Title: Unified Modeling Language (UML) Specification, Version 2.5.1
o​ Author: Object Management Group (OMG)
o​ Version: 2.5.1
o​ Date: December 2017
o​ Source: OMG
o​ URL: UML 2.5.1 Specification
o​ Description: Defines the standards for UML diagrams used in Visual Paradigm,
including class diagrams, use case diagrams, and activity diagrams for clear and
structured requirements and system modeling.
Each reference provides essential guidance and tools for requirements modeling, documentation,
and Java development, supporting consistent and efficient development practices in line with
project objectives.

2.​ Overall Description

The Computer Store Management System is designed to enhance the efficiency and accuracy
of operations within a computer retail store environment. The system enables streamlined
management of inventory, customer orders, returns, promotions, and customer information. Built
using Java and modeled in Visual Paradigm, it provides an integrated approach to managing
store functions, improving both employee productivity and customer satisfaction.

2.1 Product Perspective

The Computer Store Management System is an entirely new product, designed to replace
manual processes and legacy systems used in computer retail stores. Its purpose is to provide a
comprehensive, centralized solution for managing inventory, processing customer orders,
handling returns, updating promotions, and managing customer information. By consolidating
these functions, the system aims to enhance operational efficiency, data accuracy, and customer
satisfaction in a retail environment.

a.Context and Origin

This system is being developed to address common pain points in computer retail operations,
including:

●​ Time-intensive manual inventory updates.

●​ Limited tracking of customer orders, returns, and exchanges.
●​ Lack of integration between promotional activities and product inventory.
●​ Inefficiencies in customer record management and order processing.

The system is built as a standalone, in-store application tailored specifically to the needs of
physical computer retail locations and does not interface with online e-commerce platforms.

System Context and Major Interfaces

The system operates in a self-contained environment, with data inputs coming directly from
in-store activities such as sales, customer interactions, inventory updates, and promotional
setups. There are no external data sources or systems connected to this version; all functions
occur within the local store infrastructure.

i.​ Key Interfaces

●​ User Interface (UI): Provides user-friendly access for store staff, with role-based controls
ensuring that users have appropriate access to functions (e.g., inventory management, order
processing, customer management).
 ●​ Database Interface: Centralized storage where data on products, customers, orders, and
promotions is stored and managed. This database ensures real-time access and updates to
maintain accurate records across all functions.
●​ Reporting and Analytics Interface (Future Expansion): While this version includes basic
reporting, future versions may introduce more complex analytics accessible through a dedicated
reporting module, enhancing data-driven decision-making.

Product Functions

Key functions of the system include:

●​ Inventory Management: Track, update, and display stock quantities, product details, and
categories.
●​ Order Processing: Create, update, and complete customer orders while adjusting inventory as
necessary.
●​ Returns and Exchanges: Process and validate customer returns or exchanges in accordance with
store policy.
●​ Customer Management: Store and manage customer details, history, and account statuses.
●​ Promotion Management: Add, update, or remove promotional offers, with specified products or
categories.
●​ Payment Refund Processing: Handle payment refunds due to returns or cancellations.

User Characteristics

The primary users of this system will include:

●​ Customer Support Staff: Responsible for handling returns, exchanges, and customer account
management.
●​ Inventory Staff: Manages stock levels, product information, and supplier restocking.
●​ Sales and Order Staff: Processes customer orders, updates order statuses, and ensures timely
fulfillment.
●​ Marketing Staff: Manages promotions, discounts, and other customer-facing marketing efforts.

Each user group will require appropriate training to operate the system efficiently.

Constraints

●​ System Access: Limited to in-store use on designated systems, with role-based access controls.
●​ Data Privacy Compliance: Adheres to relevant data protection policies, ensuring secure handling
of customer data.
●​ Resource Constraints: The system operates within a limited infrastructure, including database
and processing capacities specific to in-store hardware.

Assumptions and Dependencies

●​ Stable In-store Network: Assumes a reliable network within the store for seamless data access
and updates.
 ●​ Java Runtime Environment: Assumes availability of the appropriate Java runtime on all machines
where the system will be deployed.
●​ Regular Inventory Updates: Assumes that inventory data is regularly synchronized to reflect
actual stock levels.

This system is developed with the primary objective of supporting core retail functions and
meeting the operational demands of a computer store. Future expansions may consider
integrating analytics or additional reporting features, provided resource constraints are addressed.

System Context diagram

2.2​ User Classes and Characteristics

The Computer Store Management System is designed to be used by both store staff and
stakeholders, each with specific roles and access needs to support efficient operations.

Primary User Classes

1.​ Staff
 o​ Description: Store employees responsible for managing various operational tasks,
including inventory management, order processing, customer support, and promotions.
o​ Responsibilities: Adding and updating products, processing orders, handling customer
requests (returns, exchanges, refunds), managing promotions, and maintaining customer
records.
o​ Skills and Needs: Basic computer skills, familiarity with store processes, and ability to
navigate the system efficiently. Staff require intuitive access to all key functions to
support daily operations, ensuring a seamless experience for both employees and
customers.( khong can thiet)
2.​ Owner
o​ Description: The business owner who oversees store operations, monitors performance,
and makes strategic decisions based on system reports.
o​ Responsibilities: Accessing high-level reports on sales, inventory, and promotions,
overseeing store operations, and configuring system settings as needed.
o​ Skills and Needs: Requires high-level access for oversight and decision-making. The
system should provide the owner with dashboards, reports, and analytics for business
insights without requiring detailed operational interactions.
3.​ Customer
o​ Description: The end-user who interacts with the store’s offerings, makes purchases, and
occasionally requests returns, exchanges, or other services.
o​ Responsibilities: Browsing products, making purchases, requesting returns or exchanges,
and interacting with promotional offers.
o​ Skills and Needs: Customers do not directly interact with the system interface but rely
on Staff for order information, product availability, and promotional details.

Favored User Class

The Staff class is the primary user group, as they handle core operations that ensure efficient
daily functionality. The system prioritizes streamlined access for staff, allowing quick processing
of inventory, orders, and customer services to maintain customer satisfaction.
Each user class has tailored access to necessary functions, with intuitive interfaces to enhance
productivity and support operational workflows.

User Description
1 Customer The end-user who engages
with the store’s offerings,
makes purchases, and
occasionally requests returns,
exchanges, or other customer
services.
2 Owner The business owner who
oversees store operations,
 monitors performance, and
makes strategic decisions
based on system reports.
3 Staff Store employees responsible
for managing operational
tasks, including inventory
management, order
processing, customer support,
and promotions.

2.3​ Operating Environment

The Computer Store Management System is designed for in-store deployment, utilizing
designated hardware, operating systems, and a networked environment to support seamless store
operations. The system operates locally within the store, accessible to authorized staff via
workstations connected to a central server.

A.​ Hardware Platform

●​ User Workstations: Desktop computers or laptops used by store staff for accessing system
features. These workstations require moderate processing capabilities to support the Java-based
application, with connectivity to the in-store network.
●​ Server Requirements: A dedicated in-store server or a centralized server hosted at a regional
office will support application hosting, database management, and access control. The server
requires sufficient storage capacity to maintain transactional, customer, inventory, and
promotion data.

b.​ Operating System and Software

●​ User Workstations: The system is compatible with operating systems that support Java
applications, including:
o​ Windows: Version 10 or later.
o​ macOS: Version 10.15 or later.
o​ Linux: Various distributions capable of supporting Java Runtime Environment (JRE).
●​ Server Operating System: The server can operate on:
o​ Linux (preferred for stability and resource efficiency) or Windows Server 2016 and later
versions, provided they support the necessary Java and database configurations.
●​ Java Runtime Environment: Java SE 17 or later is required on both the workstations and server
to ensure compatibility with the application.

Database and Storage

●​ Database Management System: A relational database (e.g., MySQL or PostgreSQL) will be

installed on the server to manage and store data related to inventory, customer information,
sales orders, returns, and promotions.
 ●​ Data Backup: Regular data backups are essential for data security and recovery. These backups
will be stored locally on secure storage solutions, with options for cloud backup as needed.

Geographical Locations

●​ User Location: The primary users (store staff) will access the system within the physical store.
●​ Server and Database Location: Hosted on-site at each store location or, for multi-store setups,
within a centralized data center for shared access across regional stores.

Integration and Compatibility

●​ Point of Sale (POS) System: The system may need to exchange data with the in-store POS system
to ensure consistent tracking of sales orders and payments. Integration with the POS system will
be achieved through APIs or data exports where possible.
●​ No E-commerce Integration: This version does not support direct integration with external
e-commerce platforms.

Network Requirements

●​ In-store Network: A reliable LAN or WAN setup is required to allow real-time data sharing
between workstations and the server. This network should be secured with proper firewall
configurations to ensure data privacy and prevent unauthorized access.

If further infrastructure is required to support this system’s deployment, it will be documented in

a separate infrastructure requirements specification to ensure a clear setup and reliable
operational environment.

2.4​ Design and Implementation Constraints

The Computer Store Management System is subject to several design and implementation
constraints based on corporate policies, hardware capabilities, and specific technology
requirements. These constraints ensure the system meets security, performance, and
compatibility standards while aligning with in-store operations.

2.4.1 Corporate and Regulatory Policies

●​ Data Privacy Compliance: The system must adhere to relevant data privacy laws and corporate
policies to ensure customer information is securely stored and handled. This includes compliance
with policies regarding data access, storage, and backup.
●​ Role-based Access Control: Access to specific functions must be restricted based on user roles
(e.g., Staff, Owner), ensuring that sensitive data and management functionalities are only
available to authorized personnel.

2.4.2 Hardware Limitations

 ●​ In-store Workstations: The system is designed to run on standard in-store desktops and laptops,
which may have moderate processing power and memory. The application should therefore be
optimized to avoid excessive resource usage and support smooth performance within these
constraints.
●​ Server Requirements: The server may have limited storage and processing power, particularly in
smaller retail locations. As a result, data-intensive tasks (e.g., bulk inventory updates or
reporting) should be optimized for efficiency.

2.4.3 Technology and Tool Requirements

●​ Java Development: All development will be in Java, requiring compatibility with Java SE 17 or
later across both workstations and the server. The system must be developed and tested within
this language environment.
●​ Visual Paradigm for Modeling: Visual Paradigm is the exclusive tool for creating UML diagrams,
use case models, and other documentation artifacts. All design elements must be documented
within Visual Paradigm for consistency.
●​ Relational Database Management: A relational database, such as MySQL or PostgreSQL, will be
used for storing data related to products, orders, customers, and promotions. The application
must be compatible with these databases.

2.4.4 Interface and Integration Constraints

●​ POS System Integration: The system may need to interface with the store’s POS system to
synchronize orders and payments. The integration must be achieved through APIs or file exports
if the POS supports them, without direct dependencies on external systems.
●​ No E-commerce Integration: This system does not support integration with external e-commerce
or online sales platforms. It is intended for in-store use only.

2.4.5 Network and Security Constraints

●​ In-store Network Dependency: The system relies on a stable LAN or WAN within the store to
ensure real-time access to the server. Network instability could limit system access, so the design
must include error handling for potential connectivity issues.
●​ Data Security: The system must implement secure data access protocols to protect customer
and transactional data. This includes secure database access, encryption where applicable, and
restricted system login methods.

These constraints ensure that the Computer Store Management System aligns with corporate,
regulatory, and operational requirements, supporting an efficient and secure implementation
within the store environment.

2.5​ Assumptions and Dependencies

The requirements and design of the Computer Store Management System are based on several
assumptions and dependencies that, if changed, could impact the project’s scope, timeline, or
functionality. This section outlines these assumptions and any critical dependencies on external
factors.
 2.5.1 Assumptions

1.​ Stable In-store Network: It is assumed that the store will have a reliable and stable LAN
or WAN connection. This network stability is essential for real-time data access between
workstations and the server. Any network issues could disrupt system functionality and
access.
2.​ Java Runtime Environment: It is assumed that Java SE 17 (or a compatible version) is
installed and maintained on all workstations and the server. This version of Java is
necessary for running the application, and any change in Java compatibility could require
code updates or system modifications.
3.​ Data Backup Procedures: It is assumed that regular data backups will be performed,
either locally or to a secure cloud platform, to prevent data loss and maintain data
integrity. A lapse in backup routines could lead to data inconsistencies or losses in case of
hardware failure.
4.​ Availability of Visual Paradigm for Modeling: Visual Paradigm will be available and
used exclusively for UML and system modeling. If this tool becomes unavailable or is
replaced, rework might be required for all existing documentation and model updates.
5.​ Staff Training: It is assumed that all users (staff and owners) will receive adequate
training on system functionality. A lack of training could lead to errors in usage, affecting
data accuracy and operational efficiency.
6.​ In-store POS Compatibility: It is assumed that the POS system in the store will support
integration, either via API or data export capabilities, to enable synchronization of sales
and order information. Limited POS compatibility could restrict the system’s ability to
access real-time transaction data.

2.5.2 Dependencies

1.​ Database Management System: The project depends on a compatible relational

database management system (e.g., MySQL or PostgreSQL) for storing and managing
data. If database support or licensing changes, additional work may be required to
migrate data or adapt the system.
2.​ External Hardware and Software Maintenance: The functionality of the system relies
on the maintenance of workstations, servers, and network hardware by the store’s IT
support. Delays in repairs or updates to these components could impact system
performance and access.
3.​ Regulatory Compliance Standards: Any changes in data privacy regulations or security
standards could require modifications to data handling, access controls, and storage
policies to remain compliant.
4.​ Operating System Compatibility: The system is dependent on compatible operating
systems (Windows 10 or later, macOS 10.15 or later, or supported Linux distributions) on
both workstations and the server. Changes in operating system compatibility or upgrades
could require testing and modifications to the application.
 5.​ Business Policies on Returns and Promotions: The design and workflows are based on
current business policies related to product returns, exchanges, and promotions. Any
significant changes in these policies may impact the requirements for related system
functions and processes.
These assumptions and dependencies form the basis of the system requirements and
implementation. If any of these assumptions prove incorrect or dependencies change, the project
may require adjustments to meet the new conditions.

3.​ System Features

3.1​ Use Case Diagram

3.2​ Use Case List Description

dua vao user characteristics

ID Use case Users UC Description
UC-01 Customer
Login allows a user to be able
to login in the software
 when he/she have registered
an account and his/her
account is still active.

UC-02 Customer
register in the software
Register when he/she haven’t registered
an account and his/her account
is still active.

UC-03 Customer
Logout able to logout of the
software when he/she have
registered an account and
his/her account is still active.

UC-04 Customer
search for computer in the
Seaarch store
product

UC-05 View product detail Customer view detailed information about a

product, including specifications,
price, availability, and images.

UC-06 Make Order Customer The Customer accesses the

computer store system to purchase

UC-07 Add to Cart Customer This use case enables the customer
to add a selected product to their
shopping cart. It allows customers
to specify the quantity they wish to
purchase and reflects the addition
in their cart, enabling them to
review their choices before
proceeding to checkout.
UC-08 View Cart Customer view the items they have added to
their shopping cart. It displays each
item's name, quantity, price, and
subtotal, along with the total cost
of all items in the cart

UC-9 Manage Product Staff , Owner Computer Store Staff to add,

update, or delete product
information in the system's
inventory. The staff can manage
details like product name,
specifications, price, stock
quantity, and category.
UC-10 Manage Orders Staff , Owner views the list of existing
customer orders, and can select
an order to either view details,
update the order status or items,
or cancel the order if necessary.
Updates may include changes to
delivery dates, quantities, or
specific products.
UC-11 Update Product Staff update product details, including
price, description, stock quantity,
or specifications.
UC-12 Process Orders Staff accesses the Order Processing
System to review and process
customer orders. Processing
includes verifying order details,
updating order status (e.g., "In
Progress", "Shipped",
"Delivered"), and ensuring
orders are ready for dispatch.
UC-13 Manage Customer Staff add, update, or deactivate
customer records. This allows
the staff to keep customer
information accurate, up-to-date,
and accessible for sales and
support purposes.
UC-14 Process Returns and Staff process customer requests for
Exchanges returning or exchanging
products. This involves verifying
 the eligibility of items for return
or exchange, updating the order
status, and adjusting inventory
levels accordingly.
UC-15 Refund Payment Staff the Payment Management
System to process a refund for a
customer, typically following a
return or cancellation. The
refund process involves
verifying the original payment,
calculating the refund amount,
and updating the payment status.
UC-16 Manage Inventory Owner manage product listings,
including adding new products,
updating existing product
information, or removing
products that are no longer
available.
UC-17 View Sales Reports Owner views various sales reports to
analyze business performance,
including daily and monthly
reports
UC-18 Manage Employees Owner manages employee records by
adding, updating, or removing
employees from the system.
UC-19 Handle Customer Owner The Owner addresses customer
Inquiries inquiries regarding products,
orders, and services to ensure
customer satisfaction.
System Feature Description

3.2.1 Usecase 1: Login

UC ID and Name: UC-1 Login

Created By: Giang Date Created: 10/10/2024

Primary Actor: Customer Secondary Actors: N/A

Description: The function allows a user to be able to login in the software when he/she
have registered an account and his/her account is still active.

Preconditions: 1. User has an account still active

 Postconditions: ​ 1. user successfully logged into system and able to access all
custome’s features

1.​ Customer access to the to the system

Normal Flow: 2.​ system Display Login screen with the following fields: user name,
password, login and sign up button
3.​ Users enter informations on the Login screen, then click on the
Login button.
4.​ System Validate the entered user name & password and then
display Home screen

Alternative Flows: N/A

Exceptions: 1. Cannot communicate with API server.

​ System displays error message.

2. Input data in step 7 violates one or some of the business rules.

​ System displays error message on the registration form.

3. 24 hours since the activation email is sent, the Guest does not click the
activation link.

​ System will deletes the account and the activation link from
database.

Priority: High

Frequency of use: High

Other N/A
Information:
 Assumptions: N/A

Business rule:
BR-01

3.2.2 Usercase: Register

UC ID and Name: UC-2 Register

Created By: Giang Date Created: 10/10/2024

Primary Actor: Customer Secondary Actors: N/A

 Description: The function allows a user to be able to register in the software when
he/she haven’t registered an account and his/her account is still active.

Preconditions: ​ 1. Guest has a valid email

Postconditions: 1 When the normal flow completes successfully, a new account is

created on the computer store System
 Normal Flow: 1. Guest open desktop application.

2. System display home page.

3. Guest clicks Register menu on navigation bar.

4. System displays login/register dialog box.

5. System displays the registration form in the dialog box.

6. Guest enters username, email, password, repassword on the

registration form.

7. Guest clicks Sign Up button on the registration form.

8. System creates a new account with field provided.

9. System generates an activation link for the account.

10. System sends an email with the activation link to provided

email address.

11. System displays a message to notify that account has been

created and activation email has been sent to the registered email
address.

12. Guest visits his/her email account and open the activation
email.

13. Guest clicks the activation link.

14. System activates the new account, then deletes the activations
link from database.

15. System display a message to notify that the account has been
activated.

16. System display the home page.

N/A
Alternative Flows:
 Exceptions: 1. Cannot communicate with API server.

​ System displays error message.

2. Input data in step 7 violates one or some of the business rules.

​ System displays error message on the registration form.

3. 24 hours since the activation email is sent, the Guest does not click the
activation link.

​ System will deletes the account and the activation link from
database.

Priority: High

Frequency of use: High

Other N/A
Information:

Assumptions: Guest can access his/her email account.

Business rule: BR-02

 3.2.3 Usercase: Logout

UC ID and Name: UC-3 Logout

Created By: Giang Date Created: 10/10/2024

Primary Actor: Customer Secondary Actors: N/A

Description:
The function allows a user to be able to logout of the software when
he/she have registered an account and his/her account is still active.

Preconditions: User has an account

Postconditions: ​ 1. When the normal flow completes successfully

 1. User login on computer store system successful
Normal Flow:
2. User click to Button Logout
3. User will exit the system
4. Computer store will redirect user to Home Page

Alternative Flows: N/A

Exceptions: 1. Cannot communicate with API server.

​ System displays error message.

2. Input data in step 7 violates one or some of the business rules.

​ System displays error message on the registration form.

3. 24 hours since the activation email is sent, the Guest does not click the
activation link.

​ System will deletes the account and the activation link from
database.

Priority: High

Frequency of use: High

Other N/A
Information:

Assumptions: N/A

Business rule:
BR-03
 3.2.4 Usercase: Search

UC ID and Name: UC-4 Search

Created By: Giang Date Created: 10/10/2024

Primary Actor: Customer Secondary Actors: N/A

Description: The function allows a user to be able to search for computer in the store

Preconditions: N/A

Postconditions: N/A
 1. Guest enters search keyword on search box in navigation.
Normal Flow:
2. Guest clicks search button.
3. System displays the list of products matched with the search

Alternative Flows: N/A

Exceptions: N/A

Priority: Low

Frequency of use: Medium

Other N/A
Information:

Assumptions: N/A

Business rule:
BR-04
 3.2.5 Usercase: View Product detail

UC ID and Name: UC-5 View product detail

Created By: Giang Date Created: 10/10/2024

Primary Actor: Customer Secondary Actors: N/A

Description: Allows the customer to view detailed information about a product,

including specifications, price, availability, and images. It helps customers
make informed purchasing decisions by providing all relevant details for
each product.

Preconditions: 1. The system has available product data in the inventory.

2. ​ The customer is on the product listing page or a product category page.

 Postconditions: 1. The customer is shown the selected product’s detailed information.

2. The system logs the customer's product view history (optional).

1. The customer selects a product from the product listing or

Normal Flow: category page.
2. The system retrieves the detailed information for the selected
product.
3. The system displays the product details, including
specifications, price, stock status, and images.
4. The customer can view, zoom in on images, and read product
specifications.

Alternative Flows: 1: Product Out of Stock

If the product is out of stock, the system shows an "Out of Stock" message
and may offer a "Notify Me" option.

2: Product Information Update (Admin)

Admin can update product details to reflect new specifications, price, or

stock status. Updates are shown in real-time to customers.

Exceptions: 1. ​ Network Issues - If there is a network error, the system displays a

message, "Unable to retrieve product details. Please try again later."

2. ​ Product Not Found - If the product is not found in the database, the
system displays an error message, "Product not available."

Priority: High

Frequency of use: High

Other N/A
Information:
 Assumptions: 1. The customer is familiar with basic navigation in the online
store.

2. Product details are kept up-to-date by the admin to ensure

accuracy.

Business rule:
BR-04 , BR-05

3.2.6 Usercase: Make Order

UC ID and Name: UC-6 Make Order

Created By: Giang Date Created: 10/10/2024

Primary Actor: Customer Secondary Actors: N/A

Trigger: A Customer indicates that he wants to purchase

Description: The Customer accesses the computer store system to purchase

Preconditions: 1. Customer is logged into the computer store system.

2. da co sp trong gio hang

Postconditions: 1. Once the order has been created, it will be entered into the
system.
 Normal Flow: Create orders

1.Customer login into the Computer store system

2. The system provides options for Customer to perform purchase.

3. Customer selects the button "Order" option.

4. The system presents a form with fields for the Order information
and customer information if they are new customer

5. Computer store system will generate OrderDate for the order.

6. Once the order details are complete, Customer submits the new
order.

7. If there are any validation issues, the system notifies the

customer and allows for corrections.

8. If validation succeeds, the system confirms the creation of the

new order.

9. Customer can review the order details and confirm the creation.

10. The system generates an Order Tracking for reference.

Alternative Flows: 1.1 Create multiple identical orders

​ 1.The Customer creates more than 1 order with customerID

​ 2.Return to step 3 of normal flow.

1.2 Order has not been submitted yet

​ 1. Customer forgot to submit order

​ 2. Return to step 4 of normal flow.

 Exceptions: 1.0.E1 Customer places orders that are too short-term compared to the
minimum production process

1. The system will display the message "invalid time"

2a. If Customer cancels the order, the system will end

2b. If the customer changes to another date, the system will restart the use
case.

Priority: High

Frequency of use: High

Frequency of Use: Frequency of use: About 100 orders, an average of one use per day. Peak
usage for this use case is between 7 am and 5 pm

Business Rules: BR1: Order total price is calculated by the price of the product multi by the
quantity of each product.

BR2: If customer attempt to place an order exceeding the available

quantity in the warehouse, the system will notify and prompt them to fix
the issue

BR3: The system must authenticate and prompt the customer to fill in any
missing information before allowing the order to be submitted.
 Other 1. Customer can edit orders after submitting
Information:

2. Draft orders will be automatically removed after 7 days

3. Cannot edit when process progress is 20%

Assumptions: Assume that 30 percent of orders are placed on the same day and at the
same time and there are not enough workers to work that day

Business rule: BR-01,BR-06,BR-07

3.2.7 Add to cart

UC ID and Name: UC-7 Add to Cart

Created By: Giang Date Created: 10/10/2024

Primary Actor: Customer Secondary Actors: N/A

Description: This use case enables the customer to add a selected product to their
shopping cart. It allows customers to specify the quantity they wish to
purchase and reflects the addition in their cart, enabling them to review
their choices before proceeding to checkout.

Preconditions: 1. The customer is viewing a product’s detail page.

2. ​ The product is in stock.

Postconditions: 1. The product is added to the customer’s cart with the specified
quantity.

2. The cart is updated, and the customer receives confirmation that the
item was added.

1. The customer selects a product and specifies the quantity to

Normal Flow: add to the cart.
2. The customer clicks the "Add to Cart" button.
3. The system checks the product’s availability and quantity.
4. The system adds the specified quantity of the product to the
customer’s cart.
5. The system displays a confirmation message, showing the item
has been added to the cart, and provides an option to view the
cart or continue shopping.
Alternative Flows: 1.Out of Stock

1.1. If the product is out of stock or insufficient for the specified quantity,
the system notifies the customer and suggests adjusting the quantity.

2.Product Limit Exceeded

2.1. If the quantity exceeds the allowed limit (e.g., bulk purchase limit), the
system prompts the customer to enter a valid quantity.

Exceptions: N/A

Priority: High

Frequency of use: Medium

Other N/A
Information:

Assumptions: 1. The customer is familiar with the "Add to Cart" functionality.

2. Product information, including price and stock status, is

up-to-date.

Business rule:
BR-01,BR-06,BR-07
 3.2.8 View cart

UC ID and Name: UC-8 View Cart

Created By: Giang Date Created: 10/10/2024

Primary Actor: Customer Secondary Actors: N/A

Description: Allows the customer to view the items they have added to their shopping
cart. It displays each item's name, quantity, price, and subtotal, along with
the total cost of all items in the cart. The customer can review their
selected items before proceeding to checkout.

Preconditions: 1. The customer has an active shopping session.

 2. ​ There is at least one item in the shopping cart.

Postconditions: 1. The customer can review items in the cart and make modifications if
necessary.

2. The system reflects any changes made to the cart (e.g.,

adding/removing items, updating quantities).

1. The customer selects the "Cart" option from any page in the
Normal Flow: system.
2. The system retrieves the items currently in the customer’s
cart.
3. The system displays each item’s name, quantity, price,
subtotal, and the total amount for all items.
4. The customer can proceed to checkout or update the cart.

Alternative Flows: 1: Empty Cart:

1.1. If there are no items in the cart, the system displays a message, "Your
cart is empty." and suggests browsing products.

2: Update Cart Item:

2.1. The customer can modify item quantities or remove items.

2.2. The system updates the cart total in real-time.

Exceptions: 1. ​ Network Issues - If there is a network error, the system displays a

message, "Unable to retrieve cart details. Please try again later."

2. ​ Price/Availability Change - If an item’s price or availability changes, the

system updates the cart with the new information and notifies the
customer.

Priority: High

Frequency of use: Medium

 Other N/A
Information:

Assumptions: 1. The customer has already selected items to add to the cart.

2. Product prices are up-to-date and consistent with displayed

promotions.

Business rule:
BR-01,BR-06,BR-07
 3.2.9 View purchase history

UC ID and Name: UC-9 View purchase history

Created By: Giang Date Created: 10/10/2024

Primary Actor: Customer Secondary Actors: N/A

Description: This use case allows the customer to view a history of their past purchases.
It displays order details such as the date of purchase, list of items,
quantities, total amount, and order status (e.g., delivered, in transit).
Customers can also access receipts and track orders if they are still in
progress.

1. The customer is logged into their account.

Preconditions:
2. ​ The customer has completed at least one purchase.

Postconditions: 1. The customer can view details of past purchases and track ongoing
orders.

2. The customer can download receipts or invoices for completed

purchases.

1. The customer navigates to the "Purchase History" section from

Normal Flow: their account dashboard.
2. The system retrieves a list of past orders and their details for
the customer.
3. The system displays a summary list of past orders with key
details (date, total, order status).
4. The customer can select any order to view full details,
including itemized purchases, quantities, prices, and order
status.

Alternative Flows: 1.No Purchase History

 1.1. If the customer has no past purchases, the system displays a message,
"No purchase history available," and suggests browsing products.

Exceptions: N/A

Priority: Low

Frequency of use: Low

Other N/A
Information:

Assumptions: 1. The customer is familiar with navigating their account

dashboard.

2. Purchase history is kept up-to-date in the system.

Business rule:
1. Only completed and confirmed purchases are shown in the
history.

2. Orders older than a certain date may be archived according to

data retention policies.
 3.2.10 Manage Product

ID and Name: UC-10 Manage Product

Created By: Tuấn Anh Date Created: 10/27/2024

N/A
Primary Actor: Computer Store Secondary
Staff Actors:

Description: This use case allows the Computer Store Staff to add, update, or
delete product information in the system's inventory. The staff can
manage details like product name, specifications, price, stock
quantity, and category.

Trigger: A Computer Store Staff member decides to add a new product,

update an existing product, or remove a product from the system.
Preconditions: PRE-1. Staff is logged into the system with appropriate
permissions to manage products..

PRE-2. The product data is available and ready to be entered or

updated.

Postconditions: POST-1. The product inventory is updated with the latest

information on products.

POST-2. Updated product information is reflected in the system

and available to other users..

Normal Flow: Normal Flow: 1.0 Manage Product Information

1. Staff selects the "Manage Products" option from the main menu.

2. System displays options to add, update, or delete a product.

3. Staff chooses one of the options:

●​ Add Product: Staff enters product details (image, name,

description, price, quantity, category) and submits. (see
1.0.E1)
●​ Update Product: Staff searches for the product, selects it,
makes changes to the fields, and submits. (see 1.0.E1,
1.0.E2)
●​ Delete Product: Staff searches for the product, selects it,
and confirms the deletion. (see 1.0.E2)

4. System processes the input and updates the inventory database.

5. System displays a confirmation message indicating successful

update, addition, or deletion of the product.
Alternative Flows: 1.1.Product Already Exists

1. If staff attempts to add a product that already exists in the

inventory, the system notifies staff and provides an option to
update the existing product instead.

1.2.Insufficient Permissions

2. If staff does not have sufficient permissions to manage

products, the system denies access and displays an error
message.

Exceptions: 1.0.E1 Invalid Input Data

1.​ If any required product details are missing or entered

incorrectly, the system prompts staff to correct the
information.

1.0.E2 Product Not Found

1.​ If staff attempts to update or delete a product that is not in

the inventory, the system displays a "Product Not Found"
error.

Priority: High

Frequency of Use: Approximately 50-100 updates or additions per week, depending

on inventory needs.

Business Rules: BR-01

Other Information: 1. Staff can view all products in the inventory and filter by
category or availability.

2. Changes to product prices or specifications must be logged for

audit purposes.

Assumptions: Assume that staff have been trained in system usage and
understand inventory requirements for the store.
 3.2.11 Manage Orders

ID and Name: UC-11 Manage Orders

Created By: Tuấn Anh Date Created: 10/27/2024

Primary Actor: Computer Store Secondary

Staff Actors:

Description: A Computer Store Staff member accesses the Order Management

System from the store’s internal network, views the list of existing
customer orders, and can select an order to either view details,
update the order status or items, or cancel the order if necessary.
Updates may include changes to delivery dates, quantities, or
 specific products. When an order is canceled or updated, the
system adjusts the inventory and notifies the customer if required.

Trigger: A Computer Store Staff member needs to process or update a

customer order..

Preconditions: PRE-1. Staff is logged into the system with appropriate

permissions to manage orders.​
PRE-2. Order data is available in the system.

Postconditions: POST-1. The order is updated with the latest information or status.​
POST-2. Any inventory or delivery schedules impacted by the
order are updated accordingly.

Normal Flow: 2.0 Manage Order

1.​ Staff selects the "Manage Orders" option from the main
menu.
2.​ System displays a list of current orders and search options.
3.​ Staff chooses an order to view, update, or cancel.
○​ View Order: Staff selects an order to view order
details, including items, customer information, and
delivery status.
○​ Update Order: Staff modifies order details such as
delivery date, items, or status. (see 2.0.E1, 2.0.E2)
○​ Cancel Order: Staff selects an order, confirms the
cancellation, and the system marks it as canceled.
(see 2.0.E2, 2.0.E3)
4.​ System processes the input and updates the order status
and/or details in the database.
5.​ System displays a confirmation message indicating the
successful viewing, update, or cancellation of the order.
Alternative Flows: 2.1. Customer Requests Order Modification

1.​ After selecting an order, if the customer has requested a

modification (such as changing delivery time or items), the
staff member makes the requested changes.
2.​ System verifies if the updated items are available in stock.
3.​ If stock is available, the system updates the order and
inventory levels.
4.​ If stock is not available, the system notifies the staff and
provides options to adjust quantities or replace items. (see
2.0.E1)

2.2. Partial Order Cancellation

1.​ Instead of canceling the entire order, the staff may cancel
specific items within an order if allowed by the store's
policy.
2.​ The system updates the order, removes the canceled items,
adjusts the total price, and updates the inventory.
3.​ The system notifies the customer of the partial cancellation.

Exceptions: 2.0.E1 Invalid Input Data: Occurs if any required details in the
order update are missing or entered incorrectly (e.g., invalid
delivery date or item quantity). The system prompts the staff to
correct the information.

2.0.E2 Order Not Found: Occurs if the staff attempts to update or

cancel an order that does not exist in the system. The system
displays an "Order Not Found" error.

2.0.E3 Order Cannot Be Canceled: Occurs if the staff attempts to

cancel an order that is already marked as shipped or delivered. The
system notifies the staff that the order cannot be canceled.

Priority: BR-01

Frequency of Use: Approximately 50-100 orders processed daily, with peak usage
during business hours.
 Business Rules: BR-6, BR-8, BR-15

Other Information: 1. Staff can filter orders by status, date, or customer for easier
management.

2. All changes to orders must be logged for audit and tracking

purposes.

Assumptions: Assume that staff are familiar with order management procedures
and have the necessary permissions to access order information.

3.2.12 Update Product

 ID and Name: UC-12 Update Product

Created By: Tuấn Anh Date Created: 10/27/2024

Primary Actor: Computer Store Secondary

Staff Actors:

Description: A Computer Store Staff member accesses the Product

Management System from the internal network to update product
details, including price, description, stock quantity, or
specifications. This ensures that product information remains
accurate and up-to-date for customers viewing the catalog or
making purchases.

Trigger: A Computer Store Staff member needs to modify the information

for an existing product in the inventory.

Preconditions: PRE-1. Staff is logged into the system with permissions to update
product information.​
PRE-2. The product exists in the inventory database.

Postconditions: POST-1. The product information is updated in the system and is

visible to customers in the catalog.​
POST-2. Any changes in stock quantities are reflected in inventory
reports.
 Normal Flow: 4.0 Update Product Information

1.​ Staff selects the "Product Management" option from the

main menu.
2.​ System displays a list of available products and a search
function.
3.​ Staff searches for the product to be updated and selects it.
(see 4.0.E2)
4.​ System displays current product details (e.g., name,
description, price, stock).
5.​ Staff modifies one or more fields (e.g., price, stock quantity,
specifications) and submits the changes. (see 4.0.E1)
6.​ System validates the input and updates the product
information in the database.
7.​ System displays a confirmation message indicating the
successful update of the product information.

Alternative Flows: 4.1.A1 Simultaneous Product Update Conflict

1.​ If another staff member is already editing the same product,

the system notifies the staff of the conflict and provides
options:

· Wait until the other update is complete.

· Override the changes if permissions allow.

2.​ Staff chooses an option, and the system proceeds

accordingly.

Exceptions: 4.0.E1 Invalid Input Data: Occurs if any required fields are left
blank or contain invalid values (e.g., negative stock quantity or
invalid price format). The system prompts the staff to correct the
information.

4.0.E2 Product Not Found: Occurs if the product does not exist in
the inventory (e.g., due to deletion or incorrect search input). The
system displays a "Product Not Found" error.
 Priority: High

Frequency of Use: Product information is updated frequently, especially for stock

adjustments or price changes, with approximately 50-100 updates
per week.

Business Rules: BR-01,BR-05

Other Information: 1. Product updates must be logged for inventory tracking and audit
purposes.

2. Staff can view product history to see previous modifications.

Assumptions: Assume that staff have access to accurate product information and
understand the required format for each field.
 3.2.13 Process Orders

ID and Name: UC-13 Process Orders

Created By: Tuấn Anh Date Created: 10/27/2024

Primary Actor: Computer Store Secondary

Staff Actors:

Description: A Computer Store Staff member accesses the Order Processing

System to review and process customer orders. Processing
includes verifying order details, updating order status (e.g., "In
Progress", "Shipped", "Delivered"), and ensuring orders are ready
for dispatch.

Trigger: A new customer order is received, or an existing order requires

status updates for fulfillment.

Preconditions: PRE-1. Staff is logged into the system with permissions to process
orders.​
PRE-2. The order exists in the system and is ready for processing.

Postconditions: POST-1. The order status is updated in the system and is visible to
the customer.​
POST-2. Inventory quantities are adjusted according to the items
in the processed order.
 Normal Flow: 5.0 Process Orders

1.​ Staff selects the "Process Orders" option from the main
menu.
2.​ System displays a list of pending orders and search
functionality.
3.​ Staff searches for and selects an order to process. (see
5.0.E2)
4.​ System displays the order details, including customer
information, items, quantities, and total price.
5.​ Staff verifies the order details and confirms stock
availability for each item. (see 5.0.E1)
6.​ Staff updates the order status as necessary (e.g., "In
Progress", "Shipped", "Delivered") and confirms. (see
5.0.E3)
7.​ System processes the update and adjusts inventory
quantities for the ordered items.
8.​ System displays a confirmation message indicating the
successful processing of the order.

Alternative Flows: 5.0.A1 Insufficient Stock for Order Items

1. If stock is insufficient for one or more items in the order, the

system notifies the staff and provides options:

· Place items on backorder if possible.

· Notify the customer of the stock issue and adjust the order.

2. Staff selects one of the options, and the system updates the order
accordingly.

.
 Exceptions: 5.0.E1 Stock Unavailable: Occurs during the verification step if
any ordered items are out of stock. The system notifies staff and
suggests checking the backorder option or notifying the customer.

5.0.E2 Order Not Found: Occurs if the order does not exist in the
system (e.g., due to incorrect search input or deletion). The system
displays an "Order Not Found" error.

5.0.E3 Invalid Order Status: Occurs if an invalid or inappropriate

status is selected for the order (e.g., setting "Delivered" before
"Shipped"). The system prompts the staff to correct the status.

Priority: High

Frequency of Use: Order processing occurs frequently, with peak times based on
business hours and daily transactions, totaling approximately
100-200 orders processed weekly.

Business Rules: BR-01,BR-06

Other Information: 1. Order history and status changes are logged for audit and
tracking purposes.

2. Staff can filter orders by status or customer information for more

efficient processing.

Assumptions: Assume that inventory levels are updated regularly and that staff
have the authority to place items on backorder if necessary.

ID and Name: UC-06 Manage Customer

Created By: Tuấn Anh Date Created: 10/27/2024

Primary Actor: Computer Store Secondary

Staff Actors:
 Description: A Customer Support Staff member accesses the Customer
Management System to add, update, or deactivate customer
records. This allows the staff to keep customer information
accurate, up-to-date, and accessible for sales and support
purposes.

Trigger: A customer requests an update to their information, or the staff

needs to modify customer records for business reasons.

Preconditions: PRE-1. Staff is logged into the system with permissions to manage
customer records.​
PRE-2. The customer’s record exists in the system (for updates or
deactivation).

Postconditions: POST-1. Customer information is updated or deactivated in the

system.​
POST-2. Updated information is accessible for order processing,
support, and sales analysis.

Normal Flow: 6.0 Manage Customer Information

1.​ Staff selects the "Manage Customer" option from the main
menu.
2.​ System displays options to add a new customer, update
existing customer information, or deactivate a customer
account.
3.​ Staff chooses one of the options:

· Add Customer: Staff enters customer details (name, contact

information, address, preferences) and submits. (see 6.0.E1)

· Update Customer: Staff searches for the customer record,

selects it, modifies the necessary fields, and submits. (see 6.0.E1,
6.0.E2)

· Deactivate Customer: Staff searches for the customer record,

selects it, and confirms deactivation. (see 6.0.E2)

4.​ System processes the input and updates the customer

database.
 5.​ System displays a confirmation message indicating the
successful addition, update, or deactivation of the customer
record.

Alternative Flows: 6.1.A1 Reactivate Deactivated Customer

1.​ If a previously deactivated customer wants to reactivate

their account, staff searches for the customer record.
2.​ System identifies the record as deactivated and prompts the
staff to confirm reactivation.
3.​ Staff confirms reactivation, and the system updates the
customer’s status to active.

Exceptions: 6.0.E1 Invalid Input Data: Occurs if any required customer details
are missing or incorrectly formatted (e.g., invalid contact number or
address). The system prompts the staff to correct the information.

6.0.E2 Customer Not Found: Occurs if the customer record does

not exist in the system (e.g., due to incorrect search input or
deletion). The system displays a "Customer Not Found" error.

Priority: Medium

Frequency of Use: Customer records are updated frequently, especially with new
customers or changes to contact information, with approximately
30-50 updates weekly.

Business Rules: BR-01

Other Information: · All changes to customer records are logged for tracking and
compliance purposes.

· Staff can filter customer records by status (active/inactive), name,

or date of last update for easier management.

Assumptions: Assume that customer records are regularly reviewed and that staff
understand privacy and data entry requirements for managing
customer information.
 3.2.14 Process Returns and Exchanges

ID and Name: UC-14 Process Returns and Exchanges

Created By: Tuấn Anh Date Created: 10/27/2024

Primary Actor: Computer Store Secondary

Staff Actors:

Description: A Customer Support Staff member accesses the Return and

Exchange Management System to process customer requests for
returning or exchanging products. This involves verifying the
eligibility of items for return or exchange, updating the order status,
and adjusting inventory levels accordingly.

Trigger: A customer requests a return or exchange for a purchased item,

either due to product issues or preference.

Preconditions: PRE-1. Staff is logged into the system with permissions to process
returns and exchanges.​
 PRE-2. The product return or exchange request is submitted
within the store's return/exchange policy timeframe.

Postconditions: POST-1. The product status is updated in the system, and the
customer’s return or exchange is recorded.​
POST-2. Inventory is adjusted if the product is restocked or
exchanged.

Normal Flow: 7.0 Process Return or Exchange

1.​ Staff selects the "Process Returns and Exchanges" option

from the main menu.
2.​ System displays a list of recent orders and a search function
to locate the specific order.
3.​ Staff searches for and selects the order with the item to be
returned or exchanged. (see 7.0.E2)
4.​ System displays order details, including item(s), purchase
date, and eligibility for return or exchange.
5.​ Staff verifies the return/exchange eligibility according to
policy (e.g., within return period, item condition). (see
7.0.E1)
6.​ If eligible, staff selects the item(s) for return or exchange
and confirms the action.
7.​ System updates the order status and inventory levels,
processing the return or preparing the new item for
exchange.
8.​ System displays a confirmation message indicating
successful processing of the return or exchange.
Alternative Flows: 7.1 Partial Return or Exchange

1.​ If only some items in the order are being returned or

exchanged, staff selects the specific items rather than the
entire order.
2.​ System processes the selected items, updating their status
and adjusting inventory.
3.​ System displays confirmation for the partial return or
exchange.

7.2 Non-Eligible Item for Return or Exchange

4.​ If an item is not eligible for return or exchange (e.g., due to

policy restrictions or damage), the system notifies staff.
5.​ Staff informs the customer of the non-eligibility, with
options to provide alternative resolutions (e.g., repair
services or discounts).

Exceptions: 7.0.E1 Ineligible Return/Exchange: Occurs if the item does not

meet return/exchange criteria (e.g., outside the return period or
improper condition). The system notifies staff and prevents further
action.

7.0.E2 Order Not Found: Occurs if the order does not exist in the
system (e.g., incorrect search input or system error). The system
displays an "Order Not Found" error.

Priority: High

Frequency of Use: Approximately 50-100 updates or additions per week, depending

on inventory needs.

Business Rules: BR-01

Other Information: 1. Staff can view all products in the inventory and filter by
category or availability.
 2. Changes to product prices or specifications must be logged for
audit purposes.

Assumptions: Assume that staff have been trained in system usage and
understand inventory requirements for the store.

3.2.15 Refund Payment

ID and Name: UC-15 Refund Payment

Created By: Tuấn Anh Date Created: 10/27/2024

Primary Actor: Computer Store Secondary

Staff Actors:

Description: A Customer Support Staff member accesses the Payment

Management System to process a refund for a customer, typically
following a return or cancellation. The refund process involves
verifying the original payment, calculating the refund amount, and
updating the payment status.

Trigger: A refund request is initiated due to an approved return, exchange,

or order cancellation.

Preconditions: PRE-1. Staff is logged into the system with permissions to process
refunds.​
PRE-2. The return, exchange, or cancellation has been approved,
making the customer eligible for a refund.

Postconditions: POST-1. The refund is processed and recorded in the system.​

POST-2. The customer's payment status is updated, and the
refund amount is transferred back to the original payment method.
 Normal Flow: 8.0 Process Refund

1.​ Staff selects the "Process Refund" option from the main
menu.
2.​ System displays a list of orders eligible for a refund and a
search function to locate specific orders.
3.​ Staff searches for and selects the order for which a refund is
to be issued. (see 8.0.E2)
4.​ System displays order details, including payment
information and eligible refund amount.
5.​ Staff verifies the refund amount and confirms the refund
method (e.g., original payment method, store credit).
6.​ System processes the refund request and initiates the refund
to the customer’s original payment method or selected
option. (see 8.0.E1)
7.​ System updates the payment status to "Refunded" and
records the transaction.
8.​ System displays a confirmation message indicating the
successful processing of the refund.

Alternative Flows: 8.1 Partial Refund

1.​ If only a partial refund is required (e.g., for a partial return

or service fee), staff adjusts the refund amount accordingly.
2.​ System processes the adjusted refund and updates the
payment status to reflect the partial refund.
3.​ System displays confirmation for the partial refund.

8.2 Refund via Store Credit

1.​ If the customer requests a refund in store credit instead of

the original payment method, staff selects the "Store Credit"
option.
2.​ System processes the refund by issuing the equivalent
amount in store credit to the customer’s account.
3.​ System displays confirmation, showing the store credit
applied to the customer’s account.
 Exceptions: · 8.0.E1 Refund Method Not Available: Occurs if the original
payment method cannot be refunded (e.g., expired card). The
system prompts staff to select an alternative refund method, such as
store credit.

· 8.0.E2 Order Not Found: Occurs if the order does not exist in
the system (e.g., due to incorrect search input or cancellation
without record). The system displays an "Order Not Found" error.

Priority: High

Frequency of Use: Refunds are processed occasionally, with approximately 10-20

transactions per month depending on customer returns and
cancellations.

Business Rules: BR-01

Other Information: 1. ​ All refund transactions are logged for audit and compliance
purposes.

2. Staff can filter eligible orders by refund status to prioritize

pending requests.

Assumptions: Assume that staff understand refund policies and have access to
customer payment information necessary for processing refunds.
 3.5.16 Manage Inventory

UC ID and Name: UC-16 Manage Inventory

Created By: Mạnh Nam Date Created: 10/27/2024

Primary Actor: Owner Secondary

Actors:

Trigger: The Owner initiates inventory management to update stock

levels or add new products.

Description: The Owner accesses the Inventory Management System to

manage product listings, including adding new products,
updating existing product information, or removing products
that are no longer available.
 Preconditions: PRE-1. Owner is logged into the system with inventory
management permissions.

PRE-2. The product record exists in the system for updates or

removal.

Postconditions: POST-1. Product information is updated or removed from the

inventory system.

POST-2. Inventory records are current and accurate for sales

and order processing.

1. Owner selects the "Manage Inventory" option from the main

Normal Flow: menu.
2. System displays options to add, update, or remove
products.
3. Owner chooses one of the options:

●​ Add Product: Owner enters product details (image,

name, price, quantity, description) and submits.
●​ Update Product: Owner searches for the product
record, selects it, modifies the necessary fields, and
submits.
●​ Remove Product: Owner searches for the product
record, selects it, and confirms removal.

4. System processes the input and updates the product

database.
5.System displays a confirmation message indicating the
successful addition, update, or removal of the product record.

Alternative Flows: 1A. If the Owner selects Update Product, and the product
does not exist, the system displays an error message.
 Exceptions: 1.E1 Invalid Input Data: Occurs if any required product details
are missing or incorrectly formatted. The system prompts the
Owner to correct the information.

1.E2 Product Not Found: Occurs if the product record does not
exist in the system. The system displays a "Product Not Found"
error.

Priority: High

Frequency of Use: Daily, with frequent updates as products are added or removed.

Business Rules: BR-41. BR-42

Other Information: All changes to product records are logged for tracking
purposes.

Assumptions: Assume that the inventory data is regularly reviewed and

updated.

3.2.17 View Sales Reports

UC ID and Name: UC-17 View Sales Reports

Created By: Mạnh Nam Date Created: 10/27/2024

Primary Actor: Owner Secondary

Actors:
 Trigger: The Owner requests a sales report to review sales
performance.

Description: The Owner views various sales reports to analyze business

performance, including daily and monthly reports.

Preconditions: PRE-1. Owner is logged into the system with access to sales
data.

Postconditions: POST-1. The Owner views the selected sales report.

1. Owner selects the "View Sales Reports" option from the

Normal Flow: main menu.
2. System generates and displays the report.
3. Owner reviews the report details.

Alternative Flows: 2A. If no reports are available for the selected date range, the
system prompts the Owner to select a different range.

Exceptions: 2.E1 Report Generation Failure: Occurs if there is an error

generating the report. The system displays an error message.

Priority: Medium

Frequency of Use: Monthly

Business Rules: BR-43

Other Information: Reports can be exported in various formats (e.g., PDF, CSV).

Assumptions: The sales data is regularly updated and maintained.

3.2.18 Manage Employees
UC ID and Name: UC-18 Manage Employees

Created By: Mạnh Nam Date Created: 10/27/2024

Primary Actor: Owner Secondary

Actors:

Trigger: The Owner needs to update employee information or manage

staffing.

Description: The Owner manages employee records by adding, updating, or

removing employees from the system.

Preconditions: PRE-1. Owner is logged into the system with employee

management permissions.

Postconditions: POST-1. Employee records are updated or removed from the

system.

1. Owner selects the "Manage Employees" option from the

Normal Flow: main menu.
2. System displays options to add, update, or remove
employees.
3. Owner chooses one of the options:

●​ Add Employee: Owner enters employee details

(image, name, role, contact information, salary) and
submits.
●​ Update Employee: Modifies the necessary fields, and
submits.
●​ Remove Employee: Owner searches and confirms
removal.

4. System processes the input and updates the employee

database.
 5. System displays a confirmation message indicating the
successful addition, update, or removal of the employee
record.

Alternative Flows: I3A. If the Owner selects Update Employee, and the employee
does not exist, the system displays an error message.

Exceptions: 3.E1 Invalid Input Data: Occurs if any required employee

details are missing or incorrectly formatted. The system
prompts the Owner to correct the information.

3.E2 Employee Not Found: Occurs if the employee record does

not exist in the system. The system displays an "Employee Not
Found" error.

Priority: High

Frequency of Use: As needed (depends on staffing changes)

Business Rules: BR-44

Other Information: All changes to employee records are logged for tracking
purposes.

Assumptions: Assume that employee data is regularly reviewed and updated.

3.2.19 Handle Customer Inquiries

UC ID and Name: UC-19 Handle Customer Inquiries

Created By: Mạnh Nam Date Created: 10/27/2024

 Primary Actor: Owner Secondary
Actors:

Trigger: A customer contacts support with an inquiry.

Description: The Owner addresses customer inquiries regarding products,

orders, and services to ensure customer satisfaction.

Preconditions: PRE-1. Owner is logged into the system and has access to
customer information.

Postconditions: POST-1. Customer inquiries are logged and addressed in the

system.

1. Owner selects the "Handle Customer Inquiries" option from

Normal Flow: the main menu.
2. System displays a list of current inquiries.
3. Owner selects an inquiry to address.
4. Owner responds to the inquiry and submits the response.
5. System updates the inquiry status and logs the response.

Alternative Flows: 4A. If the inquiry cannot be addressed, the Owner can escalate
it to a higher authority.

Exceptions: 4.E1 Inquiry Not Found: Occurs if the inquiry record does not
exist in the system. The system displays an error message.

Priority: High

Frequency of Use: Daily, depending on customer interaction volume.

Business Rules: BR-47

Other Information: Inquiry responses are tracked for service quality assessment.
Assumptions: Assume that all inquiries are documented in the system for
reference.
 1.​

4.​ Data Requirements

The Computer Store Management System handles various types of data related to inventory, customer
orders, promotions, and customer information. This section outlines the essential data inputs,
processing, and outputs, along with storage and security considerations.

4.1​ Logical Data Model

1.​ 1. Entities and Attributes
●​ Product
o​ Attributes: ProductID , Name, Description, Specifications, Category, Price, StockQuantity,
SupplierID (FK)
o​ Relationships: Related to Order and Promotion entities; linked to Supplier through
SupplierID.
●​ Customer
o​ Attributes: CustomerID (PK), Name, ContactInfo, Address, LoyaltyPoints
o​ Relationships: Related to Order and Return entities.
●​ Order
o​ Attributes: OrderID (PK), CustomerID (FK), OrderDate, Status, TotalAmount,
PaymentMethod
o​ Relationships: Linked to Customer via CustomerID; contains multiple OrderItems.
●​ OrderItem
o​ Attributes: OrderItemID (PK), OrderID (FK), ProductID (FK), Quantity, Price
o​ Relationships: Links Order to Product through foreign keys, indicating products included
in an order.
●​ Promotion
o​ Attributes: PromotionID (PK), Name, DiscountType, DiscountValue, StartDate, EndDate
 o​ Relationships: Associated with Product through a many-to-many relationship, as a
promotion can apply to multiple products and vice versa.
●​ Return
o​ Attributes: ReturnID (PK), OrderID (FK), CustomerID (FK), ReturnDate, RefundAmount,
Reason
o​ Relationships: Linked to Order and Customer, representing a return request for an
order.
●​ Supplier
o​ Attributes: SupplierID (PK), Name, ContactInfo, Address
o​ Relationships: Linked to Product via SupplierID, representing the supplier of each
product.

2.​ 2. Relationships

●​ Product - OrderItem: Each product can appear in multiple orders, and each order may contain
multiple products. This is represented through the OrderItem entity as a many-to-many
relationship between Product and Order.
●​ Product - Promotion: A promotion may apply to multiple products, and each product can have
multiple active promotions (e.g., holiday discounts plus category-specific discounts).
●​ Order - Customer: Each order is placed by a single customer, and each customer can have
multiple orders.
●​ Return - Order: Each return request is linked to a specific order, representing items returned
from that order.
●​ Product - Supplier: Each product is associated with a supplier.

If you’re using Visual Paradigm, you can model these entities and their relationships in an
Entity-Relationship Diagram (ERD) to provide a visual structure of how data entities relate to
each other within the system. Let me know if you’d like further assistance with a detailed ERD
or additional attributes and relationships.

4.2​ Data Dictionary

The Data Dictionary defines the structure, meaning, data type, length, format, and allowed values for
the primary data elements in the Computer Store Management System. This document provides an
organized view of key data elements for use in modeling and database design. Ideally, the Data
Dictionary should be maintained as a separate document for easy updates and potential reuse across
related projects.
A.​ Entity : Product
Description Data Type Length Allowed
Field Values
Name
Format
ProductID INT 10 Integer Auto-increme
Unique nt, Primary
identifier for Key
product

Name 100 Text Alphanumeric

Product name VARCHAR

Description TEXT 500 Text Alphanumeric

Brief
description of
product

TEXT 1000 Text Alphanumeric

Specifications Product
specifications

Category 50 Text Alphanumeric

Product VARCHAR
category

Price DECIMAL Decimal

Product price 8, 2 Positive
numbers
only
 INT 5 Integer
StockQuantity Available Non-negativ
stock count e integers

INT 10 Integer References

SupplierID Foreign key Supplier table
to Supplier

B.​ Entity : Customer

Description Format Allowed
Field Data Type Length Values
Name

INT 10 Integer
CustomerID Unique Auto-increme
identifier nt, Primary
for Key
customer

Name 100 Alphabetical

Customer VARCHAR Text
name
 ContactInfo VARCHAR 150
Contact Text Phone/email
details

Address TEXT 255

Customer Text Alphanumeric
address

LoyaltyPoints INT 5 Non-negative

Customer Integer integers
loyalty
points

C.​ Entity: Order

Description Format Allowed
Field Data Type Length Values
Name

10 Integer
OrderID Unique INT Auto-increm
identifier ent, Primary
for order Key

10 Integer
CustomerID Foreign key INT
to Customer
 References
Customer
table

DATE -
OrderDate Date of YYYY-M Valid dates
order M-DD only
creation

- Enum
Status Status of ENUM Pending,
the order Shipped,
Delivered

TotalAmount 10,2
Total order DECIMAL Decimal Positive
price numbers
only

PaymentMethod 50 Text Cash, Card,

Payment VARCHAR etc.
method
used

D.​ Entity : OrderItem

Description Length Format
Field Data Type Allowed
Name Values
 OrderItemID INT 10
Unique Integer Auto-increm
identifier for ent, Primary
order item Key

OrderID INT 10
Foreign key Integer References
to Order Order table

ProductID INT 10
Foreign key Integer References
to Product Product table

Quantity INT 5
Quantity of Integer Positive
product numbers
ordered only

8, 2 Decimal Positive
Price Price per DECIMAL numbers only
unit of
product

E.​ Entity: Promotion

 Description Length
Field Data Type Format Allowed
Name Values

PromotionID INT 10 Integer

Unique Auto-increme
identifier nt, Primary
for Key
promotion

Name 100 Text

Name of VARCHAR Alphanumeric
the
promotion

ENUM - Enum
DiscountType Type of Percentage,
discount Fixed Amount

DECIMAL 5, 2
DiscountValue Value of Decimal Positive
discount numbers only

StartDate DATE -
Promotion YYYY-M Valid dates
start date M-DD only
 EndDate DATE -
Promotion YYYY-M Valid dates
end date M-DD only

F.​ Entity : Return

Description Length Format
Field Data Type Allowed
Name Values

INT Integer
ReturnID Unique 10 Auto-increm
identifier ent, Primary
for return Key

OrderID Integer
Foreign key INT 10 References
to Order Order table

INT Integer
CustomerID Foreign key 10 References
to Customer Customer
table

ReturnDate DATE -
Date of YYYY-M Valid dates
return M-DD only
 RefundAmount Decimal
Amount DECIMAL 10, 2 Positive
refunded to numbers
customer only

Reason Text Alphanumeric

Reason for VARCHAR 255
return

This Data Dictionary provides a structured definition for each data field in the system. To ensure
maintainability and facilitate reuse across projects, it is advisable to store this Data Dictionary as
a separate document within the project’s documentation resources

4.3​ Reports

The Computer Store Management System generates various reports to support store
operations, inventory control, sales tracking, and customer management. This section outlines
the primary reports, their logical content, sorting, and totaling requirements. Detailed layout and
design will be addressed in the design stage.

ii.​ 4.3.1 Inventory Report

●​ Purpose: To provide a comprehensive view of stock levels, restock history, and low-stock alerts
for products.
●​ Content:
o​ Product ID, Name, Category, Current Stock Quantity, Reorder Threshold, Last Restocked
Date.
●​ Sort Sequence: Primarily sorted by Category, then by Product Name within each category.
●​ Totaling Levels: Totals per category (showing cumulative stock levels) and a grand total for all
products.
●​ Frequency: Generated daily and accessible on-demand for real-time stock updates.

iii.​ 4.3.2 Sales Report

●​ Purpose: To track sales performance over a specified period, providing insights into revenue and
best-selling products.
●​ Content:
o​ Order ID, Order Date, Customer ID, Total Order Amount, Payment Method, Itemized
Products Sold (Product ID, Quantity, Unit Price).
●​ Sort Sequence: Sorted by Order Date, with subtotaled sales per day and summarized sales for
the reporting period.
●​ Totaling Levels: Daily sales totals, weekly/monthly totals, and overall sales totals for the period.
●​ Frequency: Generated weekly, monthly, and on-demand for custom date ranges.

iv.​ 4.3.3 Customer Order History Report

●​ Purpose: To provide a detailed view of each customer’s purchase history for customer support
and loyalty tracking.
●​ Content:
o​ Customer ID, Customer Name, Order ID, Order Date, Itemized Products (Product ID,
Quantity, Price), Total Order Amount.
●​ Sort Sequence: Sorted by Customer ID, then by Order Date within each customer’s record.
●​ Totaling Levels: Totals for each customer (cumulative amount spent) and an overall total of all
customer orders in the report period.
●​ Frequency: Generated on-demand for specific customers as needed by Customer Support.

v.​ 4.3.4 Promotions Effectiveness Report

●​ Purpose: To assess the effectiveness of active promotions, showing sales performance during
promotional periods.
●​ Content:
o​ Promotion ID, Promotion Name, Discount Type and Value, Applicable Products, Total
Sales under Promotion, Promotion Start and End Dates.
●​ Sort Sequence: Sorted by Promotion Start Date, with an option to filter by active or completed
promotions.
●​ Totaling Levels: Sales totals for each promotion and overall total sales under promotions.
●​ Frequency: Generated monthly and at the conclusion of each promotion.

vi.​ 4.3.5 Returns and Refunds Report

●​ Purpose: To track returns and refunds, providing insights into customer return behavior and
financial impact.
●​ Content:
o​ Return ID, Order ID, Customer ID, Return Date, Items Returned (Product ID, Quantity),
Refund Amount, Reason for Return.
●​ Sort Sequence: Sorted by Return Date, with the option to filter by Customer ID or Product ID.
●​ Totaling Levels: Total number of items returned, total refund amounts, and summaries per
product category.
●​ Frequency: Generated monthly and on-demand for analysis.
Each report serves a distinct operational purpose, providing vital insights and supporting
decision-making. The detailed layout, formatting, and specific display requirements for each
report will be addressed during the design phase, where customization for readability and
functionality can be incorporated.

4.4​ Data Acquisition, Integrity, Retention, and Disposal

The Computer Store Management System acquires, maintains, and protects data essential for
managing inventory, orders, customer information, and promotions. This section outlines data
acquisition methods, integrity protection techniques, retention policies, and disposal processes,
ensuring data accuracy, security, and compliance.

vii.​ 4.4.1 Data Acquisition

●​ Manual Entry: Most data, such as product details, customer information, and promotions, is
entered manually by staff through the system interface. Staff is responsible for verifying the
accuracy of data before submission.
●​ Order and Transaction Data: Data related to orders, returns, and refunds is acquired in real-time
through sales and customer service interactions, ensuring up-to-date records of store
transactions.

viii.​ 4.4.2 Data Integrity Protection

●​ Validation Rules: Data fields, such as stock quantities, prices, and customer contact information,
are validated at the point of entry to prevent errors (e.g., negative quantities, invalid dates).
●​ Role-Based Access Control: Only authorized users can access or modify sensitive data, such as
customer information, product prices, and promotions. This prevents unauthorized
modifications and enhances data security.
●​ Regular Backups: Daily backups of the database are scheduled to capture all current data.
Backups are stored in secure local storage and periodically backed up to cloud storage for
disaster recovery.
●​ Checkpointing: Key system operations, like large inventory updates or bulk order processing,
include checkpoints, allowing for rollback in case of system failure.
●​ Audit Logging: System maintains logs of data modifications, especially for critical data fields like
inventory stock levels, order status, and customer account updates, to track changes and
maintain accountability.

ix.​ 4.4.3 Data Retention Policies

●​ Operational Data: All core operational data (e.g., product information, customer records, order
history) is retained as long as the data remains relevant to store operations. Order history and
customer data are maintained for at least two years to support customer service and loyalty
programs.
 ●​ Temporary and Cached Data: Cached data, such as session information or temporary files, is
cleared periodically, typically upon user logout or at the end of the day, to ensure system
efficiency and data security.
●​ Archived Data: Data older than two years, such as past orders or inactive promotions, is
archived. Archived data is accessible to the system only for historical reporting and can be
restored if required.
●​ Interim Backups: Interim backups, created during data migrations or major updates, are retained
until the successful completion of the process. These backups are deleted once integrity checks
confirm the stability of new data.

x.​ 4.4.4 Data Disposal

●​ Deleted Records: When a record is deleted (e.g., a product or customer account), it is marked as
"inactive" or "deleted" in the database to maintain referential integrity. Periodic review and
permanent deletion of these records are performed every six months.
●​ Residual Data: Residual data, such as residual cache files or temporary records, is cleared on a
regular schedule to maintain storage efficiency and data privacy.
●​ Data Sanitization: Sensitive data, such as customer contact information, is securely wiped from
the system before disposal or when no longer required by operational policy or regulations.

By adhering to these data acquisition, integrity, retention, and disposal practices, the Computer
Store Management System ensures that data remains accurate, secure, and relevant, supporting
reliable operations and compliance with data management policies.

5.​ External Interface Requirements

The Computer Store Management System interacts with users, external devices, and potentially
other software components to support in-store operations. This section outlines the
requirements for these external interfaces, ensuring the system communicates effectively with
users and compatible hardware and software.

5.1​ User Interfaces

The Computer Store Management System provides an intuitive and accessible user interface
for store staff to manage daily operations, including inventory control, order processing,
customer management, and promotions. This section outlines the logical characteristics of each
interface, including layout standards, common functions, and error handling. A detailed user
interface design will be documented in a separate UI specification.

xi.​ 5.1.1 General Layout and Navigation

●​ Main Menu: The main menu is a sidebar or top navigation bar, containing links to the primary
system functions: Inventory, Orders, Customers, Promotions, and Returns.
●​ Screen Layout: Each module’s main screen includes a search bar, a list view for displaying
records, and action buttons (e.g., Add, Edit, Delete) at the top or side of each record.
●​ Standard Buttons:
o​ Save: Saves changes to records. Available in forms and editable screens.
o​ Cancel: Discards any changes and returns the user to the previous screen.
o​ Search: Executes searches based on user-entered terms.
o​ Help: Provides access to a help screen with basic system instructions.
●​ Keyboard Shortcuts: Standard shortcuts for common actions, such as Ctrl+S for Save and Esc
for Cancel, will be enabled to improve user efficiency.

xii.​ 5.1.2 Module-Specific Interfaces

1.​ Inventory Management Interface

●​ Features:
o​ Product List View: Displays product details (ID, Name, Category, Stock Quantity, Price).
o​ Add Product: Opens a form to add new products, with fields for product name,
description, category, price, and stock.
o​ Edit Product: Allows users to modify existing product details. Editable fields include
price, stock level, and category.
o​ Low Stock Alerts: Highlights products with low stock levels in red or with an alert icon.
●​ Error Messages: Error messages appear if required fields are missing or invalid data is entered
(e.g., negative stock quantity).

2.​ Order Processing Interface

●​ Features:
o​ Order List View: Displays order details, including Order ID, Customer Name, Order Date,
and Status.
o​ Create Order: Opens a form for adding new orders. Includes customer selection, item
addition, and payment method.
o​ Update Status: Allows the user to change order status (Pending, Shipped, Delivered).
o​ Itemized View: Displays individual items in each order, including quantities and prices.
●​ Error Messages: If an invalid status transition occurs (e.g., setting "Delivered" before "Shipped"),
the system will show an error message explaining the issue.

3.​ Customer Management Interface

●​ Features:
o​ Customer List View: Lists all customers with details such as Customer ID, Name, Contact
Info, and Order History.
o​ Add/Edit Customer: Provides a form for entering or updating customer data, including
contact details and address.
o​ Order History: Accesses detailed order history for each customer, showing purchase
dates and items.
●​ Error Messages: Prompts appear if mandatory fields, like name or contact information, are left
blank.
 4.​ Promotions Management Interface

●​ Features:
o​ Promotion List View: Displays active and past promotions with details such as
Promotion Name, Discount Type, Value, and Validity Period.
o​ Create Promotion: Form for adding a new promotion, allowing selection of applicable
products/categories, discount type, and validity dates.
o​ Edit Promotion: Allows modification of existing promotions, including start/end dates
and discount values.
●​ Error Messages: Alerts when attempting to overlap promotions for the same products without
resolution, prompting user confirmation.

5.​ Returns and Refunds Interface

●​ Features:
o​ Return Request View: Lists all return requests with details on returned items, reason for
return, and refund amount.
o​ Process Return: Form to validate and finalize returns, including eligibility checks and
refund processing.
o​ Refund Status: Displays status of each refund (Pending, Approved, Processed).
●​ Error Messages: Alerts if return eligibility is not met, explaining the reason (e.g., outside return
period).

xiii.​ 5.1.3 Standard Functions and Messages

●​ Error Message Standards: Error messages appear in a consistent style across all screens, using
red text to highlight errors. Each error message provides clear guidance to the user, explaining
what went wrong and how to correct it.
●​ Confirmation Dialogs: Critical actions (e.g., deletion, status updates) prompt confirmation
dialogs to prevent accidental changes.
●​ User Help and Guidance: A Help button on each main screen links to a help section providing
guidance on navigating and using features.

The system’s interface is designed to be straightforward, with consistent visual elements and
interactive feedback, ensuring efficient and accurate user interactions. Detailed UI layouts,
including sample screens, will be provided in the user interface specification document.

5.2​ Software Interfaces

The Computer Store Management System integrates with several external software
components to manage data storage, POS transactions, and network operations. This section
details the interfaces with other software components, describing the purpose, data exchange
formats, communication methods, and requirements for each connection.

xiv.​ 5.2.1 Database Management System (DBMS)

●​ Component: MySQL or PostgreSQL (compatible versions)
●​ Purpose: To store and retrieve all system data, including inventory, customer records, orders,
returns, and promotions.
●​ Data Exchange:
o​ Input: CRUD operations from the system’s UI to create, update, delete, and retrieve
data.
o​ Output: Responses to queries for data retrieval, updates, and transactions.
o​ Data Format: Structured query language (SQL) queries and transactions.
●​ Communication Protocol: JDBC (Java Database Connectivity) for Java-based database
interaction.
●​ Nonfunctional Requirements:
o​ Service Levels: Response time for database queries should not exceed 2 seconds to
ensure seamless UI operation.
o​ Security Controls: All data transactions are encrypted, and only authorized system
components can access the DBMS.

xv.​ 5.2.2 Point of Sale (POS) System Integration

●​ Component: Existing POS software compatible with API or file-based integration (e.g., JSON,
CSV).
●​ Purpose: To synchronize transaction data between the POS and the management system,
ensuring accurate sales records and inventory updates.
●​ Data Exchange:
o​ Input: Transaction records, payment information, and inventory updates from the POS
system.
o​ Output: Updated inventory levels, order completion status.
o​ Data Format: JSON for API-based integrations; CSV or XML for file-based
exports/imports.
●​ Communication Protocol: REST API for real-time communication or periodic batch file
import/export.
●​ Nonfunctional Requirements:
o​ Frequency: Data synchronization occurs in real time or through periodic batch
processing every hour.
o​ Security Controls: Secure API keys or encrypted files for access control, ensuring only
verified data exchanges.

xvi.​ 5.2.3 Operating System

●​ Component: Windows 10 or later, macOS 10.15 or later, or Linux (compatible distributions)

●​ Purpose: To provide a compatible environment for running the Java-based application.
●​ Interaction: The operating system manages process control, memory allocation, and network
access for the application.
●​ Data Exchange:
o​ Input/Output: System requests for file storage, memory access, and network
communication.
●​ Nonfunctional Requirements:
 o​ Service Levels: The application must maintain stable operation, utilizing a minimal
resource footprint to avoid slowing other store operations.
o​ Security Controls: Role-based OS access to ensure only authorized users and services
can run or modify the application.

xvii.​ 5.2.4 Java Runtime Environment (JRE)

●​ Component: Java SE 17 or later

●​ Purpose: To execute the application code, providing a runtime environment for the system's Java
components.
●​ Interaction: The system relies on the JRE for managing memory, handling threads, and executing
Java classes.
●​ Data Exchange:
o​ Internal Communication: Internal data handling, object serialization, and memory
management.
●​ Nonfunctional Requirements:
o​ Performance: The JRE must provide sufficient memory and processing capacity to
support real-time transactions.
o​ Security: All system modules and libraries must be compatible with JRE security updates
to prevent vulnerabilities.

xviii.​ 5.2.5 External Backup Solution (Cloud or Local Backup Service)

●​ Component: Cloud-based storage solution (e.g., AWS S3, Google Cloud Storage) or a secure local
backup server.
●​ Purpose: To ensure data redundancy and recovery in case of system failure, protecting critical
information like order records and customer data.
●​ Data Exchange:
o​ Input: Scheduled database backups, typically in SQL dump format or JSON/XML exports.
o​ Output: Restored backups if required for data recovery.
●​ Data Format: Compressed database files or encrypted archives in a standardized format (e.g.,
.sql, .zip).
●​ Nonfunctional Requirements:
o​ Frequency: Backups are performed daily; incremental backups may occur hourly.
o​ Security Controls: Backups are encrypted during transfer and storage to prevent
unauthorized access.

xix.​ 5.2.6 Reporting and Analytics Tool (Optional Future Integration)

●​ Component: Optional analytics tool for advanced reporting (e.g., Tableau, Power BI).
●​ Purpose: To generate detailed reports and visual analytics from system data for business
insights.
●​ Data Exchange:
o​ Input: Data extracts from the main database, including sales data, customer records, and
inventory trends.
o​ Output: Visual reports and dashboards for analysis.
●​ Data Format: JSON, CSV, or direct SQL queries for data retrieval.
 ●​ Communication Protocol: JDBC or API-based data access.
●​ Nonfunctional Requirements:
o​ Performance: Analytics queries should not interfere with real-time system operations;
reporting jobs run during off-peak hours.
o​ Security Controls: Restricted access to analytics data, with role-based permissions for
report access.

xx.​ 5.2.7 Network Protocols and Security

●​ Component: TCP/IP, SSL/TLS Encryption

●​ Purpose: To facilitate secure data exchange between workstations and the server within the
in-store network.
●​ Data Exchange:
o​ Input/Output: Data requests and responses between client workstations and the server.
●​ Nonfunctional Requirements:
o​ Service Levels: Real-time data exchange must have latency of less than 200 ms.
o​ Security: All network communications are encrypted using SSL/TLS to prevent
interception.

These software interfaces ensure that the Computer Store Management System can effectively
manage and communicate with other software components, maintaining secure, reliable
operations within the store environment. Detailed configuration and compatibility testing will be
completed during the implementation phase to validate each interface.

5.3​ Hardware Interfaces

The Computer Store Management System interfaces with several in-store hardware devices to
support operations such as inventory management, order processing, and receipt printing. This
section describes the types of hardware supported, data and control interactions, communication
protocols, input/output formats, and any timing considerations.

xxi.​ 5.3.1 Barcode Scanner

●​ Supported Device Types: Handheld barcode scanners compatible with USB or wireless
connections.
●​ Purpose: To facilitate quick product identification during inventory management and checkout
by scanning product barcodes.
●​ Data and Control Interactions:
o​ Input: Scanned barcode data, representing a unique product ID.
o​ Output: The barcode scanner sends the scanned data directly to the system, populating
the product field in the inventory or checkout screen.
o​ Format: Numeric or alphanumeric string that corresponds to a ProductID in the system’s
database.
 o​ Valid Values: Only valid ProductIDs that exist in the database; otherwise, the system
prompts an error for invalid or unrecognized barcodes.
●​ Communication Protocol: USB HID (Human Interface Device) protocol for plug-and-play
compatibility.
●​ Timing Considerations: Real-time entry; barcode data should be processed immediately upon
scan, with a response time under 200 ms.

xxii.​ 5.3.2 Receipt Printer

●​ Supported Device Types: Thermal or inkjet receipt printers compatible with USB or Bluetooth
connections.
●​ Purpose: To generate printed receipts for customers after a sale, including order details, prices,
discounts, and contact information for returns.
●​ Data and Control Interactions:
o​ Input: Formatted receipt data, generated by the system upon order completion.
o​ Output: Printed receipt containing order details, customer information, and return
instructions.
o​ Format: Structured text or PDF format with order ID, item list, quantities, prices, tax,
total amount, and store branding.
o​ Valid Values: Any completed order is eligible for receipt printing.
●​ Communication Protocol: Standard USB or Bluetooth printing protocols, depending on the
printer model.
●​ Timing Considerations: Receipts should print within 2-5 seconds of order completion to avoid
customer wait times.

xxiii.​ 5.3.3 POS Terminal (Optional Integration)

●​ Supported Device Types: Standard POS terminals used in-store for processing payments.
●​ Purpose: To exchange transaction data for payment processing and order confirmation.
●​ Data and Control Interactions:
o​ Input: Transaction information, including order ID, total amount, and payment type.
o​ Output: Payment confirmation, transaction status (Approved, Declined), and, if
necessary, additional payment details.
o​ Format: JSON or XML for API-based data exchange; CSV for batch processing if API
integration is unavailable.
o​ Valid Values: Numeric and alphanumeric strings for transaction IDs, order totals, and
payment statuses.
●​ Communication Protocol: REST API or file-based batch data transfer.
●​ Timing Considerations: Transactions must be processed in under 5 seconds to avoid customer
delays; system retries once if the initial transaction fails.

xxiv.​ 5.3.4 Customer Display Screen (Optional)

●​ Supported Device Types: LCD or LED customer-facing displays connected to the POS
workstation.
●​ Purpose: To display real-time order information, pricing, and promotions to customers at
checkout.
 ●​ Data and Control Interactions:
o​ Input: Live data feed from the POS system showing order items, quantities, subtotal, and
applicable discounts.
o​ Output: Displayed list of purchased items with running total, discounts, and promotional
information.
o​ Format: Simple text or graphic display, refreshed dynamically as items are added.
o​ Valid Values: Product names, prices, and promotional details are limited to valid
characters and supported resolution.
●​ Communication Protocol: HDMI or VGA, or via USB connection to the POS terminal, depending
on the display device.
●​ Timing Considerations: Information should update in real time (under 100 ms delay) as items
are scanned.

xxv.​ 5.3.5 Cash Drawer (Optional)

●​ Supported Device Types: Electronic cash drawers connected via USB or directly through the
receipt printer.
●​ Purpose: To securely store cash transactions and open automatically during cash payments.
●​ Data and Control Interactions:
o​ Input: Trigger command from the POS system at the end of a cash transaction.
o​ Output: Open command sent to the cash drawer.
o​ Format: Control signal to trigger drawer opening.
o​ Valid Values: The drawer only opens upon a confirmed cash transaction.
●​ Communication Protocol: Proprietary or standard USB signal triggered by the POS terminal or
receipt printer.
●​ Timing Considerations: The cash drawer should open instantly upon completion of a cash
transaction (within 1 second).

These hardware interfaces ensure the Computer Store Management System can interact
effectively with essential in-store devices, supporting efficient checkout, inventory management,
and customer service processes. Detailed integration requirements, including driver installations
and device-specific configurations, will be addressed in a separate hardware interface
specification if necessary.

5.4​ Communications Interfaces

The Computer Store Management System requires several communication functions to

facilitate data exchange within the store network and, if applicable, to secure external systems for
backup and data storage. This section outlines the required communication protocols, message
formatting, security considerations, and constraints.

xxvi.​ 5.4.1 Internal Network Communication

●​ Purpose: To enable real-time communication between the system’s client workstations and the
central server for data transactions related to inventory, orders, and customer information.
●​ Protocol: TCP/IP over the store’s local area network (LAN).
●​ Message Formatting: All data exchanges are formatted in JSON for simplicity and compatibility,
allowing for easy parsing and processing by the system.
●​ Security: SSL/TLS encryption is required for all network communications to ensure data privacy
and prevent unauthorized interception.
●​ Data Transfer Rates: The network should support a minimum data transfer rate of 1 Mbps to
allow seamless real-time data exchange between devices.
●​ Handshaking and Synchronization: Handshaking mechanisms are in place to ensure reliable data
transfer, with automatic retries for incomplete or interrupted transmissions.
●​ Constraints: This communication is limited to in-store devices on the secured LAN, with no
external network access allowed.

xxvii.​ 5.4.2 Cloud-Based Backup Communication (Optional)

●​ Purpose: To transfer backup files to a secure cloud storage service for data redundancy and
recovery.
●​ Protocol: HTTPS for secure file transfers over the internet.
●​ Message Formatting: Backup files are formatted as compressed SQL dumps or encrypted ZIP
files to minimize data size and ensure security.
●​ Security: Backups are encrypted using AES-256 encryption before transfer, and communication is
secured with SSL/TLS to protect data in transit.
●​ Data Transfer Rates: Requires a stable internet connection with a minimum upload speed of 512
Kbps, particularly for larger data transfers during full backups.
●​ Handshaking and Synchronization: The backup process includes checksums to verify file
integrity upon upload and automatic retry if a transfer fails.
●​ Constraints: Only incremental backups are transferred daily to minimize data transfer, with full
backups scheduled weekly.

xxviii.​ 5.4.3 Email Notification (Optional Future Feature)

●​ Purpose: To send email notifications to customers for order confirmations, promotional offers,
and support updates.
●​ Protocol: SMTP (Simple Mail Transfer Protocol) for outgoing mail.
●​ Message Formatting: Emails are formatted as HTML to support rich text, with a plain text
alternative for compatibility.
●​ Security: Emails are sent over SSL/TLS to ensure secure transmission. No sensitive data (e.g.,
payment details) is included in email content to avoid security risks.
●​ Data Transfer Rates: Minimal bandwidth requirements as email data packets are generally small.
●​ Constraints: No attachments are sent with these emails to prevent unnecessary bandwidth
usage and ensure compatibility with customer inboxes.

xxix.​ 5.4.4 POS System Communication (Optional)

●​ Purpose: To synchronize data between the store’s POS system and the Computer Store
Management System for real-time inventory and order status updates.
 ●​ Protocol: REST API over HTTP/HTTPS for real-time communication; batch CSV or JSON file
exchange for asynchronous communication.
●​ Message Formatting: JSON format for API requests and responses, with CSV as an alternative for
batch processing.
●​ Security: Communication over HTTPS with API keys for authentication, and data payload
encryption as required by the POS system’s capabilities.
●​ Data Transfer Rates: Real-time updates should be nearly instantaneous (under 1 second) to
ensure inventory remains accurate.
●​ Constraints: Communication is limited to data synchronization tasks, and the POS must support
required API endpoints or file exchange formats.

xxx.​ 5.4.5 Reporting System Integration (Optional Future Feature)

●​ Purpose: To provide data to an external reporting or business intelligence system for advanced
analytics.
●​ Protocol: API-based data transfer using REST over HTTP/HTTPS, or direct SQL queries if allowed
by the reporting system.
●​ Message Formatting: JSON format for API-based communication, or direct table access for SQL
queries.
●​ Security: Access restricted to specific reporting user roles with SSL/TLS encryption for secure
communication.
●​ Data Transfer Rates: Should support batch transfers at off-peak times to avoid impacting system
performance.
●​ Constraints: Only non-sensitive, aggregated data is shared externally to maintain data privacy.

These communication interfaces support secure and reliable data exchange within the Computer
Store Management System and, where applicable, with optional external systems such as cloud
storage or POS systems. Detailed configuration specifications, including API keys,
authentication, and encryption protocols, will be documented in a separate communications
interface specification if required.

6.​ Quality Attributes

6.1​ Usability

The Computer Store Management System is designed to be user-friendly, with specific

usability requirements to ensure that store staff can efficiently manage daily operations, reduce
errors, and provide smooth customer service. Usability requirements are focused on ease of
learning, ease of use, error handling, efficiency, accessibility, and conformity to user interface
standards.

xxxi.​ 6.1.1 Ease of Use

●​ Intuitive Layout: The system’s interface follows a straightforward, consistent layout across all
modules, with clear labels, intuitive icons, and readily accessible functions. Navigation menus,
buttons, and links are structured logically to minimize user confusion.
●​ Minimal Steps for Core Tasks: Frequently performed tasks, such as order processing, inventory
updates, and customer management, require minimal steps, ensuring staff can complete actions
quickly.
●​ Standardized Screen Design: All screens use a consistent layout with common buttons (e.g.,
Save, Cancel, Help) in fixed locations, making it easy for users to remember locations and
actions.

xxxii.​ 6.1.2 Ease of Learning

●​ Simple Onboarding: New users should be able to navigate and use basic functions with minimal
training due to the system’s logical structure and consistent design.
●​ Tooltips and Labels: Tooltips and field descriptions provide contextual assistance, especially for
new or infrequent users, allowing them to understand actions without additional guidance.
●​ Onboarding Guide: An onboarding guide or tutorial is available within the Help menu, covering
basic functions such as order processing, product lookup, and inventory management.

xxxiii.​ 6.1.3 Memorability

●​ Consistent Navigation: Primary functions (Inventory, Orders, Customers, Promotions, Returns)

are accessible from a persistent main menu. Consistent placement of navigation elements
supports memorability, allowing users to quickly regain proficiency even after short absences.
●​ Shortcut Keys: Keyboard shortcuts (e.g., Ctrl+S for Save, Esc for Cancel) are available for core
actions, helping regular users navigate the system more quickly.

xxxiv.​ 6.1.4 Error Avoidance, Handling, and Recovery

●​ Data Validation: Form fields have built-in validation to prevent common errors, such as entering
negative stock quantities or incorrect dates.
●​ Error Messaging: Error messages are clear, concise, and provide actionable guidance on how to
correct the issue, reducing user frustration.
●​ Undo and Confirmations: Users are prompted with confirmation dialogs for critical actions (e.g.,
deleting records or processing refunds), with an option to undo the last action if they realize a
mistake.
●​ Automatic Save for Drafts: If a form is incomplete or the system times out, a draft is
automatically saved, allowing users to recover and complete the form without losing progress.

xxxv.​ 6.1.5 Efficiency of Interactions

●​ Quick Search and Filters: Users can quickly locate records using a global search bar and specific
filters, such as searching for products by category or orders by date range, to minimize time
spent browsing.
●​ Batch Actions: The system allows batch processing of common tasks, such as updating multiple
product records or applying a promotion to several products simultaneously, reducing redundant
actions.
 ●​ Real-Time Updates: Changes in inventory, order status, and customer information are reflected
in real-time, ensuring that all users work with the latest information.

xxxvi.​ 6.1.6 Accessibility

●​ Keyboard Navigation: The system is fully navigable using a keyboard, supporting staff who may
prefer or require keyboard-only interactions.
●​ Screen Reader Compatibility: The interface is compatible with screen readers, ensuring
accessibility for users with visual impairments. All buttons and labels are equipped with
descriptive text for assistive technologies.
●​ High-Contrast Mode: A high-contrast display option is available to improve visibility for users
with visual impairments or low vision.

xxxvii.​ 6.1.7 Ergonomics

●​ Large Button Sizes and Click Areas: Buttons and clickable elements are large enough to support
easy selection, reducing user fatigue and minimizing accidental selections.
●​ Reduced Visual Clutter: The system design limits the amount of information displayed on each
screen, using collapsible sections and minimal text to reduce cognitive load.
●​ Responsiveness: The application is optimized to respond quickly, with minimal loading times,
supporting efficient interactions that do not frustrate or slow down the user.

xxxviii.​ 6.1.8 Conformance to Standards

●​ UI Design Standards: The interface follows established design standards (e.g., Material Design,
Windows Fluent Design) to ensure consistent, recognizable visual elements.
●​ Accessible Color Schemes: The system uses a color scheme with sufficient contrast ratios,
adhering to WCAG 2.1 standards to ensure readability.
●​ Form and Input Standards: Form fields, buttons, and icons are designed according to established
UI conventions, ensuring ease of use and clarity.

These usability requirements are aimed at providing an accessible, efficient, and error-resistant
interface that enhances the productivity of store staff and contributes to a high-quality customer
experience. Detailed user interface specifications, including mockups and visual standards, will
be developed during the design phase.

6.2​ Performance

The Computer Store Management System is designed to support efficient in-store operations,
and its performance requirements ensure that the system functions smoothly during peak usage
periods. Specific performance metrics are outlined below for key operations to ensure reliable
and responsive performance.

xxxix.​ 6.2.1 System Startup and Login

●​ Requirement: The system should load and be ready for use within 10 seconds after startup on
in-store workstations.
●​ Login Response Time: User login should complete within 2 seconds after credentials are
entered.
●​ Frequency: Required every time a user initiates the application.

xl.​ 6.2.2 Data Retrieval and Display

●​ Inventory Lookup:
o​ Requirement: The system should retrieve and display inventory records, including search
results or filtered data, within 1 second.
o​ Frequency: Frequent; used for product lookups, availability checks, and inventory
management.
●​ Customer and Order History Retrieval:
o​ Requirement: Customer records and order history should be retrieved and displayed
within 2 seconds of a search query.
o​ Frequency: Frequent; accessed during order processing, returns, and customer support
interactions.

xli.​ 6.2.3 Order Processing and Checkout

●​ Order Submission:
o​ Requirement: Order processing, including payment authorization and inventory
adjustment, should complete within 3 seconds after submission.
o​ Frequency: Frequent; performed for every completed customer transaction.
●​ Receipt Printing:
o​ Requirement: Receipt generation and sending data to the printer should take no more
than 2 seconds after order completion.
o​ Frequency: Performed with every checkout transaction involving a physical receipt.

xlii.​ 6.2.4 Inventory Management Operations

●​ Product Add/Update:
o​ Requirement: Adding or updating product details in the inventory should complete
within 2 seconds per action.
o​ Frequency: Moderate; performed during restocking or product updates.
●​ Batch Update for Multiple Products:
o​ Requirement: Batch updates (e.g., bulk restock or price changes for multiple products)
should complete within 5 seconds for up to 50 records.
o​ Frequency: Occasional; used for large-scale inventory changes.

xliii.​ 6.2.5 Promotion Application

●​ Promotion Update:
o​ Requirement: Updating or adding a promotion should propagate to all applicable
products within 5 seconds of saving.
o​ Frequency: Occasional; typically done at the start or end of a promotional period.
●​ Discount Calculation:
o​ Requirement: Promotional discounts should apply and update order totals instantly
(within 1 second) during order entry.
o​ Frequency: Frequent during checkout, especially during promotional events.

xliv.​ 6.2.6 Return and Refund Processing

●​ Return Request Processing:

o​ Requirement: Processing a return request, including updating inventory and refund
calculation, should complete within 3 seconds.
o​ Frequency: Moderate; performed as needed for returns and exchanges.
●​ Refund Transaction:
o​ Requirement: Refund transactions should be processed and confirmed within 2 seconds
of submission.
o​ Frequency: Moderate; performed in conjunction with return processing.

xlv.​ 6.2.7 Reporting

●​ Standard Report Generation:

o​ Requirement: Common reports (e.g., daily sales, inventory summaries) should generate
within 5 seconds.
o​ Frequency: Daily or weekly; run for performance tracking and inventory management.
●​ Custom Date-Range Reports:
o​ Requirement: Reports with custom date ranges (e.g., monthly sales report) should
generate within 10 seconds.
o​ Frequency: Occasional; run for financial summaries or specific analysis.

xlvi.​ 6.2.8 Backup and Recovery

●​ Data Backup:
o​ Requirement: Daily backups should complete within 10 minutes, with minimal impact
on active operations.
o​ Frequency: Performed nightly or during off-hours.
●​ Data Recovery:
o​ Requirement: Recovery of a full backup should be achievable within 30 minutes to
restore the system after a failure.
o​ Frequency: Rare; only required in case of data loss or corruption.

xlvii.​ 6.2.9 Network Communication

●​ Response Time for Database Queries:

o​ Requirement: Database query response time should not exceed 1 second for standard
operations, ensuring that all retrievals are real-time.
o​ Frequency: Continuous; every time data is requested from the database.
●​ API Communication with POS:
o​ Requirement: Data synchronization with the POS system (if implemented) should occur
within 1 second per transaction for real-time updates.
 o​ Frequency: Continuous for transactions, especially during high-traffic periods.

These performance requirements ensure the Computer Store Management System maintains
efficiency and responsiveness, even under peak usage, supporting a seamless experience for store
staff and customers. Monitoring and optimization will be performed regularly to maintain these
standards.

6.3​ Security

The Computer Store Management System enforces stringent security measures to protect
sensitive information, maintain data integrity, and ensure access control. These security
requirements cover data protection, role-based access, regulatory compliance, and system
resilience, conforming to relevant business rules and privacy regulations.

xlviii.​ 6.3.1 Access Control

●​ Role-Based Access: Access to system functions is restricted by role, with Staff having access to
core functionalities (e.g., order processing, inventory management), while the Owner has full
access, including sensitive functions such as refunds and reporting.
●​ Authentication: All users must authenticate with unique login credentials. Multi-factor
authentication (MFA) is recommended for access to sensitive data and administrative functions.
●​ Session Management: Users are automatically logged out after a set period of inactivity (e.g., 15
minutes) to prevent unauthorized access on unattended workstations.

xlix.​ 6.3.2 Data Security

●​ Data Encryption:
o​ In Transit: All data transferred over the network is encrypted using SSL/TLS to prevent
interception and unauthorized access.
o​ At Rest: Sensitive data, including customer contact information and payment-related
data, is encrypted in the database to protect against unauthorized access.
●​ Data Masking: Sensitive information, such as customer contact details, is partially masked in all
non-essential views to reduce exposure, displaying only necessary details for operational tasks.
●​ Database Access Control: Only authorized applications and users can access the database.
Access credentials are stored securely and are not hardcoded in the application.

l.​ 6.3.3 Privacy Compliance

●​ Data Minimization: The system only collects and stores data necessary for business operations,
adhering to the principles of data minimization.
●​ Regulatory Compliance: The system must comply with applicable data privacy laws (e.g., GDPR,
CCPA) to protect customer data, including the right to access, correct, or delete personal data
upon request.
●​ Audit Logging: An audit trail logs all access and modification to sensitive data, including who
accessed it, what was changed, and when the action occurred. Logs are stored securely and
retained for a minimum of one year for compliance and troubleshooting.

li.​ 6.3.4 Physical Security

●​ Workstation Security: Physical access to in-store workstations is restricted to authorized

personnel, with locked rooms or stations as required in the store’s security policies.
●​ Server Room Access: If a dedicated server is used, physical access to the server room is
restricted to authorized IT staff. Surveillance and access logs should be maintained.

lii.​ 6.3.5 Data Backup and Recovery Security

●​ Encrypted Backups: All backup files, whether stored locally or on the cloud, are encrypted with
AES-256 to protect against unauthorized access.
●​ Backup Access Control: Only authorized personnel can access backups. Access permissions are
managed through role-based access control.
●​ Secure Disposal: Backups older than the retention policy are securely deleted, ensuring no
residual data remains accessible.

liii.​ 6.3.6 Network Security

●​ Firewalls and Intrusion Detection: Firewalls are in place to control access to the system’s
network. Intrusion detection systems (IDS) monitor network traffic for suspicious activity and
alert administrators to potential breaches.
●​ Internal LAN Segmentation: The network segments POS terminals, workstations, and server
connections to minimize cross-network vulnerabilities. Only necessary connections are allowed
between segments.
●​ VPN for Remote Access: Any remote access to the system, such as for administrative tasks or
support, requires a secure VPN connection, ensuring encrypted communication.

liv.​ 6.3.7 Security Testing and Monitoring

●​ Regular Security Testing: Security assessments, including penetration testing and vulnerability
scanning, are conducted regularly to identify and mitigate security risks.
●​ System Monitoring: Continuous monitoring of system activity is in place to detect unauthorized
access attempts or anomalous behavior. Any suspicious activity triggers alerts for immediate
review.
●​ Patch Management: The system and all third-party components (e.g., JRE, database) must be
kept up to date with security patches, ensuring protection against known vulnerabilities.

lv.​ 6.3.8 User Education and Training

●​ Security Awareness: Staff are educated on best security practices, such as password
management and recognizing phishing attempts, to reduce the risk of human error leading to
security breaches.
 ●​ Data Handling Training: Staff handling sensitive customer information receive training on secure
data handling practices and compliance requirements.

These security requirements are designed to safeguard the Computer Store Management
System against unauthorized access, data breaches, and operational disruptions, ensuring
compliance with privacy laws and corporate policies. Detailed security protocols and regular
assessments will ensure ongoing system resilience and data protection.

6.4​ Safety

The Computer Store Management System has safety requirements aimed at preventing data
loss, financial discrepancies, and operational disruptions that could affect store functionality.
While the system does not involve physical risks, safeguards are in place to ensure data integrity,
avoid financial errors, and maintain secure, stable operations.

lvi.​ 6.4.1 Data Loss Prevention

●​ Automated Backups: The system performs daily automated backups of critical data (inventory
records, customer orders, financial transactions). Backup data is stored securely and encrypted,
with redundancy measures to prevent data loss from hardware failures.
●​ Incremental Backups: Hourly incremental backups capture recent changes without disrupting
performance, allowing data recovery to specific points throughout the day.
●​ Data Recovery: A recovery process allows quick restoration from recent backups in case of
system failure, with a goal of data recovery within 30 minutes to minimize operational
downtime.

lvii.​ 6.4.2 Financial Data Integrity

●​ Transaction Verification: Every financial transaction, such as sales and refunds, undergoes a
verification check to ensure accuracy in calculations, item pricing, and discounts applied. Any
discrepancy triggers an alert to the user, prompting review before completion.
●​ Audit Logs for Financial Transactions: Detailed logs are maintained for all transactions, capturing
changes in real-time. These logs provide traceability to detect and investigate any errors or
unusual activity.
●​ Error Prevention for Refunds: Refund transactions require a secondary confirmation step to
prevent accidental refunds. Once processed, refunds are logged with detailed records for
accountability and review.

lviii.​ 6.4.3 System Stability and Operational Continuity

●​ Graceful Error Handling: The system is designed to handle unexpected errors without crashing.
Any error or crash results in an automatic rollback of the last transaction or operation, ensuring
no partial or inconsistent data remains.
 ●​ Data Validation Checks: Data fields, such as stock quantities, prices, and customer contact
information, undergo validation checks to prevent erroneous entries that could disrupt
operations (e.g., negative quantities, invalid dates).
●​ Safe Mode for Recovery: In the event of a critical failure, the system has a “safe mode” that
allows limited functionality, enabling basic operations such as inventory lookup and order
processing while the full system is restored.

lix.​ 6.4.4 Prevention of Unauthorized Actions

●​ Access Control for Critical Actions: Sensitive actions, such as deleting records, issuing refunds, or
modifying pricing, are restricted to authorized users. A confirmation prompt is required before
completing these actions to prevent accidental or unauthorized operations.
●​ Restrictions on Data Deletion: Critical data, such as customer order history and transaction
records, cannot be deleted from the system. Instead, records are archived, preserving data
integrity and preventing accidental data loss.
●​ Role-Based Function Limitation: Staff roles limit access to high-risk functions, such as modifying
inventory levels or accessing financial reports, preventing accidental misuse or harmful changes.

lx.​ 6.4.5 Compliance with Safety Policies and Certifications

●​ Data Protection Compliance: The system complies with data protection policies that prevent
misuse of sensitive information, such as personal customer details, thereby avoiding
reputational and legal damage.
●​ Financial Reporting Standards: The system generates financial reports that conform to retail
reporting standards, ensuring data accuracy and reliability for tax and auditing purposes.

lxi.​ 6.4.6 User Safety Education

●​ Training on Safe Data Handling: Staff members are trained on proper handling of sensitive data
and transaction procedures to prevent errors that could impact operational safety.
●​ Alert Notifications for High-Risk Actions: Users are alerted when performing actions that could
impact financial or operational safety, such as bulk updates, ensuring that such actions are
performed intentionally.

lxii.​ 6.4.7 Safety Precautions for Network and Power Failures

●​ Uninterruptible Power Supply (UPS): If required by store policy, servers hosting the system can
be connected to a UPS to prevent data loss or corruption during power outages.
●​ Network Outage Handling: In case of network interruptions, the system stores in-progress
transactions locally, synchronizing with the central server once connectivity is restored, ensuring
no data is lost.

These safety requirements ensure that the Computer Store Management System operates
securely and reliably, minimizing the risk of data loss, financial discrepancies, or unauthorized
actions. The system's design includes multiple layers of safeguards, supporting operational
continuity and compliance with data protection standards.
6.5​ Additional product quality

This section describes quality attributes that are critical for the Computer Store Management
System, providing specific, measurable goals for availability, reliability, scalability,
modifiability, interoperability, and robustness. These attributes help ensure that the system meets
the expectations of both customers and developers, supporting smooth and secure store
operations.

lxiii.​ 6.5.1 Availability

●​ Requirement: The system must be available 99.9% of operational hours, allowing downtime of
no more than 1 hour per month during scheduled business hours.
●​ Monitoring: Availability will be monitored continuously, with alerts sent to administrators for
any unplanned downtime.
●​ Priority: High, as downtime directly impacts sales and customer service.

lxiv.​ 6.5.2 Reliability

●​ Requirement: The system should maintain 99.5% accuracy in transaction and inventory data to
ensure that sales, orders, and inventory levels reflect real-time information.
●​ Error Detection and Correction: Any discrepancies detected in inventory or transaction records
should trigger an automatic correction alert, allowing staff to investigate and resolve within 30
minutes.
●​ Priority: High, as data reliability is essential for accurate inventory management and order
processing.

lxv.​ 6.5.3 Scalability

●​ Requirement: The system must support up to 10,000 products, 5,000 customer records, and
500 concurrent transactions without impacting performance or response time.
●​ Scalability Plan: Future versions of the system should allow for modular expansion, enabling the
addition of features such as advanced reporting or e-commerce integration.
●​ Priority: Medium, to accommodate potential growth in data volume as the store expands or
opens additional locations.

lxvi.​ 6.5.4 Modifiability

●​ Requirement: System components should be modular, allowing for new features or updates to
be added with minimal impact on existing functionality.
●​ Change Management: Code changes must undergo testing in a staging environment before
deployment, ensuring compatibility with existing features.
●​ Priority: Medium, as future changes may include integrating additional functionalities such as
analytics or marketing features.

lxvii.​ 6.5.5 Interoperability

●​ Requirement: The system must seamlessly interact with external POS systems and database
platforms (e.g., MySQL, PostgreSQL) via REST API or file-based data exchange formats (JSON,
CSV).
●​ Data Mapping and Conversion: Data exchanged between systems should be mapped correctly,
with conversion protocols in place to handle format differences.
●​ Priority: High, to ensure smooth data exchange and synchronization between critical in-store
systems.

lxviii.​ 6.5.6 Robustness

●​ Requirement: The system should handle unexpected inputs or operational interruptions without
crashing or data loss, automatically recovering from errors where possible.
●​ Fault Tolerance: In the event of a system error, the application should log the incident, rollback
incomplete transactions, and continue to function for other operations.
●​ Priority: High, especially during peak hours or high-volume transactions.

lxix.​ 6.5.7 Portability

●​ Requirement: The system must be portable across operating systems (Windows 10 or later,
macOS 10.15 or later, and compatible Linux distributions) without requiring significant changes
in code or configuration.
●​ Environment Testing: Portability will be validated through testing on multiple platforms to
confirm compatibility with system requirements.
●​ Priority: Medium, as store setups may vary in operating systems used on staff workstations and
servers.

lxx.​ 6.5.8 Verifiability

●​ Requirement: All system functions, including transaction processing, inventory management,

and data security, should be verifiable through automated tests, logs, and audits.
●​ Verification Tools: Regular testing (unit, integration, and regression) will be performed to verify
that system requirements are met, with results stored in an audit log.
●​ Priority: High, especially for compliance with data security standards and business requirements.

lxxi.​ Prioritization of Attributes

1.​ Security and Reliability are prioritized over other attributes, ensuring that the system protects
data integrity and supports accurate daily operations.
2.​ Availability and Robustness are next in priority, ensuring that the system remains operational
during business hours and can handle unexpected inputs.
3.​ Interoperability and Scalability are also high priorities, as they ensure that the system can
expand to meet growing business needs and work seamlessly with other in-store systems.
4.​ Modifiability and Portability are important but have a lower priority in the current version, as
major changes and relocations are not anticipated frequently.
These quality attributes guide development and testing to ensure that the system is robust,
adaptable, and well-suited for the demands of a busy retail environment.

7.​ Internationalization and Localization Requirements

lxxii.​ 7.1 Language and Character Set

●​ Language Support: The system interface and all user-facing text should be available in
Vietnamese, including menus, labels, error messages, and notifications.
●​ Character Set: The system must support UTF-8 encoding to properly display Vietnamese
diacritics and special characters.
●​ Spellings and Terms: Vietnamese terminology should be used consistently. For example, use
"Khách hàng" for "Customer" and "Đơn hàng" for "Order".

lxxiii.​ 7.2 Currency and Financial Data

●​ Currency Symbol: The system should display the Vietnamese Dong currency symbol (₫) for all
prices, totals, and financial data.
●​ Currency Formatting: Prices and monetary values should be displayed without decimal points
(e.g., "1.000.000 ₫" instead of "1,000,000.00") as is customary in Vietnam.
●​ Exchange Rates: If currency conversion is required for reports or other features, the system
should pull updated rates from a trusted source to ensure accurate conversions.

lxxiv.​ 7.3 Date, Time, and Number Formatting

●​ Date Format: All dates should be displayed in DD/MM/YYYY format, as is standard in Vietnam.
For example, "31/12/2024" instead of "12/31/2024".
●​ Time Format: Times should be displayed in 24-hour format (e.g., "14:30" instead of "2:30 PM").
●​ Number Formatting: Large numbers should use periods as thousand separators (e.g.,
"1.000.000" instead of "1,000,000") to align with Vietnamese standards.

lxxv.​ 7.4 Address and Phone Number Formatting

●​ Address Structure: Vietnamese addresses typically follow the order: House Number, Street,
Ward, District, City/Province. The system should allow fields to accommodate this format.
●​ Phone Number Format: Vietnamese phone numbers should be formatted as (0x) xxxx xxxx for
landlines or 09x xxxx xxxx for mobile numbers. The system should validate phone numbers
according to these formats and allow for optional country code (+84).

lxxvi.​ 7.5 Time Zone and Regional Settings

●​ Time Zone: The system should default to the Indochina Time Zone (ICT, UTC+7) and allow for
time-sensitive features (e.g., promotions, order timestamps) to be displayed and managed
accurately within this time zone.
●​ Regional Holidays: The system should account for Vietnamese national holidays (e.g., Tết
Nguyên Đán, National Day) in any scheduling, reporting, or promotional planning modules.
 lxxvii.​ 7.6 Units of Measurement

●​ Weight and Dimensions: Use the metric system for weights and measures, displaying items in
kilograms (kg) for weight and centimeters (cm) for dimensions where applicable.
●​ Temperature: If temperature readings are required (e.g., for certain products), temperatures
should be displayed in degrees Celsius (°C).

lxxviii.​ 7.7 Legal and Compliance Requirements

●​ Invoice and Receipt Requirements: Invoices and receipts should comply with local regulations,
including showing VAT where applicable and using the Vietnamese language.
●​ Data Privacy: Compliance with Vietnamese data protection laws (e.g., Decree No.
13/2023/ND-CP) is mandatory, especially regarding the collection, storage, and processing of
customer personal information.
●​ Customer Name Order: Vietnamese names often place the family name first. The system should
allow flexible name fields to handle this ordering and display names accordingly.

lxxix.​ 7.8 Other Localization Requirements

●​ Paper Size for Printing: Default paper size for printed documents (e.g., receipts, invoices) should
be A4 or A5, as these sizes are commonly used in Vietnam.
●​ Standard Tax Rate: The system should be capable of applying the standard Vietnamese VAT rate
(currently 10%) and allow for rate changes in compliance with government updates.
●​ Regulatory Compliance for Promotions: Ensure that promotions and discounts comply with
local regulations, including accurate terms and expiration dates displayed in Vietnamese.

These localization adjustments ensure the system is fully compatible with Vietnamese standards
and supports the specific needs of customers and staff in Vietnam. This setup will provide a
familiar, compliant, and accessible user experience for Vietnamese users.