50
1 | Page HAWASSA UNIVERSITY INSTITUTE OF TECHNOLOGY (IOT) SCHOOL OF INFORMATICS INDUSTRIAL PROJECT I Requirement Analysis and Design On Material management system For Hawassa University By ABDELLAH BEHRI IS/004/02 ABDU AMDE IS/009/02 Submitted to: Axsumawit T. Date 2/11/2013

Project proposal 32

Embed Size (px)

DESCRIPTION

 N ~ represents number n=log2n.

Citation preview

Page 1: Project  proposal 32

1 | P a g e

HAWASSA UNIVERSITY

INSTITUTE OF TECHNOLOGY (IOT) SCHOOL OF INFORMATICS

INDUSTRIAL PROJECT I

Requirement Analysis and Design

On

Material management system

For Hawassa University

By

ABDELLAH BEHRI IS/004/02

ABDU AMDE IS/009/02

Submitted to: Axsumawit T.

Date 2/11/2013

Page 2: Project  proposal 32

2 | P a g e

Table of Contents

Acknowledgements .................................................................................................... 4

List of Tables ............................................................................................................. 5

List of figures ............................................................................................................. 5

Acronyms ................................................................................................................... 7

Chapter one ................................................................................................................ 8

1.1 Introduction ...................................................................................................... 8

1.2 Background of the organization ....................................................................... 9

1.3. Descriptions of the existing system .................................................................... 9

1.4. Statement of problem ........................................................................................10

1.5. Scope and limitation of the system ...................................................................11

1.6. Objective ...........................................................................................................11

1.6.1. General objective ...........................................................................................11

1.6.2. Specific objective ...........................................................................................12

1.7. Methodology .....................................................................................................12

1.7.1. Data collection methodology .........................................................................12

1.7.2. System design and analysis tools ...................................................................12

1.7.3. System development tools .............................................................................13

1.8. Cost of the project .............................................................................................13

1.9. Schedule of the project ......................................................................................14

Chapter two ..............................................................................................................15

2.1. Requirement Analysis .......................................................................................15

2.1.1. Functional requirements .................................................................................15

2.1.2. Nonfunctional requirements ........................................................................15

Page 3: Project  proposal 32

3 | P a g e

Chapter three System Design ...................................................................................17

3.1. Use case model ..................................................................................................17

3.2. Use case description ..........................................................................................18

3.3. Sequence Diagram ..........................................................................................22

3.4. Class Diagram .................................................................................................30

3.5. User Interface Architecture ............................................................................31

3.5.1. Architecture of system.................................................................................32

3.6. Activity diagrams ...........................................................................................33

3.7. Database Design .............................................................................................38

3.7.1. Normalization ..............................................................................................38

3.8. User interface design ......................................................................................40

Reference..................................................................................................................50

Page 4: Project  proposal 32

4 | P a g e

Acknowledgements I would like to express my gratitude to our advisor Axsumawit T. for her guidance,

support and her continuous enthusiasm and encouragement throughout the project.

We are also very grateful and extend my sincere thanks to the principals and staff

members of the department of Hawassa university (main compass) store for their

cooperation by sharing the load that we was performing their activity to make our

have time to work on this project and throughout our study.

Finally many thanks to friends, who have helped and given us suggestions,

supports and corrections throughout the project.

Page 5: Project  proposal 32

5 | P a g e

List of Tables Table 1.1 Cost Estimation ........................................................................................................................... 14

List of figures

Figure 1.1 Schedule of the project ...........................................................................14

Figure 2 3.1 Use Case ..............................................................................................17

Figure 3.2 Sequence Diagram of login for Manager ...............................................23

Figure 4.3.3 Sequence diagram of Check item form ...............................................24

Figure 5.3.4 sequence diagram of report .................................................................25

Figure 8. 3.6 sequence diagram of Record new item ..............................................27

Figure 9.3.7 sequence diagram of update the item ..................................................28

Figure 10.3.8 sequence diagram of return the item .................................................29

Figure 11. 3.9 class diagram of HU store ................................................................30

