2.

Chapter Two
Analysis
2.1 Introduction
This chapter focuses on developing the requirement and analysis models for the new system
using the use case model, sequence diagram, activity diagram and class diagram.

Online inventory management system, which can be used for the entire internet users. The
System is an Internet based application that can be accesses throughout the Network and
can be accessed by anyone who has a net connection. This application will automate the
management of inventory.

The system also provides a comprehensive mechanism of managing inventory for any
store workers, this project is designed to help wide range of store officer and provide
service to the staff member.

2.2. Purpose of the study

The purpose of the study to this project is:-

 Access information’s easily.

 Increase staff satisfaction.
 Increase speed of activity.
 Saving store workers cost, time and energy.
 Store any information safely.
 It reduces the number of workers in the office.
 To record items easily.
 To access information easily.
 Report generation is simple.
 To decrease the human labor.
2.3 Description the Existing System
 The existing inventory management system performs the following function with
the manual system and this leads security issues, because of the manual system recording
materials is time consuming and boring. This is the result of lack of computerized system or
web based system.

2.4 Player of the Existing System

The main players of the existing system include the following:

i. Stock manager
ii. Stock keeper
iii. Stock clerk
iv. Customer/staff members

2.1. Work Flow of the Existing System

The work flow in the existing system is performed starting from the top store head to the
lower or store keeper. First the store clerk receives the material detail from the store head and
he/she assigns a code and record the information.
Then the store keeper must get permission to receive and give the materials to the staff
members by the head of the store office and the store keeper checks the incoming and outgoing
materials by the related professionals. Then the store keeper documents the information and
reports those materials detail based on their type to the officer.
2.2. Report Generating in the Existing System

The stock clerk generates report to the stock manager then the manager generates report
periodically according to the task of the organization what activities are performed. But at the
end of the year, the report must be within a total income and an item.

2.3. Business Rules Identified in the Existing System

A business rule is successfully an operating standard or polices that the team has tried to
specify for both the existing system and the proposed system of the store management must
satisfy.
The team mainly focuses on the existing system business rules.
 The existing system has many business rules or principles some of them are:
Br1: new items are recorded and assigned a code by the stock clerks.
Br2: after recording and assigning code by the store clerk the items led to the store keeper
then he/she record, check and place them.
Br3: only staff members of the university are allowed to take an authenticated material.
Br4: when the users/staffs want to borrow any material he/she must register his id, full name,
email, status and other user details properly.
Br5: in order to get the item he /she must get permission from the academic president /president
and the store officer have to put their signature.
Br6: the staff member has to put his/her signature while taking the item.
Br7: the staff member should not damage the item.
Br8: if the staff member has loss or damage the item he/she has to replace that item or pay the
cost with additional percent.

2.4. Problem in the Existing System

The major problem of the existing system is often used manual system so that it takes much
time to generate reports, to manipulate the overall activity of this system.

2.6. Alternative Solution

The team tries to put an alternative solution to the problems of the current existing system
that are described in the above section. The best alternative solution to the existing system is to
change the existing manual system and producing a computerized for the inventory management
system.

2.7. The Proposed System

This is the new system that reduces the existing problems which usually occurred in the
inventory system. The main purpose of the proposed system is to improve some activities
through computerized way that simplifies the workload of the existing system and speed up the
operation of the system.
The team all knows the importance of automation. The application areas for the
computerization have been selected on the basis of following factors:
Minimizing the manual records kept at different locations.
  There will be more data integrity.
 Facilitate desired information display very quickly by retrieving information from users.
 Facilitating various statistical information which helps in decision-making.
 To reduce manual efforts in activities that involved repetitive work.
 Updating and deletion of such a huge amount of data will become easier.
2.8. User Diagrams for the Proposed System
Use case diagram a set of use cases for a system, the actors of these use cases, the relations
between the actors and these use cases, and the relations among the use cases. The UML notation
for a use case diagram is:
 An oval represents a use case,
 A stick figure represents an actor,
 A line between an actor and a use case represents that the actor initiates and/or
