OBJECTIVE 1

IDENTIFY THE REQUREMENT FROM PROBLEM

STATEMENT

1.1 PROBLEM STATEMENT

The stock maintenance system must take care of sales information of the
company and must analyze the potential of the trade. It maintains the number
of items that are added or removed. The sales person initiates this Use case.
The sales person is allowed to update information and view the database.

1.2 INTRODUCTION:

Stock maintenance is an interface between the customer and the salesperson. It

aims at improving the efficiency in maintaining the stocks.

1.3 PURPOSE
The entire process of Stock maintenance is done in a manual manner
considering the fact that the number of customers for purchase is increasing
every year, a maintenance system is essential to meet the demand. So this
system uses several programming and database techniques to elucidate the
work involved in this process.

1.4 SCOPE

The System provides an interface to the customer where they can fill in orders
for the item needed.

The sales person is concerned with the issue of items and can use this system.

Provide a communication platform between the customer and the sales person.

1.5 DEFINITIONS , ACRONYMSA AND THE ABBREVIATIONS

Market Data provider: One who analyze the product and distribute the news.

Customer: One who takes order of product

Salesperson: One who maintains the stock details.

1.6 OVERVIEW
SRS includes two sections overall description and specific requirements
Overall Description will describe major role of the system components and
inter-Connections Specific Requirements will describe roles &functions of the
actors.
 OBJECTIVE 2

To the object of SDLC document requirements.

2.1 Software Development Life Cycle (SDLC)

Software development life cycle (SDLC) is a structured process that is used to

design, develop, and test good-quality software. SDLC, or software
development life cycle, is a methodology that defines the entire procedure of
software development step-by-step.

Fig.2.1 Software Development Life Cycle (SDLC)

The goal of the SDLC life cycle model is to deliver high-quality, maintainable
software that meets the user’s requirements. SDLC in software engineering
models outlines the plan for each stage so that each stage of the software
development model can perform its task efficiently to deliver the software at a
low cost within a given time frame that meets users’ requirements.

2.2 Software Development Models – SDLC Models

SDLC Models or Software Development Life Cycle (SDLC) models are
frameworks that guide the development process of software applications from
initiation to deployment. Various SDLC models in software engineering exist,
each with its approach to the phases of development. During the software
development phase, various software development life cycle models are
specified and designed. To guarantee success at each stage of the software
development process, each process model adheres to a set of phases specific to
its kind.

Fig.2.2: SDLC Models – Software Development Models

2.3 Waterfall SDLC Models:

The Waterfall model follows a linear and sequential approach to software

development. Each phase in the development process must be completed
before moving on to the next one, resembling the downward flow of a
waterfall. The model is highly structured, making it easy to understand and
use.
 Fig2.3 Waterfall SDLC Models

Phases of Waterfall SDLC Models:

Requirements: The first phase involves gathering requirements from

stakeholders and analyzing them to understand the scope and objectives of the
project.

Design: Once the requirements are understood, the design phase begins. This
involves creating a detailed design document that outlines the software
architecture, user interface, and system components.

Development: The Development phase includes implementation involves

coding the software based on the design specifications. This phase also
includes unit testing to ensure that each component of the software is working
as expected.

Testing: In the testing phase, the software is tested as a whole to ensure that it
meets the requirements and is free from defects.

Deployment: Once the software has been tested and approved, it is deployed
to the production environment.
Maintenance: The final phase of the Waterfall Model is maintenance, which
involves fixing any issues that arise after the software has been deployed and
ensuring that it continues to meet the requirements over time

Advantages of the Waterfall SDLC Models:

Simplicity: The linear and sequential nature of the Waterfall models makes it
easy to understand and implement.

Clear Documentation: Each phase has its own set of documentation, making
it easier to track progress and manage the project.

Stable Requirements: Well-suited for projects with stable and well-defined

requirements at the beginning.

Predictability: Due to its structured nature, the Waterfall model allows for
better predictability in terms of timelines and deliverables.

Disadvantages of the Waterfall SDLC Models:

Rigidity: The model is highly inflexible once a phase is completed, making it

challenging to accommodate changes.

Late Testing: Testing is performed after the implementation phase, so defects

might not be discovered until late in the process.

Limited Client Involvement: Clients are involved mainly in the initial phase,
and significant changes cannot be easily accommodated later in the
development process.

No Prototyping: The models lack the provision for creating prototypes, which
could be a disadvantage in projects where user feedback is crucial.
 OBJECTIVE 3

ESTIMATION OF PROJECT METRICS

Project Duration: Estimate the total time required for development, testing,
and deployment of the stock management system. Break it down into phases
such as planning, design, development, testing, and deployment.