Figure 12.3.10 user interface architecture of HU store ...........................................32

Figure 13.3.11 architecture of the system ................................................................32

Figure 14.3.11 activity diagram for Record .............................................................33

Figure 15.3.12 activity diagram for Return .............................................................34

Figure 16.3.14 class diagram for Dispatch ..............................................................36

Figure 17.3.15 class diagram for checkout ..............................................................37

Page 6: Project  proposal 32

6 | P a g e

Figure 18.3.16database design .................................................................................38

Figure 19.3.16 Normalization ..................................................................................39

Figure 20. 3.17 login form .......................................................................................40

Figure 21.3.16 Splash form ......................................................................................40

Figure 22.3.18 Manager Window form ...................................................................41

Figure 23.3.18 Stock clerk window form ................................................................42

Figure 24. 3.19 item record form .............................................................................44

Figure 25.3.20 item dispatch form ...........................................................................45

Figure 26.3.21 checkout form 27. ............................................................................46

Figure 28. 3.22 return form ......................................................................................47

Figure 29. 3.23 create account form ........................................................................47

Figure 30.3.24.delete form .......................................................................................48

Figure 31.3.25 user form ..........................................................................................49

Figure 32.3.26 Report form .....................................................................................49

Page 7: Project  proposal 32

7 | P a g e

Acronyms

HU Hawassa University

ACA Awassa College of Agriculture

WGCF Wondo Genet College of Forestry

Mgr Manager

Page 8: Project  proposal 32

8 | P a g e

Chapter one

1.1 Introduction

Computerized systems are very important in every organizational level so as to

automate activities easily in the manner that check the information currently going

on the organizations to be checked its accuracy and consistency.

Today’s competitive environment is forcing companies to optimize the

procurement processes and inventory levels while at the same time ensure accuracy

of controls and implementation of standard procedures for the flow of materials.

However, in the absence of appropriate systems and information infrastructure,

companies are finding it difficult to achieve smooth and efficient materials

planning and execution.

In Departmental Store’s Management System we keep track of objects or materials

of the store. Properly managing inventory is essential to the success of every store

keeper. Store Management system provides information to efficiently manage the

flow of materials, effectively utilize people and equipment, coordinate internal

activities and communicate with customers. In the current scenario of our country

few departmental stores are automated and some are semi automated and many are

still having manual system for keeping the record of items. In manual system the

store management system is quite time consuming and tedious. Semi automated

system is also not well organized.

There are many departments in Hawassa University (main campus) which are not

using the automated systems. The materials store of this University is one of them.

Therefore, we are eager to develop store management system for this unit of the

University.

Page 9: Project  proposal 32

9 | P a g e

1.2 Background of the organization

Hawassa University (HU) was established at Hawassa in April 2000.Since 1976

the different colleges of HU had been operational starting with the college of

Agriculture. The University has been formed by merging three colleges in

Southern Ethiopia: Awassa College of Agriculture (ACA), Wondogenet College of

Forestry and Dilla College of Teacher Education and Health Sciences.

The university now has five different campuses. These are Main campus, Awassa

College of Agriculture (ACA), College of Medicine and Health Science, Wondo

Genet College of Forestry (WGCF) and Yirgalem Campus.

Within all this campuses Hawassa University has different department such as

Finance, Human Resource, Academic Department, Store Department, and etc.

Store Department is used as a backbone of each department. It has been established

parallel to HU making its location in ACA and was providing services for all

branches. Even though this department has now been opened in each branch due to

the destruction and missing of materials, the Main Campus Store Department is

also servicing others in some materials like Desk Tops, Lap Tops, etc. Generally

the Store Department is established only for temporary settlement of the materials

and it is not profitable organization but providing services for the University

society especially for those who are studying and for those who are teaching in it

1.3. Descriptions of the existing system

The existing system is fully manual work except the use of file system. Thus the

procedure is as follows first all the materials are inspected, receipt and stored in the

warehouse through the paper known to be MODEL 19 to allow materials entrance.

Then the materials detail is written on the BIN card, in which each transaction is

