supply chain management plan

Office Depot®

Offic Depot®

Office Depot®

Office Depot®

Office Depot®

Offic Depot®

Offic Depot®

Office Depot®

Office Depot®

Offic Depot®

Office Depot®

Office Depot®

Office Depot®

Offic Depot®

Office Depot®

Office Depot®

Office Depot®

Offic Depot®

Office Depot®

Office Depot®

Office Depot®

Offic Depot®

Office Depot®

Office Depot®

Office Depot®

®

Offic Depot®

Office Depot®

Offic Depot®

Office Depot®

Offic Depot®

Office Depot®

Office Depot®

Office Depot®

Offic Depot®

Office Depot®

Office Depot®

Office Depot®

Offic Depot®

Offic Depot®

Office Depot®

Office Depot®

®

Offic Depot®

Office Depot®

Office Depot®

Office Depot®

Offic Depot®

Office Depot®

Office Depot®

Office Depot®

Course CMPE 221 – Software Engineering Professor

Dr. Lee Chang Students

Cuong Pham Donny Chan

e

e

e e

e

ee

e

e

Reorganizing Supply Chain Management

(SCM)

for the Corporation Business Strategy

e

e

e eee eSupply Chain Management

Plan

Offic Depot® Office Depot®

Offic Depot

eProject Report

Office Depot®

e

l

DepotOffic

of 206 OfficeDepot™ - Confidential

Table of Contents

1. INTRODUCTION..........................................................................................................................6 1.1 OFFICE DEPOT TODAY ..........................................................................................................................6 1.2 DRAMATIC GROWTH OVER 15 YEARS....................................................................................................6 1.3 NEW LEADERSHIP OPENS EXCITING NEW CHAPTER IN COMPANY HISTORY .............................................7 1.4 SUPPLY CHAIN MANAGEMENT- SUPPLY CHAIN MANAGEMENT DEFINED...................................................7 1.5 BUSINESS CHALLENGES AND OPPORTUNITIES........................................................................................8

1.5.1 Customer Retention......................................................................................................................8 1.5.2 Complexity of Extended Supply Chains.......................................................................................8 1.5.3 The Challenge of the Internet .......................................................................................................9

1.6 SUPPLY CHAIN MANAGEMENT (SCM): FEATURES AND BENEFITS............................................................9 1.6.1 Features......................................................................................................................................10

1.6.2 BENEFITS .........................................................................................................................................10 1.6.3 Inventory Reductions ..................................................................................................................10 1.6.4 Increased Customer Satisfaction................................................................................................10 1.6.5 Revenue Growth.........................................................................................................................10 1.6.6 Throughput Improvements..........................................................................................................11 1.6.7 Operating Cost Reduction ..........................................................................................................11 1.6.8 Implementing Effective Supply Chain Management Strategies .................................................11

1.6.8.1 Manage inventory investment in the chain:.........................................................................11 1.6.8.2 Establish supplier relationships:...........................................................................................11 1.6.8.3 Increase customer responsiveness: ....................................................................................11 1.6.8.4 Build a competitive advantage for the channel: ...................................................................12 1.6.8.5 Introduce supply chain management solutions and enabling information technology:........12

2. REQUIREMENTS......................................................................................................................13 2.1 BUSSINES MODELING...........................................................................................................................13

2.1.1 Business Vision...........................................................................................................................13 2.1.1.1 Vision Statement ..................................................................................................................13 2.1.1.2 Goal Model ...........................................................................................................................14 2.1.1.3 Conceptual Model ................................................................................................................15

2.1.2 Business Structure.....................................................................................................................16 2.1.2.1 Resource Structure Diagram................................................................................................16 2.1.2.2 Organization Structure ........................................................................................................17

2.1.3 Business Behavior ......................................................................................................................18 2.1.3.1 Sequence Diagram for Interaction Analysis.........................................................................18 2.1.3.2 Process Diagram................................................................................................................19 2.1.3.3 Process Decomposition for Forecasting ..............................................................................20 2.1.3.4 Process Decomposition for Planning ...................................................................................21 2.1.3.5 Process Decomposition for Warehousing-Store transfer.....................................................22 2.1.3.6 Process Decomposition for warehouse-warehouse transfer ..............................................23 2.1.3.7 Process Decomposistion Diagram for Order Tracking........................................................24 2.1.3.8 Process Decomposition Diagram for Purchasing ...............................................................25 2.1.3.9 Process Decomposition Diagram for System Inventory Management ...............................26 2.1.3.10 Assembly Diagram ............................................................................................................27

2.2 FUNCTION FEATURES...........................................................................................................................28 2.2.1 SCM Strategy.............................................................................................................................28 2.2.2 System Inventory Management (Track Inventory Level) ...........................................................28 2.2.3 Forecasting ................................................................................................................................28 2.2.4 Planning .....................................................................................................................................29 2.2.5 Requisition .................................................................................................................................29 2.2.6 Purchasing .................................................................................................................................29


2.2.7 Suppliers’ performance measurement (Suppliers scoring)........................................................30 2.2.8 Transacting – Action tracking and Cost calculating..................................................................30 2.2.9 Warehousing.............................................................................................................................30 2.2.10 Tracking ..................................................................................................................................31 2.2.11 Receiving ................................................................................................................................31

2.3 USE CASE MODEL ..............................................................................................................................32 2.3.1 Forecasting............................................................................................................................33

2.3.1.1 Use Case Forecasting .......................................................................................................33 2.3.1.2 Use Case Diagram: Forecasting........................................................................................34 2.3.1.3 Sequence Diagram: Forecasting .......................................................................................35 2.3.1.4 Contract: Forecasting ........................................................................................................36

2.3.2 Planning .....................................................................................................................................37 2.3.2.1 Use Case Planning ............................................................................................................37 2.3.2.2 Use Case Diagram: Planning ............................................................................................38 2.3.2.3 Sequence Diagram: Planning............................................................................................38 2.3.2.4 Contract: Planning .............................................................................................................39

2.3.3 Purchasing .................................................................................................................................40 2.3.3.1 Use Case Purchasing ........................................................................................................40 2.3.3.2 Use Case Diagram: Purchasing ........................................................................................40 2.3.3.3 Sequence Diagram: Purchasing........................................................................................41 2.3.3.4 Contract: Purchasing .........................................................................................................42

2.3.4 Supplier performance ............................................................................................................43 2.3.4.1 Use Case Supplier performance........................................................................................43 2.3.4.2 Use Case Diagram: Supplier performance........................................................................43 2.3.4.3 Sequence Diagram: Supplier performance .......................................................................44 2.3.4.4 Contract: Supplier performance.........................................................................................44

2.3.5 System Inventory Management.............................................................................................45 2.3.5.1 Use Case: System Inventory Management .......................................................................45 2.3.5.2 Use Case Diagram: System Inventory Management ........................................................46 2.3.5.3 Sequence Diagram: System Inventory Management........................................................47 2.3.5.4 Contract: System Inventory Management .........................................................................47

2.3.6 Order Tracking.......................................................................................................................48 2.3.6.1 Use Case Order Tracking ..................................................................................................48 2.3.6.2 Use Case Diagram: Tracking.............................................................................................49 2.3.6.3 Sequence Diagram: Order Tracking..................................................................................50 2.3.6.4 Contract: Order Tracking ...................................................................................................50

2.3.7 Warehousing .........................................................................................................................51 2.3.7.1 Use Case Warehousing.....................................................................................................51 2.3.7.2 Use Case Diagram: Warehousing .....................................................................................54 2.3.7.3 Sequence Diagram: Warehousing.....................................................................................54 2.3.7.4 Contract: Warehousing ......................................................................................................55

2.3.8 Receiving...............................................................................................................................56 2.3.8.1 Use Case Receiving ..........................................................................................................56 2.3.8.2 Use Case Diagram: Receiving...........................................................................................56 2.3.8.3 Sequence Diagram: Receiving ..........................................................................................57 2.3.8.4 Contract: Receiving ...........................................................................................................57

3. ANALYSIS .....................................................................................................................................59 3.1 ANALYSIS CLASSES.............................................................................................................................59

3.1.1 Class Diagram.......................................................................................................................59 3.1.1.1 Forecasting ........................................................................................................................59 3.1.1.3 Purchasing ..........................................................................................................................61 3.1.1.4 Supplier's Performance.......................................................................................................62 3.1.1.5 Order Tracking ....................................................................................................................63 3.1.1.6 Warehousing......................................................................................................................64 3.1.1.7 System Inventory Management.........................................................................................66 3.1.1.8. Receiving.............................................................................................................................67

3.1.1 Use-Case Realization............................................................................................................68 3.1.2.1 Forecasting ........................................................................................................................68


3.1.2.2 Planning .............................................................................................................................69 3.1.2.3 Purchasing.........................................................................................................................70 3.1.2.4 Supplier’s Performance .....................................................................................................71 3.1.2.5 Tracking Order...................................................................................................................72 3.1.2.6 Warehousing......................................................................................................................73 3.1.2.7 System Inventory Management.........................................................................................75 3.1.2.8 Receiving ...........................................................................................................................76

3.1.3 Package .....................................................................................................................................77 3.1.3.1 Forecasting ........................................................................................................................77 3.1.3.2 Planning .............................................................................................................................78 3.1.3.3 Purchasing.........................................................................................................................79 3.1.3.4 Supplier’s Performance .....................................................................................................80 3.1.3.5 Order tracking ....................................................................................................................81 3.1.3.6 Warehousing......................................................................................................................82 3.1.3.7 System Inventory Management.........................................................................................83 3.1.3.8 Receiving ...........................................................................................................................84

3.1.4 Architectural View (Significant elements, tracabilities)..........................................................85 3.1.4.1 Forecasting ........................................................................................................................85 3.1.4.2 Planning .............................................................................................................................86 3.1.4.3 Purchasing.........................................................................................................................87 3.1.4.4 Supplier’s Performance .....................................................................................................88 3.1.4.5 Order Tracking...................................................................................................................89 3.1.4.6 Warehousing......................................................................................................................90 3.1.4.7 System Inventory Management.........................................................................................91 3.1.4.8 Receiving ...........................................................................................................................92

4. DESIGN ...........................................................................................................................................93 DESIGN CLASSES ......................................................................................................................................94

4.1.1 Forecasting............................................................................................................................94 4.1.2 Planning.................................................................................................................................96 4.1.3 Purchasing ..................................................................................................................................99 4.1.4 Supplier Performance ...............................................................................................................102 4.1.5 Tracking...............................................................................................................................104 4.1.6 Warehousing..........................................................................................................................106 4.1.7 System Inventory Management...........................................................................................110 4.1.8 Receiving.............................................................................................................................114 4.1.9 Common classes.................................................................................................................116

4.2 DESIGN SUBSYSTEMS ...................................................................................................................117 4.2.1 Forecasting ..............................................................................................................................117 4.2.2 Planning ..................................................................................................................................118 4.2.3 Purchasing ................................................................................................................................119 4.2.4 Supplier Performance ..............................................................................................................120 4.2.5 Tracking ...................................................................................................................................121 4.2.6 Warehousing.............................................................................................................................122 4.2.7 System Inventory Management...........................................................................................123 4.2.8 Receiving.............................................................................................................................124 4.2.9 Dependencies and layers....................................................................................................125

4.3 USECASE REALIZATION .................................................................................................................128 4.3.1 Forecasting..........................................................................................................................128 4.3.2 Planning...............................................................................................................................129 4.3.3 Purchasing ................................................................................................................................130 4.3.4 Supplier Performance ...............................................................................................................131 4.3.5 Tracking ....................................................................................................................................132 4.3.6 Warehousing.............................................................................................................................133 4.3.7 System Inventory Management...........................................................................................135 2.3.1 Receiving.............................................................................................................................142

4.4 DATABASE DESIGN .......................................................................................................................143 4.5 ARCHITECTURAL VIEW ................................................................... ERROR! BOOKMARK NOT DEFINED. 4.6 DEPLOYMENT MODEL....................................................................................................................145


5. IMPLEMENTATION ...............................................................................................................147 5.1 IMPLEMENTATION SUBSYSTEMS .....................................................................................................148

5.1.1 Forecasting..........................................................................................................................148 5.1.2 Planning...............................................................................................................................149 5.1.3 Purchasing ................................................................................................................................150 5.1.4 Supplier Performance ...............................................................................................................151 5.1.6 Warehousing.............................................................................................................................153 5.1.7 System Inventory Management ................................................................................................154

5.2 COMPONENTS...............................................................................................................................156 5.2.1 Forecasting..........................................................................................................................156 5.2.2 Planning...............................................................................................................................158 5.2.4 Purchasing ................................................................................................................................161 5.2.4 Supplier Performance ...............................................................................................................163 5.2.6 Warehousing.............................................................................................................................166 5.2.7 System Inventory Management...........................................................................................167

5.3 ARCHITECTURAL VIEW ..................................................................................................................172 5.4 PROTOTYPE..................................................................................................................................173

6. TEST................................................................................................................................................179 6.1 TEST CASES .................................................................................................................................180 6.1.1 TEST CASE FOR FORECASTING: .......................................................................................................180 6.1.2 TEST CASE FOR PLANNING ..............................................................................................................181 6.1.3 TEST CASE FOR PURCHASING..........................................................................................................183 6.1.4 TEST CASE FOR SUPPLIER PERFORMANCE:......................................................................................185 6.1.5 TEST CASE FOR TRACKING: .............................................................................................................187 6.1.6 TEST CASE FOR WAREHOUSE-WAREHOUSE TRANSFER: ...................................................................188 6.1.7 TEST CASE FOR WAREHOUSE-STORE TRANSFER: ............................................................................189 6.1.8 TEST CASE FOR SYSTEM INVENTORY MANAGEMENT: ........................................................................191 6.1.9 TEST CASE FOR RECEIVING: ............................................................................................................192 6.2 TEST MANAGEMENT ......................................................................................................................194

APPENDICES...........................................................................................................................................199 A. GLOSSARY..........................................................................................................................................199 B. REFERENCES ......................................................................................................................................202 C. PROTOTYPE.......................................................................................................................................203

VERSION HISTORY.................................................................................................................................204


1. Introduction

1.1 Office Depot Today

Office Depot, Inc. is the world’s largest supplier of office products and services. The Company’s selection

of brand name office supplies includes business machines, computers, computer software and office

furniture, while its leading-edge business services encompass copying, printing, document reproduction,

mailing and shipping. Office Depot’s customers include small office/home office (SoHo), medium-sized

and large businesses located in the U.S. and in 17 other countries around the globe.

The Company sells its products through multiple distribution channels, including more than 950 office

supply stores, direct mail, global Internet sites, business-to-business e-commerce, and sales forces.

Office Depot operates under the Office Depot, Office Depot Express and The Office Place names, while

its contract and catalog businesses operate under the names Office Depot and Viking Office Products. An

S&P 500 company, Office Depot generates revenues of $12 billion annually and has 48,000 employees

worldwide. The Company’s common stock trades on the New York Stock Exchange under symbol ODP.

1.2 Dramatic Growth Over 15 Years

While Office Depot is clearly a powerful organization today, the Company’s beginnings were quite

modest. Office Depot was founded in Florida in 1986 and opened its first store in Fort Lauderdale. In late

1987, David I. Fuente assumed the post of Chairman and Chief Executive Officer of the fledging

company, and took Office Depot public in 1988. Fuente immediately began to execute an ambitious plan

to expand the Company’s footprint in key U.S. markets. The results were dramatic: By the end of 1990

Office Depot had 173 stores in 27 states. That same year, Office Depot merged with The Office Club,

Inc., becoming the largest office products retailer in North America.

Domestic growth, however, was only one aspect of Office Depot’s expansion in the Company’s early

years; the management team had its sights set on penetrating international markets as well. Early 1992

marked the Company’s acquisition of H.Q. Office International, Inc., which included the Great Canadian

Office Supplies Warehouse chain in western Canada. Growing steadily, the Company also opened new

retail stores in Israel and Colombia under international licensing agreements.

As Office Depot expanded geographically, the Company also began to extend beyond its traditional

markets. In 1993, Office Depot entered the rapidly consolidating contract stationer business by acquiring

two market leaders: Wilson Stationary & Printing Company and Eastman Office Products Corporation.

The merger of six additional contract stationers followed these purchases during 1994. These moves

positioned Office Depot to take advantage of industry trends that would come to play a central role in the

Company’s success.


In the meantime, Office Depot continued its steady international growth. Between 1995 and 1998, the

Company opened stores in Poland, Hungary and Thailand under international licensing agreements, and

in Mexico, France and Japan under joint venture agreements. Later, the Company acquired the interests

of its joint venture partners in both France and Japan.

In 1998, Office Depot merged with Viking Office Products, a public company and the world’s leading

direct mail marketer of office products. The addition of Viking to the Office Depot organization not only

vastly expanded Office Depot’s international presence, but also made the Company the leading provider

of office products and services in the world.

That same year, Office Depot began to leverage the Internet aggressively, launching the first of a number

of new Web sites, www.officedepot.com. The award-winning site established Office Depot as the

industry’s technology leader, expanded its domestic e-commerce capabilities, and ultimately extended the

range of products and services the Company could offer its customers. The following year, the Company

launched its first European e-commerce site, www.viking-direct.co.uk, in the U.K. Today, the Company

has 11 international Web sites in eight countries, with domestic Internet sales in 2000 of $850 million.

What’s more, Office Depot’s domestic online sales are expected to nearly double within the next two

years.

1.3 New Leadership Opens Exciting New Chapter in Company History

As Office Depot grew larger and more complex, its management leadership needs changed. In 2000,

David Fuente stepped aside, and Bruce Nelson was appointed Chief Executive Officer. Nelson’s charge

was challenging: To guide Office Depot at an exciting and defining time in the Company’s evolution.

Nelson immediately undertook several new management initiatives geared to make Office Depot a more

compelling place to work, shop and invest. With a careful focus on invigorating the Company’s U.S. retail

operations, expanding its international business, growing its best-in-class e-commerce business, and

building a world-class warehouse and distribution network, Nelson and his management team are poised

to take Office Depot to the next level of growth and success.

1.4 Supply Chain Management- Supply Chain Management Defined Supply Chain Management is the planning and execution of the movement of goods and materials

through the supply chain to deliver products to your customers. Starting from the design of the supply

chain, where to source manufacturing, where to place your distribution and manufacturing facilities.

Continuing with the anticipation and management of demand, what demand to expect as well as what

opportunities exist to promote and create demand. Extending then to the planning of procurement,

production, and logistics to coordinate the movement of materials and capacity to meet the demand.

Beyond planning, SCM assists in executing the plan through visibility into resources allowing a company

to make accurate and reliable delivery promises to customers based on the positioning of material,

capacity and logistics to respond to demand. SCM triggers purchase orders, work orders, and

transportation orders, while maximizing profits.


This integration of both a company’s internal processes, as well as the processes of suppliers and

customers, provides the visibility and velocity that are required to succeed in this era of global

competition, with its shrinking product lifecycles and shorter order lead-times.

The use of the Internet to connect your enterprise, people and processes to your trading partners

increases the velocity not only of your own enterprise, but by taking away the disconnects through the

supply chain, increases the velocity the extended virtual enterprise. The value derived from integrating

your own business processes are dwarfed in comparison to the inefficiencies leading to lost value that

exists in your supply chain. The typical supply chain is complex, with generally with thousands of

suppliers, outsourced manufacturing, and outsourced logistics. All participants in the supply chain must

be coordinated, have timely information, and effectively collaborate on a plan to ensure the efficient

movement of materials to become products for your customers. Failure to do so results in broken

promises to customers, long order lead-times, limited configurations of your offerings. In short, lack of

effective SCM means a sluggish, unresponsive supplier.

1.5 Business Challenges and Opportunities 1.5.1 Customer Retention The inability to fill orders taken on web storefronts destroyed credibility (and market caps) for many

companies in 1999 and underscored the importance of timely fulfillment for e-business. US companies

actually lose as much as 50 percent of customers every year. This is debilitating because for a number of

businesses (especially consumer goods and retail), the top 20 percent of customers account for 80 –100

percent of profits, and there is an 80 percent turnover in that highly desirable 20 percent that these

businesses need to retain, at all costs. Further exacerbating this syndrome is the fact that that customer

acquisition costs are 7-10 times higher than customer retention costs. The bottom line is that customer

loyalty, referrals and retention through reliable fulfillment can spell the difference between success and

failure for enterprises today.

1.5.2 Complexity of Extended Supply Chains Fulfillment is harder today than ever before, as supply chains become more complex due to the

outsourcing of manufacturing and logistics. Central planning no longer has full control over the third

parties. Coordinating this new multi-enterprise supply chain becomes a challenge, and collaboration

becomes key. Planning tools that reach beyond the enterprise walls to plan the extended, outsourced

supply chain are required.