Resource Allocation: Determine the number of developers, testers, designers,

and other team members required for the project based on its scope and
complexity.

Budget: Estimate the total cost of the project, including salaries, infrastructure
costs, software licenses, and any other expenses.

Scope: Clearly define the features and functionalities of the stock management
system to ensure that the project stays on track and within budget.

Risk Assessment: Identify potential risks that could impact the project
timeline, budget, or quality, and develop mitigation strategies to address them.

Quality Assurance Metrics: Define metrics for measuring the quality of the
stock management system, such as code coverage, defect density, and
customer satisfaction.

Performance Metrics: Determine performance benchmarks for the system,

such as response time, throughput, and scalability.

User Adoption: Estimate the expected adoption rate of the stock management
system among users, and plan for user training and support accordingly.

Maintenance: Estimate the ongoing maintenance effort required to support

and update the stock management system after deployment.

Success Criteria: Define criteria for measuring the success of the project,
such as meeting project deadlines, staying within budget, and achieving the
desired level of functionality and performance.
 OBJECTIVE 4

Modeling UML Use Case Diagrams and Capturing Use Case Scenarios

4.1 Use Case Diagram

Its purpose is to present a graphical overview of the functionality provided by

a system in terms of actors and their goals.
The main purpose of a use case diagram is to show what system functions are
performed for which actors.

4.2 Diagram Building Block Use cases

A use case describes a sequence of actions that provide something of
measurable value to an actor and is drawn as a horizontal ellipse.

Use case

Actor

An actor is a person, organization or external system that plays a role in one or

more interactions with the system.

Actor
System boundary boxes (optional)

A rectangle is drawn around the use case called the system boundary box to
indicate scope of the system.
Fig.4.1 SMS Use Diagram
 Objective 5

E-R MODELLING FROM THE PROJECT STATEMENT.

5.1 Introduction of ER Model

The Entity Relational Model is a model for identifying entities to be

represented in the database and representation of how those entities are related.
The ER data model specifies enterprise schema that represents the overall
logical structure of a database graphically.

5.2 Why Use ER Diagrams In DBMS?

ER diagrams are used to represent the E-R model in a database, which makes
them easy to convert into relations (tables).

ER diagrams provide the purpose of real-world modeling of objects which

makes them intently useful.

ER diagrams require no technical knowledge and no hardware support.

These diagrams are very easy to understand and easy to create even for a naive
user.

It gives a standard solution for visualizing the data logically.

5.3 Symbols Used in ER Model

Entity Symbol Name Descripti

on

Stron These
g entity shapes
are
independ
ent from
other
entities,
and are
often
 called
parent
entities,
since they
will often
have
weak
entities
that
depend
on them.
They will
also have
a primary
key,
distinguis
hing each
occurrenc
e of the
entity.

Weak Weak
entity entities
depend
on some
other
entity
type.
They
don't
have
primary
keys, and
have no
 meaning
in the
diagram
without
their
parent
entity.

Associativ Associati
e entity ve entities
relate the
instances
of several
entity
types.
They also
contain
attributes
specific
to the
relationsh
ip
between
those
entity
instances.

Attribute Symbol Name Descripti

on

Attribute Attributes
are
characteri
stics of an
entity, a
 many-to-
many
relationsh
ip, or a
one-to-
one
relationsh
ip.

Multivalue Multivalu
d attribute ed
attributes
are those
that are
can take
on more
than one
value.

Derived Derived
attribute attributes
are
attributes
whose
value can
be
calculated
from
related
attribute
values.
 Relationshi Relations
p hips are
associatio
ns
between
or among
entities.

OBJECTIVE 6
 IDENTIFYING DOMAIN CLASSES FROM THE PROBLEM
STATEMENTS

1. Product: This class represents individual items or products that are being
managed in the system. It might include attributes such as product ID, name,
description, price, quantity in stock, etc.

2. Inventory: This class manages the overall inventory of products. It might

include methods for adding, removing, or updating products in the inventory.

3. Supplier: Represents the entities or companies that supply the products to the
system. Attributes might include supplier ID, name, contact information, etc.

4. Order: This class represents orders placed for products. It could include
attributes such as order ID, customer ID, date, status (pending, shipped, etc.),
and a list of products ordered.

5. Customer: Represents the customers who are purchasing products. Attributes

might include customer ID, name, contact information, etc.

6. Transaction: This class tracks the transactions that occur within the system,
such as purchases, sales, returns, etc. Attributes might include transaction ID,
type (purchase, sale, return), date, products involved, etc.

7. Location/Storage: Represents the physical locations where products are stored

