Online Inventory Management System SRS

Online Inventory Management System
PARVEZ MOHAMMAD SHARIAR 朴维
ID – 1911562106
CLASS -19lc 软工
Project Source Code
https://github.com/Piaowei/Online-Inventory-Management-System
2022
Submitted to: 紫气东来

Contents
REVISION HISTORY...............................................ERROR! BOOKMARK NOT DEFINED.
DOCUMENT APPROVAL.......................................ERROR! BOOKMARK NOT DEFINED.
1. INTRODUCTION.......................................................................................................................1
1.1 PURPOSE 1
1.2 SCOPE 1
1.3 GLOSSARY 2
1.4 REFERENCES 39
2. STAKEHOLDERS......................................................................................................................3
2.1 QUESTIONERS 3
2.2 STAKEHOLDER’S POINT OF VIEW 4
2.3 COLLABORATION 4
3. GENERAL DESCRIPTION........................................................................................................5
3.1 PRODUCT PERSPECTIVE 5
3.2 CURRENT SYSTEM ANALYSIS 6
3.3 PRODUCT FUNCTIONS 7
3.4 POTENTIAL USER OF THE OF THE SYSTEM 7
3.5 USER CHARACTERISTICS 8
3.6 ASSUMPTIONS AND DEPENDENCIES 8
4. REQUIREMENT ANALYSIS....................................................................................................9
4.1 EXTERNAL INTERFACE REQUIREMENTS 9
4.1.1 User Interfaces 9
4.1.2 Hardware Interfaces 9
4.1.3 Software Interfaces 9
4.1.4 Communications Interfaces 9
4.2 FUNCTIONAL REQUIREMENTS 10
4.2.1 General Functional Requirements 10
4.2.2 Functional Requirements for Production Controller 10
4.2.3 Functional Requirements for Production Supervisor 11
4.2.4 Functional Requirements for Administrator 11
4.2.5 Quality Function Deployment 11
4.3 NON-FUNCTIONAL REQUIREMENTS 14
4.3.1 Performance 14
4.3.2 Releability 14
4.3.3 Availability 14
4.3.4 Security 14
4.3.5 Maintainability 15
4.3.6 Portability 15
4.3.7 Operational Requirement 15
4.3.8 Design Constraints 15
5. ONLINE INVENTOPRY APPILICATION.............................................................................16
5.2 DASHBOARD 17
5.3 INVENTORY ITEMS 18
5.4 ADMIN MANAGEMEN 19
5.5 TRANSACTION 20
Software Requirements Specification Page i

6. ANALYSIS MODELS..............................................................................................................21
6.1 SCENARIO BASED MODEL 21
6.1.1 Use Case Diagram 21
6.1.2 Activity Diagram 18
6.1.3 Swim Lane Diagram 19
6.2 FLOW MODEL 20
6.2.1 Data flow model (level 0) 20
6.3CLASS MODEL 22
6.3.1 Class Diagram 22
6.3.2 CRC Diagram 23
6.6 BEHAVIORAL MODEL 24
6.4.1 State Representation Diagram 24
6.4.2 Sequence Diagram 25
6.4.3 Collaboration Diagram 26
7.PROJECT MANAGEMENT PLANNING................................................................................26
6.4.1 Work Breakdown Structure and gantt Chart 24
6.4.1 Responsibility Mattrix 24
6.4.1 Responsibility Mattrix 24
8. SOURCE CODE
List of Figure
Figure 1- Current System 6
Figure 2- Use Case Diagram 17
Figure 3- Activity Diagram 18
Figure 4- Swim Lane Diagram 19
Figure 5- Data Flow Diagram (Level 0) 20
Figure 7- Class Diagram 22
Figure 8- CRC Diagram 23
Figure 9- State Representation Diagram 24
Figure 10- Sequence Diagram 25
Figure 11- Collaboration Diagram 26
Software Requirements Specification Page ii

1. Introduction
In software industry requirement engineering is one of the most important parts of software
engineering process, which one gives us the proper scenarios what the customers want, analyzing
their needs and checking the feasibility what they need, negotiating a reasonable solution etc. In
software industries, a software project begins when a business need is identified. So the first step
is we need to understand the customer needs. Figure out a rough feasibility analysis, not only the
customer’s need but also with the people who are apparently involved with the introducing
system. In this phase after interacting with our client “Sunrise Fashion Ltd.”, we get some
requirements for an inventory management solution.
This paper will be more easeful after communicating with our client with their more specific
requirements. At the same time, in this paper we will focus on Inventory management module.
Again this paper is a partial submission; more detail will be included as per communicating with
the entire stakeholder’s.
1.1 Purpose
The purpose of this document is to present a detailed description of the Online Inventory
Management System. It will explain the purpose and features of the system, the interfaces of the
system, what the system will do, the constraints under which it must operate and how the system
will react to external stimuli.
In this document we will try introduce our stakeholders along with their respective viewpoints,
describe the existing problem, combining those various view points, balancing those to reach an
ultimate “theoretical” solution of the identified problems, generating graphical reviews through
unified modeling language (UML) to formulate the problems and the proposed solution, the
project scope and the project schedule. Next we present the solution including system analysis,
the deviation between final and initial design, the function of our Inventory management system
and testing plan. Finally we evaluate our work on different aspects, present areas of improvement
and conclusion.
1.2 Scope
The outcome of the project would be automated inventory management service .The software
will have all common features and functionalities along with some other special facilities.
To provide user efficient working environment.

User friendly interface for the target stakeholders.
Proper monitoring facility for the authority.
Easy maintenance and administration.

Ensure high level of security.
This system will help in tracking records so that past records can be verified through them and
one can make decisions based on the past records. This system will complete the work in a
very less time resulting in less time consumption and high level of efficiency.
1.3 Glossary
Key Terms Definition
RMG Ready Made Garments
Inventory Inventory means a list compiled for some formal purpose
Production Who guide and supervise production work.

Controller
QC Quality Control
IIS Internet Information System
SRS Software Requirement Specification
DFD Data Flow Diagram
PQ Production Controller
1.5 Overview
The next chapter is identifying stakeholders. In this chapter gives an over view who are directly
or indirectly depend on the developing system and what is their point of view.
The next chapter, the General Description section, of this document gives an overview of the
functionality of the product. It describes the informal requirements and is used to establish a
context for the technical requirements specification in the next chapter.
The Forth chapter, Requirements Specification section, of this document is written primarily for
the developers and describes in technical terms the details of the functionality of the product.
Software Engineering Project Report Page i

Life Cycle of the project

The fifth chapter, Analysis model section. In this section of this document there are some model
diagrams. List of all these analysis models used in developing specific requirements .
All the sections of the document describe the same software product in its entirety,
2. Stakeholders
The stakeholders of the software project are those people or positions who are directly or
indirectly affected or effected by the project. The stakeholders and users who are most
immediately involved in an Inventory management system can be divided in to four groups, they
are:
Executives and upper management.

Production Controller.
Production supervisor.
The root level workers.
System developers.
2.1 Questioners
1. How the processes work?

2. Who are the primary and secondary actors of the whole process all through?
3. Who will be the vital actors in the required system?
4. What is the usual working procedure for an order?
Software Engineering Project Report Page ii

5. What are the major flaws that forced you to automated management solution?
6. Will it be more specific in terms of some major flaws you want us to solve?
7. How will you appreciate the functional facilities as an administrator of the proposed
system?
8. Who are the people you want to directly to interact with the system and what should be
their domain?
9. What event starts the use case?
10. How does the use case end?
11. Are there any optional situations for the use case?
12. How the processes will work, if the system will become automated?
2.2 Stakeholders view point
Different Stakeholders achieve different benefits form a software system. Consequently each of
them has a different point of view. So we have to recognize the requirements from multiple view
point. For this Inventory management system point of view of stakeholders is:
 Executives and upper management beholds the people who are concerned with company
management and company’s financial states. They always deal with the profitability and
increasing production unit.
 Production controller is the people who supervise a part of a production unit.

They will interact with our system to input the data of their subordinate workers.
 The production supervisors are the people who act as the subordinates of the production
controllers, and they must have the real interactions with the root operation. This is not
necessary that every supervisor will have distinguished areas to work with; there can be
more than one supervisor to supervise a single activity, when it’s a larger one.
The supervisors are responsible to check the given input and the outcomes they
managed to produce.
 One of the indirect stakeholders of our proposed system is the root level workers of
RMG sector, who use to do the primary level jobs of cutting, printing, and combing all
the parts together, or any other jobs for example. As because of our limitation of
resources, all the workers won’t use our system frequently.
Software Engineering Project Report Page iii

2.3 Collaboration
As information from multiple viewpoints is collected, emerging requirements may be

inconsistent or may conflict with one another. So considering the scope of feasibility, we have
collaborated the following list of requirements from multiple viewpoints.
The extracted ideas gathered from the inventory department are:
 Online status of item quantity in terms of on-hand, on-hand available, reserved,

ordered, to order, rejected, defective and rework able quantities.
 Complete excise functionality and generation of excise registers.
 Quality Control based on QC parameters.
 Physical verification of stock.
 Purchasing and subcontracting.
 Accounting – inventory synchronization.
 Update delay notification.
 Keep Track of partial Production.
 All Financial transactions related to production.
.
The next steps of this analysis are analyzing credibility and go/ no- go decision making.
For these, this team needs more data to be analyzed and communicating with the client. We hope
that we will be able to submit the full Functioning paper within a short time.
3. General Description
3.1 Product Perspective
In this modern world of commercialization, garments business has been established as one of the
flourishing in Bangladesh. It has been one of the most flourishing export sectors for our country,
as we have told in background. Now, our project is concerned with this sector. This is a huge
field to cover, as hundreds of manageable aspects can be found to maintain the highest
productivity of textile manufacturing. We choose the inventory management as our preferred
field to work.
To instantiate, this can be specified as a b2b system, from producers to abroad or home dealers
through some intermediate business nodes. The important deals that our RMG sector are mostly
Software Engineering Project Report Page iv

from abroad interests, as stated above. And our goal would be facilitate this whole process, from
collecting raw materials to the finished product shipment.
Unlike the old days, RMG sector of Bangladesh has been implementing a variety of management
software, in order to enhance the productivity, and to satisfy the customers’ needs. As these deals
are very sensitive to handle, and there are a lot of variables that must be maintained, the need of
online interaction between the buyer and the seller, or even seller to seller, is a must, and can
play a dramatic influence on these deals.
The existing systems have been using not for so long, and the maturity level of software industry
in our country is still very low. So, the systems which are being used in recent days in the
garments industry do have a lot of bugs, functional dependencies and design
The thing is missing all through and which we have been planning to introduce in these kind of
usual management system, is online interface to control the system. Internet has been a pivotal
determiner in every aspects life.
At the same time, there are technologies being used to manage payroll, appointments, inventory,
and in many other purposes. But as our major concerns will be inventory oriented, we will focus
the most on that.
3.2 Current System Analysis
Figure 1: Current System.
The given diagram is a scenario of current system. In the present system, when the administrator
sealed the production order then the people related to the production, specially
PQ ,administrator’s make the total production planning, and according to the plan the make a
check sheet. According to the production planning total production work is divided in to partial
Software Engineering Project Report Page v

