The document is a final report on the development of an Inventory Management System (IMS) for the Institute of Information Technology at the University of Dhaka, detailing the software design, development processes, and testing. It outlines the project's objectives, scope, deliverables, and the technologies used, emphasizing the transition from a manual to an automated inventory management process. Additionally, it provides a comprehensive overview of the system's functionalities and user interactions to streamline inventory requests and management.

1. 0
June 11, 2015
INVENTORY
MANAGEMENT
SYSTEM
Software
Project Lab II
SE 505

2. Inventory Management System
Final Report
SE - 505
Submitted by:
BSSE 0502-Jobayer Ahmmed
BSSE 0523-Shahriar Mohammed Ishmam
BSSE 0535-Khandaker Mamun Ahmed
Supervisor:
Alim Ul Gias
Lecturer
Institute of Information Technology
Submitted to:
Emon Kumar Dey
Lecturer
Institute of Information Technology
Submission Date: June 11, 2015

3. LETTER OF TRANSMITTAL
June 11, 2015
Emon Kumar Dey
Lecturer
Institute of Information Technology
University of Dhaka.
Sir,
We have developed the Inventory Management System Software
and prepared the final report of ‘Inventory Management System
for IIT DU’ for your approval. This report details the design,
development process, software requirement analysis and
specification and testing process.
The primary purpose of this report is to summarize all the
thing that have been done to develop the software application .
This report includes the details of each step we followed to
develop the software.
Sincerely Yours,
Jobayer Ahmmed (BSSE-0502)
Shahriar Mohammed Ishmam (BSSE-0523)
Khandaker Mamun Ahmed (BSSE-0535)

4. 0
Contents
Chapter 1: Introduction ………………………………………………………………1
1.1 Motivation and Background..............................................................1
1.2 Objectives .........................................................................................2
1.3 About the Project..............................................................................2
1.4 Scope ................................................................................................2
1.5 Assumption and Constraints .............................................................3
1.6 Project Delivery.................................................................................3
1.6.1 Deliverables .............................................................................................. 3
1.6.2 Timescale .................................................................................................. 4
1.7 Cost and Benefits ..............................................................................5
1.7.1 Cost........................................................................................................... 5
1.7.2 Benefits..................................................................................................... 5
1.8 Glossary of Technical Terms..............................................................6
1.9 Conclusion.........................................................................................6
Chapter 2: Software Requirements Analysis and Specifications 7
2.1 Inception...........................................................................................7
2.1.1 Introduction .............................................................................................. 7
2.1.1.1 Identifying Stakeholders..................................................................... 7

5. 2.1.1.2 Asking the First Questions.................................................................. 9
2.1.1.3 Recognizing Multiple Viewpoints ....................................................... 9
2.1.1.4 Working towards Collaboration........................................................ 11
2.1.2 Conclusion............................................................................................... 13
2.2 Elicitation ........................................................................................20
2.2.1 Introduction ............................................................................................ 20
2.2.2 Eliciting Requirements ............................................................................ 20
2.2.3 Collaborative Requirements Gathering ................................................... 21
2.2.4 Quality Function Deployment ................................................................. 21
2.2.4.1 Normal Requirements ...................................................................... 21
2.2.4.2 Expected Requirements ................................................................... 22
2.2.4.3 Exciting Requirements...................................................................... 22
2.2.5 Usage Scenario........................................................................................ 23
2.2.6 Elicitation Work Product ......................................................................... 24
2.3 Scenario-Based Model ....................................................................25
2.3.1 Introduction ............................................................................................ 25
2.3.2 Use Case Scenario ................................................................................... 25
2.3.3 Use Case Description............................................................................... 27
2.4 Data Model .....................................................................................79
2.4.1 Introduction ............................................................................................ 79
2.4.2 Data Objects Selection ............................................................................ 79

6. 2.4.3 Data Objects and Attributes:................................................................... 84
2.4.4 Relationships between Data Objects....................................................... 85
2.4.5 Entity-Relationship Diagram.................................................................... 87
2.4.6 Schema ................................................................................................... 89
2.5 Class Based Modeling.....................................................................92
2.5.1 Introduction ............................................................................................ 92
2.5.2 Identifying Analysis Classes ..................................................................... 92
2.5.3 Selection Characteristics: ........................................................................ 94
2.5.4 Attribute Selection.................................................................................. 96
2.5.5 Defining Methods.................................................................................... 97
2.5.5.1 Verb List ........................................................................................... 97
2.5.5.2 Selected Methods ............................................................................ 98
2.5.6 Class Diagram.......................................................................................... 99
2.5.6 Class-Responsibility-Collaborator (CRC) Modeling................................. 100
2.6 Flow-Oriented Model....................................................................102
2.6.1 Introduction .......................................................................................... 102
2.6.2 Data Flow Diagram (DFD)...................................................................... 102
2.7 Behavioral Model..........................................................................106
2.7.1 Introduction .......................................................................................... 106
2.7.2 Identifying Events.................................................................................. 106
2.7.3 State Transition Diagram....................................................................... 107

7. 2.7.4 Sequence Diagram ................................................................................ 113
Chapter 3: Software Design……………………………………………….. 126
3.1 Internal Software Design...............................................................126
3.2 System Structure...........................................................................127
3.3 Graphical User Interface (GUI)......................................................127
3.4 Conclusion.....................................................................................128
Chapter 4: Implementation and Testing……………………………...129
4.1 Implementation ............................................................................129
4.1.1 Technologies ......................................................................................... 129
4.1.1.1 ASP.NET Framework....................................................................... 129
4.1.1.2 Hyper Text Markup Language (HTML) ............................................ 129
4.1.1.3 Cascading Style Sheet (CSS)............................................................ 130
4.1.2 Implementation Tools........................................................................... 130
4.1.2.1 Microsoft Visual Studio 2013.......................................................... 130
4.1.2.2 Microsoft SQL Server 2012............................................................. 130
4.2 Coding...........................................................................................131
4.2.1 Data Access Layer.................................................................................. 132
4.2.2 Business Logic layer............................................................................... 132
4.2.3 Presentational layer .............................................................................. 133
4.3 Testing ..........................................................................................133

8. 4.3.1 Test Cases ............................................................................................. 134
4.4 Conclusion.....................................................................................136
Chapter 5: User Manual……………………………………………………….137
5.1 Work flow of Store-in-charge........................................................137
5.1.1 Create Register Book............................................................................. 137
5.1.2 Set recommender and director ............................................................. 138
5.1.2.1 Set Director .................................................................................... 138
5.1.2.2 Set Recommender.......................................................................... 139
5.1.3 Category window .................................................................................. 141
5.1.4 All Items window................................................................................... 141
5.1.5 Notification System............................................................................... 142
5.1.5.1 Message Queue.............................................................................. 142
5.1.5.2 Send notification ............................................................................ 143
5.1.6 Requisition System................................................................................ 145
5.1.6.1 Requisition History ......................................................................... 145
5.2 Work flow of recommender..........................................................146
5.2.1 Category................................................................................................ 147
5.2.2 All Items................................................................................................ 147
5.2.3 Notification System............................................................................... 147
5.2.4 Requisition System................................................................................ 147

9. 5.2.4.1 Requisition History ......................................................................... 148
5.2.4.2 Create Requisition Slip ................................................................... 149
5.3 Work flow of Director ...................................................................150
5.4 Work flow of user..........................................................................151
Chapter 6: Conclusion………………………………………………………….152
6.1 Future Plan....................................................................................152
Appendix.............................................................................................153

10. x
Executive Summary
An Inventory Management System (IMS) is proposed by Institute of Information
Technology, University of Dhaka (IIT, DU) for the people who interacts with the
system. It is a web based system where actors are provided user friendly
automated environment to accomplish their tasks.
Acknowledgements
By the grace of Almighty Allah we have developed Inventory Management
System software for IIT, DU. We are grateful to our honorable supervisor Alim UL
Gias for his supervision throughout the working time. He helped us a lot by
sharing his invaluable knowledge with us. We are also thankful to all teachers, staffs
of IIT. They greatly helped us a lot. Especially the store-in-charge who helps us find
out all requirements specifically

11. This page is intentionally left blank