participates in the process.
Use cases
Informally speaking, a use case is a story or a case of using a system by some users to carry out a
process. A bit more precisely speaking, a use case describes the sequence of events of some
types of users, called Actors, using some part of the system functionality to complete a process.
Actors
An actor represents a coherent set of roles that are entities external to the system can play in
using the system, rather than representing a particular individual. An actor represents a type of
users of the system or external systems that the system interacts with.
The figure describe below represents Use case diagram.
 Web based Inventory Management System in DMU

Add User Update User

<<Include>> <<Include>> Inactive User

<<Include>>
Manage User

View
<<in
clude
>>
Comment
<<inc
lude>
>

Delete View Report

Login
Administrator <<Extends>> Manager

Logout
View Item

Request Item

<<Include>> <<Include>>
Take Request
Return Request
Staff Member
Stock Clerk Receive Response

Manage Item

>>
clude
<<in

<<inc
lude
Add Item >>

<<in
clude Update Item
>>

Delete Item
 Fig 3.1: Use Case of the Proposed Inventory Management System

3.1.1. Use Case Documentation

It is a sequence event that describes what the proposed inventory system the team will
develop does and how it interacts with the environment mainly. This section describes the most
important activates that the user of inventory system do experience to make use of the system.

Name: Login
UC_ID: UC_01
Actor: users (administrator, manager, stock Clerk and staffs)
Description: this use case is used to ensure security in system usage.
Precondition: the user must have at least username and password.
Post condition: the user get access to the system according to their predefined system privilege
and finally he/she logout or turn off the page.

Main course of action:

Actor action System response

Step1: User has to activate the system. Step2: The System responses by
Step3: User selects account type and fills displaying the login interface and allow the
his or her username and password. user for the user name and password.
Step4: he/she select login button. Step5: System verifies user_name and
Step6: the User get authentication and Password.
access the system. Step7: System displays its own window.
Step8: Use case ends.
Table 3.1: Main Course of Action about Login

Alternative course of action (if user enters wrong user ID and / or password)
Step6: System displays an incorrect username and password message.
Step7: System enables user to try again.

Name: Manage User

UC_ID: UC_02
Actor: Administrator
Description: This use case is done by the Administrator when they need to delete, edit and make
some modification.
Preconditions: The Administrator login to the system to manage users.
Post conditions: The user information will be managed by administrator.
Main course of action:
About adding new user account

Actor action System response

Step1: the Administrator wants to add new user to Step4: the system validates the new user
the system and he/she login to the system. detail.
Step2: the Administrator enters the new user Step5: the system save the user detail to the
name, account type, Password and reenter database.
password to the system via adding new user form. Step6: the system permits some operational
Step 3: the Administrator submits the new user tasks according to his/her category of the
information. new user.
Step7:the Administrator tells the category, user Step8:the system ends
name and password to the user
Table 3.2: Main Course of Action about Add New User Account

Alternative course of action:

Step2: If the Administrator does not enter the username or the password or he/she entered which
does not match correctly, the system displays a message please enters the user name and
password correctly.
Step4: if not correct the system doesn’t save the entered information to the database.
Step5: the system displays a fill again message and allow him/her to fill again.
About updating an account:

Actor action System response

Step1: the Administrator wants to update an Step4: the system checks the new account
account and he/she login to the system. information with the existing account in the
Step2: the Administrator inserts account database.
_type, user_name, password, and other user Step5: the system save the new account to the
 information. database.
Step3: he/she submits the data. Step6: the updating process ends
Table 3.3: Main Course of Action about Update Account

Alternate course action:

Step5: the system doesn’t save the new account to the system database and it displays a fill again
message.
About inactivate the account:

Actor action System response

Step1: the administrator wants to inactivate Step5: the system checks the entered
the account. information with the existing account in the
Step2: he/she login to the system. database
Step3: the administrator enters the account Step6: the system sends message “Do you
type, user_name of the user to be want to inactive?” to the administrator
inactivated in the form. Step8: the system inactivated the account
Step4: the administrator selects the from the system.
inactivate button.
Step7: the administrator selects the yes
option.
Table 3.4: Main Course of Action about Inactivate Account

Alternate course action:

Step3: the system displays fill again message to Administrator.