productions. These partial productions are the part of total production. Combining this entire
partial production element total production take place.
But the fact is that in each stage of this partial production face production loses because of
manual updating system. They cannot follow the check sheet properly. So they cannot deliver
their shipment with in due date.
3.3 Product Functions

Inventory Management System must be designed to meet the dictates of the marketplace and
support the company's strategic plan. Along with the inventory system Garment industries need
some more special attributes. The Software’s for Garment are specially made for managing the
various steps in order processing of garments manufacturing process. This software is modular in
design and is web enabled for remote access as well as intranet usage without the need to install
in every machine.
So the features are,
Web based interface

User based Login - password based authentication for data protection.
Dynamic Modular structure – Each and every section related to a production
has separate menus.
Manage master details of buyer, supplier and vendor.
Job Work tracking.
Raw material tracking.
Shipment tracking.
Product category and product stock information with value.
Reports include purchase, issues, stocks & categories.
Customized package
Notification System in case of any process delay.
Check sheet automation.
These features are primary requirement of our client for this inventory management system. This
feature list will change in terms of client demand
Software Engineering Project Report Page vi

3.4 Potential User of the of the System

There are two groups of users in our system. They are the production controller and the system
maintenance administrators. They have different authorities in our system which is shown as
follows;
 Production Controller: They are the Controller of the production in each and every
section related to total production. They can insert the detail product information which is
completed. Besides, they are able to view order sheet and sample sheet to keep their
production accurate. But their authentication domain is limited between their field, which
can be exemplified as the production controller who is in charge of cutting, will not have
the access to the information about payroll or customers.
 Administrator: They are authorized staffs to control the system. They are assigned with
different level of authority to control different parts of the system like inventory and
administrators. In addition, administrators are responsible to maintain database.
3.5 User Characteristics

The users of the software are classified into two categories – Registered user and unregistered
user.
Both users will be able to visit the homepage of the website but only the registered user is
allowed to give input in the system. To work through the system one user should go through
some fixed steps-
First of all the user should be registered.

The separate production module will be presented to the user as a catalog
for viewing.
The user can browse through the categories to choose the module they
desire.
The user can input partially complete production quantity of the total
production.
Finally the product will be delivered within a fixed and trusted time period
to the next production module.
And the process will continue until the shipment is completed
3.6 Assumptions and Dependencies

After completing our study about inventory and inventory management system, we thought that,
our Inventory management software will be ideal one in terms of garments industries of our
country. According to our view that inventory system will Contain module like:
Information of different products category
Available stock
Price of different items
transaction details
One can also extract any reports relating to purchase and Sale.
Software Engineering Project Report Page vii

The inventory management application will have all the categories,

Subcategories, items, Stock details and reports.
The administrator of this inventory system will have right to create product, add items delete
items etc. The application will provide all information of the products. The category will be
tagged with subcategory. Again the subcategories are tagged with different items in the
respective category and rate of the item. Each item will have a specific bar code. The rates will
be tagged to the bar code.
Using these functions the user can:

Add items to inventory
Edit items in inventory
Add an action for an item
The application will also help to generate reports to get latest update on
Master Entry
Purchase order entry
Receive entry
Delivery entry
Report
This inventory system also has some dependencies like

 If data’s are inserted it cannot be deleted except administrator
 User can insert a data but can’t delete
 If data’s are not inserted, user cannot view report.
4. Requirement Analysis
Requirement Analysis presents the requirement specification, software and hardware
requirements for both system developers and system users, process model and data model. In this
section we specify the External Interface Requirements, functional and nonfunctional
requirements of the system.
4.1 External Interface Requirements
4.1.1 User Interfaces

User interface is one of the most important elements in any software. Most of the software’s are
used by non- technical persons. So they always seek of user friendly environment in their
Software Engineering Project Report Page viii

system. And the user interface makes the system more familiar to its user. For our system we do
not design an user interface yet. But the process is going on.
4.1.2 Hardware Interfaces
In the current version of the software, it will have no special hardware interface with other
external systems. It will run in a general-purpose computer system with general-purpose
hardware and software.
4.1.3 Software Interfaces
The Current version of this system will be built on the following software:
Server:
Internet Information system
MySQL server 2008.
MVC 3.
Client:
JavaScript.
OpenSSL.
JavaScript (synchronous/asynchronous) Enable Browser.
4.1.4 Communications Interfaces
All sorts of communications between server and client programs will be using ADO.NET
(ActiveX Data Objects for .NET) is a set of computer software components that programmers
can use to access data and data services. It is a part of the base class library that is included with
the Microsoft .NET Framework
4.2 Functional Requirements

Functional requirements define the functions that are requested by our stakeholders Different
functions are needed by different users of the system. Different administrators have authority to
maintain the system. The system specifies the authority of the administrator. The administrator
has got control over the database of the system. S/He can make changes to update the total
inventory system, and the update will be carried out dynamically.
4.2.1 General functional requirements:
Garment production is combination of different partial production. To keep track of

those partial production there will some modules in the system those are,
 Sketch Submission: In the garment manufacturing the first step is designing
the sketch for the dresses that have to be prepared. That sketch contains all
sort of information related to the product. So in the time of production work
this sketch is followed very strictly
 Production Pattern: The pattern design is taken for creating the production
patterns according to the sketch design. The production pattern is one which
will be used for huge production of garments. The pattern maker makes the
patterns on standard pattern making paper.
Software Engineering Project Report Page ix

 Spreading: With the help of spreading machines, fabric is stacked on one

another in reaches or lays that may go over 100 ft. Long and hundreds of
plies (fabric pieces) thick.
 Cutting: Cutting the clothes to the desired sizes is a massively important
job in RMG business.
 Sorting: Sorting the inventory to increase the productivity is challenge,
which must be overcome to ensure the best management of the company.
 Sewing: There are sewing stations for sewing different parts of the cut
pieces. In this workplace, there are many operators who perform a single
operation.
 Finishing.
 Packing.
4.2.2 Functional Requirements for Production Controller
Login.
Browse desired modules.
Browse desired supervisor portfolio.
Notify the system about the module requirements.
Input product quantity after compiled.
Distribute requirements between the production supervisors.
Supervise inter-work station combination.
View production details with delivery date.
Browse through different production areas.
Balancing the check sheet.
4.2.3 Functional Requirements for Production Supervisor
Login.
Get update from the controller.
Setting the goal of the group and updating it on the system.
Input the worker-to-worker data.
Supervise own worker group performance.
Notify the dependent working group supervisors through the system.
Software Engineering Project Report Page x

Balancing the group input and output.

Submitting the group balance sheet to the responsible controller.
4.2.4 Functional Requirements for Administrator
Login.
Accessibility to the whole system.
Monitoring the total system as well as the database.
Giving the total goal of a deal as the input.
Clarifying the resources.
Distributing the job segments to the controllers.
Getting update information about the production.
Getting update information about production delay.
Getting update information about operation.
Invoice information collection.
Change settings
4.2.5 Quality Function Deployment
Quality function deployment is a method to transform user demands into design quality, to
deploy the functions forming quality, and to deploy methods for achieving the design quality into
subsystems and component parts, and ultimately to specific elements of the manufacturing
process.
QFD is designed to help planners focus on characteristics of a new or existing product or service
from the viewpoints of market segments, company, or technology-development needs. The
technique yields graphs and matrices.
Software Engineering Project Report Page xi

QFD helps transform customer needs into engineering characteristics for a product or service,
prioritizing each product or service characteristic while simultaneously setting development
targets for product or service.
Quality Function Deployment (QFD) can be categorized by-
Normal Requirements,
Expected Requirements, and
Exciting Requirements.
Here is the list of functional quality of our product,
4.2.5.1 Normal Requirements
Normal requirements are those requirements which stakeholders want to be available in the
System. The normal requirements of this proposed application are given below-
The Inventory System must keep track of all compiled products or resources
records, which is expected to generate and must notify if resources associated
with the production is missing or order is incomplete.
The system must have an option to produce check sheet.
The system will perform authorization of users for security purposes. All the
users as well as the administrator must have to perform this part.
All types of resources and price information related to any production must
have to store in the system.
If any kind of change will occur, there will be an update option in the system,
using that administrator can change the existing information.
Users can browse through different production module.

The system must have the production plan making option.
Every module will have separated record for all the compilations occur.
Limited external accessibility, between companies or between selected
groups.
Limited internal accessibility, one module can be maintained and manipulated
by one person or one group of responsible employees.
Well-structured database to store inventory records.
4.2.5.2 Expected Requirements

Software Engineering Project Report Page xii
Expected requirements are those requirements which stakeholders not mentioned to be available
in the system but he/she expects this will provide by the developer in the system. The expected
requirements for our proposed system are given below-
The system will contain user friendly interface that will be designed in a
manner which implements functionalities that are easily accessible by the
users.
The system must ensure database backups, which are as recent and complete
as possible
Check sheet, production planning, and backup files should be in readable file
format or in crystal reports format.
Order will be issued according to buyer name. This will help authority to deal
with their respected buyer.
4.2.5.3 Exciting Requirements
Exciting requirements are those requirements which stakeholders not actually want but these
requirements have to fulfill to make the system interesting. The exciting requirements for our
proposed system are given below-
Production planning with investment and estimated profit will be calculated
through the system.
Normal users and administrators have to login through different login page
which will ensure that, without administrator no one can change any
information of a production as well as the system.
System has the notifying system for any kind of delay occurs in the given
period. But the system can notify the dependent working group supervisors
if the administrators need them.
Administrators can distribute the job segments to the controllers.
4.3 Non-Functional Requirement

Non-functional Requirements of a system specify the performance, reliability, availability,
security, maintainability, portability of a system. So below there are a short description each of
those non-functional requirements.
Software Engineering Project Report Page xiii

4.3.1 Performance
Our proposed inventory management system will be used in Garment industry. There are lot of
internal and external operation which are inter-related with each other for fruit full production.
So the communication among each end system should be tightly scheduled and the notification
should be sent in timely manner.
4.3.2 Reliability
The production process in the garment industries is a combination of different operations, which
generate lots of data. These data lose can cause high damage to a specific module as well as to
the total process.
4.3.3 Availability
This system will be dedicated to a particular client. So the availability will be restricted of this
system.
4.3.4 Security
This system will deal with huge amount of data. So security is a prime issue of our system. So
the system should be secured from external interfere by providing efficient security to the entire
system.
4.3.5 Maintainability
Software maintenance in software engineering is the modification of a software product after
delivery to correct faults, to improve performance or other attributes. Maintainability of software
is categorized in four classes:
Adaptive – dealing with changes and adapting in the software environment.
Perfective – accommodating with new or changed user requirements which concern
functional enhancements to the software.
Corrective – dealing with errors found and fixing it.
Preventive – concerns activities aiming on increasing software maintainability and
prevent problems in the future.
So to maintain our system we will try to concentrate on this four classes.
4.3.5 Portability
Portability is the degree to which software running on one platform can easily be converted to
run on another. Portability is hard to quantify, because it is hard to predict on what other
platforms the software will be required to run. So to make our system portable we have to use
languages, operating systems and tools that are universally available and standardized.
4.3.7 Operational Requirement
Software Engineering Project Report Page xiv

