Data Flow

Explanation of Processes:

First the Warehouse sends it's data to the TIRM system which then takes the information and updates the Inventory Files. The stores will also send goods sold information to the TIRM system. The System will then update the goods sold file. Using a combination of the golds sold and the inventory file the system will compute the total amount of goods that can be sold across all stores and the warehouse and put the information in a Goods Available for Sale file. The Information in the file will then be sent to the stores so they can see what is out there for them to request and request based on that. The requests will be sent to the TIRM system and then filled and sent to the appropriate store.

Process Data Flows Attributes from Data Stores

Record Inventory None

Update Goods Sold Goods Sold File SKU, Location ID, Amount

Sold

Update Inventory Inventory File SKU, Location ID, Amount

Calculate Goods Available for

Sale Goods Available for Sale SKU, Location ID, Amount

Process Request and Send

Goods None

Process Specification:

1.0 - Record Inventory

Input: Items In Warehouse and Goods Sold.

Process: Record the changes in inventory

Output: List of Changes in inventory sent to Update Goods Sold and Update Inventory 2.0 - Update Inventory

Input: Changes in Inventory

Process: Record any changes in inventory to make them accurate.

Output: Place information into Data Store 1: Inventory File 3.0 - Update Goods Sold

Input: Changes in Inventory

Process: Record the goods that were sold

Output: Place Information into Data Store 2: Goods Sold File

Input: Data Stores 1 and 2, Inventory File and Goods Sold File

Specifications IV-7

Process: Remove any goods sold from inventory, and check to make sure that only goods on hand that can be sold by a store are in the file

Out: Data Store 3: Goods Available for Sale 5.0 - Proccess Request and Send goods

Input: Requests from stores

Process: Take the request and check it against inventory files, and then send the goods out.

Output: Send goods to the store.

4: Constraints

The constraints for TIRM can be categorized under the following sub-categories:

1. Technical restraints 2. Skills of the developers 3. Time

The explanations of each of the constraints are given in the following table.

Continued on next page

Constraint Category Sub category Reason for choosing Possible problem 1.Technical 1.1Waterfall

model with prototyping in the final stages.

This project through the earlier stages will depend on the completion of prior stages. While the final stages will require the users feedback to complete.

1.1a. Long waiting time as most of the work is

progressed serially 1.1b. Requirements once stated cannot be revisited in earlier stages.

1.1c. Will require minimal communication with the customer in earlier stages, the later stages will require active participation from the customer.

Microsoft access as the

development tool.

have a small budget and this system is being developed by mostly inexperienced graduate students the simplicity was another reason.

support only a limited size database.

1.2b. If the client working environment changes from Windows to Unix or Linux, the system will not work

2. Skills 2.1 System to be developed by

inexperienced graduate students.

2.1 The graduate students have the necessary knowledge from their past courses regarding, project management,

programming, analysis, design and so forth.

2.1a. The graduate students do not have the necessary skills to develop the system.

2.1b. Certain details may require a more experienced expert then the graduates have.

3. Time 3.1 Limited time is available to develop the system.

3.1 The system should only take thirty days in order to develop.

3.1a. The system will take more than thirty days to develop therefore not everything may be available on the thirtieth day.

3.1b. More time will be needed in order to finish the

development of the system.

5: Risks

The risks with its causes, impact, likelihood of occurrence and the solutions are provided in the following table. The impact and the likelihood of occurrence, are measured on a three scale of Low, Medium, and High.

Risks Possible reasons Impact (I)and

Likelihood (L) of occurrence

Possible solutions to mitigate the effects.

1. Data, document, or programs gets

corrupted or lost.

1.1. Hard disk crash on any developer’s

machine

I = High L= Low

1.1a. All member’s must have backups for their work as well as other member’s work.

1.1b. Back ups of all documents, and programs will be maintained in floppies, CDs or online.

1.1c. All documents and versions is to be maintained in a chronological order until the final version is delivered to the customer.

1.1d. All the documents and programs are to be uploaded into google’s google docs

behind schedule. ill or becoming absent.

L= Medium

distributed. Too much reliance and

dependence must not be exercised on one member.

2.1b. Programming responsibilities are shared between two persons, with no functional boundaries.

2.1c. Responsibilities of Documentation and System Designing, Interface Designing are also shared, like wise.

2. 2 Project Manager falling ill or becoming absent.

I = High L= Medium

2.2a. The responsibility of Signing off will fall upon all the

developers. Every member will sign on a document or a

deliverable to approve it, in absence of the project manager.

2.3. Lack of discipline among members.

I = High L= Low

2.3a. Members progress will be monitored by how timely they are on submitting there share of the work.

2.3b. If still not timely work will be

distributed among other members evenly.

L= High to low given at first during development but nearing the end of the development deadlines will be more strictly watched.

3. Poor Quality 3.1. Poor Quality Documentation

I = High L= Medium

3.1a. All

documentation will be double checked by all members to ensure quality.

3.1b. Mistakes will be corrected by the member who noticed the mistake.

3.2 Poor Quality Design

I= High L= Medium

3.2a. Design must be double checked by all the members and approved by the manager before coding starts.

3.3 Poor Quality Interface.

I= High L= Medium

3.3a. The interface will be tested by workers from Shirt Shack.

3.3b. There input will ensure that the

interface is the quality Shirt Shack is

expecting.

3.4 Poor Functionality I= High L= Medium

3.4a. Will continue to check with Shirt Shack that it functions as well as they expect.

Design V-1.

Running head: TRANSACTION & INVENTORY RETAIL