Abdulwadood-Assignment-2

Requirements
1.1 definition of requirements:
A requirement is a statement that specifies what a system needs to do or the characteristics it
must have. During the analysis phase, requirements are drafted from the business owner's
perspective, focusing on the "what" of the system. These requirements, known as business
requirements, primarily address the needs of business users and, occasionally, the end-users.
As the design process progresses, these business requirements evolve and become more
detailed, outlining the strategy for system implementation. Once defined from the developer's
perspective, they are often called system requirements in the design phase. Both functional and
non-functional requirements are essential.

1.2 Analysis Strategies:

- Problem analysis: Identifies what's causing issues or mistakes in the operating system.

- Root Cause Analysis: This technique searches for the primary reasons behind problems
or deficiencies.

- Duration analysis: Look at the time it takes to complete different tasks in the system.

- Activity-Based Costing: Checks the costs associated with each activity in the system.

- Informal benchmarking: Compares the system with industry standards or similar

systems.

- Observation: Watching how users interact with the current system helps spot issues and
areas for improvement.

I would use observation, problem analysis, and root cause analysis together to assess the
needs. This approach helps find evident and hidden issues with the current system and better
understand what users need.

1.3 Methods for Gathering Requirements:

- Interview: Talking face-to-face with stakeholders to gather their views and insights.

- Joint Application Development (JAD): Holding workshops with stakeholders to identify

needs.
 - Questionnaire: Collecting structured responses from many stakeholders.

- Document analysis: Reviewing existing documents related to the system or similar

systems.

- Observation: Watching how people interact with the current system in its usual
environment.

Each method has its pros and cons. For instance, questionnaires can gather information from
many stakeholders quickly but might need more detailed insights, while interviews can offer in-
depth qualitative data but are more time-consuming.

1.4 Suitable Methods for Gathering Requirements:

Interviews and observational methods could be better suited for online registration. Interviews
allow for a detailed exploration of stakeholders' needs and concerns. At the same time,
observation gives valuable insights into how users interact with the system in real-time,
identifying issues and usability challenges.

1.5 Questionnaires for the Online Registration Process:

• How satisfied are you with the current POS system at your store?
• What challenges have you encountered while using the POS system?
• How often do you use the POS system for transactions?
• Which features do you consider most important in a POS system?
• How user-friendly do you find the interface of the current POS system?
• What improvements would you like to see in the POS system?
• How reliable do you think the POS system is during operations?
• Do you feel your transaction data is secure when using the POS system?
• How would you rate the responsiveness of the POS system during use?
• Would you recommend this POS system to other businesses?

The responses to these questions will be utilized to enhance the design of the POS system by
highlighting user satisfaction levels, identifying common issues, determining key features, and
understanding user perceptions regarding system security and performance.

1.6 Functional and Non-Functional Requirements:

Functional Requirements
These are specific behaviors or functions the system must perform:
Transaction Handling:

 Process sales, returns, exchanges, and refunds.

 Support multiple payment methods: cash, credit/debit cards, mobile payments, and gift
cards.
 Calculate totals, taxes, and discounts automatically.
 Generate and print receipts.

Inventory Management:

 Track and update inventory in real time.

 Provide alerts when items are low in stock.
 Allow manual entry and adjustment of inventory levels.
 Generate inventory reports.

User Management:

 Support multiple user roles (e.g., cashier, manager) with different access levels.
 Allow users to log in and log out securely.

Reporting:

 Generate daily sales reports.

 Produce detailed reports on transactions, inventory, and customer purchases.
 Support custom report generation.

Customer Management:

 Store and manage customer information.

 Track customer purchase history and preferences.
 Support loyalty programs and customer rewards.

Promotions and Discounts:

 Allow the setup and application of promotional discounts.

 Manage time-limited offers or seasonal promotions.

Non-Functional Requirements
These are the standards or conditions the system must meet:

Performance:

 Ensure high transaction speed to handle peak traffic periods without delays.
 Optimize system performance for quick response times.
Reliability:

 Guarantee system uptime, especially during business hours.

 Provide reliable backup and recovery processes.

Usability:

 Design an intuitive and easy-to-use interface.

 Ensure minimal training is required for new users.
 Provide user assistance and help documentation within the system.

Scalability:

 As the business grows, allow for expansion in terms of features, number of transactions,
and concurrent users.

Security:

 Secure sensitive data like customer information and transaction details.

 Comply with data protection regulations (e.g., GDPR, PCI-DSS).
 Implement secure authentication and authorization processes.

Compatibility:

 Ensure compatibility with hardware components like barcode scanners, receipt printers,
and cash drawers.
 Support integration with other business systems, such as accounting software and e-
commerce platforms.

Structural modeling:
2.1 Introduction of Modeling:
A conceptual or structural model shows how the elements supporting a business's processes
are arranged. It helps analysts concentrate on the business aspects rather than technical details
by presenting a logical organization of objects during the analysis phase without showing how
they are made, stored, or changed. Later in the design process, this structural model is updated
to accurately reflect how the objects are stored in databases and files. This section discusses
using class diagrams, object diagrams, and class-responsibility-collaboration (CRC) cards to
develop the structural model.
2.2 Use-Case Discussion:
A use case describes all the possible ways an end user can interact with a system. It details the
system's actions in response to user requests, illustrating its interaction with its users (actors).
In the context of a Point of Sale (POS) system, the main actors typically include:

1. Cashier (Sales Associate): This actor operates the POS system during customer
transactions. The cashier can scan products, apply discounts, process payments, issue
receipts, and handle returns and refunds.

2. Store Manager: The manager has overarching access to the POS system. They can
modify product prices and details, manage inventory, view detailed sales reports, set up
promotions, and manage cashier accounts.

3. Customer: Although not interacting with the system directly as the other actors do, the
customer is central to the POS interactions. Customers engage with the system by
presenting items for purchase, making payments, and receiving receipts.

POS System Use Cases:

 Processing a Sale:

o Actor: Cashier

o Description: The cashier scans items, applies any discounts, calculates the total,
processes the customer's payment, and issues a receipt.

 Handling Returns/Refunds:

o Actor: Cashier

o Description: The cashier processes returns by verifying the item and the receipt
and then issues a refund based on the original payment method.

 Managing Inventory:

o Actor: Store Manager

o Description: The manager updates inventory counts, adds new products to the
system, and adjusts product details.

 Generating Reports:

o Actor: Store Manager

 o Description: The manager generates reports, such as daily sales, inventory levels,
and transaction logs, to monitor store performance.

 Setting Promotions and Discounts:

 Actor: Store Manager

 Description: The manager sets up POS promotional discounts, which are automatically
applied when eligible items are purchased.

2.3 The Process of Creating a Use-Case Diagram:

To make a use case diagram, first identify which systems or users will be actors in the system.
Use cases show the interactions or actions that actors perform to achieve goals. Describe the
relationships (like association, generalization, or inclusion/extension) between actors and use
cases. For easier understanding, group related use cases together. Use a diagramming tool to
create the diagram, placing use cases on the right side and actors on the left. Finally, review the
diagram with the system's stakeholders to ensure it accurately represents how users interact
with it and how it functions.

2.4 The Process of Creating Use-Case Description:

Creating system descriptions involves several steps: defining the objective, gathering data,
organizing the content, writing clear and concise explanations, reviewing and revising,
documenting changes, and distributing the descriptions. This process requires understanding
the user's needs, the system, and the design requirements, ensuring the information is
accessible. The descriptions should be formatted using headings, bullet points, tables, diagrams,
and other elements to make them easy to read. Although the descriptions are written in a
straightforward style, they still need to be checked for accuracy, consistency, and
completeness. This process helps in both developing and implementing a system.