The system can be viewed by open source Mozilla Firefox.
The system is supported by the IIS(Internet information’s system).
The team used MsSQL database to develop and maintain the database
management systems.
4.3.8 Design Constraints

When the project team is started to design the system, at that time the team always tries to meet
all the requirements of their client properly. But some time client’s make the job difficult for the
team to design the system by raising some last moment requirements. This is considered as main
constraints of designing a system.
Sometime clients do not give the proper information which is needed by the team to design
software, because of company policies. At that situation software project team start their work
without proper overview through the existing system to design new one.
5. ONLINE INVENTOPRY APPILICATION

5.1 Login / Registration
5.2 Dashboard
Software Engineering Project Report Page xv

5.3 Inventory Items
Software Engineering Project Report Page xvi

5.4 Admin Management
5.5 Transaction
Software Engineering Project Report Page xvii

6. Analysis Models
Analysis model is one of the most important parts of SRS. All the models give us clear view of
the developing system. In this section, here is the list of all analysis models used in developing
specific requirements of the current developing system.
Scenario based model:
 Use Case Diagram.

 Activity Diagram.
 Swim lane Diagram.
Flow Model
 Data Flow Diagram.
Class Model:
 Class Diagram.
 CRC Diagram.
Behavioral model:
 State transition Diagram.

 Sequence Diagram.
 Collaboration Diagram.
6.1
Scenario Based Model
6.1.1 Use Case diagram
Software Engineering Project Report Page xviii

In software and systems engineering, a use case is a list of steps, typically defining interactions
between a role or actor and a system, to achieve a goal. The actor can be a human or an external
system.
Initially after analyzing the requirements of our client we notify two potential actors in our
proposed system. But this can change any time when their requirements are modified.
So in this system normal users are production controllers. They can browse through their
production related modules. They can view all the production details, all the partial production
areas related to their production, can create check sheet according to order quantity.
Software Engineering Project Report Page xix

Figure 2: Use Case Diagram
On the other hand admin can change system settings, update operation information, Update
production information etc.
6.1.2 Activity Diagram
Software Engineering Project Report Page xx

Activity diagrams are graphical representations of workflows of stepwise activities and actions
with support for choice, iteration and concurrency. In the Unified Modeling Language, activity
diagrams can be used to describe the business and operational step-by-step workflows of
components in a system. An activity diagram shows the overall flow of control.
Figure 3: Activity Diagram.
If we consider the given activity diagram, it will easier for us to find out step-by step operational
workflows of total system. When the process starts it will allow a user to select his/her own
authentication. If the user logged in as an Administrator, the user has the authority to select
Software Engineering Project Report Page xxi

operation between change settings of the working module and update information of the
production.
On the other hand if the user logged in as a production controller, after valid authentication the
production controller can give input in the system to ensure the partial production of the total
production. In any state of the production if the delay is occurred, production controller can
notify administration about the delay to handle shipment related issues.
6.1.3 Swim Lane Diagram

A swim lane is a visual element used in process flow diagrams, or flowcharts, that visually
distinguishes responsibilities for sub-processes of a business process.
Software Engineering Project Report Page xxii

Figure 4: Swim Lane diagram
This is the swim lane view of our proposed system according to present requirements .System
column shows the entire operational function .and administrator and production controller
column shows the task that they will do using the system
6.2 Flow model

6.2.1 Data flow diagram
A data flow diagram (DFD) is a graphical representation of the "flow" of data through an
information system, modeling its process aspects. Often they are a preliminary step used to
create an overview of the system which can later be elaborated. DFDs can also be used for the
visualization of data processing .
A DFD shows what kinds of data will be input to and output from the system, where the data will
come from and go to, and where the data will be stored. It does not show information about the
timing of processes, or information about whether processes will operate in sequence or in
parallel
Figure 5: Data Flow Diagram (Level 0)
Data flow diagram (level 0):
DFD level 0 , is the representation of the system which can only shows the inputs and outputs of
the system without dealing with any function and file or database issue. In the given figure
Software Engineering Project Report Page xxiii

this is the data flow diagram (Level 0) for our proposed inventory management system. Control
panel and the planning is two input entity which can give data command to the system, all the
inputs will process in the system and the outputs will view in the display panel or as notification.
And the system also can produce check sheet according to given planning.
Data flow diagram (Level 1):
DFD level 1, is the representation of the system which can visualize the relation among the
functions and the file or database with the inputs and outputs. Control panel and planning entity
can give input command to the system, which can process by some functions in this system like
interact with user, configure, and update input, display status. There is a database related with
configure function which one can modify production information. And display status,
notification, check sheet can produce output depend on all the functions which configure inputs.
Software Engineering Project Report Page xxiv

6.3 Class Model

6.3.1Class Diagram
In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of
static structure diagram that describes the structure of a system by showing the system's classes,
their attributes, operations or methods, and the relationships among the classes.
Software Engineering Project Report Page xxv

Figure 7: Class Diagram
In the above exposed diagram ‘Module’ is the parent class which has two child classes
‘Administrator’ and ‘Production Controller’. Order Class deals with all the steps related to order
and maintained by administrator. ‘Store ‘and ‘Shipment’ class maintained by production
controller.
Software Engineering Project Report Page xxvi

6.3.2 Class Responsibility Collaboration Diagram
Figure 8: CRC Diagram
A Class Responsibility Collaborator (CRC) model is a collection of standard index cards that
have been divided into three sections,
Section 1: A class represents a collection of similar objects.
Section 2: A responsibility is something that a class knows or does.
Section 3: A collaborator is another class that a class interacts with.
Software Engineering Project Report Page xxvii

6.4 Behavioral model
6.4.1 State Representation Diagram
Figure 9: State Representation Diagram.
A state diagram is a type of diagram used to describe the behavior of systems. State diagrams
require that the system described is composed of a finite number of states; sometimes, this is
indeed the case, while at other times this is a reasonable abstraction. Many forms of state
diagrams exist, which differ slightly among each other.
In the given figure, this is the state representation diagram for our proposed system. In the given
figure there are four states, first one “reading state” just read the instructions. Second one
“comparing state” compares the given command. When the state compare password, if the
password is invalid, total system will be locked for a while. Or if the password is valid it will
move a step ahead to select operation what the system allow an user.
Software Engineering Project Report Page xxviii

6.4.2 Sequence Diagram
Figure 10: Sequence Diagram
A sequence diagram in a Unified Modeling Language (UML) is a kind of interaction diagram

that shows how processes operate with one another and in what order. It is a construct of our
proposed system’s Sequence Chart. A sequence diagram shows object interactions arranged in
time sequence. It depicts the objects and classes involved in the scenario and the sequence of
Command exchanged between the objects needed to carry out the functionality of the scenario.
Software Engineering Project Report Page xxix

6.4.3 Collaboration Diagram
Figure 11: Collaboration Diagram
Collaboration diagrams belong to a group of UML diagrams called Interaction Diagrams.

Collaboration diagrams, like Sequence Diagrams, show how objects interact over the course of
time. However, instead of showing the sequence of events by the layout on the diagram,
collaboration diagrams show the sequence by numbering the Commands on the diagram. This
makes it easier to show how the objects are linked together, but harder to see the sequence at a
glance.
Software Engineering Project Report Page xxx

Software Engineering Project Report Page xxxi

7 Project Management Planning

The following are the key members of the project team:
1.
Business Analyst
2.
Project Manager
3.
Team Leader
4.
Function Head
5.
Function Executor
7.1 Work Breakdown Structure and Gantt Chart
Software Engineering Project Report Page xxxii

Software Engineering Project Report Page xxxiii

7.2 Responsibility Matrix

P B S P P P F V D C U A B S P P P F V S D C U A B S P P P F V D C U A
M A R B D F D A C A R B D F D & T A C A R B D F D A C
S T & & S T V & S T & &
V C C V C
B P P P P
A
P P
M
T P P P P P P P P P
L
F P P P P P P P P P
H
B
n
R
A
F P P P P
H
V
n
V
F P P P P P P P P P P P P P P P P P
E
B
n
Software Engineering Project Report Page xxxiv

R
A
F P P P P P P
E
I
n
S
F P P P P P P P P P P P P
E
D
N
D
F P P P P P P P P P P
E
V
n
V
F P P P
E
B
n
R
Abbreviations Used:
BA- Business Analyst
SRS- Software requirement specification
PB- Product Backlog
PD- Prototype Development
PFT- Prototype Fine tuning
FD- Final Development
V & V- Validation and Verification
D- Deployment
C & C- Customization and configuration
UA- User Acceptance
AC- Application Conclusion
ST- Stress Testing
Resource Allocation
Resources Used:
1. PM – Project Manager
2. FE-BnRA- Business and Requirement Analysis , Function Executor
Software Engineering Project Report Page xxxv
3. FH-BnRA - Business and Requirement Analysis ,Function Head

4. FE-Dnd – Development and Delivery ,Function Executor
5. TL-Dnd – Team leader, Development and Delivery Executor
6. FE-Vnv – Verification and Validation , Function Executor
7. FH-VnV- Function Head, Validation and Verification
8. FE-InS – Implementation and Support by Function Executor
Analysis
As we can see from the bar graphs few resources are leveled properly
but some are not leveled.
To level the resources we will have to shift the activities but as we can
see from the activity diagram there is no slack in the activities so we
cannot delay the activities without affecting the project time and hence,
resources cannot be leveled. Using a different software model process
could help to level the resources.
7.3 Budgeting and Cost Estimation
The brief budget of project is as follows:-
Software Engineering Project Report Page xxxvi

Analysis
Looking at the over budgeting resource table it is clearly seen

that there is a lot of deviation in the estimated cost and the
actual cost. Financial analysis of potential problems was not
done.
Software Engineering Project Report Page xxxvii

If any person (resource) leaves the project/company then in that

case either a new person is hired or the cost of each resource
increases because in such a case the work load on each
employee will increase. Hiring a new employee would add to
cost and time of the project. Also the employee might have to be
trained and would take time to understand the software in order
to work on it. Analyzing all these factors would lead to better
financial planning.
7.4Scheduling
Software Engineering Project Report Page xxxviii