12. 1
Chapter 1
Introduction
IIT Inventory Management System is a web based application. It will provide a
complete automated system which will be greatly beneficial for people who use
inventories from the store of IIT. The main aim of this project is to make the
application easy to use and user friendly. Here users can create requisition slip and
send it to store-in-charge. If the requested item is available to the store room the
store-in-charge will send the item to the requested user. Users can also
communicate with each other through notification. In this chapter, we have
discussed the background study and motivation of this project, objectives of the
project, scope of this project, cost and benefits and some preliminary idea of our
IMS application. We also provide a timeline schedule to reach our goal.
1.1 Motivation and Background
Technology has brought about a revolution in the modern world. It has made our
live easy and fast. Internet offers us to grab the whole world within a very short
time. Today most of the manual works is replaced by automated systems. The IMS
is developed based on this purpose.
Institute of Information Technology (IIT) has a store room which keeps all the
inventories of IIT. A store-in-charge is assigned to manage all the inventories. When
some inventories are brought to IIT, it is added to the store. If teachers or staffs
need something, they take it from the store room. They fill up a requisition slip and
submit it to the store-in-charge. Then the requisition slip is verified and the
applicant is provided with the inventory. The store-in-charge keeps track of all

13. 2
these transactions. All these tasks are done manually. It is time consuming,
troublesome and error-pron. So the automated solution for this system has
become essential to make this job easier.
1.2 Objectives
Objectives of the project are the followings:
 Create requisition slip.
 Verify requisition slip through the system.
 Preserve all the necessary documents.
 Track all the transactions’ information.
 Create easy, user-friendly, attractive web interface.
1.3 About the Project
IMS has built to automate the manual inventory management system of IIT. It saves
a lot of time as well as cost. Here users get easy access to the system via internet.
Users can create requisition slip here and send it to store-in-charge. The store-in-
change creates register book here. He gives inventory to the requested user when
he gets notification from users. When new items are brought he updates the
inventory list. Here he can also create reports. If some inventories are not available
in the store room the user can directly see it. Communication is also established
here through notification.
1.4 Scope
IMS is a web based application developed in .net platform. Users can access to the
system via any standard browser. Creation of requisition slip and register book,

14. 3
updating the inventory list, verifying of the requisition slip, tracking the
transactions all can be done through the system. Users can also communicate with
each other through notification.
1.5 Assumption and Constraints
User should use standard browser (such as Firefox, chrome, IE, opera) for
better visibility. Those who will use this web-app in mobile set, their mobile set’s
browser must have to support JavaScript and HTML5. The application can be
deployed in windows platform only.
1.6 Project Delivery
This project is developed according to a timescale. The followings will be submitted
as necessary deliverables.
1.6.1 Deliverables
We will deliver our product with all required contents so that one can grab and use
it easily.
The following contents will be delivered with the project:
 Source code
 An *.exe file
 User manual
 Documentation

15. 4
1.6.2 Timescale
We have developed our project maintaining a timescale, so that we can deliver the
project in time. We have given enough time for both requirements analysis and
coding. Along with coding, we have tested our code and finally integrated our
module of programs.
Idea Generation Jan 15 – Jan 24 10 days
Requirements Analysis Jan 25 – Feb 28 35 days
Preparing Project Proposal Feb 21 – Feb 25 05 days
Learning Technologies Mar 01 – Mar 30 30 days
Coding Mar 22 – May 05 45 days
Integration May 05 – May 15 10 days
Testing June 01 – June 05 05 days
Preparing Final Report June 06 – June 10 05 days
Table 1.1: Timescale

16. 5
Fig 1.1: Timeline
1.7 Cost and Benefits
The costs and benefits of the project are the following which gives clear idea to the
users.
1.7.1 Cost
The development of the application costs some money which are the following:
Cost type Amount
Communication 500 Taka
Internet 500 Taka
Meeting 400 Taka
Printing 800 Taka
Table 1.2: Cost
1.7.2 Benefits
Benefits of the project are given below:
 Automates the manual system.
 Store-in-charge can create register book, update inventories, keep
inventories record.

17. 6
 Users can create requisition slip, send it to store-in-charge and will get
notification when the inventory will deliver to him.
 Users can access to the system via internet.
1.8 Glossary of Technical Terms
Here we demonstrates all the technical word, jargons and abbreviations.
Terms Definition
IIT Institute of Information Technology
IMS Inventory management system
Browser A software application for retrieving,
presenting and traversing information
resources on the World Wide Web.
.net Platform for developing different
applications.
JavaScript A web language to give dynamic
property.
HTML5 Hypertext markup language
Table 1.3: Glossary of Technical Terms
1.9 Conclusion
To build applications background study and scope is necessary. Thus before
building this software application IIT IMS, we studied these and gave time for pre-
planning.

18. 7
Chapter 2
Software Requirement Analysis And Specification
2.1 Inception
2.1.1 Introduction
Inception is the beginning phase of requirements engineering. It defines
how does a software project get started and what is the scope and
nature of the problem to be solved. The goal of the inception phase is to
identify concurrence needs and conflict requirements among the
stakeholders of a software project. To establish the groundwork we
have worked with the following factors related to the inception
phases:
 Identifying Stakeholders
 Asking the First Questions
 Recognizing Multiple Viewpoints
 Working towards Collaboration
2.1.1.1 Identifying Stakeholders
Stakeholder refers to any person or group who will be affected by the system
directly or indirectly. Stakeholders include end-users who interact with the
system and everyone else in an organization that may be affected by its

19. 8
installation. To identify the stakeholders we consulted with Store in charge of IIT
and asked him following questions:
 Who will be using the project outcomes?
 Who has resources I need to get the project done?
 Whose work will my project affect?
Concluding thoughts on Stakeholders, We identified following stakeholders for
our automated Student information system for IIT DU:
1. Store in Charge: Store in charge is the person who is responsible for maintaining
the inventories in store of IIT. He manages all the tasks related to the inventories
and decides who will be the next actors for what tasks and what will be the next
action. He has the power to update the information of store.
2. User: Users are those who will use the inventories from the store for the purpose
of IIT. All the teachers including director, staffs, and store in charge of IIT are the
users.
3. Director: Director has the supreme power to take decisions about IIT. If
modifications (buying inventories, giving inventories to users) are needed in store,
it has to be verified by the director.
4. Recommender: Recommenders are those who have authority to recommend
for the users to accomplish any tasks. In the system, when user take inventories
they have to be recommended by the recommender.

20. 9
2.1.1.2 Asking the First Questions
We set our first set of context-free questions focuses on the customer and other
stakeholders, overall project goals and benefits. The questions are mentioned
above. These questions helped us to identify all stakeholders, measurable benefit
of the successful implementation and possible alternatives to custom software
development. Next set of question helped us to gain a better understanding
of problem and allows the customer to voice his or her perception about the
solution. The final set of question focused on the effectiveness of the
communication activity itself.
2.1.1.3 Recognizing Multiple Viewpoints
We collect these view points by discussing with IIT’s store in charge,
teachers, staffs, director.
Store in charge:
 A web based system.
 User friendly interfaces.
 System can be accessed from internet.
 Application will be platform independent.
 A system that has secure database.
 Easy to maintain the store.
 Easy to add new items.
 A system that will track all information about all items.
 An easy system to create report.

21. 10
 Should have notification based communication system.
 All user should have different account
User (Teachers, Staffs):
 User friendly interface
 Easy access
 Can check the availability of an item in store
 Easy system to order inventories
 History of individual’s usages of inventories
 User can access the system from mobile phone
Recommender:
 An web based system
 System can be accessed from internet
 The recommendation process should be an automated
system
 Recommender will see the applicant’s profile
Director:
 An web based system
 Director will get all the facilities of a normal user
 Only he can verifies when verification is needed
 The verification system will be an automated system

22. 11
2.1.1.4 Working towards Collaboration
Every stakeholder has their own requirements. We followed following steps to
merge these requirements:
 Identify the common and conflicting requirements
 Categorize the requirements
 Take priority points for each requirement from stakeholders and on
the basis of this voting prioritize the requirements
 Make final decision about the requirements
Common Requirements:
 Web-Based Interfaces.
 The application can be accessed from any computer that has Internet
access.
 Easy Access.
 Every user will have individual account.
 Maintain a database of all items in the student information system.
 Every user can check the current inventories of store.
 Application, recommendation and verification system will be automated.

23. 12
Conflicting Requirements:
 Easy access and Strong Authentication.
 Public and private information about profile.
 About the authority who will order for buying inventories.
Final Requirements:
 Web-Based Interfaces.
 The application can be accessed from any computer that has Internet
access.
 Easy Access.
 An error free system.
 Every user will have individual account.
 Maintain a database of all items in inventory management system.
 Every user can check the current inventories of store.
 Restrict access to functionality of the system based upon user roles.