2.5 Activity Diagram Discussion:

An activity diagram is a flowchart used in Unified Modeling Language (UML) that illustrates the
flow of activities in a system or process. This diagram is also known as a "behavior diagram"
because it describes what happens within the modeled system, focusing on its dynamic aspects.

For a Point of Sale (POS) system, the activity diagram might depict a typical sales transaction
process. Here is an example of how such a process might be outlined:
 1. Starting the Transaction: The cashier initiates the process by starting a new transaction
on the POS terminal.
2. Scanning Items: The cashier scans the barcodes of items the customer wishes to
purchase. Each scanned item's price is automatically added to the total bill.
3. Adding Discounts (if applicable): If any promotions or discounts are appropriate, the
cashier applies these to the relevant items.

4. Processing Payment:

 The cashier asks the customer for their preferred payment method.
 If the payment is by card, the customer swipes, inserts, or taps their card and then
enters a PIN or signs if required.
 If the payment is in cash, the cashier inputs the amount received, and the POS
calculates any change due.
5. Issuing Receipt: Once the payment is successfully processed, the POS system generates
a receipt, which the cashier can print or email to the customer, depending on the
customer's preference.

6. Handling Returns/Exchanges: In a separate flow, if a customer wants to return or

exchange an item:

 The customer presents the item along with the receipt.

 The cashier verifies the item against the receipt and processes the return or
exchange.
 If a return is processed, the system updates the inventory accordingly, and the
cashier issues a refund.
7. End of Transaction: The transaction is completed, and the process ends with the cashier
ready to begin the next customer's transaction.

This activity diagram provides a precise sequence of steps during a typical interaction with a
POS system, highlighting the system's behavior from the cashier's initiation of a transaction to
the finalization of the sale.
Provide diagrams:
3.1 Use-Case Diagram:
3.2 Use Case Description:

______________________________________________________________________________

Use Case Name: Process Sale Transaction

Actors:

1. Cashier
2. Customer

Description: This use case describes the process of a cashier handling a sale transaction in a
retail environment using a Point of Sale (POS) system.

Preconditions:

 The cashier is logged into the POS system.

 The POS system is operational and connected to necessary peripherals (barcode
scanner, receipt printer).

Basic Flow:

1. Start Transaction: The cashier initiates a new sale on the POS system.
2. Scan Items: The cashier scans the items the customer wishes to purchase, and the
system updates the total cost.
3. Apply Discounts: If applicable, the cashier discounts the eligible items, and the system
recalculates the total.
4. Payment: The cashier collects payment from the customer based on the final total. This
can be via cash, card, or digital payment methods.
5. Verify Payment: The cashier ensures the system processes the payment correctly.
6. Print Receipt: Once payment is verified, the POS system generates a receipt, which the
cashier hands to the customer.
7. Close Transaction: The cashier closes the transaction in the system, which updates
inventory and sales records.

Alternate Flow:

1. Item not scanning: The cashier manually enters the item's SKU or barcode into the
system.
2. Payment declined: The cashier informs the customer of the issue and requests another
form of payment.
3. Printer issues: If the receipt printer is not working, the cashier offers to send the receipt
via email or use an alternative printer.
Postcondition:

1. The transaction data is accurately recorded in the system.

2. The inventory levels are updated based on the items sold.
3. The customer receives a receipt confirming their purchase.

Exceptional Condition:

1. In a system failure, transactions may be temporarily paused until the system is restored.
2. If there are issues with payment processing, the cashier may need to restart the
transaction or use an alternative payment system.

_____________________________________________________________________________

This use case description includes all elements from preconditions and basic flow to alternate
flows, postconditions, and exceptional conditions. It provides a comprehensive view of the
transaction process at the POS, detailing what the cashier and the system need to do to
complete a sale.

3.3 Activity Diagram:

Diagram of cashier logging into the system