Although many companies have implemented a web-based, front-end ordering system, they often lack

the necessary back-end planning and order execution capabilities and logistics systems. Many

companies can’t see downstream demand because they sell through intermediaries, they may forecast

with historical data, but don’t have current information on shifts in demand.


To avoid stock-outs they build inventory for a wide range of demand scenarios. In addition, many

companies can’t see upstream supply of materials and manufacturing capacity. Supplier performance is

poor because of a company’s inability to understand their constraints to deliver goods.

Facilities still have high inventory to buffer for poor planning and lack of future visibility. Existing assets

are not fully utilized; resources and people are often idle. Expediting and firefighting are common

practices rather than uncommon exceptions. This disruptive mode greatly impacts the operational

efficiencies: the wrong product is often produced at the wrong time, the opportunity cost of, which is

especially high if capacity is scarce. Mergers and acquisitions add to the existing supply chain’s intricacy.

Complexity is definitely increasing but the tools to manage this complexity are not keeping pace.

1.5.3 The Challenge of the Internet The advent of the Internet in the 90’s posed a unique challenge and opportunity. At first, businesses

rushed to figure out how to market and sell through this new channel. By the end of the decade, as use of

the Internet became pervasive and bandwidth increased, businesses saw that the Internet held the key to

being able to more efficiently collaborate with their suppliers. Business-to-business (B2B) e-markets

emerged, both public and private. As the century closed, leading businesses and industry analysts saw

that successful B2B on the Internet was inextricably tied to the extended supply chain, sometimes called

the value chain. Companies that can take orders, generate demand over the Internet, and plan their

operations with their suppliers, as if all are one integrated supply chain, will be the ones to win in the next

decade.

1.6 Supply Chain Management (SCM): Features and Benefits Since its inception about 10 years ago, the field of supply chain management has become tremendously

important to companies in an increasingly competitive global marketplace. The term supply chain refers to

the entire network of companies that work together to design, produce, deliver, and service products. In

the past, companies focused primarily on manufacturing and quality improvements within their four walls;

now their efforts extend beyond those walls to encompass the entire supply chain.

Why do this? Most of the gains achievable from an internal focus have been realized, while the

opportunities that exist through cooperation and collaboration are the new frontier!


1.6.1 Features • Representation of entire supply chain

• Simulation to validate plans and decisions

• Forward looking, identification of problems before they happen

• Integrated, providing visibility into all business processes

• Extreme speed and scalability

• Highly interactive problem-oriented planning & execution

• Proven optimization algorithms based on industry best practices

• Collaborative multi-enterprise planning and execution: demand, supply, capacity and logistics

1.6.2 Benefits

• Inventory Reductions

• Increased Customer Satisfaction

• Revenue Growth

• Throughput Improvement

• Operating Cost Reduction

1.6.3 Inventory Reductions • Supply and demand visibility substitutes inventory with information

• Increased planning frequency, and fidelity lowers the requirement of buffers against uncertainty

• Ability to know when to buy materials based on customer demand, and the capacity, logistics and

other materials needed to build the order to completion

1.6.4 Increased Customer Satisfaction

• Better positioning supply chain resources to anticipated demand

• Reduced lead times through optimal inventory management

• Understanding the capability to deliver on a promise based on availability of materials, capacity

and logistics

• Pro-active notification of potential delivery problems, and the ability to react with velocity to

examine ways to maintain the delivery date

• Use of Part Criticality Planning Logic to increase stocking of critical parts while decreasing overall

service parts inventories

1.6.5 Revenue Growth • Intelligently offering the "right" product mix to increase revenue per customer.

• Real-time visibility across the supply chain (alternate sources, parts, cancelled orders, capacity

etc.) enables order fill opportunities that are otherwise lost.


1.6.6 Throughput Improvements • Better coordination of material and capacity prevents loss of utilization waiting for parts

• Optimization of changeovers, batches, and other scheduling constraints maximizes productivity.

1.6.7 Operating Cost Reduction

• Optimized logistics planning to reduce expediting, overtime, and trucks leaving the docks half full.

• Forward visibility to prevent last minute heroism incurred to maintain customer service

1.6.8 Implementing Effective Supply Chain Management Strategies The primary purpose in establishing supply chains is to minimize the flow of raw materials, and finished

products at every point in the pipeline in order to enhance productivity and cost savings. Successful

supply chain ventures manage the following critical elements for parts (individual business unit, or a

division / function) and / or the whole (the entire supply chain):

1.6.8.1 Manage inventory investment in the chain:

Each constituent of the supply chain wants to hold no more than its fair share of inventory. For instance,

the distributor wants fewer inventories and would like to see inventory held by the manufacturer. As a

result, the concept of vendor managed inventory has become a trend in inventory management. This

system allows the inventory to be pushed back to the vendor and as a result lowers the investment and

risk for the other chain members

As product life cycles are shortening, lower inventory investments in the chain has become important.

Cycle times are being reduced as a result of quick response inventory system. The quick response

system improves customer service because the customer gets the right amount of product, when and

where it is needed [May 1994]. Quick response also serves to increase manufacturing inventory turns.

1.6.8.2 Establish supplier relationships:

It is important to establish strategic partnerships with suppliers for a successful supply chain.

Corporations have started to limit the number of suppliers they do business with by implementing vendor

review programs. These programs strive to find suppliers with operational excellence, so the customer

can determine which supplier is serving it better. The ability to have a closer customer / supplier

relationship is very important because these suppliers are easier to work with.

With the evolution toward a sole supplier relationship, firms need full disclosure of information such as

financial, gain sharing, and jointly designed work. They may establish a comparable culture and also

implement compatible forecasting and information technology systems. This is because their suppliers

must be able to link electronically into the customer’s system to obtain shipping, production schedules

and any other needed information.

1.6.8.3 Increase customer responsiveness:

To remain competitive, firms focus on improved supply chain efforts to enhance customer service through

increased frequency of reliable product deliveries. Increasing demands on customer service levels is of 206

OfficeDepot™ - Confidential

driving partnerships between customers and suppliers. The ability to serve their customers with higher

levels of quality service, including speedier delivery of products, is vital to partnering efforts. Having a

successful relationship with a supplier results in trust and the ability to be customer driven, customer

intimate and customer focused .

1.6.8.4 Build a competitive advantage for the channel:

Achieving and maintaining competitive advantage in an industry is not an easy undertaking for a firm.

Many competitive pressures force a firm to remain efficient. Supply chain management is seen by some

as a competitive advantage for firms that employ the resources to implement the process. It also serves

to increase the clout in the channel because these firms are recognized as leading edge and are treated

with respect.

Attaining competitive advantage in the channel comes with top management support for decreased costs

and waste, in addition to increased profits. Many firms want to push costs back to their supplier and take

labor costs out of the system. These cost reducing tactics tend to increase the competitive efficiency of

the entire supply chain.

Firms have become more market channels focused. They are watching how the entire channel’s activities

affect the system operation. In recent times, the channel power has shifted to the retailer. Retailer

channel power in the distribution channel is driven by the shift to some large retail firms such as, Wal-

Mart, Kmart, and Target. The large size of these retailers allows them the power to dictate exactly how

they want their suppliers to do business with them. The use of point of sales data and increased efficiency

of distribution also have been instrumental in improving channel power and competitive advantage

1.6.8.5 Introduce supply chain management solutions and enabling information technology:

Information is vital to effectively operating the supply chain. The communication capability of an enterprise

is enhanced by information technology system. However, information system compatibility among trading

partners can limit the capability to exchange information. An improved information technology system that

is user friendly, and where partners in the channel have access to common data bases that are updated

real-time is needed.

The long-term success of a firm depends on the success of its suppliers and customers. That is, the

entire supply chain must be successful. Poor performing supply chains are easy to recognize and

generally schedule product, using forecasting. These supply chains push product through to the

customer, have low overall reliability and maintain high inventory levels to achieve fulfillment rates.

Overtime, expediting, premium freight and inventory obsolescence drives up product costs. A growing

number of firms are designing products and operating in an extended multi-company enterprise. They are

minimizing non-value-added work and reducing inventory levels across the supply chain. These

organizations are also coordinating planning, forecasting and operations in multi-company context and

managing a multi-tier supplier environment. Many firms are eliminating cost rather than reallocating them.

An example of this effort is outsourcing of materials management function. They are implementing

customer pull across multiple boundaries and also treating suppliers as partners rather than adversaries.


What we are experiencing today is a fundamental change in global business philosophy of increasing

partnering arrangements.

In order to manage these supply chain arrangements, it is necessary to improve planning

and management of complex interrelated systems, such as materials planning, inventory management,

capacity planning, logistics, and production systems and realize overall improvement in enterprise

productivity. The availability of information technologies has enabled delivery of integrated systems for

decision-making. We have proposed a framework to delivery integrated systems for supply chain

management. Since the proposed approach offers generic solutions for problem-solving, it is now

possible to address variety of problems across industries having similar design and modeling

characteristics.

2. Requirements

2.1 Bussines Modeling

2.1.1 Business Vision

2.1.1.1 Vision Statement

We plan to become the most prominent office supply retailer. In the near future, we intend to capture a

major portion of the market for office supply sales. Our goal is to provide a wide range of office supplies

present in the market; offer customers attractive prices; maintain quality of goods; and increase profit.

This can be achieved by keeping inventory at optimal level, evaluating suppliers and minimizing supplier’s

price. Further, providing online selling would boost sales.


2.1.1.2 Goal Model

Wir

Increase profit: Quantitative Goal

Goal_value = 20 Current_value = 10 Unit_of_measure = “% profit”

Warehousing Management: Quantitative Goal

Managing Internal transfer: Quantitative Goal

Cut cost in receiving: Quantitative Goal

eless communication: Quantitative Goal

Cut cost in shipping: Quantitative Goal

Receiving Management: Quantitative Goal

Optimizing Logistic Planning

Shipping Management: Quantitative Goal

Order Schedule Management:

Quantitative Goal

Purchasing Management: Quantitative Goal

BigDeals with Suppliers: Quantitative Goal

Update Suppliers Productivity

Precise Forecasting

Update Market Trends

Update Real-time Demand

Goal Model


2.1.1.3 Conceptual Model

Conceptual Model Conceptual Model

Bussiness Plan

SCM Strategy

Forcasting

Planning

Demand Forcasting

Lead time Forcasting

Warehousing

High Profit & Cost effective

Plan Order release

Purchasing

Purchase Order release

Blanket Orders

Purchase Orders

+

Suppliers

Warehouse

Receiving

+ +

+Payment

+Retail Store

Business Strategies

Vision Statement

Goal Model

Key ratio

+

+

Is based on

Is used for

Uses

Leads to

Leads to

Obtains

Results in

Is sent to

Uses Paid

Delivers to

Distributes to

Leads to

Manifests

Motovates

Leads to

Goes to

System Inventory Management Decision making

Intelligent data

Contribute to

Market Demand

Sale History

Bussiness Ideas


2.1.2 Business Structure

2.1.2.1 Resource Structure Diagram

Controls the level of

Delivers

Is a concept of

Send to

1..*

Given to Places an

Sales Department

Demand information

Estimates purchases

Goes to

Results in Types of order

Plan w.r.t forecast

Forecast

Planning

Purchase Requisition

Purchase Section

Order

Blanket Order

Purchase Order

Supplier

Negotiation and Supplier

review

Product Description

Item Quality

Warehouse Inventory

Key Ratio

Resource Structure

System LogisticIs a decision maker

Analyze

Logical factors and arguments


of 206

Organization Model

Office Depot Corporation

SCM System Logistic Support

Marketing/Forecasting Department

Purchasing Department

Finance Department

Planning/Support Department

Inventory Management

Data Report To Decision Making (management relationship)

System Level

Departmental Level

Regional Level

Shipping/Receving Department

Marketing Department

Regional Logistic Support

Regional

warehousing

Coporate Level

CRM System ERP System

Divisional Level

Retail Stores

2.1.2.2 Organization Structure


2.1.3 Business Behavior

2.1.3.1 Sequence Diagram for Interaction Analysis


Sequence Diagram for Interaction Analysis

Sales Department Organizational Unit

Suppliers

Marketing/ Forecasting Department Organizational Unit

Planning/ Supporting Department Organizational Unit

Purchasing Department Organizational Unit

Shipping/ Receiving Department Organizational Unit

Inventory/ Warehousing Department Organizational Unit

Finance Department Organizational Unit

2: forecast demand

3: purchase requisition

4: approval

1: sale records

5: purchase orders (blanket orders or orders)

6: invoicel 7 : delivery

8: shipping

11: regionally distributing

12: shipping

System Logistic support Department Organizational Unit

9: request inventory balancing

10: globally distributing


Process Diagram

<<goal>> Minimum cost

Customer forecast

Misc. forecast

Forecast demand

Sale forecast

Sale history

Plan history

<<process>>Forecasting Forecast reports

and analyses

<<goal>> Update Market trends. Update realtime demands. Update Suppliers Productivities

Inventory status/safety stock, availabilities of sale products, lead time etc…

<<process>>Planning

<<resource>> Plan Order Release

<<goal>> Inventory level + supply level = demand level

<<process>>Purchasing

<<goal>> Negotiate with suppliers to get BigDeals

<<process>>

<<resource>> Purchase Order Release

<<resource>> Blanket Order Release

Suppliers <<process>>Receiving

Shipping Services

Tracking Reports

<<resource>> Inventory

<<process>> Warehousing <<resource>>

Products Delivery <<resource>>

Stores

<<goal>> Cut receving cost. Cut shipping cost. Effective inventory management. Minimize delivery time. Interwarehouse communications

<<resource>> Warehouses

<<resource>> System Logistic

Support

<<goal>> reconcile system inbventory, balance distribution

2.1.3.2 Process Diagram

2.1.3.3 Process Decomposition for Forecasting

Process Decomposition for Forecasting

<<event>> fiscal year forecast

System Analyst

<<process>> Collecting data

<<information>> past forecast

<<information>> warehouse inventory

<<information>> Market trends

<<information>> sale reports

<<information>> Supplier statuses

<<information>> competitor statuses

<<supply>><<supply>>

<<supply>>

<<supply>> <<supply>> <<supply>>

<<process>> Analyses

<<resource> Reports/Charts

<<goal>> get accurate

numbers

<<achieve>>

<<resource> Forecast rules

<<process>> Generate forecast

demand

<<goal>> estimate demand for

entire fiscal year

<<resource> Forecast demand

<<achieve>>

<<information>> Stock Market

Index

<<information>> Consumer

Index

<<information>> Investment

return

<<information>> Political stability

<<supply>> <<supply>> <<supply>> <<supply>>

Planning


2.1.3.4 Process Decomposition for Planning

<<process>> Analyze Previous

Plans

<<resource>> Analysis Results

<<process>> Create Plan

<<information>> demand

<<goal>> Beat Wall Street Estimates

<<goal>> Gather tendencies and correct past

mistakes

<<resource>> Forecast Demand

<<information>> current inventory

<<achieve>>

<<resource>> budget

<<information>> economic conditions

Planner

<<event>> fiscal year

plan

<<information>> past plans

<<information>> past forecast reports

<<supply>>


<<information>> company bottom line

Forecasting

Purchasing

<<resource>> plan


Process Decomposition for Planning


2.1.3.5 Process Decomposition for Warehousing-Store transfer


<<process>> warehouse/store

interactions

<<information>> warehouse/store

<<information>> quantity

<<information>> product

<<supply >><<supply >> <<supply >>

<<information>> forecast report

<<goal>> sell all products

<<achieve>>

<<resource> transfer request

<<process>> transfer

<<process>> product

distribution

<<phy sical> product to be transferred

<<goal>> deliv er on time

<<resource> key ratio

<<achieve>><<control>>


<<phy sical> product delivered to

store/warehouse


<<information>> requesting

warehouse/store

<<information>> supplying

warehouse

<<process>> organizations

<<supply >><<supply >>

<<supply >>

<<supply >>

<<information>> schedule

<<resource> store/warehouse

<<resource> transporation

<<resource> packaging

<<supply >> <<supply >> <<supply >>

<<achieve>>

<<resource> product

<<process>> receiving

<<information>> zone

<<information>> lot

<<information>> sublot

<<information>> lev el

<<resource> deliv ery vehicle

<<resource> supplier

<<resource> blanket

order/purchase order transfer

<<resource> amount of physical nv entory

<<resource> supllying

warehouse

<<supply >> <<supply >> <<supply >> <<supply >>




interactions


interactions

<<information>> warehouse/store<<information>> warehouse/store





<<supply >><<supply >> <<supply >>





<<achieve>>

<<resource> transfer request<<resource>

transfer request<<process>>

transfer<<process>>

transfer<<process>>

product distribution

<<process>> product

distribution







<<achieve>><<control>>




store/warehouse


store/warehouse




warehouse/store


warehouse/store


warehouse


warehouse

<<process>> organizations<<process>> organizations


<<supply >>

<<supply >>





<<resource> transporation<<resource> transporation




<<achieve>>

<<resource> product

<<resource> product





<<information>> lot

<<information>> lot





<<resource> deliv ery vehicle<<resource>

deliv ery vehicle



<<resource> blanket


<<resource> blanket





warehouse


warehouse

<<supply >> <<supply >> <<supply >> <<supply >>



Process Decomposition for Warehousing-Store transfer

2.1.3.6 Process Decomposition for warehouse-warehouse transfer


<<process>> warehouse/warehouse

interactions

<<process>> system dispatching


<<information>> location

<<information>> demand inventory

<<goal>> balance warehouse

inventory

<<event>> inventory

alert


<<process>> system inventory

management

<<goal>> balance organization

inventory

<<achieve>> <<achieve>>

<<supply>><<supply>><<supply>>

<<information>> Distribution schedule

<<information>> warehouse

demand


forecast


demand history

<<information>> supplier

<<supply>><<supply>>

<<supply>>

<<supply>>

<<supply>>

<<goal>> Update Market trends. Update real-time demands. Update Suppliers Productivities

<<information>> list of candidate

warehouses

<<information>> nearest

warehouse

<<information>> regional forecast

<<goal>> select product from the warehouse that has most available inventory <<achieve>>

<<resource> request report

<<goal>> Inventory level + supply level = demand level

<<resource> Plan Order Release

<<process>> update forecast

<<resource> Forecast demand

<<process>> update planning

Purchasing

<<achieve>> <<supply>> <<supply>> <<supply>>


Inventory agent

<<process>> transfer

<<information>> requested warehouse


warehouse



<<supply>> <<supply>>

<<supply>> <<supply>>

<<physical> product to be transferred

<<process>> product

distribution

<<goal>> deliver on time

<<physical> product delivered to

store/warehouse



<<resource> transportation


<<supply>>

<<achieve>>

<<supply>>

Process Decomposition for warehouse-warehouse transfer

2.1.3.7 Process Decomposistion Diagram for Order Tracking

«information» PO number

«information»

Product ID

«information»

Store ID

«supply»

«goal»Tracking all

products

«supply»«supply»

«achieve»

Request order reportSearch Orders

<<process>

Query order data

<<process>

Track order request «resource»

Order data confirm

«resource»

«goal»Report order

status

Log tracking result

«resource»

Process Decomposition Diagram for Order Tracking

of 206


2.1.3.8 Process Decomposition Diagram for Purchasing

<<process>> requisition


<<resource>> Key ratio

<<resource>> buyer

<<process>> Supplier selection

<<information>> plan order

<<goal>> Choose the

best supplier

Approve Supplier list

<<goal>> Get the best deal after negotiation and get an approval

<<resource>> Purchase Order

Negotiation

<<information>> supplier capacity

<<resource>> supplier

<<supply>>

<<achieve>>

<<supply>>

<<resource>> planner

<<supply>><<information>> inventory quality control

Process Decomposition Diagram for Purchasing


2.1.3.9 Process Decomposition Diagram for System Inventory Management

Process Decomposition Diagram for System Inventory Management

<<event>> regional inventory

request

System Inventory agent

<<process>> Priotize request

<<information>> regional

<<information>> request level

<<information>> system demand

<<resource> system request

<<process>> Queuing request

<<information>> request level

<<resource> request queue

<<process>> evaluation

<<information>> Distribution schedule


demand


forecast


demand history <<information>>

supplier <<information>>

POR <<information>>

product

<<resource> action item

<<process>> Select Routing

algorithms

<<information>> list of candidate

warehouses

<<information>> proximal

warehouses

<<information>> forecast analyses

<<information>> product statistics

<<information>> demand

propability

<<process>> Dispatch product

transfer

<<resource> supplying warehouse receiving warehouse

<<process>> warehousing

<<goal>> manage requests

<<goal>> get all data related to the requested warehouse and product

<<goal>> select appropriate algorithm to reduce the transfer cost


2.1.3.10 Assembly Diagram

<<process>> Forecasting

<<process>> Planning

<<process>> Purchasing

