PROGRAM: 1

1.1OBJECTIVE 1.2THEORY 1.3 PROCEDURE 1.4 OUTPUT

1.1 OBJECTIVE: Prepare a SRS document in line with the IEEE recommended
standards.

1.2 THEORY: An SRS is basically an organization's understanding (in writing) of a customer or

potential client's system requirements and dependencies at a particular point in time (usually)
prior to any actual design or development work. It's a two-way insurance policy that assures that
both the client and the organization understand the other's requirements from that perspective at
a given point in time.
Well-designed, well-written SRS accomplishes four major goals:
1. It provides feedback to the customer.
2. It decomposes the problem into component parts.
3. It serves as an input to the design specification.
4. It serves as a product validation check.

The basic issues that the SRS shall address are the following:

1 Functionality. What is the software supposed to do?

2 External interfaces. How does the software interact with people, the system’s hardware,
other hardware, and other software?
3 Performance. What is the speed, availability, response time, recovery time of various
software functions, etc.?
4 Attributes. What is the portability, correctness, maintainability, security, etc.
considerations?

1.3 PROCEDURE:

IEEE Standard SRS Template

1. Introduction
1.1. Purpose
1.2 Intended Audience
1.2. Scope
1.3. Definitions, acronyms & abbreviations
1.4. References
1.5. Overview
2. Overall description
2.1. Product perspective: A block diagram showing the major components of the large system,
interconnections and external interfaces can be useful
2.1.1. User interfaces
2.1.2. Hardware interfaces
2.1.3. Software interfaces
2.1.4. Memory constraints
2.1.5. Operations

2.2. Product functions

2.3. User characteristics
2.4. Constraints
 2.5. Assumptions and dependencies

3. Specific Requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communication interfaces
3.2 Specific requirements
3.2.1 Sequence diagrams
3.2.2 Classes for classification of specific requirements
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.5.1 Reliability
3.5.2 Availability
3.5.3 Security
3.5.4 Maintainability
3.6 Other requirements
4. Supporting information
4.1 Table of contents and index
4.2 Appendixes

Note: History of versions of this document with author/contributor info may be included before
the main sections of the document.

1.4 OUTPUT:

1. INTRODUTION
Here, we are developing an inventory management system for managing the shoes
inventory for providing the best quality shoes to the customer. The primary goal of this
inventory management system is to ensure that a company has the right amount of stock on
hand at any given time to meet customer demand while minimizing excess inventory and
associated costs.

1.1 PURPOSE
Our shoe inventory management system serves several purposes, primarily aimed at
providing best quality trendy shoes to the customer.
Alongside it also serves such purposes:

1.) Inventory Tracking: The primary purpose of a shoe inventory management system
is to accurately track the quantity, location, and status of shoes in stock.

2.) Order Management: It facilitates the management of orders by keeping track of

customer requests, purchases, and returns.

3.) Data Analysis and Reporting: Inventory management systems generate various
reports and analytics that offer insights into inventory turnover, sales trends, and
stock movement patterns.

4.) Improved Customer Service: Accurate inventory information enables businesses

to provide better customer service by ensuring that products are available when
customers need them.
 5.) Inventory Valuation: These systems provide accurate valuation of inventory,
which is crucial for financial reporting and decision-making.

1.2 INTENDED AUDIENCE

Our main target for shoe inventory management system is:
• Youth

• Individual aged between 14 years and above

1.3 SCOPE
The future scope of our shoe inventory system are as follow:
1.) Latest Design: Our registered user will get the shoes with latest design of that time
available in the market at reasonable prices.

2.) Trendy Shoe: Users will be able to get the trendy shoes as per the market trend.

3.) Efficient: With the varsity of time, it will provide a convenient way of shopping to
the user.

1.4 Definitions, acronyms & abbreviations

1.) DBMS – Database Management System

1.5 REFERENCE
IEEE standard 830-1998 recommended practice for Software Requirements
Specifications-Description.

1.6 OVERVIEW

1.) The SRS contains an analysis of the requirements necessary to help easy design.

2.) The overall description provides interface requirements for the Library
Management System, product perspective, hardware interfaces, software interfaces,
communication interface, memory constraints, product functions, user characteristics
and other constraints.
3.) Succeeding pages illustrate the characteristics of typical naïve users accessing the
system along with legal and functional constraints enforced that affect Library
Management System in any fashion.
2. OVERALL DESCRIPTION

2.1 PRODUCT PERSPECTIVE: A block diagram showing the major components of

the large system, interconnections and external interfaces can be useful

User Interface

Application Layer

Database Layer

Hardware Interface

2.1.1 User Interface

• Graphical User Interface (GUI) for accessing and managing inventory.
• Command-line interface (CLI) for advanced users or administrators.
2.1.2 Hardware Interface
• Barcode scanner: To input product information.
• RFID reader: For inventory tracking.
• Computer or mobile device: Interface for accessing the system.

2.1.3 Software Interface

• Database management system (e.g., MySQL, PostgreSQL) for storing
inventory data.
• API for integration with other systems (e.g., e-commerce platforms,
accounting software).

2.1.4 Memory Constraints

