Software Requirements Specification for Warehouse Management

Desklib provides solved assignments and past papers to help students succeed.

Table of Contents
Introduction.................................................................................................................................................2
Functional and Nonfunctional Requirements...............................................................................................3
Functional requirements..........................................................................................................................3
Nonfunctional requirements....................................................................................................................5
Use Case Diagram.......................................................................................................................................7
Domain Model Class Diagram....................................................................................................................9
Event Partitioned System Model...............................................................................................................13
Conclusion.................................................................................................................................................15
References.................................................................................................................................................16
Table of Figures
Figure 1 Use Case Diagram.........................................................................................................................7
Figure 2 Domain Model Class Diagram......................................................................................................9
Figure 3 Event Partitioned System Model.................................................................................................13

Introduction
In this report, functional and nonfunctional requirements of the warehouse management system
will be evaluated. The major use cases will be identified and diagrams will be prepared
according to the requirements and the situations in the warehouse management system. The
relationships will be evaluated according to the diagrams.

Functional and Nonfunctional Requirements
Functional requirements
Functional prerequisites are item highlights or capacities that engineers must execute to empower
clients to achieve their assignments. In this way, it's imperative to make them unmistakable both
for the advancement group and the partners (AltexSoft, 2019). By and large, utilitarian
necessities depict framework conduct under explicit conditions.
The functional requirements are listed below:
Specific requirements for software document
The document contains depictions of capacities and abilities that the item should give. The
record additionally characterizes limitations and presumptions. The document can be a solitary
archive conveying useful necessities or it might go with other programming documentation like
client stories and use cases. It's basic to make the document decipherable for all partners. You
additionally should utilize layouts with visual accentuation to structure the data and help in
getting it. In the event that you have necessities put away in some other record groups,
connection to them to enable perusers to locate the required data.
Use cases
Use cases portray the collaboration between the framework and outside clients that prompts
accomplishing specific objectives.
A use case outline doesn't contain a lot of subtleties. It demonstrates an abnormal state outline of
the connections between on-screen characters, distinctive use cases, and the framework.
The use case graph incorporates the accompanying principle components:
1. Use cases
Generally drawn with ovals, use cases speak to various use situations that on-screen
characters may have with the framework (sign in, make a buy, see things, and so forth.)
2. Associations
Associations are drawn with lines indicating various sorts of connections among on-
screen characters and use cases.

3. Actors
These are the assumes that portray outside clients (individuals or frameworks) that
connect with the framework.
4. System
Limits are laid out by the crate that gatherings different use cases in a framework.
User stories
A client story is a recorded portrayal of a product highlight seen from the end-client viewpoint.
The client story portrays what precisely the client needs the framework to do. In Agile
undertakings, client stories are sorted out in the form of the backlog. The backlog is an arranged
rundown of item works. As of now, client stories are viewed as the best configuration for
backlog things.
These user stories are combined with the acceptance criteria. These are the conditions that the
item should fulfill to be acknowledged by a client, partners, or an item proprietor. Every client
story must-have in any event one acknowledgment basis. Viable acknowledgment criteria must
be testable, compact, and totally comprehended by all colleagues and partners.
Work Breakdown Structures (WBS)
WBS represents a visual record that represents how complex procedures separate into their more
straightforward segments. WBS is a powerful way to deal with taking into consideration an
autonomous investigation of each part. WBS likewise helps catch the full image of the venture.
The highlights of the project ought to be deteriorated to the time when the most minimal level
parts can't be separated any further.
Software prototypes
Prototype-based on software is defined for various types of beginning period expectations that
are worked to feature how necessities must be actualized. Models help connect the vision holes
and let partners and groups explain convoluted regions of items being developed. Generally,
models speak to how the arrangement will function and give instances of how clients will
interface with it to achieve their assignments.

Models can be shabby and quick visual portrayals of necessities or increasingly complex ones.
The last can even turn into the early forms of the item that as of now have a few bits of the last
code.
Nonfunctional requirements
Nonfunctional requirements depict how a framework must carry on and set up limitations of its
usefulness.
The nonfunctional requirements are mentioned below:
Usability
Usability characterizes how troublesome it will be for a client to learn and work the framework.
It can be evaluated by observing the different point of view like,
1. The normal time it takes to achieve a client's objectives, what number of assignments a
client can finish with no assistance, the number of exchanges finished without mistakes,
and so forth.
2. Characterization of the difficulty in understanding the way of using buttons, interface,
etc.
3. Estimating the number of attempts done by the user to perform any task.
Security
Security prerequisites guarantee that the product is shielded from unapproved access to the
framework and its put away information. It thinks about various degrees of approval and
validation crosswise over various clients’ jobs. For example, information protection is a security
trademark that portrays who can make, see, duplicate, change, or erase data. Security likewise
incorporates insurance against infections and malware assaults.
Reliability
Reliability characterizes how likely it is for the product to work without disappointment for a
given timeframe. Unwavering quality abatements on account of bugs in the code, equipment
disappointments, or issues with other framework parts. To gauge programming dependability,
you can tally the level of activities that are finished effectively or track the normal timeframe the
framework keeps running before falling flat.