<<process>> Receiving

<<process>> Warehousing

<assembly line= Customer/Store demand>

<assembly line=Inventory status>

<assembly line=Forecast report>

<assembly line=PO Release>

<assembly line=Blank PO/PO>

<assembly line=Inventory>

<assembly line=Suppliers>

<assembly line=Forecast demand>


<<goal>> analysis of historical and current market

<<goal>> optimum inventory at any time in warehouse

<<goal>> obtain quality products at reasonable prices

<<goal>> minimize operating and delivery costs


<<achieve>> <<achieve>> <<achieve>> <<achieve>> <<achieve>>

<<resource> Key ratio







<assembly line=Inventory status>

<assembly line=Forecast report>

<assembly line=PO Release>

<assembly line=Blank PO/PO>

<assembly line=Inventory>

<assembly line=Suppliers>








<<process>> Forecasting<<process>> Forecasting







<<process>> Warehousing<<process>> Warehousing



<assembly line=Inventory status><assembly line=Inventory status><assembly line=Inventory status>

<assembly line=Forecast report><assembly line=Forecast report><assembly line=Forecast report>

<assembly line=PO Release><assembly line=PO Release><assembly line=PO Release>

<assembly line=Blank PO/PO><assembly line=Blank PO/PO><assembly line=Blank PO/PO>

<assembly line=Inventory><assembly line=Inventory><assembly line=Inventory>

<assembly line=Suppliers><assembly line=Suppliers><assembly line=Suppliers>

<assembly line=Forecast demand><assembly line=Forecast demand><assembly line=Forecast demand>

<assembly line=Forecast demand><assembly line=Forecast demand><assembly line=Forecast demand>





















Assembly Line Diagram


2.2 Function Features

2.2.1 SCM Strategy Reference Function Category

R.1.0 Define the rules that govern the movement of goods (office supplies)

through Office Depot Supply Chain.

Evident

R.1.1 Setting supplier capacity constraints – assign suppliers source relative

to their capacity (location, no. of goods).

Evident

R.1.2 Setting Office Depot office supply department constraints by capacity

and location.

Evident

2.2.2 System Inventory Management (Track Inventory Level) Reference Function Category

R.2.0 Increase Inventory Level with Purchased (Delivered) quantity. Hidden

R.2.1 Decrease Inventory Level with each sold item, clearance, discounts,

discards, or damaged item.

Hidden

R.2.2 Handle Inventory shortage. Evident

R.2.3 Handle Inventory excess (unexpected decline in demand). Evident

R.2.4 Handle late supply pegged to forecast. Evident

R.2.5 Track items below safety stock. Evident

R.2.6 Handle over committed items (demand fluctuations). Evident

R.2.7 Send Alerts to Planners, Buyers (rain check), Store managers Hidden

R.2.8 Calculate current value of goods in stock. Evident

R.2.9 Replenish supply subinventories stored by item or by day (internal

orders).

Evident/

Hidden

2.2.3 Forecasting Reference Function Category

R.3.0 Evaluate the supply and demand situation Evident

R.3.1 Carry-Forward (deferring it to a later in period) if the order demands

seems light.

Evident

R.3.2 Choose and apply appropriate forecast rule

R.3.3 Schedule the entire forecast demand. Evident

R.3.4 Log the forecast info: Forecast name, Description, Item, Quantity,

Warehouse, and Date.

Evident

R.3.5 Associating a forecast with a schedule. Evident


2.2.4 Planning Reference Function Category

R.4.0 Query Bucket Material Inquiry and Material Activity Inquiry (the

forecasted requirements).

Evident

R.4.1 Print the requirements Evident/

Frill

R.4.2 Set up lead-time, safety stock, and warehouse/lot size. Evident

R.4.3 Calculate planned values (quantities) based on demand, scheduled

and current values (quantities)

Hidden/

Evident

R.4.4 Compare actual planned values with planned order release values,

and adjust planned order quantities in the corresponding buckets.

Hidden/

Evident

R.4.5 Log the analysis Evident

R.4.6 Create and lunch the plan (capacity and material) Evident

R.4.7 Modify objectives, supply/demand, resources, and suppliers’

parameters.

Hidden

R.4.8 Evaluate the performance plan – Compare actual to target values

using Key Performance Indicator (KPI).

Evident

2.2.5 Requisition Reference Function Category

R.5.0 Overview of the planning requirements and recommendations Hidden

R.5.1 Handle creation, editing and reviewing requisitions Evident

R.5.2 Handle delivery instructions, multiple account distributions, and notes

to buyers, approvers, and receivers.

Hidden

R.5.3 Handle approval (rejection) and review. Evident

2.2.6 Purchasing Reference Function Category

R.6.0 Receive and analyze purchase requisitions. Evident

R.6.1 Approve Purchase requisition by manager. Evident

R.6.2 Generate the approved PR report Frill

R.6.3 Handle negotiations with suppliers Evident