• Memory constraints will depend on the database management system and
hardware specifications.
• Adequate memory allocation for efficient data storage and retrieval.

2.1.5 Operations
• Inventory Management: Adding, updating, and removing shoe products from
the database.
• Stock Tracking: Monitoring stock levels, including restocking and depletion.
• Reporting: Generating reports on inventory status, sales trends, etc.
• User Management: Managing user accounts, permissions, and access levels.
• Integration: Interfacing with other systems for seamless operation (e.g., POS
systems, online stores).

2.2 Product Functions

2.2.1 Inventory Management:
• Add new shoe products to the inventory.
• Update existing product details such as quantity, price, size, etc.
• Remove discontinued products from the inventory.
 2.2.2 Stock Tracking
• Monitor stock levels in real-time.
• Receive alerts for low stock levels to prompt restocking actions.
• Track sales and inventory turnover rates.

2.2.3 User Management

• Create and manage user accounts with different access levels (e.g., admin, staff).
• Define permissions for each user role to restrict access to sensitive functions.

2.3 User characteristics

2.3.1 Administrators
• Have full access to all system functions.
• Responsible for overall management and configuration of the system

2.3.2 Warehouse Staff

• Require access to stock tracking functions.
• Responsible for managing physical inventory and stock movements.

2.4 Constraints
2.4.1 Hardware Limitations
• System performance may be limited by the hardware specifications of the
devices used.

2.4.2 Scalability
• The system should be able to handle a growing inventory and user base without
significant degradation in performance.

2.5 Assumptions and dependencies

2.5.1 Assumptions
• Users have basic computer literacy.
• The system operates within a stable network environment.

2.5.2 Dependencies
• Availability of barcode scanners and RFID readers for efficient data input.
• Integration with external systems (e.g., accounting software, e-commerce platforms)
requires API support from those systems.

3. Specific Requirement
3.1. External Interface Requirements
3.1.1. User interfaces

Graphical User Interface (GUI):

i) The GUI shall provide an intuitive interface for users to interact
with the system.
ii) It should include features for adding, updating, and removing shoe
products, as well as generating reports.
iii) The GUI shall support different user roles with varying levels of
access and permissions.
3.1.2 Database Description

The system should maintain database containing necessary information including:-

i) User Detail
ii) Admin Detail
iii) Product Detail
iv) Payment Records
v) Review Records

3.1.3 Front-End Description

i) There will be a navigation bar on the top of the landing page where users can
search for their product.

ii) There will be a card option next to the navigation bar for the user to view
their cart added products.

iii) There will also be a profile icon alongside the cart for letting the user visit
their account, change their details and other functions

iv) There will be latest deals popping up below the navigation bar.

v) On the center of the page there will category wise icons for the shoes as well
as the user.
 PROGRAM: 2

2.1OBJECTIVE 2.2THEORY 2.3 PROCEDURE 2.4 OUTPUT

2.1 OBJECTIVE: Draw the use case diagram of Library management system and specify the
role of each of the actors. Also state the precondition, post condition and function of each
use case.

2.2 THEORY:
Creating Use Case Diagrams
We start by identifying as many actors as possible. You should ask how the actors interact with
the system to identify an initial set of use cases. Then, on the diagram, you connect the actors with
the use cases with which they are involved. If actor supplies information, initiates the use case, or
receives any information as a result of the use case, then there should be an association between
them.
The following elements are available in a usecase diagram.
• Actor
• UseCase
• Association
• Directed Association
• Generalization
Actor
An actor defines a coherent set of roles that users of an entity can play when interacting with the
entity. An actor may be considered to play a separate role with regard to each use case with which it
communicates

Use Case
The use case construct is used to define the behavior of a system or other semantic entity without
revealing the entity’s internal structure. Each use case specifies a sequence of actions, including
variants, that the entity can perform, interacting with actors of the entity.

2.3 PROCEDURE:
Procedure for creating Actor
In order to create Actor, click [Toolbox] -> [UseCase] -> [Actor] button and click the position
where to place Actor. Actor is shown in the form of stick man or rectangle with icon that is decoration
view.
To display actor in decoration view, select [Format] -> [Stereotype Display] -> [Decoration] menu
item or select [Decoration] item in [combo button on toolbar.

Procedure for creating multiple Use Cases used by Actor at once

In order to create multiple Use Cases related to Actor at once, use shortcut creation syntax of Actor.
1. At the Actor's quick dialog, enter Use Case’s name after "-()" string. To create multiple Use Cases,
enter same but separate Use Case’s name by "," character.
2. And press [Enter] key. Several Use Cases associated with the Actor are created and arranged
vertically.

7
Procedure for creating Use Case
In order to create Use Case, click [Toolbox] -> [Use Case] button and click the position where to
place UseCase on the [main window].
UseCase is expressed in the forms of textual, decoration, iconic. To change UseCase's view style,
select menu item under [Format] -> [Stereotype Display] .

Procedure for adding Extension

An extension point references one or a collection of locations in a use case where the use case may
be extended.
To edit Extension Points of UseCase, click UseCase's [Collection Editor...] popup menu or click
button of [Extension Points] collection property.

2.4 OUTPUT: USE CASE