For example, Only Administrators of the system will be provided
functionality to change user types, configure new changes to maintain
database.
 User can search item according to categories.
 Application, recommendation and verification system will be automated.
 Store in charge will maintain the software.
 All information about the inventories including purchase voucher, user of
the inventories will be saved.

24. 13
 Only director can verify when needed.
 The recommenders will be pre-defined and store in charge will decide who
will recommend.
 Store in charge can create and print report when needed.
 Notification system will be the way for communication and all notification
will be saved in database.
 An automated register book will be maintained to track the information
about inventories and their users.
2.1.2 Conclusion
Inception phase helped us to establish basic understanding about Inventory
Management System(IMS) for IIT, DU; identify the people who will be benefited
if IMS becomes automated, define the nature of the IMS and establish a
preliminary communication with our stakeholders.

25. 14
Group Meeting
1. Date: January 16, 2015
Subject: Identifying Stakeholders
Place: Institute of Information Technology, University of Dhaka
Participators:
 BSSE 0502- Jobayer Ahmmed
 BSSE 0523- Shahriar Mohammed Ishmam
 BSSE 0535- Khandaker Mamun Ahmed
2. Date: January 18, 2015
Subject: Identifying Stakeholders
Place: Institute of Information Technology, University of Dhaka
Participators:
 BSSE 0502- Jobayer Ahmmed
 BSSE 0523- Shahriar Mohammed Ishmam
 BSSE 0535- Khandaker Mamun Ahmed
3. Date: January 25, 2015
Subject: Collecting requirements from the stakeholders
Place: Institute of Information Technology University of Dhaka
Participators:
 BSSE 0502- Jobayer Ahmmed
 BSSE 0523- Shahriar Mohammed Ishmam

26. 15
 BSSE 0535- Khandaker Mamun Ahmed
4. Date: January 29, 2015
Subject: Collecting requirements from the stakeholders
Place: Institute of Information Technology University of Dhaka
Participators:
 BSSE 0502- Jobayer Ahmmed
 BSSE 0523- Shahriar Mohammed Ishmam
 BSSE 0535- Khandaker Mamun Ahmed
5. Date: February 5, 2015
Subject: Collecting requirements from the stakeholders
Place: Institute of Information Technology University of Dhaka
Participators:
 BSSE 0502- Jobayer Ahmmed
 BSSE 0523- Shahriar Mohammed Ishmam
 BSSE 0535- Khandaker Mamun Ahmed
6. Date: February 13, 2015
Subject: Collecting requirements from the stakeholders
Place: Institute of Information Technology University of Dhaka

27. 16
Participators:
 BSSE 0502- Jobayer Ahmmed
 BSSE 0523- Shahriar Mohammed Ishmam
 BSSE 0535- Khandaker Mamun Ahmed
7. Date: February 17, 2015
Subject: Collecting requirements from the stakeholders
Place: Institute of Information Technology, University of Dhaka
Participators:
 BSSE 0502- Jobayer Ahmmed
 BSSE 0523- Shahriar Mohammed Ishmam
 BSSE 0535- Khandaker Mamun Ahmed
8. Date: February 20, 2015
Subject: Use Case Modeling
Place: Curzon Hall, University of Dhaka
Participators:
 BSSE 0502- Jobayer Ahmmed
 BSSE 0523- Shahriar Mohammed Ishmam
 BSSE 0535- Khandaker Mamun Ahmed
9. Date: February 27, 2015

28. 17
Subject: Activity Diagram Modeling
Place: Institute of Information Technology, University of Dhaka
Participators:
 BSSE 0502- Jobayer Ahmmed
 BSSE 0523- Shahriar Mohammed Ishmam
 BSSE 0535- Khandaker Mamun Ahmed
10. Date: February 29, 2015
Subject: Swim Lane Modeling
Place: Curzon Hall, University of Dhaka
Participators:
 BSSE 0502- Jobayer Ahmmed
 BSSE 0523- Shahriar Mohammed Ishmam
 BSSE 0535- Khandaker Mamun Ahmed
11. Date: March 6, 2015
Subject: Database Modeling
Place: Curzon Hall, University of Dhaka
Participators:
 BSSE 0502- Jobayer Ahmmed
 BSSE 0523- Shahriar Mohammed Ishmam
 BSSE 0535- Khandaker Mamun Ahmed

29. 18
12. Date: March 15, 2015
Subject: Class Based Modeling
Place: Curzon Hall, University of Dhaka
Participators:
 BSSE 0502- Jobayer Ahmmed
 BSSE 0523- Shahriar Mohammed Ishmam
 BSSE 0535- Khandaker Mamun Ahmed
13. Date: March 23, 2015
Subject: Data Flow Modeling
Place: Institute of Information Technology, University of Dhaka
Participators:
 BSSE 0502- Jobayer Ahmmed
 BSSE 0523- Shahriar Mohammed Ishmam
 BSSE 0535- Khandaker Mamun Ahmed
14. Date: March 28, 2015
Subject: State Transition Diagram
Place: Curzon Hall, University of Dhaka
Participators:

30. 19
 BSSE 0502- Jobayer Ahmmed
 BSSE 0523- Shahriar Mohammed Ishmam
 BSSE 0535- Khandaker Mamun Ahmed
15. Date: March 30, 2015
Subject: Sequence Diagram
Place: Curzon Hall, University of Dhaka
Participators:
 BSSE 0502- Jobayer Ahmmed
 BSSE 0523- Shahriar Mohammed Ishmam
 BSSE 0535- Khandaker Mamun Ahmed

31. 20
2.2 Elicitation
2.2.1 Introduction
Elicitation is a task that helps the customer to define what is required. To
complete the elicitation step we face many problems like problems of scope,
problems of volatility and problems of understanding. However, this is not an
easy task. To help overcome these problems, we have worked with the Eliciting
requirements activity in an organized and systematic manner.
2.2.2 Eliciting Requirements
Unlike inception where Q&A (Question and Answer) approach is used, elicitation
makes use of a requirements elicitation format that combines the elements
of problem solving, elaboration, negotiation, and specification. It requires the
cooperation of a group of end-users and developers to elicit requirements
.To elicit requirements we completed following four works.
1. Collaborative Requirements Gathering
2. Quality Function Deployment
3. Usage Scenarios
4. Elicitation work products

32. 21
2.2.3 Collaborative Requirements Gathering
Many different approaches to collaborative requirements gathering have been
proposed. Each makes use of a slightly different scenario .We completed following
steps to do it.
 The meetings were conducted with store in charge .He was questioned
about requirements and expectations from the Inventory Management
System.
 He was asked about the problems he is facing with the current manual
system. At last we selected our final requirement list from the meetings.
2.2.4 Quality Function Deployment
Quality Function Deployment (QFD) is a technique that translates the needs of the
customer into technical requirements for software .It consents rates on maximizing
customer satisfaction from the Software engineering process .With respect to our
project the following requirements are identified by a QFD.
2.2.4.1 Normal Requirements
Normal requirements consist of objectives and goals that are stated during
the meeting with the customers. Normal requirements of our project are:
1. Accessible via the Internet.
2. Allow any valid user to log in and log out to the system.
3. Allow all users to make requisition for inventories.
5. Restrict access to functionality of the system based upon user roles.

33. 22
2.2.4.2 Expected Requirements
These requirements are implicit to the system and may be so fundamental that
the customer does not explicitly state them. Their absence will be a cause for
dissatisfaction.
1. Maintain a database of all items in the Inventory Management System.
2. The system shall enable the administrator to change a user’s type to any user
type.
3. Administrator will be able to configure the any changes.
4. The system shall enable the store in charge to change or update any
information.
5. The system shall allow the user to log in based upon an assigned login ID and
password.
6. Each user will send notifications to other who will be responsible for next action
in the system. The communication will be notification based.
7. The user interface of the system shall be easy to use and shall make use of drop-
down boxes, radio buttons, and other selectable fields wherever possible instead
of fields that require the user to type in data.
2.2.4.3 Exciting Requirements
These requirements are for features that go beyond the customer's expectations
and prove to be very satisfying when present.
1. The user interface should provide appropriate error messages for invalid input
as well as tool-tips and online help.