Step4: it does nothing.
Step5: the system sends a try again message.
Step7: the system ends if he/she selects no.
Name: Manage Item
UC_ID: UC_03
Actor: Stock Clerk
Description: This use case is done by the stock clerk when items are needed to be managed.
Preconditions: The stock clerk has to login to the system when he/she wants to manage item to
the system.
Post conditions: The item information will be recorded to the database of the system.

Main course of action:

About adding item:

Actor action System response

Step1: the stock clerk wants to add new Step4: the system checks the item detail.
item to the system. Step5: the system saves the item input
Step2: the stock clerk inserts the item type, information to the database.
serial_no, brand, model and quantity, to the Step6: the system check whether it have
system via add item form saved successfully or not.
Step3:the stock clerk selects Add Item Step7: the system displays a message
button “successfully added”.
Step8: end the system.

Table 3.5: Main Course of Action about Add Item

Alternative course of action:

Step 3: the system does nothing.

Step4: the system displays “fill again” message.
Step5: does not save the entered data.
Step6: the system displays “not added” message.
Main course of action:

About updating the item detail:

 Actor action System response
Step1: the stock clerk wants to update the Step5: the system checks the entered
item from the system. information with the existing item deail in
Step2: he/she login to the system. the database
Step3: the stock clerk enters the item type, Step6: the system sends message “Do you
item name, item code to be updated in the want to update?” To the stock clerk.
update form. Step8: the system updates the item from the
Step4: the stock clerk selects the update system.
button.
Step7: the stock clerk selects the yes option.
Table 3.6: Main Course of Action about Update Item

Alternate course action:

Step5: displays “try again” message.

Basic course action:

About deleting item detail:

Actor action System response

Step 1: the stock clerk wants deletes the Step 4: the system checks the entered
item from the database. item_code with the existing item_code in
Step 2: the stock clerk enters item_code to the database.
the form. Step 5: the system sends confirmation
Step 3: the stock clerk clicks on delete option message to the stock clerk.
button. Step 7: the system deletes the item from
Step6: the stock clerk selects the yes the database.
option. Step 8: the deleting process ends.

Table 3.7: Main Course of Action about Delete Item

Alternative course of action:

Step5: the system displays fill again message to the stock clerk.
Step7: the system ends if he/she selects no.
Name: View Report
UC_ID: UC_04
Actor: Managers
Description: This use case is seen by manager and the stock clerk when they want to view about
the item report, employee report, scheduling report.
Preconditions: The manager and stock clerk login to the system and the staffs and the items are
already in database.
Post conditions: the manager and the stock clerk views a report of some activities based on their
task.

Main course of action:

Actor action System response

Step 1: the manager wants to view the Step3: the system displays the selected
report. report automatically.
Step2: The manager selects a report type. Step 4: the report process end

Table 3.8: Main Course of Action about View Report

Alternative course action:

Step2: the system does not display the report.
Name: View Item
UC_ID: UC_05
Actor: Manager, Stock Clerk, Staff Members
Description: This use case is seen by all system users except the Administrator about the item
detail.
Preconditions: The users login to the system and the items were already registered.
Post conditions: the staff views all the information that is available.
Main course of action:
Actor action System response
Step 1: the manager, staff or stock clerk Step 4: the system validates the item detail.
wants to see the item detail. Step5: the system displays the item detail.
Step2: they enter the item code. Step 7: the process end
Step3: they click on view item.
Step 6: the staff will see the item
information.
Table 3.9: Main Course of Action about View Item

Alternative course action:

Step2: displays please fill the form.
Step5: the system displays a fill again.
Name: Request Item
UC_ID: UC_06
Actor: Staff Members
Description: this process is done by the staff members when they need to request to take or
return an item.
Preconditions: The staff members have to login to the system and they have to fill the request
item form correctly.
Post conditions: The staff member will sent take or return item request.
Main course of action about taking Item Request:
Actor action System response
Step1: the staff wants to request the item. Step 4: the system validates the item
Step2: the staff member enters the item detail.
description (item type, item name, brand, Step5: the system sends the request.
quantity, model, serial_no etc.) he/she Step6: the process ends.
wants.
Step3: the staff member clicks on request
item.
Table 3.10: Main Course of Action about Take Item Request.
Alternative course of action:
Step5: system displays a try again message.
About returning item request:
Actor action System response
Step1: the staff wants to request the item. Step 4: the system validates the item detail.
Step2: the staff member enters the item Step5: the system sends the request to the
description (item type, item code, name, manager and the manager approves the return
brand, quantity, model, serial_no and other request.
specifications based on the item type) he/she Step6: the process ends.
want to return.
Step3: the staff member clicks on return
Item request.
Table 3.11: Main Course of Action about Return Item Requesting.
Alternative course of action:
Step4: the system displays try again message.
Name: Receive Response
Actor: Staff Members
UC_ID: UC_07
Description: this use case is done by the staff members when the manager sends a
response to them.
Precondition: the staff members have to send a request and the manager is interested to
give a response to them.

Post condition: the staff members receive an approval response or disapproval message.
Main course of action:

Actor Action System Response

Step1: the staff members login to the system. Step 3: the system displays the response
Step2: the staff member select the receive information either approval or not; if the response
response menu. is an approval, then the message should contain
Step4: the staff member views the response. an item detail he/she requested and its item code
and the quantity allowed to him/her.
Step5: the process ends.
Table 3.12: Main Course of Action about Receive Response

3.1. Analysis Level of Class Diagram

Class Diagrams are used to represent the structure of the system in terms of objects, their
notes and nature of relationship between classes. It shows the static features of the objects and do
not represent any particular processing.
Our system has the following classes:
Manager: is the representation of the real world class of manager which interacts with system to
accomplish the managerial activity such as view report, approve request.
Staff members: is the representation of the real world user.
Administrator: is an administrator which uses the automated system to manage users.
Item: it is the representation of the real world class of materials.
Stock clerk: the representation of the real world class which interacts with system to accomplish
the activity such as managing items.
Fig 3.2: Class Diagram of our System
 3.4. Sequence Diagram

A sequence diagram is a kind of interaction diagram that shows how processes of the
proposed system of inventory management system operate and in what order. It is a construct of
a Message Sequence Chart.

Sequence diagram shows object interactions arranged in time sequence. It depicts the objects and
classes involved in the scenario and the sequence of messages exchanged between the objects
needed to carry out the functionality of the scenario of the proposed system. Sequence diagrams
typically are associated with use case realization in the logical view of the proposed system
under development. The main sequence diagrams of the new system of inventory management

main window login link login form login controler Database

Login users
UC #01

1:user activate UI()

2:click on login link()

1. all system users
activate the user
interface(UI)
2.click/select on the
3:Display login form to users()
login link
3. system diisplays
the login form 4:select account type and fill user name and password()
4. select the aaccount
type and fill the user
name and password .
5.click on submit 5:clik submit()
button. 6:validate()
6. validate the account
information.
7.try again, 7:try again()
8.loged in 8:login to the system()
9. check 9:Check ()
10.display response

10:Response to login form()

system are listed below.

Fig 3.3: Sequence Diagram of Login

Add new user Add user link New user form User Controller Database
UC#02 Adminstartor

1:click add user()

1. adiminstrator click
add new user 2:display add new user form()
2.the system displays
new user form
3.he/she fill new user
information and account 3:fill new user information()
type.
4.the Adminstraator 4:Click on Add User button()
click on Add user
button 5:validate()
5.system checks the
validation of input data 6:fill again()
6.if it is not correct the 7: Added to Database()
system displays fill 8:check()
again and go to new
user foorm 9:Display response to Adminstrator()
7.if it is correct save the
new user information to
Database
8.check the user detail
in Database
9.the system displays a
response
Fig 3.4: Sequence Diagram of Add New User

update user
account UC#02 Update User link update user updated user Database
: Adminstrator
form controler

1. adiminstrator select on
update user link 1:select update user link()
2.the system displays the
update user form
3.the adminstrator fills
the user information 2:the system displayys the updaate user form()
4.he/she click on update
button.
5.the system validate the
data. 3:fill user detail()
6.if it is not correct it
displays fill it again.
7.if he/she fills correctly
the system updates the
4:click on update button()
database
5:validate()
8.system checks the data
if it is correctly updated
9.the system displays the
response .
6:fill it again()
7:update the data()