Page 10: Project  proposal 32

10 | P a g e

recorded, and attached to the item. This detail is also recorded on the STOCK card,

in which each transaction is recorded again, and transferred to stock controller.

The customers with privilege to request those materials should be encompassed

with the paper called MODEL 21 which is used as transaction permission and the

target material is permitted to be taken along with the paper called MODEL 22 to

assure the transaction process.

1.4. Statement of problem

Most activities of the existing system are manual to keep the record of the

transaction in the departmental store. We have found that employees first of all

record all information in there ledger before entering in computer system

.Meanwhile the high increment demand of materials causes the current system

unsuitable to manage the store department. This makes difficult to handle the entire

transaction. Because of the above reason the department has the following

problems.

The record cards are being destroyed and even lost since the information is kept in

card

Data redundancy in the paper document.

There may be mistakes while recording large data and this may disrupt the

transaction.

Difficult to update information (by the time of transaction process).

Difficult to retrieve information about the materials, the customers, etc

Less data security especially in case of the BIN card as it is attached to the item.

Tiresome, time consuming and tedious checking system that means to check

whether the materials are present or not.

It is time consuming to audit the transaction at the end of the year

Page 11: Project  proposal 32

11 | P a g e

Time wastage for the record during reception of new items.

Manual identification of the code of each item during transaction.

Difficult to manage and control daily activities.

So, in this project we are trying to make store management system which will help

employees to keep record of materials in systematic way and help them produce

report about the stock currently available in their store in automatic way to help

then decision making about the stock etc

1.5. Scope and limitation of the system

Our project is limited to only the HU Store Department and tends to perform

database dependant recording, searching, deletion and update of stocks, customers

and transaction process. Unfortunately it can’t process activities like integration

with other department, checking the materials quality, employee management and

materials order.

Generally we come up with this project to implement a new Store Management

System which can perform the entire specified task to the store with minimum

time, effort and resource need in addition with great efficiency and accuracy and

guarantee that the data will not lost or damaged easily.

1.6. Objective

Objective of project can be divided in to general and specific objective. We try to

mention the objective of our project from both general and specific perspective.

1.6.1. General objective

The big objective of our project is to automate the activities or to develop store

management system of departmental store found in the main campus of HU.

Page 12: Project  proposal 32

12 | P a g e

1.6.2. Specific objective

The specific objectives of my project to address the general objective we try to

mention are the following.

Assess the existing system.

Identify the main activities of the Store Department to be

implemented in the system.

Analyze the required information.

Design the database and different form applications for the activities

of the department.

Implement and test the designed system.

1.7. Methodology

1.7.1. Data collection methodology

By looking the university website

Observing the existing the system.

Interviewing the manager of store department of Hawassa

university

by surfing internet

Document review of the system.

1.7.2. System design and analysis tools

Class diagram

Activity diagram

Use case diagram

Use case description

Page 13: Project  proposal 32

13 | P a g e

Sequence diagram

User Interface Architecture

1.7.3. System development tools

C #

SQL

Visio

Plat form Window XP and 07

Ms-project

1.8. Cost of the project

Software Description Price Source

Microsoft windows XP 15birr Market

Microsoft office 2007 20

birr

Market

C# - From

university

Argo-UML and Visio - Internet

SQL - From

university

Ms-project software - From

university

Rational rose software - From

university

CD RW 20 Market

Flash disk 150 Market

Page 14: Project  proposal 32

14 | P a g e

A4 papers 100 Market

Desk top computer - University

Anti-virus software 20 Market

Copy 10

Total 335

Table 1.1 Cost Estimation

1.9. Schedule of the project

No Task name Start

date

Finis

h date

Decemb

er

Januar

y

Februa

ry

march April may June

W1

W2

W3

W4

W1

W2

W3

W4

W1

W2

W3

W4

W1

W2

W3

W4

W1

W2

W3

W4

W1

W2

W3

W4

W1

W2

W3

W4

1 Information

gathering

Dec3 jan8

2 Proposal

writing