34. 23
2. The user interface should follow standard web practices such that the web
interface is consistent with typical internet applications.
3. User can view notifications history that he/she sends or receive from other users.
4. Users’ previous records of requisition of inventories can be seen.
5. User initiate the steps for buying inventories when those are not available in the
store.
2.2.5 Usage Scenario
The usage scenario of Inventory Management System is given below:
IIT Inventory Management System
Institute of Information Technology (IIT), University of Dhaka proposes an Inventory
Management System (IMS) for IIT. It will be a web-based system which will ease to maintain
and keep track of the inventories.
IIT has a store room where all inventories of IIT are stored. When some inventories are
purchased, they are first stored in the store room. From there, those will be supplied according
to the necessity of the Institute. A store in charge is assigned to maintain those activities.
All inventories may come from multiple ways. Some inventories are provided by University,
some are purchased by IIT and some inventories may come from other sectors. The accounts
of all these inventories are kept in register books. The register books contain name of articles,
balance (received), date, No and date of voucher for purchase (received), No. of articles,
total, purpose of which issued (Issued), number of articles (Issued), balance, where located,
signature of the officer in acknowledgement of his having received the articles, remarks.
When the inventories are brought to IIT, store in charge receives them and preserves
necessary documents.

35. 24
When teachers or staffs (user) of IIT need something, they will take it from the store. They
should fill up a requisition slip. The requisition slip contains serial number, date, the applicant’s
name, position/address and purpose, item description, quantity, total item, recommender’s
signature, applicant’s signature, director’s signature. They then sends the slip to the store in
charge. The store in charge checks whether the item is available or not. If available, he
forwards the slip to the director for approval. After getting approved, the item is delivered to
the applicant. The store in charge updates the register book and the applicant signs on the
register book. If the requested item is not available in the store, the manager fills up a
requisition slip to purchase the item. Users will communicate with each other through
notifications.
The store in charge creates reports when it is needed. The report contains different fields
selected by the store in charge.
2.2.6 Elicitation Work Product
The output of the elicitation task can vary depending on size of
the system or product to be built. Our elicitation work product
includes:
 A statement of our requirements for automated book circulation
system.
 A bounded statement of scope for our system.
 A list of customers, users and other stakeholders who
participated in requirement specification.
 Set of usage scenarios.
 Description of the system’s technical environment.

36. 25
2.3 Scenario-Based Model
2.3.1 Introduction
In this model the system is described from the users’ point of view. As this is the
first model, it serves as input for creation of other modeling elements.
2.3.2 Use Case Scenario
As requirements are gathered, an overall vision of system functions and features
begins to materialize. To understand how these functions and features will be
used by different classes of end users, developers and users create a set of
scenarios, called use case scenario, that identify a thread of usage for the system
to be constructed.
Use Case Scenario
Level-0 Level-1 Level-2 Level-3 Actor
Inventory
Management
System
Authentication Sign Up User,
Store in
charge,
Director,
Recomm
ender
Sign In User,
Store in
charge,
Director,
Recomm
ender
Sign Out User,
Store in
charge,
Director,

37. 26
Recomm
ender
Creating
Register Book
Store in
charge
Receiving
Inventories
Store in
charge
Requisition
Subsystem
Creating
Requisition Slip
Select
Requisition
Type
User
Filling up
Requisition Slip
User
Send to Store
in charge
User
Recommendati
on
Send
Requisition Slip
to
Recommender
Store in
charge
Recommend Recomm
ender
Send slip to
store in charge
Recomm
ender
Verifying
Requisition Slip
Send
Requisition Slip
to Director
Store in
charge
Verify Director
Send Slip to
Store in charge
Director
Updating
Register Book
Store in
charge
Notification Send
Notification
User,
Store in
charge,
Director,
Recomm
ender
Receive
Notification
User,
Store in

38. 27
charge,
Director,
Recomm
ender
2.3.3 Use Case Description
We shall elaborate use case scenario to use case diagram, description, activity
diagram & swim-lane diagram. Here is the use case diagram of level-0 for IMS:

39. 28
Figure 4.1 - Use Case Diagram of IMS
Level 0: Inventory Management System
This is the elaborated form of level-0 for IMS:

40. 29
Figure 4.2 - Use Case Diagram of IMS
Level 1.1 Authentication
We can further section Authentication system into three sub-systems:

41. 30
Figure 4.3 - Use Case Diagram of Authentication
Level 1.1.1 Use Case: Sign Up
Primary Actor:
1. User
2. Store in charge
3. Director
4. Recommender
Goal in Context: To register the user

42. 31
Precondition: Must have to provide adequate information.
Scenario:
1. Visit the login page.
2. Click on ‘Sign Up’ button.
3. Input necessary information such as name, contact no, email, designation etc.
4. Proceed to the next activity.
Exceptions:
1. Invalid information

43. 32
Figure 4.4- Activity Diagram of Sign Up
Figure 4.5- Swim lane Diagram of Sign Up
Level 1.1.2 Use Case: Sign In
Primary Actor:
1. User
2. Store in charge
3. Director
4. Recommender

44. 33
Goal in Context: To enter the system.
Precondition: Must have an account on this system.
Scenario:
1. Visit the login page.
2. Click on ‘Sign In’ button.
3. Input username & password.
4. Proceed to the next activity.
Exceptions:
1. Unrecognized username.
2. Wrong password.

45. 34
3. User is blocked.
Figure 4.6 - Activity Diagram of Sign In

46. 35
Figure 4.7 - Swim lane Diagram of Sign in
Level 1.1.3 Use Case: Sign Out
Primary Actor:
1. User
2. Store in charge
3. Director
4. Recommender
Goal in Context: To exit from the system.
Scenario:

47. 36
1. Click the ‘Sign Out’ button.
2. Get out of the system.
Exception:
1. System error.
2. Network error.
Precondition: Must be logged in.
Figure 4.8 - Activity Diagram of Sign Out

48. 37
Activity Diagram of Sign Out reflects the Swim lane as all the actors will show the
same activity and the there is no interaction (in the context of this activity) among
the actors.
Level 1.1.4 Use Case: Edit Profile
Primary Actor:
1. User
2. Store in charge
3. Director
4. Recommender
Goal in Context: To update one's information.
Precondition: Must be logged in.
Scenario:
1. Sigh in to the system.
2. Click ‘Edit Profile’ button.
3. Change information.
4. Save changes.
Exceptions:
1. Function not configured for the system.
2. Unable to update.
3. Null information.

49. 38
Figure 4.9 - Activity Diagram of Edit Profile

50. 39
Activity Diagram of Edit Profile reflects the Swim lane as all the actors will
show the same activity and the there is no interaction (in the context of this
activity) among the actors.
Level 1.2 Use Case: Creating Register Book
Primary Actor:
1. Store in charge
Goal in Context: To create a book to preserve all information about inventory
Precondition: New register book will be created if inventories come from a new
sector.
Scenario:
1. Click Create Register Book button.
2. Proceed to the next activity.
Exceptions:
1. Old sector cannot create new register book.

51. 40
Figure 4.12- Activity Diagram of Creating Register Book

52. 41
Figure 4.13 - Swim Diagram of Creating Register Book

53. 42
Level 1.3 Use Case: Receiving Inventories
Primary Actor:
1. Store in charge
Goal in Context: To preserve all information in about received inventory.
Precondition: Register Book have to be created previously
Scenario:
1. Go to register book
2. Enter information
3. Save
4. Proceed to the next activity.
Exceptions:
1. Invalid Information
2. Null Information

54. 43
Figure 4.14 - Activity Diagram of Receiving Inventories

55. 44
Figure 4.15 - Swim lane Diagram of Receiving Inventories

56. 45
Level 1.4 Requisition Subsystem
We can further section Requisition system into three sub-systems:
Figure 4.16- Use Case Diagram of Requisition System

57. 46
Level 1.4.1 Creating Requisition Slip
We can further section Creating Requisition Slip system into three sub-systems:
Figure 4.17 - Creating Requisition Slip

58. 47
Level 1.4.1.1 Use Case: Select Requisition Type
Primary Actor:
1. User
Goal in Context: To select the purpose of requisition slip (taking or buying
inventories).
Precondition: User must be logged in
Scenario:
1. Click requisition system.
2. Check the availability of inventories in store.
3. If available, slip is for taking otherwise for buying inventories.
4. Proceed to the next activity.
Exceptions: Not applicable

59. 48
Figure 4.18- Activity Diagram of Select Requisition Type

60. 49
Figure 4.19- Swim lane Diagram of Select Requisition Type

61. 50
Level 1.4.1.2 Use Case: Fill Up Requisition Slip
Primary Actor:
1. User
Goal in Context: To give the necessary inventories’ information.
Precondition: User have to select the requisition type.
Scenario:
1. Go to requisition slip interface.
2. Give item names
3. Give quantity
4. Give total amount of inventories.
5. Proceed to the next activity.
Exceptions:
Not applicable