Activity ID Early Start Early Finish Late Start Late Finish Slack
3 0 2 0 2 0
11 2 5 2 5 0
12 5 7 5 7 0
13 7 10 7 10 0
15 10 16 10 16 0
16 16 19 16 19 0
17 19 31 19 31 0
18 31 35 31 35 0
20 35 37 35 37 0
21 37 39 37 39 0
22 39 41 39 41 0
23 41 42 41 42 0
27 42 45 42 45 0
28 45 47 45 47 0
29 47 49 47 49 0
31 49 55 49 55 0
32 55 58 55 58 0
33 58 65 58 65 0
35 65 69 65 69 0
36 69 72 69 72 0
38 72 73 72 73 0
39 73 74 73 74 0
40 74 75 74 75 0
41 75 76 75 76 0
45 76 77.5 76 77.5 0
46 77.5 79 77.5 79 0
47 79 80 79 80 0
49 80 83 80 83 0
50 83 85 83 85 0
51 85 90 85 90 0
52 90 93 90 93 0
54 93 94 93 94 0
55 94 96 94 96 0
56 96 97 96 97 0
57 97 99 97 99 0
Project Completion Time: 99 Days.
Software Engineering Project Report Page xxxix

8. Project Monitoring and Control

In this project, the project team uses the Tracking Gantt Chart which
allows them to constantly review the project’s status and progress by
linking task initiation and completion to the project schedule.
The schedule is reviewed at the interval of every 15-20 Days.
The progress review is focused on –

 Percentage of work done and work remaining
 Bottlenecks of the remaining tasks
 Resource utilization: Utilization of resources according to
schedule and in favor of all performance, cost and time.
 Resources re-shuffling due to escalation of task: sequence of
tasks maybe changed in the schedule later at a stage due to
changed priorities and therefore resource re-shuffling is needed.
 Possible risks which maybe encountered in the future and their
solutions.
Resource Utilization and resources re-shuffling due to escalation of task

is monitored by resource allocation charts and graphs. By using these
tools, the amount of resources used and available is monitored.
Software Engineering Project Report Page xl

8.1Analysis of Software Project Model

In this project the software development model used
waterfall model with incremental process.
WATERFALL METHODOLOGY APPROACH
Requirement and analysis: Amongst all the requirements of the system to be designed are gotten
in this stage and written in a requirement specification document. In this stage, inquisition on
how the current system is running and the limitations therein was conducted, in order to know
where to start the proposed system.
System Design: The necessity determinations from the first phase are concentrated in this phase
and the system configuration is prepared
Integration and Testing: in this stage, as referenced prior, unit testing will be directed. All the
units created in the execution stage are coordinated into a system subsequent to testing of every
unit. Post integration the whole framework is tried for any issues and faults.
Deployment of system: This will happen after all the previously mentioned stages. When the
functional and non-functional testing is done, the item is sent in the customer environment or
delivered into the market.
Maintenance: After the deployment, there will be a few issues which will come up in the
customer environment. To fix those issues, patches are delivered.
Software Engineering Project Report Page xli

Advantages of the waterfall model:

- It is uncomplicated and undemanding to use.
- Easy to oversee because of the unbending nature of the model – each stage has explicit
expectations and a survey cycle.
- It has clearly characterized stages.
- Procedure and results are all in the order in the archived.
- Well gotten achievements.
Drawbacks of the waterfall model:

- It is not appropriate for the tasks where necessities are at a moderate to high chance of
evolving.
Along these lines, danger and vulnerability are high with this cycle model.
- Integration is done as a huge explosion at the end, which doesn't permit recognizing any
innovative or business bottleneck or difficulties early.
- It is not a decent model for complex and item arranged tasks.
- High measures of danger and vulnerability.
The waterfall methodology will be utilized because from the start of the project, everything goes
with a flow.
Software Engineering Project Report Page xlii

9 .Source Code
9 .Conclusions
The Internet has become a major resource in modern business, thus electronic shopping has
gained significance not only from the entrepreneur’s but also from the customer’s point of view.
To build any web application using ASP.NET we need a programming language such as C#,
VB.NET, J# and so on. C# was the language used to build this application. For the client browser
to connect to the ASP.NET engine we used Microsoft’s Internet Information Services (IIS) as the
Web Server
This project helps in understanding the creation of an interactive web page and the
technologies used to implement it. The building of the project has given me a precise
knowledge about how ASP.NET is used to develop a website, how it connects to the
database to access the data and how the data and web pages are modified to provide the user
with a shopping cart application.
10 .References
www.agilemodeling.com/artifacts/crcModel.html.
http://en.wikipedia.org/wiki/Unified_Modeling_Language
http://en.wikipedia.org/wiki/Requirements_analysis
Software Engineering Project Report Page xliii

http://rfptemplates.technologyevaluation.com/rfp/for/inventory-management-garments.html
http://www.slideshare.net/ahmedhasan/ieee-830-1998-software-requirements-specifications
http://gulnazahmad.hubpages.com/hub/A-Step-by-Step-of-Garment-Manufacturing
Software Engineering Project Report Page xliv

20
021
Contents
1. INTRODUCTION.....................................................................................................................1
1.1 PURPOSE 1
1.2 SCOPE 1
1.3 GLOSSARY 2
1.4 OVERVIEW 3
2. STAKEHOLDERS....................................................................................................................3
2.1 QUESTIONERS 3
2.2 STAKEHOLDER’S POINT OF VIEW 4
2.3 COLLABORATION 4
3. GENERAL DESCRIPTION.....................................................................................................5
3.1 PRODUCT PERSPECTIVE 5
3.2 CURRENT SYSTEM ANALYSIS 6
3.3 PRODUCT FUNCTIONS 7
3.4 POTENTIAL USER OF THE OF THE SYSTEM 7
3.5 USER CHARACTERISTICS 8
3.6 ASSUMPTIONS AND DEPENDENCIES 8
4. REQUIREMENT ANALYSIS.................................................................................................9
4.1 EXTERNAL INTERFACE REQUIREMENTS 9
4.1.1 User Interfaces 9
4.1.2 Hardware Interfaces 9
4.1.3 Software Interfaces 9
4.1.4 Communications Interfaces 9
4.2 FUNCTIONAL REQUIREMENTS 10
4.2.1 General Functional Requirements 10
4.2.2 Functional Requirements for Production Controller 10
4.2.3 Functional Requirements for Production Supervisor 11
4.2.4 Functional Requirements for Administrator 11
4.2.5 Quality Function Deployment 11
4.3 NON-FUNCTIONAL REQUIREMENTS 14
4.3.1 Performance 14
4.3.2 Releability 14
4.3.3 Availability 14
4.3.4 Security 14
4.3.5 Maintainability 15
4.3.6 Portability 15
4.3.7 Operational Requirement 15
4.3.8 Design Constraints 15
5. ANALYSIS MODELS & DESIG...........................................................................................15
5.1 SCENARIO BASED MODEL 16
5.1.1 Use Case Diagram 17
5.1.2 Activity Diagram 18
Software Engineering Project Report Page xlv

5.1.3 Swim Lane Diagram 19

5.2 FLOW MODEL 20
5.3CLASS MODEL
22
5.3.1 Class Diagram 22
5.3.2 CRC Diagram 23
5.6 BEHAVIORAL MODEL 24
5.4.1 State Representation Diagram 24
5.4.2 Sequence Diagram 25
5.4.3 Collaboration Diagram 26
6.PROJECT MANAGEMENT PLANNING………………………………………………...29
6.1 Work Breakdown Structure and gantt Chart 29
6.2 Responsibility Mattrix 30
6.3 Budget and Cost Estimation 32
6.4 Scheduling 35
6.5 Crashing 36
7. PROJECT MONITORING AND METHODOLOGY………………………………………...36
7.1 Analysis of software project model 36
7.2 Waterfall development methodology 37
7.3 Agile development methodology 38
7.4 Approach to chosen methodology/methods 39
7.4.1 waterfall methodology approach 40
7.4.2 agile methodology approach 41
8. IMPLEMENTATION UI AND TESTING ………..………………………………………………42
8.1 overview 42
8.2 main features 46
8.3 implementation problems 46
8.4 overcoming implementation problems 46
8.5 TESTING
8.5.1 Tests plans (for unit testing, integration testing, and system testing) 47
8.5.2 Test suite (for unit testing, integration testing, and system testing) 47
8.5.3 Test traceability matrix (for unit testing, integration testing, and system testing) 47
8.5.4 Test report summary (for unit testing, integration testing, and system testing) 53
8..5.5 Test summary report 54
8.5.6 Error reports and corrections 54
8.6 Source code
57
8.7 Summary
9. CONCLUTION.……………………………………………………………………………..58
10. REFEREENCE…………………………………………………………………………….58
Software Engineering Project Report Page xlvi

List of Figure
Figure 1- Current System 6
Figure 2- Use Case Diagram 17
Figure 3- Activity Diagram 18
Figure 4- Swim Lane Diagram 19
Figure 7- Class Diagram 22
Figure 8- CRC Diagram 23
Figure 9- State Representation Diagram 24
Figure 10- Sequence Diagram 25
Figure 11- Collaboration Diagram 26
Figure 12 LOGIN PAGE 42
Figure 13 DASHBOARD 43
Figure 14 PRODUCT PROFILE 43
Figure 15 STOCK INVENTORY 44
Figure 16 CUSTOMER PROFILE 44
Figure 17 DAILY SALES 45
Figure 18 EXPIRED ITEM 45
Figure 19 ADD ITEM 46
Figure 20 ADMIN LOGIN 49
Figure 21 NEW ITEM ADDED 50
Figure 22 ITEM ADDED TO CART 50
Figure 23 ITEMS IN STOCK 51
Figure 24 NEW STOCK ADDED 52
Figure 25 NEW CUSTOMER ADDED 52
Figure 26 NETBEANS IDE 54
Figure 27 OPEN IAS USING APP 55
Software Engineering Project Report Page xlvii

CHAPTER 1 - Introduction
The project Inventory Management System is a complete web based application An inventory
management system is the combination of technology (hardware and software) and processes
and procedures that oversee the monitoring and maintenance of stocked products, whether
those products are company assets, raw materials and supplies, or finished products ready to
be sent to vendors or end consumers. software industries, a software project begins when a
business need is identified. So the first step is we need to understand the customer needs.
Figure out a rough feasibility analysis, not only the customer’s need but also with the people
who are apparently involved with the introducing system. In this phase after interacting with
our client “Sunrise Fashion Ltd.”, we get some requirements for an inventory management
solution.
This paper will be more easeful after communicating with our client with their more specific
requirements. At the same time, in this paper we will focus on Inventory management
module. Again this paper is a partial submission; more detail will be included as per
communicating with the entire stakeholder’s.
1.1 Purpose
The purpose of this document is to present a detailed description of the Online Inventory
Management System. It will explain the purpose and features of the system, the interfaces of
the system, what the system will do, the constraints under which it must operate and how the
system will react to external stimuli.
In this document we will try introduce our stakeholders along with their respective
viewpoints, describe the existing problem, combining those various view points, balancing
those to reach an ultimate “theoretical” solution of the identified problems, generating
graphical reviews through unified modeling language (UML) to formulate the problems and
the proposed solution, the project scope and the project schedule. Next we present the
solution including system analysis, the deviation between final and initial design, the function
of our Inventory management system and testing plan. Finally we evaluate our work on
different aspects, present areas of improvement and conclusion.
1.2 Scope
The outcome of the project would be automated inventory management service .The software
will have all common features and functionalities along with some other special facilities.
To provide user efficient working environment.