within the system. Attributes might include location ID, name, capacity, etc.

8. Category/Classification: Represents the categories or classifications to which

products belong. This can help organize and categorize products within the
system.

9. User: Represents the users who interact with the system. Attributes might
include user ID, username, password, permissions, etc.

10. Report: Represents the various reports that can be generated from the system,
such as inventory reports, sales reports, etc. Attributes might include report ID,
type, date, parameters, etc.

OBJECTIVE 7
STATECART AND ACTIVITY MODELING

States:

Idle: The initial state where the system is waiting for input.

Processing Order: The system is processing an order.

Adding Stock: The system is adding stock to the inventory.

Removing Stock: The system is removing stock from the inventory.

Out of Stock: Indicates that a particular item is out of stock.

Transitions:

Place Order: Transition from Idle to Processing Order when a new order is
placed.

Order Processed: Transition from Processing Order back to Idle when the
order processing is completed.

Add Stock: Transition from Idle to Adding Stock when new stock is added to
the inventory.

Stock Added: Transition from Adding Stock back to Idle when the stock
addition process is completed.

Remove Stock: Transition from Idle to Removing Stock when stock is

removed from the inventory.

Stock Removed: Transition from Removing Stock back to Idle when the stock
removal process is completed.

Stock Empty: Transition from Idle to Out of Stock when the inventory is
depleted for a particular item.

Restock: Transition from Out of Stock back to Idle when new stock is added
to replenish the inventory.
 State Chart diagram

Place Order: Represents the activity of placing an order.

Process Order: Checks if the order is valid and if the items are available in the
inventory.

Update Inventory: Updates the inventory based on the order or stock

addition/removal.

Notify User: Notifies the user about the outcome of the operation (order processed,
items out of stock, etc.).

Add Stock: Represents the activity of adding stock to the inventory.

Remove Stock: Represents the activity of removing stock from the inventory.

Start and End: Indicate the beginning and end of the activity diagram, respectively.
Fig. Activity Diagram
 OBJECTIVE 8

MODELING UML CLASS DIAGRAM AND SEQUENCE

DIAGRAMS

A class diagram is a type of diagram in the Unified Modeling Language (UML) that
represents the structure of a system by showing the classes of the system, their
attributes, methods, and relationships between them. It provides a static view of the
system's structure and is widely used in software engineering for design and
documentation purposes.

Name Notation Description

Class Represents a blueprint

or template for creating
objects in the system.

Attributes Represented as
variables within a class
 OBJECTIVE -9

MODELING DATA FLOW DIAGRAMS

Define

A Data Flow Diagram (DFD) is a graphical representation that depicts the flow of data
within a system. It illustrates how data moves from one process to another, how it is
stored, and how it is transformed along the way. DFDs are commonly used in system
analysis and design to model the information flow and processes within a system.
Level(0)Data flow Diagram
Level (1) Data flow diagram
 OBJECTIVE 10

ESTIMATATION OF TEST COVERAGE METRICS AND

STRUCTURAL COMPLEXITY
Functional Coverage:

Ensure all core functionalities of the stock management system are thoroughly tested,
such as inventory tracking, order processing, stock replenishment, and reporting.

Test cases should cover the end-to-end flow of data and processes within the system.

Integration Coverage:

Verify the system's ability to seamlessly integrate with external systems, such as
supplier portals, customer relationship management (CRM), and accounting software.

Test the accuracy of data exchange, error handling, and overall system interoperability.

Risk Coverage:

Assess the system's security, including protection against common vulnerabilities like
SQL injection, cross-site scripting, and unauthorized access.

Evaluate the system's performance under high load, stress, and edge cases to ensure it
can handle real-world scenarios.

Condition Coverage:

Test various business rules and conditions related to inventory management, such as
discounting, stock allocation, and backorder handling.

Ensure the system correctly applies the appropriate logic and provides a seamless user
experience.

Stock Coverage Metrics:

Measure the stock turnover rate to understand how efficiently inventory is being sold
and replenished.

Evaluate stock accuracy to ensure the physical inventory matches the recorded data,
minimizing discrepancies.
Calculate stock coverage to determine how long the current inventory will last based on
the average sales rate, aiding in replenishment planning.

Monitor stock availability to ensure a high percentage of items are in stock and ready
for delivery.

Assess stock obsolescence to identify and minimize outdated or unsellable inventory.

 OBJECTIVE 11

DESINGING TEST SUITES

Test Test Test case States Expected Output

Case Case Description Result Result
Id Name

1. User Verify Navigate to User should be Passed

Registration successful the registration successfully
user page. registered and
registration logging into the
Fill in valid
system
user
information

2.