62. 51
Figure 4.20- Activity Diagram of Fill up Requisition Slip

63. 52
Figure 4.21- Swim lane Diagram of Fill up Requisition Slip

64. 53
Level 1.4.1.3 Use Case: Send to Store in charge
Primary Actor: User
Goal in Context: To send the filled requisition slip to store in charge.
Precondition: User have to fill up the requisition slip’s empty field.
Scenario:
1. Click send to store in charge button
2. Proceed to the next activity.
Exceptions:
Not applicable
Figure 4.22- Activity Diagram of Send to Store in Charge

65. 54
Figure 4.23- Swim lane Diagram of Send to Store in charge

66. 55
Level 1.4.2 Recommendation
We can further section Requisition system into three sub-systems:
Figure 4.24 – Recommendation

67. 56
Level 1.4.2.1 Use Case: Send requisition slip to recommender
Primary Actor:
1. Store in charge
Goal in Context: To give the requisition slip to recommender to recommend
Precondition: Recommender will be predefined.
Scenario:
1. Select the recommender from the list.
2. Click send to recommender button
3. Proceed to the next activity.
Exceptions: Not applicable

68. 57
Figure 4.25- Activity Diagram of Send Requisition Slip to Recommender
Level 1.4.2.2 Use Case: Recommend

69. 58
Primary Actor:
1. Recommender
Goal in Context: To recommend the requisition slip
Precondition: Information in requisition slip have to be valid
Scenario:
1. Get notification for recommending.
2. View the requisition slip.
3. Click recommend button.
4. Proceed to the next activity.
Exceptions: Recommender can disagree to recommend.
Figure 4.27- Activity Diagram of Recommend

70. 59
Figure 4.28- Swim lane of Recommendation

71. 60
Level 1.4.2.3 Use Case: Send Requisition Slip to Store in charge
Primary Actor:
1. Recommender
Goal in Context: To return the requisition slip
Precondition: Requisition slip has to be viewed by recommender.
Scenario:
1. Get notification about recommendation status
2. View the requisition slip.
3. Proceed to the next activity.
Exceptions: Not applicable
Figure 4.29- Activity Diagram of Send Requisition Slip to Store in charge

72. 61
Level 1.4.3 Verifying Requisition Slip
We can further section creating requisition slip system into three sub-systems:
Figure 4.31- Verify Requisition Slip

73. 62
Level 1.4.3.1 Use Case: Send Requisition slip to Director
Primary Actor:
1. Store in charge
Goal in Context: To give the requisition slip to director to verify
Precondition: Director will pre-defined
Scenario:
1. Click send to director button
2. Proceed to the next activity.
Exceptions:
Not applicable

74. 63
Figure 4.32- Activity Diagram of Send Requisition Slip to Director

75. 64
Figure 4.33- Swim lane Diagram of Send Requisition Slip to Director

76. 65
Level 1.4.3.2 Use Case: Verify
Primary Actor:
1. Director
Goal in Context: To verify the requisition slip
Precondition: Requisition slip can arrive with or without recommendation
Scenario:
1. Get notification for verifying.
2. View the requisition slip.
3. Click verify button.
4. Proceed to the next activity.
Exceptions:
Director has authority to disagree to verify.
Figure 4.34- Activity Diagram of Verify

77. 66
Figure 4.35- Swim lane Diagram of Verify

78. 67
Level 1.4.3.3 Use Case: Send slip to store in charge
Primary Actor:
1. Director
Goal in Context: To return the requisition slip to store in charge
Precondition: Requisition slip has to be viewed by director.
Scenario:
1. Get notification about verification status
2. View the requisition slip.
3. Proceed to the next activity.
Exceptions:
Not applicable
Figure 4.36- Activity Diagram of Send Slip to Store in charge

79. 68
Figure 4.37- Swim lane Diagram of Send Slip to Store in charge

80. 69
Level 1.4.1 Updating Register Book
Primary Actor:
1. Director
Goal in Context: To record the information about applicant and verified
requisition slip
Precondition: Requisition slip has to be verified by director.
Scenario:
1. Get notification about verification status
2. View the requisition slip.
3. Give information of fields
4. Save
Exceptions: Null Information

81. 70
Figure 4.38- Activity Diagram of Updating Register book

82. 71
Figure 4.39- Swim lane of Updating Register book

83. 72
Level 1.5 Notification
We can further divide notification sub-system into the following sub-system:
Figure 4.40 – Notification

84. 73
Level 1.5.1 Use Case: Send Notification
Primary Actor:
1. Director
2. Store in charge
3. User
4. Recommender
Goal in Context: To communicate with other user.
Precondition: User has to be logged in
Scenario:
1. Click notification system
2. Write notification
3. Send notification
4. Proceed to the next activity.
Exceptions: Not applicable
Figure 4.41 - Activity Diagram of Send Notification

85. 74
Figure 4.42 - Swim lane Diagram of Send Notification

86. 75
Level 1.5.2 Use Case: Receive Notification
Primary Actor:
5. Director
6. Store in charge
7. User
8. Recommender
Goal in Context: To communicate with other user.
Precondition: User has to be logged in
Scenario:
1. Click view notification
2. Proceed to the next activity.
Exceptions:
Not applicable

87. 76
Figure 4.43 - Activity Diagram of Receive Notification

88. 77
Level 1.6 Use Case: Creating Report
Primary Actor:
1. Store in charge
Goal in Context: To create report and print it
Precondition: Store in charge must be logged in.
Scenario:
1. Click on ‘Create Report’ button.
2. Select field.
3. Click in ’OK’ Button
4. Proceed to the next activity.
Exceptions:
1. Null information

89. 78
Figure 4.44- Activity Diagram of Creating Report

90. 79
2.4 Data Model
2.4.1 Introduction
If software requirements include the need to create, extend or interface with a
database or if complex data structures must be constructed and manipulated, the
software team may choose to create a data model as part of overall requirements
modeling.
2.4.2 Data Objects Selection
A data object is a representation of composite information that must be
understood by software. A data object can be an external entity, a thing, an
occurrence or event, a role, an organizational unit, a place or a structure. Data
attributes define the properties of a data object. Here is a table of potential data
objects and attributes.
Noun Attributes Description Remark
Institute of
Information
Technology
An institute, out of
scope
Rejected
University of
Dhaka
An institute, out of
scope
Rejected
Inventory
Management
System
Represents the
whole system
Rejected

91. 80
Inventory inventory name,
amount, inventory
description
Potential data
object
Accepted
Store room Out of scope Rejected
Store-in-charge first name, last name,
username, password,
job position, system
position, sex, photo,
email, contact no.,
signature
Potential data
object
Rejected
(alias of
user)
Sector sector name, sector id,
sector description
Potential data
object
Accepted
Account Alias of register
book
Rejected
Register book name of articles,
Balance (received),
date, Name and date
of voucher for
purchase (received),
No. of articles, total,
purpose of which
issued (issued), No. of
articles, balance,
where located,
acknowledgement
signature of the
officer, remarks
Potential data
object
Accepted
Name of articles Attribute of register
book
Rejected
Balance (received) Attribute of register
book
Rejected
Date Attribute of register
book
Rejected
No. and date of
voucher for
purchase
(received)
Attribute of register
book
Rejected

92. 81
No. of articles Attribute of register
book
Rejected
Total Attribute of register
book
Rejected
Purpose of which
issued (issued)
Attribute of register
book
Rejected
No. of articles
(issued)
Attribute of register
book
Rejected
Balance Attribute of register
book
Rejected
Where located Attribute of register
book
Rejected
Acknowledgement
signature of the
officer
Attribute of register
book
Rejected
Remarks Attribute of register
book
Rejected
Document
(received)
document id, voucher
(file)
Potential data
object
Accepted
Teacher first name, last name,
username, password,
job position, system
position, sex, photo,
email, contact no.,
signature
Potential data
object
Rejected
(alias of
user)
Staff first name, last name,
username, password,
job position, system
position, sex, photo,
email, contact no.,
signature
Potential data
object
Rejected
(alias of
user)
User first name, last name,
username, password,
job position, system
position, sex, photo,
Potential data
object
Accepted