Dec3 dec20

3 Requiremen

t document

Dec

15

Jan10

4 Analysis

document

Jan 5 Jan20

5 Design Jan

21

Feb 2

6 Implementat

ion

Feb 9 May

20

7 Testing Ap

15

May

30

8 Deployment May

30

Jun 5

Figure 1.1 Schedule of the project

Page 15: Project  proposal 32

15 | P a g e

Chapter two

2.1. Requirement Analysis

2.1.1. Functional requirements

Functional requirements of the system are:

Records the entrance and dispatch of the materials.

Announce the materials which are present or not present.

Indicate the shelf number with its corresponding items by the time of

dispatch.

Record and update the customer details with the material to be taken by

them.

The system should allow user to login into the system and display the

window based on their privilege.

Make a report of activities related to item entrance and dispatch.

Delete the customer information from the dispatch table when the customers

return the item taken by them.

Create and give the account along with the deserved privilege when a need

to add new stock clerk and delete the account in case of resigning work.

2.1.2. Nonfunctional requirements

Security consideration

The system allows its user to perform their task only after login process. The

user should be accompanied with the legible account and password

otherwise they won’t be allowed. All users have access only their own

interface.

Page 16: Project  proposal 32

16 | P a g e

User interface:( attractive and easy to use)

The system will have consistent interface formats and button sets for all

forms in the application, will have a form based interface for all data entry

and viewing formats, and will generate reports that are formatted in a table

and that should look like the existing manual report formats for user

friendliness.

Good performance

The system is capable of carrying huge amount of data with one database.

This system can carry information sufficiently.

Fast response time

In our system when user requests or want to operate some task the system

responses what the user request quickly to satisfy the user need.

System Modification & Maintainability

As it is known, every system needs to be maintained and modified, so we

will try to make the code easily readable and write the comment along with

necessary to the codes.

Page 17: Project  proposal 32

17 | P a g e

Chapter three System Design

3.1. Use case model

Use cases of the system are identified to be “login”, “Record new item”, “Update

item ”, “Record dispatch item ”, “Update dispatch ” , “Return item”, “Checkout

item”, “View report ”, “administer user”. The diagram depicted in Figure 3.1

shows the use case diagram of the system

HAWASSA UNIVERSITY (main cumpas)

Store management system

record new item

record dispatch

item

update item

update dispatch

return item

login

view rport

administer user

checkout item

Stock Clerk

search for item

Manager

«uses»

«uses»

«uses»

«uses»

Figure 2 3.1 Use Case

Page 18: Project  proposal 32

18 | P a g e

3.2. Use case description

I. Login

Actor: stock clerk, manager

Prerequisite: both users must have user account

Workflow:

1. The stock clerk and manager enter their username and password in login

box

2. The system checks for identification and authentication of user accounts.

3. If the user account is valid the system gives access based on their

authentication privilege.

4. Else the system denies the access.

Post Condition: If login is succeeded, the system displays splash. Otherwise it

displays the message “please enter the correct user name or password “and after

three attempt the login button the system is want to be close and open again.

II. Add New Items

Actor: stock clerk, manager

Prerequisite: the new item does not exist in the database

Workflow:

1. Stock clerk enter the basic information of the item: item name, item

description, item code, category (shelf number), quantity received, price

(each item), and remark.

2. The system will validate the filled information.

Post Condition: The system will display a save success message and also

allows stock clerk to update the details.

Page 19: Project  proposal 32

19 | P a g e

III. Update Item

Actor: stock clerk, manager

Prerequisite: The item already exists in the database and the same item is

supplied again.

Workflow:

1. The stock clerk will enter the item name, item description, or item code.

2. The system will search for the item based on the entered criteria (item

name, item description, or item code).

3. The system will display the item’s information allowing the update of

the old information.

4. The store clerk will save the changes made.

Post Condition: The system will display an update success message with the

updated items details.

IV. Record dispatch item

Actor: stock clerk, manager

Prerequisite: The item exists in the database and the customer must be

allowed by the manager.

Workflow:

1. The store clerk will enter customer details with the details of the

corresponding item to take.

2. The system will search for the item based on the entered criteria (item

name, item description, or item code and quantity issued) and decreases

the amount of the item to be taken from the existing item.

3. The system updates the currently available item.

Page 20: Project  proposal 32

20 | P a g e

Post Condition: The system will display a save success message and prints out

confirmation paper for the customer.

V. Update dispatch

Actor: stock clerk, manager

Prerequisite: The customer who previously took item exist in the database

Workflow:

1. The stock clerk will enter the ID or name of the customer.

2. The system will search for the customer based on the entered criteria

(the ID or name of the customer)

3. The system will display the previously dispatch information allowing

the editing of the old information.

4. The store clerk will save the changes made.

Post Condition: The system will display an update success message with the

updated items details.

VI. Return item

Actor: stock clerk, manager

Prerequisite: The item must be dispatched earlier by the customer and he is

ready to give back the item.

Workflow:

1. The stock clerk will enter the ID or name of the customer.

2. The system will search for the customer corresponding with the item

based on the given criteria.

3. The stock clerk will remove the customer along with the item returned.

Page 21: Project  proposal 32

21 | P a g e

4. Post Condition: the system will show the successfully removed

(returned) message

VII. Checkout items

Actor: Manager

Prerequisite: All the items details exist in the database

Workflow:

1. The manager will enter the item name, item description, or item code.

2. The system will search for the all items present based on entered criteria.

3. The system displays all the details of currently present items.

Post Condition: none

VIII. View report

Actor: Manager

Prerequisite: all the activities must be recorded in the database

Workflow:

1. The manager will press the view report button.

2. The system will display the paginated activities.

Post Condition: none

IX. Administer user

Actor: Manager

Prerequisite: the manager should have full privilege

Workflow:

a. Create user account

1. The manager press the create user account button.

Page 22: Project  proposal 32

22 | P a g e

2. He enters the user name and password of the user .

3. He provides the specific privileges that match to the user’s task.

4. He creates the user account.

Post Condition: the system displays confirmation message.

b. Delete user account

1. The manager presses the delete user account button.

2. He enters the user name and password of the user.

3. He deletes the user account.

Post Condition: the system displays unsubscribe message

3.3. Sequence Diagram

Sequence diagrams show the interaction between participating objects in a given

use case. They are helpful to identify the missing objects that are not identified in

the analysis object model. To see the interaction between objects, the following

describe the sequence diagram of each identified use cases.

In the Fig 3.6 below, once the user has activated the record module by interacting

with the boundary object “Record item Button” button, the control object named

“Record items Control” manages the activities involved in “Record item” use

case. First the “Record item form” activates record form which will be filled by the

stock clerk and submitted. The record control sends the record to a persistent

storage.

The sequence diagrams for “Manager Login”, “user login”, “Check the items”,

“General report of items”, “Update items”, and “Return items” use cases are shown

in figures 3.2, 3.5, 3.3, 3.4, 3.7 and 3.8 respectively.

Page 23: Project  proposal 32

23 | P a g e

1. Manager Login

Manager

Login form Login Controller account

{}{}

{} {}

1.Press on the form

2.activate controller

3.Checkdata()

4.Return data

5.Display administrator window

2.enter account

Figure 3.2 Sequence Diagram of login for Manager

Page 24: Project  proposal 32

24 | P a g e

2. Check the item

Manager

check item

button

check item

form

check items

controller Record item

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

1.press check button

2.initiate check item form

3.fill the form

4. press check item button

5.activate controller

9.Display search result

6.Getdata()

7.Return the data

Figure 4.3.3 Sequence diagram of Check item form

Page 25: Project  proposal 32

25 | P a g e

3. General report of items

Manager

Report button Report Controller Database

{}

{} {}{}

2.activate controller

3.Getdata()

4.Return data

5.Display report

Press report button

Figure 5.3.4 sequence diagram of report

Page 26: Project  proposal 32

26 | P a g e

4. User login

Stock clerk

Login form Login Controller account

{}{}