R.6.4 Create and submit purchase order (order number, order lines, item –

office supply, quantity, delivery date, and cost.

Evident

R.6.5 Verify invoices Frill


2.2.7 Suppliers’ performance measurement (Suppliers scoring) Reference Function Category

R.7.0 Query the report by suppliers’ features. Evident

R.7.1 Compare suppliers’ prices. Evident

R.7.2 Measure delivery times – does supplier stick with scheduled plan. Evident

R.7.3 Evaluate item quality. Evident

R.7.4 Evaluate suppliers commitments Evident

R.7.5 Log the analysis Evident

R.7.6 Grading the suppliers’ performances Hidden

R.7.7 Select/discard suppliers based on performance report Evident

2.2.8 Transacting – Action tracking and Cost calculating Reference Function Category

R.8.0 Handle transactions: completed, canceled, pending, in progress,

approved, and rejected.

Hidden

R.8.1 Handle charging for labor, machines, transport and outside resource Evident

R.8.2 Track standard and weighted cost Evident

R.8.3 Handle charging for standard, employee, or actual rates and tax Evident

R.8.4 Calculate company profit Hidden

R.8.5 Report efficiency, usage, and transaction history Evident

R.8.6 Publish the business results – cost savings and profit Evident

2.2.9 Warehousing Reference Function Category

R.9.0 Create schedule for trip and delivery planning. Evident

R.9.1 Schedule appointment and dock assignments. Evident

R.9.2 Calculate the size dimensions and carton numbers for order fulfillment. Evident

R.9.3 Provide ability to specify packing instructions. Evident

R.9.4 Ability to create customer compliance labeling for rules set up by the

company.

Frill

R.9.5 Provide shipment stage and handle loading Evident

R.9.6 Handle shipment verification Evident

R.9.7 Handle return material authorization (RMA) receiving Evident

R.9.8 Handle returns to the supplier Evident

R.9.9 Provide mechanism for automated replenishment Frill

R.9.10 Provide container management feature Evident

R.9.11 Provide mechanism for lot control Evident


R.9.12 Provide mechanism for sublot control Evident

R.9.13 Provide mechanism for material status control Evident

R.9.14 Provide zone configuration Evident

R.9.15 Provide a locator structure Evident

R.9.16 Provide a WMS control board Frill

R.9.17 Provide task dispatching Evident

R.9.18 Ability to conduct warehouse-warehouse transfers Evident

R.9.19 Ability to conduct warehouse-store transfers Evident

R.9.20 Provide serial number tracking Evident

R.9.21 Provide cycle counting and physical inventory Evident

R.9.22 Provide data coding and shelf life monitoring Evident

R.9.23 Provide active alerts and notifications Evident

R.9.24 Produce real-time inquiries Evident

R.9.25 Ability to generate warehouse reports Evident

2.2.10 Tracking Reference Function Category

R.10.0 Search existing order. Evident

R.10.1 Get supplier ID Evident

R.10.2 Get product ID Evident

R.10.3 Get Carrier ID Evident

R.10.4 Get Store ID Evident

R.10.5 Report order status Evident

R.10.6 Log tracking order Hidden

2.2.11 Receiving Reference Function Category

R.11.0 Create schedule for receiving planning. Evident

R.11.1 Confirm suppliers transfers schedule Evident

R.11.2 Provide product serial number tracking Evident

R.11.3 Receive product Evident

R.11.4 Check amount and product with order Frill

R.11.5 Notice System Inventory Management Evident

R.11.6 Notice Transacting (to pay) Evident

R.11.7 Handle product transfers to warehouse Evident


2.3 Use Case Model

Finance Manager

Supplier

Buyer

Purchasing

Planner

Planning

Forecaster

Forecasting

Supplier analyst

Supplier Performance

System logistic


Inventory agent

Tracker

Order Tracking

Overall Use Case Diagram

Receiving

Warehouse Clerk

Store Manager

Warehouse-warehouse

Warehouse- store

Warehouse Manager


2.3.1 Forecasting 2.3.1.1 Use Case Forecasting

Use Case: Forecasting

Actors: Planner

Purpose: Prepare forecast report for the specified time frame.

Overview: The Planner evaluates demand situation for Office Depot. Create a forecast report based

on forecast. Printing out the report.

Type: Primary

Cross-references: R.3.0, R.3.1, R.3.2, R.3.3, R.3.4

Typical Course of Events

Actor Action System response

1. Query customer demand, sales demand,

Miscellaneous demand data for a specified time

frame (eg : last 3 months) for 2 main customers

forming 80% of the revenue.

2. Data response – items sold to the customer in

the period specified, approximate time of

placement of the orders by the customers. The

effect of this demand in Inventory level.

3. Evaluate the demand situation by looking at the

methods applied for forecasting, the forecast

accuracy during that period.

4. Demand Evaluation – Demand Management

applications consider shipment histories and actual

customer demand at the detailed transactional

level. The sales ranking by product, by customer,

by product family, by sales territory, - sorted by

units, sales value, cost and margin/profit. The

future sales. Accuracy of the previous forecasts

and scope for improvement. The performance of

the product with respect to the company. Also, try

to use various methods like exponential smoothing,

mean average deviation and check to see which

fits into the category of the product well and apply

that method for forecasting.


5. Schedule forecast. Create a forecast. Several

forecasting methods like “optimal” selects the best

forecast after considering the others. Divide the

forecast into flexible categories so that the

appropriate history and forecast technique can be

applied to each unique combination of products,

customers and location. Statistically generate

forecasts with this history.

6. Associating a forecast with a schedule.

7. Print the forecast results.

2.3.1.2 Use Case Diagram: Forecasting

Forecaster

Forecasting

Use Case Diagram: Forecasting

The business use case model identifies the business use case created during the forecasting. These

include querying historical data, seasonal demand tracking, etc and forecast demand for specified time in

the future. The one involved is Forecaster.

A methodology that is apply in the forecasting process is push-pull approach.

The push-pull point relates to anticipated demand (forecasts) versus actual demand (firm orders). In most

supply chains, the upstream activities respond to forecasts, while somewhere on the downstream side the

chain waits for orders to be placed.


Where the chain switches from push (BTS) to pull (BTO) is called the Push-Pull point. Though there are

exceptions, generally speaking the activities upstream of the Push-Pull point are BTS, and those

downstream are BTO. It is important to know where the Push-Pull point is for your supply chain and that

of your competition. In particular, technological changes may enable you to shift your Push-Pull point to

obtain better performance.

2.3.1.3 Sequence Diagram: Forecasting

evaluate_demand(number_of_days, item_id,…..);

information_retrieval (date, item_id….);

: System

create_forecast (forecast_id,forecast_rule,…);

log_forecast_info (forecast_name,…..);

query_demand(item_ID, quantity, sales_rank….);

evaluation_results (number_of_days….);

forecast ();

forecast_association (forecast_id, schedule_id….);

:Planner

1. The Planner gets demand data from the system.

2. Evaluate all kinds of data like seasonal, cyclic etc.

3. Creates a forecast.

4. Associates a forecast to a schedule.

5. Log all the details of the forecast into the system to create a forecast report.


2.3.1.4 Contract: Forecasting

Name: log_forecast_info ( forecast_name string,

forecast_name string,

forecast_creation_date date,

forecast_desc string,

employee_id number,

employee_name name,

schedule_id number,

item_id number,

no_of_items number,

bucket_number number)

Responsibilities: Create new forecast.

Log the forecast results.

Type: System

Cross-references: R.3.3.

Use cases: Forecasting

Notes: Uses ERP’s SCM forecasting GUI.

Exceptions: If invalid/corrupted data.

Output: The forecast report.

Pre-conditions: The forecast has to exist.

Post-conditions:

• If a new demand, a forecast was created (association creation).

• If existing demand, forecast launched (instance creation).


2.3.2 Planning 2.3.2.1 Use Case Planning

Use Case: Planning

Actors: Planner

Purpose: Analyze the need and create material and capacity plan.

Overview: The Planner analyses, calculates, compares, and evaluates the need of Office Depot.

The Planner makes sure that by issuing and returning components from and to

warehouse (including internal orders and replenishments) keeps inventory on optimal

level.

Type: Essential and Critical

Cross-references: R.4.0, R.4.1, R.4.2, R.4.3, R.4.4, R.4.5, R.4.6, R.4.7, R.4.8, R.4.9, R.5.0, R.5.1,

R.5.2, and R.5.3.



1. Query Bucket Material Inquiry and Material

Activity Inquiry.

2. Print the forecasted requirements.

3. Calculate planned values based on demand,

schedule and current values.

4. Compare actual plan values with planned order

release values and adjust planned order quantities

in the corresponding buckets, in order to keep

inventory above ‘safety stock’ level.

5. Log the analysis.

6. Create the plan.

7. Launch the plan.

8. Modify objectives, supply/demand, resources

and supplier parameters.

9. Evaluate the performance of the plan (compare

actual to target values).


2.3.2.2 Use Case Diagram: Planning

Use Case Diagram: Planning

Planner

Planning

The business use case model identifies the business use case created during the planning process.

These include querying of forecasted requirements, calculation of planned quantities, creation of plan etc.

The one involved actor is Planner.

2.3.2.3 Sequence Diagram: Planning

calculatePlannedQty(bucketValue, week, …)

queryForecastedRequirements()

adjustPlannedQty(bucketValue, week, …)

createPlan(bucketValue, week, onHand, …)

modify( supplier, demand, …)

evaluatePlan(plan_id, item…..)

: System :Planner

1. The Planner gets forecasted requirements from the system.

2. Calculate planned quantities.

3. Compare and adjust planned quantities in order to keep inventory above

‘safety-stock’ level.

4. Create and launch the Plan.

5. The Planner modifies objectives, supply/demand, resources, and suppliers’

parameters.

6. The planner evaluates the performance of the plan.


2.3.2.4 Contract: Planning

Name: createPlan ( bucketValue number,

week date,

demand number,

currentVal number,

onHand number,

plannedRel number,

leadTime date,

safetyStock number,

lotSize number,

releaseDate date)

Responsibilities: Enter the plan.

Calculate and log the input values.

Launch the plan.

Type: System

Cross-references: R.4.6

Use cases: Create a Plan

Notes: Uses ERP’s SCM Planning GUI.

Exceptions: If the forecast buckets are not populated or not positive integer values throw the

exception (error).

Output: The plan

Pre-conditions: The forecast has to exist.

Post-conditions:

• If a new forecast, a Plan was created (association creation).

• If a new plan, a Plan was launched (instance creation).

• Demand, Planned order release, and Release dates are bound to the Plan

(association created).

of 206


2.3.3 Purchasing

2.3.3.1 Use Case Purchasing

Use Case: Purchasing

Actors: Buyer, Supplier, Manager

Purpose: Purchasing office supplies for Office Depot.

Overview: The Buyer receives Purchase Requisitions and analyzes them to make Purchase Orders

after financial approval.

Type: Essential and Interactive

Cross-references: R.6.0, R.6.1, R.6.2, R.6.3, R.6.4, R.6.5, R.6.6.



1. Receive and analyze purchase requisitions

2. Send PR for approval

3. Send Approval Statement

4. Handle negotiations with suppliers.

5. Generate Purchase Order.

6. Submit purchase orders.

7. Verify invoices.

2.3.3.2 Use Case Diagram: Purchasing

Finance Manager

Supplier

Use Case Diagram: Purchasing

Buyer

Purchasing


The business use case model identifies the business use case created during the purchasing process.

These include retrieving the PR, Approving the PR, negotiating with suppliers, creating a PO etc. The

actors involved are Buyer, Finance Manager, Supplier.

2.3.3.3 Sequence Diagram: Purchasing

System:

PR_Retrieval( );

Approval_Request( )

Approval_Given( )

Negotiate_Supplier( )

Negotiation_Results( )

Create_PO( );

Submit_PO( );

Verify_Invoices( )

Buyer Finance manager Supplier

1. The Buyer retrieves the purchase requisition from the System.

2. Requests the approval of the purchase requisition from the Finance Manager.

3. The Finance Manager gives the approval for the purchase requisition

4. After the purchase requisition is approved, the Buyer negotiates with the Supplier.

5. The Negotiation results are sent back to the Buyer from the Supplier.

6. Now the Buyer creates a purchase order.

7. When the purchase order is submitted, then the System sends the purchase order to the

Supplier.

8. Finally, the Buyer verifies the Invoice.


2.3.3.4 Contract: Purchasing

Name: create_PO ( PO_id number,

PO_name string,

PO_line number,

item string,

quantity number,

cost number,

delivery_date date,

supplier_id number,

buyer_id number,

warehouse_id number,

creation_date date)

Responsibilities: Create Purchase Order.

Type: System


Use cases: Purchasing

Notes: Uses ERP’s SCM Purchase Order GUI.

Exceptions: If no financial approval.

If no suitable supplier.

Output: The Purchase Order.

Pre-conditions: The Purchase Requisition has to exist.

Financial Department should approve.

Supplier should exsist.

Post-conditions: PO created (Instance creation).

For every PR, a PO is generated (Association creation)


2.3.4 Supplier performance

2.3.4.1 Use Case Supplier performance

Use Case: Supplier Performance

Actors: Supplier, Supplier Analyst

Purpose: Prepare a supplier list based on their performance and select the best supplier for the

given item.

Overview: The Supplier analyst evaluates the supplier based on certain criteria such as product

quality, delivery time, cost, and supplier commitment.


Cross-references: R.7.0, R.7.1, R.7.2, R.7.3, R.7.4, R.7.5, R.7.6, R.7.7.



1. Query the report by the suppliers’ features.

2. Compare supplier’s prices and measure delivery

time.

3. Evaluate item quality.

4. Evaluate suppliers’ commitments.

5. Log the analysis.

6. Grade suppliers based on the given criteria.

7. Select/discard supplier based on the

performance report

2.3.4.2 Use Case Diagram: Supplier performance

Supplier analyst


Use Case Diagram: Supplier Performance

The business use case model identifies the business use case created during the supplier scoring. This

includes querying supplier features and then comparing their prices, delivery time, quality of item


delivered, supplier commitment for the next bucket. The supplier is selected based on the above criteria.

The one involved actor is Supplier analyst.

2.3.4.3 Sequence Diagram: Supplier performance

System:

queryData(item_id,..)

comparePrice(itemId, supList[]..)

CompareDelTime(itemId, supList[]..)

evalQuality(itemId, noOfDef..)

evalSupCom(itemId, ..)

LogAnalysis(itemId, price, ..)

gradeSupp(itemId, price, ..)

SelSupp(itemId, suppList[] )

Supplier

2.3.4.4 Contract: Supplier performance

Name: selSupp( itemId number,

SupList[] string[],

creation_date date)

Responsibilities: Selecting the supplier based on his performance.

Type: System


Use cases: Supplier Performance Measurement - Selecting best supplier

Notes: Uses ERP’s SCM Suppliers’ performance GUI.

Exceptions: If no suppliers available for the given item.

Corrupt data from database.

Output: The best supplier for the given item is chosen.


Pre-conditions: The item has to exist.

Supplier should exist.

Post-conditions: The best supplier is chosen

2.3.5 System Inventory Management

2.3.5.1 Use Case: System Inventory Management

Use Case: System Inventory Management

Actors: Planner, Inventory Agent

Purpose: Manage the inventory of the Office Depot at an optimum level.

Overview: The planner monitors the inventory level, handles inventory shortage and inventory

excess from regional warehouses. The inventory agent sends alerts to the planner and

store managers when inventory of a regional warehouse or overall inventory falls below

safety stock or exceeds maximum allowable quantity. The planner adjusts internal

inventory levels.

Type: Critical and real-time

Cross-references: R.2.0, R.2.1, R.2.2, R.2.3, R.2.4, R.2.5, R.2.6, R.2.7, R.2.8, and R.2.9



1. Regional warehouse inventory agent sends alert

on its inventory level (shortage or surplus)

3. Planners coordinate with logistic support unit to

acquire the plan information and forecast to

evaluate the priority of the alarm from the regional

warehouse

4. Planners send a report that included the PORs

and forecast demands for the regional warehouse

2. Gathers the inventory information from the

regional agen and sends forward to the planner

5. Analyze the data, collect the inventory

information of proximal warehouses of the

requested warehouse.

3. Handle Inventory shortage. 6. Coordinates with logistic support unit to make

decision to decrease or increase the inventory level


of the requested warehouse.

4. Handle Inventory excess. 7. Generate reports for forecasting, planning

department and suppliers.

8. Planner adjusts the current plan, modifies or

generate new POR.

9. Selects algorithm for routing item and sends the

decision back to the regional warehouse.

10. Regional inventory agent adjust inventory level

based on the decision from the system inventory

agent.

11. Send confirmation to Planners, Buyers (rain

check), and Store managers.

12. Calculate current value of goods in stock.

13. reset the alarm level (safety stock level)

2.3.5.2 Use Case Diagram: System Inventory Management

Use Case Diagram: Inventory Management

System logistic


Planner

Inventory agent

This business use case model identifies the business use case created when the inventory alert is

generated by the inventory agent. This includes the reading of data by the inventory agent and sending

the alert to the planner. The planner handles the alert by taking suitable action.


2.3.5.3 Sequence Diagram: System Inventory Management

System: Planner Inventory Agent

readData(item id, quantity, safetystock current time …)

triggerAlert(planner id, item id…)

sendAlert(planner id, item id…)

handleAlert(item id…)

TransferProduct(item id…)

SendReports(planner id …)

1. The inventory agent reads data from the system for every item.

2. The agent compares the current quantity to the safety stock and the maximum

allowable quantity. If the current quantity is abnormal then it triggers an alert.

3. The system sends the alert to the planner.

4. The planner handles the alert by taking appropriate action.

5. The system makes decision based on the evaluation from planner, select algorithm for routing item

and sends the response to the inventory agent.

6. The inventory agent reset the alert level and send report to the appropriate planner about the

action

2.3.5.4 Contract: System Inventory Management

Name: triggerAlert ( alertType string,

itemId number,

plannerId number,

warehouseId number,

currentDate date)

Responsibilities: Send trigger when the inventory level is unacceptable.

Type: System


Cross-references: R.2.7

Use cases: System Inventory Management

Notes: Uses system triggers and alerts.

Exceptions: Invalid item id, planner id, or warehouse id, can happen in case of incoherency of

database.

Output: Alert is generated

Pre-conditions: Inventory level is abnormal (below safety stock or above maximum allowable quantity).

Post-conditions:

• Alert is generated (instance creation)

• If item quantity is abnormal then alert is generated (association creation).

2.3.6 Order Tracking

2.3.6.1 Use Case Order Tracking

Use Case: Tracking

Actors: Tracker

Purpose: Tracking process provides system an ability to provide information about an order or a

shipment from supplier or to a customer and to report the time turn around of the store

processes.

Overview: Tracker follows up a status of distributed product or an order from the purchase

organization unit with a supplier. The tracker receives status of the order, its location and

ETA. The turn around time of each order is logged and reported for planners and

analysts

Type: Essential and Realtime

Cross-references: R.10.1, R.10.2, R.10.3, R.10.4, R.10.5, R.10.6, R.10.7, R.10.8, R.10.9, R.10.10,

R.10.11, R.10.12, R.10.13, R.10.14, R.10.15, R.10.16, R.10.17, R.10.18, R.10.19,

R.10.20, R.10.21, R.10.22, R.10.23, R.10.24


Actor Action System Response 1. A tracker send a request to track an order

from a supplier by giving a PO number.

2. System identify the supplier of the order and of 206


notifies the supplier.

3. Supplier receives the PO number, validate

the order and send back the order status,

shipping date and carrier ID .

4. System verifies the order status is shipped

and send the request to carrier to locate the

order and ETA. System notifies the tracker.

5. The tracker confirm the order as is in the

invoice and send confirmation to the system.

6. System logs the tracking record and records

the turn around time of the order.

2.3.6.2 Use Case Diagram: Tracking

Tracker

Order Tracking

Supplier

Use Case Diagram: Order Tracking


2.3.6.3 Sequence Diagram: Order Tracking

SendOrderInfo()

Notify(PO)

:System

SearchPO(PO, type)

ReportOrder()

LogTracking()

Tracker Supplier

Query PO

Send request for PO status

1. Tracker search a purchase order from the system

2. The system found a existing PO to tracker

3. The tracker send request to the system for the PO status

4. The system verifies PO and notifies for relevant supplier of the PO

5. The supplier acknowledge the PO and send information about the order

6. The system gather the order information and create a report then send it to the tracker.

7. The tracker acknowledge the order status and send confirmation to the system so that the system

records in log tracking.

2.3.6.4 Contract: Order Tracking

Name: searchPO(

PO number,

OrderType string

)


Responsibilities: Looks up PO and quantity in the warehouse inventory then transfers the

requested quantity of a product to the store.

Type: System

Cross-references: R.9.15, R.9.18, R.9.22, R.9.23, R.9.24

Notes: Uses ERP’s SCM warehousing GUI.

Exceptions: If warehouse does not possess enough inventory to handle the quantity requested, the

product_id provided is not valid, the store_id provided is not valid, or the warehouse_id

provided is not valid, then indicate it was an error.

Output: Return an acknowledgement of the transfer that needs to be confirmed along with

possible shipping dates and times to the store.

Pre-conditions: The product_id must exist.

The store_id must exist.

The warehouse_id must exist.

The quantity requested must not be larger than amount in inventory.

Post-conditions: Quantity of product in store is incremented and quantity in warehouse is decremented.

System Inventory Management will be invoked if inventory level is unacceptable.

Transferred items must be packaged and shipped from the warehouse to the store.

2.3.7 Warehousing 2.3.7.1 Use Case Warehousing

Use Case: Warehouse-warehouse

Actors: Warehouse Manager, Warehouse Clerk, Back Office System

Purpose: Warehouse transfers product to another warehouse due to shortage or demand.

Overview: The warehouse issues a warehouse-warehouse transfer request for a product. The

system searches the inventory data to determine which warehouse to transfer from. The

system will update the forecast and send a request to the back office system. The back

office system will issue the transfer and notify the warehouse clerk transferring the

product. Type: Essential and Interactive


R.9.13, R.9.14, R.9.15, R.9.16, R.9.17, R.9.18, R.9.19, R.9.20, R.9.21, R.9.22, R.9.23,

R.9.24, R.9.25


Actor Action System Response 1. Warehouse manager issues a search

request for product that is needed


2. System queries the inventory data to find a

warehouse with the quantity of product

requested.

3. Warehouse manager requests a warehouse-

warehouse transfer of the product.

4. System checks availability of the product in

the warehouse, sends a request to the back

office system, and confirms if the request was

valid. The system updates the real-time

demand of product for the requesting

warehouse.

5. Back office system selects a transfer

schedule and sends it to the requested

warehouse

6. System completes transfer of product by

verifying the requested product is available and

notifies an alert agent which notifies the

requested warehouse personnel.

7. Warehouse clerk packages product for

shipment, attaches shipping label, loads

product into truck for delivery to the requesting

warehouse.

Use Case: Warehouse-store

Actors: Warehouse Clerk, Store Manager

Purpose: Warehouse provides product to the store when inventory at the store is low.

Overview: The store issues a warehouse-store transfer request for a product. The regional

warehouse receives notification, completes the transfer, and delivers the product to the

store




R.9.13, R.9.14, R.9.15, R.9.16, R.9.17, R.9.18, R.9.19, R.9.20, R.9.21, R.9.22, R.9.23,

R.9.24, R.9.25


Actor Action System Response 1. Store issue inter-organization transfer

request for a product

2. System sends warehouse notification of

transfer request

3. Warehouse request transfer of the product to

the store, entering the store id, product id, and

the quantity to be transferred

4. System checks availability of the product in

the warehouse. System then returns available

delivery dates and requests a delivery date

from the actor

5. Warehouse chooses acceptable delivery

date and confirms transaction

6. System completes transfer of product to the

store. The system then returns a transfer

acknowledgement to the store with the

package id, delivery date and returns to the

warehouse with the shipping label, package id,

the quantity to be shipped, the physical location

of the product, and the packaging size and type

along with the loading dock, truck id, and date

of shipment.

7. Warehouse packages product for shipment,

attaches shipping label, loads product into

truck for delivery to the store


2.3.7.2 Use Case Diagram: Warehousing

Use Case Diagram: Warehousing

Warehouse Clerk

Store Manager

Warehouse-warehouse

Warehouse- store

Warehouse Manager

2.3.7.3 Sequence Diagram: Warehousing

Warehouse Clerk Store Manager System:

request transfer()transfer notify()

transfer()

transfer schedule

transfer confirm()

print transfer info

transfer acknowledg

transfer verify()

1. Store issues request for inter-organization transfer of product

2. System notifies warehouse of the request

3. Warehouse issues transfer of product

4. System notifies warehouse of available delivery dates and asks for transfer confirmation

5. Warehouse supplies delivery date and confirms transfer


6. System returns information necessary to complete the physical transfer of the product requested

7. System returns an acknowledgement to the store in regards to the transfer request

8. Store verifies delivery of the product

2.3.7.4 Contract: Warehousing

Name: transfer(

transaction_id number,

transaction_date date,

product_id number,

quantity number,

receive_loc_id number,

warehouse_id number

)

Responsibilities: Looks up product id and quantity in the warehouse inventory then transfers the

requested quantity of a product to the requesting store or warehouse.

Type: System

Cross-references: R.9.15, R.9.18, R.9.19, R.9.23, R.9.24, R.9.25

Notes: Uses ERP’s SCM warehousing GUI.

Exceptions: If warehouse does not possess enough inventory to handle the quantity

requested, the product_id provided is not valid, the receive_loc_id provided is not

valid, or the warehouse_id provided is not valid, then indicate it was an error.

Output: Return an acknowledgement of the transfer that needs to be confirmed along

with possible shipping dates and times to the store.


The receive_loc_id must exist.

The warehouse_id must exist.

The quantity requested must not be larger than amount in inventory.

Post-conditions: Quantity of product in store is incremented and quantity in warehouse is

decremented.

System Inventory Management will be invoked if inventory level is unacceptable.

Transferred items must be packaged and shipped from the warehouse to the

store.


2.3.8 Receiving

2.3.8.1 Use Case Receiving

Use Case: Receiving

Actors: Supplier, Inventory Manager

Purpose: Supplier provides product, after receiving products and checking amount, product then

notice System Inventory Management.

Overview: Make sure the products conform to the order and receive on time.


Cross-references: R11.0, R11.2, R11.3, R11.4, R11.5, R11.6, R11.7


Actor Action System Response 1. Supplier sends Inventory the products

Transfer schedule.

2. System follow the schedule, make sure to

receive before deadline.

3. Supplier transfer products.

4. System Check the products ID and amounts.

5. System Inventory Management updates

product

amount data

2.3.8.2 Use Case Diagram: Receiving

Use Case Diagram: Receiving

Supplier

Receiving

Inventory Manager


The business use case model identifies the business use case created during receiving.

These include transfer schedule, deadline warning, check ID and amount, and update data. The actors

involved are Supplier and System Inventory Management.

2.3.8.3 Sequence Diagram: Receiving

Supplier Inventory Manager System:

deadline_warn()

transfer schedule

checkID_amount()

transfer()

update_amount()

1.Supplier sends Inventory the products Transfer schedule.

2. System follow the schedule, make sure to receive before deadline.

3. Supplier transfer products.

4. System Check the products ID and amounts.

5. System Inventory Management updates data

2.3.8.4 Contract: Receiving

Name: check(

transaction_id number,

transaction_date date,

product_id number,

product_amount number,

)

Responsibilities: Check the product’s item and amounts are correct.

Type: System

Cross-references: R.11.0, R11.1, R11.2, R11.3, R11.4, R11.5, R11.6, R11.7

Notes: Uses ERP’s SCM receiving GUI.


Exceptions: If receiving product’s item and amounts does not conform to the order.

The transation_id provided is not valid.

The transaction_date provided is not valid.

Output: Return a boolean value about the receiving process.


The product_amount must exist.

Post-conditions: After receiving, the product ID and Amount must are the same as the order.


3. Analysis

3.1 Analysis classes

3.1.1 Class Diagram

3.1.1.1 Forecasting

Forecaster

ScheduleUI

PastForecast Report Search UI

Query Forecast Reports

Forecast Reports

Coporate Inventory

Management UI

Get current inventory report

Inventory data

PO Search UI Get pending PO Pending POs

Reconcile inventory

Market Trend DataInput UI

Analyze maket data

Forecast Inventory

Create a forecast

Calculate lead time

Associate forecast with a

schedule

Forecast demand

Forecast report

ForecasterForecaster

ScheduleUIScheduleUI




Forecast Reports

Coporate Inventory

Management UI

Coporate Inventory

Management UI


Inventory data

PO Search UIPO Search UI Get pending PO Pending POs

Reconcile inventory

Market Trend DataInput UIMarket Trend DataInput UI

Analyze maket data

Forecast Inventory

Create a forecast

Calculate lead time


schedule

Forecast demand

Forecast report

Analysis Class Diagram For Forecasting Use Case


3.1.1.2 Planning

Planner

Forecast Search UI

Purchasing Search UI

Planning UI

Query Forecast Report

Query P.O. Data

Forecast Report

Pending & Released P.O. Data

Plan Analyzer

Query Supplier Performance

Target Vs. Actual KPI’s


Evaluate KPI’s / Modify Objectives

Updated Plan

Analysis Class Diagram for Planning Use Case


3.1.1.3 Purchasing

Analysis Class Diagram for Purchasing Use Case

Buyer

Finance Manager

Supplier

Purchase Requisition UI

Purchase Order UI

Purchase Requisition Retrieval

Purchase Requisition Approval

Purchase Requisitions

Approval UI

Purchase Order Negotiation

Approval Retrieval

Purchase Orders

Invoice Verificaton

Invoice UI

Invoice Generation

Purchase Order Submission

SupplierUI

Invoices


3.1.1.4 Supplier's Performance

Analysis Class Diagram for Supplier Performance Use Case

Supplier Analyst

QueryHandler SupplierUI

Plan

EvaluationUI

SupplierDetails

Analysis Parameters

Grade and

Select

Select Suppliers

Evaluate Delivery Time

Evaluate Quality

Evaluate Commitments

EvaluatePrice

Evaluate Supplier Details

Evaluate Plan


3.1.1.5 Order Tracking

Analysis Class Diagram For Tracking Order Use Case

Tracker

Query POs

PO Search UI

Order Schedule UI

Supplier Supplier Search UI

POs

Query Suppliers

Get Order Schedule

Tracking Reports Get tracking

Carrier Search UI

Carrier Query Carriers

Schedule

Generate tracking

data

Tracking records


3.1.1.6 Warehousing

Requesting Store Clerk

Transfer request UI

Transfer confirmation

Transfer Notice

Generate Confirmation

Transfer Request UI

Transfer

Product

Delivery Schedule

Confirmation

Transfer Schedule UI Transfer Schedule

Warehouse clerk

Request Confirmation

Inquiry

Back Office System

Warehouse Product Search UI

Dispatch Request

Request Alert Agent UI

Inventory Demand Data

Analysis class for Warehouse-store Transfer Use Case


Manager

Warehouse transfer request

UI

Transfer

Inventory demand data

Warehouse product search

UI

Query product searched

Inventory data

Dispatch request

Warehouse

Back Office System


Product transfer schedule UI

Notify requested warehouse

Notify forecast unit


Warehouse Manager

Requested Product data

Analysis Class Diagram For Inter-warehousing Transfer Use Case

Confirmation UI

Return Product Data


Transfer Confirmation



3.1.1.7 System Inventory Management

Analysis Class Diagram For System Inventory Management Use Case

Warehouse manager

Alert UI

Generating alert

Request Prioritize requests

Queue requests

Inventory

Send

Planner

Report Alert UI

Inventory UI

Notification Evaluate

System Analyst

Alert UI

Inventory UI

Action item list

Get Algorithm

Dispatch


3.1.1.8. Receiving

Inventory Manager

Confirms schedule UI

Confirm product Quantities& ID

Supplier

Query Deadline

Receiving UI

Check product Quantities& ID

Update Data

Receiving Report

Analysis Class Diagram For Receiving Use Case


3.1.1 Use-Case Realization

3.1.2.1 Forecasting

Forecaster

ScheduleUI

Past Forecast Report Search UI


Forecast Reports

Coporate Inventory

Management UI


Inventory data

PO Search UI Get pending PO Pending POs

Reconcile inventory

Market Trend DataInput UI

Analyze maket data

Forecast Inventory

Create a forecast

Calculate lead time


schedule

Forecast demand

Forecast report

1. Send request

2. Generate report

3. Filter data

3. Request inventory

4. Generate report

5. Filter data

6. Request pending PO

7. Generate pending PO

8. Filter data 9. Analyze filter data

10. Send market data

11. Generate market report

12. Comparision forecast vs. inventory

13. Generate forecast report

14. Distribute forecast data

15. Setup schedule

16. Send lead time 17. Generate

forecast demand

Collaboration Diagram for Forecasting Use Case


3.1.2.2 Planning

Collaboration Diagram for Planning Use Case

Planner

Forecast Search UI

Purchasing Search UI

Planning UI

Query Forecast Report

Query P.O. Data

Forecast Report

Pending& Released P.O. Data

PlanAnalyzer

Query Supplier Performance

Target Vs. Actual KPI’s


EvaluateKPI’s / Modify Objectives

Updated Plan

1. Send forecast request

2. Generate forecast report

3. Filter forecastdata

4. Send P.O data request

5. Generate P.O. report

6. FilterP.O. Data 7. Analyze

Forecast vs. Actuals

8. Send supplier request

9. Generate Supplier Report

10. Filter SupplierData

11. Generate Plan


3.1.2.3 Purchasing

Bu

Collaboration Diagram for Purchasing Use Case

yer

Finance Manager

Supplier

Purchase Requisition UI

Purchase Order UI

Purchase Requisition Retrieval

Purchase Requisition Approval


Approval UI

Purchase Order Negotiation

Approval Retrieval

Purchase Orders

Invoice Verificaton

Invoice UI

Invoice Generation

Purchase Order Submission

SupplierUI

Invoices

1. Send PR request

2. Submit PR for approval

3. Filter PR for approval

4. Approve PR

5. Mark PR approved

6. Send request for approved PR

7. Query for approved PR

8. Negotiate with Supplier

9. Negotiate with Buyer

10. Create P.O

11. Submit P.O. to Supplier

12. Send P.O. to Supplier

13. Request Create Invoice

14. Create Invoice

15. Retrieve Invoice

16. Filter Invoice Data


3.1.2.4 Supplier’s Performance

1.Send Supplier Request

2. Request Plan

3. Request Supplier

6. Filter Plan Data

7. Filter Supplier Data

8. Send Delivery Time Evaluation

9. Filter DeliveryTime Data

10. Send Quality Evaluation

11. Filter Quality Data

12. Send Commitment Evaluation

13. Filter Commitment Data

14. Send Price Evaluation 15. Filter Price Data

16. Send Data for Grading/ Selection

17. Run Grade and Selection Algorithms

Collaboration Diagram for Supplier Performance Use Case

Supplier Analyst

QueryHandler SupplierUI

Plan

EvaluationUI

SupplierDetails

Analysis Parameters

Grade and

Select

Select Suppliers

Evaluate Delivery Time

Evaluate Quality


EvaluatePrice

Evaluate Supplier Details

Evaluate Plan

4. Get Plan Data

5. Get Supplier Data


3.1.2.5 Tracking Order

Tracker

Query POs

PO Search UI

Order Schedule UI

Supplier Supplier Search UI

POs

Query Suppliers

Get Order Schedule

Tracking Reports Get tracking

Carrier Search UI

Query Carriers

Schedule

Generate tracking

Tracking records

1. Enter PO/BO number

2. Input search criteria

3. Send request

8. Select order schedule

7. Generate schedule form

10. Send order schedule

6. Get Order numbers

9. Send order schedule

4. Query PO

11. Enter Supplier Info 12. Send request

13. Query supplier list

14. Send supplier list

15. Enter carrier info

16. Send request

17. Query carrier list

18. Send carrier list

19. Send tracking records

20. Build tracking records

21. Generate tracking

22. Display tracking results

Collaboration Diagram for Tracking Order Use Case


3.1.2.6 Warehousing

Collaboration diagram for Warehouse-store Transfer Use Case

1. Issue Request

2. Send

3. Update Notices

7. Issue transfer

5. Product Search

6. Check Inventory

8. Complete

7. Return Inventory

12. Get Delivery Date & Time

13. Pick a Date & Time

14. Schedule 15. Update Schedule

16. Confirm

17. Confirm transfer

18. Issue Confirmation

19. Check Transfer Request

20. Return Confirmation

4. Issue Product Search

9. Send Request to System

11. Notify System of Demand


Transfer request UI

Transfer confirmation

Transfer Notice


Transfer Request UI

Transfer

Product

Delivery Schedule

Confirmation

Transfer Schedule UI Transfer Schedule

Warehouse clerk


Inquiry

Back Office System

Warehouse Product Search UI

Dispatch Request



10. Confirm the request valid


Sy

1. Login search form

2. Product Search

3. Check Inventory

4. Return Inventory

5. Login transfer request

6. Send notice to Inventory

7. Send request to system

8. Confirm the request valid 9. Notify the

system the coming demand

11. Update real time demand for requesting warehouse

12. Select a transfer schedule.

13. Send 14. Verify request product available

16. Notify alert agent 17. Notify

requested warehouse personnel

10. Display message

Warehouse transfer request

UI

Transfer

Inventory demand data

Warehouse product search

UI

Query product searched

Product

Dispatch request

Warehouse Manager

Back Office stem


Product transfer schedule UI

Notify requested warehouse

Notify forecast unit


Warehouse Manager

Requested Product data

Collaboration Diagram For Inter-warehousing Transfer Use Case

Confirmation UI

Return Product Data


Transfer Confirmation


15. Get Product Data

18. Confirm 19. ConfirmTransfer

20. Issue Confirmation

21. Check Transfer Request

22. Return Confirmation



Collaboration diagram for System Inventory Management Use Case

Warehouse manager

Alert UI

Generating alert

Request Prioritize requests

Queue requests

Inventory

Send

Planner

Report Alert UI

Inventory UI

Notification Evaluate

System Analyst

Alert UI

Inventory UI

Action item list

Get Algorithm

Dispatch

1. input inventory request

2. Trigger regional inventory alert

3. format to request

4. Get priority level 5. Send to system

6. Generate invetory request

7. Trigger system inventory alert

8. acknowledge

9. Input in system data10. send

11. Generate action items

12. Select routing algorithm

13. Send demands to supply warehouse

14. Response

15. Trigger notification

16. acknowledge

18. Notify planners

17. Decisions made

19. Trigger alert 20. acknowledge


3.1.2.8 Receiving

Inventory Manager

Confirms schedule UI

Confirm product Quantities& ID

Supplier

Query Deadline

Receiving UI

Check product Quantities& ID

Update Data

Receiving Report

1. Get schedule

2. Input ID 3. Resume data

4. Select Deadline

5. Sent Notified Message

6. Receiving Product

7. Input ID 8. Sent

9. Select Data Amount

10. Confirm update

Collaboration Diagram For Receiving Use Case


3.1.3 Package 3.1.3.1 Forecasting

Forecasting

Package Diagram Forecasting

Historical Data Data Evaluation

Data Evaluation

Evaluation Results

Schedule Forecast Evaluation

Forecast Evaluation

Forecast Results


3.1.3.2 Planning

Forecast

Query Forecast

Forecast Data

Planning

Suppliers

Purchase Orders

Plan Generation

Package Diagram for Planning

Query P.O

P.O. Data

Forecast

Query Supplier

Supplier Data

P.O Data

Modify

Suppliers

Plan Analyze


3.1.3.3 Purchasing

Purchasing PR Approval

Retrieval Approval

PO Submission Invoice Verification

PO Negotiation

Purchase Orders

Negotiaton

Package Diagram for Purchasing


Submit PO Purchase Orders

Invoices Generate Invoice

Verify Invoice



Package Diagram for Supplier Performance

Supplier Performance Collect Data

Query Suppliers /

Plan

Analysis Parameters

Evaluate Data

Grade Suppliers

Grade and Select

Analysis Parameters

Evaluate Delivery

Time

Evaluate Quality


Analysis Parameters

Evaluate Price


3.1.3.5 Order tracking

Tracking Management

Supplier

Supplier

Selected Supplier

Search supplier

Organization

Purchase Order

Searched PO

Query PO

Blanket Order

Searched BO

Query BO

Carrier

Carrier

Selected Carrier

Search carrier

Organization

Create Report

Tracking Records

Tracking Data

Forecast data

Validate

Tracking Report

Package Diagram for Order Tracking Management


3.1.3.6 Warehousing

Warehouse Management Products

Product Product History

Product Transfer

Receiving

Supplier

Product

Receiving Organization

Packaging

Distribution

Product

Warehouse or Store

Schedule

Delivery

Notice

Product Notice

Retrieve

Product Retrieve

Package Diagram for Warehouse Management



Inventory

Inventory Inventory Check Alert Alert Handling

Inventory Alert

Package Diagram Inventory Management


3.1.3.8 Receiving

Products

Product Search

Receiving

Product

Receiving Checking

Warning

Product Deadline Warning

Update

Receiving Management

Product

Supplier

Inventory Update data

Package Diagram for Receiving Management


3.1.4 Architectural View (Significant elements, tracabilities)

3.1.4.1 Forecasting

Forecasting

Demand Evaluation Forecasting

<<trace>> <<trace>>

Architecture View For Forecasting


3.1.4.2 Planning

Planning

Forecasting

Suppliers

<<trace>> <<trace>>

Architecture View For Planning

Purchase Orders

<<trace>>


3.1.4.3 Purchasing

Purchasing


Suppliers

<<trace>> <<trace>>

Architecture View For Purchasing

Purchase Orders

<<trace>>




Planning Suppliers

<<trace>> <<trace>>

Architecture View For Supplier Performance


3.1.4.5 Order Tracking

Generate reports

Tracking Management


Purchase Management

Carrier

Forecasting

<<trace>>

<<trace>>

<<trace>>

<<trace>>

<<trace>>

Architecture View For Tracking Management


3.1.4.6 Warehousing

Generate reports

Warehouse Management

Warehouse - store

transfer

Warehouse-warehouse

transfer

Warehouse organization

Receiving

Returns to supplier

Packaging

Distribution

Generate inquiries

<<trace>>

<<trace>>

<<trace>>

<<trace>>

<<trace>>

<<trace>>

<<trace>>

<<trace>>

<<trace>>

Architecture View For Warehouse Management




Generate Alert Handle Alert

<trace> <trace>

Architecture View For Inventory Management


3.1.4.8 Receiving

Receiving Management

Supplier

Warning Message

Update Data

Checking

<<trace>>

<<trace>> <<trace>>

<<trace>>

Architecture View For Receiving Management


4. Design

The design model serves as higher-level view of the source code – a “blueprint” of how the

source code is organized, and some of its key features. Similar to analysis model, the design model

consists of design classes (and types) and design subsystems.

In the transition form the analysis types to the design classes, more details related to the target language

and execution environment will be incorporated.

A design class represents a class at a more detailed, but still high level in the system’s

implementation. Each design object plays one or more roles in the use cases. Design classes are drawn

as rectangles. Exactly what each design class corresponds to in the code depends on the implementation

language.

The design classes can be found by using the use case descriptions and the analysis and by considering

the implementation environment. Which design classes have to be created depends on, for instance,

choice of programming language, process structure, available Commercial Off The Shelf software, and

legacy systems.

As a starting point, each analysis type will be mapped and have a trace to a similar design class.

Then additional design classes may be added, other classes split, combined, or removed, and some

relationships added or changed. For example, new classes may be needed to define attribute types, to

provide support or inheritable super-classes, or to wrap legacy systems.

Likewise, analysis subsystems will be mapped (and have a trace) to corresponding design subsystems,

and others will be added, or changed. Some relationships, such as extends or even inheritance, may be

difficult to implement in some languages, and so should be replaced by associations, such as

communicates, aggregation, or delegation.

Like the analysis model, the design model is organized into subsystems, in which lower-level

subsystems and design classes (and types) are grouped. The design classes (and types) have much the

same properties as the analysis types, but tend to match the intended implementation more closely.


Design Classes

4.1.1 Forecasting

Class dia

gram for Forecasting

ForecastCustomer -CustomerType_id : Number -EstimateCustomerNumber : Number -Product_id : Number -Regional_id: Number + customer_forecast(product_id, estimated_customer_quantity, regional_id, start_date, end_date); +productSaleHistory(product _id, regional_id, quantity_sold, start_date, end_date); +getForecastAccuracy(product _id, forecast_quantity, actual_sold);

ForecastMarket -MarketSector_id : Number -sales_estimated : Number -quantity_sold : Number -start_date: Date -end_date : Date +market_forecast (product _id, sales_estimated, start_date,end_date); +actual_sold (product _id,quantity_sold, start_date, end_date); +getForecastAccuracy (product _id, forecast_quantity, actual_sold);

Forecast -forecast_id : Number -forecast_name:string -forecast_start_date : date -forecast_end_date : date -forecast_desc : string -schedule_id : Number -product_id : Number -customer_forecast : Number -market_forecast : Number -accuracyLevel:Number -start_date : Date -end_date : Date -no_of_items: Number -bucket_number : Number -bucket_size : string +create_forecast(forecast_id, product _id, schedule_id …..); +log_forecast_info(product _id, schedule_id….);

ForecastHistory -forecast_history_id: Number -forecast_rule_id:Number -product_id:Number -customer_forecast : Number -market_forecast : Number -accuracyLevel:Number -start_date : Date -end_date : Date +get_forecast_info(start_date, end_date); +calculate_forecast_accuracy (product_id, start_date, end_date, accurateLevel, ..)

of 206


Relation between classes in class diagram for Forecasting

Product Forecast ForecastHistory

ForecastCustomer ForecastMarket ForecastSupplier

ForecastRule Schedule

1

1

1

*


4.1.2 Planning

Class diagram for Planning

ForecastData -forecast_id : number -forecast_name:string -forecast_start_date : date - forecast_end_date : date -forecast_desc : string -employee_id :number -employee_name : name -schedule_id : number -item_id : number -no_of_items:number -bucket_number : number -bucket_size : string +create_forecast(forecast_iditem_id,…..); +log_forecast_info(item_id, schedule_id….);

ForecastInterface -forecast_rule_id: number -forecast_rule_name:string -forecast_rule_desc:string -customer_forecast:number -market_forecast:number +get_forecast_rule(); +set_forecast_rule (forecast_rule_id,forecast_rule_name,forecast_rule_desc); +calculate_formula (forcast_rule_id,customer_forecast, sales_forecast,misc_forecast,quantity_sold)

BlanketOrder -blanket_order_id: number -purchase_order_release_id: number -supplier_id: number -item_id : number -quantity : number -creation_date:date -get_quantity(), -set_quantity(), -verify_supplier()

KeyPerformanceIndicators -KPI_group_id: number -forecasted_sales: number -actual_sales: number -item_id : number -quantity : number -start_date:date -end_date:date -get_KPIs(), -set_KPIs(), -calculate_KPIs -create_report()


PlanningObjectives -objectives_id: number -region_id: number -items_forecasted: number -start_date : date -end_date : date -items_sold:number -evaluate_data(), -modify_objectives()

PurchasingInterface -purchase_rule_id: number -purchasing_rule_name:string -purchasing_rule_desc:string -start_date:date -end_date:date +get_purchase_orders(); +get_blanket_orders(); -send_po_data(); -send_bo_data()

PurchaseOrder -PO_id: Number -PORNum: Number -Supplier_id: number -Item_id: Number -Approved_date: Date -Approved_by : String +createPO(PO_id: Number) +submitPO(PO_id:Number, Supplier_id: number) +getPOid() +getPORID()

Plan -plan_id: number -forecast_demand_id: number -purchase_ordder_release_id: number -safety_stock_qty : number -on_hand_quantity : date -current_quantity:number -lot size: number -plan_type: string -start_date:date -completion_date: date -description: string -created_by: number -creation_date:date -calculate_planned_qty(), -adjust_planned_qty(), -create_plan,

- Supplier_name: String - Supplier_id : Number - Product_id : Number - Product_name :String - Address : String - Address1 : String - Address2 : String - City : String - State : String - Zipcode : String - Country : String - Phone_number : Number - Email_address : String - Lead time: Number - Last_order_quantity : Number - Last_order : Date + get_supplier_info (); + edit_suppler_info (); + supplier_data_filter(); + send_supplier_notice();

Supplier


Relation between classes in class diagram for Planning

KeyPerformance Objectives

Plan

ForecastInterface Purchasing Interface

Supplier

PurchaseOrder ForecastData BlanketOrder SupplierData


4.1.3 Purchasing

Class diagram for Purchasing

- Supplier_name: String - Supplier_id : Number - Product_id : Number - Product_name :String - Address : String - City : String - State : String - Zipcode : String - Country : String - Phone_number : Number - Email_address : String - Lead time: Number - Last_order_quantity : Number - Buyer_id

+ get_invoice_info (); + verify_invoice_info ();

InvoiceInterface

BlanketOrder -blanket_order_id: number -bo_name: string -supplier_id: number -item_id : number -quantity : number -creation_date:date -buyer_id:number -cost: number -delivery_date:date -get_bo(); -create_bo(); submit_bo();

- invoice_id:number - Supplier_name: String - Supplier_id : Number - Product_id : Number - Product_name : String - Delivery_time : Number - Delivery_time_comments : String - Commitments : Number - Commitments_comments : String - Price : Number - Price_comments : String - Overall_grade : Number - purchase_order_id:number - Comments : String

-get_invoice(); -review_invoice(); -verify_invoice();

Invoice

InvoiceGeneration -invoice_id: number -Supplier_Name: String -purchase_ordder_release_id: number -blanket_order_release_id:number -cost:number -description: string -created_by: number -creation_date:date -create_invoice(); -delete_invoice();


PurchaseOrder/BONegotiation -PO/BO_contract_id: Number -buyer_id: Number -supplier_id: number -Item_id: Number -Approved_date: Date -Approved_by : String -approval_number:number -create_po_contract(); -submit_po_contract(); -create_bo_contract(); submit_bo_contract();

PurchaseOrder -purchase_order_id: number -po_name: string -supplier_id:number -item_id:number -quantity:number -cost:number -delivery_date:date buyer_id:number creation_date:date -create_po(); -get_po(); -submit_po();

PurchaseRequisitionInterface -pr_processing_id: number -pr_name:string -pr_id: number -buyer_id:number -buyer_name:string -approver_id:number -approver_name:string -get_pr(); -edit_pr(); -send_pr_for_approval();

PurchaseOrderInterface -po_processing_id: number -po_name:string -po_id:string -bo_name:string -bo_id:number -buyer_id:number -buyer_name:string -get_blanket_order(); -get_purchase_order(); -negotiate_purchase_order(); -submit_purchase_order();

PR Approval -approval_id : number -approver_name:string -approval_number: number -approval_date : date -item_name : string -item_id :number -purchase_requisition_id:number -create_approval(); -log_approval();


.

Relation between classes in class diagram for Purchasing

Purchase Orders/ Blanket Orders

Invoice

Generation

Invoice

Purchase Order/BO Interface

Supplier

PO/BO NegotiationPO/BO Submission

PR Approval

Purchase Requisition Interface

of 206


4.1.4 Supplier Performance

Class diagram for Supplier Performance

- Supplier_name: String - Supplier_id : Number - Product_id : Number - Product_name :String - Address : String - Address1 : String - Address2 : String - City : String - State : String - Zipcode : String - Country : String - Phone_number : Number - Email_address : String - Lead time: Number - Last_order_quantity : Number - Last_order : Date + get_supplier_info () + edit_suppler_info () + supplier_data_filter() + send_supplier_notice()

Supplier Plan -plan_id: number -forecast_demand_id: number -purchase_ordder_release_id: number -safety_stock_qty : number -on_hand_quantity : date -current_quantity:number -lot size: number -plan_type: string -start_date:date -completion_date: date -description: string -created_by: number -creation_date:date -calculate_planned_qty(), -adjust_planned_qty(), -create_plan() -plan_data_filter()

- Supplier_eval_id: Number - Supplier_eval_date: Date - Supplier_name: String - Supplier_id : Number - Product_id : Number - Product_name : String - Delivery_time : Number - Delivery_time_comments : String - Quality : Number - Quality_comments : String - Commitments : Number - Commitments_comments : String - Price : Number - Price_comments : String - Overall_grade : Number - Selected : Number - Comments : String

+ delivery_time_eval_filter() + quality_eval_filter() + commitments_eval_filter() + price_eval_filter() + send_supplier_data() + supplier_select()

SupplierEval

QueryHandler

+plan_request() +supplier_request()

- Supplier_name: String - Supplier_id : Number - Product_id : Number - Product_name :String - Address : String - Address1 : String - Address2 : String - City : String - State : String - Zipcode : String - Country : String - Phone_number : Number - Email_address : String - Lead time: Number - Last_order_quantity : Number - Last_order : Date + get_selectedsupplier_info () + edit_selectedsuppler_info () + selectedsupplier_data_filter() + send_selectedsupplier_notice()

Selected Supplier


Relation between classes in class diagram for Supplier Performance

Supplier

SupplierEval SelectedSupplier

Product


4.1.5 Tracking

Of

Class diagram for Tracking

Order -orderID: number -orderDate: date -orderStatus: string -total:number -shipDate: date -shipOption:number -freight: number -fromPO: number -description: string +getOrderNum() +getOrderSchedule() +changeOrderStatus (orderNumber:Number) +getOrderDate() +isChildOrder()

Purchase_order -PO_id: Number -PORNum: Number -Supplier_id: number -Item_id: Number -Approved_date: Date -Approved_by : String +createPO(PO_id: Number) +submitPO(PO_id:Number, Supplier_id: number) +getPOid() +getPORID()

Tracking -trackingNumber: Number -OrderID: Number -POID: Number -shipToLocationCode: Number -carrierID: Number -OnTime:boolean -shipOption:number -latestDeliverAllowed: Date -supllierID: Number -description: String +gettrackingNum() +getDeliverSchedule() +isOnSchedule(latestDeliverAllowed:Date,POID:Number,…) +getCarrierOption();

Carriers -Carrier_id :Number -Carrier_desc : String -CarrierOption: Number +getCarrier (carrierOption: Number, Carrier_id:Number)

Suppliers -Supplier_id :Number -Supplier_desc : String -Product_id: Number +getsupplier (item_id: Number, Supplier_id:Number)

- Location_id: Number - Warehouse_id : Number - Region_id : Number - Address : String - Address1 : String - Address2 : String - City : String - State : String - Zipcode : String - Country : String - Phone_number : Number - Fax_number : Number - Email_address : String - Notes : String - Manager : String - Notices : String + get_warehouse_info() + edit_warehouse_info() + send_warehouse_notice()

Warehouse

of 206 ficeDepot™ - Confidential

Order

Tracking

Purchase_Order

Supplier Carrier

Warehouse

Relation between classes in class diagram for Tracking


4.1.6 Warehousing

Class diagram for Warehousing

- Confirmation_id: Number - Confirmation_date: Date - Confirmed: Boolean - Confirmed By: String - Transaction_id : Number - Transaction_date : Date - Product_id : Number - Confirmed_quantity : Number - Warehouse_id : Number - Warehouse_location_id: Number - Receiving_location_id : Number - Shipment_date: Date - Priority : Number - Notes : String - Approved_by : String

+ confirmation() + generate_confirmation() + get_confirmation() + query_confirmation()

Confirmation

- Dispatch_request_id: Number - Demand_id: Number - Demand_confirm: Boolean - Transaction_id : Number - Transaction_date : Date - Product_id : Number - Warehouse_quantity : Number - Warehouse_id : Number - Warehouse_location_id: Number - Receiving_location_quantity: Number - Receiving_location_id : Number - Shipment_date: Date - Priority : Number - Notes : String - Approved_by : String

+ dispatch_request()

Dispatch Request

- Schedule_id : Number - Delivery_date: Date - Delivery_time: Time - Region_id : Number - Address : String - Address1 : String - Address2 : String - City : String - State : String - Zipcode : String - Country : String - Phone_number : Number - Notes : String - Manager : String - Delivery_status: String

+ get_schedule() + select_schedule() + update_schedule()

Delivery Schedule

-Product_id:Number -quantity:Number -Update_date:Date

currentStock

+getAvailability(product_id:Number) +setAvailability(product _id:Number, quantity:Number)


- Demand_id: Number - Demand_confirm: Boolean - Transaction_id : Number - Transaction_date : Date - Product_id : Number - Warehouse_quantity : Number - Warehouse_id : Number - Warehouse_location_id: Number - Receiving_location_quantity: Number - Receiving_location_id : Number - Shipment_date: Date - Priority : Number - Notes : String - Approved_by : String

+ confirm_request()


Receiving Location

Requested Product

+verify_requested_product() +get_product_info()

-Product_id : Number -SKU: String -Description:String -Size :String -Weight: Number -Lot : Number -Sublot : Number -Level : Number -Supplier_id : Number -UPC_code : Number -Receive_date : Date -Expiration_date : Date -Notes : String -Sales_strength : Number -Configurable: Boolean -Supplies_Accessories:Boolean

+getPrice() +getDescriptions() +overrride() +setProductState()

Product

-Product_id:Number -quantity:Number -Update_date:Date -Warehouse_id:Number -Regional_id:Number -DaysInactivity:Number

Stock


safetyStock

-Product_id:Number -quantity:Number -max_allowable_quantity:Number -min_allowable_quantity:Number -Created_by:String -Create_date:Date

+getSafetyStock(item_id:Number) +setSafetyStock(item_id:Number quantity:Number)


- Location_id: Number - Store_id : Number - Region_id : Number - Regional_warehouse_id : Number - Address : String - Address1 : String - Address2 : String - City : String - State : String - Zipcode : String - Country : String - Phone_number : Number - Fax_number : Number - Email_address : String - Manager : String - Notes : String - Notices : String + get_store_info () + edit_store_info () + send_store_notice()

Store

- Transaction_id : Number - Transaction_date : Date - Product_id : Number - Quantity : Number - Warehouse_id : Number - Receiving_location_id : Number - Shipment_date: Date - Priority : Number - Notes : String - Approved_by : String + send_request() + transfer_request() + transfer_notice() + transfer() + transfer_schedule() + update_stock()

Warehouse Transfer

- Location_id: Number - Warehouse_id : Number - Product_id : Number - Quantity : Number - Supplier_id : Number - Zone : Number - Lot : Number - Sublot : Number - Level : Number - Receive_date : Date - Expiration_date : Date

+ get_organization_info () + edit_organization_info ()

Warehouse Organization

- Location_id: Number - Warehouse_id : Number - Region_id : Number - Address : String - Address1 : String - Address2 : String - City : String - State : String - Zipcode : String - Country : String - Phone_number : Number - Fax_number : Number - Email_address : String - Notes : String - Manager : String - Notices : String + get_warehouse_info() + edit_warehouse_info() + send_warehouse_notice()

Warehouse


Relation between classes in class diagram for Warehousing

Warehouse

WarehouseTransfer

WarehouseOrganization

Stock

Confirmation

DeliverySchedule

ReceivingLocation

Warehouse Store


DispatchRequest

RequestedItem



Class diagram for System Inventory Management

-Lot_id:Number -transaction_id:Number -Lot_size:Number -Stardate:Date -Enddate:Date -Dateonshelf:Date -Expirydate:Date -Created_by:String -Create_date:Date

InventoryLots

+getLotSize(item_id:Number) +updateLotSize(item_id:Number, lot_size:number)

AlertHandler

-AlertSent:Alert -Duration:Number -Level:Number -Type:String -MethodSend:String

+send(alert:Alert) +cancel(alert:Alert) +promote(alert:Alert, level:Number)+demote(alert:Alert, level:Number)+SelectMethod(level:Number) +close()

Alert

-Alert_id:Number -Alert_type:String -Alert_reason:String -Message_id:Number -Create_timestamp:Timestamp -Inventory_id:Number -Adjustment:Number

+getalert(alert_id:Number) +setAlert(alert_type:String, item_id:Number, adjustment:Number) +send() +queue() +promote() +demote() +cancel() +close()

InventoryHandler

-Transaction_id:Number -Product_id:Number -Order_id:Number -DeliveryDate:Date -Quantity:Number -Warehouser_id:Number -Lot_id:Number -Sublot_id:Number -Carrier_id:Number -Note:String -Alert:Boolean

+dispatchRequest(warehouse_id: Number) +updateStock(product_id:Number, quantity:Number) +NotifyForecast(transaction_id:Number) +sendAlert(); +UpdatePlanning(); +InitNewPurchase();

-Product_id:Number -quantity:Number -Update_date:Date

currentStock

+getAvailability(product_id:Number)+setAvailability(product _id:Number, quantity:Number)

InventoryProcess

+transfer() +updateStock() +Notify() +sendAlert()


-Product_id : Number -SKU: String -Description:String -Size :String -Weight: Number -Lot : Number -Sublot : Number -Level : Number -Supplier_id : Number -UPC_code : Number -Receive_date : Date -Expiration_date : Date -Notes : String -Sales_strength : Number -Configurable: Boolean -Supplies_Accessories:Boolean

+getPrice() +getDescriptions() +overrride() +setProductState()

Product

-Product_id:Number -quantity:Number -Update_date:Date -Warehouse_id:Number -Regional_id:Number -DaysInactivity:Number

Stock


PriorityHandler

-Transaction_id:Number -Product_id:Number -Invoice_id:Number -ReceivedDate:Date -Quantity:Number -Warehouser_id:Number -Lot_id:Number -Sublot_id:Number -Supplier_id:Number -Carrier_id:Number -Note:String -Alert:Boolean

+transfer(warehouse_id:Number) +updateStock(product_id:Number, quantity:Number) +Notify(transaction_id:Number) +sendAlert()

safetyStock

-Product_id:Number -quantity:Number -max_allowable_quantity:Number -min_allowable_quantity:Number -Created_by:String -Create_date:Date

+getSafetyStock(item_id:Number) +setSafetyStock(item_id:Number quantity:Number)


Alert

InventoryProcess

InventoryHandler

PriorityHandler

AlertHandler

Product

InventoryLot

Stock

CurrentStock SafetyStock

1

1 1

1

*

**

*

1

1

1

Interface

*


Created

Pending

+getAlert()

Queued

+promote()

Sent

+send()

Closed

+close()

+cancel()

+demote()

Statechart Diagram for the Alert class


4.1.8 Receiving

Class diagram for Receiving

-Item_id:Number -Item_amounts:Number -Departure_date:Date -Arrived_date:Date -Supplier_id:Number

Schedule

+Send_schedule(item_id:Number, item_amounts:Number, departure_date:Date,

Supplier

-Item_id:Number -Item_amounts:Number -Departure_date:Date -Inventory_info:String

+Send(-Item_id:Number, item_amounts:Number, departure_date:Date, inventory_info:String)

Inventory

-Item_id:Number -Item_amounts:Number -Arrived_date:Date -Supplier_id:Number

+arrive(item_id:Number, item_amounts:Number, arrived_date:Date)

-Item_id:Number -Item_amounts:Number

Receiving

+check(item_id:Number, item_amounts:Number)

Warn

-Warn_id:Number -Warn_reason:String -Item_id:Number -Arrived_date:Date

+warn(Warn_id:Number, warn_reason:String, item_id:Number, arrived_date:Date)


Planner

Schedule

Inventory Supplier

Receiving_Check Deadline_Warning


4.1.9 Common classes Employee

-ID: Number -type: String -firstName: String -lastName: String -age: Number -DOB: Date -POB: String -Address: String -jobTitle: String -jobCode: Number -jobLocation: String -dateOfHire: Date -degree: String

+getID() +getType() +getName(id:Number) +getAddress(id:Number) +getJobTitle(jobcode:Number) +getJobCode(id:Number) +getJobLocation() +getDegree() +setJobTitle(jobCode:Number) +setJobCode(id:Number) +promote(curID:Number. newID:Number)+setJobLocation(newLoc:String)

Forecaster

+Forecaster() …

Planner

+Planner() …

SystemAnalyst

+SystemAnalyst()…

Purchaser

+Purchaser() …

Saleman

+Saleman() …

Warehousemgr

+warehousemgr()…

Employee

Forecaster Planner System Analyst

Purchaser Saleman Warehouse manager


4.2 Design Subsystems 4.2.1 Forecasting

<<service package>> Evaluate data

<<service subsystem>> Evaluate data

Design Model

Analysis Model

A class referencing Data evaluation from the outside

Implies candidate

Evaluation

Data evaluation

Historical data Evaluation results

<<trace>>

Subsystem diagram for Forecasting

of 206


4.2.2 Planning

Analysis Model

<<service subsystem>> Planning Objectives

<<trace>> Implies candidate

Planning Objectives

Design Model

A class referencing Planning Objectives From the outside

Subsystem diagram for Planning

<<service package>> Planning Objectives

Forecast Data KPI Analysis

Objectives Supplier Data

Purchasing Data


4.2.3 Purchasing

Analysis Model

<<service subsystem>> Invoice Verification


Invoice Verification

Design Model

A class referencing Invoice Verification From the outside

Subsystem diagram for Purchasing

<<service package>> Invoice Verification

PO/BOData Invoice Generation

Verification Invoices




Analysis Model

Design Model

Analyze

A class referencing Grade and Select from the outside

Subsystem diagram for Supplier Performance <<service package>> Grade Suppliers

Grade and Select

Analysis Parameters

<<service subsystem>> Grade Suppliers


4.2.5 Tracking

Create Report

<<Service package>> Tracking Records

Tracking Data

Forecast data

Validate

Tracking Report

Design Model

Analysis Model

A class referencing BuildTrackingReport from the outside

Implies candidate

BuildTrackingReportds

<<trace>>

Subsystem diagram for Tracking

<<Service subsystem>> Tracking Records


4.2.6 Warehousing

<<service package>> Products

Product Product History

Product Transfer


Analysis Model

Design Model

Creates

A class referencing Product Transfer from the outside

<<service subsystem>> Products

Subsystem diagram for Warehousing



Analysis Mo

Design Mode

A class refFrom the o

OfficeDepot™ - Con

Subsystem diagram for Inventory Management

del <<service package>> Inventory Management

InventoryProcess

PriorityHandler /InventoryHandler

AlertHandler Alert

<<service subsystem>> Inventory Management


Alert Handling

l

erencing Aler Handler utside

of 206 fidential

4.2.8 Receiving

Analysis Model <<service package>> Receiving Management

Inventory Deadline Warning

Receiving Check Supplier

<<service subsystem>> Receiving Management


Receiving Check

Design Model

A class referencing Receiving Check From the outside

Subsystem diagram for Receiving Management


4.2.9 Dependencies and layers

PurchaseOrder Management

Payment Management

Account Mangement

Application - Specific Layer

Application – General Layer

Middleware Layer

System -software Layer


Java.beans Javax.swing Java.rmi Javax.ejb

JVM EJB Container JSP Web Browser

TCP/IP

Subsystem Diagram in the Purchasing


Warehouse transfer

System Alert Management

System Inventory Mangement

Application - Specific Layer

Application – General Layer

Middleware Layer

System -software Layer


Java.beans Javax.swing Java.rmi Javax.ejb

JVM EJB Container JSP Web Browser

TCP/IP

Subsystem Diagram in the Warehousing


Presentation details (CSS)

Presentation structure (XSLT)

XML JSP’s

Taglibs

Session bean

Entity beans

Database (Oracle, LDAP)

Presentation Layers

Information Layer

Logic Interface Layer

Logic Layer

Data Interface Layer

Data Layer


4.3 Usecase Realization

4.3.1 Forecasting

Collaboration Diagram for Forecasting Use Case

Forecaster

:Forecast SearchUI

:Inventory ManagementUI

:POSearchUI

:Market TrendUI

:ScheduleUI

:QueryHandler

:PO

:Product

:Forecast

:Schedule Processing :Schedule

:MarketData

:Forecast Demand

:Forecasting

:Inventory Reconcile

:Evaluation Process

:Evaluation Result

2. SearchForecast() 3. getForeCast()

8. Get Inventory()

12. getCurrentPO()

19. Display Schedule()

4. sendForeCast()

6. SearchtInvetory()

7. Request Invetory() 9. Update() 14. SendReport()

10. InputPO()

11. SearchPO()

13. convertProduct()

15. evaluateData()

17. InputTimePlan()

18. setTime()

20. Leadtime() 16. sendPreForecastdata()

21. InputMarketData()

1. InputForecasrParamenter()

22. dataAnalysis() 22. AnalysisReport()

23. getForecastDemand()

of 206


4.3.2 Planning

Collaboration Diagram for Planning Use Case

:Forecast SearchUI

:Purchasing Search UI

:Planning UI

:QueryHandler

:Forecast Reports

:Updated Plan

:Plan Analyzer

:Targetvs ActualKPIs

3. SearchForecast()

1. InputForecastParameters()

:Supplier Performace

:PO/BO Data

2. RequestForecast()

:Eval/Modify Objectives

4. SendForecast()

5. InputPurchasing Parameters()

6. Request Purchasing()

7. Search Purchasing()

8. SendPurchasing()

10. SendTarget VsActualsKPIs()

11. InputSupplier Parameters() 12. Request

SupplierData()

13. Search SupplierData()

14. SendSupplierData()

15. Send Modified Plan()

9. SendAnalyzedData()


4.3.3 Purchasing

1. InputPRParameters()

Collaboration Diagram for Purchasing Use Case

:Purchase RequisitionUI

:PO/BO UI

:Invoice UI

:QueryHandler

:Purchase Requisitions

:PO/BO Negotiation

:Approval UI

:Purchase/ Blanket Orders

:PR Approvals 6. InputApproval

Parameters()

16. InputInvoice Parameters()

:Supplier UI

:PO/BO Submission

:Invoice Generation

:Invoices :Invoice Verification :QueryHandler

2.RequestPR()

3. SearchPR() 4. SendPR()

5. ApprovePR() 7. RequestApprovedPRs()

8. SearchApprovedPRs()

9. BuyerNegotiate()

10. SupplierNegotiate()

11. CreatePO()

13. Create Invoice()

14. Send Invoice() 15. Return

Invoice() 17. RequestInvoice() 18. VerifyInvoice()

Finance Mgr.

Supplier



Collaboration Diagram for Supplier's Performance

Supplier Analyst

:SupplierUI :EvaluationUI

:QueryHandler

:Supplier

:Selected Supplier

:SupplierEval

:Plan

:SupplierEval :SupplierEval :SupplierEval :SupplierEval

:SupplierEval

1.send_ request()

2. plan_ request()

3. supplier_ request()

6. plan_data_ filter()

7. supplier_data_filter()

8. send_ delivery_ time()

9. delivery_ time_ filter()

10. send_ quality_ eval()

11. quality_ eval_ filter()

12. send_ commitment_ eval()

13. commitment_ eval_ filter()

14. send_ price_ eval()

15. price_ eval_ filter()

16. send_ supplier_ data()

17. supplier_ select()

:SupplierEval :SupplierEval

5. get_supplier_ data()

4. get_plan_ data()


4.3.5 Tracking

:T ReportUI

racking

:PurchaseOrder

:Order

:Supplier

:Carrier

:Tracking

Forecaster

:POSearchUI

:OrderSearchUI

:Supplier SearchUI

:Carrier SearchUI

:QueryHandler

:Report Builder

1. InputPONumber()2. searchPO()

3. getPOs()

4. POReport()

5. InputOrder Number()

6. searchOrder ()

7. getOrders()

8. OrderReport()

9. InputSupplierID()

10. searchSuppliers ()

11. getSuppliers()

12. SupplierList()

13. Input CarrierID()

14. searchCarriers ()

15. getCarriers()

16. CarrierList()

17. RequestTrackingReport()

18. Send()

19. GenerateReports

Collaboration diagram for Tracking Use Case


4.3.6 Warehousing

Collaboration diagram for Warehouse-store Transfer Use Case

: Transfer Request UI

Warehouse Clerk


: Confirmation

: Transfer Schedule UI

: Confirmation UI

: Confirmation

:CurrentStock

:Delivery Schedule

: SafetyStock

:Delivery Schedule

: Confirmation

1. transfer_request()

2. transfer_notice()

3. getAvailability()

4. getSafetyStock()

6. transfer()

5. update_stock()

9. get_schedule()

10. select_schedule() 11. update_schedule()

12. confirmation()

13. generate_ confirmation()

14. get_confirmation()

15. query_confirmation()

:Warehouse Transfer

:Warehouse Transfer

Back Office System

: Transfer Request UI

: Warehouse Stock Search

: Request Alert Agent

: Inventory Demand Data

7. send_request()

9.dispatch_ request ()

: Dispatch Request

8. confirm_ request()


3. update_stock()

Collaboration diagram for Interwarehouse Transfer Use Case

:Warehouse Clerk

:Warehouse Manager

: Back Office

System


:Warehouse Stock Search

: Inventory Demand Data

: Warehouse Transfer

:CurrentStock

:Transfer Request UI


: Forecast Unit

:Warehouse Transfer

: Dispatch Request

: Requested Item

: Delivery Schedule

:SafetyStock

4. transfer()

1. getAvailability() 2. getSafetyStock()

5. send_request()

6. confirm_request()

7. dispatch_request()

8. update_demand()

9. update_schedule()

11. verify_requested_product ()

13. notify_alert()

10. transfer_notice()

: Confirmation

: Confirmation

: Confirmation

: Requested Item

: Confirmation UI

12. get_product_info()

14. confirmation()

15. generate_confirmation()

16. get_confirmation()

17. query_ confirmation()



Collaboration diagram for System Inventory Management Use Case

Warehouse manager

:Inventory UI

3.getAvailability()

:CurrentStock

:SafetyStock

4.getSafetyStock()

:PriorityHandler

2.request() 1.InputData()

:Alert

5.Notify()

Warehouse Manager

:AlertHandler

7.Send()

:InventoryHandler

8.SelectMethod()

9. dispatchRequest()

6.Queue()

* InventoryIn decision table

** InventoryOut decision table

:InventoryManagentUI

:PurchaseRequisitionUI

:PlanningUI

Forecast analyst

Buyer

Planner

10.NotifyForecast()

11. InitNewPurchas()

12. UpdatePlanning()


PriorityHandler Rulesets: Alert at priority level A: when the the current inventory falls below 25 % the warehouse threshold level OR (the lead time is greater than 4 weeks

AND the system inventory availability is NOT available)

Alert at priority level B: when the the current inventory falls below 15 % the warehouse threshold level OR (the lead time is greater than 2 weeks)

Alert at priority level C: when the the current inventory falls below 10 % the warehouse threshold level OR (the lead time is greater than 2 weeks)

Alert at priority level D: when the the current inventory falls below 5 % the warehouse threshold level OR (the lead time is greater than 2 weeks)

Alert at priority level E: when the the current inventory falls in the warehouse threshold level

The alert level will be promoted by one level when the stock requested has lead time = 4 weeks or system inventory is not available.

The alert level will be demoted by one level when stock requested has lead time = 1 weeks or system inventory is available.

1. Condition A: The stock requested below threshold level of the requested warehouse

Priority level A: < threshold level 25%

Priority level B: < threshold level 15%

Priority level C: < threshold level 10%

Priority level D: < threshold level 5%

Priority level E: = threshold level

2. Condition B: lead time

H: = 4 weeks

M: = 2 weeks

L: = 1 weeks

3. Condition C: system inventory available

N = not available

Y = available


Total of rulesets = 5 x 3 x 2 = 30

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Cond A A B C D E A B C D E A B C D E A B C D E A B C D E A B C D E

Cond B H H H H H M M M M M L L L L L H H H H H M M M M M L L L L L

Cond C Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y N N N N N N N N N N N N N N N

Priority A x x x x x

Priority B x x x x x x

Priority C x x x x x

Priority D x x x x

Priority E x x x x x

x

x

x x

x

InventoryHandler Rulesets:

Transfer stock from warehouse type A: transfer stock from the nearest proximal warehouse of the requested warehouse when the requested

quantity is <10% of that warehouse stock surplus AND it has not sent any stock alert.

Transfer stock from warehouse type B: transfer stock from any regional warehouse of the requested warehouse when the requested quantity is

<20% of that warehouse stock surplus AND there is no regional alert.

Transfer stock from ware house type C: transfer stock from a non-regional warehouse when the requested quantity >20% of that warehouse stock

surplus AND there is no regional alert.

Transfer stock from warehouse type D: transfer stock from supplier when none of above conditions satisfied.

The warehouse type will be demoted if there is at least an alert in the regional.

The warehouse type will be demoted if the supplied warehouse also send a stock alert

Condition A: Get the stock requested is avail in a warehouse which is:

A: nearest proximal warehouse if the quantity < 10% of the warehouse stock surplus


B: any regional warehouse if the quantity < 20% of the warehouse stock surplus.

C: a non-regional warehouse if the quantity >20 % of the warehouse stock surplus.

D: get from suppliers

Condition B: The level of the supplied warehouse is change if

N: there is no alert in the region of the requested warehouse

Y: there is at least an alert in the region of the requested warehouse

Condition C: The second nearest of the requested warehouse will be selected if

T: the supplied warehouse also send a stock alert

F: the supplied ware house has not sent any stock alert

Total of rulesets = 4x2x2 = 16

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Cond A A B C D A B C D A B C D A B C D

Cond B Y Y Y Y N N N N Y Y Y Y N N N N

Cond C T T T T T T T T F F F F F F F F

Type A x

Type B x x x

Type C x x x x

Type D x x x x x x x x


Pseudo code: PriorityHandler class: public PriorityHandler extends Inventory {

. . . . .

Alert Notify() {

//This function create alert type and send alert object to the

system.

1. Get the stock request quantity

2. Initiate alert type = A

3. if the current inventory below 25% of the threshold level

3.1 set alert type A

3.2 if the lead time of the product is 1 week or system

inventory is availble then set alert type B.

3.3 if the lead time of the product is 4 weeks or system

inventory is not available then set alert type A


4.1 set alert type B


inventory is availble then set alert type C.


inventory is not available then set alert type A


5.1 set alert type C


inventory is availble then set alert type D.


inventory is not available then set alert type B


6.1 set alert type D


inventory is availble then set alert type E.


inventory is not available then set alert type C

7. if the current inventory is equal of the threshold level

7.1 set alert type E

8. return alert

}//end Notify() function

}//end PriorityHandler class


InventoryHandler class: public InventoryHandler extends Inventory {

. . . . .

Request WarehouseTransfer() {

//This function select a supplied warehouse and send a request to

the system.

1. Get the stock request quantity

2. while a warehouse ID has not been found do

2.1 if the nearest warehouse has 10% of the stock surplus >

requested quantity and there is no alert for the stock then

send the warehouse ID request.

2.2 else loop for all regional warehouse

2.2.1 if the regional warehouse has 20% of the stock surplus >

requested quantity and there is no regional alert for the

stock then send the warehouse ID request

2.2.2 break

2.3 if warehouse ID has not been found yet loop for all non-

regional warehouse

2.3.1 if the non- regional warehouse has 20% of the stock

surplus > requested quantity and there is no regional

alert for the stock then send the warehouse ID request

2.3.2 break

3. if a warehouse ID has not been found, get supplier of the product.

4. send request to the system for product order.

}//end WarehouseTransfer() function

}//end InventoryHandler class


2.3.1 Receiving


1. Get schedule()

2. Input ID() 3. Resumedata()

4.SelectDeadline() 5. SentWarningMessage()

7.InputID()

6. Receiving Product()

8.Sent()

9.Select Data Amount()

10.Confirmupdate()

:Confirm Schedule UI

:Confirm product Amount & ID

:Supplier

:Query Deadline

:Check product Amount & ID

:Receiving UI

:Update Data

:Generate Receiving

Collaboration diagram for Receiving Use Case


of 206

Forecast Rules

Schedule

Applied for

Demand History Product_ID View

Planner Rule_ID

Create

Associate to

Forecast demand

Forecast_ID Create

Becomes

Plan Plan_ID

View

Plan Order

Release

POR_ID

Employee

Buyer

d

Negotiate

Supplier

Create

Purchase Order

Submit to

Alert

Cause

On handView

Update

Inventory

Use

Use

Alert_ID

Item_ID, Update date

PO_ID

Purchase Order

Release

d


Blank purchase order

Has a Deduct from

Purchase Order

Blanket Order

PO_ID

BPO_ID BPR_ID

BO_ID

Schedule Receipt

ItemID Duedate

Inventory Lot

Lot_ID

CauseSafety Stock ItemID

createdate

1 1 1

1

1

1

1 1 1

1 1

1

1

1

M

M

M M

M M

M

M

1

1

1

1 1

M

1

Manages

Warehouse Manager

1

1

Warehouse_ID

Warehouse Database

Entity Relationship Diagram

4.4 Database Design


Entity Relationship Diagram for Warehousing

Warehouse

Warehouse_id

Found in Inventory Lots

1

Requested Product

Warehouse Manager Products

Receiving Location

Warehouse Store

Forecast Demand

Contains

Organizes Stored in

Product_id

Warehouse_id

Interacts with

Updates

Transfers

Requests Contain

Transfers

d

Store_id

M

M

M

M

M

M

M

M

M

M1 1

1

1 1

Back Office System

1

1

1

1

Lot #

Sold in

Store Store_id

M

1

Manages

1

M


4.5 Deployment Model

Retail Store Manager

Store Client

Warehouse server

Warehouse Manager

Warehouse client

Internet

Intranet

System server

System client

System Analyst

Supplier server

Supplier client

Supplier

Intranet

Intranet

Internet

IntranetInternet

*

1 1 *

*

*

*

*

*1

1

1

1


Purchaser

Supplier

System Server

Router

Internet

Printer Hub

Database DB Server

Router

Router

Router

Router

Hub

System ClientSystem Client System Client

Warehouse client

Warehouse Server

Hub

Warehouse client Warehouse client

Forecaster Planner

Supplier

Store Client

Router

Hub

ISP Provider

Store Client

Store Client

Printer


5. Implementation

In implementation, we start with the result from design and implement the system in terms of components,

that is source code, scripts, binaries and executable files.

Following the system’s architecture captured during the design phase, the implementation phase is to

flesh out the architecture and the system as a whole. In the other words, the purposes of implementation

are to:

Plan the system integrations required in each iteration. Our approach to this is incremental,

which results in a system that is implemented as a succession of small and manageable

steps.

Distribute the system by mapping executable components onto services in the deployment

model. This is primarily based on active classes found during design

Implement the design classes and subsystems found during design. In particular, design

classes are implemented as file components that contain source code.

Unit test the components, and then integrate them by compiling them and linking then

together in to one or more executables, before they are sent to integration and system tests.


5.1 Implementation subsystems

5.1.1 Forecasting

ForecastMarket

ForecastCustomer

Forecast

Employee

Schedule

Forecast history

Product

ForecastSupplier

<<file>>

<<design subsystem>>

<<file>>

<<trace>>

<<Implementation subsystem>>

<<trace>>(1:1)

<<trace>>

a = query demand b = evaluate

a b

Subsystem Diagram for Forecasting


5.1.2 Planning

Off


ForecastInterface

Purchasing Interface

Objectives

Employee

Key Performance

Plan

Supplier Interface

<<trace 1:2>>

<<trace 1Supplier Data

Purchase Order

Blanket Order

Forecast Data

of 206 iceDepot™ - Confidential


<<trace>>(x:x)

<<file>>

<<file>>

:

<<trace 1:2>>

<<file>>2>>

<<file>>

><<file>>

a = query demand
b = evaluate
a
b
Subsystem Diagram for Planning

<<trace1:2

<<trace 1:3>

5.1.3 Purchasing

PurchaseRequisition Interface

PurchaseOrder Interface

InvoiceGeneration

Employee

PurchaseOrders/ BlanketOrders

Invoice

Supplier Interface

<<file>>


<<file>>

<<trace 1:2>>


<<trace>>(x:x)

<<trace 1:2>>

a = query demand b = evaluate

a b

Subsystem Diagram for Purchasing

InvoiceGeneration

PR Approval

PO/BO Submission

PO/BONegotiation

<<file>>

<<file>>

<<trace1:2

<<trace 1:2>>

<<trace 1:3>><<file>>



<<design subsy

<<trace>> (1:1)

stem>> <<implementation subsystem>>

<<file><<trace>>

a = evaluate b = select

Suppliers

Selected Suppliers

SupplierEval

a b

Subsystems Diagram for Supplier Performance


Subsystem Diagram for Tracking


5.1.5 Tracking

<<file>>

<<file>>


<<trace>>(1:1)

a = Tracking b = Report a b

warehouse

Carriers

se ordPurcha

Tracking

<<trace>>

Suppliers

Order


5.1.6 Warehousing

<<trace>> (1:1)

<<design subsystem>> <<implementation subsystem>>

<<file>

<<file>

Warehouse

Store

Product <<file>

<<trace>>

<<trace>>

<<trace>>

a = transfer b = schedule

Warehouse Organization

Delivery Schedule

Warehouse Transfer

a b

Subsystems Diagram for Warehousing



CurrentStock

SafetyStock

InventtoryLot

AlertHandler

Product

InventoryHandler

Alert

PriorityHandler

<<file>>


<<file>>

<<trace>>


<<trace>>(1:1)

<<trace>>

a = query demand b = alert

a b

<<file>>

<<file>>

Subsystem Diagram for System Inventory Management


Subsystem Diagram for Receiving


5.1.8 Receiving

<<design subsystem>> Supplier

a = receiving check b = warning a b

Receiving

Inventory

Schedule

Warning

<<file>>

<<file>>

<<trace>>(1:1)

<<tra >>

<<trace>>

ce


5.2 Components

5.2.1 Forecasting

check Inventory

Gets

<<file>>

product.java

GetProduct

Gets

Selects

<<file>>

ForecastRule.java

SelectForeCastRule

Selects

Evaluates

<<file>>

Forecast.java

getForeCastDemand

Evaluates

File and Executable components


Analyze

Gets

<<file>>

ForecastMarket.java

GetForecastMarket

Gets

Gets

<<file>>

ForecastCustomer.java

GetForecastCustomer

Gets

Gets

<<file>>

ForecastSupplier.java

GetForecastSupplier

Gets

Gets

<<file>>

ForecastHistory.java

GetForecastHistory

Gets


5.2.2 Planning

Create Plan

Gets

<<file>>

getforecast.java

RequestForecast

Gets

Gets

<<file>>

getpurchasingdata.java

RequestPurchasing

Gets

Gets

<<file>>

getsupplierdata.java

GetSupplierData

Gets



Create Plan

Evaluates

<<file>>

analyzeplan.java

AnalyzePlan

Evaluates

Evaluates

<<file>>

analyzeactuals.java

AnalyzeActuals

Evaluates

Evaluates

<<file>>

analyzesuppliers.java

AnalyzeSuppliers

Evaluates



Create Plan

Creates

<<file>>

createplan.java

CreatePlan

Creates



5.2.4 Purchasing

Create Invoice

Gets

<<file>>

getPR.java

RequestPR

Gets

Evaluates

<<file>>

approvePR.java

ApprovePR

Evaluates

Creates

<<file>>

createpo/bo.java

CreatePO/BO

Creates



Create Invoice

Evaluates

<<file>>

negotiatePO/BO.java

NegotiatePO/BO

Evaluates

Creates

<<file>>

submitPO/BO.java

SubmitPO/BO

Creates

Creates

<<file>>

createinvoice.java

CreateInvoice

Creates




Design Model Implementation Model

<<trace>>

<<file>>

Evaluate Supplier Performance SupplierEval.java

evaluates evaluates

<<trace>>

<<file>>

Select Supplier SupplierSelect.java

selects selects

Files and Executable Components



5.2.5 Tracking

Select <<file>>

PO.java

Select

GetPO

GetOrder

Select

<<file>>

Order.java

Get Get

SearchPO



GetSupplier

Report Report

RepoerForecaster <<file>>

Report.java

Get

<<file>>

Supplier.java

Get

GetCarrier

Get Get

<<file>>

Carrier.java

5.2.6 Warehousing

Files and Executable ComponentsDesign Model Implementation Model

<<trace>>

<<file>>

Warehouse-warehouse transfer WarehouseTrans

.java

transfer transfer

<<trace>>

<<file>>

Warehouse-store transfer StoreTrans.java

transfer transfer

<<trace>>

<<file>>

Organize Warehouse WarehouseOrg

.java

organizes organizes

<<trace>>

<<file>>

Schedule Delivery ScheduleDelivery .java

schedules schedules

<<trace>>

<<file>>

Get Product Information ProductQuery.java

gets gets



Check Inventory

Selects

<<file>>

Inventory.java

GetInventoryIn

Selects

GetInvetoryOut

Selects

Gets

<<file>>

Stock.java

getCurrentStock

Gets

getCurrentStock

Gets



Alert

Creates

<<file>>

Alert.java

CreateAlert

Creates

Sends

<<file>>

AlertHandler.java

SendAlert

Sends

Gets

<<file>>

InventoryLot.java

GetInventoryLot

Gets




Getschedule

Notice <<file>>

Confirm.java

Notice

Notice NoticeInventory

NoticeSupplier

Get

<<file>>

Schedule.java

Get

5.2.8 Receiving

Receiving <<file>>

Check.java

Check Check

Warning

Warn Warn

<<file>>

Warning.java


5.3 Architectural View

<<trace>> <<trace>> <<trace>> <<trace>> <<trace>> <<trace>> <<trace>> <<trace>> <<trace>>

java.office.com.planning << package>>

java.office.com.purchasing << package>>

java.office.com.inventory << package>>

java.office.com.warehousing << package>>

Design

Implementation

<<trace>> <<trace>> <<trace>> <<trace>> <<trace>>

Planning Management <<analysis package>>

Forecasting <<service subsystem>>

Planning <<service subsystem >>

Purchasing Management<<analysis package>>

Puchasing <<service subsystem >>

Supplier <<service subsystem >>

Transacting <<service subsystem >>

Inventory Management <<analysis package>>

Inventory <<service subsystem >>

Alert <<service subsystem >>

<<trace>>

Warehousing Management <<analysis package>>

organization <<service subsystem >>

Warehouse <<service subsystem

Store <<service subsystem

Planning Management <<analysis package>>

Forecasting <<service package>>

Planning <<service package>>

Purchasing Management<<analysis package>>

Puchasing <<service package>>

Supplier <<service package>>

Transacting <<service package>>

Inventory Management <<analysis package>>

Inventory <<service package>>

Alert <<service package>>

AnalysisWarehousing Management

<<analysis package>>

organization <<service package>>

Warehouse <<service package>>

Store <<service package>>

<<trace>>


5.4 Prototype

Snapshot of OfficeDepot Web aplication: System Inventory Management


of 206


A test procedure specifies how to perform one or several test cases or parts of them. It will

contain textual descriptions of how to conduct the test and what requirements are being validated. The

test procedure should also contain the specification of commands used to perform the test and

information returned from the system as a result of the test. In addition, the test description should details

methods of analysis to be applied to the test data. A test component automates one or several test

procedures or parts of them. Test components can be developed using a scripting language or a

programming language, or they can be recorded with a test automation tool. All work products that are

created for and during unit testing should be captured in a Software Development Folder (SDF). System

level (black box) or stress tests are appropriate for whole system or intersegment software verifications

and also require test artifacts to demonstrate software qualification.

The ultimate purpose of all forms of testing is to uncover defects as early in the development

program as possible. Risk mitigation is accomplished by fixing problems found during iterative testing.

This helps to reduce the cost of software development and provides for timely software delivery to

customers. Although not all software problems can be found before release to a customer, a well-

planned and executed software test plan minimizes the problems encountered by the end user.

6. Test

Testing is a critical component of the software process. It begins when requirements are being

defined for a system and continues through when a product is delivered to its intended customer. All

phases of the software process should be geared with testing in mind. Requirements should be written to

be testable, analysis should lend itself to validation, and code should be developed with verification as a

goal. Test planning should commence as soon as requirements are being captured in Use Cases. Testing

should be integrated into the iterative process of the production of quality software. Initial test planning

can be derived from the system Use Cases, with more detailed test planning continuing as analysis,

design and integration models are created.

The test planner and the individual testers are responsible for analyzing the system under

development and deriving test cases relevant to each project phase. Tests can be planned using a top-

down (function based) or a bottoms-up (component based) approach. White box testing techniques are

geared towards scrutinizing the logic and data flow mechanisms of fundamental software components.

Black box testing aims to test the requirements against a collective software implementation without

regard for the internal workings of the system. Distributed systems and Client/Server implementations

demand rigorous system tests to uncover perfomance issues and possible influences of differing

hardware platforms. Real-time systems present the even greater challenge of testing the time critical and

asynchronous tasking behavior of software applications. Object-oriented systems require an expansion

of the classical notions of software testing to include reviews of the analysis and design classes. They

also demand less emphasis on functional testing and more of an emphasis on class testing. The artifacts

created as a result of the Unified Process assist in the testing of classes and systems of classes.


6.1 Test cases 6.1.1 Test case for Forecasting: Test Case : Forecasting

Purpose : Determined the forecast demand of a product based on the submitted

market data, schedule, current PO data, and current inventory.

Actors : Forecaster

Precondition : A forecast must exist

Post condition : A plan is returned

Description : The forecaster evaluates the demand based on certain criteria such as

market data, schedule, current inventory, and current purchase orders.

Priority : Critical

Freq of use : Multiple (Forecaster performs forecast on each product)

Normal course of events:

Forecaster Action Expected results

For each product, the forecaster enters the market data,

schedule, current inventory, and current PO’s.

The demand of each product is returned based on the

values entered into the system


6.1.2 Test case for Planning Test Case : Planning

Purpose : Analyze the need and create material and capacity plan.

Actors : Planner

Preconditions : A forecast and selected supplier list must exist.

Post condition : A modified plan is returned.

Description : The Planner analyses, calculates, compares, and evaluates the

inventory need of Office Depot based on information developed in the

Forecast. The Planner issues a plan that, when followed, makes sure

that by issuing and returning components from and to warehouse

(including internal orders and replenishments) inventory is kept at an

optimal level.

The Planner also analyzes Supplier Performance as a Key Performance

Indicator and modifies the Plan based on this information and inventory

values.

Priority : High

Freq of use : Multiple (Plan contains information for each item stocked)


Expected results Planner Action

For each product, the planner inputs the forecast,

purchasing data, and supplier data

A plan is created based upon the forecast data,

purchasing data, and supplier data received.

The planner reviews the plan utilizing Key Performance

Indicators of Suppliers.

New plans can be generated based on the KPI

analysis

Unit Testing

Case 1: Planner logs into system and requests Forecast GUI. Planner enters data to obtain forecast for

selected product. [InputForecastParameters(),RequestForecast(),SendForecast()]

Expected Result: The current forecast is returned to the tester.

Case 2: Planner requests Planner GUI to calculate bucket quantities based on

Forecast.[InputPurchasingParameters(), RequestPurchasing(),SendPurchasing(),

calculatePlannedQty(bucketValue, week, …)]

Expected Result: Planner receives calculated bucket quantities from the system.


Case 3: Planner adjusts bucket values based on informat returned by forecast. [SendAnalyzedData,

adjustPlannedQty(bucketValue, week, …)]

Expected Result: Planner receives adjusted bucket quantities from the system.

demand number,

leadTime date,

Expected Result: Plan is generated for stock item.

Expected Result: System returns Supplier Data to Planner.

Case 6: Planner modifies supplier data in database [ Modify( supplier, demand, …)].

Expected Result: Supplier database is modified to include updated information.

Case 7: Planner evaluates plan based on Supplier performance [SendTargetvsActualsKPIs(),

evaluatePlan(plan_id, item…..)]

Expected Result: Key Performance Indicators reflect Supplier performance against plan.

Case 4: Planner requests creation of plan.

createPlan ( bucketValue number,

week date,

currentVal number,

onHand number,

plannedRel number,

safetyStock number,

lotSize number,

releaseDate date)]

Case 5: Planner requests Supplier data from system [InputSupplierParameters, RequestSupplierData].

of 206


6.1.3 Test case for Purchasing

Precondition : A plan should exist as well as a list of suppliers for an item.

Freq of use : Multiple

Test Case : Purchasing

Purpose : To generate an invoice for a given item to be purchased.

Actors : Buyer, Finance Manager, Supplier

Post condition : An invoice is generated.

Description : The buyer requests to make a purchase through a Purchase Request.

The finance manager approves the purchase request. The buyer then

negotiates a PO/BO with the supplier based on an existing supplier list

that reflects supplier performance. A PO/BO is issued from the buyer

and the supplier issues an invoice. Buyer can then query the invoice

generated.

Priority : High


Buyer Action Expected results

Buyer makes a request for a purchase and makes an

inqury to see if purchase request was approved.

Finanace manager approved purchase request is

returned by the system.

Buyer negotiates PO/BO with supplier and issues a

PO/BO.

The invoice generated by the supplier is returned by

the system.

Expected Result: Purchase Request is created by the system.

Case 2: Buyer sends Purchase Request to the Finance Manager for approval.[SendPR()]

Expected Result: Purchase Request is marked as approved.

Case 4: Buyer requests approved PRs. [InputApprovalParameters(), RequestApprovedPRs(),

SearchApprovedPRs()]

Expected Result: Approved PR is returned to Buyer.

Unit Testing

Case 1: Buyer logs into system and requests Purchasing GUI. Buyer enters information required to create

a Purchase Request. [ InputPRParameters(), RequestPR(), SearchPR()]

Expected Result: Purchase Request is forwarded to Finance Manager.

Case 3: Finance Manager gives approval for Purchase Request [ApprovePR()]


Case 5: Buyer negotiates Purchase Order or Blanker Order with Supplier. [BuyerNegotiate(),

SupplierNegotiate()]

Expected Result: Negotiation results are sent back to Buyer from the Supplier.

Case 6: Buyer creates a Purchase Order or Blanker Order.

create_PO ( PO_id number,

PO_name string,

PO_line number,

item string,

quantity number,

buyer_id number,

warehouse_id number,

creation_date date)]