93. 82
email, contact no.,
signature
Requisition slip serial number,
requisition date,
applicant name,
position, address,
purpose, item
description, quantity,
total item,
recommender’s
signature, applicant’s
signature, director’s
signature
Potential data
object
Accepted
Serial number Attribute of
requisition slip
Rejected
Date Attribute of
requisition slip
Rejected
Applicant name Attribute of
requisition slip
Rejected
Position Attribute of user Rejected
Address Attribute of user Rejected
Purpose Attribute of
requisition slip
Rejected
Item description Attribute of item Rejected
Quantity Attribute of
requisition slip
Rejected
Total item Attribute of
requisition slip
Rejected
Recommender’s
signature
Alias of signature Rejected
Applicant’s
signature
Alias of signature Rejected
Director’s
signature
Alias of signature Rejected

94. 83
Item item name, item id,
item description,
amount
Potential data
object
Accepted
Notification notification id, sender,
receiver, notification
date
Potential data
object
Accepted
Report report id, sector name,
report title, report
date, report file
Potential data
object
Accepted
Now we finalize the data objects and attributes in the following table.
Data object Attribute Remark
Inventory inventory name, inventory
description, inventory picture
Sector sector name, sector id, sector
description
Left page sector id, page id, inventory
name, receiving date,
receiving serial, voucher date,
voucher id, previous balance,
no. of receiving articles, total
balance
Derived from Register
book
Right page sector id, page id, taking date,
current balance, where
located, applicant signature,
taking serial, requisition serial
number
Derived from Register
book
Voucher voucher id, voucher file Voucher represents
Document (received)

95. 84
User first name, last name,
username, password, job
position, system position, sex,
photo, email, contact no.,
signature
Requisition slip requisition serial number,
requisition date, username,
issuing purpose, issuing
quantity, applicant name,
item description, item id,
recommender’s signature,
applicant’s signature,
director’s signature
Item item name, item id, item
description
Notification notification id, sender,
receiver, notification date
Report report id, sector id, report
title, report date, report file
2.4.3 Data Objects and Attributes:
A brief representation of the attributes of the objects are as follows.
Inventory: inventoryName + inventoryDescription + inventoryPicture+ amount
Sector: sectorName + sectorId + sectorDescription

96. 85
Left page: sectorId + pageId + inventoryName + receivingDate + receivingSerial +
voucherDate + voucherId + previousBalance + noOfReceivingArticles +
totalBalance
Right page: sectorId + pageId + takingDate + currentBalance + whereLocated +
applicantSignature + takingSerial + requisitionSerialNumber
Voucher: voucherId + voucherFile
User: firstName + lastName + username + password + jobPosition +
systemPosition + sex + photo + email + contactNo + signature
Requisition slip: requisitionSerialNumber + requisitionDate + username +
issuingPurpose + issuingQuantity + applicantName + itemDescription + item1Id +
Item2Id + item3Id+recommenderSignature + applicantSignature +
directorSignature
Item: itemName + itemId + itemDescription
Notification: notificationId + sender + receiver + notificationDate
2.4.4 Relationships between Data Objects
Data objects are connected to one another in different ways. Here are the
relationships between data objects.

97. 86
receiv
es
creates
User Requisition Slip
creates
User Report
sends
creates
User Sector
saves
User Voucher
updates
User Left Page
updates
User Right Page
contains
Inventory Item
User Notification

98. 87
2.4.5 Entity-Relationship Diagram
Entity-Relationship (E-R) Diagram represents the relationships among data
objects. Here data objects are represented by a labeled rectangle and
relationships are indicated with a labeled line. The E-R diagram of our objects is
here.
belongs to
Item Sector
takes information
Requisition Slip Item
belongs to
Left Page Sector
belongs to
Right Page Sector
contains
Left Page Inventory
holds
Left Page Voucher
refers to
Right Page Requisition Slip

99. 88
Figure-ER Diagram of IMS

100. 89
2.4.6 Schema
The schema diagram of Inventory Management System (IMS) is given below:
Inventory
Attributes Data Type
inventoryName varchar(20)
inventoryDescription varchar(100)
inventoryPicture blob
Amount number
Sector
Attributes Data Type
sectorName varchar(20)
sectorId number
sectorDescription varchar(100)
username varchar(20)
Left Page
Attributes Data Type
pageId number
sectorId number
inventoryName varchar(100)
receivingDate date
receivingSerial number
voucherDate date
voucherId int
previousBalance int
noOfReceivingArticles int
totalBalance number
voucherId int

101. 90
Right Page
Attributes Data Type
pageId number
sectorId number
takingDate date
currentBalance int
whereLocated varchar(50)
takingSerial int
requisitionSerialNumber int
Voucher
Attributes Data Type
voucherId number
voucherFile blob
userName varchar(20)
User
Attributes Data Type
firstName varchar(20)
lastName varchar(20)
userName varchar(20)
password number
jobPosition varchar(20)
systemPosition varchar (20)
sex varchar(5)
photo blob
email varchar (20)
contactNo number
signature blob

102. 91
Requisition slip
Attributes Data Type
requisitionSerialNumber number
Item1Id number
Item2Id number
Item3Id number
username varchar(20)
requisitionDate date
issuingPurpose varchar (40)
issuingQuantity int
applicantName varchar(20)
recommenderSignature blob
applicantSignature blob
directorSignature blob
Item
Attributes Data Type
itemId number
itemName varchar(20)
itemDescription varchar(50)
username varchar(20)
sectorId int
inventoryName varchar(20)
Notification
Attributes Data Type
notificationId number
sender varchar(20)
itemDescription varchar(50)
receiver varchar(20)
notificationDate date

103. 92
2.5 Class Based Modeling
2.5.1 Introduction
Class-based modeling represents the objects that the system will manipulate, the
operations that will be applied to the objects to effect the manipulation, relationships
between the objects and the collaborations that occur between the classes that are
defined. The elements of a class-based model include classes and objects, attributes,
operations, class responsibility-collaborator models and collaboration diagrams.
2.5.2 Identifying Analysis Classes
We can begin to identify the analysis classes by examining the usage scenarios.
Classes are determined by identifying each noun or noun phrase and entering it into
a simple table. Analysis classes manifest themselves in one of the following ways:
1. External entities
2. Things
3. Occurrences or events
4. Roles
5. Organizational units
6. Places
7. Structures

104. 93
Noun General Classification Remarks
Institute of Information
Technology
Problem Space
University of Dhaka Problem Space
Inventory Management
System
Problem Space
Inventory 2 Solution Space
Store room Problem Space
Store-in-charge 1, 4 Solution Space
Sector Solution Space
Account Problem Space
Register book 2 Solution Space
Name of articles 2 Solution Space
Balance (received) 2 Solution Space
Date 2 Solution Space
No. and date of voucher for
purchase (received)
2 Solution Space
No. of articles 2 Solution Space
Total 2 Solution Space
Purpose of which issued
(issued)
2 Solution Space
No. of articles (issued) 2 Solution Space
Balance 2 Solution Space
Where located 2 Solution Space
Acknowledgement signature
of the officer
2 Solution Space
Remarks 2 Solution Space
Document (received) 2 Solution Space
Teacher 1, 4 Solution Space
Staff 1, 4 Solution Space
User 1, 4 Solution Space
Requisition slip 2 Solution Space
Serial number 2 Solution Space
Date 2 Solution Space
Applicant name 2 Solution Space
Position 2 Solution Space
Address 2 Solution Space

105. 94
Purpose 2 Solution Space
Item description 2 Solution Space
Quantity 2 Solution Space
Total item 2 Solution Space
Recommender’s signature 2 Solution Space
Applicant’s signature 2 Solution Space
Director’s signature 2 Solution Space
Item 2 Solution Space
Notification 2, 3 Solution Space
Report 2 Solution Space
2.5.3 Selection Characteristics:
Coad and Yourdon suggest six selection characteristics that should be used to
consider each potential class for inclusion in the analysis model:
1. Retained information
2. Needed services
3. Multiple attributes
4. Common attributes
5. Common operations
6. Essential requirements
Potential Class Characteristic
Number That Applies
Remarks
Inventory 1, 3, 4, 5 Rejected
Store-in-charge 1, 2, 3, 4, 5, 6 Rejected
Sector Rejected
Register book 1, 2, 3, 4, 5 Accepted
Name of articles Rejected
Balance (received) Rejected
Date Rejected