{}

{}

1.Press on the form

3.activate controller

4.Getdata()

5.Return data

5.Display user window

2.enter account

Figure 6.3.5 sequence diagram of user login

Page 27: Project  proposal 32

27 | P a g e

5. Record new items

stock clerk

Record item

button

Record item

form

Record items

controller Record item

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

1.press record button

2.activate record form

3.fill the form

press record item button

5.activate controller

8. saved record

9.confirmation return

6.make sure the necessory data

Acknowledgment

Figure 7. 3.6 sequence diagram of Record new item

Page 28: Project  proposal 32

28 | P a g e

6. Update item

Stock clerck

Update item

button

Search item

form

Search items

controller Record item

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

1.press update button

2.initiate search item form

3.Enter detail to search

4.activate controller

10.Check redundancy

13.Confirmation for successful update

5.Getdata()

6.Return the data

7.View record item search

8.Make possible update

9.Press update item

11.save update data

12.Return confirmation

Figure 8.3.7 sequence diagram of update the item

Page 29: Project  proposal 32

29 | P a g e

Return item

Stock clerck

Return item

button

Return item

form

Return

controller Dispatch item

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

{}

1.press update button

2.initiate return item form

4.press OK button

3.Fill the return form

12.Confirmation for successful deletion

6.Getdata()

6.Return the data

5.activate controller

8. delete()

Figure 9.3.8 sequence diagram of return the item

Page 30: Project  proposal 32

30 | P a g e

3.4. Class Diagram

+create()

+clear()

+cancel()

-firstname:text

-middlename:string

-lastname:string

-password:string

-username:string

account

+exit()

-item_code : string

-itemname : char

-quantity recieved : int

-quantity issued : int

-balance : int

-price : float

report

+record()

+clear()

+cancel()

-cust_id:string

-custname:string

customer

+record()

+clear()

+cancel()

-itemcode:string

-itemdescription:text

-itemname:text

-quantity

-price:float

-shelfnum:float

-remark:string

item

1

n

nn

n

1

1 1

Figure 10. 3.9 class diagram of HU store

Page 31: Project  proposal 32

31 | P a g e

On this class diagram have many attribute that connect each other for instance

many customer can take (dispatch) many items that record on the database, many

items must record by only one account (stock clerk), many items can make in on

report, many customers record their information by one account (stock clerk), one

report are can be seen by only one account (manager) and also one account can be

created to only one user (stock clerks, manager).

3.5. User Interface Architecture User Interface prototype is communication channel that end-user can interact with

a system. All knowledge against a system occurs in compliance with the

interaction of the user and interface. In this paper, we suggest user-centered design

models to standardize user interface architecture and supports flexible development

in any GUI environment.

Dispatch item Record item

Delete account New user account

New item Update Dispatch Return

Checkout Report Administrator User

HU store management system

User login MgrLogin

Page 32: Project  proposal 32

32 | P a g e

Figure 11.3.10 user interface architecture of HU store

3.5.1. Architecture of system

switch

Data base

Stock

clerk

SERVER/

manager

Figure 12.3.11 architecture of the system

Page 33: Project  proposal 32

33 | P a g e

3.6. Activity diagrams 3.6.1.Activity diagram for record items

Login form

[ Click login form]

HU store window

[ click new record]

Record form

[ click record]

summary message box

[ click No] Close record form

[ click yes]

Record succesfull message

[ Cancel]

Figure 13.3.11 activity diagram for Record

Page 34: Project  proposal 32

34 | P a g e

3.6.2.Activity diagram for return the item

Login form

[ Click login form]

HU store window

[ click return]

Return form

[ click return]

summary message box

[ click No] Close return form

[ click yes]

Return succesfull message

[ Cancel]

Figure 14.3.12 activity diagram for Return

Page 35: Project  proposal 32

35 | P a g e

3.6.3.Activity diagram for create account

Open the system

[]

system ask username and password

[ Click login form]

use entered its username and password

[valid]

Access the page

Display error message[ invalid]

Fig.3.13 activity diagram for create account