User friendly interface for the target stakeholders.
Proper monitoring facility for the authority.
Easy maintenance and administration.
Software Engineering Project Report Page

Ensure high level of security.
This system will help in tracking records so that past records can be verified through them
and one can make decisions based on the past records. This system will complete the work
in a very less time resulting in less time consumption and high level of efficiency.
1.3 Glossary
Key Terms Definition
RMG Ready Made Garments
Inventory Inventory means a list compiled for some formal purpose
Production Who guide and supervise production work.

Controller
QC Quality Control
IIS Internet Information System
SRS Software Requirement Specification
DFD Data Flow Diagram
PQ Production Controller
1.5 Overview
The next chapter is identifying stakeholders. In this chapter gives an over view who are
directly or indirectly depend on the developing system and what is their point of view.
The next chapter, the General Description section, of this document gives an overview of the
functionality of the product. It describes the informal requirements and is used to establish a
context for the technical requirements specification in the next chapter.
The Forth chapter, Requirements Specification section, of this document is written primarily
for the developers and describes in technical terms the details of the functionality of the
product.

Life Cycle of the project

The fifth chapter, Analysis model section. In this section of this document there are some
model diagrams. List of all these analysis models used in developing specific requirements .
All the sections of the document describe the same software product in its entirety,
CHAPTER 2 - Stakeholders
The stakeholders of the software project are those people or positions who are directly or
indirectly affected or effected by the project. The stakeholders and users who are most
immediately involved in an Inventory management system can be divided in to four groups,
they are:
Executives and upper management.

Production Controller.
Production supervisor.
The root level workers.
System developers.
2.1 Questioners
13. How the processes work?

14. Who are the primary and secondary actors of the whole process all through?
15. Who will be the vital actors in the required system?
16. What is the usual working procedure for an order?
17. What are the major flaws that forced you to automated management solution?
18. Will it be more specific in terms of some major flaws you want us to solve?
19. How will you appreciate the functional facilities as an administrator of the proposed
system?
20. Who are the people you want to directly to interact with the system and what should
be their domain?
21. What event starts the use case?
22. How does the use case end?
23. Are there any optional situations for the use case?
24. How the processes will work, if the system will become automated?
2.2 Stakeholders view point
Different Stakeholders achieve different benefits form a software system. Consequently each
of them has a different point of view. So we have to recognize the requirements from
multiple view point. For this Inventory management system point of view of stakeholders is:
 Executives and upper management beholds the people who are concerned with
company management and company’s financial states. They always deal with the
profitability and increasing production unit.
 Production controller is the people who supervise a part of a production unit.

They will interact with our system to input the data of their subordinate workers.
 The production supervisors are the people who act as the subordinates of the
production controllers, and they must have the real interactions with the root
operation. This is not necessary that every supervisor will have distinguished areas
to work with; there can be more than one supervisor to supervise a single activity,
when it’s a larger one.
The supervisors are responsible to check the given input and the outcomes they
managed to produce.
 One of the indirect stakeholders of our proposed system is the root level workers of
RMG sector, who use to do the primary level jobs of cutting, printing, and combing
all the parts together, or any other jobs for example. As because of our limitation of
resources, all the workers won’t use our system frequently.
2.3 Collaboration

As information from multiple viewpoints is collected, emerging requirements may be

inconsistent or may conflict with one another. So considering the scope of feasibility, we
have collaborated the following list of requirements from multiple viewpoints.
The extracted ideas gathered from the inventory department are:
 Online status of item quantity in terms of on-hand, on-hand available, reserved,

ordered, to order, rejected, defective and rework able quantities.
 Complete excise functionality and generation of excise registers.
 Quality Control based on QC parameters.
 Physical verification of stock.
 Purchasing and subcontracting.
 Accounting – inventory synchronization.
 Update delay notification.
 Keep Track of partial Production.
 All Financial transactions related to production.
.
The next steps of this analysis are analyzing credibility and go/ no- go decision
making. For these, this team needs more data to be analyzed and communicating with the
client. We hope that we will be able to submit the full Functioning paper within a short time.
CHAPTER - 3 General Description

3.1 Product Perspective
In this modern world of commercialization, garments business has been established as one of
the flourishing in Bangladesh. It has been one of the most flourishing export sectors for our
country, as we have told in background. Now, our project is concerned with this sector. This
is a huge field to cover, as hundreds of manageable aspects can be found to maintain the
highest productivity of textile manufacturing. We choose the inventory management as our
preferred field to work.
To instantiate, this can be specified as a b2b system, from producers to abroad or home
dealers through some intermediate business nodes. The important deals that our RMG sector
are mostly from abroad interests, as stated above. And our goal would be facilitate this whole
process, from collecting raw materials to the finished product shipment.
Unlike the old days, RMG sector of Bangladesh has been implementing a variety of
management software, in order to enhance the productivity, and to satisfy the customers’
needs. As these deals are very sensitive to handle, and there are a lot of variables that must be
maintained, the need of online interaction between the buyer and the seller, or even seller to
seller, is a must, and can play a dramatic influence on these deals.

The existing systems have been using not for so long, and the maturity level of software
industry in our country is still very low. So, the systems which are being used in recent days
in the garments industry do have a lot of bugs, functional dependencies and design
The thing is missing all through and which we have been planning to introduce in these kind
of usual management system, is online interface to control the system. Internet has been a
pivotal determiner in every aspects life.
At the same time, there are technologies being used to manage payroll, appointments,
inventory, and in many other purposes. But as our major concerns will be inventory oriented,
we will focus the most on that.
3.2 Current System Analysis
Figure 1: Current System.
The given diagram is a scenario of current system. In the present system, when the
administrator sealed the production order then the people related to the production, specially
PQ ,administrator’s make the total production planning, and according to the plan the make a
check sheet. According to the production planning total production work is divided in to
partial productions. These partial productions are the part of total production. Combining this
entire partial production element total production take place.
But the fact is that in each stage of this partial production face production loses because of
manual updating system. They cannot follow the check sheet properly. So they cannot deliver
their shipment with in due date.

3.3 Product Functions

Inventory Management System must be designed to meet the dictates of the marketplace and
support the company's strategic plan. Along with the inventory system Garment industries
need some more special attributes. The Software’s for Garment are specially made for
managing the various steps in order processing of garments manufacturing process. This
software is modular in design and is web enabled for remote access as well as intranet usage
without the need to install in every machine.
So the features are,
Web based interface

User based Login - password based authentication for data protection.
Dynamic Modular structure – Each and every section related to a
production has separate menus.
Manage master details of buyer, supplier and vendor.
Job Work tracking.
Raw material tracking.
Shipment tracking.
Product category and product stock information with value.
Reports include purchase, issues, stocks & categories.
Customized package
Notification System in case of any process delay.
Check sheet automation.
These features are primary requirement of our client for this inventory management system.
This feature list will change in terms of client demand
3.4 Potential User of the of the System

There are two groups of users in our system. They are the production controller and the
system maintenance administrators. They have different authorities in our system which is
shown as follows;
 Production Controller: They are the Controller of the production in each and every
section related to total production. They can insert the detail product information
which is completed. Besides, they are able to view order sheet and sample sheet to
keep their production accurate. But their authentication domain is limited between
their field, which can be exemplified as the production controller who is in charge of
cutting, will not have the access to the information about payroll or customers.
 Administrator: They are authorized staffs to control the system. They are assigned
with different level of authority to control different parts of the system like inventory
and administrators. In addition, administrators are responsible to maintain database.

3.5 User Characteristics

The users of the software are classified into two categories – Registered user and unregistered
user.
Both users will be able to visit the homepage of the website but only the registered user is
allowed to give input in the system. To work through the system one user should go through
some fixed steps-
First of all the user should be registered.

The separate production module will be presented to the user as a
catalog for viewing.
The user can browse through the categories to choose the module they
desire.
The user can input partially complete production quantity of the total
production.
Finally the product will be delivered within a fixed and trusted time
period to the next production module.
And the process will continue until the shipment is completed
3.6 Assumptions and Dependencies

After completing our study about inventory and inventory management system, we thought
that, our Inventory management software will be ideal one in terms of garments industries of
our country. According to our view that inventory system will Contain module like:
Information of different products category
Available stock
Price of different items
transaction details
One can also extract any reports relating to purchase and Sale.
The inventory management application will have all the categories,
Subcategories, items, Stock details and reports.
The administrator of this inventory system will have right to create product, add items delete
items etc. The application will provide all information of the products. The category will be
tagged with subcategory. Again the subcategories are tagged with different items in the
respective category and rate of the item. Each item will have a specific bar code. The rates
will be tagged to the bar code.
Using these functions the user can:

Add items to inventory
Edit items in inventory
Add an action for an item
The application will also help to generate reports to get latest update on
Master Entry
Purchase order entry
Receive entry
Delivery entry
Report
This inventory system also has some dependencies like

 If data’s are inserted it cannot be deleted except administrator
 User can insert a data but can’t delete
 If data’s are not inserted, user cannot view report.
CHAPTER 4 - Requirement Analysis

Requirement Analysis presents the requirement specification, software and hardware
requirements for both system developers and system users, process model and data model. In
this section we specify the External Interface Requirements, functional and nonfunctional
requirements of the system.
4.1 External Interface Requirements
4.1.1 User Interfaces

User interface is one of the most important elements in any software. Most of the software’s
are used by non- technical persons. So they always seek of user friendly environment in their
system. And the user interface makes the system more familiar to its user. For our system we
do not design an user interface yet. But the process is going on.
4.1.2 Hardware Interfaces
In the current version of the software, it will have no special hardware interface with other
external systems. It will run in a general-purpose computer system with general-purpose
hardware and software.
4.1.3 Software Interfaces
The Current version of this system will be built on the following software:
Server:
Internet Information system
MySQL server 2007.
MVC 3.
Client:
PHP
OpenSSL.
JavaScript (synchronous/asynchronous) frontend, Enable Browser .
4.1.4 Communications Interfaces
All sorts of communications between server and client programs will be using ADO.NET
(ActiveX Data Objects for .NET) is a set of computer software components that programmers
can use to access data and data services. It is a part of the base class library that is included
with the Microsoft .NET Framework

4.2 Functional Requirements

Functional requirements define the functions that are requested by our stakeholders Different
functions are needed by different users of the system. Different administrators have authority
to maintain the system. The system specifies the authority of the administrator. The
administrator has got control over the database of the system. S/He can make changes to
update the total inventory system, and the update will be carried out dynamically.
4.2.1 General functional requirements:
Garment production is combination of different partial production. To keep track

of those partial production there will some modules in the system those are,
 Sketch Submission: In the garment manufacturing the first step is