106. 95
No. and date of voucher for
purchase (received)
Rejected
No. of articles Rejected
Total Rejected
Purpose of which issued
(issued)
Rejected
No. of articles (issued) Rejected
Balance Rejected
Where located Rejected
Acknowledgement signature
of the officer
Rejected
Remarks Rejected
Document (received) Rejected
Teacher 3, 4, 5 Rejected
Staff 3, 4, 5 Rejected
User 1, 2, 3, 4, 5 Accepted
Requisition slip 1, 2, 3, 4, 5 Accepted
Serial number Rejected
Date Rejected
Applicant name Rejected
Position Rejected
Address Rejected
Purpose Rejected
Item description Rejected
Quantity Rejected
Total item Rejected
Recommender’s signature Rejected
Applicant’s signature Rejected
Director’s signature Rejected
Item 1, 3, 4 Rejected
Notification 1, 2, 3, 4, 5 Accepted
Report 1, 2, 3, 4, 5 Accepted
System 2, 3, 4, 5 Accepted

107. 96
2.5.4 Attribute Selection
Attributes describe a class that has been selected for inclusion in the requirements
model.
Class Attributes Remarks
Register Book sectorName, nameOfArticle,
pageId, receivedBalance,
reveivingDate, voucherName,
voucherDate, numberOfArticle,
totalBalance, receivingSerial,
takingDate, currentBalance,
signature, remarks, takingSerial,
sectorDescription, sectorId,
voucherId, voucher
User Username, firstName, lastName,
password, jobPosition, sex,
photo, email, contactNo,
signature, systemPosition
Requisition Slip requisitionSerialNumber,
requisitionDate, issuingPurpose,
issuingQuantity, itemId,
recommederSignature,
directorSignature,
applicantSignature
Notification notificationId, senderName,
receivingName, notificationDate
System directorName,
storeInChargeName,
recommenderName

108. 97
2.5.5 Defining Methods
Methods define the behavior of an object. To select methods, we make a grammatical
parse in the usage scenario and isolate the verbs.
2.5.5.1 Verb List
Here is the list of verb and verb phrase from the usage scenario.
Verb
Propose IMS Out of scope
Ease No need
Maintain inventory No need
Keep track inventory No need
Store inventory Yes
Purchase inventory Out of scope
Supply inventory Out of scope
Assign store-in-charge Yes
Come inventory Out of scope
Provide inventory Out of scope
Keep in register book No need
Bring to IIT Out of scope
Receive inventory Yes
Preserve document Yes
Need inventory No need
Take inventory Yes
Fill up Requisition Slip Yes
Contain No need
Send Requisition Slip Yes
Check availability Yes

109. 98
Forward Requisition Slip Yes
Approve Requisition Yes
Deliver inventory Out of scope
Update Register Book Yes
Sign on the Register Book Yes
Communicate Yes
2.5.5.2 Selected Methods
Here are the selected methods for the classes. We slightly modified the verbs for
clarity.
Class Methods
Register Book createRegisterBook()
addInventory()
addItem()
updateItem()
saveDocument()
createNewSector()
User signUp()
editProfile()
signIn()
signOut()
retrievePasswordUsername()
Requisition slip createRequisitionSlip()
sendRequisitionSlip()
verifyRequisitionSlip()
reccommendRequisitionSlip()
Notification sendNotification()
receiveNotification()
viewNotification()
System setDirector()
setStoreInCharge()
addRecommender()

110. 99
2.5.6 Class Diagram
A class diagram shows the interaction among the classes. Here is the class diagram
for the classes:

111. 100
2.5.6 Class-Responsibility-Collaborator (CRC) Modeling
Class-responsibility-collaborator (CRC) modeling provides a simple means for
identifying and organizing the classes through class cards. Class card represents a
graphical view of responsibility and collaborator for each class. CRC modeling for
IMS is given below:

112. 101

113. 102
2.6 Flow-Oriented Model
2.6.1 Introduction
Although data flow-oriented modeling is perceived as an outdated technique by
some software engineers, it contains to be one of the most widely used
requirements analysis notations in use today. Although the data flow diagram
(DFD) and related diagrams and information are not a formal part of UML, they can
be used to complement UML diagrams and provide additional insight into system
requirements and flow.
2.6.2 Data Flow Diagram (DFD)
The data flow diagram (DFD) takes an input-process-output view of a system. That
is, data objects flow into the software, are transformed by processing elements,
and resultant data objects flow out of the software. Data objects are represented
by labeled arrows and transformations are represented by circles.

114. 103
Figure 8.1: Level 0 DFD
Figure 8.2: Level 1 DFD

115. 104
Figure 8.3: Level 1.1 DFD (Create Requisition Slip)

116. 105
Figure 8.4: Level 1.2 DFD (Store Inventory)
Figure 8.5: Level 1.3 DFD (Communicate via Notification)

117. 106
2.7 Behavioral Model
2.7.1 Introduction
Behavior modeling is also referred to as State modeling, State machines and State
transition matrix. Behavior modeling is when one thinks of his ideas in terms of
states and transitions. This requires both identifying all of the interesting states of
being that software or its components are likely to be in. And also, at a high level,
abstracting what events are likely to cause software or its components to change
between states of being.
2.7.2 Identifying Events
Here we have identified events from the Usage Scenario and listed their
corresponding initiators & collaborators.
Event Initiator Collaborator
Sign up User System
Sign in User System
Create register book Register book User
Add inventory Register book User
Create requisition slip Register book User
Send requisition slip to
store-in-charge
Requisition slip User
Send requisition slip to
recommender
Requisition slip User
Recommend requisition
slip
Requisition slip User
Send requisition slip to
director
Requisition slip User
Verify requisition slip Requisition slip User

118. 107
Update register book Register book User
Send notification Notification User
Receive notification
View notification history
Notification User
Create report Report Register book, User
View report Report User
Print report Report User
Sign out User System
2.7.3 State Transition Diagram
State Transition Diagram represents active states for each class and the events
(Triggers) that cause changes between these active states. Here we have provided
diagram for each of the class.

119. 108
Figure 8.1: User

120. 109
Figure 8.2: Register Book

121. 110
Figure 8.3: Requisition Slip

122. 111
Figure 8.4: Notification

123. 112
Figure 8.6: System

124. 113
2.7.4 Sequence Diagram
Sequence Diagram indicates how events cause transitions from object to object. It
is actually a representation of how events cause flow from one object to another
as a function of time.
Figure 8.7: Sign Up

125. 114
Figure 8.8: Edit Profile

126. 115
Figure 8.10: Add Inventory

127. 116
Figure 8.11: Create Register Book

128. 117
Figure 8.12: Update Register Book

129. 118
Figure 8.13: Prepare Requisition Slip

130. 119
Figure 8.14: Recommend Requisition Slip

131. 120
Figure 8.15: Verify Requisition Slip

132. 121
Figure 8.16: Send Notification

133. 122
Figure 8.17: Receive Notification

134. 123
Figure 8.20: Set Director

135. 124
Figure 8.21: Set Store in Charge

136. 125
Figure 8.22: Add Recommender