Availability
The availability is determined by checking the timeframe that the system's usefulness and
administrations are accessible for use with all activities. Along these lines, booked support
periods legitimately impact this parameter. What's more, it's imperative to characterize how the
effect of support can be limited. When composing the accessibility necessities, the group needs
to characterize the most basic parts of the framework that must be accessible at record-breaking.
You ought to likewise plan client notices on the off chance that the framework or one of its parts
winds up inaccessible.
Scalability
Scalability is the most important factor as it is responsible for making the system grown while
the enterprise is growing and adapt to their needs. This implies serving more clients, preparing
more information, and accomplishing more exchanges. Adaptability has both equipment and
programming suggestions. For example, you can build adaptability by including memory,
servers, or circle space. Then again, you can pack information, use upgrading calculations, and
so forth.

Use Case Diagram
Use case diagram is the easiest portrayal of a client's association with the framework that
demonstrates the connection between the client and the distinctive use cases in which the client
is included (SmartDraw, 2019).
Figure 1 Use Case Diagram
Above is the use case diagram of the warehouse management system. In this system, there are 2
actors. The first actor is the Administrator who is the supplier and the second actor is the
customer.
Use Case: Send Products
In this use case, the administrator is responsible for sending the products while verifying the
availability of the stocks.
Use Case: Create Invoice
In this use case, the administrator creates the invoice of the order when the payment has been
successfully completed.
Use Case: Manage Bills

In this use case, the administrator can manage all the bills according to the date, time and name
of the customers.
Use Case: Manage Customers
The administrator can manage the accounts of the customer and can even delete it if any fraud
has been detected.
Use Case: Inventory Management
The inventory management system is embedded in the warehouse management system from
where the administrator can manage the inventory according to space in the warehouse.
Use Case: Manage Stocks
In this use case, the administrator is responsible for managing the stocks in the warehouse
according to space availability.
Use Case: Login & Logout
In this use case, the administrator and the user is performing the same operation of logging in
and logging out of their systems.
Use Case: Tracking orders
In this use case, the customer can see the details of order while it is being shipped to the
customer’s address. This data is also visible to the administrator.
Use Case: Payment
This use case is responsible for making the payment of the purchase after which the invoice will
be created.
Use Case: Manage Purchasing
In this use case, the customer manages the purchases of his/her inventory and organize them in a
systematic order and add or delete anything he/she wants to.

Domain Model Class Diagram
Class diagram portrays the qualities and tasks of a class and furthermore, the limitations forced
on the framework (SourceMaking, 2019). The class outlines are generally utilized in the
displaying of object-oriented frameworks since they are the main UML charts, which can be
mapped legitimately with OOP languages.
Figure 2 Domain Model Class Diagram
There are 6 classes in the class diagram. Each class represents different functions. As seen above,
the administrator is able to handle all the classes to some extent.
Customer
The customer has various attributes like name, address, number and email which creates a unique
identification for the record. There are 4 methods in the customer class.
1. customer login()
It is responsible for the login process of the customer. It verifies if the credentials are
correct or not.

2. addCustomer()
It is responsible for adding new customer in the system.
3. deleteCustomer()
It is responsible for the deletion of the customer’s account whenever they want to delete
it.
4. editCustomer()
It is responsible for updating the profile and shipping details of the customer.
Inventory
The inventory possesses the information about the products like name, quantity available,
description and price. The inventory class can exist whether there exists any customer or not.
The inventory class has 2 methods.
1. displayProductDetails()
This method is responsible for displaying the product and its details in the inventory.
2. checkAvailability()
This method is responsible for checking the availability of the product before displaying
it in the inventory.
Order
The order has 3 attributes. The first one is to display the details of the order, the second one is to
display the expected delivery date and the third one is to display the shipping details of the order.
The order class cannot exist if there is no inventory. There are 2 methods in the order class.
1. trackOrder()
This method is responsible for tracking the order when it is delivered.
2. calculateAmount()
This method is responsible for calculating the total amount of the order.
Payment
The payment class includes 3 attributes. The first one is to display the customer details, the
second one is to display the amount to be paid for the order and the third one to display the date

for the payment. The payment class cannot exist if there is no order. The payment class has only
one method called payment() which is responsible for running the whole process of the payment.
Invoice
The invoice class includes four attributes such as,
1. Displaying the details of the payment
2. Displaying the total amount of the order
3. Displaying the details of the order
4. Displaying the shipping details of the order
There are 2 methods in the invoice class,
1. verifyPayment()
This method is responsible for verifying the successful competition of the payment.
2. invoiceDetails()
This method is responsible for displaying the details of the invoice.
Administrator
The administrator class has only 2 attributes. The first attribute is the name of the administrator
and the second attribute is the password of the administrator.
There are 5 methods in the administrator class.
1. adminLogin()
This method is responsible for verifying the administrator credentials while logging
in and provide a safe and secure login.
2. manageCustomers()
This method controls all the records of the customers. The administrator can remove
any customer whenever he/she wants.
3. editInventory()
This method is responsible for adding, updating and deleting the products for the
inventory.
4. verifyOrder()

This method is responsible for checking the availability of the stock before
confirming the order.
5. createInvoice()
This method is responsible for creating an invoice for every successful transaction
from the customer’s side.