designing the sketch for the dresses that have to be prepared. That sketch
contains all sort of information related to the product. So in the time of
production work this sketch is followed very strictly
 Production Pattern: The pattern design is taken for creating the
production patterns according to the sketch design. The production
pattern is one which will be used for huge production of garments. The
pattern maker makes the patterns on standard pattern making paper.
 Spreading: With the help of spreading machines, fabric is stacked on

one another in reaches or lays that may go over 100 ft. Long and
hundreds of plies (fabric pieces) thick.
 Cutting: Cutting the clothes to the desired sizes is a massively important
job in RMG business.
 Sorting: Sorting the inventory to increase the productivity is challenge,
which must be overcome to ensure the best management of the company.
 Sewing: There are sewing stations for sewing different parts of the cut
pieces. In this workplace, there are many operators who perform a single
operation.
 Finishing.
 Packing.
4.2.2 Functional Requirements for Production Controller
Login.
Browse desired modules.
Browse desired supervisor portfolio.
Notify the system about the module requirements.
Input product quantity after compiled.
Distribute requirements between the production supervisors.

Supervise inter-work station combination.

View production details with delivery date.
Browse through different production areas.
Balancing the check sheet.
4.2.3 Functional Requirements for Production Supervisor
Login.
Get update from the controller.
Setting the goal of the group and updating it on the system.
Input the worker-to-worker data.
Supervise own worker group performance.
Notify the dependent working group supervisors through the system.
Balancing the group input and output.
Submitting the group balance sheet to the responsible controller.
4.2.4 Functional Requirements for Administrator
Login.
Accessibility to the whole system.
Monitoring the total system as well as the database.
Giving the total goal of a deal as the input.
Clarifying the resources.
Distributing the job segments to the controllers.
Getting update information about the production.
Getting update information about production delay.
Getting update information about operation.
Invoice information collection.
Change settings

4.2.5 Quality Function Deployment
Quality function deployment is a method to transform user demands into design quality, to
deploy the functions forming quality, and to deploy methods for achieving the design quality
into subsystems and component parts, and ultimately to specific elements of the
manufacturing process.
QFD is designed to help planners focus on characteristics of a new or existing product or

service from the viewpoints of market segments, company, or technology-development
needs. The technique yields graphs and matrices.
QFD helps transform customer needs into engineering characteristics for a product or service,
prioritizing each product or service characteristic while simultaneously setting development
targets for product or service.
Quality Function Deployment (QFD) can be categorized by-
Normal Requirements,
Expected Requirements, and
Exciting Requirements.
Here is the list of functional quality of our product,
4.2.5.1 Normal Requirements
Normal requirements are those requirements which stakeholders want to be available in the
System. The normal requirements of this proposed application are given below-
The Inventory System must keep track of all compiled products or

resources records, which is expected to generate and must notify if
resources associated with the production is missing or order is incomplete.
The system must have an option to produce check sheet.
The system will perform authorization of users for security purposes. All
the users as well as the administrator must have to perform this part.
All types of resources and price information related to any production

must have to store in the system.
If any kind of change will occur, there will be an update option in the
system, using that administrator can change the existing information.
Users can browse through different production module.

The system must have the production plan making option.
Every module will have separated record for all the compilations occur.
Limited external accessibility, between companies or between selected
groups.
Limited internal accessibility, one module can be maintained and
manipulated by one person or one group of responsible employees.
Well-structured database to store inventory records.
4.2.5.2 Expected Requirements
Expected requirements are those requirements which stakeholders not mentioned to be

available in the system but he/she expects this will provide by the developer in the system.
The expected requirements for our proposed system are given below-
The system will contain user friendly interface that will be designed in a
manner which implements functionalities that are easily accessible by the
users.
The system must ensure database backups, which are as recent and
complete as possible
Check sheet, production planning, and backup files should be in readable
file format or in crystal reports format.
Order will be issued according to buyer name. This will help authority to
deal with their respected buyer.
4.2.5.3 Exciting Requirements
Exciting requirements are those requirements which stakeholders not actually want but these
requirements have to fulfill to make the system interesting. The exciting requirements for our
proposed system are given below-
Production planning with investment and estimated profit will be
calculated through the system.
Normal users and administrators have to login through different login
page which will ensure that, without administrator no one can change
any information of a production as well as the system.
System has the notifying system for any kind of delay occurs in the
given period. But the system can notify the dependent working group
supervisors if the administrators need them.
Administrators can distribute the job segments to the controllers.

4.3 Non-Functional Requirement

Non-functional Requirements of a system specify the performance, reliability, availability,
security, maintainability, portability of a system. So below there are a short description each
of those non-functional requirements.
4.3.1 Performance
Our proposed inventory management system will be used in Garment industry. There are lot
of internal and external operation which are inter-related with each other for fruit full
production. So the communication among each end system should be tightly scheduled and
the notification should be sent in timely manner.
4.3.2 Reliability
The production process in the garment industries is a combination of different operations,
which generate lots of data. These data lose can cause high damage to a specific module as
well as to the total process.
4.3.3 Availability
This system will be dedicated to a particular client. So the availability will be restricted of
this system.
4.3.4 Security
This system will deal with huge amount of data. So security is a prime issue of our system.
So the system should be secured from external interfere by providing efficient security to the
entire system.
4.3.5 Maintainability
Software maintenance in software engineering is the modification of a software product after
delivery to correct faults, to improve performance or other attributes. Maintainability of
software is categorized in four classes:
Adaptive – dealing with changes and adapting in the software environment.
Perfective – accommodating with new or changed user requirements which concern
functional enhancements to the software.
Corrective – dealing with errors found and fixing it.
Preventive – concerns activities aiming on increasing software maintainability and
prevent problems in the future.
So to maintain our system we will try to concentrate on this four classes.
4.3.6 Portability
Portability is the degree to which software running on one platform can easily be converted
to run on another. Portability is hard to quantify, because it is hard to predict on what other

platforms the software will be required to run. So to make our system portable we have to
use languages, operating systems and tools that are universally available and standardized.
4.3.7 Operational Requirement
The system can be viewed by open source Mozilla Firefox.
The system is supported by the IIS(Internet information’s system).
The team used MsSQL database to develop and maintain the database
management systems.
4.3.8 Design Constraints

When the project team is started to design the system, at that time the team always tries to
meet all the requirements of their client properly. But some time client’s make the job
difficult for the team to design the system by raising some last moment requirements. This is
considered as main constraints of designing a system.
Sometime clients do not give the proper information which is needed by the team to design
software, because of company policies. At that situation software project team start their
work without proper overview through the existing system to design new one.
CHAPTER 5 - Analysis Models

Analysis model is one of the most important parts of SRS. All the models give us clear view
of the developing system. In this section, here is the list of all analysis models used in
developing specific requirements of the current developing system.
Scenario based model:
 Use Case Diagram.

 Activity Diagram.
 Swim lane Diagram.
Flow Model
 Data Flow Diagram.
Class Model:
 Class Diagram.
 CRC Diagram.

Behavioral model:
 State transition Diagram.

 Sequence Diagram.
 Collaboration Diagram.
5.1 Scenario Based Model
5.1.1 Use Case diagram

In software and systems engineering, a use case is a list of steps, typically defining
interactions between a role or actor and a system, to achieve a goal. The actor can be a human
or an external system.
Initially after analyzing the requirements of our client we notify two potential actors in our
proposed system. But this can change any time when their requirements are modified.
So in this system normal users are production controllers. They can browse through their
production related modules. They can view all the production details, all the partial
production areas related to their production, can create check sheet according to order
quantity.

Figure 2: Use Case Diagram
On the other hand admin can change system settings, update operation information, Update
production information etc.

5.1.2 Activity Diagram
Activity diagrams are graphical representations of workflows of stepwise activities and

actions with support for choice, iteration and concurrency. In the Unified Modeling
Language, activity diagrams can be used to describe the business and operational step-by-step
workflows of components in a system. An activity diagram shows the overall flow of control.
Figure 3: Activity Diagram.
If we consider the given activity diagram, it will easier for us to find out step-by step
operational workflows of total system. When the process starts it will allow a user to select
his/her own authentication. If the user logged in as an Administrator, the user has the
authority to select operation between change settings of the working module and update
information of the production.

On the other hand if the user logged in as a production controller, after valid authentication
the production controller can give input in the system to ensure the partial production of the
total production. In any state of the production if the delay is occurred, production controller
can notify administration about the delay to handle shipment related issues.
5.1.3 Swim Lane Diagram

A swim lane is a visual element used in process flow diagrams, or flowcharts, that visually
distinguishes responsibilities for sub-processes of a business process.
Figure 4: Swim Lane diagram
This is the swim lane view of our proposed system according to present requirements .System
column shows the entire operational function .and administrator and production controller
column shows the task that they will do using the system

5.2 Flow model

5.2.1 Data flow diagram
A data flow diagram (DFD) is a graphical representation of the "flow" of data through an
information system, modeling its process aspects. Often they are a preliminary step used to
create an overview of the system which can later be elaborated. DFDs can also be used for
the visualization of data processing .
A DFD shows what kinds of data will be input to and output from the system, where the data
will come from and go to, and where the data will be stored. It does not show information
about the timing of processes, or information about whether processes will operate in
sequence or in parallel

Data flow diagram (level 0):
DFD level 0 , is the representation of the system which can only shows the inputs and outputs
of the system without dealing with any function and file or database issue. In the given figure
this is the data flow diagram (Level 0) for our proposed inventory management system.
Control panel and the planning is two input entity which can give data command to the
system, all the inputs will process in the system and the outputs will view in the display panel
or as notification. And the system also can produce check sheet according to given planning.
Data flow diagram (Level 1):
DFD level 1, is the representation of the system which can visualize the relation among the
functions and the file or database with the inputs and outputs. Control panel and planning
entity can give input command to the system, which can process by some functions in this
system like interact with user, configure, and update input, display status. There is a database
related with configure function which one can modify production information. And display
status, notification, check sheet can produce output depend on all the functions which
configure inputs.

5.3 Class Model

5.3.1Class Diagram
In software engineering, a class diagram in the Unified Modeling Language (UML) is a type
of static structure diagram that describes the structure of a system by showing the system's
classes, their attributes, operations or methods, and the relationships among the classes.
Figure 7: Class Diagram
In the above exposed diagram ‘Module’ is the parent class which has two child classes
‘Administrator’ and ‘Production Controller’. Order Class deals with all the steps related to
order and maintained by administrator. ‘Store ‘and ‘Shipment’ class maintained by
production controller.

5.3.2 Class Responsibility Collaboration Diagram
Figure 8: CRC Diagram
A Class Responsibility Collaborator (CRC) model is a collection of standard index cards that
have been divided into three sections,
Section 1: A class represents a collection of similar objects.
Section 2: A responsibility is something that a class knows or does.
Section 3: A collaborator is another class that a class interacts with.