Page 36: Project  proposal 32

36 | P a g e

3.6.4.Activity diagram for dispatch items

Login form

[ Click login form]

HU store window

[ click dispatch]

Dispatch form

[ click return]

summary message box

[ click No] Close dispatch form

[ click yes]

Dispatch succesfull message

[ Cancel]

Figure 15.3.14 class diagram for Dispatch

Page 37: Project  proposal 32

37 | P a g e

3.6.5.Activity diagram for checkout items

Login form

[ Click login form]

HU store window

[ click check]

Checkout form

[ click check ]

Close dispatch form

display search result

[ Cancel]

Figure 16.3.15 class diagram for checkout

Page 38: Project  proposal 32

38 | P a g e

3.7. Database Design

3.7.1. Normalization

ITEM RECORD

PK Item_code

Item_description

Item_name

Shelf_number

Quantity_received

Unit_price

Remark

Ent_date

Item dispatch

PK Cust_id

Cust_name

Item_code

Item_dispatch

Quantity_issued

exit_date

User name

Account

PK User_name

Password

F_name

L_name

position

Report

PK Item_code

PK cust id

balance

quantity recieved

quantity issued

user name

total price

User name

Dispatch

View by

Put in

Put in Record

Figure 17.3.16.database design

Page 39: Project  proposal 32

39 | P a g e

Item record

Itemdispatch

Customer

Report

Account

Figure 18.3.16 Normalization

I_code I_description I_name Q_recieved U_price E_date Remark

I_code Cust_id Cust_name I_name Exit_date Q_issued

I_code Cust_id User name Quantity recieved

Quantity issued

balance

User_name Password F_name L_name position

Page 40: Project  proposal 32

40 | P a g e

3.8. User interface design

This form is access by both manager and stock clerk by their own account.

Figure 19. 3.17 login form

Figure 20.3.16 Splash form

1. Manager window form

This window is display after the manager entered through administrator account

(user name and password) The manager is as administrator he can access all tasks

but mostly use “Checkout”,”Report”,”Administrator User” this button is contain

Page 41: Project  proposal 32

41 | P a g e

some branches for instance “create account”, “delete account”, “record user ”(stock

clerk, manager).

Figure 21.3.18 Manager Window form

2. Stock clerk window form

After Stock clerk pass the login form by appropriate account(user name and

password ) user window is display . As we see in below figure Stock clerk

restricted by some tasks only he/she can access only “record

item”,”update”,”dispatch”,”return item”.

Page 42: Project  proposal 32

42 | P a g e

Figure 22.3.18 Stock clerk window form

3. Record item form

Mostly this task done by stock clerk by using “record item”button that

placed on the toolbar of user window .stock clerk after entered appropriate

Data in blank form click “Record “button to record the item then click on the

“clear “button if we want to enter additional items finally use “cancel”

button to exit the form.

Page 43: Project  proposal 32

43 | P a g e

1.1. Successful message

This message will displayed when stock clerk fill appropriate information

regard to new item

Page 44: Project  proposal 32

44 | P a g e

1.2. Wrong message

When stock clerk miss some information at the time of new item records the

system indicate wrong process by display wrong message

Figure 23. 3.19 item record form

Page 45: Project  proposal 32

45 | P a g e

Figure 24.3.20 item dispatch form

Page 46: Project  proposal 32

46 | P a g e

Figure 25.3.21 checkout form 26.

Page 47: Project  proposal 32

47 | P a g e

Figure 27. 3.22 return form

Figure 28. 3.23 create account form

Page 48: Project  proposal 32

48 | P a g e

Figure 29.3.24.delete form

Page 49: Project  proposal 32

49 | P a g e

Figure 30.3.25 user form

Figure 31.3.26 Report form

Page 50: Project  proposal 32

50 | P a g e

Reference

T. Willis and B. Newsome. Beginning Visual Basic 2005, Wiley Publishing,

Inc., 2006.

Stephen ,R.(2005) Object Oriented and Classical Software Engineering

Software engineering text book and object oriented software engineering

book.