Upload
agcristi
View
353
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Citation preview
Galla – the Small Shop ERP Product Date: November 13, 2005
Team Members:
Palwencha Nagraj Krishna([email protected]) (project manager, documentation)
Anirudha Joshi ([email protected]) (domain specialist, product and human-interaction
design)
Gulavani Bhargav Subhash ([email protected]) (software architect, system interface
design and development)
Avinash Gupta ([email protected]) (quality assurance)
Nilesh Nalnikar ([email protected]) (tooling, system interface design and
development)
2
Index
1. Introduction 3
1.1 Background 3
1.2 Design Goals 3
1.2.1 Requirements 6
1.2.2 Preliminary Use Cases 11
2. Architecture 25
2.1 Overall Architecture 25
2.2 Data Models 26
2.3 Object Oriented Design 29
2.3.1 CRC cards 29
2.3.2 Interaction Diagrams 40
2.4 Package Structure 43
2.5 User Interface Design 44
3. Test cases and QA 50
3.1 Test cases 50
3.2 Testing methods and Test optimization 54
3.3 QA Review 55
4. Estimation 57
5. Bibliography 60
3
Chapter1. Introduction
1.1 Background
The Need Millions of small shops in urban India are threatened by the changing business environment.
As large shopping malls, departmental stores and super markets have emerged to dot the
cities, traditional small shops have had to fight back to retain market share.
The onslaught of organized retail through large shops is evident in metros and is spreading
fast to smaller cities. Large shopping malls provide enhanced shopping experience to the
young, upward mobile population that often purchases high-margin, high-value items. Large
shops are marketed better, often as multi-city chains such as Crosswords, D-Mart, Big Bazaar,
Foodworld, Lifestyle and Shoppers Stop. Their large scale enables them to operate at lower
margins – many of the larger grocery stores give discounts over the printed price. Some have
even started marketing themselves as the cheapest – “Is se sastaa aur accha kahin nahin.” (No
where else will you find it cheaper and better than here.) They use automated systems for
procurement, demand forecasting, printing price labels, billing and inventory tracking,
ensuring high efficiency at lower costs.
However, large shops have some problems. Several of the large shops are very crowded on
weekends. Because customers tend to buy for the whole week at a time, their average
shopping is higher, leading to long queues at the checkout cashiers. To manage crowds, these
shops have had to deploy better security arrangements, thus taking away some of the
shopping experience. Since a large shop caters to a larger geographical area, customers have
to either bring their vehicles (cars, scooters) leading to traffic congestion near the large shop,
or need to rely on public transport (bus, rickshaw, taxi) to reach the shop and particularly to
carry their purchase back home. Moreover, and perhaps because of these reasons, large shops
have not yet managed to attract shoppers from lower-middle and lower classes in the cities.
This poses an opportunity to the small shops. Small shops have responded by improving
quality of service, in particular by introducing free home delivery. Some small shops also
provide credit to customers and retain long-term relationship with them. Customers of small
shops rely on personal recommendations by the shop keeper. In case of many of the non-
branded items such as cereals, shops serve as a brand.
However going forward, this may not prove to be sufficient. If small shops have to sustain
competition with the organized retail chains, they will have to constantly improve efficiency
and use the power of information technology to improve service. Small shops compete not
only with large shops, but also with each other. In the process, no doubt some of the small
shops will be shaken out of the business. Those that remain competitive must ensure that
they are equipped to do business in the environment of the future.
1.2 Design Goals
The Vision Powai Technologies Pvt. Ltd. is a start-up company that proposes to bring out a device
(Galla) for implementing ERP systems in small shops in India and a service (galla.com) that
will serve these small shops through this device.
4
Galla is an Enterprise Resource Planning (ERP) tool for small shops. It is a scalable piece of
hardware. The shop may start with only one device, but may scale up to connect multiple
devices together as the business grows.
galla.com, the service from Powai Technologies Pvt. Ltd. provides shop keepers with these
kinds of services:
� Services to administer and maintain Galla
� Services of accounting, demand forecasting, cash-flow management etc.
� A web-based shopping interface for customers to locate best deals which hook up
through the device as additional orders
galla.com may be only one of the services. Through Galla, the shopkeeper may interface with
other such services from other organizations. Figure 1 shows a schematic of the proposed
vision for Galla, galla.com and other services.
Fig. 1 A schematic of the proposed system and the role of Galla, the device. This document is restricted
to the requirements of Galla, and not other services such as galla.com or the Internet.
About this Document This document captures the requirements, the initial use-cases and key quality attribute
scenarios expected from the tool of Galla, the device. A complete description of the
requirements of galla.com, the service, is beyond the scope of this document. This document
refers to galla.com as an external interface of Galla. Galla can perform several functions
related to small shop ERP independently, without the need to interface with galla.com.
Galla Galla is a hardware device that lets a small shop use the power of information technology to
do the routine tasks more efficiently and flexibly. These tasks include billing, cash flow,
customer credit tracking, inventory, vendor account management etc. Galla lets the
shopkeeper retain his current business practices such as personalized service and credit to
customers.
Customer Vendors
Gall
a
Small
Shopkeeper
Interne
t
galla.com
service
Shop
Gall
a
Cashier
other
services
5
Galla also throws open new possibilities by supporting decision making on the basis of
experience and information (as opposed to experience alone) and by introduction of modern
business practices in traditional shops. It allows the shopkeeper to respond to the changing
business environment and provide better service by doing things like up-sale, discounts and
sale, frequent customer relationship management, premium pricing, demand forecasting etc.
To start with, Galla is being targeted to shops whose primary function is retail sale (e.g.
medical shop, grocery store, vegetable shop etc.). At this stage, the product is not being
targeted to shops that primarily sell services (e.g. restaurants, laundry etc.)
Galla is inexpensive, given the large numbers of small shops in India. Galla fits in the
informal culture of the Indian trading community and does not force any formalities on the
shopkeeper that he does not desire. It is easy to use, even by a user with limited literacy and
limited familiarity with technology. It works in an environment with high dust and heat,
limited connectivity and fluctuating power.
Galla is flexible and scalable, catering to needs of all kinds of small shops in India. One, lone
shopkeeper is able to carry out all activities single-handedly. A shopkeeper may choose to use
only a part of the tool to start with. Yet, as business grows, he is able to delegate work to
employees, add terminals or connect to external services. As the shopkeeper becomes familiar
with the advantages of Galla, he can start using the additional features. The design of Galla
makes the transitions easy.
The Stakeholders The following are assumed to be the stakeholders in this project:
� Users
o Shop Manager (usually also the owner of the shop, who takes all the business
decisions of the shop and may do all the other roles in a small shop).
o Cashier (who handles the device to manager all transactions with the
customer for either located within the shop or mobile).
o Employee (who runs errands and does assigned tasks).
o Consultant (who provides the shop services such as hardware maintenance,
administration, configuration, training etc.)
� Development team (members in Powai Technologies Pvt. Ltd.)
o Management
o Marketing
o Project manager
o Domain specialist
o Human-interaction designer
o Software architect
o Quality assurance lead
o Developers
o Quality assurance members
6
1.2.1 Requirements
Functional Requirements
1. Ordering and Billing
1.1. Ordering:
Users: Shop Manager, Cashier, Phone operator, Customer.
Stakeholders: Domain specialist, Human-interaction designer.
The system should enable an order taker to take orders from a customer and prepare
a bill for settlement. The system should support at least these types of orders:
1.1.1. Items in Hand: In the first type of order, the customer walks through the
shop and collects all items he wishes to purchase himself from the shelf.
1.1.2. Shopping List: In the second type of order, the customer gives a verbal or
written order to the shop manager at the counter. An order may come over the
phone or over the web. The shop manager or one of the employees then collects
all the ordered items from the shelves. In case items are out of stock, the system
should warn the order taker at the time of accepting the order. In case the items
are ‘nearly’ out of stock, the system should allow the order taker to check if
some unbilled customers have not picked up the remaining stock. The system
should help the order taker or an employee to pull out all items from the
shelves to process such an order.
1.1.3. Advance Order: This may be an order for an item to be delivered to the
customer at a later date or time (e.g. birthday cake to be delivered tomorrow)
1.1.4. Recurring Order: An order that customers want repeated at a periodicity for
a duration of time (e.g. one litre of milk delivered daily, except on Sundays)
1.2. Up-sale Items:
Users: Shop Manager, Cashier, Phone operator, Customer.
Stakeholders: Domain specialist, Human-interaction designer.
When the order is being taken, the system should support the shop manager to
suggest up-sale items (additional suggestions from the shopkeeper). The shop
manager may do so from his personal experience. In addition, the system can suggest
additional items depending on the other purchases, the season, the customer’s history
etc. (for example, if a customer buys birthday candles, the system can suggest
birthday cake, party decoration items, soft drinks and other relevant items
1.3. Order Changes:
Users: Shop Manager, Cashier, Phone operator, Customer.
Stakeholders: Domain specialist, Human-interaction designer.
While processing the order, if the employee or the customer wants to change some of
the items in the order (e.g. item cancelled, quantity changed, variety changed etc.) the
system should allow this.
1.4. Home Delivery:
Users: Shop Manager, Cashier, Phone operator, Employee, Customer.
Stakeholders: Domain specialist, Human-interaction designer.
In case the shop supports home delivery, the system should enable the shop manager
7
to take orders in the shop or on the phone. The system should allow for delayed
settlement for such orders.
1.5. Returns management:
Users: Shop Manager, Cashier, Phone operator, Customer.
Stakeholders: Domain specialist, Human-interaction designer.
The system should allow the shop manager to accept allowed returns from customers
at the discretion of the shop manager. Returned items may be re-offered for sale, may
be marked to be returned to the vendor or marked to be discarded at the discretion of
the shop manager. The system should account for returned items according to their
status.
2. Customer Settlement
2.1. Settlement:
Users: Shop Manager, Cashier and Customer.
Stakeholders: Domain specialist, Human-interaction designer.
The system should allow the manager to settle a transaction through cash, credit card
or if the customer has an account with the shop, on credit. A settlement may be
delayed in case of home delivery orders or recurring orders.
2.2. Credit Warning:
Users: Shop Manager, Cashier and Customer.
Stakeholders: Domain specialist, Human-interaction designer.
If a transaction is settled on credit, the manager or cashier should be warned about
the current outstanding amount of the customer. The transaction should be settled on
credit only on the approval from the manager or the cashier.
2.3. Account Settlement:
Users: Shop Manager, Cashier and Customer.
Stakeholders: Domain specialist, Human-interaction designer.
Manager should be able to accept settlement against a customer account by cash or
credit card.
3. Cash Flow Management
3.1. Cash Flow Statement:
Users: Shop Manager, Consultant.
Stakeholders: Domain specialist, Human-interaction designer.
The system should give a summary of income, expenses, vendor outstanding
amounts for items sold, and customer outstanding amounts for items sold and net
cash flow for a given period of time in the past.
3.2. Cash Flow Forecasting:
Users: Shop Manager, Consultant.
Stakeholders: Domain specialist, Human-interaction designer.
The system should compute known and expected future vendor payments, expenses,
cash flow, demand forecasts etc. and give a cash flow forecast for a given period of
8
time. Such forecast should clearly differentiate between assured pessimistic
expectation, most probable expectations and potential optimistic expectations.
4. Customer Credit Tracking
4.1. Outstanding:
Users: Shop Manager, Cashier, and Customer.
Stakeholders: Domain specialist, Human-interaction designer.
The manager should be able to browse the current outstanding amount of all
customers. He should be able to sort the list in various ways, (by date, amount, oldest
settlements etc.)
4.2. Statement:
Users: Shop Manager, Cashier and Customer.
Stakeholders: Domain specialist, Human-interaction designer.
For each customer, the manager should be able to print out a statement of bills and
payments received for a given period.
5. Preferred Customer Relationship Management
5.1. Preferred Customer Relationship Management:
Users: Shop Manager, Consultant.
Stakeholders: Domain specialist, Human-interaction designer
Manager should be able to run his own preferred customer relationship management
program or be a partner in an external preferred customer relationship program
(such as galla.com service or Ticket Restaurant programme). These are the offers he
should be able to make:
� Discounts / reward points / free services to be given to customers in case they do
specified amount of purchases in specified time period, single purchases worth
certain amounts or on orders settled against cash, credit or credit cards.
� Discounts / reward points / free services to be given to specific customers.
� Redemption rules for reward points if any.
5.2. Control:
Users: Shop Manager, Consultant.
Stakeholders: Domain specialist, Human-interaction designer.
All parameters could be discretionary to the shop manager. In addition, the shop
manager may be able to set these parameters, so that they are not discretionary to the
cashier.
6. Inventory:
Users: Shop Manager, Cashier and Employee.
Stakeholders: Domain specialist, Human-interaction designer.
The system should help the manager to take a physical inventory of all stocks. The
system should assist the manager by preparing a list of items sorted according to their
location in the shop. The system should help the manager to weed out expired items,
expiring items or items that have not been sold for a long time.
7. Discounts and Sale:
Users: Shop Manager, Consultant.
Stakeholders: Domain specialist, Human-interaction designer.
The system should allow the shop manager to run discount sales. Such sales may be run
by controlling several permutations and combinations of the following:
9
o Sale for a period of time (one week)
o Periodic sales (e.g. sale from 1-4 pm in the afternoons on weekdays)
o Sale of all items nearing expiry (particularly, non-returnable items)
o Sale of all non-returnable items not sold for ‘long’ time
8. Ordering and Demand Forecasting
8.1. Demand Forecasting:
Users: Shop Manager, Consultant.
Stakeholders: Domain specialist, Human-interaction designer.
Galla should provide basic demand forecasting facilities based on the local trends in
the shop for specific items. In addition, the system can suggest additional items the
demand for which is likely to pick up in a given period of time depending on the
current sale trend (bleblaids), the season (Diwali, so order lamps) or other
parameters (vendor introducing new products or giving special commissions).
If the shopkeeper chooses to subscribe to external services such as galla.com, Galla
should interface with such external services to provide more advanced features
offered by those services through http interface.
8.2. Ordering:
Users: Shop Manager.
Stakeholders: Domain specialist, Human-interaction designer.
The system should prepare vendor-wise orders of items that have been sold out, or
items whose stock is almost over (i.e. as per the demand forecast for an item, it may
not last 1x to 5x number of days it takes for the supplier to supply the goods). The
manager should be allowed to vary the factor, or add / delete items to such orders
manually. The system should place recurring orders with vendors as well.
8.3. Filing stocks:
Users: Shop Manager.
Stakeholders: Domain specialist, Human-interaction designer.
The system should help the manager and employees to file stocks delivered by the
vendor. The system should help the manager to track discrepancies between the
items supplied and the vendor bills.
9. Vendor Account Management
9.1. Vendor Bills and Payment:
Users: Shop Manager.
Stakeholders: Domain specialist, Human-interaction designer.
The system should record the bills received from vendors and payments made to
vendors. The system should enable the preparation of a statement of bills and
payments for the given period of time.
9.2. Returnable / Damaged Goods:
Users: Shop Manager.
Stakeholders: Domain specialist, Human-interaction designer.
The system should enable the manager to return unsold, returnable goods to
vendors make adjustments against bills and provide credit notes to vendors.
10. Expenses:
Users: Shop Manager.
Stakeholders: Domain specialist, Human-interaction designer.
The system should record all expenses such as salaries of employees, rent, etc.
10
Elements Not Considered There will be aspects of the system that are important in the final product but the team is
unable to consider because the team can spend limited time. For now we are putting such
aspects beyond the scope of this project. Here is a list of such aspects we have identified as of
now:
� Functionality of galla.com services, including web-based ordering by the customer
� Home delivery management
� Credit issues with vendors (and how commissions vary as a result)
� Loans / credit from banks and several other issues related to banking
� Details of shop expenses such as employee salaries, rent etc.
11
1.2.2 Preliminary Use Cases
Includes
Includes
Includes
Includes Includes
Includes
Includes
Shop
Manager
Phone
Operator
Cashier
Shop
Employe
Customer
Session
Ordering
Normal
Order Recurring
Order
Order
Settlement
Extends
Includes
Goods
Returns
Cash
Credit
Card
Credit
Account
Settlement
Cash
Credit
Card
Includes
Vendor
Session
Accepting Delivery
and Billing
Includes
Vendor
Returns
Includes Vendor
Settlement
Includes
Placing
Orders
Includes Administratio
n
Includes
Discounts
and Sales
Demand
Forecasting
Start-up /
Shut-down
Filing
Stock
Galla – the Small Shop ERP
Product
Includes
Cash Flow
Forecasting
Customer Credit
Tracking
Stock
Taking
Setting Customer
Loyalty Benefits
Create New
Account
Delivery
Person
Order
Change
Includes
Create New
Account
Expenses
12
1. Administration
Users: Shop Manager, Consultant.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements:
Administration use case is triggered when the system is being set up by the manager or
consultant for the first time or when the manager is free and wants to carry out some
administrative tasks. Administration functions are to be carried out by the manager
personally or by an external consultant in consultations with a manager. Administration
includes the following use cases:
• Start-up
• Stock taking
• Setting up customer loyalty benefits
• Preparing the orders and demand forecasting
• Cash flow forecasting
• Setting up discounts and sales
• Customer credit tracking
• Filing stocks
• Expenses
• Shut-down
1.1 Start-up Users: Shop Manager, Consultant.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements:
Start-up use case is triggered when the shop opens for business.
The manager or the cashier physically starts the system by pressing the on switch, identifies
and authenticates him. Then the system becomes ready for transactions. The default state of
the system is normal order use case.
1.2 Stock Taking Users: Shop Manager, Consultant.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 6
Stock taking use case is triggered when the manager decides to physically verify the stock in
the shop at his discretion.
The manager indicates that he wants to take stock.
The system prepares a summary of all the stock in the shop and prints it out in a manner that
is convenient to take stock (e.g. shelf-wise). It also indicates stocks that are expired, stocks
that are nearing expiry and stocks that have remained unsold for a long duration (more than
a percentage of shelf life of an item).
The manager, with help from other shop employees conducts verification of stock, optionally
removes expired items and optionally identifies old or expiring items for potential discount
sale or return to vendors. The manager indicates this to the system either during the process
13
of stock verification or after. Similarly, he also indicates any items that are missing. The
system eliminates items that are earmarked to be discarded and returned and removes them
from the stock.
The manager may also add items during stock taking that are available for sale in the shop,
but are not recorded in the system. While an item is being added, the system will indicate
status of other items such that no duplicate entries occur.
1.3 Setting Customer Loyalty Benefits Users: Shop Manager, Consultant.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 5.1, 5.2
Setting customer loyalty benefits use case is triggered when the manager decides to set up a
customer loyalty program or to change its rules at his discretion. The manager sets up or
modifies rules about
� Discounts / reward points / free services to be given to customers in case they do
specified amount of purchases in specified time period, single purchases worth
certain amounts or on orders settled against cash, credit or credit cards.
� Discounts / reward points / free services to be given to specific customers.
� Redemption rules for reward points if any
In addition, the manager may set what items are and are not discretionary to the cashier.
1.4 Demand Forecasting Users: Shop Manager, Consultant.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 8.1
Demand forecasting use case is triggered when the manager decides to prepare orders and
forecast demand in the large at his discretion, from cash flow forecasting use case, the
placing orders use case or from the setting up discounts and sales use case.
The system provides analytical tools about the current confirmed recurring orders, current
stocks of various items and projected future demands on the basis of past trends, seasons,
market trends or other parameters. The system will give some parameters to the manager to
manipulate (such as conservative estimates, most probable estimates, aggressive estimates,
sales and discount parameters, customer loyalty programme parameters etc.).
On the basis of this analysis, the system prepares a set of preliminary orders of items per-
vendor on the basis of the average time each vendor is known to have taken in the past to
supply from the time of placing order.
When the use case is triggered in context of a particular vendor, the system will do demand
forecasting and order preparation as above only in the context of a specific vendor.
The manager may optionally decide to manually edit these orders on the basis of his personal
judgement and experience.
If the shop has subscribed to an external demand forecasting service, the system may display
results from this external service, in addition to predictions from the local service. The
manager will use his discretion to decide the final orders.
14
1.5 Cash Flow Forecasting Users: Shop Manager, Consultant.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 3.1, 3.2
Cash flow forecasting use case is triggered when the manager decides to do cash flow
analysis at his discretion or from the setting up discounts and sales use case.
The manager provides a start date and end date from the past and the system displays or
prints a statement for the given period. The cash flow statement displays income, expenses,
vendor outstanding amounts for items sold, customer outstanding amounts for items sold
and net cash flow.
The system provides analytical tools to forecast cash flow in future, including confirmed
recurring orders, current outstanding from account holding customers, confirmed recurring
expenses (salary, rent etc.), as well as projected demands (demand forecasting use case) on
the basis of past trends. The system will give some parameters to the manager to manipulate
(such as conservative estimates, most probable estimates, aggressive estimates, sales and
discount parameters, customer loyalty programme parameters etc.).
Thus system takes the input from the demand forecasting feature and translates that into cash
flow prediction.
1.6 Setting up Discounts and Sales Users: Shop Manager, Consultant.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 7
Setting up discounts and sales use case is triggered when the manager decides to set up
discounts and sales in his shops at his discretion.
The system allows the manager to analyze sales trends over a period of time, including hours
of day, days of the week, months of the year, days of maximum sales, days of minimal sales
etc.
On the basis of these trends, the system can suggest revenue management schemes (e.g.
discounts on specific items, discounts at specific times, days of week, periods etc.). The
manager may optionally edit some of these schemes, or an earlier saved scheme or set up a
completely new scheme. While trying out different schemes, the system will compute
demand forecasts and cash flow forecasts for each scheme, without committing to any
scheme.
The manager may save schemes for use later.
1.7 Customer Credit Tracking Users: Shop Manager, Consultant.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 4.1, 4.2
Customer credit tracking use case is triggered when the manager decides to analyze the
current situation about account holding customers and wants to follow up on the customers
whose payments are due.
The system will give options to view all account holding customers, customers with overdue
amounts, customers with outstanding amounts above a threshold, customers from specific
area etc.
15
The system will display customer data and give further options to sort the data according to
several parameters (location, outstanding amount, name etc.), to print summary of the views
or to print statements for chosen customers.
The manager may optionally drill down to see purchase trends of a specific customer or a
group of customers. He can further drill down to analyze the details of each order.
The manager may at his discretion initiate a call to specific customers regarding their
outstanding amount. If the customer agrees to settle, an account settlement use case is
triggered.
The manager may optionally blacklist a customer from further purchases or write off overdue
amounts of certain customers.
1.8 Filing Stocks Users: Shop Manager, Consultant.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 8.3
Filing stocks user case is triggered at the discretion of the manager when goods from vendors
arrive and after the accepting delivery and billing use case. Although this is an
administration function, the manager may solicit help of other shop employees in this use
case and delegate some of the responsibilities to other shop employees. If delegated, it should
not be possible to go to other administrative modules from this use case.
The stock taker unpacks, inspects and counts the goods and enters them in the system and
optionally tracks them with an identifier such as a bar code. The stock taker may optionally
indicate where the item is to be kept in the shop. The system may help him in this by
providing default values based on the past experience of similar items.
The system shows any discrepancies at the end of entering items from the order and the
delivery challan. The stock filer approves these discrepancies, and through the manager
informs the vendor about them. These are later used during vendor settlement use case.
1.9 Expenses Users: Shop Manager.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 10
Expenses user case is triggered at the discretion of the manager when any shop related
expenses happen.
The manager indicates the type of expense (rent, salary, electricity, phone bill etc.), the
amount and the date. The system records the expense against the shop.
1.10 Shut-down Users: Shop Manager.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements:
Shut-down use case is triggered when the shop closes for business and no other
administrative functions need to be performed.
The manager or the cashier physically shuts the system down by pressing the off switch.
16
2. Vendor Session
Users: Shop Manager.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 9
Vendor session use case starts when a vendor walks in the shop or when he calls up on the
phone, or when the manager calls up the vendor to place an order at his discretion. This
session includes following use cases:
� Create new vendor account
� Placing orders
� Accepting delivery and billing
� Vendor returns
� Vendor settlement
2.1 Create New Vendor Account Users: Shop Manager.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements:
Create new vendor account use case starts at the discretion of the manager at any time
during the vendor session use case.
The manager asks for the vendor for details such as name, address, phone number, typical
items supplied, lead time for procuring items, commissions on each item, payment terms and
enters those in the system.
The system generates vendor identification.
2.2 Placing Orders Users: Shop Manager.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 8.2
Placing orders use case starts at the discretion of the manager at any time during the vendor
session use case. Typically, it may be triggered from the demand forecasting use case or from
the accepting delivery and billing use case.
The manager reviews and edits an order created during demand forecasting for a particular
vendor. Alternately, he may choose to create a completely new order.
The manager places the order either in a printed form, in a vendor-supplied format or orally.
The manager updates the finalised order in the system if there are any changes. Based on past
experience with the vendor or entries in the vendor account, the system updates the probable
date of delivery. The manager checks the probable date of delivery back with the vendor and
may optionally update this in the system.
If the order contains new items, the system automatically prompts the manger to enter these
items in the system.
2.3 Accepting delivery and billing Users: Shop Manager.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 9.1
17
Accepting delivery and billing use case starts during the vendor session use case when the
vendor delivers goods or an invoice.
The system displays corresponding order for which the delivery is to be made. If no order
was entered, placing orders use case is triggered at this point to create a new order.
The manager checks if the items in the order match the items in the delivery challan or
otherwise updates the order.
At this point, the stock filing use case may be triggered.
If the vendor has supplied an invoice, the manager inputs the receipt of the invoice in the
system along with one or more delivery challans against which the bills were received. The
system generates a statement that indicates if the stock filing use case has been completed for
this delivery challan and goods have been verified or not.
The manager may optionally take a print of the statement.
If there are discrepancies in the amount between corresponding delivery challans and invoice
amount, the system indicates this to the manager in the statement. The manager may choose
to inform this discrepancy to the vendor at this stage at this discretion.
2.4 Vendor returns Users: Shop Manager.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 9.2
Vendor returns use case starts at the discretion of the manager at any time during the vendor
session use case if any items are due to be returned to the vendor.
The manager shows or describes the returnable items to the vendor. The vendor accepts or
rejects these items.
If the vendor rejects a returnable item, the manager at his discretion decides to move the item
back for sale or writes off the item and indicates this to the system.
If the vendor accepts a returnable item, the manager indicates this to the system.
After all returnable items have thus been processed, the manager optionally prints a memo of
all returnable items and provides a credit note to the vendor. Such credit notes are entered as
negative transactions in the vendors account and are considered during vendor settlement
use case.
2.5 Vendor settlement Users: Shop Manager.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 9
Vendor settlement use case triggers when the manager at his discretion decides to carry out a
vendor settlement during a vendor session use case.
The system displays a statement of the amount due for the vendor, considering bills,
discrepancies between delivery challan and the invoice (uncovered during the accepting
delivery and billing use case), returns (vendor returns use case) and discrepancies between
the delivery challan and the items delivered (uncovered during the filing stocks use case).
The system indicates separately the amount over due beyond the credit limit prescribed in the
vendor’s account from the date of the invoice and delivery.
18
At his discretion, the manager decides to pay the vendor a sum of money and indicates the
payment details to the system (cash, credit card, cheque etc.)
At his discretion, the manager may input an ‘adjustment amount’ to adjust for any
accounting discrepancies between the system and the vendor.
3. Customer Session
Users: Shop Manager, Cashier, Employee.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 1, 2
Customer session starts when a customer walks in the shop or when he calls up on the
phone. This session includes following use cases:
� Ordering
� Order Settlement
� Creating New Account
� Account Settlement
� Goods Returns
3.1 Ordering Users: Shop Manager, Cashier, Phone operator, Employee, Customer.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 1
Note: Order Settlement is an abstract generalization.
Ordering use cases are of two types – normal order and recurring order.
3.1.1 Normal Order
Users: Shop Manager, Cashier, Employee.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 1.1.1, 1.1.2, 1.1.3, 1.2, 1.4
Normal order use case begins in one of the following cases:
� The customer walks in the shop and picks out items he wishes to buy
� The customer walks in the shop and orders items he wishes to buy either verbally or
through a written order
� The customer calls the shop by phone and orders the desired goods.
� The customer places an order over a web-based service such as galla.com.
An order may be taken by either the manager, or the phone operator or the cashier (called
order taker).
If the order comes over the phone, the order taker asks the customer for the phone number. If
there is a home address tied to the phone number, the system displays the same and the order
taker verifies it and if necessary updates it.
The order taker takes the written or verbal orders or items selected by the customer and feeds
items into the system. If the items are bar coded and if the customer has already picked them
out from the shelf, the order taker may scan these to enter them into the system.
19
As each item is entered, the system checks it against the saleable inventory and warns the
order taker about items out of stock or nearly out of stock. The order taker may ignore these
warnings if the customer has already picked out the items from the shelf.
After all items in the customer’s order are entered, the system prompts for any up-sale items
along with their price and other relevant details. These items may be related to the items in
the current order, current season or any other items generated by a data mining algorithm.
The order taker may offer the customer from among these or any other up-sale items by his
experience. If the customer agrees, these items are also added to the order.
After all items have been entered, the order taker applies (on suggestion from the system and
/ or at his discretion) any applicable discounts and informs the customer about the total
amount due and asks the customer which of three payment options he would prefer for order
settlement:
� Cash payment
� Credit card payment
� Credit settlement. This option is available only to customers who have an account
with the shop
The customer informs about his choice. The order taker inputs the choice in the system.
If the customer chose credit, the credit order settlement use case is triggered at this stage. If
the order taker does not approve credit order settlement, the customer has option to use other
payment mechanisms. If the customer does not choose any other option, the order is treated
as cancelled and the order taker returns the goods to the rack if necessary.
The order taker gives the customer the option of delivering the order in shop or at the
customer’s home. If the customer chooses home and the customer was ordering in the shop,
the order taker asks for home address and phone number or, if the customer has an account,
customer account number, and inputs it in the system.
The order taker gives the customer the option of delivering the order immediately or at a later
date and time (advance order). The order taker records the customer’s option and at his
discretion may change the date and time depend on the availability of stocks, shop timings
and availability of delivery boys.
Even in case of an immediate order, while the order is being fulfilled, the order taker may
optionally put the current order on hold and take order from another customer or do other
things. If the order is on the phone, the order taker may hang up the phone at this stage and
may offer to call the customer back in case the customer was paying by credit card.
The order taker optionally prints a receipt of the order.
Unless the customer has already done so, the order taker or any other employee processes the
order (removes the items from the shelf, packs them etc.). If this was to be a delayed order,
when the time of order processing comes, the system reminds the order taker and displays
items in the order. Order processing may be done by another employee in parallel with the
order being taken by the order taker.
If there are any changes necessary during the order processing, order change extension use
case is triggered.
Once the order is processed, it is ready for delivery.
If the customer chose credit card for order settlement, and if the order was on the phone, the
order taker calls the customer back at this stage.
20
If the customer chose chooses credit card for order settlement, the credit card order
settlement use case is triggered. If the credit card company does not approve the settlement,
the customer has option to use other payment mechanisms. If the customer does not choose
any other option, the order is treated as cancelled and the order taker returns the goods to the
shelf.
At this stage, if the customer selected home delivery, the items are sent to the customer. Else,
the items are delivered to the customer in the shop.
If the credit card was used as the settlement mechanism, and the delivery was in the shop, the
order taker takes a signature of the customer on the charge slip. If the delivery was at home,
the delivery person takes a signature of the customer on the charge slip and returns the
charge slip to the order taker.
If the customer chose cash order settlement option, the cash order settlement use case is
triggered. If the customer is unable to pay cash and if the delivery is in the shop, the customer
has option to use other payment mechanisms. If the customer does not choose a valid
settlement option, the order is treated as cancelled and the order taker returns the goods to
the shelf.
3.1.2 Recurring Order
Users: Shop Manager, Cashier, Employee.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 1.1.4
Recurring order use case works like a normal order in all respects except that while each item
is being ordered, the recurrence of the item is recorded. Such recurrence may be daily, weekly
or monthly.
3.1.3 Order Change Extends Ordering
Users: Shop Manager, Cashier, Employee.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 1.3
Order change extension use case is triggered during the normal order use case or recurring
order use case if during the order fulfilment, any items are added or changed from the order.
If a particular part of the order cannot be fulfilled, (because it is found to be out of stock or
damaged) the order taker opens the order and deletes the item.
If the customer asks for additional items during order fulfilment, those are added to the
order.
If the order was on phone, the order taker optionally communicates with the customer and
changes the order as per his instructions.
After all changes are made to the order, the order taker optionally prints a modified order
receipt.
If credit was chosen as the settlement option, the earlier credit transaction is rolled back and
new credit order settlement use case is carried out.
3.2 Order Settlement Users: Shop Manager, Cashier.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 2
Note: Order Settlement is an abstract generalization.
21
Order settlement use case is triggered when an order is ready for settlement during normal
order use case. An order may be settled by either cash, credit card or credit.
3.2.1 Credit Order Settlement
Users: Shop Manager, Cashier.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 2.1, 2.2
Credit order settlement use case is triggered when a customer chooses to settle an order by
credit and after the order is entered by the order taker during normal order use case,
recurring order use case or during order change extension use case.
The customer provides the necessary identification for authorization by order taker (cashier
or manager). The order taker inputs the identification into the system.
The system informs the order taker about the current outstanding amount against the
customer.
At his discretion, the order taker authorizes the settlement or does not authorize it. If he
authorizes it, the order taker records the settlement in the system and optionally prints a
statement of the customer’s account since the last settlement.
3.2.2 Credit Card Order Settlement
Users: Shop Manager, Cashier.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 2.1
Credit card order settlement use case is triggered during the normal order use case if the
customer opts to settle the order by credit card. If the customer placed the order in the shop in
person, the credit card order settlement use case is triggered after the order is processed and
any order changes are made in the order change extension use case. If the customer placed
the order on the phone, the credit card order settlement use case is triggered after the order is
processed, any order changes are made in the order change extension use case and the order
taker has called the customer back to get the credit card details.
The customer provides the credit card details. The order taker enters the credit card details on
the system. Optionally, the system dials out to the credit card company number and provides
transaction information. The credit card company provides authorization code.
The system prints out a charge slip.
3.2.3 Cash Order Settlement
Users: Shop Manager, Cashier.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 2.1
Cash order settlement use case is triggered during the normal order use case if the customer
opts to settle the order by cash, after the order is processed. Any order changes are made in
the order change extension use case and the items are delivered to the customer (either in the
shop or at home).
The customer provides the necessary cash.
If the delivery is in the shop, the order taker accepts the cash and optionally enters the cash
details (number of notes, coins etc.) in the system. If he does so, the system displays the
amount of change that needs to be returned. The order taker returns the appropriate change.
The order taker indicates so to the system that the cash transaction was completed.
22
If the delivery is at home, the delivery person accepts the cash and return any change. When
the delivery person comes to the shop, the he hands the cash over to the order taker. The
order taker indicates so to the system that the cash transaction was completed.
3.3 Create New Account Users: Shop Manager.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements:
Create new account use case starts at the discretion of the manager at any time during the
customer session use case if the manager offers the customer to open an account and the
customer accepts.
The manager asks for the customer for details such as name, address, phone number and
enters those in the system.
The system generates a customer identification. The manager hands over this identification to
the customer.
3.4 Account Settlement Users: Shop Manager, Cashier.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 2.3
Note: Account Settlement is an abstract generalization.
Account settlement use case is triggered at any time when a customer shows willingness to
settle an account. This may happen when the customer visits the shop or when the manager
calls up the customer reminding him of his outstanding amount during the customer credit
tracking use case. An order may be settled by either cash or credit card.
3.4.1 Cash Account Settlement
Users: Shop Manager, Cashier.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 2.3
Cash account settlement use case is triggered if the customer chooses to settle the account by
cash. This may happen when the customer visits the shop or when the manager calls up the
customer reminding him of his outstanding amount during the customer credit tracking use
case.
The manager or cashier informs the customer of the outstanding amount and asks him how
much amount he is willing to settle. The customer informs about full or partial settlement.
If the customer is in the shop, the customer provides the necessary cash immediately. The
manager or cashier accepts the cash and enters the amount to be settled against the customer
in the system. Optionally he also enters the cash details (number of notes, coins etc.) in the
system. If he does so, the system displays the amount of change that needs to be returned, if
any. The manager or cashier returns the appropriate change and indicates so to the system
that the cash transaction was completed.
If the customer is at home, the manager sends an employee to collect the cash from the
customer at home. When the employee returns with the cash, the manager accepts the cash
and enters the amount to be settled against the customer in the system.
23
3.4.2 Credit Card Account Settlement
Users: Shop Manager, Cashier.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 2.3
Credit card account settlement use case is triggered if the customer chooses to settle the
account by credit card. This may happen when the customer visits the shop or when the
manager calls up the customer reminding him of his outstanding amount during the
customer credit tracking use case.
The manager or cashier informs the customer of the outstanding amount and asks him how
much amount he is willing to settle. The customer informs about full or partial settlement.
The customer provides the credit card details. The manager or cashier enters the credit card
details on the system. Optionally, the system dials out to the credit card company number
and provides transaction information. The credit card company provides authorization code.
The system prints out a charge slip.
If the customer is in the shop, the customer signs the charge slip immediately.
If the customer is at home, the manager or cashier sends an employee to collect the signature
from the customer at home.
The manager or cashier accepts the charge slip and enters the amount to be settled against the
customer in the system.
3.5 Goods Returns Users: Shop Manager, Cashier.
Stakeholders: Domain specialist, Human-interaction designer.
Requirements: 1.5
Goods returns use case starts when a customer brings a returnable item in a returnable
condition back to the shop for the purpose of returning it.
The customer presents the returnable item to the order taker.
The order taker inspects the items and ensures that they are in returnable condition as per the
policies of the shop.
The order taker then asks the customer for proof of purchase (the receipt). He enters the
receipt number in the system to look up the transaction. If the customer does not provide the
receipt, the order taker may use at his discretion the customer name, date of transaction or
name of the item sold to look up the order in the system. Once he finds the transaction, he re-
verifies that the item is returnable (i.e. the date of transaction is within acceptable range, if the
transaction was completed through credit cards etc.) and marks the particular item as
returned in the system.
The system rolls back the item in the order and gives these choices to the order taker:
� Return cash amount
If the cashier or manager chooses this option, he returns the cash amount to the
customer – he may particularly do so if the original order was settled by cash.
� Give a credit token
If the cashier or the manager chooses this option, he prints a token that the customer
can redeem against future shopping as cash for some duration of time that the order
taker optionally decides.
24
� Give credit in account
This choice appears if the customer has an account with the shop. If the cashier or the
manager chooses this option, he adjusts the amount against the account of the
customer – he may particularly do so if the original order was settled by credit.
25
Chapter2. Architecture
2.1 Overall Architecture The layered view of the overall Architecture is as shown:
For customers requiring single terminal, all the layers of the above architecture diagram will
be packaged into a single terminal. In the case that multiple terminals are required, there will
be a master terminal which has the database server running on it. There can be one or more
terminals where the backup database will reside and any one of these terminals can take on
the role of master terminal in case the master terminal fails. The other terminals can connect
to the database server (over LAN) residing at the master. But these terminals will have the
processing capability and the same application layer as is present in the master terminal is
present on all of these. These terminals can also have some cache of part of the database, so
that they can operate standalone when not on network. There could as well be other dumb
terminals which can connect to the master terminal for all the activities. These various kinds
of terminals are shown in the figure below. Note that all these terminals are connected over a
LAN which could be wireless or wired.
Fig 2.2 Layered architecture over a LAN
The overall functionality can divided in following subsets::
a) Billing Customer + Customer Goods Returns Management + Transactions Summary
b) Vendor Accounts Maintenance + Expense Management + Vendor Returns Management +
Vendor Transactions Summary
c) Inventory tracking (database of all items up to date) + Order Management + Stock Filing +
Stock Checking
D e vic e sD e vic e s
O S
D B M SU I M g r
A + B + C
D e vic e sD e vic e s
O S
D B M SU I M g r
A + B + C
M a s t e r B a c k u p
T e r m in a l w it h o u t D B M S T e r m in a l w it h o u t D B M S
D e vic e sD e vic e s
O S
C a c h eU I M g r
A + B + C
D e vic e sD e vic e s
O S
C a c h eU I M g r
A + B + C
Devices
OS
UI Mgr A + B + C
A = Customer Management
B = Vendor Management
C = Administrative Activities
Fig 2.1 Layered architecture
diagram
DB Management System
26
d) Maintaining Customer Accounts
e) Customer Relationship Management (CRM)
f) Forecasting + Predictions
The software can be delivered to the client with one or more of the above functional aspects
provided that the dependences shown in the following dependence graph are satisfied:
2.2 Data Model
The following databases will be required for the system to carry out the requirements
detailed in the software requirements specification. In the Entity Relation Diagram, CO refers
to Customer Order, and VI refers to Vendor Invoice.
a
b
c
d
e
f
Fig 2.3 Dependence
Graph
27
Fig 2.4 ER Diagram
In the following we list the attributes of each of the tables, their primary keys (underlined)
and the foreign keys (if any)
1. Item
1. Item-Code
2. Description
3. IsReturnable
4. Type (loose/packed – if loose, it will have rate/unit, else it will have price)
2. Transient Item Info
1. Item-Code (foreign key)
2. Category-Code
3. Cost (per unit item)
4. Expiry-date
5. Vendor-id
28
6. Commission
7. ReturnDuration (Period until which the goods can be returned)
3. Transient Info
1. Item-Code
2. Category-Code
3. Quantity (the remaining quantity)
4. Safe-Quantity (this is the derived attribute and the system might modify this attribute
periodically. This is used to indicate whether the item is nearly out of stock)
4. Vendor Information
1. Vendor-Id
2. Name
3. Address
4. Phone
5. Supplies Items
1. Vendor-Id (foreign key)
2. Item-Code (foreign key)
3. Category-Code (foreign key)
6. Vendor Payment
1. Vendor-Id (foreign key)
2. Payment-Number
3. Date
4. Amount
5. Payment-Mode (this will be a finite domain attribute – {cash, credit-card, credit})
7. Purchase Order
1. Order-Id
2. Vendor-Id (foreign key)
3. Date
4. IsPending
5. Delivery Date
8. Purchase Details
1. Order-Id (foreign key)
2. Item-Code (foreign key)
3. Category-Code (foreign key)
4. Quantity (for each of the ordered item)
9. Delivery Discrepancy
1. Discrepancy-Id
2. Order-Id (foreign key)
3. Item-Code (foreign key)
4. Category-Code (foreign key)
5. Quantity
10. Customer Information
1. Customer-Id
2. Name
3. Address
4. Phone
5. Points (used for giving the discounts according to rules in table Loyalty Rules)
11. Customer Order (CO)
1. Order-Id
2. Customer-Id (foreign key)
3. Date
4. IsPending
29
5. Cost
6. Tax
7. Payment-Mode (enum data {cash, credit, credit card})
12. CO Contents
1. Order-Id (foreign key)
2. Item-Code (foreign key)
3. Category-Code (foreign key)
13. Customer Payment
1. Payment-Id
2. Order-Id (may be null, in case payment is not associated with single order)
3. Customer-Id (foreign key)
4. Date
14. Loyalty Rules
1. Min-Points
2. Max-Points
3. Discount-Percentage
15. Discount
1. Item-Code (foreign key)
2. Category-Code (foreign key)
3. Discount-Percentage
4. Min-Quantity
16. Reward Points
1. Min-Purchase
2. Max-Purchase
3. Points
2.3 Object Oriented Design
2.3.1 CRC Cards
The CRC cards for the various classes are as follows:
Class CustomerTransactionsScreen
Responsibilities Collaborators
Provide a navigation interface for different
screens
CustomerOrderScreen
DisplayWidgets CustomerOrderSettlementScreen
Create the different screens navigable from
this screen
CustomerGoodsReturnScreen
CustomerPaymentScreen
NewCustomerScreen
CustomerOrderSearchScreen
PendingCustomerOrderScreen
CustomerCreditSumaryScreen
Class CustomerOrderScreen
30
Responsibilities Collaborators
DisplayWidgets CustomerOrder
Pass on the values for Customer details to
CustomerOrder object
CustomerOrderSettlementScreen
Pass on the details(or just item id) of each
item entered to CustomerOrder object as
each item is added
NewCustomerScreen
Pass on the order status to the
CustomerOrder object
Create the CustomerOrderSettlement object Customer
Display the Order Settlement Screen when
done with the order
Class CustomerOrder
Responsibilities Collaborators
Add an item to the list and check the
consistency (in stock?)
Get Item Details from item identifier
Delete Item from the list
Add the customer identifier
Get Customer Details from the customer
identifier
Get Customer Details from the customer name
Compute tax
Compute total amount
Check if credit can be given to the customer
Set the payment mode
Set/Reset the pending order status
Compute discount
Commit the order
Class CreditCardSettlementScreen
Responsibilities Collaborators
31
Responsibilities Collaborators
Pass on the credit card information to the
CreditCardHandler object
CustomerOrder
Send the message to perform the credit card
transaction to CreditCardTransaction object
Prompt the status of credit card transaction CreditCardHandler
Class CreditCardHandler
Responsibilities Collaborators
Contact the credit card transaction gateway
Perform the credit card transaction for the
indicated amount
Set the status of the transaction
Class CustomerPaymentScreen
Responsibilities Collaborators
Display Widgets CustomerPayment
Pass on the credit card information to the
CreditCardHandler object
CreditCardHandler
Prompt the status of credit card transaction, if
credit card opted for
Class CustomerPayment
Responsibilities Collaborators
Set the customer identifier
Set the amount paid
Set the mode of paymennt
Commit the Payment
Class GoodsReturnScreen
Responsibilities Collaborators
Display Widgets CustomerGoodsReturn
Pass on the Order Identifier against which the
returns are made to CustomerGoodsReturn
object
32
Responsibilities Collaborators
For each item entered check from the
CustomerGoodsReturn object whether it is
valid for return
Pass on the mode of return payment to the
CustomerGoodsReturn object
Class GoodsReturn
Responsibilities Collaborators
Set the order identifier
Add return item to the list
Check if added item is consistent
Compute total return
Set the type of mode of payment
Commit the goods returned
Class NewCustomerScreen
Responsibilities Collaborators
Display Widgets Customer
Pass on the details of the customer to the
Customer object
Class Customer
Responsibilities Collaborators
Set the detials of Customer
Commit the details
The CRC cards for the Vendor activities are as follows:
Class VendorSummaryScreen
Responsibilities Collaborators
Display Widgets VendorSumary
Display the list of all vendors and optionally
vendor details
VendorStatementScreen
For any selected vendor show the list of items
supplied by him in a collapsible fashion / new
screen
VendorStatement
Create the VendorStatementScreen NewVendorScreen
33
Responsibilities Collaborators
Create the NewVendorScreen Vendor
Create the Vendor object PendingVendorOrderScreen
Cerate the VendorStatement object PendingVendorOrder
Class VendorSummary
Responsibilities Collaborators
Get the set of all registered vendors
For each vendor get the set of items supplied
by that vendor
Class VendorOrderScreen
Responsibilities Collaborators
DisplayWidgets VendorOrder
Pass on vendor details to VendorOrder object
Pass on each item added to the VendorOrder
object
Class VendorOrder
Responsibilities Collaborators
Set Vendor details
Check each item added for consistency
Compute total amount
Compute taxes
Commit the vendor order details
Class VendorGoodsReturnScreen
Responsibilities Collaborators
Display Widgets VendorGoodsReturn
Pass on the vendor order identifier to the
VendorGoodsReturn object
Pass on each of the items entered to
VendorGoodsReturn object for validity of
return
Pass on the amount and mode of payment to
VendorGoodsReturn object
34
Class VendorGoodsReturn
Responsibilities Collaborators
Set the vendor order identifier
Set the amount and mode of payment
Check each item for validity of return
Compute total amount
Commit the vendor goods return details
Class VendorPaymentScreen
Responsibilities Collaborators
Display Widgets VendorPayment
Pass on the amount and mode of payment to
the VendorPayment object
Class VendorPayment
Responsibilities Collaborators
Set the vendor identifier
Set the amount paid
Set the mode of payment
Commit the details
Class NewVendorScreen
Responsibilities Collaborators
Display Widgets Vendor
Pass on the details of Vendor to the Vendor
object
Pass on each item entered to the Vendor object
Class Vendor
Responsibilities Collaborators
Set the detials of Vendor
Add an item supplied by vendor
Commit the vendor details
35
Class VendorStatementScreen
Responsibilities Collaborators
Display Widgets VendorStatement
Pass on the VendorId to the VendorStatement
object
VendorOrderScreen
Create the VendorOrderScreen VendorOrder
Create the VendorGoodsReturnScreen VendorGoodsReturnScreen
Create the VendorOrder object VendorGoodsReturn
Create the VendorGoodsReturn object VendorPaymentScreen
Create the VendorPaymentScreen VendorPayment
Create the VendorPayment object
Class VendorStatement
Responsibilities Collaborators
Set the VendorId
Get data about all the vendor orders from the
selected vendor
Get data about all the payments made to the
selected vendor
Following are the CRC cards for Administrative activities:
Class AuthenticationScreen
Responsibilities Collaborators
DisplayWidgets Authentication
Pass on the username and password to the
Authentication object
LoggedUser
Display error message in case of failure
Pass on the username and role of that user to
the LoggedUser object
Class Authentication
Responsibilities Collaborators
Set the username
Set the password
Check whether the pair (username, pasword)
is valid
36
Responsibilities Collaborators
Get the role associated with username
Class LoggedUser
Responsibilities Collaborators
Set the logged username
Set the logged user role
Class AdministrativeActivitiesScreen
Responsibilities Collaborators
Provide a navigation interface for different
screens
StockSummaryScreen
Display Widgets ExpensesScreen
SalesTrendScreen
DemandForecastScreen
CashFlowScreen
LoyaltyProgramsSettingScreen
DiscountsSettingsScreen
RewardPointSettingsScreen
Class StockSummaryScreen
Responsibilities Collaborators
Display the list of items with their existing
quantities
StockSummary
Display Widgets
Class StockSummary
Responsibilities Collaborators
Get the list of items with their respective
existing quantities
Provide an iterator for the list
Class ExpensesScreen
Responsibilities Collaborators
Display Widgets Expenses
Provide input combos for entering date range
37
Responsibilities Collaborators
Display all the expense items between the date
range mentioned in this screen
Class Expenses
Responsibilities Collaborators
Set the start and end dates
Get the vendor expenses and other expenses
from the database
Provide an iterator for the expenses list
Class CustomerCreditSummaryScreen
Responsibilities Collaborators
Display Widgets CustomerCreditSummary
List for each customer who has outstanding
credit, the credit amount and the earliest date
of outstanding credit
Class CustomerCreditSummary
Responsibilities Collaborators
Get the list of customers that have outstanding
credit from the database
Provide an iterator for the list
Class PendingVendorOrderScreen
Responsibilities Collaborators
Display Widgets PendingVendorOrder
VendorOrderScreen
VendorOrder
Class PendingVendorOrder
Responsibilities Collaborators
Get the list of pending vendor orders from the
database
Provide an iterator for the list
38
Class PendingCustomerOrderScreen
Responsibilities Collaborators
Display Widgets PendingCustomerOrder
CustomerOrderScreen
CustomerOrder
Class PendingCustomerOrder
Responsibilities Collaborators
Get the list of pending customer orders from
the database
Provide an iterator for the list
Class SalesTrendScreen
Responsibilities Collaborators
Send the parameters on which trends are to be
computed to the AnalyzerAdapter object
SalesTrendAnalzer
Ask the analyzer to compute the results
Get and display the results
Class SalesTrendAnalyzer
Responsibilities Collaborators
Receive the data to be processed
Process the data
Send the results in standard format
Class DemandForecastScreen
Responsibilities Collaborators
Send the parameters on which trends are to be
computed to the AnalyzerAdapter object
AnalyzerAdapter
Ask the analyzer to compute the results
Get and display the results
Class AnalyzerAdapter
Responsibilities Collaborators
Set the data to be sent SalesTrendAnalyzer
39
Responsibilities Collaborators
Send the data in standard format DemandForecastAnalyzer
Receive the results in standard format RemoteAnalyzer
Class DemandForecastAnalyzer
Responsibilities Collaborators
Receive the data to be processed
Process the data
Send the results in standard format
Class RemoteAnalyzer
Responsibilities Collaborators
Read the remote address + port
Establish connection to remote service
Receive the data to be processed
Send the data to the remote processor
Convert the results in standard format
40
2.3.2 Interaction Diagrams
Fig 2.4 Interaction diagram for Customer Order
The Interaction diagram for Customer Order is as shown above.
The interaction diagram for Goods Return is shown below:
Fig 2.5 Interaction diagram for Good Return
41
The interaction diagram for add customer is as shown below:
Fig 2.6 Interaction diagram for adding Customer Screen
The interaction diagram for vendor summary and vendor statement is as shown below:
Fig 2.7 Interaction Diagram for Vendor Summary and Vendor Statement Screen
The interaction diagram for vendor order is as shown below:
42
Fig 2.8 Interaction diagram for Vendor Order Screen
The interaction diagram for sales trends is as shown below:
Fig 2.9 Interaction Diagram for Sales Trend Screen
43
2.4 Package Structure
We will now classify the classes that are required to carry out the functionality of each of the
subsets (a to f) that we had identified earlier
a) Billing Customer + Customer Goods Returns Management + Transactions Summary
• CustomerOrderScreen
• CustomerOrder
• CreditCardSettlementScreen
• CreditCardHandler
• GoodsReturnScreen
• GoodsReturn
• PendingCustomerOrderScreen
• PendingCustomerOrder
b) Vendor Accounts Maintenance + Expense Management + Vendor Returns Management +
Vendor Transactions Summary
• VendorSumaryScreen
• VendorSumary
• VendorStatementScreen
• VendorStatement
• VendorOrderScreen
• VendorOrder
• VendorGoodsReturnScreen
• VendorGoodsReturn
• VendorPaymentScreen
• VendorPayment
• NewVendorScreen
• Vendor
• ExpensesScreen
• Expenses
• PendingVendorOrderScreen
• PendingVendorOrder
c) Inventory tracking (database of all items up to date) + Order Management + Stock Filing +
Stock Checking
• StockSummaryScreen
• StockSummary
• StockFilingScreen
• StockFiling
d) Maintaining Customer Accounts
• NewCustomerScreen
• Customer
e) Customer Relationship Management (CRM)
• CustomerCreditSumaryScreen
• CustomerCreditSummary
• LoyaltyProgramsSettingScreen
• DiscountsSettingsScreen
• RewardPointSettingsScreen
f) Administration + Forecasting + Predictions
• Authentication
• AuthenticationScreen
• LoggedUser
• SalesTrendScreen
44
• SalesTrendAnalyzer
• DemandForecastScreen
• DemandForecastAnalyzer
• AnalyzerAdapter
• RemoteAnalyzer
2.5 User Interface Diagrams
Admin Screens o Admin screen
• Start-up
o Please Authenticate Yourself screen
• Stock taking
o Stock Summary screen / print
� Stock Item screen
• Setting up customer loyalty benefits
o Loyalty Program Scheme Settings screen
o Special Customer Settings screen
o Rewards Points Rules screen
� New Reward Points Rule
o Reward Points Redemption Rules screen
� New Reward Points Redemption rule screen
o Discounts screen
� New Discount screen
• Preparing the orders and demand forecasting + Cash flow forecasting + Setting up
discounts and sales
o Sales Trends screen / print
� Select Options screen
o Demand Forecast screen / print
� Set Forecast Parameters screen
o Cash Flow Forecast screen / print
� (same Set Forecast Parameters screen as demand forecast)
o Discounts Schemes Summary screen / print
� New Discount Scheme screen / print
o Pending Orders Summary screen / print
� Order screen / print (has options for each item: Order quantity,
frequency, Delivery challan quantity, Verified filed quantity, Damage /
discrepancy quantity, Sold, Unsold, Returned, Bill quantity, Bill amount,
Contested amount) tracks to DC no/date, bill no/date, allows multiple
45
DCs, bills, POs to be linked to each other. Think about this, it is not easy
to visualize as one view!!!!!!!!
• Customer credit tracking
o Customer Group Credit Summary screen
� Create New Group screen
� Customer Group Trends screen
� Customer Credit Summary screen
• Customer Bill screen
• Customer Trend screen
• Filing stocks
o Filing Stock Item screen
� Bar Code print
• Expenses
o Enter Expense Voucher screen
� Set Expense as Recurring screen
• Shut-down
o Shut-down Confirmation screen
Vendor Session Screens o Vendors Summary screen
� Add / Edit Vendor screen
• Add / Edit Vendor Item screen
� Vendor Statement screen
• Vendor Payment screen
� (same Order screen / print in preparing orders use case)
� Create new vendor account
o (same Add / Edit Vendor screen as above)
� Placing orders
� (same Order screen / print in preparing orders use case)
� Accepting delivery and billing
� (same Order screen / print in preparing orders use case)
� Vendor returns
� (same Order screen / print in preparing orders use case)
� Vendor settlement
� (same as Vendor Payment screen)
46
Customer Session Screens � Ordering
o Order / Bill screen
� Up-sale Items screen
� Recurring Order screen
� Credit Card Transaction screen
� Credit Transaction screen
� Add / Edit Customer screen
� Order Settlement
� (same Order / Bill screen as above)
� Creating New Account
� (same Add / Edit Customer screen as above)
� Account Settlement
o Customer Statement screen
� (same Order / Bill screen as above)
� Goods Returns
o Search Order / Bill screen
� (same Order / Bill screen as above)
All the screens to be designed are listed below o Admin screen
o Please Authenticate Yourself screen
o Stock Summary screen / print
� Stock Item screen
o Loyalty Program Scheme Settings screen
o Special Customer Settings screen
o Rewards Points Rules screen
� New Reward Points Rule
o Reward Points Redemption Rules screen
� New Reward Points Redemption rule screen
o Discounts screen
� New Discount screen
o Sales Trends screen / print
� Select Options screen
o Demand Forecast screen / print
47
� Set Forecast Parameters screen
o Cash Flow Forecast screen / print
� (same Set Forecast Parameters screen as demand forecast)
o Discounts Schemes Summary screen / print
� New Discount Scheme screen / print
o Pending Orders Summary screen / print
� Order screen / print (has options for each item: Order quantity,
frequency, Delivery challan quantity, Verified filed quantity, Damage /
discrepancy quantity, Sold, Unsold, Returned, Bill quantity, Bill amount,
Contested amount) tracks to DC no/date, bill no/date, allows multiple
DCs, bills, POs to be linked to each other. Think about this, it is not easy
to visualize as one view!!!!!!!!
o Customer Group Credit Summary screen
� Create New Group screen
� Customer Group Trends screen
� Customer Credit Summary screen
• Customer Bill screen
• Customer Trend screen
o Filing Stock Item screen
� Bar Code print
o Enter Expense Voucher screen
� Set Expense as Recurring screen
o Shut-down Confirmation screen
o Vendors Summary screen
� Add / Edit Vendor screen
• Add / Edit Vendor Item screen
� Vendor Statement screen
• Vendor Payment screen
� (same Order screen / print in preparing orders use case)
o (same Add / Edit Vendor screen as above)
� (same Order screen / print in preparing orders use case)
� (same Order screen / print in preparing orders use case)
� (same Order screen / print in preparing orders use case)
� (same as Vendor Payment screen)
o Order / Bill screen
� Up-sale Items screen
� Recurring Order screen
48
� Credit Card Transaction screen
� Credit Transaction screen
� Add / Edit Customer screen
� (same Order / Bill screen as above)
� (same Add / Edit Customer screen as above)
o Customer Statement screen
� (same Order / Bill screen as above)
o Search Order / Bill screen
� (same Order / Bill screen as above)
o Enter Expense Voucher screen
� Set Expense as Recurring screen
o Shut-down Confirmation screen
49
Fig 2.10 UI Diagram
Admin
screen
Settings
screen
Trends and
Forecasts screen
Expense
Voucher screen
Filing Stock
screen
Vendors
Summ. screen
Vend. Statement
screen Add / Edit Vend.
Item screen
Vend. Payment
screen
Add / Edit
Vend. screen
Order / Bill
screen
Up-sale Items
screen
Recurring
Order screen
Credit Card
Trx screen
Up-sale Items
screen
Credit Trx
screen
Add / Edit
Cust. screen
Search Order
/ Bill screen
Authentication
screen
Loyalty Prog.
Settings screen
Sp. Cust.
Settings screen
Reward Pts.
Rules screen
Sales Trends
screen
Stock Summary
screen
From any
screen
Pending
Orders screen
Cust. Credit
Summ. screen
Cust. Statement
screen
Discount Schemes
Settings screen
Cash Flow
Forecast screen
Redemption
Rules screen
Demand
Forecast screen
Vend. Order
screen
50
Chapter3 Test Case and QA
3.1 Test Cases
1. Test case for Goods return
Input for ‘Goods return test’ is Customer OrderID, Items, Units, Numbers, and Amount. When
goods are returned we have variants of test cases in terms of 1. If goods are returned with no
substituted item for the same and money is repaid back to the customer. Secondly, if items are
returned, then returned goods are substituted by another item and difference amount is returned.
So, outputs are either money or difference amount and substituted item.
Entries in this colour are provided by tester as an input for the test.
Test case 1
Inputs Goods returned Substituted Items
OrderID Items Unit Nos. Rate Amount
4367 Lux 75g 1 8.50 8.50
Tax 0
Discount 0
Total 1 8.50
No
Actual Output Return Cash Rs8.50
Expected Output Return Cash Rs8.50
Settlement
Test case 2
Inputs Goods returned Substituted Items
OrderID Items Unit Nos. Rate Amount OrderID Items Unit Nos. Rate Amount
4367 Lux 75g 2 8.50 17.00 4367 Rexona 75g 2 8.00 16.00
Amul
Ghee
1
Kg
1 120.00 120.00 Britannia
Ghee
1
Kg
1 110.00 110.00
Tax 0 0
Discount 0 0
Actual
Output
Total 3 137.00 1 126.00
Return Cash Rs 21.00
Expected
Output
Total 3 137.00 3 126.00
Return Cash Rs 11.00
Settlement
51
2. Test case for Order Bill
Inputs to this test case are Customer Order ID, Items, Units, Numbers, Rate and expected output
is supposed be Total amount including tax and discount if any.
Test case 1
Inputs Goods returned
OrderID Items Unit Nos. Rate Amount
4367 Lux 75g 2 8.50 17.00
Amul Ghee 1Kg 1 120.00 120.00
Tax 0
Discount 0
Actual Output Total 3 137.00
Expected Output Total 3 137.00
3. Test case for Credit Transaction
For credit transaction Inputs to the test case are OrderID, Total amount, Pay Mode, Amount Paid,
Previous Outstanding and Expected output will be the Total amount due which should be less
than performance measure specified. Here variants of pay mode may be cash, credit card or
cheque.
Performance measure is that the total credit limit that can be kept due is Maximum 1000.
Test Case 1
Inputs OrderID Total
amount
A
Pay
Mode
Amount
Paid
B
Previous
Outstanding
C
Total amount due
D=A+C-B
4367 137.00 Cash 200.00 456.00
Actual Output 393.00
Expected Output 393.00
Test case 2
Inputs OrderID Total
amount
A
Pay Mode Amount
Paid
B
Previous
Outstanding
C
Total amount due
D=A+C-B
4367 600.00 CreditCard 300.00 800.00
Actual
Output
1100.00
Expected
Output
1100.00
52
So, here for a given order the total amount due though Rs. 1100.00 but the fact that total amount
paid that can be due should not be more than 1000.00 as constrained by the administrator the
above test case is used to check this consistency.
Test case 3
Inputs OrderID Total
amount
A
Pay
Mode
Amount
Paid
B
Previous
Outstanding
C
Total amount
due
D=A+C-B
4367 137.00 Cheque 393.00
Actual Output 200.00
Expected Output 200.00
4. Test case for Add Customer
Input to this test case is Name of new customer; Address, phone number and output to this add
customer case is the Customer ID with stored inputs.
Test case 1
Inputs Add Customer
Name Address Phone Customer ID
Vikas Kumar #42, LBS Marg,
Mumbai-76
022-23456578
Actual
Output
Vikas Kumar #42, LBS Marg,
Mumbai-76
022-23456578 3426
Expected
Output
Vikas Kumar #42, LBS Marg,
Mumbai-76
022-23456578 3426
Input to this test case is Name of new customer, Address, phone number and output to this
delete customer case is the Deleted Customer ID and allied information.
Test case 2
Inputs Delete Customer
3426
Actual Output
Expected Output
5. Test case for Sales trends
Inputs to the sales trend test case is the previous demand information for few months and
Expected output will be the sales trend for next three months
53
Test Case 1
Inputs Sales trends
Previous demand (say last 12 months) Sales Forecast for next 3 months
200; 234; 300 250; 310; 330
Actual Output 250; 310; 330
Expected Output 250; 310; 330
6. Test case for Vendor Statement
Input for this test case is Vendor ID. Expected output to this is a whole statement for that
particular vendor.
Test case 1
Input VendorID
2453
Vendor Statement
VendorID Items Qty. Unit Rate Amount
Mode of
payment
Amount
paid
Balance
2453 Lux 1 100X100g 900.00 900.00
Cash
Actual
Output
Britania
Ghee
5 10X1Kg 1100.00 5500.00
5000.00 1400.00
2453 Lux 1 100X100g 900.00 900.00
Cash
5000.00 1400.00
Britania
Ghee
5 10X1Kg 1100.00 5500.00
Expected
Output
Total 6400.00 5000.00 1400.00
7. Test case for Vendor order screen (for order preparation for the particular vendor)
Inputs for this test case are Vendor ID, Item name, Units which is expected is total amount to be
given to the vendor.
Test Case 1
Input Vendor ID Items Ordered Units
4500 Lux Soap 10 0
Britania Ghee 50 Kg
54
Actual Output
Expected Output
4501 Chana Daal 100 Kg
Actual Output
Expected Output
8. Test case for Vendor Summary screen
Vendor summary screen will have the input Vendor ID. Output in this case will be Order
pending, Amount of order pending, and mode of payment etc.
Test Case 1
Input Vendor ID
4500
Actual Output Vendor ID Order
Pending
Amount of order
pending
A
Amount
Paid
B
Previous
Balance
C
Mode of
payment
Outstanding
Due
A-B+C
4500 Oil (50Lit) 2500.00 2500.00
Sugar(100Kg) 1400.00 1000.00
0 Cash 400.00
Total 3900.00 3500.00 0 400.00
Expected Output Vendor ID Order
Pending
Amount of order
pending
A
Amount
Paid
B
Previous
Balance
C
Mode of
payment
Outstanding
Due
A-B+C
4500 Oil (50Lit) 2500.00 2500.00
Sugar(100Kg) 1400.00 1000.00
0 Cash 400.00
Total 3900.00 3500.00 0 400.00
3.2 Testing Method and Test Optimization
Next the Method used for testing is BLACK BOX TESTING and technique under this heading
will be the Orthogonal array of size L5 method.
One example of the orthogonal testing is as follows-
Say Authentication to the system test case.
Pi = 1, Allow authentication
= 2, Allow authentication if failed in earlier login attempt
55
TEST CASES Authentication
TEST PARAMETER
User ID & Pswd
P1
Thumb
P2
Both
P3
1 1 1 1
2 1 2 2
3 1 1 2
4 2 2 2
5 2 2 1
3.3 Quality Assurance Review
1. There is no provision of workforce scheduling screen. There may be the case where some
shop may have many staff for operation. In that case workforce scheduling (algorithm)
screen would help manager and cut down the cost arises due to inefficient scheduling.
2. There is only VendorID. There should also be VendorOrderID created each time the
order is placed to the vendor so that every order can be grouped in one screen for each
vendor.
3. There is provision of only OrderID. Many orders can be placed by single customer. So
there should also be provision for CustomerID.
4. Vendor should be categorized on the basis of company/brand/make/category of goods.
This will help when implementing this package in the retail stores.
5. Customers can also be categorized on basis of buying behavior like recurring orders,
food grains orders, etc.
6. In AddCustomerScreen e-mail ID field is missing.
7. There should also be daily/weekly/monthly sales/inventory/pending order/cash flow
summary screens.
8. Vendor order Screen should be differentiated whether it is meant for order preparation
for particular vendor or for inquiring about the last order placed with the vendor.
Quality Performance Measures
1. Switching from one screen to other screen should happen within 2 sec.
2. Operator should able to switch from any screen to bill screen within a fraction of second,
say half second.
3. Booting time of the system should be less than (<) 5 Sec.
4. Maximum credit privilege given to the regular customer should be maximum up to
Rs.1000 (Can be modified by manager depending upon the creditability of the customer.)
5. System down time should not be more than half an hour and particularly should not be
during 5.00-9.00pm (Peak time).
6. Minimum inventory level for each item should be defined in order to avoid the stock -
outs.
7. Reliability of the system should be high.
8. Other issues that may be considered are-
56
• Usability of the system
• Traceability of requirements
• Understandability – this can be assured from extensive documentation externally
as well as internally to the program so as to help in maintenance.
• Maintainability
• Availability
57
Chapter4 Estimation
Functional Point Analysis:
It’s a unit to measuring the size of a application. It is used it estimating the work content of any
software application and covers all stages of project and counts function points around a single
application boundary. It is independent of technology and the system/program design.
Identification of counting boundary:
♦ Boundary indicates the border between the applications.
♦ Boundary establishes:
o Scope of the application
o Data ownership of the appliacation
o Processing relationships, eg where it occurs.
Schematic depication of components of function point count
EI- External Input
EO – External output
EQ – External Enquiries
ILF-Internal Logical Files
EIF – External Interface files
Users
ILF EIF
Other system
EO EQ
System
boundary
58
♦ Unadjusted Function Point Count Method
Transfer Type DET(data
element type)
RET(record
element type)
Complexity Weight
Customer Details EI 15 3 H 6
Customer order EI 3 1 L 6
Credit Card Details EI 5 1 L 6
Customer mode of payment EI 5 1 L 6
Order identifier EI 3 1 L 6
Mode of return payment EI 5 1 L 6
Vendor details EI 15 3 H 6
Authentication EI 3 1 L 6
Pending vendor order EI 5 1 L 6
Demand forecasting EI 5 1 L 6
Discount setting EI 5 1 L 6
Order statement EQ 5 1 L 4
Vendor statement EQ 15 1 L 4
Item details EO 19 3 A 5
Status of credit card
availability
EO 5 1 L 5
Details of user EO 19 3 A 5
Expense EO 5 1 L 5
Customer credit summary EO 5 1 L 5
Sales trend screen EO 5 1 L 5
Cashflow screen EO 5 1 L 5
Order statement EO 5 1 L 5
Status of customer order ELF 5 1 L 5
Item details file ELF 19 3 A 5
Customer details file ILF 19 1 L 7
Customer order ILF 19 1 L 7
Vendor information file ILF 19 1 L 7
Vendor payment file ILF 19 1 L 7
Cash memo/recipt ILF 19 1 L 7
UFPA=159
59
*DET – Data Element Type is a unique user-recognizable, non-recursive field in ILF/EIF
*RET – Record Element Type is a unique user recognizable subgroup of data element within an
ILF/EIF
* A stands for average
* H stands for high
* L stands for low
Suggested work norms for FPA
For CPP - 12 hours/FP
So, total no. of man-hrs=159 * 12 = 1908 man-hrs
If 6 developer works for 8 hours daily then no. of days required is
= 1908/(6*8)=40 days
Therefore two months of effort required by 6 developer working 8 hrs daily and 20 days per
month.
60
5. Bibliography
1. Pressman, R., S., Software Engineering - A Practioner's Approach (6th en), McGraw Hill
International Edition, 2005.
2. Kelkar, S., A., Software Project Management, Prentice Hall India, New Delhi, 2004.