5.4 Behavioral model
5.4.1 State Representation Diagram
Figure 9: State Representation Diagram.
A state diagram is a type of diagram used to describe the behavior of systems. State diagrams
require that the system described is composed of a finite number of states; sometimes, this is
indeed the case, while at other times this is a reasonable abstraction. Many forms of state
diagrams exist, which differ slightly among each other.
In the given figure, this is the state representation diagram for our proposed system. In the
given figure there are four states, first one “reading state” just read the instructions. Second
one “comparing state” compares the given command. When the state compare password, if
the password is invalid, total system will be locked for a while. Or if the password is valid it
will move a step ahead to select operation what the system allow an user.

5.4.2 Sequence Diagram
Figure 10: Sequence Diagram
A sequence diagram in a Unified Modeling Language (UML) is a kind of interaction diagram

that shows how processes operate with one another and in what order. It is a construct of our
proposed system’s Sequence Chart. A sequence diagram shows object interactions arranged
in time sequence. It depicts the objects and classes involved in the scenario and the sequence
of Command exchanged between the objects needed to carry out the functionality of the
scenario.

5.4.3 Collaboration Diagram
Figure 11: Collaboration Diagram
Collaboration diagrams belong to a group of UML diagrams called Interaction Diagrams.

Collaboration diagrams, like Sequence Diagrams, show how objects interact over the course
of time. However, instead of showing the sequence of events by the layout on the diagram,
collaboration diagrams show the sequence by numbering the Commands on the diagram.
This makes it easier to show how the objects are linked together, but harder to see the
sequence at a glance.


6 .Project Management Planning

The following are the key members of the project team:
6.
Business Analyst
7.
Project Manager
8.
Team Leader
9.
Function Head
10.
Function Executor
6.1 Work Breakdown Structure and Gantt Chart

Gantt Chart of Online Inventory Management System

6.2 Responsibility Matrix

P B S P P P F V D C U A B S P P P F V S D C U A B S P P P F V D C U A
M A R B D F D A C A R B D F D & T A C A R B D F D A C
S T & & S T V & S T & &
V C C V C
B P P P P
A
P P
M
T P P P P P P P P P
L
F P P P P P P P P P
H
B
n
R
A
F P P P P
H
V
n
V
F P P P P P P P P P P P P P P P P P
E
B
n
R
A
F P P P P P P
E
I
n
S
F P P P P P P P P P P P P
E
D
N
D
F P P P P P P P P P P
E
V
n
V
F P P P
E
B
n
R

Abbreviations Used:
BA- Business Analyst
SRS- Software requirement specification
PB- Product Backlog
PD- Prototype Development
PFT- Prototype Fine tuning
FD- Final Development
V & V- Validation and Verification
D- Deployment
C & C- Customization and configuration
UA- User Acceptance
AC- Application Conclusion
ST- Stress Testing
Resource Allocation
Resources Used:
9. PM – Project Manager
10. FE-BnRA- Business and Requirement Analysis , Function
Executor
11. FH-BnRA - Business and Requirement Analysis ,Function Head
12. FE-Dnd – Development and Delivery ,Function Executor
13. TL-Dnd – Team leader, Development and Delivery Executor
14. FE-Vnv – Verification and Validation , Function Executor
15. FH-VnV- Function Head, Validation and Verification
16. FE-InS – Implementation and Support by Function Executor
Analysis
As we can see from the bar graphs few resources are leveled properly
but some are not leveled.
To level the resources we will have to shift the activities but as we
can see from the activity diagram there is no slack in the activities so
we cannot delay the activities without affecting the project time and

hence, resources cannot be leveled. Using a different software model

process could help to level the resources.
6.4Scheduling
Activity ID Early Start Early Finish Late Start Late Finish Slack
3 0 2 0 2 0
11 2 5 2 5 0
12 5 7 5 7 0
13 7 10 7 10 0
15 10 16 10 16 0
16 16 19 16 19 0
17 19 31 19 31 0
18 31 35 31 35 0
20 35 37 35 37 0
21 37 39 37 39 0
22 39 41 39 41 0
23 41 42 41 42 0
27 42 45 42 45 0
28 45 47 45 47 0
29 47 49 47 49 0
31 49 55 49 55 0
32 55 58 55 58 0
33 58 65 58 65 0
35 65 69 65 69 0
36 69 72 69 72 0
38 72 73 72 73 0
39 73 74 73 74 0
40 74 75 74 75 0
41 75 76 75 76 0
45 76 77.5 76 77.5 0
46 77.5 79 77.5 79 0
47 79 80 79 80 0
49 80 83 80 83 0
50 83 85 83 85 0
51 85 90 85 90 0
52 90 93 90 93 0
54 93 94 93 94 0
55 94 96 94 96 0
56 96 97 96 97 0
57 97 99 97 99 0
Project Completion Time: 99 Days.

6.5 Crashing
As we know that crashing is a tradeoff between cost and time, so
while crashing a project or a given activity of a project both the factor
need to be kept in mind. Our main aim is basically to complete the
project in minimum possible number of days and incur the least cost
with maximum utilization of resources. The critical path of our
project is 110 days. As we can see from the data, in the activity Sale
Campaign Definition under the sub activity final development, the
execution process takes 12 days. If we crash this part of the project by
employing one additional employee skilled in each resource, the
project will be completed 6 days earlier but will lead to increase in
costs from Rs 36480 to 54720. Hence the project execution time came
down to 93 days. If we also crash the activity of prototype
development which originally takes 6 days to complete, the project
duration reduces further by 3 days. It results in an increase in costs
from Rs 20,400 to 30600. Hence the overall cost of the project which
was initially Rs 3, 19,400 increases to 3, 47,840 and also reducing the
total time taken by project to complete to 90 days.
Cost(Rupees * 1000 )
85.0 90.0 95.0 100.0
Days

CHAPTER7 -Project Monitoring and Control

In this project, the project team uses the Tracking Gantt Chart which
allows them to constantly review the project’s status and progress by
linking task initiation and completion to the project schedule.
The schedule is reviewed at the interval of every 15-20 Days.
The progress review is focused on –

 Percentage of work done and work remaining
 Bottlenecks of the remaining tasks
 Resource utilization: Utilization of resources according to
schedule and in favor of all performance, cost and time.
 Resources re-shuffling due to escalation of task: sequence of
tasks maybe changed in the schedule later at a stage due to
changed priorities and therefore resource re-shuffling is needed.
 Possible risks which maybe encountered in the future and their
solutions.
Resource Utilization and resources re-shuffling due to escalation of

task is monitored by resource allocation charts and graphs. By using
these tools, the amount of resources used and available is monitored.

7.1Analysis of Software Project Model

Two development methodologies will be used during the design of this project. They are
- Waterfall Development Methodology

- Agile Development Methodology
7.2 Waterfall Development Methodology

The waterfall model is a linear, sequential approach to the software development life cycle
(SDLC) that is popular in software engineering and product development. The waterfall
model emphasizes progression of steps. Similar to the direction water flows over the edge of
a cliff, distinct endpoints or goals are set for each phase of development and cannot be
revisited after completion. The term was first introduced in a paper published in 1970 by Dr.
Winston W. Royce and continues to be used in applications of industrial design. (TechTarget
2009)
The waterfall methodology will be utilized because from the start of the project, everything
goes with a flow.

Every component is arranged in an order and will be gotten one after the other but not all the
way through the project, then it gets to a point where there will be many unknown
circumstances hence the use of Agile Methodology will be suited.
7.3. Agile Development Methodology

Agile software development -- also referred to simply as agile- is a type of development
methodology that anticipates the need for flexibility and applies a level of pragmatism to the
delivery of the finished product. Agile software development requires a cultural shift in
many companies because it focuses on the clean delivery of individual pieces or parts of the
software and not on the entire application.
Agile has replaced Waterfall as the development methodology of choice in most companies,
but is itself at risk of being eclipsed or consumed by the growing popularity. (TechTarget
2019)
Agile Methodology is utilized here because there are some components that might require a
test and run kind of approach. The project will be tested for a multiple number of times until
the desired outcome is received. This is why the utilization of Agile methodology is
important here.

7.4 Approach to Chosen Methodology/Methods

Waterfall Model Management
If the waterfall model is to be executed properly, each of the phases we outlined earlier must
be executed in a linear fashion. Meaning, each phase has to be completed before the next
phase can begin, and phases are never repeated—unless there is a massive failure that comes
to light in the verification or maintenance phase.
Furthermore, each phase is discrete, and pretty much exists in isolation from stakeholders
outside of your team. This is especially true in the requirements phase. Once the customer’s
requirements are collected, the customers cease to play any role in the actual development of
the software.
Agile Project Management

Agile differs greatly from waterfall in two major ways; namely in regards to linear action
and customer involvement. Agile is a nimble and iterative process, where the product is
delivered in stages to the customer for them to review and provide feedback.
Instead of having everything planned out by milestones, like in waterfall, Agile operates in
“sprints” where prioritized tasks are completed within a short window, typically around two
weeks.
These prioritized tasks are fluid, and appear based on the success of previous sprints and
customer feedback, rather than having all tasks prioritized at the onset in the requirements
phase. (projectmanager 2021)
7.4.1 WATERFALL METHODOLOGY APPROACH

Requirement and analysis: Amongst all the requirements of the system to be designed are
gotten in this stage and written in a requirement specification document. In this stage,
inquisition on how the current system is running and the limitations therein was conducted,
in order to know where to start the proposed system. Based on the analysis, the basic
requirements of the proposed system will then be determined, i.e. the input and output, and
elimination of redundancies.
System Design: The necessity determinations from the first phase are concentrated in this
phase and the system configuration is prepared. This system configuration helps in

determining hardware and system necessities and helps in characterizing the general system
engineering.
Integration and Testing: in this stage, as referenced prior, unit testing will be directed. All
the units created in the execution stage are coordinated into a system subsequent to testing of
every unit. Post integration the whole framework is tried for any issues and faults.
Deployment of system: This will happen after all the previously mentioned stages. When the
functional and non-functional testing is done, the item is sent in the customer environment or
delivered into the market.
Maintenance: After the deployment, there will be a few issues which will come up in the
customer environment. To fix those issues, patches are delivered. Likewise, to upgrade the
software product some better forms are delivered. Maintenance is done to convey these
modifications to the client environment.
Advantages of the waterfall model:

- It is uncomplicated and undemanding to use.
- Easy to oversee because of the unbending nature of the model – each stage has explicit
expectations and a survey cycle.
- It has clearly characterized stages.
- Procedure and results are all in the order in the archived.
- Well gotten achievements.
Drawbacks of the waterfall model:

- It is not appropriate for the tasks where necessities are at a moderate to high chance of
evolving.
Along these lines, danger and vulnerability are high with this cycle model.
- Integration is done as a huge explosion at the end, which doesn't permit recognizing any
innovative or business bottleneck or difficulties early.
- It is not a decent model for complex and item arranged tasks.
- High measures of danger and vulnerability.

7.4.2 AGILE METHODOLOGY APPROACH