Expected Result: Purchase Order or Blanket Order is created.

Case 7: Supplier creates an invoice based on the PO or BO [CreateInvoice(),

SendInvoice(),ReturnInvoice()].

Expected Result: Invoice is sent to Buyer.

Case 8: Buyer verifies invoice [RequestInvoice(), VerifyInvoice()].

Expected Result: Buyer can acces and verify invoice.

cost number,

delivery_date date,

supplier_id number,


6.1.4 Test case for Supplier Performance:

Test Case : Supplier Performance

Purpose : Prepare a supplier list based on their performance and select the

best supplier for the given item.

Actors : Supplier analyst

Precondition : A list of supplier for an item should exist.

Post condition : A supplier is selected.

Description : The supplier analyst evaluates the supplier based on certain criteria such

as product quality, delivery time, cost, and supplier commitment.

Priority : High

Freq of use : Multiple (Supplier is selected for each item stocked)


Analyst Action Expected results

A single supplier is selected based on the data

entered by the analyst.

For each product, the supplier analyst inputs performance

information (price, quality, delivery time, and commitment)

for every supplier that provides the product.

Unit Testing:

Case 1: send_price_eval, price_eval_filter

Expected Result: Return a score for the price value entered

Case 2: send_commitment_eval, commitment_eval_filter