8:check the detail()

9:display responnse()

Fig 3.5: Sequence Diagram of Update User

Inactive user
account Inactive User Inactive user Inactive user Database
UC#02 Adminstartor
link form controler

1. adiminstrator select 1:select inactive user link()

to Inactive user link
2:displays the form()
2.the system displays a
inactive user form 3:fill the user information to be inactive()
3.the adminstrator fills
the uer detail to be
inactvated
4.click on inactive user
5. validate the data
6.the system displays
fill again message.
7.system inactivates
user from the database.
8.the system checks if it
is properly inactivated 4:click the inactive user button() 5:validate the data()
or not.
9.the system displays a 6:fill again()
messag to the form.

7: inactive the user from database()

8:check()

9:display response()
Fig 3.6: Sequence Diagram of Inactive User Account

Add Item
UC#03 Add Item link Add item form Item controler item Database
: Stock Cerk

1.he/she select Add Item

link. 1:select add item link()
2:the system displaays add
item form.
3.enter item information 2:Display Add Item form()
he/she want to Add and
press Add Item button.
4.system checks the
validation of input data
5.if not correct the 3:fill item information()
system displays try again
and go back to add item
form
6.if it is correct Add the
Item information to 4: the stock clerk click on Add item button()
database
7. the system checks the
item detail in Database 5:fill again()
8:system displays
response

6:Save to Database()
7:check()

8:displays response()
 Fig 3.7: Sequence Diagram of Add Item

View Report
view Report link Report Type Report controler Database
UC#05 Manager/Stock
Clerk
1:select view report link()
1. the manager select
view Report link
2.he/sheselect the
Report type.
3.click on view report.
4.the system fetch the
data.
5. the sytem displays 2:Manager select the Report type ()
the report to the stock
clerk or manager.
3:Clik on view()

4:fetch ()

5:display report()
Fig 3.8: Sequence Diagram of View Report

Take Item
Request Take Request Take Request Take Request Database
: Staff Member
UC#07 Link Form Controler

1:select request link()

1. the staff member
select Request link
2.the system displays the
Request from.
3.he/she fill the Request 2:Display request form()
form
4.click on Request
button 3:fill the request form()
5.validate the Data
6.if not correct the
system Displays try
again message. 7.submit 4:click on take request button()
the request and save to 5:validate()
database
8.check
9:display response 6:Try Again()

7:submit the request()

8:check()

9:display response()
Fig 3.9: Sequence Diagram of Request Item

3.2. Activity Diagram

As we have seen, a sequence diagram shows how objects interact over time to accomplish
specific system functions or activity of inventory management system. Activity diagram shows
also the conditional logic for the sequence of system activities needed to accomplish a business
process of proposed system in a good way.

Add new user

UC#02
Actor:Adminstr Login
ator

check
not correct Help to login

Correct

Main Menu
Solved

Select

Add new
user

Enter

New user
information

Submit

Wrong

True Not Solved

Added

Fig 3.10: Activity Diagram of Add New User

 Login

manage User
UC#02
Actor:Adminstrator check

not correct Help to login

Correct

Main Menu Solved

Select
update user
enter Select
user detail Manage User
Inactive
user

Check

Try Again
Not Solved

Found Managed

Fig 3.11: Activity Diagram of Manage User

 Add Item
UC#03
Actor:Stock Login
Clerk

check
not correct Help to login

Correct

Main Menu
Solved

Select

Add Item

Enter

Item
Information

Submit

not correct

Not Solved
correct

Added

Fig 3.12: Activity Diagram of Add Item

 Login

View Report
UC#05 check
Actor:Manager/Stock
Clerk
not correct Help to login

Correct

Main Menu Solved

view Item Report Select

item Report

view Select
Employee Employee View Report
report Report
view User Report
User report

Not Solved
Displayed

Fig 3.13: Activity Diagram of View Report

.

Take Request Item

UC#07
Actor:Staff Member Login

check
not correct Help to login

Correct

Main Menu
Solved
Select

Take Request
Form

Enter

Item,user
Not Correct Detail

Request

Not Solved
Correct

Send Item
Request

Fig 3.14: Activity Diagram of Take Request Item