137. 126
Chapter 3
System Design of Inventory Management system
Software design is the process of implementing software solutions to one or more
set of problems. It is the step which every software development process needs to
meet. Designing helps to create a better software and here individual idea comes
into play. In this section we are going to discuss the Inventory Management
Systems designing phase.
3.1 Internal Software Design
Inventory management system software is implemented following the client-server
architecture. Here the client requests for something via web browser then the
server responses on the request. Model-view-controller design pattern is
implemented on the server site to separate the application’s user interface from
the business logic.
Figure 3.1 (MVC Architecture for Web Applications)
(http://www.acis.org.co/fileadmin/mvc_architecture.png)

138. 127
A controller can send commands to the model to update the model's state. It
also sends commands to its associated view to change the view's presentation
of the model.
A model stores data that is retrieved by the controller and displayed in the view.
Whenever there is a change to the data it is updated by the controller.
A view requests information from the model that it uses to generate an output
representation to the user.
3.2 System Structure
A system is an internally organized whole where elements are so intimately
connected that they operate as one in relation to external conditions and other
systems. An element may be defined as the minimal unit performing a definite
function in the whole. The server is implemented on asp.net using the DB first
approach. The code is written on C# and database in SQL database language. Client
side code is written on HTML, CSS and JavaScript language.
3.3 Graphical User Interface (GUI)
GUI of inventory management system is kept as simple as possible. It is simple, user
friendly and flexible.
 Home Screen.
 Log in Screen.
 User screen.
 Store-in-charge screen.
 Director screen.
 Recommendation screen.

139. 128
3.4 Conclusion
Designing is a very important phase of developing software. We have designed the
software to make a robust, user friendly and flexible to meet any changes.

140. 129
Chapter 4
Implementation and Testing
This chapter is going to discuss about the implementation and testing of “Inventory
management system” application. Which developing tools have been used in this
project and how the testing have done will be discussed here in brief.
4.1 Implementation
Implementation is a very important phase for developing software. In this phase
the theoretical work is translated into the practical one. The Software requirement
analysis and specification, planning, designing all reflects on the implementation.
4.1.1 Technologies
All the latest technologies have been used to develop “Inventory management
System”.
4.1.1.1 ASP.NET Framework
ASP.NET is an open-source server side web application framework designed for
web development to produce dynamic web pages. The Inventory Management
System web application is developed on ASP.NET framework.
4.1.1.2 Hyper Text Markup Language (HTML)
Hyper Text Markup Language is a standard markup language used to create web
pages. HTML elements are the basic building block of web pages. HTML5 is used to
develop the application.

141. 130
4.1.1.3 Cascading Style Sheet (CSS)
Cascading Style Sheets (CSS) is a style sheet language used for describing the look
and formatting of a document written in a markup language. The latest CSS version
CSS 3.0 is used in this application.
4.1.2 Implementation Tools
A programming tool or software development tool is a computer program that
software developers use to create, debug, maintain, or otherwise support other
programs and applications. The development tools reduces a lot of time from the
developer side. There are a lot of software development tools nowadays.
Developers have to choose the right development tools to develop his software.
4.1.2.1 Microsoft Visual Studio 2013
Microsoft Visual Studio is an integrated development environment (IDE) from
Microsoft. It is used to develop computer programs as well as web sites, wed
applications and web services. Visual Studio includes a code editor supporting
IntelliSense as well as code refactoring. The software application has been
developed on Visual studio because it is light weight with respect to its ability,
database development is very easy and efficient, supports auto generated codes,
debugging is easy and efficient and finally it is very user friendly.
4.1.2.2 Microsoft SQL Server 2012
Microsoft SQL server is most popular relational database management system
developed by Microsoft. It is a software product used to store and retrieve data
from the database storage. Microsoft SQL server 2012 is used in this application
because of the following facilities:
 User defined server roles.
 Enhanced auditing features.

142. 131
 Distributed replay.
 Colum store indexes.
 Contained database.
4.2 Coding
Coding is what makes it possible to create computer software, apps and websites.
After planning and choosing the right tool we start to write code to make our vision
visible in the real world.
We have followed the layered architecture. We have divided our code in three
layers,
 Presentational layer.
 Business logic layer.
 Data access layer.

143. 132
Figure: 4.1 (3 Layered Architecture)
4.2.1 Data Access Layer
Data access layer is a layer of compute program which provides simplified access
to data stored in persistent storage. This allows the client (or user) modules to be
created with a higher level of abstraction. This kind of model could be implemented
by creating a class of data access methods that directly reference a corresponding
set of database stored procedures.
4.2.2 Business Logic layer
Business logic layer is defined as any application logic layer that is concerned with
the retrieval, processing, transformation, and management of application data;
application of business rules and policies; and ensuring data consistency and
validity.

144. 133
4.2.3 Presentational layer
The presentation layer mainly translates data between the application layer and
the network format. Data can be communicated in different formats via different
sources. Thus, the presentation layer is responsible for integrating all formats into
a standard format for efficient and effective communication.
4.3 Testing
Software testing is an investigation conducted to provide stakeholders with
information about the quality of the product or service under test. Test techniques
include the process of executing a program or application with the intent of
finding software bugs. It involves the execution of a software component or system
component to evaluate one or more properties of interest. In general, these
properties indicate the extent to which the component or system under test:
 Meets the requirements that guided its design and development,
 Responds correctly to all kinds of inputs.
 Performs its functions within an acceptable time.
 Is sufficiently usable.
 Can be installed and run in its intended environments.
 Achieves the general result its stakeholder desire.

145. 134
Figure 4.2 : Software Testing
4.3.1 Test Cases
The test cases show where the test case was conducted and how the problem has
been solved when an error is found in the test.
Test Case 1:
Test 1 is applied on the user interface to find the bugs from the users’ side.
Test procedure Run the application and for every
page test every elements are
working perfectly.
Expected Result GUI works perfectly

146. 135
Actual Result Worked perfectly in most of the
cases.
Comment Button change was not working
perfectly.
Conditional Test Again run the scene
Expected Result Changing process is working
Actual Result Yes, It is working
Table 4.1 (Test case 1)
Test Case 2:
Test case 2 is conducted on the database to find the data related bugs like
data is not stored perfectly in the database, data is not retrieved correctly
from the database etc.
Test procedure Run the application to see that data
retrieving and storing is working
perfectly.
Expected Result Retrieving and storing works
perfectly
Actual Result Worked perfectly in most of the
cases.
Comment Retrieving and storing is not working
perfectly.
Change the code Change the data Retrieving and
storing code.
Expected Result Changing process is working
Actual Result Yes, It is working
Table 4.2 (Test case 2)

147. 136
4.4 Conclusion
In this chapter we have discussed the implementation and testing of the software
application. It is a very important phase of software development. We have tested
very feature in the software and hopeful that this software will meet its quality.

148. 137
Chapter 5
User Manual
5.1 Work flow of Store-in-charge
After login as Inventory manager the following window will appear.
5.1.1 Create Register Book
After clicking create register book the next window will appear.

149. 138
5.1.2 Set recommender and director
The store-in-charge can set users director and recommender.
5.1.2.1 Set Director
The next window describes the set Director process.

150. 139
5.1.2.2 Set Recommender
This window shows how the store-in-charge sets recommender.

151. 140

152. 141
5.1.3 Category window
The inventory category shows here. And after clicking each category the next
window will appears.
5.1.4 All Items window
This is the all items window of a specific category.

153. 142
5.1.5 Notification System
This window will appear if the store-in-charge clicks notification system.
5.1.5.1 Message Queue
If store-in-charge clicks the message queue the all message history will appear as
the following.

154. 143
5.1.5.2 Send notification
If the store-in-charge clicks send notification this window will appear where s/he
can write the message and send notification to any other user.

155. 144

156. 145
5.1.6 Requisition System
This is the requisition system window.
5.1.6.1 Requisition History
This is the requuisition history.

157. 146
5.2 Work flow of recommender
After log in as recommender the user will see this page. Here he can click on
Category, All items, Notification System and Requisition Slip Queue.

158. 147
5.2.1 Category
Described as previous. The category works as previous.
5.2.2 All Items
Described as previous. The all items works as previous.
5.2.3 Notification System
Described as previous. The notification system works as previous.
5.2.4 Requisition System
After clicking the Requisition System user can see history and s/he can create a
requisition slip.

159. 148
5.2.4.1 Requisition History
If s/he clicks on Requisition History the next window will appear where see history
as user or see history as recommender options will come.

160. 149
Then the history window will appear as the following:
5.2.4.2 Create Requisition Slip
After clicking here, the create requisition slip window will apper as previously
described.
Requisition Slip Queue:

161. 150
5.3 Work flow of Director
Here is the work flow of the Director.
All functionality works as described previous.

162. 151
5.4 Work flow of user
This is the user window.
All functionality works as described previous.

163. 152
Chapter 6
Conclusion
6.1 Future Plan
There are some limitations of this software. We have considered all the limitations
and in the future version of it we’ll make it a better one.
 Mobile version: Later we’ll make a mobile version of it.
 Advertisement option: We’ll include the advertisement option.
 Create report: The cerate report feature is not implemented here. We’ll do
it in the future version.
We are pleased after developing the Inventory Management System software. It
gave us a lot of thing which will help us throughout our life. By developing the
software we have learned a lot about how to develop a software, how to gather
and analyze the requirements, the software designing process and finally the
implementation phase. It was really a great challenge for us to develop the
software. By the grace of Almighty Allah and our hard work we have come to our
destination.

164. 153
Appendix
References
1. Pressman, Roger S. Software Engineering: A Practitioner's Approach
(7th ed.). Boston, Mass: McGraw-Hill. ISBN 0-07-285318-2.
2. Ralph, Paul (2012). "The Illusion of Requirements in
Software Development".
3. Somerville, I. Software Engineering, 7th ed. Harlow,
UK: Addison Wesley, 2006
4. http://en.wikipedia.org/wiki/Database_design
5. http://en.wikipedia.org/wiki/Inventory_management_software
6. http://en.wikipedia.org/wiki/Inventory_control_system
7.http://www.demandsolutions.com/requirements-planning-inventory-
planning-software.html