Expected Result: Return a score for the commitment value entered

Case 3: send_quality_eval, quality_eval_filter

Expected Result: Return a score for the quality entered

Case 4: send_delivery_time, delivery_time_filter

Expected Result: Return a score for the delivery time entered

Case 5: send_request, supplier_request, get_supplier_data, supplier_data_filter

Expected Result: Return a data for the supplier requested

Case 6: send_request, plan_request, get_plan_data, plan_data_filter

Expected Result: Return a data for the plan requested

of 206


Case 7: send_request, supplier_request, get_supplier_data, supplier_data_filter, send_request,

plan_request, get_plan_data, plan_data_filter, send_delivery_time, delivery_time_filter,

send_quality_eval, quality_eval_filter, send_commitment_eval, commitment_eval_filter, send_price_eval,

price_eval_filter, send_supplier_data, supplier_select

Expected Result: Return a selected supplier for the evaluation data entered.


6.1.5 Test case for Tracking:

Test Case : Tracking

Purpose : Track shipments of a product based off of the PO number and the

supplier ID.

Actors : Forecaster

Precondition : A PO and supplier ID must exist

Post condition : A tracking report is issued.

Description : On demand, a forecaster can get a tracking report on a PO that has

been issued by a supplier.

Priority : High

Freq of use : Multiple (Forecaster can track any PO issued)