Notion: Projects are imagined and organized.
Inception: Team individuals are distinguished, financing is set up, and starting conditions
and necessities are talked about. Iteration/Construction: The advancement group attempts to
convey working programming software dependent on cycle necessities and feedback.
Delivery: QA (Quality Assurance) testing, inside and outside preparing, documentation
advancement, and last arrival of the cycle into creation.
Creation: Ongoing help of the software product.
Retirement: End-of-life exercises, including client notice and relocation
Advantages of the Agile Methodology

- Development is regularly more client-focused in, likely an aftereffect of more and
continuous demands from the client.
- There is overall less risk since the project's output is reviewed along the way equally.
It saves money and time from unnecessary expenditures, because providing value for users
will be prioritized.
- Dividing into segments offers the group the chance to zero in on the individual stages
and work quicker.
Drawbacks of the Agile Methodology

- The methodology may appear to be basic however be difficult to execute. It requires
responsibility and for everybody to be on the same wavelength, in a perfect flow, in a similar
actual space.
- Agile works best when individuals from the advancement group are totally
committed to the project.
- A significant level of communication between the customer and the designers is
required, which can require significant investment and make the cycle troublesome.

CHAPTER 8 - IMPLEMENTATION AND TESTING
8.1 Overview
This section portrays how the project was actualized and implemented .It shows the
fundamental highlights of the system, their execution and purposes. Additionally, it shows
the means needed to utilize or work around the system, and comprehend the framework
cycle completely. It likewise discusses the project testing utilizing diverse test scenarios and
the outcomes (anticipate result and brought result back). It additionally presents the GUI that
was executed to make the interface more agreeable and easy to use when clients are utilizing
the application.
8.2 Main Features

When you start the application, the user makes use of the application through the following
interfaces to carry out their activities.
USER INTERFACE
Figure 12 Login Page
Figure 13 Dashboard

Figure 14 Product Profile
Figure 15 Stock Inventory

Figure 16 Customer Profile
Figure 17 Daily Sales

Figure 18 Expired Item
Figure 19 Add Item
8.3 Implementation Problems
The major problems encountered was mainly time and due to this pandemic, being able to
get assistance was a little issue alongside getting materials. During the project development
and execution, the person responsible (I) is required to also have to focus on other courses
which include assignments, tests and examinations. Furthermore, several functionality with

the intention of might not have been met, however it can be implemented afterwards in later
versions.
8.4 Overcoming Implementation Problems

Managing time to be able to utilize all the accessible assets to guarantee the system has been
a success with all the necessary tasks that was applied. Additionally, at every phase there
were tests and debugging to ensure everything is running smoothly.
8.5 Testing
In this testing approach, data to run tests were obtained from the determinations of the
system and afterward used to test every conceivable section or entries as input. Where
subsequently the real outcome was then contrasted with the normal outcome after each test
trial was carried out.
On the off chance that the two outcomes relate at a point, the testing can be supposed to be a
success. Which means the developer that led the testing was more worried about the genuine
outcome delivered by the program than with the web build of the program. This online
framework is huge and very much controlled that is the reason testing framework technique
was picked as the testing method to streamline the testing cycle and make all around
reported outcomes. The system has many website pages and each page has numerous
connections and verifications that make the system successful and productive consequently
the utilization of System Testing was basic. Different kinds of testing where likewise
completed such Unit Testing and Combination Testing and so on
8.5.1 Tests Plans (for Unit Testing, Integration Testing, and System
Testing)
• During execution, bugs and errors of various calls happened. A portion of these bugs were
trivial while some made the movement of the application a little slow. Testing was
performed while execution was in advancement.
• Unit testing was performed for example after each combination of a component of line of
code, the system was developed to check for blunder errors and made to check for
exemptions.

• Combination Testing was likewise performed for example the whole application was
continually checked after a colossal coordination (for example expansion of update part of
the application).
• System testing to test the framework completely.
Table 4.1: Test Plan
S/N Admin
1 Admin can add stock
2 Admin can view customer data
3 Admin can perform CRUD functions on all products
4 Admin can view available stock
5 Admin can view and see items that are currently in stock
8.5.2 Test Suite (for Unit Testing, Integration Testing, and System Testing)
Table 4.2 Test Suite Performed
Req. Description Type

No.
R-101 When launched, the application shall stay running Performance

unless there is an intentional shutdown of the
application or the platform.
R-102
4.5.3 Test Traceability Matrix (for Unit Testing, Integration Testing, and
System Testing)
Table 4.3: Test Traceability Matrix

CASE 1
OBJECTIVES Test Validation on Login Page
TEST DATA Try to login without Access
EXPECTED RESULT Unrestricted Access
ACTUAL RESULT Unrestricted Access
CONCLUSION Successful
CASE 2
OBJECTIVES Admin Login
TEST DATA Approve
EXPECTED RESULT Dashboard
ACTUAL RESULT As below
CONCLUSION Successful
Figure 20 Admin Login
CASE 3
OBJECTIVES Add Item
TEST DATA Add Item in Item list
EXPECTED RESULT As below
ACTUAL RESULT Success
CONCLUSION

Figure 21 New Item Added
CASE 4
OBJECTIVES Add to Cart
TEST DATA Adding Item to Cart
EXPECTED RESULT As below
ACTUAL RESULT Success
Figure 22 Item Added to Cart
CASE 5

OBJECTIVES Show only items available in Stock

TEST DATA Stock Inventory
EXPECTED RESULT Item List
CONCLUSION Success
Figure 23 Items in Stock
CASE 6
OBJECTIVES Add Stock
TEST DATA Adding Stock
EXPECTED RESULT Success Message
CONCLUSION Success

Figure 24 New Stock Added
CASE 7
OBJECTIVES Add Customer
TEST DATA Adding customer
EXPECTED RESULT Success message
CONCLUSION Success
Figure 25 4New Customer Added

CASE 8
OBJECTIVES Logout
TEST DATA Logout
EXPECTED RESULT Successful Logout
ACTUAL RESULT
CONCLUSION Success
CASE 9
OBJECTIVES Delete Customer
TEST DATA Deleting Customer
EXPECTED RESULT Deleted from Table
ACTUAL RESULT Deleted
CONCLUSION Success
CASE 10
OBJECTIVES Delete Item
TEST DATA Deleting Item
EXPECTED RESULT Delete from Table
ACTUAL RESULT Deleted
CONCLUSION Success
8.5.4 Test Report Summary (for Unit Testing, Integration Testing, and
System Testing)
Table 4. 4 Test Summary Report
No Test Performed Action
1 Test Validation on Login Page Pass
2 Admin Login Pass
3 Add Item Pass
4 Add to Cart Pass

5 Show only items available in Stock Pass
6 Add Stock Pass

7 Add Customer Pass
8 Delete Customer Pass
9 Delete Item Pass
10 Logout Pass
8.5.5 Error Reports and Corrections
No error report was detected in the testing stage. All the tests were successful.
16.6 SOURCE CODE
PROJECT ARCHITECTURE

Figure 26 Netbeans IDE

Figure 27 Open IAS using App
Figure 28 : Run the code using browser
Figure 29 Server Directory (Database

Figure 30 Navigate Pages
8.7 Summary
In this chapter, it shows all the execution and tests conducted in the project. It was
successfully accomplished and some problems were encountered along the testing stage but
managed to overcome it by debugging and fixing the errors. The functionalities and
mechanism are running as expected.
CHAPTER 9 - Conclusions
The Internet has become a major resource in modern business, thus electronic shopping has
gained significance not only from the entrepreneur’s but also from the customer’s point of
view. To build any web application using ASP.NET we need a programming language such
as C#, VB.NET, J# and so on. C# was the language used to build this application. For the

client browser to connect to the ASP.NET engine we used Microsoft’s Internet Information
Services (IIS) as the Web Server
This project helps in understanding the creation of an interactive web page and the
technologies used to implement it. The building of the project has given me a precise
knowledge about how ASP.NET is used to develop a website, how it connects to the
database to access the data and how the data and web pages are modified to provide the
user with a shopping cart application.
CHAPTER 10 -References
www.agilemodeling.com/artifacts/crcModel.html.
http://en.wikipedia.org/wiki/Unified_Modeling_Language
http://en.wikipedia.org/wiki/Requirements_analysis
http://rfptemplates.technologyevaluation.com/rfp/for/inventory-management-garments.html
http://www.slideshare.net/ahmedhasan/ieee-830-1998-software-requirements-specifications
http://gulnazahmad.hubpages.com/hub/A-Step-by-Step-of-Garment-Manufacturing
For Code, Please Check my GitHub Repository –

https://github.com/Piaowei/Online-Inventory-Management-System
Thank You, 谢谢您

Online Inventory Management System SRS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Online Inventory Management System SRS

Uploaded by

Copyright:

Available Formats

Online Inventory Management System

PARVEZ MOHAMMAD SHARIAR 朴维

Project Source Code

Submitted to: 紫气东来

Software Requirements Specification Page i

Software Requirements Specification Page ii

To provide user efficient working environment.

Easy maintenance and administration.

Key Terms Definition

RMG Ready Made Garments

Inventory Inventory means a list compiled for some formal purpose

Production Who guide and supervise production work.

IIS Internet Information System

SRS Software Requirement Specification

DFD Data Flow Diagram

Software Engineering Project Report Page i

Life Cycle of the project

Executives and upper management.

1. How the processes work?

Software Engineering Project Report Page ii

2.2 Stakeholders view point

 Production controller is the people who supervise a part of a production unit.

Software Engineering Project Report Page iii

As information from multiple viewpoints is collected, emerging requirements may be

 Online status of item quantity in terms of on-hand, on-hand available, reserved,

Software Engineering Project Report Page iv

3.2 Current System Analysis

Figure 1: Current System.

Software Engineering Project Report Page v

3.3 Product Functions

Web based interface

Software Engineering Project Report Page vi

3.4 Potential User of the of the System

3.5 User Characteristics

First of all the user should be registered.

3.6 Assumptions and Dependencies

Software Engineering Project Report Page vii

The inventory management application will have all the categories,

Using these functions the user can:

This inventory system also has some dependencies like

4.1 External Interface Requirements

4.1.1 User Interfaces

Software Engineering Project Report Page viii

4.2 Functional Requirements

4.2.1 General functional requirements:

Garment production is combination of different partial production. To keep track of

Software Engineering Project Report Page ix

 Spreading: With the help of spreading machines, fabric is stacked on one

4.2.2 Functional Requirements for Production Controller

4.2.3 Functional Requirements for Production Supervisor

Software Engineering Project Report Page x

Balancing the group input and output.

4.2.4 Functional Requirements for Administrator

4.2.5 Quality Function Deployment

Software Engineering Project Report Page xi

Quality Function Deployment (QFD) can be categorized by-

Here is the list of functional quality of our product,

4.2.5.1 Normal Requirements

Users can browse through different production module.

4.2.5.2 Expected Requirements

4.2.5.3 Exciting Requirements

4.3 Non-Functional Requirement

Software Engineering Project Report Page xiii