Forecaster Action Expected results

For any PO, the forecaster can track the product shipment

by entering the PO and supplier ID into the system. A tracking report is returned by the system.


6.1.6 Test case for Warehouse-warehouse transfer:

Test Case : Warehouse-warehouse transfer

Purpose : Transfer items between warehouses located in different regions.

Actors : Warehouse manager, Back office system, Warehouse Clerk

Precondition : Requesting warehouse does not have enough of requested item.

Transferring warehouse has necessary quantity of the product

requested.

Post condition : Warehouse in different regions supplies requesting warehouse with

ample quantity of the item

Description : Warehouse requests transfer of product from another warehouse.

Inventory management selects a warehouse that possesses ample

quantity of the product, issues transfer of the product between

warehouses, and notifies the transferring warehouse.

Priority : High

Freq of use : Multiple (Transfers may occur between any number of warehouses)


Manager Action Expected results

Manager searches system for product. The product quantity at every warehouse is returned.

Manager requests transfer of product from another

warehouse.

System chooses warehouse to transfer from, updates

the forecast demand of the product, and notifies the

transferring warehouse.

Unit Testing

Case 1: product_query, product_quantity, update_quantity

Expected Result: The current inventory of a product is returned.

Case 2: transfer

Expected Result: Amount of the product is subtracted from a location and added to the inventory of the

receiving location.

Case 3: get_schedule, select_schedule, update_schedule

Expected Result: The delivery date selected is put into the schedule.

Case 4: confirmation, generate_confirmation, get_confirmation, query_confirmation


Expected Result: The confirmation of a transfer issued should be the same as the one returned.

Case 5: send_request, confirm_request, dispatch_request

Expected Result: There is not enough of a product in stock so a request made is sent to the inventory

management system.

Case 6: update_demand

Expected Result: Demand of the product is updated by the amount passed as an argument

6.1.7 Test case for Warehouse-store transfer:

Test Case : Warehouse-store transfer

Purpose : Transfer items between warehouse and stores located in

the same region.

Actors : Warehouse clerk, Store clerk Precondition : Requesting store does not have enough of requested item.

Warehouse has necessary quantity of the product requested.

Post condition : Store has ample amount of the item. Warehouse quantity is updated

regionally to show the transfer has occurred.

Description : Store requests a product from the warehouse. Warehouse transfers

quantity of the product requested to the store.

Priority : High

Freq of use : Multiple (Transfers occur between the warehouse and all stores in a

region)


Warehouse Clerk Action Expected results

Clerk issues a transfer request of a product after seeing

notices and alerts from store requesting a product.

Warehouse inventory is updated to reflect the transfer,

a delivery time is scheduled, and confirmation of the

transfer is sent to the store.

Unit Testing

Case 1: product_query, product_quantity, update_quantity

Expected Result: The current inventory of a product is returned.

Case 2: transfer

Expected Result: Amount of the product is subtracted from a location and added to the inventory of the

receiving location.

Case 3: get_schedule, select_schedule, update_schedule of 206


Expected Result: The delivery date selected is put into the schedule.

Case 4: confirmation, generate_confirmation, get_confirmation, query_confirmation

Expected Result: The confirmation of a transfer issued should be the same as the one returned.

Case 5: send_request, confirm_request, dispatch_request

Expected Result: There is not enough of a product in stock so a request made is sent to the inventory

management system.


6.1.8 Test case for System Inventory Management:

Test case: Test System Inventory alert agent

Purpose: Ensure alert agent work properly when a regional warehouse sends an

inventory request.

Actor: warehouse clerk

Precondition: The inventory request is over the warehouse threshold inventory.

Postcondition: Alert created contains sufficient information of request warehouse.

Description: A regional warehouse sends a inventory request to the system inventory

Management. The system will prioritize the alert and creates a alert to put in

a system queue. System agent will be notified when the alert is process

from the system queue.

Priority: High

Frequent of Use: Multiple from regional warehouses



Clerk issues a transfer request of a product when see a

warehouse alert agent notifies that a product inventory go

below threshold level..

System Inventory Management receives the request

and sends back an acknowledgement that the request

in the process queue.

Test case: Test System Inventory handler

Purpose: Ensure inventory distribution properly within regional or coporate level.

Actor: System agent

Precondition: The inventory request is within system inventory.

Postcondition: Inventory distribution satisfies planning schedule.

Description: System makes decision to distribute product from a warehouse to another.

Priority: High

Frequent of Use: Multiple from regional warehouses


System Agent Action Expected results

System Agent reports a path and schedule for an

inventory distribution from supllied warehouse to a

requested warehouse. System agent also send a

confirmation messages to the particiapted warehouses of

the process.

Both participated warehouse receive report of the

transfer process,


6.1.9 Test case for Receiving:

Test case: Receiving

Purpose: Ensure the receiving function operates properly.

Actor: Warehouse clerk

Precondition: There is a delivery expected.

Postcondition: Received product quantities are expected.

Description: Based off of a scheduled delivery, the receiving warehouse will update the

quantities of a product.

Priority: High

Frequent of Use: Multiple (for each delivery)



Clerk schedules a shipment from the supplier and once

shipment is received, update the quantity in stock.

Quantity in stock should reflect shipment of product.


6.2 Test management

Warehouse Test System Test Warehouse Test

Warehouse Test

Warehouse Test

Store Test Store Test

Store Test

Store Test

Inteface test

Inteface test

Inteface test

Inteface test

Inte

face

test

Inteface test

Inte

face

test

Inte

face

test

Syst

em In

tegr

atio

n Te

st O

rder

Flo

wch

art


Warehouse Test

Warehouse Test


Store Test

Store Test

Inteface test

Inteface test

Inteface test

Inteface test

Inte

face

test

Inteface test

Inte

face

test

Inte

face

test


Warehouse Test

Warehouse Test


Store Test

Store Test

Inteface test

Inteface test

Inteface test

Inteface test

Inte

face

test

Inteface test

Inte

face

test

Inte

face

test


Warehouse Test

Warehouse Test


Store Test

Store Test


Warehouse Test

Warehouse Test

Warehouse TestWarehouse Test System TestSystem Test Warehouse TestWarehouse Test

Warehouse TestWarehouse Test

Warehouse TestWarehouse Test

Store TestStore Test Store TestStore Test

Store TestStore Test

Store TestStore Test

Inteface test

Inteface test

Inteface test

Inteface test

Inte

face

test

Inteface test

Inte

face

test

Inte

face

test

Syst

em In

tegr

atio

n Te

st O

rder

Flo

wch

art


A fundamental rule of software engineering is that developers should perform unit test as early as

possible. Most mistakes are made early in the life of a project and the cost of fixing defects increases

exponentially the later they are found.

The other motivating factor for testing early is that fixing these defects gets costlier the later they are

found. This happens because of the nature of software development -- work is performed based on work

performed previously. For example, modeling is performed based on the information gathered during the

definition of requirements. Programming is done based on the models that were developed, and testing is

performed on the written source code. If a requirement was misunderstood, all modeling decisions based

on that requirement are potentially invalid, all code written based on the models is then in question, and

the testing efforts are based on verifying the application against the wrong conditions. As a result, errors

detected near the end of the development life cycle or after the application has been released are likely to

be very expensive to fix. On the other hand, errors that are detected early in the life cycle, where they are

likely to have been made, will be much less expensive to fix because only a few documents have to be

updated.

In this project, we employ Java technologies with favor of object oriented design and analysis. Therefore,

the issue in which how to perform object testing is a greate concern of the product’s validation and

verification.

Object-oriented testing approach:

Object-oriented software testing is generally performed bottom-up at four levels:

(a) Method-level testing refers to the testing of an individual method in a class.

(b) Methods and attributes make up a class. Class-level (or intra-class) testing refers to the testing of

interactions among the components of an individual class.

(c) Cooperating classes of objects make up a cluster. Cluster-level (or inter-class) testing refers to the

testing of interactions among objects.

(d) Clusters make up a system. System-level testing is concerned with the external inputs and outputs

visible to the users of a system.

Test models are abstract representations of actual tests. They can be extracted from the design

specifications (in the style of black-box testing) or the source code (in the style of white-box testing). Our

test model is extracted from the formal specifications.

In this project, we develop the Full-Life cycle Object-Oriented Testing (FLOOT) methodology that is a

collection of testing techniques to verify and validate object-oriented software. The FLOOT life cycle is

depicted in figure below, which illustrates that there is a wide variety of techniques available to you

throughout all aspects of software development. More testing, not less, is often the reality for object-

oriented systems because of the greater complexity of the problem domains at which object technology is

targeted.


In order to achieve the maxium reliability of the object oriented testing, we enforce testing process during

the development life cycle.

Developers should perform systematically and traditionally in their OOA (Object Oriented analysis) in

which each revision of their anaysis must be document and perform under coporate technical standards

as the following flow chart.


Therefore, in the validation and verification, the testers easily follow and relate the object functionalities

and performance along test cases (when they perform activity diagrams).

Similary, in the design phase, developers also coordinate their class design with documentation.


When the tester perform testcases, they easily to track down the code error in implementation or design

fault in the design schema.


Appendices A. Glossary

1) Activity diagram. A UML diagram that is used to model high-level business processes or the

transitions between states of a class (in this respect, activity diagrams are effectively

specializations of statechart diagrams).

2) Business rule. An operating principle or policy of your organization.

3) Change case. A potential requirement that your system may need to support in the future.

4) Change-case model. The collection of change cases applicable to your system. See Designing

Hard Software (in Resources) for details.

5) Class diagram. A UML diagram that shows the classes of a system and the associations between

them.

6) Class model. A class diagram and its associated documentation.

7) Class Responsibility Collaborator (CRC) card. A standard index card that has been divided into

three sections: one indicating the name of the class that the card represents, one listing the

responsibilities of the class, and one listing the names of the other classes that this one

collaborates with to fulfill its responsibilities.

8) Class Responsibility Collaborator (CRC) model. A collection of CRC cards that model all or part

of a system.

9) Collaboration diagram. A UML diagram that shows instances of classes, their interrelationships,

and the message flow between them. Collaboration diagrams typically focus on the structural

organization of objects that send and receive messages.

10) Component diagram. A UML diagram that depicts the software components that compose an

application, system, or enterprise. The components, their interrelationships, interactions, and their

public interfaces are depicted.

11) Constraint. A restriction on the degree of freedom you have in providing a solution.


12) Deployment diagram. A UML diagram showing the hardware, software, and middleware

configuration for a system.

13) Essential model. A model that is intended to capture the essence of a problem through

technology-free, idealized, and abstract descriptions. See Software Use (in Resources) for more

information about essential modeling.

14) Essential use case. A simplified, abstract, generalized use case that captures the intentions of a

user in a technology- and implementation-independent manner.

15) Essential use-case model. A use-case model comprised of essential use cases.

16) Essential user-interface prototype. A low fidelity prototype of a system's user interface that

models the fundamental, abstract characteristics of a user interface.

17) Model. An abstraction describing a problem domain or a solution to a problem domain.

Traditionally models are thought of as diagrams plus their corresponding documentation although

non-diagrams, such as interview results and collections of CRC cards, are also considered to be

models.

18) Non-functional requirements. The standards, regulations, and contracts to which your system

must conform; descriptions of interfaces to external systems that your system must interact with;

performance requirements; design and implementation constraints; and the quality characteristics

to which your system must conform.

19) Persistence model. A model that describes the persistent data aspects of a software system.

20) Prototype. A simulation of an item, such as a user interface or a system architecture, the purpose

of which is to communicate your approach to others before significant resources are invested in

the approach.

21) Requirements model. The collection of artifacts, including your use-case model, user-interface

model, domain model, change-case model, and supplementary specification that describes the

requirements for your system.

22) Sequence diagram. A UML diagram that models the sequential logic -- in effect the time ordering

of messages.


23) State chart diagram. A UML diagram that describes the states that an object may be in, as well as

the transitions between states. Formerly referred to as a state diagram or state-transition

diagram.

24) System use case. A detailed use case that describes how your system will fulfill the requirements

of a corresponding essential use case, often referring to implementation-specific features such as

aspects of your user interface design.

25) System use-case model. A use-case model comprised of system use cases.

26) Use case. A sequence of actions that provide a measurable value to an actor.

27) Use-case diagram. A UML diagram that shows use cases, actors, and their interrelationships.

28) Use-case model. A model comprised of a use-case diagram, use-case definitions, and actor

definitions. Use-case models are used to document the behavioral requirements of a system.

29) User interface-flow diagram. A diagram that models the interface objects of your system and the

relationships between them. Also known as an interface-flow diagram, a windows navigation

diagram, or an interface navigation diagram.

30) User-interface model. A model comprising your user interface prototype, user-interface flow

diagram, and any corresponding documentation regarding your user interface.

31) User-interface prototype. A prototype of the user interface (UI) of a system. User-interface

prototypes could be as simple as a hand-drawn picture or as complex as a collection of

programmed screens, pages, or reports.


B. References

1. I.Jacobson, G.booch, and J.Rumbaugh, The Unified Softwae Developement Process. Addison-

Wesley,1999

2.

13.

14.

H.Eriksson, M.Penker, Business Modeling with UML, Wiley,2000.

3. M.Fowler,UML Distilled, 2nd edition, Addison-Wesley,2000.

4. D. Rosenberg,Use Case Driven Object Modeling with UML, Addison-Wesley,1999.

5. D. Rosenberg, Applying Use Case Driven Object Modeling , Addison-Wesley,2001.

6. C. Larman, Applying UML and Patterns. Prentice Hall, 1988.

7. S. Schach, Classical and Object-oriented Software Engineering with UML and Java,fourth

edition, McGraw-Hill,1999.

8. T. Connolly, C.Begg, and A.Strachan, Database Systems, Addition-Wesley,1996.

9. E. Gamma, Design Patterns, Addition-Wesley, 1995.

10. N. Kassem, Design Enterprise Application with J2EE Addition-Wesley, 2000.

11. I. Sommerville, Software Engineering, sixth edition,Addition-Wesley, 2001.

12. W. Royce, Software project Management – A unified Framework, Addition-Wesley, 1998.

Designing and Managing the Supply Chain Concepts, Strategies, and Case Studies.By David

Simchi-Levi McGraw-Hill,2000.

Java 2 Platform, Enterprise Edition (J2EE) - developer resources, downloads, documentation,

tutorials, and more. http://java.sun.com/j2ee/

J2ME – Java 2 Platform, Micro Edition - official site. http://java.sun.com/j2me/ 15.

16. Office Depot - supplies office and technology products and services

worldwide.http://www.officedepot.com/

17. HP Supply Chain- http://www.hp.com/solutions1/supplychain/


http://java.sun.com/j2ee/

http://java.sun.com/j2me/

http://www.officedepot.com/

http://www.hp.com/solutions1/supplychain/

C. Prototype

Central Inventory

Management System

Planning Forecasting POR

Warehouse Warehouse Warehouse Warehouse

Store Store Store Store


Version History


Version Author Date Description 1.0 Cuong Pham 09/10/2001 Document released

1.1 Cuong Pham 09/17/2001 Add artifacts of requirement work flow

1.2 Cuong Pham 10/01/2001 Add artifacts of analysis work flow

1.3 Cuong Pham 10/16/2001 Add artifacts of design work flow

1.4 Donny Chan 10/23/2001

Add warehousing design portion, updated

warehousing analysis and re-inserted missing

use case portions.

1.5 Cuong Pham 10/24/2001 Add forecasting design portion.

1.6 Cuong Pham 10/25/01 Add tracking design portion.

1.7 Cuong Pham 10/26/01 Add analysis diagrams for Planning.

1.8 Donny Chan 10/28/01 Add artifacts of analysis work flow for System


1.9 Cuong Pham 10/28/01 Add analysis diagrams for Supplier Performance

1.10 Cuong Pham 10/29/01 Add ERD in the Database design section. Add

Donny’s ERD for Warehousing.

1.11 Donny Chan 11/5/2001

Correct use case diagrams for warehousing and

supplier performance, add design portion of

supplier performance, updated ERD for

warehousing

1.12 Cuong Pham 11/5/2001 Add analysis diagrams for Purchasing.

1.13 Cuong Pham 11/6/2001

Modify conceptual model, resources structure,

organization diagrams, sequence diagram and

use case charts.

1.14 Cuong Pham 11/10/2001

Modify design classes for forecasting, system

inventory management. Add common classes,

statechart diagram, deplpoyment diagram,

layers and dependencies diagrams.

1.15 Cuong Pham 11/12/2001 Add Implementation part for Forecasting,

Inventory Management, Architecture View.

1.16 Donny Chan 11/12/2001

Add Implementation part for Supplier

Performance and Warehousing, added more to

warehousing portion of Architecture View.

1.17 Donny Chan 11/17/2001 Add Implementation part for tracking and

receiving.

1.18 Cuong Pham 11/19/2001 Add all design diagrams for Planning and

Purchasing.

1.19 Cuong Pham 11/22/2001

Add decision tables for system inventory

management and pseudo codes of the relevant

functions.

1.20 Cuong Pham 11/24/2001 Add snapshot of the prototype: web

appplication.

1.21 Cuong Pham 11/26/2001 Add implementation part for Planning and

Purchasing

1.22 Donny Chan 11/26/2001 Add reference

1.23 Donny Chan 11/30/2001 Adjust content

1.26 Cuong Pham 12/03/2001

Add test management, Object Oriented test

Approach. Glossary

1.30 Donny Chan

Finalize document.

1.24 Cuong Pham 12/2/2001 Add prototype, Change receiving alphabetic

order

1.25 Donny Chan 12/2/2001 Add testing, revised analysis and design

portions of warehousing. 1st refactoring.

Add test cases for system inventory

management. 2nd refactoring

1.27 Donny Chan 12/4/2001 Add remaining test cases.

1.28 Cuong Pham 12/08/2001

Add introduction for test section. Add test cases

for planning and purchasing. Fix Purchasing

collaboration diagram.

1.29 Cuong Pham 12/10/2001

12/10/2001 Add prototype

1.31 Donny Chan 12/12/2001 Fix warehousing sections, add general use case

diagram

1.32 Cuong Pham 12/14/2001


Acknowledgement. This project is sucessfully completed under enthusiatic guides from professor Chang Lee of Computer

Engineering Department, San Jose State University. We are appreciate his instructions and guidance

throughout this project which have been helpful for us to master software engineering concepts as well as

practical skills in design and development.

Donny Chan – Hewlett-Packard

OfficeDepot SCM Team Cuong Pham – Hewlett-Packard


supply chain management plan

Documents